前言
本系列文章適用于已經了解 RxJava 的讀者，深入貫徹其原理，加深對其的認識。如果從未了解過 RxJava 的讀者們，建議先熟悉它。
RxJava 0.x
RxJava 最早是 Netflix 參照微軟的 Rx.Net，在 Java 上實現一套類似的庫，0.x 其實就是社區內部迭代開發的時代。
在 0.x 的迭代過程中，API 還不穩定，在長期的變更中，逐步完善了 Observable，Publisher，Subscriber，Scheduler 等接口以及大量的操作符。
Reactive Streams
在開發 RxJava 早期版本的過程中，開發組也參與了制定 Reactive Streams 規范。
但是 RxJava1 并沒有遵循這個規范，因為考慮到下面幾個原因：
- Subscriber.onComplete 和 當時的 Observer.onCompleted 相差一個字母，導致 API 不能兼容。
- RxJava 中的 Subscription 和 RS 中的有些細微的區別，它不能在沒有較大變動的情況下實現 request(n) 方法，因此 RxJava 引入了 Producer 這個接口，并混在了 Subscriber 中。
- RS 彼時不是穩定版本，也在持續修訂中。
因此 RxJava 開發組決定在 2.0 版本中正式支持 RS 規范，在 1.x 版本中實現類似的機制，而不像在 2.0 中直接使用 RS 的接口。
Backpressure
由于 RS 的影響，在 0.20.0-RC1 中 RxJava 第一次引入 Backpressure 的概念，從此 RxJava 變成了一個讓人愛恨交織的庫。事實上 RxJava 開發組也曾表示，在 RxJava 早期版本中，在 Observable 混入 Backpressure 是一個重大的失誤。
- 由于 Backpressure 是在中間版本引入的，因此部分操作符支持，部分操作符不支持，導致對使用者有些混亂和不友好。
- 在熱數據源中（如點擊事件），是無法被正確地 backpressured ，從而導致經常出現意外的
MissingBackpressureException。
事實上正如現在 2.x 中做的那樣，正確的做法是應該把模塊分為 支持 Backpressure 和不支持的兩類。在 io.reactivex.Observable 中徹底移除了 Backpressure，而 io.reactivex.Flowable 則遵循 RS 規范支持 Backpressure。
RxJava 1.x
經過兩年多的迭代，RxJava 在 14 年 9 月發布了 1.0.0 正式版。
上面有提到，其實 1.x 是一個類似 RS 的版本，但是不依賴 RS 的接口。同時對比 0.x，做了如下的更改。
依賴方式
| groupId | artifactId | |
|---|---|---|
| 0.x | com.netflix.rxjava | rxjava-core |
| 1.x | io.reactivex | rxjava |
拆分項目
在 RxJava 1.0.0 發布之際，把 JVM 上其他語言的實現和子工程都獨立出去了，而在 RxJava 庫中只保留了 Java 版的實現。
如：
其他
新增和廢棄了部分操作符，修復了大量的 BUG。
RxJava 2.x
RxJava 2.0.0 正式版發布于 2016 年 9 月底。
筆者也曾寫過一篇 《淺談RxJava與2.0的新特性》，不過寫那篇文章時還在版本還在 2.0.0-RC1，以現在的角度看起來不免顯得不夠全面，因此最好的理解方式還是看官方的 Wiki。
類型
| 1.x | 2.x | |
|---|---|---|
| Single/Completable | Maybe | 0 或 1 數據源 |
| Observable | Flowable | 多數據源 |
| Subject | Processor | 熱數據源 |
正如上面所說的，RxJava2 遵循了 RS 規范，其冷數據源真正實現的類型就是 Flowable，熱數據源的實現則在io.reactivex.processors包中。
同時也把 Observable 中舊的 Backpressure 徹底移除，因此在 RxJava2 中使 用 Observable 再也不會拋出MissingBackpressureException。
Observable 與 Flowable
在 RxJava2 中， Flowable 和 Observable 雖然實現的代碼復用了一部分，但是機制卻大相徑庭。這里要涉及到數據源的三種模型：
數據源
- 響應式推：如鼠標點擊事件。此時生產者無條件產生數據，消費者負責配合生產者。
- 同步拉：如
Iterable的迭代。此時消費者提出要求，生產者配合消費者下發，數據源是確定的。 - 異步拉：如
Future，Processor。消費者提出要求，生產者據此下發數據，但是數據到來不確定。
Observable
在 Observable 中，消費者是無權提出要求的，即數據都是生產者提供的，消費者只能被動接受。雖然數據源不確定，但是對消費者是透明的，只能被動等待數據。由于 Observable 已經徹底移除了 Backpressure，因此對于消費速度和生產速度不協調時，中間操作符可能會創建 Buffer(如 observeOn）來緩存數據。因此數據在無限的積累中可能會導致 OOM， 但不再會拋出MissingBackpressureException。
Flowable
在 Flowable 中，消費者通過Subscription主動的向生產者提出自己需求的數量，上游據此發射數據。從而就有生產和消費的矛盾。如果是數據源是響應式推或者異步拉時，可能會導致MissingBackpressureException。
舉例
這么說有點抽象，我們舉個例子。Subject / Processor 就是對應異步拉的數據源，也是熱數據源。消費者在訂閱他們后，無論是否可以 request，數據的是否產生以及產生速度也是未知的。
在接受到onNext時：
- Subject 直接轉發給下游
- Prosessor 檢查下游的 request 數目，如果少于已經發送的數目，則拋出
MissingBackpressureException
因此使用Prosessor稍有不慎就會出錯哦。當然在實際使用中Flowable.subscribe()時，內置的 Subscriber 通常都會在 onSubscribe 時直接向生產者request(Long.MAX_VALUE)，在 RxJava2 Long.MAX_VALUE 是一個特殊值，意味著無限流。大家可參見 subscribers
選擇
對于 Observable 與 Flowable 的選擇官方也有提示：
-
選擇 Observable：
- 處理不超過 1000 個數據時，因為數據很少，一般不會觸發 OOM
- 處理 GUI 或者點擊事件時，因為這些事件是異步推的，很難被 backpressured 也一般不這樣做
- 數據源本質上是同步的，但是平臺不支持 Java Stream API 或者你想用 RxJava 豐富的操作符，因為 Observable 比 Flowable 的性能更好
-
選擇 Flowable：
- 處理 10k+ 數據且數據源是可控的
- 基于拉的且阻塞的數據源
拆分之爭
事實上 RxJava 自 16年 開始社區一度有討論是否要把 RxJava2 拆分成多個庫，因為：
- 區分是否支持 Backpressure
- 將通用的代碼獨立出去，如
Scheduler、SimpleQueue - 減少包體積的大小
但是最終經過討論后還是放棄了：
- 使用 Proguard 來壓縮 RxJava2 的效果非常好，基本上是用多少保留多少代碼
- 如果拆分開，強行逼迫使用者需要了解 Backpressure 的概念，且增加了使用方的麻煩，因為他們需要區分自己到底需要哪些庫
- 多個不同版本子庫的組合可能會導致兼容問題
- 拆分后，Observable 和 Flowable 互不依賴，互轉需要使用靜態方法，打斷了鏈式操作
- ...
結語
如果您作為一個 Android 開發者，正在糾結于 RxJava 帶來的好處和他的龐大的體積，那么您可以打消這個顧慮了，只要正確地配置了 Proguard，RxJava 對您包體積大小的影響微乎其微。反過來說，如果沒有配置 Proguard，那么是否引入 RxJava 確實是值得思考的一件事。
事實上，做一個 Android 開發者，筆者認為 RxJava 簡直是為 Android 而生的，天生響應式的事件與 RxJava 的結合能大幅提供您的工作效率。前提是您有一些函數式編程的思維，能把流程拆解成一個個操作符。
