妖精漫画免费登录页面漫画 ,337p日本欧洲亚洲大胆艺术图,免费观看涩涩直播软件

Outline

[TOC]

前言

在上一節中, 我們找到了上下游流速不均衡的源頭 , 在這一節里我們將學習如何去治理它 . 可能很多看過其他人寫的文章的朋友都會覺得只有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.

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

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

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

前言

正題

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

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

前言

正題

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频