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

出處：http://www.jianshu.com/p/e4c6d7989356

前言

在上一節中, 我們找到了上下游流速不均衡的源頭 , 在這一節裏我們將學習如何去治理它 . 可能很多看過其他人寫的文章的朋友都會覺得只有Flowable才能解決 , 所以大家對這個Flowable都抱有很大的期許 , 其實吶 , 你們畢竟圖樣圖森破 , 今天我們先拋開Flowable, 僅僅依靠我們自己的雙手和智慧 , 來看看我們如何去治理 , 通過本節的學習之後我們再來看Flowable, 你會發現它其實並沒有想象中那麼牛叉, 它只是被其他人過度神化了.

正題

我們接着來看上一節的這個例子:

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {  //無限循環發送事件
                    emitter.onNext(i);
                }
            }
        }).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<Integer>() {
                    @Override
                    public void accept(Integer integer) throws Exception {
                        Log.d(TAG, "" + integer);
                    }
                });

上一節中我們看到了它的運行結果是直接爆掉了內存, 也明白它爲什麼就爆掉了內存, 那麼我們能做些什麼, 才能不讓這種情況發生呢.

之前我們說了, 上游發送的所有事件都放到水缸裏了, 所以瞬間水缸就滿了, 那我們可以只放我們需要的事件到水缸裏呀, 只放一部分數據到水缸裏, 這樣不就不會溢出來了嗎, 因此, 我們把上面的代碼修改一下:

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                }
            }
        }).subscribeOn(Schedulers.io())
                .filter(new Predicate<Integer>() {
                    @Override
                    public boolean test(Integer integer) throws Exception {
                        return integer % 10 == 0;
                    }
                })
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<Integer>() {
                    @Override
                    public void accept(Integer integer) throws Exception {
                        Log.d(TAG, "" + integer);
                    }
                });

在這段代碼中我們增加了一個filter, 只允許能被10整除的事件通過, 再來看看運行結果:

filter.gif

可以看到, 雖然內存依然在增長, 但是增長速度相比之前, 已經減少了太多了, 至少在我錄完GIF之前還沒有爆掉內存, 大家可以試着改成能被100整除試試.

可以看到, 通過減少進入水缸的事件數量的確可以緩解上下游流速不均衡的問題, 但是力度還不夠, 我們再來看一段代碼:

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                }
            }
        }).subscribeOn(Schedulers.io())
                .sample(2, TimeUnit.SECONDS)  //sample取樣
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<Integer>() {
                    @Override
                    public void accept(Integer integer) throws Exception {
                        Log.d(TAG, "" + integer);
                    }
                });

這裏用了一個sample操作符, 簡單做個介紹, 這個操作符每隔指定的時間就從上游中取出一個事件發送給下游. 這裏我們讓它每隔2秒取一個事件給下游, 來看看這次的運行結果吧:

sample.gif

這次我們可以看到, 雖然上游仍然一直在不停的發事件, 但是我們只是每隔一定時間取一個放進水缸裏, 並沒有全部放進水缸裏, 因此這次內存僅僅只佔用了5M.

大家以後可以出去吹牛逼了: 我曾經通過技術手段去優化一個程序, 最終使得內存佔用從300多M變成不到5M. ~(≧▽≦)/~

前面這兩種方法歸根到底其實就是減少放進水缸的事件的數量, 是以數量取勝, 但是這個方法有個缺點, 就是丟失了大部分的事件.

那麼我們換一個角度來思考, 既然上游發送事件的速度太快, 那我們就適當減慢發送事件的速度, 從速度上取勝, 聽上去不錯, 我們來試試:

Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                    Thread.sleep(2000);  //每次發送完事件延時2秒
                }
            }
        }).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<Integer>() {
                    @Override
                    public void accept(Integer integer) throws Exception {
                        Log.d(TAG, "" + integer);
                    }
                });

這次我們讓上游每次發送完事件後都延時了2秒, 來看看運行結果:

sleep.gif

完美 ! 一切都是那麼完美 !

可以看到, 我們給上游加上延時了之後, 瞬間一頭髮情的公牛就變得跟只小綿羊一樣, 如此溫順, 如此平靜, 如此平穩的內存線, 美妙極了. 而且事件也沒有丟失, 上游通過適當的延時, 不但減緩了事件進入水缸的速度, 也可以讓下游有充足的時間從水缸裏取出事件來處理 , 這樣一來, 就不至於導致大量的事件涌進水缸, 也就不會OOM啦.

到目前爲止, 我們沒有依靠任何其他的工具, 就輕易解決了上下游流速不均衡的問題.

因此我們總結一下, 本節中的治理的辦法就兩種:

一是從數量上進行治理, 減少發送進水缸裏的事件
二是從速度上進行治理, 減緩事件發送進水缸的速度

大家一定沒忘記, 在上一節還有個Zip的例子, 這個例子也爆了我們的內存, 現學現用, 我們用剛學到的辦法來試試能不能懲奸除惡, 先來看看第一種辦法.

先來減少進入水缸的事件的數量:

Observable<Integer> observable1 = Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                }
            }
        }).subscribeOn(Schedulers.io()).sample(2, TimeUnit.SECONDS); //進行sample採樣

        Observable<String> observable2 = Observable.create(new ObservableOnSubscribe<String>() {
            @Override
            public void subscribe(ObservableEmitter<String> emitter) throws Exception {
                emitter.onNext("A");
            }
        }).subscribeOn(Schedulers.io());

        Observable.zip(observable1, observable2, new BiFunction<Integer, String, String>() {
            @Override
            public String apply(Integer integer, String s) throws Exception {
                return integer + s;
            }
        }).observeOn(AndroidSchedulers.mainThread()).subscribe(new Consumer<String>() {
            @Override
            public void accept(String s) throws Exception {
                Log.d(TAG, s);
            }
        }, new Consumer<Throwable>() {
            @Override
            public void accept(Throwable throwable) throws Exception {
                Log.w(TAG, throwable);
            }
        });

來試試運行結果吧:

zip_sample.gif

哈哈, 成功了吧, 再來用第二種辦法試試.

這次我們來減緩速度:

Observable<Integer> observable1 = Observable.create(new ObservableOnSubscribe<Integer>() {
            @Override
            public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; ; i++) {
                    emitter.onNext(i);
                    Thread.sleep(2000);  //發送事件之後延時2秒
                }
            }
        }).subscribeOn(Schedulers.io());

        Observable<String> observable2 = Observable.create(new ObservableOnSubscribe<String>() {
            @Override
            public void subscribe(ObservableEmitter<String> emitter) throws Exception {
                emitter.onNext("A");
            }
        }).subscribeOn(Schedulers.io());

        Observable.zip(observable1, observable2, new BiFunction<Integer, String, String>() {
            @Override
            public String apply(Integer integer, String s) throws Exception {
                return integer + s;
            }
        }).observeOn(AndroidSchedulers.mainThread()).subscribe(new Consumer<String>() {
            @Override
            public void accept(String s) throws Exception {
                Log.d(TAG, s);
            }
        }, new Consumer<Throwable>() {
            @Override
            public void accept(Throwable throwable) throws Exception {
                Log.w(TAG, throwable);
            }
        });

來看看運行結果吧:

zip_sleep.gif

果然也成功了, 這裏只打印出了下游收到的事件, 所以只有一個. 如果你對這個結果看不懂, 請自覺掉頭看前面幾篇文章.

通過本節的學習, 大家應該對如何處理上下游流速不均衡已經有了基本的認識了, 大家也可以看到, 我們並沒有使用Flowable, 所以很多時候仔細去分析問題, 找到問題的原因, 從源頭去解決纔是最根本的辦法. 後面我們講到Flowable的時候, 大家就會發現它其實沒什麼神祕的, 它用到的辦法和我們本節所講的基本上是一樣的, 只是它稍微做了點封裝.

好了, 今天的教程就到這裏吧, 下一節中我們就會來學習你們喜聞樂見的Flowable.

harrain

發佈了47 篇原創文章 · 獲贊 13 · 訪問量 11萬+

私信關注

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

前言

正題

MySQL 核心模塊揭祕 | 18 期 | 鎖在內存里長什麼樣*

使用perf工具生成火焰圖

響應式界面控件DevExtreme * 更強的數據分析和可視化功能

大齡程序員思考

HttpSecurity 是如何組裝過濾器鏈的

數說海南——近6年海南各市縣人口簡單看

長序列中Transformers的高級注意力機制總結

WebStorm 創建 Vue 項目

nuget添加readme

mac安裝並運行stf

pytest跑appium server用例

XPATH定位

關於cocoapods的安裝和使用的一些問題

Jenkins驅動SeleniumGrid測試

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

linux以太網驅動總結