AutoDispose这东西还是在上一篇查看RxLifeCycle的时候，看到博主大力推荐下，采取查阅，奈何网上能找到介绍的确实太少，官方文档说明实在有限（或者是我没仔细阅读完全）。总之，在有限的资料上勾起了对它的兴趣，加之RxLifeCycle作者的推荐。在参考博客上与自己demo使用上进行了尝试，将笔记与自己的心得归纳一下。
一、LifeCycle
二、AutoDispose的基础原理
三、为什么推荐AutoDispose 而抛弃RxLifeCycle
四、以MVP模式为例，如何比较优雅地使用它
我们通过上述几个目标进行阐述，具体的使用可以上官方文档或者网上搜索，这里只简单带过。
在引入对应库后，使用订阅代码中，在Observable对象上补充这.as(AutoDispose.autoDisposable(AndroidLifecycleScopeProvider.from(this)))，其中this是LifecycleOwner,这个后谈。
一、LifeCycle与AutoDispose的基础原理
AutoDispose的原理是基于LifeCycle，所以我们需要先了解一下LifeCycle。Lifecycle 是一个类，它持有关于组件（如 Aty 或 Frag）生命周期状态的信息，并且允许其他对象观察此状态。以MVP模式来说，当我们要在对应Presenter里获取活动对应的生命周期时机，并在对应的生命周期时机中进行操作，最通俗的做法就是：
1、需要将presenter安排好同样对应的生命周期回调方法，如OnCreater(),OnDestory()等；
2、需要在活动对应的生命周期回调，手动调用presenter对应的生命周期回调方法，如在Aty的OnCreater里手动调用presenter.onCreater();
然而这样做虽然行之有效，但是过于繁琐，随着你的活动与对应Presenter的增多，你所需的代码量随之剧增，更可怕的是维护的时候更是折磨人。为了解决这个窘境，Lifecycle就随之而生了。让我们先看看它的使用：
与此同时，在对应的活动创建/初始时期，进行绑定监听者：getLifecycle().addObserver(mPresenter);
上述就是最基本的Lifecycle的使用了，由此我们可以看出，通过他，我们不需要在对应的活动中进行手动调用，因为Lifecycle将这部分麻烦事进行了处理，有效地简化我们的代码。现在让我们看看他的重要成员：
LifecycleObserver接口（ Lifecycle观察者）：实现该接口的类，通过注解的方式，可以通过被LifecycleOwner类的addObserver(LifecycleObserver o)方法注册,被注册后，LifecycleObserver便可以观察到LifecycleOwner的生命周期事件。
LifecycleOwner接口（Lifecycle持有者）：实现该接口的类持有生命周期(Lifecycle对象)，该接口的生命周期(Lifecycle对象)的改变会被其注册的观察者LifecycleObserver观察到并触发其对应的事件。
Lifecycle(生命周期)：和LifecycleOwner不同的是，LifecycleOwner本身持有Lifecycle对象，LifecycleOwner通过其Lifecycle getLifecycle()的接口获取内部Lifecycle对象。
State(当前生命周期所处状态)：如图所示。
Event(当前生命周期改变对应的事件)：如图所示，当Lifecycle发生改变，如进入onCreate,会自动发出ON_CREATE事件。
下面我们来看看Aty里的LifeCycle使用：
可以看出，ComponentActivity（SupportActivity的祖辈）中，其实实现了LifecycleOwner接口，持有LifecycleRegistry对象， 所以对于Lifecycle整个目的来说来说，本身就是作为被观察的对象。再进入源码查看，就能知道，他们内部已经实现了对应生命回调的进行操作
更加详细的实现可以去查看具体源码，这里就不再进行挖掘了。由上述我们可以知道，在活动对应的生命周期回调方法体中，Lifecycle对象会将对应的消息进行传递。Lifecycle通过内部的机制，使得观察者（比如我们上述的Presenter）就能在适当时机得到对应活动的生命周期回调。
二、AutoDispose的基础原理
在之前的RxLifecycle说过，目前解决RxJava内存泄露问题主要有两种方案，而AutoDispose采用的基础原理与RxLifecycle都是将订阅进行统一管理，然后通过监听对应组件/活动的生命周期中时机回调，在适当的时机进行订阅的解除。而从上文我们也说了，AutoDispose的实现是基于LifeCycle的，这也是为什么AutoDispose不需要让对应活动进行指定父类继承。
从上面的使用样例我们知道，对于使用者来说，autodispose产生作用的代码主要是这句：
as(AutoDispose.autoDisposable(AndroidLifecycleScopeProvider.from(this))；
而且我们也说过了，其中的this是LifecycleOwner对象。通过上面对Lifecycle的描述，你应该对这个不陌生。其实，跟RxLifecycle类似的是，它也是在对应的生命时机进行监听后，会根据自我的规则进行最晚解除订阅时机：
其实，AutoDispose内部也是定义了第二个订阅者，先称呼为B（我们把原本的订阅者Observable称为A）。当到达Autodispose根据规则指定的生命时机，但是A还没有完成或者解除订阅，这时候B就会发出事件。AutoDispose又通过拦截事件，判断是不是告知解除订阅的事件，如果是就解除订阅，防止内存泄漏。
内部的实现我们基本原理解释清楚了，再看看，RxLifecycle使用的是compose进行Observable的转化，但是as是进行转化吗？其实也是，但是不全是，因为Observable通过compose生成的对象还是Observable，但as方法生成的则是一个新的对象。也就是说，as方法下，并不是只针对本身的转化，而是直接重新包装生成了一个新的AutoDisposeObservable对象。
三、为什么推荐 AutoDispose 而抛弃RxLifeCycle
上面我们已经把AutoDispose的基本使用与原理，比较粗略地讲了一遍，我们结合上一篇对RxLifecycle的分析，分析一下AutoDispose对比RxLifeCycle的优势。毕竟，连作者都这么推荐，必定有其原因。先看看RxLifeCycle的弊端：
1、指定活动类必须继承指定父类（RxActivity / RxFragment等）；
2、使用订阅的地方，需强制获取对应活动类的引用：
这个需要解释一下，因为使用RxLifeCycle，必须用到集成相关父类的活动类引用。而在Adapter之中或者MVP模式里使用，我们通常不希望将Aty等活动类的引用传递下去的，因为这样耦合性就会比较高。而且更容易因此带来更多的内存泄漏的隐患。
更多的，可以参考RxLifecycle作者的自述 ：Why Not RxLifecycle?
四、以MVP模式为例，如何比较优雅地使用它
上头也说了，AutoDispose的主要优势之一，就是无需传递活动类的引用。但是他需要一个LifecycleOwner类的引用。如果我们不进行转化或者优化，也只能通过传递活动类引用，从而糟蹋了他的一个重大优势。上头我们说了，通过官方Lifecycle，可以进行对活动类的生命周期监听。那我们可以将LifecycleOwner对象放置在Presenter里：
1、为了避免代码重复冗余，先封装一个工具类（参考博客是如此推荐的，本人也是这种想法，当然本身代码也不多，这个做不做取决于本人）：
2、在订阅使用场景对应的类中，以Presenter为例，持有一个LifecycleOwner对象，在Presenter初始化的时候，使用Lifecycle提供的方法进行presenter（里的LifecycleOwner对象）对活动类生命周期的监听：
综上，我们就把AutoDispose的基本原理解释清楚了，如果有错误或者偏颇欢迎指正。本文许多的截图，思路来自于参考博客，如原作者有相关意见，请及时联系，不胜感激！
参考博文：
---------------------
作者：却把清梅嗅 来源：CSDN 题目：Android架构中添加AutoDispose解决RxJava内存泄漏
链接：https://blog.csdn.net/mq2553299/article/details/79418068
---------------------
作者：却把清梅嗅 来源：CSDN 题目：Android官方架构组件:Lifecycle详解&原理分析
链接：https://blog.csdn.net/mq2553299/article/details/79029657