Outline
[TOC]
前言
在上一節(jié)中, 我們找到了上下游流速不均衡的源頭 , 在這一節(jié)里我們將學(xué)習(xí)如何去治理它 . 可能很多看過其他人寫的文章的朋友都會覺得只有Flowable才能解決 , 所以大家對這個Flowable都抱有很大的期許 , 其實吶 , 你們畢竟圖樣圖森破 , 今天我們先拋開Flowable, 僅僅依靠我們自己的雙手和智慧 , 來看看我們?nèi)绾稳ブ卫?, 通過本節(jié)的學(xué)習(xí)之后我們再來看Flowable, 你會發(fā)現(xiàn)它其實并沒有想象中那么牛叉, 它只是被其他人過度神化了.
正題
我們接著來看上一節(jié)的這個例子:
Observable.create(new ObservableOnSubscribe<Integer>() {
@Override
public void subscribe(ObservableEmitter<Integer> emitter) throws Exception {
for (int i = 0; ; i++) { //無限循環(huán)發(fā)送事件
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);
}
});
上一節(jié)中我們看到了它的運行結(jié)果是直接爆掉了內(nèi)存, 也明白它為什么就爆掉了內(nèi)存, 那么我們能做些什么, 才能不讓這種情況發(fā)生呢.
之前我們說了, 上游發(fā)送的所有事件都放到水缸里了, 所以瞬間水缸就滿了, 那我們可以只放我們需要的事件到水缸里呀, 只放一部分?jǐn)?shù)據(jù)到水缸里, 這樣不就不會溢出來了嗎, 因此, 我們把上面的代碼修改一下:
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整除的事件通過, 再來看看運行結(jié)果:
可以看到, 雖然內(nèi)存依然在增長, 但是增長速度相比之前, 已經(jīng)減少了太多了, 至少在我錄完GIF之前還沒有爆掉內(nèi)存, 大家可以試著改成能被100整除試試.
可以看到, 通過減少進(jìn)入水缸的事件數(shù)量的確可以緩解上下游流速不均衡的問題, 但是力度還不夠, 我們再來看一段代碼:
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操作符, 簡單做個介紹, 這個操作符每隔指定的時間就從上游中取出一個事件發(fā)送給下游. 這里我們讓它每隔2秒取一個事件給下游, 來看看這次的運行結(jié)果吧:
這次我們可以看到, 雖然上游仍然一直在不停的發(fā)事件, 但是我們只是每隔一定時間取一個放進(jìn)水缸里, 并沒有全部放進(jìn)水缸里, 因此這次內(nèi)存僅僅只占用了5M.
大家以后可以出去吹牛逼了: 我曾經(jīng)通過技術(shù)手段去優(yōu)化一個程序, 最終使得內(nèi)存占用從300多M變成不到5M. (≧▽≦)/
前面這兩種方法歸根到底其實就是減少放進(jìn)水缸的事件的數(shù)量, 是以數(shù)量取勝, 但是這個方法有個缺點, 就是丟失了大部分的事件.
那么我們換一個角度來思考, 既然上游發(fā)送事件的速度太快, 那我們就適當(dāng)減慢發(fā)送事件的速度, 從速度上取勝, 聽上去不錯, 我們來試試:
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); //每次發(fā)送完事件延時2秒
}
}
}).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Consumer<Integer>() {
@Override
public void accept(Integer integer) throws Exception {
Log.d(TAG, "" + integer);
}
});
這次我們讓上游每次發(fā)送完事件后都延時了2秒, 來看看運行結(jié)果:
完美 ! 一切都是那么完美 !
可以看到, 我們給上游加上延時了之后, 瞬間一頭發(fā)情的公牛就變得跟只小綿羊一樣, 如此溫順, 如此平靜, 如此平穩(wěn)的內(nèi)存線, 美妙極了. 而且事件也沒有丟失, 上游通過適當(dāng)?shù)?code>延時, 不但減緩了事件進(jìn)入水缸的速度, 也可以讓下游有充足的時間從水缸里取出事件來處理 , 這樣一來, 就不至于導(dǎo)致大量的事件涌進(jìn)水缸, 也就不會OOM啦.
到目前為止, 我們沒有依靠任何其他的工具, 就輕易解決了上下游流速不均衡的問題.
因此我們總結(jié)一下, 本節(jié)中的治理的辦法就兩種:
- 一是從數(shù)量上進(jìn)行治理, 減少發(fā)送進(jìn)水缸里的事件
- 二是從速度上進(jìn)行治理, 減緩事件發(fā)送進(jìn)水缸的速度
大家一定沒忘記, 在上一節(jié)還有個Zip的例子, 這個例子也爆了我們的內(nèi)存, 現(xiàn)學(xué)現(xiàn)用, 我們用剛學(xué)到的辦法來試試能不能懲奸除惡, 先來看看第一種辦法.
先來減少進(jìn)入水缸的事件的數(shù)量:
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); //進(jìn)行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);
}
});
來試試運行結(jié)果吧:
哈哈, 成功了吧, 再來用第二種辦法試試.
這次我們來減緩速度:
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); //發(fā)送事件之后延時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);
}
});
來看看運行結(jié)果吧:
果然也成功了, 這里只打印出了下游收到的事件, 所以只有一個. 如果你對這個結(jié)果看不懂, 請自覺掉頭看前面幾篇文章.
通過本節(jié)的學(xué)習(xí), 大家應(yīng)該對如何處理上下游流速不均衡已經(jīng)有了基本的認(rèn)識了, 大家也可以看到, 我們并沒有使用Flowable, 所以很多時候仔細(xì)去分析問題, 找到問題的原因, 從源頭去解決才是最根本的辦法. 后面我們講到Flowable的時候, 大家就會發(fā)現(xiàn)它其實沒什么神秘的, 它用到的辦法和我們本節(jié)所講的基本上是一樣的, 只是它稍微做了點封裝.
好了, 今天的教程就到這里吧, 下一節(jié)中我們就會來學(xué)習(xí)你們喜聞樂見的Flowable.
