Outline
[TOC]
前言
上一節裡我們學習了只使用Observable如何去解決上下游流速不均衡的問題, 之所以學習這個是因為Observable還是有很多它使用的場景, 有些朋友自從聽說了Flowable之後就覺得Flowable能解決任何問題, 甚至有拋棄Observable這種想法, 這是萬萬不可的, 它們都有各自的優勢和不足.
在這一節裡我們先來學習如何使用Flowable, 它東西比較多, 也比較繁瑣, 解釋起來也比較麻煩, 但我還是儘量用通俗易懂的話來說清楚, 畢竟, 這是一個通俗易懂的教程.
正題
我們還是以兩根水管舉例子:
之前我們所的上游和下游分別是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一個, 就接收一個進行處理.
剛剛我們有說到水缸的大小為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吧☺. 電梯直達->戳這裡 )