最近這一年,RxJava/RxAndroid 實在太火了。火到了什么程度???到16年之后每一個星期的Android Weekly都會至少發布兩篇以上的Rx相關的文章(沒有訂閱的同學建議可以訂閱一下,每個星期的推送都可以學到新的知識)。
RxJava之所以被大家認為是一個優秀的異步library,很大一部分原因是其簡潔的鏈式調用,還有方便的線程切換。這篇文章我打算簡單的介紹一些RxJava的use case,在哪些情況下,使用RxJava會有優勢?這篇文章的前提是假設你已經使用過RxJava,知道一些Rx的operator的前提下。如果還沒使用過/了解過的同學建議先看看
1.RxJava基礎,操作符《RxJava Essentials》
2.拋物線大牛的神作《給Android開發者的RxJava詳解》
那么,RxJava到底有什么優勢呢?在哪些情況下使用會更方便呢?我們先從一些例子入手:
1.用flatmap()解決nested callback/ callback hell
在前段調用后端的API時,經常會出現回調嵌套的情況。假設我們有兩個API,queryA 和 queryB. 并且queryB的運行依賴于queryA的結果。那么我們的程序在一般的情況下可能是這個樣子。想象有如下的代碼:
是不是感覺非常不舒服?假如嵌套的API再多幾層,那么這將是個災難。一個人開發的時候可能不覺得有什么問題,但是可以想象做code review或者新入項目組的同事看到你這復雜的嵌套時的表情。
是時候讓flatmap出現啦!讓我們把程序稍微改造一下,在Server類里面把makeRequest的方式變成RxJava的Observable的形式(我會在例子之后解釋為什么要用flatmap()):
看上去好像沒覺得有都簡潔是么?你等著我給你看看假如嵌套多幾層之后:
看到了么?在RxJava的鏈式調用下,所有之前需要嵌套的地方都被flatMap()隔開了。代碼可讀性大大增加!假如你的IDE支持java 8的話,你可以體驗更美妙的事情:lambda!?
在拋棄了可惡的匿名類之后,代碼更加簡潔了!
此時此刻,想必在看到你新重構的代碼之后,表情是這樣的:
看來很多同學都不太理解為何要用flatmap來解決嵌套回調。那咱們就深入點:
flatMap()究竟是用來干嘛的?簡單的說,flatmap把一個Observable變成多個Observable,然后把得到的多個Obervable的元素一個個的發射出去。
假設你有一個API queryA,用這個query可以通過一個userID得到一個指定用戶的所有關注的明星的userID(但是原始數據只是String),你需要把這些userID一個個打印出來。
那么我們在調用queryA的時候就已經構建了一個Obervable了,我們暫且叫他O1.在O1每發射結果的同時,我們需要調用把返回的String結果變成另一個Observable,O2,O2含有所有的明星userID,并且一個個發射出去。代碼例子:
大家可以看到,新的observable2是一個JsonObject類型的。因為在第三行注釋之后,我們返回了一個(可以是多個)新的包含所有userID的observable,RxJava會將這個(或者多個)Observable平鋪發射.
或者大家可以參考拋物線大神文章中的學生和課程的例子?大概在文章的中間?
總之flatmap最核心的功能大家可以理解為:轉換,可一個Obervable轉換成多個Observable,再講結果平鋪發射。
在我們的例子中,是一個observable(O1)變成另一個observable(O2),是一對一的關系,因為queryA只會返回一個String s的結果,所以我們只會將一個observable(O2)平鋪并發射。
所以這和nested callback有什么關系呢?
關系大了!
再想想,我們的剛剛做的和nested callback不同的地方差在哪里?唯一不通的地方是在獲取所有明星userID的時候,我們是一個同步的操作,也就是說userID全部都包含在queryA返回的結果里面。我們用同步的方法把其封裝成一個JSONArray.
假如queryA返回的只是用戶關注明星userID的url呢?假如在第二部我們需要再做一步API call呢?
是的,就算我們還需要一步API call,程序的結構還是一樣的:
還是那句話:flatmap最核心的功能大家可以理解為:轉換,可一個Obervable轉換成多個Observable,再將結果平鋪發射。
至于轉換的Observable里面的操作是同步還是異步,我們不需要去過多的思考,Rxjava已經完美的解決了。
2.使用RxJava把不同異步操作合并
假設你有十個異步任務,程序需要在這十個異步任務完成之后發送一個通知。通常的做法可能是使用java里面的countdownlatch來實現。
但是問題是,countdownlatch是沒有上下文的,也就是說,它只支持當countdown數到了的時候啟動通知,而你并不能確定是哪一些任務完成了。當任務數,種類都增多的時候,麻煩就來了。假如你有很多個不通的任務組,每組又有若干個任務,這時候管理每個組的countdownlatch就顯得非常麻煩。
而RxJava的mergeWith() 方法完美的解決了這個問題,把不同的任務merge到一起,在所有任務執行完畢并且發送完結果之后,在同一個subscriber里面發送onComplete()。我們還是使用上面的代碼,假設我們有六個query:
看到了吧!讓若干Observable互相merge,并且共享同一個subscriber,那么我們便可以在subscriber的onComplete()里面執行我們本來要使用countdownlatch發送的通知。
哈哈爽!
今天就暫時更新到這里,下周我會繼續介紹RxJava的開山始祖Netflix(現在好像已經跳槽去FB了)的Ben Christensen在GotoConference大會上介紹的在Netflix中使用RxJava的一個例子。