LeakCanary 核心原理

LeakCanary 检测对象的类型

ReferenceQueue 与 WeakReference

LeakCanary 里的监控列表与保留列表

常见内存泄漏案例

1. 单例导致内存泄漏

2. 静态变量导致内存泄漏

3. 非静态内部类导致内存泄漏

4. 未取消注册或回调导致内存泄漏

5. Timer 和 TimerTask 导致内存泄漏

6. 集合中的对象未清理造成内存泄漏

7. 资源未关闭或释放导致内存泄漏

8. 属性动画造成内存泄漏

9. WebView 造成内存泄漏

LeakCanary

LeakCanary 是 Square 公司的一个开源库。通过它可以在 App 运行过程中检测内存泄漏，当内存泄漏发生时会生成发生泄漏对象的引用链，并通知程序开发人员。

LeakCanary 执行流程

$\bullet$ 检测保留的对象

$\bullet$ 生成堆转储文件（heap dump）

$\bullet$ 分析堆转储文件

$\bullet$ 对泄漏进行分类

LeakCanary 核心原理

LeakCanary 通过 hook Android 的生命周期来自动检测 Activity 和 Fragment 何时被销毁，何时应该被垃圾回收，这些被 destory 的对象被传递给 ObjectWatcher， ObjectWatcher 持有对它们的弱引用。

LeakCanary 检测对象的类型

$\bullet$ 已销毁的 Activity 实例

$\bullet$ 已销毁的 Fragment 实例

$\bullet$ 已销毁的 Fragment View 实例

$\bullet$ 已清除的 ViewModel 实例

ReferenceQueue 与 WeakReference

弱引用（WeakReference）可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收器回收，虚拟机就会把这个弱引用加入到与之关联的引用队列中，我们可以用此特性来检测一个对象是否被垃圾回收器回收成功。

(在上图中，首先创建弱引用WeakReference，给它关联一个ReferenceQueue，对于一个弱引用如果要引用它需要一个强引用obj来引用这个对象Object。当我们把 obj 置为空，GC 就来回收。当弱引用所引用的对象被回收后，这个弱引用就被加入到与之关联的 ReferenceQueue 里)

LeakCanary 里的监控列表与保留列表

弱引用的流转过程

常见内存泄漏案例

1. 单例导致内存泄漏

单例模式在 Android 开发中会经常用到，但是如果使用不当就会导致内存泄漏。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么整个应用程序的生命周期都不能正常被回收，从而导致内存泄漏。

public class AppSettings {

    private static volatile AppSettings mInstance;
    private Context context;

    public AppSettings(Context context) {
        this.context = context;
    }

    public static AppSettings getInstance(Context context) {
        if (mInstance == null) {
            synchronized (AppSettings.class){
                if (mInstance == null) {
                    mInstance = new AppSettings(context);
                }
            }
        }
        return mInstance;
    }
}

如上述代码中的单例写法，就会存在内存泄漏的可能。如果我们在调用 getInstance(Context context) 方法的时候传入的 context 参数是 Activity、Service 等上下文时，就会导致内存泄漏。以 Activity 为例，当我们启动一个 Activity，并调用 getInstance(Context context) 方法去获取 AppSettings 的单例，传入 Activity.this 作为 context，这样 AppSettings 类的单例 mInstance 就持有了 Activity 的引用，当我们退出 Activity 时，该 Activity 就没有用了，但是因为 mInstance 作为静态单例（在应用程序的整个生命周期中存在）会继续持有这个 Activity 的引用，导致这个 Activity 对象无法被回收释放，这就造成了内存泄漏。

为了避免这种单例导致内存泄漏，我们可以将 context 参数改为全局上下文：

    private AppSettings(Context context){
        this.context = context.getApplicationContext(); // 获取 Application 的上下文
    }

2. 静态变量导致内存泄漏

静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后，它所持有的引用只有等到进程结束才会释放。比如下面这样的情况，在 Activity 中为了避免重复的创建 info，将 sInfo 作为静态变量。

public class InfoActivity extends AppCompatActivity {

    public static Info sInfo;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_info);

        sInfo = new Info(this);
    }

    class Info{
        private Context context;

        public Info(Context context){
            this.context = context;
        }
    }
}

Info 作为 Activity 的静态成员，并且持有 Activity 的引用，但是 sInfo 作为静态变量，生命周期肯定比 Activity 长。所以当 Activity 退出后，sInfo 仍然引用了 Activity，Activity 不能被回收，这就导致了内存泄漏。

在 Android 开发中，静态持有很多时候都有可能因为其使用的生命周期不一致而导致内存泄漏，所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的引用关系，并且尽量少的使用静态持有的变量，以避免发生内存泄漏。当然，我们也可以在适当的时候将静态变量重置为 null，使其不再持有引用，这样也可以避免内存泄漏。

3. 非静态内部类导致内存泄漏

非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期比外部类对象的生命周期长时，就会导致内存泄漏。非静态内部类导致的内存泄漏在 Android 开发中有一种典型的场景就是使用 Handler(是一个匿名内部类)，很多开发者在使用 Handler 时是这样写的：

public class InfoActivity extends AppCompatActivity {
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_info);

        start();
    }

    private void start(){
        Message message = Message.obtain();
        message.what = 1;
        mHandler .sendMessage(message);
    }
    
    //TODO 存在内存泄漏
    private final Handler mHandler = new Handler(){
        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            if (msg.what == 1) {
                //功能代码
            }
        }
    };
}

也许有人会说，mHandler 并未作为静态变量持有 Activity 引用，生命周期可能不会比 Activity 长，应该不一定会导致内存泄漏。显然不是这样的，熟悉 Handler 消息机制的都知道， mHandler 会作为成员变量保存在发送的消息 msg 中，即 msg 持有 mHandler 的引用，而 mHandler 是 Activity 的非静态内部类实例，即 mHandler 持有 Activity 的引用，那么我们就可以理解为 msg 间接持有 Activity 的引用。msg 被发送后先放到消息队列 MessageQueue 中，然后等到 Looper 的轮询处理（MessageQueue 和 Looper 都是与线程相关的，MessageQueue 是 Looper 引用的成员变量，而 Looper 是保存在 ThreadLocal 中的）。那么当 Activity 退出后，msg 可能仍然存在于消息队列 MessageQueue 中未处理或正在处理，那么这样就会导致 Activity 无法被回收，以至发送 Activity 的内存泄漏。

通常在 Android 开发中如果要使用内部类，但又要规避内存泄漏，一般都会采用静态内部类+弱引用的方式。

    MyHandler mHandler;

    public static class MyHandler extends Handler{
        private WeakReference<Activity> mActivityWeakReference;

        public MyHandler(Activity activity){
            // TODO 持有 Activity 的弱引用
            mActivityWeakReference = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            // 处理逻辑
        }
    }

mHandler 通过弱引用的方式持有 Activity，当 GC 执行垃圾回收时，遇到 Activity 就会回收并释放所占据的内存单元。这样就不会发生内存泄漏了。上面的做法确实避免了 Activity 导致的内存泄漏，发送的 msg 不再持有 Activity 的引用了，但是 msg 还是有可能存在消息队列 MessageQueue 中，所以更好的是在 Activity 销毁时就将 mHandler 的回调和发送的消息给移除掉。

 @Override
    protected void onDestroy() {
        super.onDestroy();
        // TODO 把所有的回调都移除
        mHandler.removeCallbacksAndMessages(null);
    }

非静态内部类造成内存泄漏还有一种情况就是使用 Thread 或者 AsyncTask。要避免内存泄漏的话还是需要像上面 Handler 一样使用静态内部类 + 弱引用的方式。

4. 未取消注册或回调导致内存泄漏

比如我们在 Activity 中注册广播，如果在 Activity 销毁后不取消注册，那么这个广播会一直存在系统中，同上面所说的静态内部类一样持有 Activity 引用，导致内存泄漏。因此注册广播后在 Activity 销毁后一定要取消注册。在注册观察者模式的时候，如果不及时取消也会造成内存泄漏。比如使用 Retrofit + RxJava 注册网络请求的观察者回调，同样作为匿名内部类持有外部引用，所以需要记得在不用或者销毁的时候取消注册。

5. Timer 和 TimerTask 导致内存泄漏

Timer 和 TimerTask 在 Android 中通常会被用来做一些计时或循环任务，比如实现无限轮播的 ViewPager:

private void stopTimer(){
        if (mTimer != null) {
            mTimer.cancel();
            mTimer.purge();
            mTimer = null;
        }
        if (mTimerTask != null) {
            mTimerTask.cancel();
            mTimerTask = null;
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        stopTimer();
    }

当我们 Activity 销毁时，有可能 Timer 还在继续等待执行 TimerTask，它持有 Activity 的引用不能被回收，因此当我们 Activity 销毁的时候要立即 cancel 掉 Timer 和 TimerTask，以避免发生内存泄漏。

6. 集合中的对象未清理造成内存泄漏

这个比较好理解，如果一个对象放入到 ArrayList、HashMap 等集合中，这个集合就会持有该对象的引用。当我们不再需要这个对象时，也并没有将它从集合中移除，这样只要集合还在使用（而此对象已经无用了），这个对象就造成了内存泄漏。并且如果集合被静态引用的话，集合里面那些没有用的对象更会造成内存泄漏了。所以在使用集合时要及时将不用的对象从集合 remove，或者 clear 集合，以避免内存泄漏。

7. 资源未关闭或释放导致内存泄漏

在使用 IO、File 流或者 Sqlite、Cursor 等资源时要及时关闭。这些资源在进行读写操作时通常都使用了缓冲，如果不及时关闭，这些缓冲对象就会一直被占用而得不到释放，以至发生内存泄漏。因此我们在不需要使用它们的时候就及时关闭，以便缓冲能及时得到释放，从而避免内存泄漏。

8. 属性动画造成内存泄漏

动画同样是一个耗时任务，比如在 Activity 中启动了属性动画(ObjectAnimator)，但是在销毁的时候，没有调用 cancel 方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去，动画引用所在的控件，所在的控件引用 Activity，这就造成 Activity 无法正常释放。因此同样要在 Activity 销毁的时候 cancel 掉属性动画，避免发生内存泄漏。

9. WebView 造成内存泄漏

关于 WebView 的内存泄漏，因为 WebView 在加载网页后会长期占用内存而不能被释放，因此我们在 Activity 销毁后要调用它的 destory() 方法来销毁它以释放内存。另外在查阅 WebView 内存泄漏相关资料时看到这种情况：WebView 下面的 Callback 持有 Activity 引用，造成 WebView 内存无法释放，即使是调用了 Webview.destory() 等方法都无法解决问题（Android5.1 之后）。最终的解决方案是：在销毁 WebView 之前需要先将 WebView 从父容器中移除，然后再销毁 WebView。