再見！RxJava！

看到這個標題你可能會驚訝，作為 RxJava 堅定的擁護者，為什么突然不再支持 RxJava 了呢？本文是來自 W_BinaryTree 博客^[1]，對于 RxJava 我一直感冒不起來，W_BinaryTree 的觀點與我不謀而合，同時也歡迎你說說對?RxJava?看法。

先講講歷史

在我的文章中已經(jīng)講過很多次 RxJava 誕生之初就是因為異步。再后來借鑒 LINQ 的思想借用 Monad 的力量使得 Rx 可以使用操作符進行組合將各種復(fù)雜的請求簡單化。可以說，RxJava 的設(shè)計初衷就是圍繞著 Asyhconization 和 Composition。當年的 Netflix 也是為了增加服務(wù)器的性能和吞吐量來編寫 RxJava 并開源。才使得 RxJava 問世。

再聊聊異步

在那個 RxJava 剛剛火爆的年代，那是一個荒蠻的年代。我們在異步方面資源匱乏，手頭僅有 ThreadPool,AsyncTask 和 Handler 這些基礎(chǔ)封裝的異步庫。所以當我們看見 RxJava 這個新奇的小玩意，當我們看到異步還可以這么簡單，輕而易舉的解決 Concurrency 問題。我們當然如獲至寶。而我們現(xiàn)在選擇就更多了，無論是 Java 8 本身提供的CompletableFuture。還是后起之秀 Kotlin 上的Coroutine，還有 Android 上官方提供的LiveData(這里說下：雖然本質(zhì)上線程管理仍需用戶自己，但是常見的比如 Room 數(shù)據(jù)庫，Retrofit 等等都有現(xiàn)成的 LiveDataAdapter，實際上并不需要我們過多操心線程問題)。相比之下，RxJava 優(yōu)勢并不那么明顯，相反劣勢卻很突出。

RxJava 門檻太高

相信多數(shù) Android 開發(fā)者并沒有了解過或者說深入了解過（我自己也沒深入了解過）函數(shù)式相關(guān)的知識。但是如果不了解這些，那么而幾乎可以說不可能融會貫通 RxJava 的一些概念。舉個例子，一個很著名的 Googler：Yigit Boyar。也就是每次 IO 的那個大胡子，他的代表作有很多。比如 RecyclerView，再比如 Architecture Component。這樣一個 Android 界名人，水平怎么也有平均以上。但是他在實現(xiàn) LiveData 和 RxJava 適配的時候，同樣出現(xiàn)了由于理解上出的問題，造成錯誤的實現(xiàn)方式。RxJava 的門檻過于高，就連我自己推廣這么久，自己也不敢說對 RxJava 了解有多深刻。經(jīng)常在常見操作符的使用中出現(xiàn)了或多或少的 unexpected behavior。再者，無論國內(nèi)國外的 RxJava 教程水平都參差不齊。新手很難鑒別哪些人說的是對的哪些人說的是錯誤的。在這樣魚龍混雜的條件下學(xué)好這個高門檻的異步庫更是變得難上加難。很多教程在自己沒有精通的情況下，很容易誤導(dǎo)其他人（包括我自己的文章）。

投入高，收獲少

雖然這點存疑，因為我自己鉆研 RxJava 之后確實覺得收獲很大，尤其是經(jīng)由 RxJava 窺探了函數(shù)式的大門。但是功利的看，RxJava 在解決異步處理這個問題上，的確是投入高，收獲少。異步問題是 Android 開發(fā)必不可少的一個環(huán)節(jié)，可以說掌握異步應(yīng)該是成為入門 Android 開發(fā)的敲門磚。而 RxJava 歸根到底是通過響應(yīng)式的方式配合 Monad 來解決異步問題。但是僅僅為了解決異步問題，學(xué)習(xí)并精通 RxJava 并不是必不可少的。相反，精通 RxJava 需要大量時間和精力，在現(xiàn)在異步編程逐步完善的情況下，完全沒有必要。

你永遠無法預(yù)測你同事的 RxJava 水平

上面幾點可能有點抽象，而這點和接下來的幾點都是我在實際工作中遇到的實際情況。首先就是你并不能預(yù)測或者要求你的同事 RxJava 到達什么樣的水平。我之前的公司使用了一個簡單的類 redux 框架。其中 RxJava 是核心部分，他承載了中間 render 層和 view 層的連接。具體關(guān)于這個架構(gòu)可以看我這里的項目實例：Twivy^[2]。在 Review 同事的代碼之后，我才發(fā)現(xiàn) RxJava 還能這么玩？各種奇思妙想的作用讓我不得不佩服法國同事的豐富想象力。而這些錯誤使用就像一顆顆定時炸彈一樣埋在代碼里。隨時可能爆炸。但是反過來一想，并不是所有人都像我一樣喜歡研究 RxJava。他們可能僅僅是因為使用了這個架構(gòu)而接觸 Rx。而 RxJava 的掌握并不是一個 Android 開發(fā)的必要條件。他完全可以一點 RxJava 也不會也成為一個優(yōu)秀的 Android Developer。

RxJava 的行為并不可預(yù)期

RxJava 還有一大毛病就是光看方法名你很難知道他的真正意思。在初學(xué) RxJava 時候，兩個一直糾纏不清的問題就是map和flatMap的區(qū)別。還有flatMap和concatMap的區(qū)別。簡單的講map是一對一，flatMap是一對 N 的 map 然后在進行flatten操作。還有些教程直接寫出flatMap無序，concatMap有序。其實這些都只是簡單總結(jié)，而實際的行為照著相差甚遠。比如flatMap在第一個 error 的時候會不會繼續(xù)繼續(xù)觸發(fā)第二個？如果我想繼續(xù)，將如何操作？再比如concatMap在遇到第一個Observable不會中斷的時候，怎么繼續(xù)下一個？這些都幾乎是要看源碼或者做多次實驗對比才能得出結(jié)論的問題，而實際工作中并不想去因為這個工具而去浪費太多時間，得不償失。但是如果不做，就像前文提到的定時炸彈一樣。上線直接增加錯誤幾率。

RxJava 太容易出錯

Uncle Ben 說過：

with great power comes great responsibility. RxJava 就是這樣。在簡單易用的同時他太容易被濫用了。我在實際工作中碰到的例子：

val?stationId?=?"5bCP6Iqx"
val?statoin:Observable?=?staionRepo.getStationById(stationId)
val?stationLine:Observable?=?station.flatMap{station?->stationRepo.getLine(station)}

return?Observable.merge(station.map{it.toUiModel()},stationLine.map{it.toUiModel()})
復(fù)制代碼

乍一看，這幾行代碼并沒有錯。這個 Bug 還是后臺反饋給我的說為什么 android 每次都會發(fā)兩個一模一樣的請求？其實問題就出在 stationLine 和 station 并沒有共享結(jié)果。造成了每次請求都要發(fā)兩次。修改后的代碼：

val?stationId?=?"5bCP6bif"
val?statoin:Observable?=?staionRepo.getStationById(stationId)

return?station.publish{selector?->
????Observable.merge(selector.map{it.toUiModel()},
????????????selector.flatMap{station?->?stationRepo.getLine(station)}
????????????????????.map{it.toUiModel()})
}

RxJava 還是過于理想化了

RxJava 承諾出一個完美的異步世界，一切異步操作由上游控制，下游只需要思考如何處理，并不關(guān)心數(shù)據(jù)來源。而實際過程中，這個過程還是過于理想化了。最直接的例子就是 BackPressure 的出現(xiàn)。在數(shù)據(jù)量足夠龐大時，緩存池并不能及時緩存所有生產(chǎn)的數(shù)據(jù)，造成越積越多最終 OOM。也即是所謂的 BackPressure。再者，函數(shù)式中的 Monad 來包裹異步這個操作還是過于復(fù)雜了，看過 RxJava 的朋友都應(yīng)該清楚。某些很簡單的操作符在實現(xiàn)起來其實非常復(fù)雜。追蹤數(shù)據(jù)十分困難，很容易掉入很難 Debug 的情況。而且雖然 RxJava 的文檔是我見過少有寫的非常出色的庫，但是很多操作符如果不讀通源碼，僅僅從 Java Doc 和 Method Signature 來觀察，并不清楚期待的行為是什么。就算知道，在一些特殊情況如何處理，仍是一個未知結(jié)果。同時 RxJava 雖然解放了上游控制權(quán)力的，也引入了不安全性。如果上游出現(xiàn)了非預(yù)想的問題，下游將很難處理。其次，RxJava 為了這個理想化的世界，引入了太多的 overhead。無論是每個操作符都要生成一個新的 Observable 實例還是蹦床模式的異步解決方案。都生成了太多的 Object 在堆中存放。這種 overhead 在輕量級應(yīng)用，或者一些小型異步處理比如數(shù)據(jù)埋點等等行為中，都顯得過于龐大。

RxJava 起于異步，卻也不單單是異步

Rx 在被 Erik Meijer 提出的時候，確實是由同步的 Iterable 推導(dǎo)，由主動拉取數(shù)據(jù)改為被動接受數(shù)據(jù)。但是在加入函數(shù)是 Monad 的概念之后,RxJava 作為響應(yīng)式數(shù)據(jù)流，應(yīng)用在了更多 Callback base 的場景中。在 Android 這種 GUI 平臺下尤為出色。多數(shù)基于 Redux 結(jié)構(gòu)的 Android 架構(gòu)都或多或少基于 RxJava。或者借鑒 RxJava 的思想。比如 Airbnb 推出的 MvRx^[3]。還有 Google 在 18 年 io 中當作 Sample App 做出的 Sunflower，大量使用LiveData。而LiveData無疑也是大量借鑒了 RxJava 的思想。

總結(jié)：RxJava 雖然優(yōu)秀，但并不適合所有人

即使 RxJava 有且不僅限于我說的上述幾個問題，但無疑 RxJava 仍是一個劃時代的優(yōu)秀的異步框架。但是優(yōu)秀并不代表適合所有人，我在之前推廣 RxJava，認為這樣的異步基礎(chǔ)應(yīng)該是每一個 Android 開發(fā)者必不可少的知識點。但實際工作使用兩年之后，我覺得這并不實際，也不必要。RxJava 的水平并不能映射一個 Android Dev 的開發(fā)水平，反之，一個高水平的 Android Dev 也并不一定對 RxJava 了解多少。在這樣的前提下，再加上入門門檻高，易出錯，行為不好預(yù)期等等缺點下。在團隊沒有 RxJava Expert 的情況下我更傾向于直接棄用 RxJava，轉(zhuǎn)為更容易使用的異步框架和響應(yīng)式數(shù)據(jù)流。我在入職新公司的的時候，郵件里寫了這樣一句：

engineering is about trade off

RxJava 便是這樣一個庫，甲之蜜糖，乙之砒霜。用的好 RxJava，他是一個利器，根本離不開。用不好，他就是你身邊的定時炸彈，隨時爆炸卻又很難拆解。

參考資料