这篇软文承接前一篇：项目框架（一）MVP。在开发中使用Retrofit+Rxjava进行网络请求，我们使用网络请求必须要对他们进行管理，比如页面退出销毁了请求还在继续，万一他拿到数据回头更新View岂不是要Crash了，还有其他等等原因。

目录导读：

1、分析；

2、实现；

3、使用。

---

分析

在Rx2使用中，被观察者和观察者产生订阅后会有一个叫Disposable的东东，字面意思可丢弃的，我们就要用到它进行网络的控制。

Disposable 的两个方法

然而在实际使用中，我们会有很多请求，也就是说会有很多的Disposable，难道我们要每个Disposable都存储一个变量手动进行控制么，额，这玩意想想就要吐血。别急，Rx2提供了同意管理Disposable的容器DisposableContainer，我们发现他有两个实现子类：

DisposableContainer 接口注释 DisposableContainer 实现的子类

然后发现CompositeDisposable符合我们的使用需求（当然，另外一个也是可以的，如果你喜欢可以试试）：

CompositeDisposable 注释

分析：

我们找到了可供统一管理的容器，那么我们该怎么进行管理呢，我们简单分析一下：在请求（订阅）的时候，将产生的Disposable加入到这个CompositeDisposable里，然后在完成或错误的时候再从CompositeDisposable清除掉（因为这时候已经不再需要了）；我们网络请求一般用在Presenter层，那我们就把这个CompositeDisposable放在Presenter里，在detach方法里将CompositeDisposable中储存的剩余的没有取消订阅的所有订阅给取消掉。

---

那么还有个问题，难道我们要在每个请求里都这么写一遍？那岂不是又要吐血......然后想到Rx里的compose操作符，我们就先来实现一下：

---

实现

我们先写一个工具类，返回给compose操作符需要的Transformer类型（Rx2将Transformer大分家为很多种，要根据自己的需求来选取合适的）（之所以会看到Disposable[]这个奇葩的局部变量，是因为内部类调用外部需要final，而一般变量不行，只能搞一个长度为1的数组来存放；测试时打印了下add和remove后的容器size，这种写法是好用的）（Class<T> streamType这个参数只是纯粹为了规范上下两个流的泛型）：

1、如果你够懒，这两个remove的操作是可以不写的，只保留一个add操作即可；

2、doOnError和doOnComplete两个方法也可以换成一个doOnDispose(Action onDispose)；

3、或者全部三个方法更换为一个方法doOnLifecycle(final Consumer<? super Disposable> onSubscribe,final Action onDispose)；

4、经过测试证明doOnSubscribe可以写多个不会冲突，按照书写顺序调用正常。

工具类方法：给compose操作符需要的Transformer类型4、

修改后的Presenter长这样，逻辑就是按照上面的分析来的，带注释貌似没什么需要特别说明的：

增加bind方法后的Presenter父类

也可以在IBasePresenter中定义方法 <T> ObservableTransformer<T,T> bind(Class<T> streamType)，然后BaseMvpPresenter的bind方法在View层也可以调用了。

---

使用

我们现在看一下封装完的这个东东怎么来使用，炒鸡简单，就只增加了一行compose：

在Presenter中使用

总结：

本篇封装是以网络请求为例子的，但是封装后的这个方法并不局限于网络请求去使用，任何Rx2的订阅都可以使用它！

Rxjava提供了非常广泛而强大的操作符，可以大大提高我们的开发效率，提高代码可读性，值得我们学习使用。

---

安卓开发交流：

有兴趣一起学习的朋友，请加Q群：76161364