明白原理
一般内存泄漏(traditional memory leak)的原因是：忘记释放分配的内存
逻辑内存泄漏(logical memory leak)的原因是：当应用不再需要这个对象，未释放该对象的所有引用。
一般内存泄漏如：Cursor忘记关闭等，此种场景存在一个标准的关闭方法，网络大把，不再展开，也比较好排查。实际操作中发现，Activity相关的逻辑泄漏占一大方向，泄漏的原因:
内部类，handler等，持有activity引用，导致Activity的需要释放的时候，释放不了。
这其中又以内部类表现最为突出：
- 非静态内部类（默认）隐式持有外部类的的引用
- 注意这和匿名不匿名没有关系
- 内部类在干一些事情，外部类（如activity）在特殊环境下，比如内存不足，反复手动返回（monkey能跑出来），需要回收的时候，发现内部类还在持有他，从而产生无法回收的问题。就导致了泄漏。
tips: 在kotlin中 “嵌套类的类默认并不是内部类：他们并没有包含外部类的隐式引用”——《kotlin Action》
重点理解：第一条，第二条
一个内部类的示例代码：
这是安卓编码中经常会遇到的一种场景，即内部类访问外部类的private的成员变量或者方法。
这是可以的，为什么？java中private修饰的成员不是只能被成员所在类访问么，难道private真的失效了？
其实是编译器做了一些我们看不到的工作。反编译上面代码，我们来看看究竟发生了什么
内部类MyRunnable里面多了一个MainActivity的成员变量，并且，在构造函数里面获得了外部类的引用
至此我们明白了：
为什么我们可以在非静态内部类中，直接调用外部类的成员?原因就是内部类，持有了外部类的一个引用 那就是this
内部类的调用外部类的成员的时候，其实是省略了 "this."的。
内部类和外部类之间，是通过一个外部类的引用进行调用的，而外部类的private属性通过编译器生成的我们看不见的静态方法，通过传入的外部类实例引用获取出来。通过还原，我们了解了非静态内部类跟外部类交互时的工作方式，以及非静态内部类为什么会持有外部类的引用。
辅助系列：
Android内存泄漏快速解决——三大工具
android内存泄漏快速解决——模板泄漏代码
解决系列：
android内存泄漏快速解决——一个方法解决70%的泄漏
怎么解决这个问题，思路就是避免使用非静态内部类，定义内部类时，要么是放在单独的类文件中，要么就是使用静态内部类。因为静态的内部类不会持有外部类的引用，所以不会导致外部类实例的内存泄露。当你需要在静态内部类中调用外部的Activity时，我们可以使用弱引用来处理。
分享两个案例：leakCanary观测到的泄漏：
android内存泄漏快速解决——构造方法里不能出现非弱引用的对象的实例化
其他正在处理中的泄漏：
android内存泄漏快速解决——fragment的rootview泄漏
android内存泄漏快速解决——系统源码泄漏
viewpager+fragment滑动泄漏
泄漏好文章整理：
