RxJava2.0 Observable 对比（Flowable + onBackPressureDrop()）
RxJava2.0 Observable vs ( Flowable + onBackPressureDrop() )
我正在迁移到 RxJava2.0，我不太明白为什么它会在 API.
中引入 Flowables 的概念
在 2.x 上，Observable 类型不再支持背压。如果您的事件源可以减慢速度，您应该使用具有适当背压策略的 Flowable。
我的问题是：为什么他们不只保留 Observable 类型，而只是让您在那些无法减慢的来源上调用 .onBackPressureDrop() 或类似的类型。这将防止 MissingBackPressureException
编辑
根据@akarnokd 的回答：
"There are use cases, ..., where people don't want to lose data. If
the the data source supports a form of cooperation then stages with
different speed can still work together without overflowing anybody or
running out of memory."
我同意，但在这种情况下，应该为每个用例使用适当的背压策略。如果数据源不支持合作形式，则使用 onBackpressureDrop() 避免 MissingBackpressureException。没有？
"The project management at the time decided to add backpressure to the
Observable type, which in theory should have been able to deal with
both bounded and unbounded use, but lead to a lot of confusion and a
never ending routine to try to educate users about why they get
MissingBackpressureException."
我明白了，但是创建两个单独的接口（flowable/observable 具有不同的父接口 (ObservableSource/Publisher`)）并复制其中的所有运算符不会'不要让它对初学者更友好。
我认为它现在非常混乱的原因是因为发音相似 class/method names
Observer/SubscriberPublisher/ObservableSourceObservable/Flowablesubscribe/subscribeWithSubscription 和 Disposable 一样吗？- 为什么 Flowable 在
subscribe() 时返回 Disposable
接口 Subscriber 和 Publisher 与 Subscriptions 一起工作。 （Observable 也 returns Disposable，这是有道理的，因为 Observer 和 ObservableSource 与 Disposable 一起工作）
由于相似或相同的 class/interface 名称，光是写这篇文章就很混乱。它们是同义词，很容易混淆！
why haven't they just kept the Observable type and just have you call .onBackPressureDrop() or similar on those sources that cannot be slowed down
有些用例，我猜大多数情况下，人们不想丢失数据。如果数据源支持一种合作形式，那么具有不同速度的阶段仍然可以一起工作而不会溢出任何人或 运行 内存不足。
is it the only reason they split the Observable class into flowable/observable?
没有。最初的 ReactiveX 设计主要预期类似 GUI 的用例或小型异步数据源，在这些情况下没有很好的方法来控制序列。当 ReactiveX 概念在 Netflix 中被引入 "real use" 时，很快发现当数据丢失不是一种选择时，异步边界上的无界流会给内存和系统带来不必要的压力。
当时的项目管理决定给Observable类型加backpressure，理论上应该可以同时处理bounded和unbounded的使用，但是导致很多混乱，永远不会结束例程以尝试教育用户他们为什么会得到 MissingBackpressureException.
当 2.x 的工作开始时，新的管理层（后来）和外部各方看到了将多值源类型分成两部分的价值：Observable 用于非背压流Flowable 现在完全可以感知背压。要从 Observable 转换为 Flowable 或简单地创建命令式 Flowable，必须指定背压策略（不像 1.x，后者缺少默认支持并导致很多坏习俗 Observables）。这对于简单的源流来说是一种便利，它总是可以创建更复杂的背压行为。
请参阅 wiki 以获取有关用途的建议。
我正在迁移到 RxJava2.0，我不太明白为什么它会在 API.
中引入Flowables 的概念
在 2.x 上，Observable 类型不再支持背压。如果您的事件源可以减慢速度，您应该使用具有适当背压策略的 Flowable。
我的问题是：为什么他们不只保留 Observable 类型，而只是让您在那些无法减慢的来源上调用 .onBackPressureDrop() 或类似的类型。这将防止 MissingBackPressureException
编辑
根据@akarnokd 的回答：
"There are use cases, ..., where people don't want to lose data. If the the data source supports a form of cooperation then stages with different speed can still work together without overflowing anybody or running out of memory."
我同意，但在这种情况下，应该为每个用例使用适当的背压策略。如果数据源不支持合作形式，则使用 onBackpressureDrop() 避免 MissingBackpressureException。没有？
"The project management at the time decided to add backpressure to the Observable type, which in theory should have been able to deal with both bounded and unbounded use, but lead to a lot of confusion and a never ending routine to try to educate users about why they get MissingBackpressureException."
我明白了，但是创建两个单独的接口（flowable/observable 具有不同的父接口 (ObservableSource/Publisher`)）并复制其中的所有运算符不会'不要让它对初学者更友好。
我认为它现在非常混乱的原因是因为发音相似 class/method names
Observer/SubscriberPublisher/ObservableSourceObservable/Flowablesubscribe/subscribeWithSubscription和Disposable一样吗？- 为什么 Flowable 在
subscribe()时返回 Disposable 接口Subscriber和Publisher与Subscriptions一起工作。 （Observable也 returnsDisposable，这是有道理的，因为Observer和ObservableSource与Disposable一起工作）
由于相似或相同的 class/interface 名称，光是写这篇文章就很混乱。它们是同义词，很容易混淆！
why haven't they just kept the Observable type and just have you call .onBackPressureDrop() or similar on those sources that cannot be slowed down
有些用例，我猜大多数情况下，人们不想丢失数据。如果数据源支持一种合作形式，那么具有不同速度的阶段仍然可以一起工作而不会溢出任何人或 运行 内存不足。
is it the only reason they split the Observable class into flowable/observable?
没有。最初的 ReactiveX 设计主要预期类似 GUI 的用例或小型异步数据源，在这些情况下没有很好的方法来控制序列。当 ReactiveX 概念在 Netflix 中被引入 "real use" 时，很快发现当数据丢失不是一种选择时，异步边界上的无界流会给内存和系统带来不必要的压力。
当时的项目管理决定给Observable类型加backpressure，理论上应该可以同时处理bounded和unbounded的使用，但是导致很多混乱，永远不会结束例程以尝试教育用户他们为什么会得到 MissingBackpressureException.
当 2.x 的工作开始时，新的管理层（后来）和外部各方看到了将多值源类型分成两部分的价值：Observable 用于非背压流Flowable 现在完全可以感知背压。要从 Observable 转换为 Flowable 或简单地创建命令式 Flowable，必须指定背压策略（不像 1.x，后者缺少默认支持并导致很多坏习俗 Observables）。这对于简单的源流来说是一种便利，它总是可以创建更复杂的背压行为。
请参阅 wiki 以获取有关用途的建议。