給初學者的RxJava2.0教程(八)

前言

原文鏈接：http://www.jianshu.com/p/a75ecf461e02

正題

在上一節中最後我們有個例子, 當上遊一次性發送128個事件的時候是沒有任何問題的, 一旦超過128就會拋出MissingBackpressureException異常, 提示你上游發太多事件了, 下游處理不過來, 那麼怎麼去解決呢?

我們先來思考一下, 發送128個事件沒有問題是因爲FLowable內部有一個大小爲128的水缸, 超過128就會裝滿溢出來, 那既然你水缸這麼小, 那我給你換一個大水缸如何, 聽上去很有道理的樣子, 來試試:

Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; i < 1000; i++) {
                    Log.d(TAG, "emit " + i);
                    emitter.onNext(i);
                }
            }
        }, BackpressureStrategy.BUFFER).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });

這次我們直接讓上游發送了1000個事件,下游仍然不調用request去請求, 與之前不同的是, 這次我們用的策略是BackpressureStrategy.BUFFER, 這就是我們的新水缸啦, 這個水缸就比原來的水缸牛逼多了,如果說原來的水缸是95式步槍, 那這個新的水缸就好比黃金AK , 它沒有大小限制, 因此可以存放許許多多的事件.

所以這次的運行結果就是:

zlc.season.rxjava2demo D/TAG: onSubscribe
zlc.season.rxjava2demo D/TAG: emit 0
zlc.season.rxjava2demo D/TAG: emit 1
zlc.season.rxjava2demo D/TAG: emit 2
...
zlc.season.rxjava2demo D/TAG: emit 997
zlc.season.rxjava2demo D/TAG: emit 998
zlc.season.rxjava2demo D/TAG: emit 999

不知道大家有沒有發現, 換了水缸的FLowable和Observable好像是一樣的嘛...

不錯, 這時的FLowable表現出來的特性的確和Observable一模一樣, 因此, 如果你像這樣單純的使用FLowable, 同樣需要注意OOM的問題, 例如下面這個例子:

Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                }
            }
        }, BackpressureStrategy.BUFFER).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });

按照我們以前學習Observable一樣, 讓上游無限循環發送事件, 下游一個也不去處理, 來看看運行結果吧:

flowable.gif

同樣可以看到, 內存迅速增長, 直到最後拋出OOM. 所以說不要迷戀FLowable, 它只是個傳說.

可能有朋友也注意到了, 之前使用Observable測試的時候內存增長非常迅速, 幾秒鐘就OOM, 但這裏增長速度卻比較緩慢, 可以翻回去看之前的文章中的GIF圖進行對比, 這也看出FLowable相比Observable, 在性能方面有些不足, 畢竟FLowable內部爲了實現響應式拉取做了更多的操作, 性能有所丟失也是在所難免, 因此單單只是說因爲FLowable是新興產物就盲目的使用也是不對的, 也要具體分場景,

那除了給FLowable換一個大水缸還有沒有其他的辦法呢, 因爲更大的水缸也只是緩兵之計啊, 動不動就OOM給你看.

想想看我們之前學習Observable的時候說到的如何解決上游發送事件太快的, 有一招叫從數量上取勝, 同樣的FLowable中也有這種方法, 對應的就是BackpressureStrategy.DROP和BackpressureStrategy.LATEST這兩種策略.

從名字上就能猜到它倆是幹啥的, Drop就是直接把存不下的事件丟棄,Latest就是隻保留最新的事件, 來看看它們的實際效果吧.

先來看看Drop:

public static void request() {
        mSubscription.request(128);
    }

public static void demo3() {
        Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                }
            }
        }, BackpressureStrategy.DROP).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

我們仍然讓上游無限循環發送事件, 這次的策略選擇了Drop, 同時把Subscription保存起來, 待會我們在外部調用request(128)時, 便可以看到運行的結果.

我們先來猜一下運行結果, 這裏爲什麼request(128)呢, 因爲之前不是已經說了嗎, FLowable內部的默認的水缸大小爲128, 因此, 它剛開始肯定會把0-127這128個事件保存起來, 然後丟棄掉其餘的事件, 當我們request(128)的時候,下游便會處理掉這128個事件, 那麼上游水缸中又會重新裝進新的128個事件, 以此類推, 來看看運行結果吧:

drop.gif

從運行結果中我們看到的確是如此, 第一次request的時候, 下游的確收到的是0-127這128個事件, 但第二次request的時候就不確定了, 因爲上游一直在發送事件. 內存佔用也很正常, drop的作用相信大家也很清楚了.

再來看看Latest吧:

public static void request() {
        mSubscription.request(128);
    }

public static void demo4() {
        Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                }
            }
        }, BackpressureStrategy.LATEST).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });
    }

同樣的, 上游無限循環發送事件, 策略選擇Latest, 同時把Subscription保存起來, 方便在外部調用request(128).來看看這次的運行結果:

latest.gif

誒, 看上去好像和Drop差不多啊, Latest也首先保存了0-127這128個事件, 等下游把這128個事件處理了之後才進行之後的處理, 光從這裏沒有看出有任何區別啊...

古人云，師者，所以傳道受業解惑也。人非生而知之者，孰能無惑？惑而不從師，其爲惑也，終不解矣．

作爲初學者的入門導師, 是不能給大家留下一點點疑惑的, 來讓我們繼續揭開這個疑問.

我們把上面兩段代碼改良一下, 先來看看DROP的改良版:

 Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; i < 10000; i++) {  //只發1w個事件
                    emitter.onNext(i);
                }
            }
        }, BackpressureStrategy.DROP).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(128);  //一開始就處理掉128個事件
                    }

                    @Override
                    public void onNext(Integer integer) {
                        Log.d(TAG, "onNext: " + integer);
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });

這段代碼和之前有兩點不同, 一是上游只發送了10000個事件, 二是下游在一開始就立馬處理掉了128個事件, 然後我們在外部再調用request(128)試試, 來看看運行結果:

drop_1.gif

這次可以看到, 一開始下游就處理掉了128個事件, 當我們再次request的時候, 只得到了第3317的事件, 後面的事件直接被拋棄了.

再來看看Latest的運行結果吧:

latest_1.gif

從運行結果中可以看到, 除去前面128個事件, 與Drop不同, Latest總是能獲取到最後最新的事件, 例如這裏我們總是能獲得最後一個事件9999.

好了, 關於FLowable的策略我們也講完了, 有些朋友要問了, 這些FLowable是我自己創建的, 所以我可以選擇策略, 那面對有些FLowable並不是我自己創建的, 該怎麼辦呢? 比如RxJava中的interval操作符, 這個操作符並不是我們自己創建的, 來看下面這個例子吧:

Flowable.interval(1, TimeUnit.MICROSECONDS)
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Long>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(Long.MAX_VALUE);
                    }

                    @Override
                    public void onNext(Long aLong) {
                        Log.d(TAG, "onNext: " + aLong);
                        try {
                            Thread.sleep(1000);  //延時1秒
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });

interval操作符發送Long型的事件, 從0開始, 每隔指定的時間就把數字加1併發送出來, 在這個例子裏, 我們讓它每隔1毫秒就發送一次事件, 在下游延時1秒去接收處理, 不用猜也知道結果是什麼:

zlc.season.rxjava2demo D/TAG: onSubscribe
zlc.season.rxjava2demo W/TAG: onError: 
                              io.reactivex.exceptions.MissingBackpressureException: Can't deliver value 128 due to lack of requests
                                  at io.reactivex.internal.operators.flowable.FlowableInterval$IntervalSubscriber.run(FlowableInterval.java:87)
                                  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)
                                  at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278)
                                  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:273)
                                  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
                                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
                                  at java.lang.Thread.run(Thread.java:761)

一運行就拋出了MissingBackpressureException異常, 提醒我們發太多了, 那麼怎麼辦呢, 這個又不是我們自己創建的FLowable啊...

別慌, 雖然不是我們自己創建的, 但是RxJava給我們提供了其他的方法:

onBackpressureBuffer()
onBackpressureDrop()
onBackpressureLatest()

熟悉嗎? 這跟我們上面學的策略是一樣的, 用法也簡單, 拿剛纔的例子現學現用:

Flowable.interval(1, TimeUnit.MICROSECONDS)
                .onBackpressureDrop()  //加上背壓策略
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Long>() {
                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;
                        s.request(Long.MAX_VALUE);
                    }

                    @Override
                    public void onNext(Long aLong) {
                        Log.d(TAG, "onNext: " + aLong);
                        try {
                            Thread.sleep(1000);
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }

                    @Override
                    public void onError(Throwable t) {
                        Log.w(TAG, "onError: ", t);
                    }

                    @Override
                    public void onComplete() {
                        Log.d(TAG, "onComplete");
                    }
                });

其餘的我就不一一列舉了.

好了, 今天的教程就到這裏吧, 這一節我們學習瞭如何使用內置的BackpressureStrategy來解決上下游事件速率不均衡的問題. 這些策略其實之前我們將Observable的時候也提到過, 其實大差不差, 只要理解了爲什麼會上游發事件太快, 下游處理太慢這一點, 你就好處理了, FLowable無非就是給你封裝好了, 確實對初學者友好一點, 但是很多初學者往往只知道How, 卻不知道Why, 最重要的其實是知道why, 而不是How.

(其餘的教程大多數到這裏就結束了, 但是, 你以爲FLowable就這麼點東西嗎, 騷年, Too young too simple, sometimes naive! 這僅僅是開始, 真正牛逼的還沒來呢. 敬請關注下一節, 下節見 ! )

Okamiy

發佈了39 篇原創文章 · 獲贊 30 · 訪問量 3萬+

私信關注

給初學者的RxJava2.0教程(八)

給初學者的RxJava2.0教程(八)

前言

正題

[轉帖]使用NMT和pmap解決JVM資源泄漏問題原創

Python實現大麥網搶票的四大關鍵技術點解析

Python 安裝庫指令大全

salesforce零基礎學習（一百三十八）零碎知識點小總結（十）

一款開源的.NET程序集反編譯、編輯和調試神器

關於接口協議，你必須要知道這些！

【2024-05-21】以茶會友

關於 RxJava 最友好的文章—— RxJava 2.0 全新來襲

關於RxJava最友好的文章（進階篇）

給初學者的RxJava2.0教程(四)

app安裝了但沒自動運行

給初學者的RxJava2.0教程(二)

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結