我正在迁移到RxJava2.0，我不太明白为什么它会将Flowables的概念引入API。
在2.x上，Observable类型不再支持背压。如果您的事件来源可以放慢速度，那么您应该使用Flowable并采用适当的背压策略。
我的问题是：为什么他们只保留Observable类型，只是让你在那些无法减速的来源上打电话给.onBackPressureDrop()或类似的人。这会阻止MissingBackPressureException
修改
根据@akarnokd回答：
＆＃34;有用例，...，人们不想丢失数据。如果 数据源支持一种合作形式，然后分阶段 不同的速度仍然可以一起工作，而不会溢出任何人或 内存不足。＆＃34;
我同意，但在这种情况下，应该为每个用例使用适当的背压策略。如果数据源不支持某种形式的合作，请使用onBackpressureDrop()来避免MissingBackpressureException。否？
＆＃34;当时的项目管理层决定为该项目增加背压 可观察的类型，理论上应该能够处理 有界和无界的使用，但导致很多混乱和a 永无止境地试图教育用户他们为什么会这样做 MissingBackpressureException＆＃34;
我明白了，但创建了两个独立的接口（flowable / observable，它们具有不同的父接口（ObservableSource/ Publisher`））并复制其中的所有运算符。让它更适合初学者友善。
我认为它现在非常令人困惑的原因是因为类似的发声类/方法名称
Observer / Subscriber Publisher / ObservableSource Observable / Flowable subscribe / subscribeWith Subscription相同，是Disposable？subscribe()时返回一个Disposable
接口Subscriber和Publisher与Subscriptions一起使用。 （Observable也会返回Disposable，这是有道理的，因为Observer和ObservableSource与Disposable合作由于相似或相同的类/接口名称，只是写这个非常混乱。它们是同义词，很容易混淆！
答案 0 :(得分：2)
为什么他们不保留Observable类型，只是在那些无法减速的源上调用.onBackPressureDrop（）或类似的
有用例，我猜大多数情况下，人们不想丢失数据。如果数据源支持一种合作形式，那么不同速度的阶段仍然可以一起工作，而不会溢出任何人或内存不足。
它是将Observable类拆分为flowable / observable的唯一原因吗？
没有。最初的ReactiveX设计主要是预期的类似GUI的用例或小型异步数据源，其中没有好的方法来流程控制序列。当ReactiveX概念在Netflix中被“实际使用”时，很快就会发现，当数据输出不是一个选项时，异步边界上的无限制流动会给内存和系统带来不必要的压力。
当时的项目管理决定将背压添加到Observable类型，理论上它应该能够处理有界和无限使用，但会导致很多混乱和永无止境的例行程序尝试向用户介绍他们获得MissingBackpressureException的原因。
当开始处理2.x时，新管理（后来）和外部各方看到了将多值源类型拆分为两个的值：Observable用于非背压流和{{1现在是完全背压感知的。要从Flowable转换为Observable或仅创建命令式Flowable，必须指定背压策略（与1.x不同，默认支持不存在且导致大量损坏自定义Flowable s）。这对于简单的源流是一种便利，人们总能创建更复杂的背压行为。
请参阅wiki以获取有关使用哪些内容的建议。