Outline

[TOC]

前言

在上一節中, 我們學習了FLowable的一些基本知識, 同時也挖了許多坑, 這一節就讓我們來填坑吧.

正題

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

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

Flowable.create(new FlowableOnSubscribe<Integer>() {@Overridepublic 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;}@Overridepublic void onNext(Integer integer) {Log.d(TAG, "onNext: " + integer);}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic 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>() {@Overridepublic 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;}@Overridepublic void onNext(Integer integer) {Log.d(TAG, "onNext: " + integer);}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic 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>() {@Overridepublic 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;}@Overridepublic void onNext(Integer integer) {Log.d(TAG, "onNext: " + integer);}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic 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>() {@Overridepublic 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;}@Overridepublic void onNext(Integer integer) {Log.d(TAG, "onNext: " + integer);}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic void onComplete() {Log.d(TAG, "onComplete");}});}復制代碼

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

latest.gif

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

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

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

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

Flowable.create(new FlowableOnSubscribe<Integer>() {@Overridepublic 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;s.request(128); //一開始就處理掉128個事件}@Overridepublic void onNext(Integer integer) {Log.d(TAG, "onNext: " + integer);}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;s.request(Long.MAX_VALUE);}@Overridepublic void onNext(Long aLong) {Log.d(TAG, "onNext: " + aLong);try {Thread.sleep(1000); //延時1秒} catch (InterruptedException e) {e.printStackTrace();}}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic 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 requestsat 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>() {@Overridepublic void onSubscribe(Subscription s) {Log.d(TAG, "onSubscribe");mSubscription = s;s.request(Long.MAX_VALUE);}@Overridepublic void onNext(Long aLong) {Log.d(TAG, "onNext: " + aLong);try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}}@Overridepublic void onError(Throwable t) {Log.w(TAG, "onError: ", t);}@Overridepublic void onComplete() {Log.d(TAG, "onComplete");}});復制代碼

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

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

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

總結

以上是生活随笔為你收集整理的给初学者的 RxJava2.0 教程 (八)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。