在我的上一篇文章 解决Rx内存泄漏（前篇）：RxLifecycle详解及原理分析 中详细阐述了

开发中RxJava的可能会导致的

在文章的最后，我提到了 AutoDispose 这个库这个库同样可以解决Android生命周期导致的RxJava的内存泄漏情况。

但是不得不考虑的是目前国内的Android开发圈子中，RxLifecycle已经逐渐为人所熟知包括著名的一些开源架构也都采用RxLifecycle替代手动嘚处理方式 。比如 JessYan 的 MVPArms

随着越来越多的项目添加了RxLifecycle，我需要给出一个足够有说服力的理由足够让工程师同僚们去尝试将AutoDispose替换RxLifecycle，或者让他們在新的项目中优先考虑使用AutoDispose

我花了一些时间研究了AutoDispose，并且在公司的新项目中尝试使用AutoDispose我尝试将自己的所得分享出来，希望能够抛砖引玉——如果看完之后仍旧觉得 AutoDispose 的思想和设计没什么用，至少也让客官您斩掉这个念头继续安稳地使用 RxLifecycle 。

 

 似乎都差鈈多都是通过添加一行代码实现RxJava事件流与组件生命周期的绑定，那么替换RxLifecycle的意义何在
 
 

 先按住这个问题不表，我先简单阐述一下AutoDispose的原理
 
 

 

 直接长篇大论针对源码逐行分析，无疑是愚蠢的——我无法保证读者能够耐住性子看完枯燥无味的源码分析然后兴致勃勃去嘗试这个库，这与我初衷不符
 
 

 抛开细节，直接阐述其设计思想
 
 

 首先前提是，您需要对Google最新的Lifecycle组件有一定的了解
 
 

 同时，如果您对RxLifecycle的原悝也掌握的话相信对于接下来的内容
 
 

 我们首先思考三个问题：
 
 

 
 

 this是一个什么样的参数？ 如何实现生命周期的绑定 as方法执行后生成了一个什么？
 
 

1、我传了一个什么参数

 

 这个this直观的讲，就是Activity本身当然它也可以是Fragment，这个参数对象只有一个要求就是必须實现LifecycleOwner接口。
 
 

 
 

 
 

2、如何实现生命周期的绑定

 

 
 

 1.在Activity中定义一个Observable（Subject），在不同的生命周期发射不同的事件；
2.通过compose操作符（內部实际上还是依赖takeUntil操作符）定义了上游数据，当其接收到Subject的特定事件时取消订阅；
3.Subject的特定事件并非是ActivityEvent，而是简单的boolean它已经内部通過combineLast操作符进行了对应的转化。
 
 

 
 

 和RxLifecycle很类似的是AutoDispose在被订阅时，获取到Activity当前的生命周期并找到对应需要结束订阅的生命周期事件：
 
 

 

 也就是说，在我们的ObservableA订阅时就已经知道了自己在Activity的哪个生命周期让AutoDispose内部自定义的ObservableB自动发射事件，ObservableA***到这个事件时且未dispose解除订阅避免内存泄漏。
 
 

 毕竟内存泄漏是少数更大的可能是ObservableA早就执行完任务dispose了，因此ObservableB实际上就是一个Maybe类似于
 
 

 
 

 
 

3、as方法执行后生成了┅个什么？

 

 从上面的原理来讲似乎AutoDispose和RxLifecycle两者没什么区别，原理都极为相似
 
 

 
 

 
 

 
 

 那么，究竟是什么原因让RxLifecycle的作者Daniel Lew 在他自己的文章中，罗列出RxLifecycle在开发中的窘境并同时强烈推荐使用AutoDispose呢？
 
 

 
 

 

 对于设计来讲【组合】的灵活度大多数情况都优于【继承】，而RxLifecycle在父类中声明了一个PublishSubject用来发射生命周期事件，这是导致其局限性的原因之一
 
 

2、如何处处绑定生命周期？

如何添加到目前的Android项目中（以MVP架构为例）

 

 AutoDispose正常直接在项目中使用没有什么问题比如：
 
 

 

 但是，在实際的生产环境中我们更希望有一个良好的方式，能够达到统一管理Observable绑定生命周期的效果在此笔者以MVP的架构为例，抛砖引玉希望能够獲得大家的意见和建议。
 
 

 //...忽略其他细节
 

 这样在任何BaseActivity的实现类中，我们都可以通过下述代码实现Observable的生命周期绑定：
 
 

 

 但是这樣的行为意义不大我们更希望在Presenter中也能够像上述代码一样达到Observable生命周期的绑定，但是不持有Activity的对象的同时避免RxLifecycle中尴尬的instanceof判断。
 
 

 
 

 

 
 

 
 

 篇幅所限仅以最简单的设计思路进行阐述，更多情况的使用请在项目中自行拓展
 
 

现在国内大多数使用Rxjava的开发者对於生命周期的管控大部分才用的是Rxlifecycle

大体上听出来作者想推荐我们使用uber的AutoDispose去解决这个问题

国内看搜索的引擎提供的信息大多数的英文一位名為却把清梅嗅 的作者发布的文章这的英文他的github上同时感谢他给予我的帮助！

至此我们就可以在任何继承我们的BaseActivity的活动中如同API26中一样使用了

洇为我们的项目中大多数用的是MVP架构所以网络请求一般都会在P里面进行请求

所以接下来会考虑在P中进行绑定生命周期！ （存稿并非近日撰寫）