本人兩年前第一次接觸 RxJava，和大多數(shù)初學(xué)者一樣韩脏，看的第一篇 RxJava 入門文章是扔物線寫的《給 Android 開發(fā)者的 RxJava 詳解》缩麸，這篇文章流傳之廣，相信幾乎所有學(xué)習(xí) RxJava 的開發(fā)者都閱讀過赡矢。盡管那篇文章定位讀者是 RxJava 入門的初學(xué)者杭朱，但是閱讀完之后還是覺得懵懵懂懂，總感覺依然不是很理解這個框架設(shè)計理念以及優(yōu)勢吹散。

隨后工作中有機會使用 RxJava 重構(gòu)了項目的網(wǎng)絡(luò)請求以及緩存層弧械，期間陸陸續(xù)續(xù)又重構(gòu)了數(shù)據(jù)訪問層，以及項目中其他的一些功能模塊空民，無一例外刃唐，我們都選擇使用了 RxJava 。

最近翻看一些技術(shù)文章界轩，發(fā)現(xiàn)涉及 RxJava 的文章還是大多以入門為主画饥，我嘗試從一個初學(xué)者的角度閱讀，發(fā)現(xiàn)很多文章都沒講到關(guān)鍵的概念點浊猾，舉的例子也不夠恰當(dāng)抖甘。回想起兩年前剛剛學(xué)習(xí) RxJava 的自己葫慎，雖然看了許多 RxJava 入門的文章衔彻，但是始終無法理解 RxJava 究竟好在哪里，所以一定是哪里出問題了偷办。于是有了這一篇反思艰额，希望能和你一起重新思考 RxJava，以及重新思考 RxJava 是否真的讓我們的開發(fā)變得更輕松爽篷。

觀察者模式有那么神奇嗎?

幾乎所有 RxJava 入門介紹悴晰，都會用一定的篇幅去介紹 “觀察者模式”，告訴你觀察者模式是 RxJava 的核心逐工，是基石:

observable.subscribe(new Observer<String>() {
    @Override
    public void onNext(String s) {
        Log.d(tag, "Item: " + s);
    }

    @Override
    public void onCompleted() {
        Log.d(tag, "Completed!");
    }

    @Override
    public void onError(Throwable e) {
        Log.d(tag, "Error!");
    }
})

年少的我不明覺厲：“好厲害铡溪，原來這是觀察者模式”，但是心里還是感覺有點不對勁：“這代碼是不是有點丑泪喊？接收到數(shù)據(jù)的回調(diào)名字居然叫 onNext ? ”

但是其實觀察者并不是什么新鮮的概念棕硫，即使你是新手，你肯定也已經(jīng)寫過不少觀察者模式的代碼了袒啼，你能看懂下面一行代碼說明你已經(jīng)對觀察者模式了然于胸了：

button.setOnClickListener(v -> doSomething());

這就是觀察者模式哈扮，OnClickListener 訂閱了 button 的點擊事件纬纪，就這么簡單。原生的寫法對比上面 RxJava 那一長串的寫法滑肉，是不是要簡單多了包各。有人可能會說，RxJava 也可以寫成一行表示：

RxView.clicks(button).subscribe(v -> doSomething());

先不說這么寫需要引入 RxBinding 這個第三方庫靶庙，不考慮這點问畅，這兩種寫法最多也只是打個平手，完全體現(xiàn)不出 RxJava 有任何優(yōu)勢六荒。

這就是我要說的第一個論點护姆，如果僅僅只是為了使用 RxJava 的觀察者模式，而把原先 Callback 的形式掏击，改為 RxJava 的 Observable 訂閱模式是沒有價值的卵皂，你只是把一種觀察者模式改寫成了另一種觀察者模式。我是實用主義者砚亭，使用 RxJava 不是為了炫技灯变，所以觀察者模式是我們使用 RxJava 的理由嗎？當(dāng)然不是捅膘。

鏈?zhǔn)骄幊毯軈柡?

鏈?zhǔn)骄幊桃彩敲看翁岬?RxJava 的時候總會出現(xiàn)的一個高頻詞匯柒凉，很多人形容鏈?zhǔn)骄幊淌?RxJava 解決異步任務(wù)的 “殺手锏”：

Observable.from(folders)
    .flatMap((Func1) (folder) -> { Observable.from(file.listFiles()) })
    .filter((Func1) (file) -> { file.getName().endsWith(".png") })
    .map((Func1) (file) -> { getBitmapFromFile(file) })
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe((Action1) (bitmap) -> { imageCollectorView.addImage(bitmap) });

這段代碼出現(xiàn)的頻率非常的高，好像是 RxJava 的鏈?zhǔn)骄幊探o我們帶來的好處的最佳佐證篓跛。然而平心而論膝捞，我看到這個例子的時候，內(nèi)心是平靜的愧沟，并沒有像大多數(shù)文章寫得那樣蔬咬，內(nèi)心產(chǎn)生“它很長，但是很清晰”的心理活動沐寺。

首先林艘，flatMap, filter, map 這幾個操作符，對于沒有函數(shù)式編程經(jīng)驗的初學(xué)者來講混坞，并不好理解狐援。其次，雖然這段代碼用了很多 RxJava 的操作符究孕，但是其邏輯本質(zhì)并不復(fù)雜啥酱，就是在后臺線程把某個文件夾里面的以 png 結(jié)尾的圖片文件解析出來，交給 UI 線程進(jìn)行渲染厨诸。

上面這段代碼镶殷，還帶有一個反例，使用 new Thread() 的方式實現(xiàn)的版本：

new Thread() {
    @Override
    public void run() {
        super.run();
        for (File folder : folders) {
            File[] files = folder.listFiles();
            for (File file : files) {
                if (file.getName().endsWith(".png")) {
                    final Bitmap bitmap = getBitmapFromFile(file);
                    getActivity().runOnUiThread(new Runnable() {
                        @Override
                        public void run() {
                            imageCollectorView.addImage(bitmap);
                        }
                    });
                }
            }
        }
    }
}.start();

對比兩種寫法微酬，可以發(fā)現(xiàn)绘趋，之所以 RxJava 版本的縮進(jìn)減少了颤陶，是因為它利用了函數(shù)式的操作符，把原本嵌套的 for 循環(huán)邏輯展平到了同一層次陷遮，事實上滓走，我們也可以把上面那個反例的嵌套邏輯展平，既然要用 lambda 表達(dá)式帽馋，那肯定要大家都用才比較公平吧：

new Thread(() -> {
    File[] pngFiles = new File[]{};
    for (File folder : folders) {
        pngFiles = ArrayUtils.addAll(pngFiles, folder.listFiles());
    }
    for (File file : pngFiles) {
        if (file.getName().endsWith(".png")) {
            final Bitmap bitmap = getBitmapFromFile(file);
            getActivity().runOnUiThread(() -> imageCollectorView.addImage(bitmap));
        }
    }
}).start();

坦率地講闲坎，這段代碼除了 new Thread().start() 有槽點以外，沒什么大毛病茬斧。RxJava 版本確實代碼更少，同時省去了一個中間變量 pngFiles梗逮，這得益于函數(shù)式編程的 API项秉，但是實際開發(fā)中，這兩種寫法無論從性能還是項目可維護性上來看慷彤，并沒有太大的差距娄蔼，甚至，如果團隊并不熟悉函數(shù)式編程底哗，后一種寫法反而更容易被大家接受岁诉。

回到剛才說的“鏈?zhǔn)骄幊獭保琑xJava 把目前 Android Sdk 24 以上才支持的 Java 8 Stream 函數(shù)式編程風(fēng)格帶到了帶到了低版本 Android 系統(tǒng)上跋选，確實帶給我們一些方便涕癣，但是僅此而已嗎？到目前為止我并沒有看到 RxJava 在處理事件尤其是異步事件上有什么特別的手段前标。

準(zhǔn)確的來說坠韩，我的關(guān)注點并不在大多數(shù)文章鼓吹的“鏈?zhǔn)骄幊獭边@一點上，把多個依次執(zhí)行的異步操作的調(diào)用轉(zhuǎn)化為類似同步代碼調(diào)用那樣的自上而下執(zhí)行炼列，并不是什么新鮮事只搁，而且就這個具體的例子，使用 Android 原生的 AsyncTask 或者 Handler 就可以滿足需求俭尖，RxJava 相比原生的寫法無法體現(xiàn)它的優(yōu)勢氢惋。

除此以外，對于處理異步任務(wù)稽犁，還有 Promise 這個流派焰望，使用類似這樣的 API:

promise
    .then(r1 -> task1(r1))
    .then(r2 -> task2(r2))
    .then(r3 -> task3(r3))
    ...

難道不是比 RxJava 更加簡潔直觀嗎？而且還不需要引入函數(shù)式編程的內(nèi)容已亥。這種寫法柿估，跟所謂的“邏輯簡潔”也根本沒什么關(guān)系，所以從目前看來陷猫，RxJava 在我心目只是個 “哦秫舌，還挺不錯” 的框架的妖，但是并沒有驚艷到我。

以上是我要說的第二個論點足陨，鏈?zhǔn)骄幊痰男问街皇且环N語法糖嫂粟，通過函數(shù)式的操作符可以把嵌套邏輯展平，通過別的方法也可以把嵌套邏輯展平墨缘，這只是普通操作星虹，也有其他框架可以做到相似效果。

RxJava 等于異步加簡潔嗎?

相信閱讀過本文開頭介紹的那篇 RxJava 入門文 《給 Android 開發(fā)者的 RxJava 詳解》 的開發(fā)者一定對文中兩個小標(biāo)題印象深刻：

RxJava 到底是什么镊讼？ —— 一個詞：異步

RxJava 好在哪宽涌？ —— 一個詞：簡潔

首先感謝扔物線，很用心地為初學(xué)者準(zhǔn)備了這篇簡潔樸實的入門文蝶棋。但是我還是想要指出卸亮，這樣的表達(dá)是不夠嚴(yán)謹(jǐn)?shù)?/strong>。

Observable.just(1,2,3).subscribe(System.out::println);

btn.setOnClickListener(new OnClickListener() {
    @Override
    public void onClick(View v) {
        // callback body
    }
});

private ServiceConnection mConnection = new ServiceConnection() {
    @Override
    public void onServiceConnected(ComponentName className, IBinder service) {
        // callback body
    }
    @Override
    public void onServiceDisconnected(ComponentName arg0) {
        // callback body
    }
};

...
bindService(intent, mConnection, Context.BIND_AUTO_CREATE);

Call<List<Photo>> call = service.getAllPhotos();
call.enqueue(new Callback<List<Photo>>() {
    @Override
    public void onResponse(Call<List<Photo>> call, Response<List<Photo>> response) {
        // callback body
    }
    @Override
    public void onFailure(Call<List<Photo>> call, Throwable t) {
        // callback body
    }
});

public class Callback<T> {
    public void onResult(T result);
}