97人妻碰碰视频免费上线,吃瓜网站爆料,中文天堂在线

Outline

[TOC]

前言

上一節里我們學習了只使用Observable如何去解決上下游流速不均衡的問題, 之所以學習這個是因為Observable還是有很多它使用的場景, 有些朋友自從聽說了Flowable之后就覺得Flowable能解決任何問題, 甚至有拋棄Observable這種想法, 這是萬萬不可的, 它們都有各自的優勢和不足.

在這一節里我們先來學習如何使用Flowable, 它東西比較多, 也比較繁瑣, 解釋起來也比較麻煩, 但我還是盡量用通俗易懂的話來說清楚, 畢竟, 這是一個通俗易懂的教程.

正題

我們還是以兩根水管舉例子:

prepare.png

之前我們所的上游和下游分別是Observable和Observer, 這次不一樣的是上游變成了Flowable, 下游變成了Subscriber, 但是水管之間的連接還是通過subscribe(), 我們來看看最基本的用法吧:

Flowable<Integer> upstream = Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                Log.d(TAG, "emit 1");
                emitter.onNext(1);
                Log.d(TAG, "emit 2");
                emitter.onNext(2);
                Log.d(TAG, "emit 3");
                emitter.onNext(3);
                Log.d(TAG, "emit complete");
                emitter.onComplete();
            }
        }, BackpressureStrategy.ERROR); //增加了一個參數

        Subscriber<Integer> downstream = new Subscriber<Integer>() {

            @Override
            public void onSubscribe(Subscription s) {
                Log.d(TAG, "onSubscribe");
                s.request(Long.MAX_VALUE);  //注意這句代碼
            }

            @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");
            }
        };

        upstream.subscribe(downstream);

這段代碼中,分別創建了一個上游Flowable和下游Subscriber, 上下游工作在同一個線程中, 和之前的Observable的使用方式只有一點點的區別, 先來看看運行結果吧:

D/TAG: onSubscribe   
D/TAG: emit 1        
D/TAG: onNext: 1     
D/TAG: emit 2        
D/TAG: onNext: 2     
D/TAG: emit 3        
D/TAG: onNext: 3     
D/TAG: emit complete 
D/TAG: onComplete

結果也和我們預期的是一樣的.

我們注意到這次和Observable有些不同. 首先是創建Flowable的時候增加了一個參數, 這個參數是用來選擇背壓,也就是出現上下游流速不均衡的時候應該怎么處理的辦法, 這里我們直接用BackpressureStrategy.ERROR這種方式, 這種方式會在出現上下游流速不均衡的時候直接拋出一個異常,這個異常就是著名的MissingBackpressureException. 其余的策略后面再來講解.

另外的一個區別是在下游的onSubscribe方法中傳給我們的不再是Disposable了, 而是Subscription, 它倆有什么區別呢, 首先它們都是上下游中間的一個開關, 之前我們說調用Disposable.dispose()方法可以切斷水管, 同樣的調用Subscription.cancel()也可以切斷水管, 不同的地方在于Subscription增加了一個void request(long n)方法, 這個方法有什么用呢, 在上面的代碼中也有這么一句代碼:

 s.request(Long.MAX_VALUE);

這句代碼有什么用呢, 不要它可以嗎? 我們來試試:

 Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                Log.d(TAG, "emit 1");
                emitter.onNext(1);
                Log.d(TAG, "emit 2");
                emitter.onNext(2);
                Log.d(TAG, "emit 3");
                emitter.onNext(3);
                Log.d(TAG, "emit complete");
                emitter.onComplete();
            }
        }, BackpressureStrategy.ERROR).subscribe(new Subscriber<Integer>() {

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

            @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");
            }
        });

這次我們取消掉了request這句代碼, 來看看運行結果:

zlc.season.rxjava2demo D/TAG: onSubscribe
zlc.season.rxjava2demo D/TAG: emit 1
zlc.season.rxjava2demo W/TAG: onError: 
                              io.reactivex.exceptions.MissingBackpressureException: create: could not emit value due to lack of requests
                                  at io.reactivex.internal.operators.flowable.FlowableCreate$ErrorAsyncEmitter.onOverflow(FlowableCreate.java:411)
                                  at io.reactivex.internal.operators.flowable.FlowableCreate$NoOverflowBaseAsyncEmitter.onNext(FlowableCreate.java:377)
                                  at zlc.season.rxjava2demo.demo.ChapterSeven$3.subscribe(ChapterSeven.java:77)
                                  at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:72)
                                  at io.reactivex.Flowable.subscribe(Flowable.java:12218)
                                  at zlc.season.rxjava2demo.demo.ChapterSeven.demo2(ChapterSeven.java:111)
                                  at zlc.season.rxjava2demo.MainActivity$2.onClick(MainActivity.java:36)
                                  at android.view.View.performClick(View.java:5637)
                                  at android.view.View$PerformClick.run(View.java:22429)
                                  at android.os.Handler.handleCallback(Handler.java:751)
                                  at android.os.Handler.dispatchMessage(Handler.java:95)
                                  at android.os.Looper.loop(Looper.java:154)
                                  at android.app.ActivityThread.main(ActivityThread.java:6119)
                                  at java.lang.reflect.Method.invoke(Native Method)
                                  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
                                  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
zlc.season.rxjava2demo D/TAG: emit 2
zlc.season.rxjava2demo D/TAG: emit 3
zlc.season.rxjava2demo D/TAG: emit complete

哎哎哎, 大兄弟, 怎么一言不合就拋異常?

從運行結果中可以看到, 在上游發送第一個事件之后, 下游就拋出了一個著名的MissingBackpressureException異常, 并且下游沒有收到任何其余的事件. 可是這是一個同步的訂閱呀, 上下游工作在同一個線程, 上游每發送一個事件應該會等待下游處理完了才會繼續發事件啊, 不可能出現上下游流速不均衡的問題呀.

帶著這個疑問, 我們再來看看異步的情況:

Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                Log.d(TAG, "emit 1");
                emitter.onNext(1);
                Log.d(TAG, "emit 2");
                emitter.onNext(2);
                Log.d(TAG, "emit 3");
                emitter.onNext(3);
                Log.d(TAG, "emit complete");
                emitter.onComplete();
            }
        }, BackpressureStrategy.ERROR).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");
                    }
                });

這次我們同樣去掉了request這句代碼, 但是讓上下游工作在不同的線程, 來看看運行結果:

zlc.season.rxjava2demo D/TAG: onSubscribe
zlc.season.rxjava2demo D/TAG: emit 1
zlc.season.rxjava2demo D/TAG: emit 2
zlc.season.rxjava2demo D/TAG: emit 3
zlc.season.rxjava2demo D/TAG: emit complete

哎, 這次上游正確的發送了所有的事件, 但是下游一個事件也沒有收到. 這是因為什么呢?

這是因為Flowable在設計的時候采用了一種新的思路也就是響應式拉取的方式來更好的解決上下游流速不均衡的問題, 與我們之前所講的控制數量和控制速度不太一樣, 這種方式用通俗易懂的話來說就好比是葉問打鬼子, 我們把上游看成小日本, 把下游當作葉問, 當調用Subscription.request(1)時, 葉問就說我要打一個! 然后小日本就拿出一個鬼子給葉問, 讓他打, 等葉問打死這個鬼子之后, 再次調用request(10), 葉問就又說我要打十個! 然后小日本又派出十個鬼子給葉問, 然后就在邊上看熱鬧, 看葉問能不能打死十個鬼子, 等葉問打死十個鬼子后再繼續要鬼子接著打...

所以我們把request當做是一種能力, 當成下游處理事件的能力, 下游能處理幾個就告訴上游我要幾個, 這樣只要上游根據下游的處理能力來決定發送多少事件, 就不會造成一窩蜂的發出一堆事件來, 從而導致OOM. 這也就完美的解決之前我們所學到的兩種方式的缺陷, 過濾事件會導致事件丟失, 減速又可能導致性能損失. 而這種方式既解決了事件丟失的問題, 又解決了速度的問題, 完美 !

但是太完美的東西也就意味著陷阱也會很多, 你可能只是被它的外表所迷惑, 失去了理智, 如果你濫用或者不遵守規則, 一樣會吃到苦頭.

比如這里需要注意的是, 只有當上游正確的實現了如何根據下游的處理能力來發送事件的時候, 才能達到這種效果, 如果上游根本不管下游的處理能力, 一股腦的瞎他媽發事件, 仍然會產生上下游流速不均衡的問題, 這就好比小日本管他葉問要打幾個, 老子直接拿出1萬個鬼子, 這尼瑪有種打死給我看看? 那么如何正確的去實現上游呢, 這里先賣個關子, 之后我們再來講解.

學習了request, 我們就可以解釋上面的兩段代碼了.

首先第一個同步的代碼, 為什么上游發送第一個事件后下游就拋出了MissingBackpressureException異常, 這是因為下游沒有調用request, 上游就認為下游沒有處理事件的能力, 而這又是一個同步的訂閱, 既然下游處理不了, 那上游不可能一直等待吧, 如果是這樣, 萬一這兩根水管工作在主線程里, 界面不就卡死了嗎, 因此只能拋個異常來提醒我們. 那如何解決這種情況呢, 很簡單啦, 下游直接調用request(Long.MAX_VALUE)就行了, 或者根據上游發送事件的數量來request就行了, 比如這里request(3)就可以了.

然后我們再來看看第二段代碼, 為什么上下游沒有工作在同一個線程時, 上游卻正確的發送了所有的事件呢? 這是因為在Flowable里默認有一個大小為128的水缸, 當上下游工作在不同的線程中時, 上游就會先把事件發送到這個水缸中, 因此, 下游雖然沒有調用request, 但是上游在水缸中保存著這些事件, 只有當下游調用request時, 才從水缸里取出事件發給下游.

是不是這樣呢, 我們來驗證一下:

    public static void request(long n) {
        mSubscription.request(n); //在外部調用request請求上游
    }

    public static void demo3() {
        Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                Log.d(TAG, "emit 1");
                emitter.onNext(1);
                Log.d(TAG, "emit 2");
                emitter.onNext(2);
                Log.d(TAG, "emit 3");
                emitter.onNext(3);
                Log.d(TAG, "emit complete");
                emitter.onComplete();
            }
        }, BackpressureStrategy.ERROR).subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Subscriber<Integer>() {

                    @Override
                    public void onSubscribe(Subscription s) {
                        Log.d(TAG, "onSubscribe");
                        mSubscription = s;  //把Subscription保存起來
                    }

                    @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");
                    }
                });
    }

這里我們把Subscription保存起來, 在界面上增加了一個按鈕, 點擊一次就調用Subscription.request(1), 來看看運行結果:

request.gif

結果似乎像那么回事, 上游發送了四個事件保存到了水缸里, 下游每request一個, 就接收一個進行處理.

剛剛我們有說到水缸的大小為128, 有朋友就問了, 你說128就128嗎, 又不是唯品會周年慶, 我不信. 那就來驗證一下:

Flowable.create(new FlowableOnSubscribe<Integer>() {
            @Override
            public void subscribe(FlowableEmitter<Integer> emitter) throws Exception {
                for (int i = 0; i < 128; i++) {
                    Log.d(TAG, "emit " + i);
                    emitter.onNext(i);
                }
            }
        }, BackpressureStrategy.ERROR).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");
                    }
                });

這里我們讓上游一次性發送了128個事件, 下游一個也不接收, 來看看運行結果:

zlc.season.rxjava2demo D/TAG: onSubscribe
zlc.season.rxjava2demo D/TAG: emit 0
  ...
zlc.season.rxjava2demo D/TAG: emit 126
zlc.season.rxjava2demo D/TAG: emit 127

這段代碼的運行結果很正常, 沒有任何錯誤和異常, 上游僅僅是發送了128個事件.

那來試試129個呢, 把上面代碼中的128改成129試試:

zlc.season.rxjava2demo D/TAG: onSubscribe
zlc.season.rxjava2demo D/TAG: emit 0
  ...
zlc.season.rxjava2demo D/TAG: emit 126
zlc.season.rxjava2demo D/TAG: emit 127
zlc.season.rxjava2demo D/TAG: emit 128  //這是第129個事件
zlc.season.rxjava2demo W/TAG: onError: 
                              io.reactivex.exceptions.MissingBackpressureException: create: could not emit value due to lack of requests
                                  at io.reactivex.internal.operators.flowable.FlowableCreate$ErrorAsyncEmitter.onOverflow(FlowableCreate.java:411)
                                  at io.reactivex.internal.operators.flowable.FlowableCreate$NoOverflowBaseAsyncEmitter.onNext(FlowableCreate.java:377)
                                  at zlc.season.rxjava2demo.demo.ChapterSeven$7.subscribe(ChapterSeven.java:169)
                                  at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:72)
                                  at io.reactivex.Flowable.subscribe(Flowable.java:12218)
                                  at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82)
                                  at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:59)
                                  at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:51)
                                  at java.util.concurrent.FutureTask.run(FutureTask.java:237)
                                  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:272)
                                  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)

這次可以看到, 在上游發送了第129個事件的時候, 就拋出了MissingBackpressureException異常, 提醒我們發洪水啦. 當然了, 這個128也不是我憑空捏造出來的, Flowable的源碼中就有這個buffersize的大小定義, 可以自行查看.

注意這里我們是把上游發送的事件全部都存進了水缸里, 下游一個也沒有消費, 所以就溢出了, 如果下游去消費了事件, 可能就不會導致水缸溢出來了. 這里我們說的是可能不會, 這也很好理解, 比如剛才這個例子上游發了129個事件, 下游只要快速的消費了一個事件, 就不會溢出了, 但如果下游過了十秒鐘再來消費一個, 那肯定早就溢出了.

好了, 今天的教程就到這里了, 下一節我們將會更加深入的去學習FLowable, 敬請期待.

(哈哈, 給我的RxDownload打個廣告: RxDownload是一個基于RxJava的多線程+斷點續傳的下載工具, 感興趣的來GitHub點個star吧?. 電梯直達->戳這里 )

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

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

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

前言

正題

推薦閱讀更多精彩內容

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

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

前言

正題

推薦閱讀更多精彩內容

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