What's different in 2.0描述了Observable和Flowable之间的差异。但是，Observable主要是根据与Flowable相比缺少的功能进行描述。提到的Observable只有一个显着特征：
使用
Observable的开销通常低于Flowable。
但即使这似乎与Observable对于少数元素更可取的建议相矛盾，如果任务太多，则更有可能导致OutOfMemoryError。这似乎表明Flowable通常更有效率。
另一件让我感到困惑的事情是，对于少于1K元素的用例，如果Observable是首选，对于超过10K元素的用例，Flowable是首选，那么使用1K之间的用例和10K元素是一个灰色区域。
对Observable和Flowable之间的差异是否有更多技术性解释？特别是提出了一种实用的启发式算法来决定在1K之间的灰色区域使用哪种方法和10K元素，或当元素数量未知或可能改变时。
相关：This Q&A仅引用文档而无需进一步说明。
答案 0 :(得分：10)
对Observable和Flowable之间的差异有更多技术性的解释吗？
我会给你一个，但大多数人都会被技术细节吓到。
然而，Observable主要用与Flowable相比缺乏的功能来描述。
是的，因为技术上Observable是Flowable减去所有运营商的背压相关请求协调逻辑。
但即使这似乎与建议相矛盾......
没有矛盾，通过Observable从一端到另一端获取值会遇到较少的“阻力”，因为逻辑不必处理请求协调或临时缓冲。例如，Observable.flatMapIterable不必排队源项，因为每个内部Iterable可以立即从onNext完整地流式传输。 Flowable必须排队物品，蹦床排水和可变物品排放，并将其限制在相当昂贵的队列排水逻辑中与直接排放相比所需的数量。
这似乎表明Flowable通常更有效率。
在内存使用（因此GC开销）和延迟之间存在权衡。
然后，具有1K和10K元素之间的用例是灰色区域。
这意味着在这两个数字之间，您可能需要找到其他决策变量，例如单个元素大小，预期延迟，应用程序/系统的其余部分，等等。
或当元素数量未知或可能发生变化时
Observable的情况使用“最长”一词，这意味着在任何给定时间，您可能有1000个元素或更少的缓冲序列，或者您的源每毫秒最多发出1个元素平均。
这是典型的“依赖”案例：
如果您对这些问题的回答是肯定的，那么您最好使用Flowable。
答案 1 :(得分：0)
Observable和Flowable非常相似。 Flowable更新，通常更先进：
Observable仍然存在的原因是与原始Microsoft的ReactiveX框架的概念兼容性。记住RxJava是ReactiveX project的一部分。
在大多数（甚至所有）案例中，我建议Flowable超过Observable。除非您正在开发Java部分不占优势的多语言项目。