Observable优于Flowable的实际优势是什么？

Question

2.0中的不同之处描述了Observable和之间的区别Flowable.然而,Observable主要是根据与之相比缺乏的特征来描述Flowable.Observable提到的只有一个显着特征:

使用Observable通常比开销更低Flowable.

但即便如此,这似乎与Observable少数元素更有利的建议相矛盾,并且更有可能导致OutOfMemoryError过于严重的任务.这似乎表明Flowable通常更有效率.

另一件令我困惑的事情是,如果Observable对于少于1K元素Flowable的用例是优选的,并且对于具有超过10K元素的用例是优选的,则具有1K和10K元素之间的用例是灰色区域.

是否有更多技术解释Observable和Flowable？之间的差异？ 特别是提出了一种实用的启发式方法,用于决定在1K和10K元素之间的灰色区域中使用哪种方法,或者当元素的数量未知或可能改变时.

相关:此问答仅引用文档而无需进一步说明.

Answer 1

对Observable和Flowable之间的差异有更多技术性的解释吗？

我会给你一个,但大多数人都被技术细节吓到了.

但是,Observable主要是根据与Flowable相比缺少的功能来描述的.

是的,因为从技术上Observable是Flowable减去所有运营商的背压的有关要求协调逻辑.

但即使这似乎也与建议相矛盾......

没有矛盾,通过Observable从一端到另一端的值获得较少的"阻力",因为逻辑不必处理请求协调或临时缓冲.例如,Observable.flatMapIterable不必排队源项目,因为每个内部Iterable都可以立即从中完整地流式传输onNext.Flowable必须排队物品,蹦床排水和可变物品排放,并将其限制在与直接排放相比相当昂贵的排队 - 排水逻辑中的所需数量.

这似乎表明Flowable通常更有效.

在内存使用(因此GC开销)和延迟之间存在权衡.

然后具有1K和10K元素之间的用例是灰色区域.

这意味着在这两个数字之间,您可能需要找到其他决策变量,例如单个元素大小,预期延迟,您的应用/系统的其余部分正在做什么等.

或当元素的数量未知或可能改变时

为的情况下Observable使用单词"最长",这意味着在任何给定时间,有1000个元件或更小,或者可替换地的可能缓冲序列,将信号源发出每毫秒至多1个元件上平均.

这是一个典型的"依赖"案例:

• 源可以合理地反压吗？
• 处理逻辑通常比源或其上级慢吗？
• 不同的订阅者会遇到不同数量的元素吗？
• 环境是否受到某种限制？
• 物品比较大吗？

如果您对这些问题的答案是肯定的,那么您最好还是选择Flowable.