深入理解 RxJava2：前世今生（1）

蝶翼的罪發表於2018-08-12
RxJava

前言

本系列文章適用於已經瞭解 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 並沒有遵循這個規範，因為考慮到下面幾個原因：

  1. Subscriber.onComplete 和 當時的 Observer.onCompleted 相差一個字母，導致 API 不能相容。
  2. RxJava 中的 Subscription 和 RS 中的有些細微的區別，它不能在沒有較大變動的情況下實現 request(n) 方法，因此 RxJava 引入了 Producer 這個介面，並混在了 Subscriber 中。
  3. 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 的結合能大幅提供您的工作效率。前提是您有一些函數語言程式設計的思維，能把流程拆解成一個個操作符。

最後，歡迎關注筆者公眾號，有問題歡迎後臺留言：

深入理解 RxJava2：前世今生（1）

相關文章