我從去年開始使用 RxJava 康聂，到現(xiàn)在一年多了护昧。今年加入了 Flipboard 后下愈，看到 Flipboard 的 Android 項目也在使用 RxJava 翎碑，并且使用的場景越來越多 。而最近這幾個月吠裆，我也發(fā)現(xiàn)國內越來越多的人開始提及 RxJava 按厘。有人說『RxJava 真是太好用了』抵恋，有人說『RxJava 真是太難用了』纲菌，另外更多的人表示：我真的百度了也谷歌了挠日，但我還是想問： RxJava 到底是什么？
鑒于 RxJava 目前這種既火爆又神秘的現(xiàn)狀翰舌，而我又在一年的使用過程中對 RxJava 有了一些理解嚣潜，我決定寫下這篇文章來對 RxJava 做一個相對詳細的、針對 Android 開發(fā)者的介紹椅贱。
這篇文章的目的有兩個： 1. 給對 RxJava 感興趣的人一些入門的指引 2. 給正在使用 RxJava 但仍然心存疑惑的人一些更深入的解析
參考原文地址：http://gank.io/post/560e15be2dca930e00da1083
3) compose: 對 Observable 整體的變換
在正文開始之前的最后，放上?GitHub?鏈接和引入依賴的?gradle?代碼： Github：?
https://github.com/ReactiveX/RxJava?
https://github.com/ReactiveX/RxAndroid?
引入依賴：?
compile 'io.reactivex:rxjava:1.0.14'?
compile 'io.reactivex:rxandroid:1.0.1'?
（版本號是文章發(fā)布時的最新穩(wěn)定版）
RxJava 到底是什么
一個詞：異步庇麦。
RxJava 在 GitHub 主頁上的自我介紹是 "a library for composing asynchronous and event-based programs using observable sequences for the Java VM"（一個在 Java VM 上使用可觀測的序列來組成異步的计技、基于事件的程序的庫）。這就是 RxJava 山橄，概括得非常精準垮媒。
然而，對于初學者來說，這太難看懂了涣澡。因為它是一個『總結』贱呐，而初學者更需要一個『引言』丧诺。
其實入桂， RxJava 的本質可以壓縮為異步這一個詞。說到根上驳阎，它就是一個實現(xiàn)異步操作的庫抗愁，而別的定語都是基于這之上的。
RxJava 好在哪
換句話說呵晚，『同樣是做異步蜘腌，為什么人們用它，而不用現(xiàn)成的 AsyncTask / Handler / XXX / ... 饵隙？』
一個詞：簡潔撮珠。
異步操作很關鍵的一點是程序的簡潔性，因為在調度過程比較復雜的情況下金矛，異步代碼經(jīng)常會既難寫也難被讀懂芯急。 Android 創(chuàng)造的AsyncTask?和Handler?，其實都是為了讓異步代碼更加簡潔驶俊。RxJava 的優(yōu)勢也是簡潔娶耍，但它的簡潔的與眾不同之處在于，隨著程序邏輯變得越來越復雜饼酿，它依然能夠保持簡潔榕酒。
假設有這樣一個需求：界面上有一個自定義的視圖?imageCollectorView?，它的作用是顯示多張圖片故俐，并能使用?addImage(Bitmap)?方法來任意增加顯示的圖片∠胗ィ現(xiàn)在需要程序將一個給出的目錄數(shù)組?File[] folders?中每個目錄下的 png 圖片都加載出來并顯示在imageCollectorView?中。需要注意的是药版，由于讀取圖片的這一過程較為耗時辑舷，需要放在后臺執(zhí)行，而圖片的顯示則必須在 UI 線程執(zhí)行刚陡。常用的實現(xiàn)方式有多種惩妇，我這里貼出其中一種：
而如果使用 RxJava ，實現(xiàn)方式是這樣的：
那位說話了：『你這代碼明明變多了翱鹑椤歌殃！簡潔個毛啊蝙云！』大兄弟你消消氣氓皱，我說的是邏輯的簡潔，不是單純的代碼量少（邏輯簡潔才是提升讀寫代碼速度的必殺技對不？）波材。觀察一下你會發(fā)現(xiàn)股淡， RxJava 的這個實現(xiàn)，是一條從上到下的鏈式調用廷区，沒有任何嵌套唯灵，這在邏輯的簡潔性上是具有優(yōu)勢的。當需求變得復雜時隙轻，這種優(yōu)勢將更加明顯（試想如果還要求只選取前 10 張圖片埠帕，常規(guī)方式要怎么辦？如果有更多這樣那樣的要求呢玖绿？再試想敛瓷，在這一大堆需求實現(xiàn)完兩個月之后需要改功能，當你翻回這里看到自己當初寫下的那一片迷之縮進斑匪，你能保證自己將迅速看懂呐籽，而不是對著代碼重新捋一遍思路？）蚀瘸。
另外狡蝶，如果你的 IDE 是 Android Studio ，其實每次打開某個 Java 文件的時候苍姜，你會看到被自動 Lambda 化的預覽牢酵，這將讓你更加清晰地看到程序邏輯：
如果你習慣使用 Retrolambda ，你也可以直接把代碼寫成上面這種簡潔的形式衙猪。而如果你看到這里還不知道什么是 Retrolambda 馍乙，我不建議你現(xiàn)在就去學習它。原因有兩點：1. Lambda 是把雙刃劍垫释，它讓你的代碼簡潔的同時丝格，降低了代碼的可讀性，因此同時學習 RxJava 和 Retrolambda 可能會讓你忽略 RxJava 的一些技術細節(jié)棵譬；2. Retrolambda 是 Java 6/7 對 Lambda 表達式的非官方兼容方案显蝌，它的向后兼容性和穩(wěn)定性是無法保障的，因此對于企業(yè)項目订咸，使用 Retrolambda 是有風險的曼尊。所以，與很多 RxJava 的推廣者不同脏嚷，我并不推薦在學習 RxJava 的同時一起學習 Retrolambda骆撇。事實上，我個人雖然很欣賞 Retrolambda父叙，但我從來不用它神郊。
在Flipboard 的 Android 代碼中肴裙，有一段邏輯非常復雜，包含了多次內存操作涌乳、本地文件操作和網(wǎng)絡操作蜻懦，對象分分合合，線程間相互配合相互等待夕晓，一會兒排成人字宛乃，一會兒排成一字。如果使用常規(guī)的方法來實現(xiàn)运授，肯定是要寫得欲仙欲死烤惊，然而在使用 RxJava 的情況下乔煞，依然只是一條鏈式調用就完成了吁朦。它很長，但很清晰渡贾。
所以逗宜， RxJava 好在哪？就好在簡潔空骚，好在那把什么復雜邏輯都能穿成一條線的簡潔纺讲。
API 介紹和原理簡析
這個我就做不到一個詞說明了……因為這一節(jié)的主要內容就是一步步地說明 RxJava 到底怎樣做到了異步，怎樣做到了簡潔囤屹。
1. 概念：擴展的觀察者模式
RxJava 的異步實現(xiàn)熬甚，是通過一種擴展的觀察者模式來實現(xiàn)的。
觀察者模式
先簡述一下觀察者模式肋坚，已經(jīng)熟悉的可以跳過這一段乡括。
觀察者模式面向的需求是：A 對象（觀察者）對 B 對象（被觀察者）的某種變化高度敏感，需要在 B 變化的一瞬間做出反應智厌。舉個例子诲泌，新聞里喜聞樂見的警察抓小偷，警察需要在小偷伸手作案的時候實施抓捕铣鹏。在這個例子里敷扫，警察是觀察者，小偷是被觀察者诚卸，警察需要時刻盯著小偷的一舉一動葵第，才能保證不會漏過任何瞬間。程序的觀察者模式和這種真正的『觀察』略有不同合溺，觀察者不需要時刻盯著被觀察者（例如 A 不需要每過 2ms 就檢查一次 B 的狀態(tài)）卒密，而是采用注冊(Register)或者稱為訂閱(Subscribe)的方式，告訴被觀察者：我需要你的某某狀態(tài)辫愉，你要在它變化的時候通知我栅受。 Android 開發(fā)中一個比較典型的例子是點擊監(jiān)聽器?OnClickListener?。對設置OnClickListener?來說，?View?是被觀察者屏镊，?OnClickListener?是觀察者依疼，二者通過?setOnClickListener()?方法達成訂閱關系。訂閱之后用戶點擊按鈕的瞬間而芥，Android Framework 就會將點擊事件發(fā)送給已經(jīng)注冊的?OnClickListener?律罢。采取這樣被動的觀察方式，既省去了反復檢索狀態(tài)的資源消耗棍丐，也能夠得到最高的反饋速度误辑。當然，這也得益于我們可以隨意定制自己程序中的觀察者和被觀察者歌逢，而警察叔叔明顯無法要求小偷『你在作案的時候務必通知我』巾钉。
OnClickListener 的模式大致如下圖：
如圖所示，通過?setOnClickListener()?方法秘案，Button?持有?OnClickListener?的引用（這一過程沒有在圖上畫出）砰苍；當用戶點擊時，Button?自動調用?OnClickListener?的?onClick()?方法阱高。另外赚导，如果把這張圖中的概念抽象出來（Button?-> 被觀察者、OnClickListener?-> 觀察者赤惊、setOnClickListener()?-> 訂閱吼旧，onClick()?-> 事件），就由專用的觀察者模式（例如只用于監(jiān)聽控件點擊）轉變成了通用的觀察者模式未舟。如下圖：
而 RxJava 作為一個工具庫圈暗，使用的就是通用形式的觀察者模式。
RxJava 的觀察者模式
RxJava 有四個基本概念：Observable?(可觀察者处面，即被觀察者)厂置、?Observer?(觀察者)、?subscribe?(訂閱)魂角、事件昵济。Observable?和Observer?通過?subscribe()?方法實現(xiàn)訂閱關系，從而?Observable?可以在需要的時候發(fā)出事件來通知?Observer野揪。
與傳統(tǒng)觀察者模式不同访忿， RxJava 的事件回調方法除了普通事件?onNext()?（相當于?onClick()?/?onEvent()）之外，還定義了兩個特殊的事件：onCompleted()?和?onError()斯稳。
onCompleted(): 事件隊列完結海铆。RxJava 不僅把每個事件單獨處理，還會把它們看做一個隊列挣惰。RxJava 規(guī)定卧斟，當不會再有新的onNext()?發(fā)出時殴边，需要觸發(fā)?onCompleted()?方法作為標志。
onError(): 事件隊列異常珍语。在事件處理過程中出異常時锤岸，onError()?會被觸發(fā)，同時隊列自動終止板乙，不允許再有事件發(fā)出是偷。
在一個正確運行的事件序列中,?onCompleted()?和?onError()?有且只有一個，并且是事件序列中的最后一個募逞。需要注意的是蛋铆，onCompleted()?和?onError()?二者也是互斥的，即在隊列中調用了其中一個放接，就不應該再調用另一個刺啦。
RxJava 的觀察者模式大致如下圖：
2. 基本實現(xiàn)
基于以上的概念， RxJava 的基本實現(xiàn)主要有三點：
1) 創(chuàng)建 Observer
Observer 即觀察者透乾，它決定事件觸發(fā)的時候將有怎樣的行為洪燥。 RxJava 中的?Observer?接口的實現(xiàn)方式：
除了?Observer?接口之外，RxJava 還內置了一個實現(xiàn)了?Observer?的抽象類：Subscriber乳乌。?Subscriber?對?Observer?接口進行了一些擴展，但他們的基本使用方式是完全一樣的：
不僅基本使用方式一樣市咆，實質上汉操，在 RxJava 的 subscribe 過程中，Observer?也總是會先被轉換成一個?Subscriber?再使用蒙兰。所以如果你只想使用基本功能磷瘤，選擇?Observer?和?Subscriber?是完全一樣的。它們的區(qū)別對于使用者來說主要有兩點：
onStart(): 這是?Subscriber?增加的方法搜变。它會在 subscribe 剛開始采缚，而事件還未發(fā)送之前被調用，可以用于做一些準備工作挠他，例如數(shù)據(jù)的清零或重置扳抽。這是一個可選方法，默認情況下它的實現(xiàn)為空殖侵。需要注意的是贸呢，如果對準備工作的線程有要求（例如彈出一個顯示進度的對話框，這必須在主線程執(zhí)行）拢军，?onStart()?就不適用了楞陷，因為它總是在 subscribe 所發(fā)生的線程被調用，而不能指定線程茉唉。要在指定的線程來做準備工作固蛾，可以使用?doOnSubscribe()?方法结执，具體可以在后面的文中看到。
unsubscribe(): 這是?Subscriber?所實現(xiàn)的另一個接口?Subscription?的方法艾凯，用于取消訂閱昌犹。在這個方法被調用后，Subscriber?將不再接收事件览芳。一般在這個方法調用前斜姥，可以使用?isUnsubscribed()?先判斷一下狀態(tài)。?unsubscribe()?這個方法很重要沧竟，因為在subscribe()?之后铸敏，?Observable?會持有?Subscriber?的引用，這個引用如果不能及時被釋放悟泵，將有內存泄露的風險杈笔。所以最好保持一個原則：要在不再使用的時候盡快在合適的地方（例如?onPause()?onStop()?等方法中）調用?unsubscribe()?來解除引用關系，以避免內存泄露的發(fā)生糕非。
2) 創(chuàng)建 Observable
Observable 即被觀察者蒙具，它決定什么時候觸發(fā)事件以及觸發(fā)怎樣的事件。 RxJava 使用?create()?方法來創(chuàng)建一個 Observable 朽肥，并為它定義事件觸發(fā)規(guī)則：
可以看到禁筏，這里傳入了一個?OnSubscribe?對象作為參數(shù)。OnSubscribe?會被存儲在返回的?Observable?對象中衡招，它的作用相當于一個計劃表篱昔，當?Observable?被訂閱的時候，OnSubscribe?的?call()?方法會自動被調用始腾，事件序列就會依照設定依次觸發(fā)（對于上面的代碼州刽，就是觀察者Subscriber?將會被調用三次?onNext()?和一次?onCompleted()）。這樣浪箭，由被觀察者調用了觀察者的回調方法穗椅，就實現(xiàn)了由被觀察者向觀察者的事件傳遞，即觀察者模式奶栖。
這個例子很簡單：事件的內容是字符串匹表，而不是一些復雜的對象；事件的內容是已經(jīng)定好了的驼抹，而不像有的觀察者模式一樣是待確定的（例如網(wǎng)絡請求的結果在請求返回之前是未知的）桑孩；所有事件在一瞬間被全部發(fā)送出去，而不是夾雜一些確定或不確定的時間間隔或者經(jīng)過某種觸發(fā)器來觸發(fā)的框冀×鹘罚總之，這個例子看起來毫無實用價值明也。但這是為了便于說明宣虾，實質上只要你想惯裕，各種各樣的事件發(fā)送規(guī)則你都可以自己來寫。至于具體怎么做绣硝，后面都會講到蜻势，但現(xiàn)在不行。只有把基礎原理先說明白了鹉胖，上層的運用才能更容易說清楚握玛。
create()?方法是 RxJava 最基本的創(chuàng)造事件序列的方法「Σぃ基于這個方法挠铲， RxJava 還提供了一些方法用來快捷創(chuàng)建事件隊列，例如：
just(T...): 將傳入的參數(shù)依次發(fā)送出來寂诱。
from(T[])?/?from(Iterable)?: 將傳入的數(shù)組或?Iterable?拆分成具體對象后拂苹，依次發(fā)送出來。
上面?just(T...)?的例子和?from(T[])?的例子痰洒，都和之前的?create(OnSubscribe)?的例子是等價的瓢棒。
3) Subscribe (訂閱)
創(chuàng)建了?Observable?和?Observer?之后，再用?subscribe()?方法將它們聯(lián)結起來丘喻，整條鏈子就可以工作了脯宿。代碼形式很簡單：
observable.subscribe(observer);// 或者：observable.subscribe(subscriber);
有人可能會注意到矿瘦，?subscribe()?這個方法有點怪：它看起來是『observalbe?訂閱了?observer?/?subscriber』而不是『observer?/subscriber?訂閱了?observalbe』伴找，這看起來就像『雜志訂閱了讀者』一樣顛倒了對象關系。這讓人讀起來有點別扭向族，不過如果把 API 設計成?observer.subscribe(observable)?/?subscriber.subscribe(observable)?搀继，雖然更加符合思維邏輯，但對流式 API 的設計就造成影響了翠语，比較起來明顯是得不償失的叽躯。
Observable.subscribe(Subscriber)?的內部實現(xiàn)是這樣的（僅核心代碼）：
// 注意：這不是 subscribe() 的源碼，而是將源碼中與性能肌括、兼容性点骑、擴展性有關的代碼剔除后的核心代碼。// 如果需要看源碼谍夭，可以去 RxJava 的 GitHub 倉庫下載黑滴。public Subscription subscribe(Subscriber subscriber) {? ? subscriber.onStart();? ? onSubscribe.call(subscriber);? ? return subscriber;}
可以看到，subscriber()?做了3件事：
調用?Subscriber.onStart()?紧索。這個方法在前面已經(jīng)介紹過袁辈，是一個可選的準備方法。
調用?Observable?中的?OnSubscribe.call(Subscriber)?珠漂。在這里晚缩，事件發(fā)送的邏輯開始運行尾膊。從這也可以看出，在 RxJava 中荞彼，Observable?并不是在創(chuàng)建的時候就立即開始發(fā)送事件冈敛，而是在它被訂閱的時候，即當?subscribe()?方法執(zhí)行的時候鸣皂。
將傳入的?Subscriber?作為?Subscription?返回抓谴。這是為了方便?unsubscribe().
整個過程中對象間的關系如下圖：
或者可以看動圖：
除了?subscribe(Observer)?和?subscribe(Subscriber)?，subscribe()?還支持不完整定義的回調寞缝，RxJava 會自動根據(jù)定義創(chuàng)建出Subscriber?癌压。形式如下：
簡單解釋一下這段代碼中出現(xiàn)的?Action1?和?Action0。?Action0?是 RxJava 的一個接口第租，它只有一個方法?call()措拇，這個方法是無參無返回值的；由于?onCompleted()?方法也是無參無返回值的慎宾，因此?Action0?可以被當成一個包裝對象丐吓，將?onCompleted()?的內容打包起來將自己作為一個參數(shù)傳入?subscribe()?以實現(xiàn)不完整定義的回調。這樣其實也可以看做將?onCompleted()?方法作為參數(shù)傳進了subscribe()趟据，相當于其他某些語言中的『閉包』券犁。?Action1?也是一個接口，它同樣只有一個方法?call(T param)汹碱，這個方法也無返回值粘衬，但有一個參數(shù)；與?Action0?同理咳促，由于?onNext(T obj)?和?onError(Throwable error)?也是單參數(shù)無返回值的稚新，因此?Action1?可以將?onNext(obj)?和?onError(error)?打包起來傳入?subscribe()?以實現(xiàn)不完整定義的回調。事實上跪腹，雖然?Action0?和?Action1?在 API 中使用最廣泛褂删，但 RxJava 是提供了多個?ActionX?形式的接口 (例如?Action2,?Action3) 的，它們可以被用以包裝不同的無返回值的方法冲茸。
注：正如前面所提到的屯阀，Observer?和?Subscriber?具有相同的角色，而且?Observer?在?subscribe()?過程中最終會被轉換成Subscriber?對象轴术，因此难衰，從這里開始，后面的描述我將用?Subscriber?來代替?Observer?逗栽，這樣更加嚴謹盖袭。
4) 場景示例
下面舉兩個例子：
為了把原理用更清晰的方式表述出來，本文中挑選的都是功能盡可能簡單的例子，以至于有些示例代碼看起來會有『畫蛇添足』『明明不用 RxJava 可以更簡便地解決問題』的感覺苍凛。當你看到這種情況趣席，不要覺得是因為 RxJava 太啰嗦，而是因為在過早的時候舉出真實場景的例子并不利于原理的解析醇蝴，因此我刻意挑選了簡單的情景宣肚。
a. 打印字符串數(shù)組
將字符串數(shù)組?names?中的所有字符串依次打印出來：
b. 由 id 取得圖片并顯示
由指定的一個 drawable 文件 id?drawableRes?取得圖片，并顯示在?ImageView?中悠栓，并在出現(xiàn)異常的時候打印 Toast 報錯：
正如上面兩個例子這樣霉涨，創(chuàng)建出?Observable?和?Subscriber?，再用?subscribe()?將它們串起來惭适，一次 RxJava 的基本使用就完成了笙瑟。非常簡單。
然而癞志，
在 RxJava 的默認規(guī)則中往枷，事件的發(fā)出和消費都是在同一個線程的。也就是說凄杯，如果只用上面的方法错洁，實現(xiàn)出來的只是一個同步的觀察者模式。觀察者模式本身的目的就是『后臺處理戒突，前臺回調』的異步機制屯碴，因此異步對于 RxJava 是至關重要的。而要實現(xiàn)異步膊存，則需要用到 RxJava 的另一個概念：?Scheduler?导而。
3. 線程控制 —— Scheduler (一)
在不指定線程的情況下， RxJava 遵循的是線程不變的原則隔崎，即：在哪個線程調用?subscribe()今艺，就在哪個線程生產(chǎn)事件；在哪個線程生產(chǎn)事件爵卒，就在哪個線程消費事件洼滚。如果需要切換線程，就需要用到?Scheduler?（調度器）技潘。
1) Scheduler 的 API (一)
在RxJava 中，Scheduler?——調度器千康，相當于線程控制器享幽，RxJava 通過它來指定每一段代碼應該運行在什么樣的線程。RxJava 已經(jīng)內置了幾個?Scheduler?拾弃，它們已經(jīng)適合大多數(shù)的使用場景：
Schedulers.immediate(): 直接在當前線程運行值桩，相當于不指定線程。這是默認的?Scheduler豪椿。
Schedulers.newThread(): 總是啟用新線程奔坟，并在新線程執(zhí)行操作携栋。
Schedulers.io(): I/O 操作（讀寫文件、讀寫數(shù)據(jù)庫咳秉、網(wǎng)絡信息交互等）所使用的?Scheduler婉支。行為模式和?newThread()?差不多，區(qū)別在于?io()?的內部實現(xiàn)是是用一個無數(shù)量上限的線程池澜建，可以重用空閑的線程向挖，因此多數(shù)情況下?io()?比?newThread()?更有效率。不要把計算工作放在?io()?中炕舵，可以避免創(chuàng)建不必要的線程何之。
Schedulers.computation(): 計算所使用的?Scheduler。這個計算指的是 CPU 密集型計算咽筋，即不會被 I/O 等操作限制性能的操作溶推，例如圖形的計算。這個?Scheduler?使用的固定的線程池奸攻，大小為 CPU 核數(shù)蒜危。不要把 I/O 操作放在?computation()?中，否則 I/O 操作的等待時間會浪費 CPU舞箍。
另外舰褪， Android 還有一個專用的?AndroidSchedulers.mainThread()，它指定的操作將在 Android 主線程運行疏橄。
有了這幾個?Scheduler?占拍，就可以使用?subscribeOn()?和?observeOn()?兩個方法來對線程進行控制了。 *?subscribeOn(): 指定subscribe()?所發(fā)生的線程捎迫，即?Observable.OnSubscribe?被激活時所處的線程晃酒。或者叫做事件產(chǎn)生的線程窄绒。 *?observeOn(): 指定Subscriber?所運行在的線程贝次。或者叫做事件消費的線程彰导。
文字敘述總歸難理解蛔翅，上代碼：
上面這段代碼中，由于?subscribeOn(Schedulers.io())?的指定位谋，被創(chuàng)建的事件的內容?1山析、2、3掏父、4?將會在 IO 線程發(fā)出笋轨；而由于observeOn(AndroidScheculers.mainThread()) 的指定，因此?subscriber?數(shù)字的打印將發(fā)生在主線程 。事實上爵政，這種在?subscribe()?之前寫上兩句?subscribeOn(Scheduler.io())?和?observeOn(AndroidSchedulers.mainThread())?的使用方式非常常見仅讽，它適用于多數(shù)的 『后臺線程取數(shù)據(jù)，主線程顯示』的程序策略钾挟。
而前面提到的由圖片 id 取得圖片并顯示的例子洁灵，如果也加上這兩句：
那么，加載圖片將會發(fā)生在 IO 線程等龙，而設置圖片則被設定在了主線程处渣。這就意味著，即使加載圖片耗費了幾十甚至幾百毫秒的時間蛛砰，也不會造成絲毫界面的卡頓罐栈。
2) Scheduler 的原理 (一)
RxJava 的 Scheduler API 很方便，也很神奇（加了一句話就把線程切換了泥畅，怎么做到的荠诬？而且?subscribe()?不是最外層直接調用的方法嗎，它竟然也能被指定線程位仁？）柑贞。然而 Scheduler 的原理需要放在后面講，因為它的原理是以下一節(jié)《變換》的原理作為基礎的聂抢。
好吧這一節(jié)其實我屁也沒說钧嘶，只是為了讓你安心，讓你知道我不是忘了講原理琳疏，而是把它放在了更合適的地方有决。
4. 變換
終于要到牛逼的地方了，不管你激動不激動空盼，反正我是激動了书幕。
RxJava 提供了對事件序列進行變換的支持，這是它的核心功能之一揽趾，也是大多數(shù)人說『RxJava 真是太好用了』的最大原因台汇。所謂變換，就是將事件序列中的對象或整個序列進行加工處理篱瞎，轉換成不同的事件或事件序列苟呐。概念說著總是模糊難懂的，來看 API俐筋。
1) API
首先看一個?map()?的例子：
這里出現(xiàn)了一個叫做?Func1?的類掠抬。它和?Action1?非常相似，也是 RxJava 的一個接口校哎，用于包裝含有一個參數(shù)的方法。?Func1?和?Action的區(qū)別在于，?Func1?包裝的是有返回值的方法闷哆。另外腰奋，和?ActionX?一樣，?FuncX?也有多個抱怔，用于不同參數(shù)個數(shù)的方法劣坊。FuncX?和ActionX?的區(qū)別在?FuncX?包裝的是有返回值的方法。
可以看到屈留，map()?方法將參數(shù)中的?String?對象轉換成一個?Bitmap?對象后返回局冰，而在經(jīng)過?map()?方法后，事件的參數(shù)類型也由?String轉為了?Bitmap灌危。這種直接變換對象并返回的康二，是最常見的也最容易理解的變換。不過 RxJava 的變換遠不止這樣勇蝙，它不僅可以針對事件對象沫勿，還可以針對整個事件隊列，這使得 RxJava 變得非常靈活味混。我列舉幾個常用的變換：
map(): 事件對象的直接變換产雹，具體功能上面已經(jīng)介紹過。它是 RxJava 最常用的變換翁锡。?map()?的示意圖：
flatMap(): 這是一個很有用但非常難理解的變換蔓挖，因此我決定花多些篇幅來介紹它。 首先假設這么一種需求：假設有一個數(shù)據(jù)結構『學生』馆衔，現(xiàn)在需要打印出一組學生的名字瘟判。實現(xiàn)方式很簡單：
很簡單。那么再假設：如果要打印出每個學生所需要修的所有課程的名稱呢哈踱？（需求的區(qū)別在于荒适，每個學生只有一個名字，但卻有多個課程开镣。）首先可以這樣實現(xiàn)：
依然很簡單刀诬。那么如果我不想在?Subscriber?中使用 for 循環(huán)，而是希望?Subscriber?中直接傳入單個的?Course?對象呢（這對于代碼復用很重要）邪财？用?map()?顯然是不行的陕壹，因為?map()?是一對一的轉化，而我現(xiàn)在的要求是一對多的轉化树埠。那怎么才能把一個 Student 轉化成多個 Course 呢糠馆？
這個時候，就需要用?flatMap()?了：
從上面的代碼可以看出怎憋，?flatMap()?和?map()?有一個相同點：它也是把傳入的參數(shù)轉化之后返回另一個對象又碌。但需要注意九昧，和?map()?不同的是，?flatMap()?中返回的是個?Observable?對象毕匀，并且這個?Observable?對象并不是被直接發(fā)送到了?Subscriber?的回調方法中铸鹰。flatMap()?的原理是這樣的：1. 使用傳入的事件對象創(chuàng)建一個?Observable?對象；2. 并不發(fā)送這個?Observable, 而是將它激活皂岔，于是它開始發(fā)送事件蹋笼；3. 每一個創(chuàng)建出來的?Observable?發(fā)送的事件，都被匯入同一個?Observable?躁垛，而這個?Observable?負責將這些事件統(tǒng)一交給?Subscriber?的回調方法剖毯。這三個步驟，把事件拆成了兩級教馆，通過一組新創(chuàng)建的?Observable?將初始的對象『鋪平』之后通過統(tǒng)一路徑分發(fā)了下去逊谋。而這個『鋪平』就是?flatMap()?所謂的 flat。
flatMap()?示意圖：
擴展：由于可以在嵌套的?Observable?中添加異步代碼活玲，?flatMap()?也常用于嵌套的異步操作涣狗，例如嵌套的網(wǎng)絡請求。示例代碼（Retrofit + RxJava）：
傳統(tǒng)的嵌套請求需要使用嵌套的 Callback 來實現(xiàn)舒憾。而通過?flatMap()?镀钓，可以把嵌套的請求寫在一條鏈中，從而保持程序邏輯的清晰镀迂。
throttleFirst(): 在每次事件觸發(fā)后的一定時間間隔內丟棄新的事件丁溅。常用作去抖動過濾，例如按鈕的點擊監(jiān)聽器：RxView.clickEvents(button) // RxBinding 代碼探遵，后面的文章有解釋 .throttleFirst(500, TimeUnit.MILLISECONDS) // 設置防抖間隔為 500ms .subscribe(subscriber);媽媽再也不怕我的用戶手抖點開兩個重復的界面啦窟赏。
此外， RxJava 還提供很多便捷的方法來實現(xiàn)事件序列的變換箱季，這里就不一一舉例了涯穷。
2) 變換的原理：lift()
這些變換雖然功能各有不同，但實質上都是針對事件序列的處理和再發(fā)送藏雏。而在 RxJava 的內部拷况，它們是基于同一個基礎的變換方法：lift(Operator)。首先看一下?lift()?的內部實現(xiàn)（僅核心代碼）：
這段代碼很有意思：它生成了一個新的?Observable?并返回掘殴，而且創(chuàng)建新?Observable?所用的參數(shù)?OnSubscribe?的回調方法?call()?中的實現(xiàn)竟然看起來和前面講過的?Observable.subscribe()?一樣赚瘦！然而它們并不一樣喲~不一樣的地方關鍵就在于第二行onSubscribe.call(subscriber)?中的?onSubscribe?所指代的對象不同（高能預警：接下來的幾句話可能會導致身體的嚴重不適）——
subscribe()?中這句話的?onSubscribe?指的是?Observable?中的?onSubscribe?對象，這個沒有問題奏寨，但是?lift()?之后的情況就復雜了點起意。
當含有?lift()?時：?
1.lift()?創(chuàng)建了一個?Observable?后，加上之前的原始?Observable病瞳，已經(jīng)有兩個?Observable?了揽咕；?
2.而同樣地悲酷，新?Observable?里的新?OnSubscribe?加上之前的原始?Observable?中的原始?OnSubscribe，也就有了兩個?OnSubscribe心褐；?
3.當用戶調用經(jīng)過?lift()?后的?Observable?的?subscribe()?的時候舔涎，使用的是?lift()?所返回的新的?Observable?，于是它所觸發(fā)的onSubscribe.call(subscriber)逗爹，也是用的新?Observable?中的新?OnSubscribe，即在?lift()?中生成的那個?OnSubscribe嚎于；?
4.而這個新?OnSubscribe?的?call()?方法中的?onSubscribe?掘而，就是指的原始?Observable?中的原始?OnSubscribe?，在這個?call()?方法里于购，新?OnSubscribe?利用?operator.call(subscriber)?生成了一個新的?Subscriber（Operator?就是在這里袍睡，通過自己的?call()?方法將新?Subscriber?和原始?Subscriber?進行關聯(lián)，并插入自己的『變換』代碼以實現(xiàn)變換）肋僧，然后利用這個新?Subscriber?向原始Observable?進行訂閱斑胜。?
這樣就實現(xiàn)了?lift()?過程，有點像一種代理機制嫌吠，通過事件攔截和處理實現(xiàn)事件序列的變換止潘。
精簡掉細節(jié)的話，也可以這么說：在?Observable?執(zhí)行了?lift(Operator)?方法之后辫诅，會返回一個新的?Observable凭戴，這個新的Observable?會像一個代理一樣，負責接收原始的?Observable?發(fā)出的事件炕矮，并在處理后發(fā)送給?Subscriber么夫。
如果你更喜歡具象思維，可以看圖：
或者可以看動圖：
兩次和多次的?lift()?同理肤视，如下圖：
舉一個具體的?Operator?的實現(xiàn)档痪。下面這是一個將事件中的?Integer?對象轉換成?String?的例子，僅供參考：
observable.lift(new Observable.Operator() {? ? @Override? ? public Subscriber call(final Subscriber subscriber) {? ? ? ? // 將事件序列中的 Integer 對象轉換為 String 對象? ? ? ? return new Subscriber() {? ? ? ? ? ? @Override? ? ? ? ? ? public void onNext(Integer integer) {? ? ? ? ? ? ? ? subscriber.onNext("" + integer);? ? ? ? ? ? }? ? ? ? ? ? @Override? ? ? ? ? ? public void onCompleted() {? ? ? ? ? ? ? ? subscriber.onCompleted();? ? ? ? ? ? }? ? ? ? ? ? @Override? ? ? ? ? ? public void onError(Throwable e) {? ? ? ? ? ? ? ? subscriber.onError(e);? ? ? ? ? ? }? ? ? ? };? ? }});
講述?lift()?的原理只是為了讓你更好地了解 RxJava 邢滑，從而可以更好地使用它腐螟。然而不管你是否理解了?lift()?的原理，RxJava 都不建議開發(fā)者自定義?Operator?來直接使用?lift()殊鞭，而是建議盡量使用已有的?lift()?包裝方法（如?map()?flatMap()?等）進行組合來實現(xiàn)需求遭垛，因為直接使用 lift() 非常容易發(fā)生一些難以發(fā)現(xiàn)的錯誤。
3) compose: 對 Observable 整體的變換
除了?lift()?之外操灿，?Observable?還有一個變換方法叫做?compose(Transformer)锯仪。它和?lift()?的區(qū)別在于，?lift()?是針對事件項和事件序列的趾盐，而?compose()?是針對?Observable?自身進行變換庶喜。舉個例子小腊，假設在程序中有多個?Observable?，并且他們都需要應用一組相同的?lift()?變換久窟。你可以這么寫：
observable1
? ? .lift1()? ? .lift2()? ? .lift3()? ? .lift4()? ? .subscribe(subscriber1);observable2
? ? .lift1()? ? .lift2()? ? .lift3()? ? .lift4()? ? .subscribe(subscriber2);observable3
? ? .lift1()? ? .lift2()? ? .lift3()? ? .lift4()? ? .subscribe(subscriber3);observable4
? ? .lift1()? ? .lift2()? ? .lift3()? ? .lift4()? ? .subscribe(subscriber1);
你覺得這樣太不軟件工程了秩冈，于是你改成了這樣：
private Observable liftAll(Observable observable) {? ? return observable
? ? ? ? .lift1()? ? ? ? .lift2()? ? ? ? .lift3()? ? ? ? .lift4();}...liftAll(observable1).subscribe(subscriber1);liftAll(observable2).subscribe(subscriber2);liftAll(observable3).subscribe(subscriber3);liftAll(observable4).subscribe(subscriber4);
可讀性、可維護性都提高了斥扛∪胛剩可是?Observable?被一個方法包起來，這種方式對于?Observale?的靈活性似乎還是增添了那么點限制稀颁。怎么辦芬失？這個時候，就應該用?compose()?來解決了：
public class LiftAllTransformer implements Observable.Transformer {? ? @Override? ? public Observable call(Observable observable) {? ? ? ? return observable
? ? ? ? ? ? .lift1()? ? ? ? ? ? .lift2()? ? ? ? ? ? .lift3()? ? ? ? ? ? .lift4();? ? }}...Transformer liftAll = new LiftAllTransformer();observable1.compose(liftAll).subscribe(subscriber1);observable2.compose(liftAll).subscribe(subscriber2);observable3.compose(liftAll).subscribe(subscriber3);observable4.compose(liftAll).subscribe(subscriber4);
像上面這樣匾灶，使用?compose()?方法棱烂，Observable?可以利用傳入的?Transformer?對象的?call?方法直接對自身進行處理，也就不必被包在方法的里面了阶女。
compose()?的原理比較簡單颊糜，不附圖嘍。
5. 線程控制：Scheduler (二)
除了靈活的變換秃踩，RxJava 另一個牛逼的地方衬鱼，就是線程的自由控制。
1) Scheduler 的 API (二)
前面講到了吞瞪，可以利用?subscribeOn()?結合?observeOn()?來實現(xiàn)線程控制馁启，讓事件的產(chǎn)生和消費發(fā)生在不同的線程∩指眩可是在了解了map()?flatMap()?等變換方法后惯疙，有些好事的（其實就是當初剛接觸 RxJava 時的我）就問了：能不能多切換幾次線程？
答案是：能妖啥。因為?observeOn()?指定的是?Subscriber?的線程霉颠，而這個?Subscriber?并不是（嚴格說應該為『不一定是』，但這里不妨理解為『不是』）subscribe()?參數(shù)中的?Subscriber?荆虱，而是?observeOn()?執(zhí)行時的當前?Observable?所對應的?Subscriber?蒿偎，即它的直接下級?Subscriber?。換句話說怀读，observeOn()?指定的是它之后的操作所在的線程诉位。因此如果有多次切換線程的需求，只要在每個想要切換線程的位置調用一次?observeOn()?即可菜枷。上代碼：
Observable.just(1, 2, 3, 4) // IO 線程苍糠，由 subscribeOn() 指定? ? .subscribeOn(Schedulers.io())? ? .observeOn(Schedulers.newThread())? ? .map(mapOperator) // 新線程，由 observeOn() 指定? ? .observeOn(Schedulers.io())? ? .map(mapOperator2) // IO 線程啤誊，由 observeOn() 指定? ? .observeOn(AndroidSchedulers.mainThread)
? ? .subscribe(subscriber);? // Android 主線程岳瞭，由 observeOn() 指定
如上拥娄，通過?observeOn()?的多次調用，程序實現(xiàn)了線程的多次切換瞳筏。
不過稚瘾，不同于?observeOn()?额港，?subscribeOn()?的位置放在哪里都可以线梗，但它是只能調用一次的假瞬。
又有好事的（其實還是當初的我）問了：如果我非要調用多次?subscribeOn()?呢糠悯？會有什么效果？
這個問題先放著哗伯，我們還是從 RxJava 線程控制的原理說起吧苇瓣。
2) Scheduler 的原理（二）
其實匠楚，?subscribeOn()?和?observeOn()?的內部實現(xiàn)捷沸，也是用的?lift()。具體看圖（不同顏色的箭頭表示不同的線程）：
subscribeOn()?原理圖：
observeOn()?原理圖：
從圖中可以看出狐史，subscribeOn()?和?observeOn()?都做了線程切換的工作（圖中的 "schedule..." 部位）痒给。不同的是，?subscribeOn()?的線程切換發(fā)生在?OnSubscribe?中骏全，即在它通知上一級?OnSubscribe?時苍柏，這時事件還沒有開始發(fā)送，因此?subscribeOn()?的線程控制可以從事件發(fā)出的開端就造成影響姜贡；而?observeOn()?的線程切換則發(fā)生在它內建的?Subscriber?中试吁，即發(fā)生在它即將給下一級?Subscriber?發(fā)送事件時，因此?observeOn()?控制的是它后面的線程楼咳。
最后熄捍，我用一張圖來解釋當多個?subscribeOn()?和?observeOn()?混合使用時，線程調度是怎么發(fā)生的（由于圖中對象較多母怜，相對于上面的圖對結構做了一些簡化調整）：
圖中共有 5 處含有對事件的操作余耽。由圖中可以看出，①和②兩處受第一個?subscribeOn()?影響苹熏，運行在紅色線程碟贾；③和④處受第一個observeOn()?的影響，運行在綠色線程轨域；⑤處受第二個?onserveOn()?影響袱耽，運行在紫色線程；而第二個?subscribeOn()?干发，由于在通知過程中線程就被第一個?subscribeOn()?截斷朱巨，因此對整個流程并沒有任何影響。這里也就回答了前面的問題：當使用了多個subscribeOn()?的時候铐然，只有第一個?subscribeOn()?起作用蔬崩。
3) 延伸：doOnSubscribe()
然而恶座，雖然超過一個的?subscribeOn()?對事件處理的流程沒有影響，但在流程之前卻是可以利用的沥阳。
在前面講?Subscriber?的時候跨琳，提到過?Subscriber?的?onStart()?可以用作流程開始前的初始化。然而?onStart()?由于在?subscribe()?發(fā)生時就被調用了桐罕，因此不能指定線程脉让，而是只能執(zhí)行在?subscribe()?被調用時的線程。這就導致如果?onStart()?中含有對線程有要求的代碼（例如在界面上顯示一個 ProgressBar功炮，這必須在主線程執(zhí)行）溅潜，將會有線程非法的風險，因為有時你無法預測?subscribe()?將會在什么線程執(zhí)行薪伏。
而與?Subscriber.onStart()?相對應的滚澜，有一個方法?Observable.doOnSubscribe()?。它和?Subscriber.onStart()?同樣是在?subscribe()調用后而且在事件發(fā)送前執(zhí)行嫁怀，但區(qū)別在于它可以指定線程设捐。默認情況下，?doOnSubscribe()?執(zhí)行在?subscribe()?發(fā)生的線程塘淑；而如果在?doOnSubscribe()?之后有?subscribeOn()?的話萝招，它將執(zhí)行在離它最近的?subscribeOn()?所指定的線程。
示例代碼：
Observable.create(onSubscribe)? ? .subscribeOn(Schedulers.io())? ? .doOnSubscribe(new Action0() {? ? ? ? @Override? ? ? ? public void call() {? ? ? ? ? ? progressBar.setVisibility(View.VISIBLE); // 需要在主線程執(zhí)行? ? ? ? }? ? })? ? .subscribeOn(AndroidSchedulers.mainThread()) // 指定主線程? ? .observeOn(AndroidSchedulers.mainThread())? ? .subscribe(subscriber);
如上存捺，在?doOnSubscribe()的后面跟一個?subscribeOn()?槐沼，就能指定準備工作的線程了。
RxJava 的適用場景和使用方式
1. 與 Retrofit 的結合
Retrofit 是 Square 的一個著名的網(wǎng)絡請求庫捌治。沒有用過 Retrofit 的可以選擇跳過這一小節(jié)也沒關系岗钩，我舉的每種場景都只是個例子，而且例子之間并無前后關聯(lián)具滴，只是個拋磚引玉的作用凹嘲，所以你跳過這里看別的場景也可以的。
Retrofit 除了提供了傳統(tǒng)的?Callback?形式的 API构韵，還有 RxJava 版本的?Observable?形式 API周蹭。下面我用對比的方式來介紹 Retrofit 的 RxJava 版 API 和傳統(tǒng)版本的區(qū)別。
以獲取一個?User?對象的接口作為例子疲恢。使用Retrofit 的傳統(tǒng) API凶朗，你可以用這樣的方式來定義請求：
@GET("/user")public void getUser(@Query("userId") String userId, Callback callback);
在程序的構建過程中， Retrofit 會把自動把方法實現(xiàn)并生成代碼显拳，然后開發(fā)者就可以利用下面的方法來獲取特定用戶并處理響應：
getUser(userId, new Callback() {? ? @Override? ? public void success(User user) {? ? ? ? userView.setUser(user);? ? }? ? @Override? ? public void failure(RetrofitError error) {? ? ? ? // Error handling? ? ? ? ...? ? }};
而使用 RxJava 形式的 API棚愤，定義同樣的請求是這樣的：
@GET("/user")public Observable getUser(@Query("userId") String userId);
使用的時候是這樣的：
getUser(userId)? ? .observeOn(AndroidSchedulers.mainThread())? ? .subscribe(new Observer() {? ? ? ? @Override? ? ? ? public void onNext(User user) {? ? ? ? ? ? userView.setUser(user);? ? ? ? }? ? ? ? @Override? ? ? ? public void onCompleted() {? ? ? ? }? ? ? ? @Override? ? ? ? public void onError(Throwable error) {? ? ? ? ? ? // Error handling? ? ? ? ? ? ...? ? ? ? }? ? });
看到區(qū)別了嗎？
當 RxJava 形式的時候，Retrofit 把請求封裝進?Observable?宛畦，在請求結束后調用?onNext()?或在請求失敗后調用?onError()瘸洛。
對比來看，?Callback?形式和?Observable?形式長得不太一樣次和，但本質都差不多反肋，而且在細節(jié)上?Observable?形式似乎還比?Callback?形式要差點。那 Retrofit 為什么還要提供 RxJava 的支持呢踏施？
因為它好用笆帷！從這個例子看不出來是因為這只是最簡單的情況畅形。而一旦情景復雜起來养距，?Callback?形式馬上就會開始讓人頭疼。比如：
假設這么一種情況：你的程序取到的?User?并不應該直接顯示日熬，而是需要先與數(shù)據(jù)庫中的數(shù)據(jù)進行比對和修正后再顯示棍厌。使用?Callback方式大概可以這么寫：
getUser(userId, new Callback() {? ? @Override? ? public void success(User user) {? ? ? ? processUser(user); // 嘗試修正 User 數(shù)據(jù)? ? ? ? userView.setUser(user);? ? }? ? @Override? ? public void failure(RetrofitError error) {? ? ? ? // Error handling? ? ? ? ...? ? }};
有問題嗎？
很簡便竖席，但不要這樣做定铜。為什么？因為這樣做會影響性能怕敬。數(shù)據(jù)庫的操作很重，一次讀寫操作花費 10~20ms 是很常見的帘皿，這樣的耗時很容易造成界面的卡頓东跪。所以通常情況下，如果可以的話一定要避免在主線程中處理數(shù)據(jù)庫鹰溜。所以為了提升性能虽填，這段代碼可以優(yōu)化一下：
getUser(userId, new Callback() {? ? @Override? ? public void success(User user) {? ? ? ? new Thread() {? ? ? ? ? ? @Override? ? ? ? ? ? public void run() {? ? ? ? ? ? ? ? processUser(user); // 嘗試修正 User 數(shù)據(jù)? ? ? ? ? ? ? ? runOnUiThread(new Runnable() { // 切回 UI 線程? ? ? ? ? ? ? ? ? ? @Override? ? ? ? ? ? ? ? ? ? public void run() {? ? ? ? ? ? ? ? ? ? ? ? userView.setUser(user);? ? ? ? ? ? ? ? ? ? }? ? ? ? ? ? ? ? });? ? ? ? ? ? }).start();? ? }? ? @Override? ? public void failure(RetrofitError error) {? ? ? ? // Error handling? ? ? ? ...? ? }};
性能問題解決，但……這代碼實在是太亂了曹动，迷之縮進罢铡！雜亂的代碼往往不僅僅是美觀問題墓陈，因為代碼越亂往往就越難讀懂恶守，而如果項目中充斥著雜亂的代碼，無疑會降低代碼的可讀性贡必，造成團隊開發(fā)效率的降低和出錯率的升高兔港。
這時候，如果用 RxJava 的形式仔拟，就好辦多了衫樊。 RxJava 形式的代碼是這樣的：
getUser(userId)? ? .doOnNext(new Action1() {? ? ? ? @Override? ? ? ? public void call(User user) {? ? ? ? ? ? processUser(user);? ? ? ? })? ? .observeOn(AndroidSchedulers.mainThread())? ? .subscribe(new Observer() {? ? ? ? @Override? ? ? ? public void onNext(User user) {? ? ? ? ? ? userView.setUser(user);? ? ? ? }? ? ? ? @Override? ? ? ? public void onCompleted() {? ? ? ? }? ? ? ? @Override? ? ? ? public void onError(Throwable error) {? ? ? ? ? ? // Error handling? ? ? ? ? ? ...? ? ? ? }? ? });
后臺代碼和前臺代碼全都寫在一條鏈中，明顯清晰了很多。
再舉一個例子：假設?/user?接口并不能直接訪問科侈，而需要填入一個在線獲取的?token?载佳，代碼應該怎么寫？
Callback?方式臀栈，可以使用嵌套的?Callback：
@GET("/token")public void getToken(Callback callback);@GET("/user")public void getUser(@Query("token") String token, @Query("userId") String userId, Callback callback);...getToken(new Callback() {? ? @Override? ? public void success(String token) {? ? ? ? getUser(token, userId, new Callback() {? ? ? ? ? ? @Override? ? ? ? ? ? public void success(User user) {? ? ? ? ? ? ? ? userView.setUser(user);? ? ? ? ? ? }? ? ? ? ? ? @Override? ? ? ? ? ? public void failure(RetrofitError error) {? ? ? ? ? ? ? ? // Error handling? ? ? ? ? ? ? ? ...? ? ? ? ? ? }? ? ? ? };? ? }? ? @Override? ? public void failure(RetrofitError error) {? ? ? ? // Error handling? ? ? ? ...? ? }});
倒是沒有什么性能問題蔫慧，可是迷之縮進毀一生，你懂我也懂挂脑，做過大項目的人應該更懂藕漱。
而使用 RxJava 的話，代碼是這樣的：
@GET("/token")public Observable getToken();@GET("/user")public Observable getUser(@Query("token") String token, @Query("userId") String userId);...getToken()? ? .flatMap(new Func1>() {? ? ? ? @Override? ? ? ? public Observable onNext(String token) {? ? ? ? ? ? return getUser(token, userId);? ? ? ? })? ? .observeOn(AndroidSchedulers.mainThread())? ? .subscribe(new Observer() {? ? ? ? @Override? ? ? ? public void onNext(User user) {? ? ? ? ? ? userView.setUser(user);? ? ? ? }? ? ? ? @Override? ? ? ? public void onCompleted() {? ? ? ? }? ? ? ? @Override? ? ? ? public void onError(Throwable error) {? ? ? ? ? ? // Error handling? ? ? ? ? ? ...? ? ? ? }? ? });
用一個?flatMap()?就搞定了邏輯崭闲，依然是一條鏈肋联。看著就很爽刁俭，是吧橄仍？
2016/03/31 更新，加上我寫的一個 Sample 項目：?
好牍戚，Retrofit 部分就到這里侮繁。
2. RxBinding
RxBinding?是 Jake Wharton 的一個開源庫，它提供了一套在 Android 平臺上的基于 RxJava 的 Binding API如孝。所謂 Binding宪哩，就是類似設置?OnClickListener?、設置?TextWatcher?這樣的注冊綁定對象的 API第晰。
舉個設置點擊監(jiān)聽的例子锁孟。使用?RxBinding?，可以把事件監(jiān)聽用這樣的方法來設置：
Button button = ...;RxView.clickEvents(button) // 以 Observable 形式來反饋點擊事件? ? .subscribe(new Action1() {? ? ? ? @Override? ? ? ? public void call(ViewClickEvent event) {? ? ? ? ? ? // Click handling? ? ? ? }? ? });
看起來除了形式變了沒什么區(qū)別茁瘦，實質上也是這樣品抽。甚至如果你看一下它的源碼，你會發(fā)現(xiàn)它連實現(xiàn)都沒什么驚喜：它的內部是直接用一個包裹著的?setOnClickListener()?來實現(xiàn)的甜熔。然而圆恤，僅僅這一個形式的改變，卻恰好就是?RxBinding?的目的：擴展性腔稀。通過?RxBinding把點擊監(jiān)聽轉換成?Observable?之后盆昙，就有了對它進行擴展的可能。擴展的方式有很多焊虏，根據(jù)需求而定弱左。一個例子是前面提到過的throttleFirst()?，用于去抖動炕淮，也就是消除手抖導致的快速連環(huán)點擊：
RxView.clickEvents(button)? ? .throttleFirst(500, TimeUnit.MILLISECONDS)? ? .subscribe(clickAction);
如果想對?RxBinding?有更多了解拆火，可以去它的?GitHub 項目?下面看看。
3. 各種異步操作
前面舉的?Retrofit?和?RxBinding?的例子，是兩個可以提供現(xiàn)成的?Observable?的庫们镜。而如果你有某些異步操作無法用這些庫來自動生成Observable币叹，也完全可以自己寫。例如數(shù)據(jù)庫的讀寫模狭、大圖片的載入颈抚、文件壓縮/解壓等各種需要放在后臺工作的耗時操作，都可以用 RxJava 來實現(xiàn)嚼鹉，有了之前幾章的例子贩汉，這里應該不用再舉例了。
4. RxBus
RxBus 名字看起來像一個庫锚赤，但它并不是一個庫匹舞，而是一種模式，它的思想是使用 RxJava 來實現(xiàn)了 EventBus 线脚，而讓你不再需要使用Otto?或者 GreenRobot 的?EventBus赐稽。至于什么是 RxBus，可以看這篇文章浑侥。順便說一句姊舵，F(xiàn)lipboard 已經(jīng)用 RxBus 替換掉了?Otto?，目前為止沒有不良反應寓落。
最后
對于 Android 開發(fā)者來說括丁， RxJava 是一個很難上手的庫，因為它對于 Android 開發(fā)者來說有太多陌生的概念了伶选□锝可是它真的很牛逼。因此考蕾，我寫了這篇《給 Android 開發(fā)者的 RxJava 詳解》，希望能給始終搞不明白什么是 RxJava 的人一些入門的指引会宪，或者能讓正在使用 RxJava 但仍然心存疑惑的人看到一些更深入的解析肖卧。無論如何，只要能給各位同為 Android 工程師的你們提供一些幫助掸鹅，這篇文章的目的就達到了塞帐。
