另一个原因是将Observable的类型划分为两种类型:Observable和 Flowable。让一切都需要背压是错误的，因为并非所有的用例都是这样。它有轻微的性能开销，但是这是一个错误的主要原因是它增加了使用Observable的心理复杂性（其实就是考虑是否使用的纠结），并且极大地增加了创建自定义操作符的难度。

纯推送用例应该能够使用由Erik Meijer设计的Observable，而无需考虑Reactive Streams的request(n)语义。这些用例非常常见。基本上，所有用户界面(UI)用例，比如Android，都是纯push的;request(n)的使用是令人困惑的，并且不必要地使事情复杂化。是的，在这些情况下，onBackpressureDrop风格的操作符是非常有用的，但是那些应该是可选择的。

因此,RxJava2中，Observable将不会遵循Reactive Streams类型或者规范，它是一个纯push的操作，没有request(n) 。一个新的Flowable 类型将会被添加进来，它即是带有背压特性的Observable，并且实现Reactive Streams Publisher类型和规格。而名字“Flowable ”受到Java 9 java.util.concurrent.Flow的启发，它采用了Reactive Streams接口。

在公共API中，通过Observable 和Flowable可以很清楚知道我们的数据源的行为。如果它是一个Observable ，它将推送，而消费者必须做好准备。如果它是一个Flowable，它将以推-拉的方式运行，并且只发送由使用者请求的数量的条目。它们之间的桥接将是可能的，类似于RxJava v1的工作方式，但是它将会更加明确，比如observable.toFlowable(Strategy.DROP) ，它可以将一个Observable 转换为一个具有适当的背压策略的Flowable，如果推送的数据的速度超过了消费者的处理速度，那么就可以应用这个策略来背压反馈。

发布RxJava2的最后一个主要原因是提高整体性能(减少开销)的能力，因为它不再受RxJava1设计的架构限制的约束。这在一定程度上是通过在构建操作符链、订阅和运行它们时减少分配数量来实现的。默认情况下，Subscribers 不再被封装到一个SafeSubscriber(提供在Flowable.safeSubscribe()中)，并且不再需要在终端事件（它是RxJava2上的unsubscribe术语）上cancel链。

性能改进的第二个来源是一个名为operator-fusion 的内部优化方法(它扩展了Reactive-Streams协议)，大大减少了许多典型的同步流设置（有时也在异步流中）中的背压和队列管理的开销。在一些基准测试中，与Java 8的流相比，具有背压的流量的吞吐量要慢20 - 30%，相比之下，RxJava1的吞吐量是慢100 - 200%左右。