Android内存泄露检测之LeakCanary的简单使用

前言

使用MAT来分析内存问题，有一些门槛，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比才能找到问题原因。

为了能够简单迅速的发现内存泄漏，Square公司基于MAT开源了LeakCanary。

PS：有不同版本的leakcanary出现不同的问题，因此20210422日重新更新，并验证

使用

在app build.gradle 中加入引用：

Android 9.0 上使用

dependencies {
    //leakcanary 2.3
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.3'
}

Android 4.2 上

dependencies {
    testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
}

然后在自定义application申明

public class TestMemApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        Logger.addLogAdapter(new AndroidLogAdapter());
        if (LeakCanary.isInAnalyzerProcess(this)) {
            // This process is dedicated to LeakCanary for heap analysis.
            // You should not init your app in this process.
            return;
        }
        LeakCanary.install(this);
        // Normal app init code...
    }
}

测试demo分析

在项目中加入LeakCanary之后就可以开始检测项目的内存泄露了，把项目运行起来之后, 开始随便点自己的项目，下面以一个Demo项目为例，来聊一下LeakCanary记录内存泄露的过程以及我如何解决内存泄露的。

使用Handler持有外部类引用来说明，代码片段如下：

public class MainActivity extends AppCompatActivity {
    private final int MSG_DELAY_GO = 0x1000;

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

        //发送延迟处理消息
        mHandler.sendEmptyMessageDelayed(MSG_DELAY_GO, 60 * 1000 * 5);
    }

    private Handler mHandler = new Handler() {

        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);

            switch (msg.what) {
                case MSG_DELAY_GO:

                    break;
            }
        }
    };
}

运行起来后。过滤日志LeakCanary日志TAG

D/LeakCanary( 3323): LeakCanary is running and ready to detect leaks

按Back键退出后（部分日志），需要等一段时间才有完整的日志显示哈。

07-08 19:31:40.013 D/LeakCanary( 3323): 107241 bytes retained by leaking objects
07-08 19:31:40.013 D/LeakCanary( 3323): Signature: 4f5bc1c21df027da9d327d87c73072dfb27e734c
07-08 19:31:40.013 D/LeakCanary( 3323): ┬───
07-08 19:31:40.013 D/LeakCanary( 3323): │ GC Root: Input or output parameters in native code
07-08 19:31:40.013 D/LeakCanary( 3323): │
07-08 19:31:40.013 D/LeakCanary( 3323): ├─ android.os.MessageQueue instance
07-08 19:31:40.013 D/LeakCanary( 3323): │    Leaking: NO (MessageQueue#mQuitting is false)
07-08 19:31:40.013 D/LeakCanary( 3323): │    ↓ MessageQueue.mMessages
07-08 19:31:40.013 D/LeakCanary( 3323): │                   ~~~~~~~~~
07-08 19:31:40.013 D/LeakCanary( 3323): ├─ android.os.Message instance
07-08 19:31:40.013 D/LeakCanary( 3323): │    Leaking: UNKNOWN
07-08 19:31:40.013 D/LeakCanary( 3323): │    ↓ Message.target
07-08 19:31:40.013 D/LeakCanary( 3323): │              ~~~~~~
07-08 19:31:40.013 D/LeakCanary( 3323): ├─ com.la.testleakcanary.MainActivity$1 instance
07-08 19:31:40.013 D/LeakCanary( 3323): │    Leaking: UNKNOWN
07-08 19:31:40.013 D/LeakCanary( 3323): │    Anonymous subclass of android.os.Handler
07-08 19:31:40.013 D/LeakCanary( 3323): │    ↓ MainActivity$1.this$0
07-08 19:31:40.013 D/LeakCanary( 3323): │                     ~~~~~~
07-08 19:31:40.013 D/LeakCanary( 3323): ╰→ com.la.testleakcanary.MainActivity instance
07-08 19:31:40.013 D/LeakCanary( 3323): ​     Leaking: YES (ObjectWatcher was watching this because com.la.testleakcanary.MainActivity received Activity#onDestroy() callback and Activity#mDestroyed is true)
07-08 19:31:40.013 D/LeakCanary( 3323): ​     key = 13f228b5-c5cf-4279-8513-9fac9bc8b9c4
07-08 19:31:40.013 D/LeakCanary( 3323): ​     watchDurationMillis = 5258
07-08 19:31:40.013 D/LeakCanary( 3323): ​     retainedDurationMillis = 223
07-08 19:31:40.013 D/LeakCanary( 3323):
07-08 19:31:40.013 D/LeakCanary( 3323): ====================================
07-08 19:31:40.013 D/LeakCanary( 3323): METADATA
07-08 19:31:40.013 D/LeakCanary( 3323):
07-08 19:31:40.013 D/LeakCanary( 3323): Please include this in bug reports and Stack Overflow questions.
07-08 19:31:40.013 D/LeakCanary( 3323):
07-08 19:31:40.013 D/LeakCanary( 3323): Build.VERSION.SDK_INT: 28
07-08 19:31:40.013 D/LeakCanary( 3323): Build.MANUFACTURER: alps
07-08 19:31:40.013 D/LeakCanary( 3323): LeakCanary version: 2.3
07-08 19:31:40.013 D/LeakCanary( 3323): App process name: com.la.testleakcanary
07-08 19:31:40.013 D/LeakCanary( 3323): Analysis duration: 22673 ms
07-08 19:31:40.013 D/LeakCanary( 3323): Heap dump file path: /data/user/0/com.la.testleakcanary/files/leakcanary/2020-07-08_19-31-13_439.hprof
07-08 19:31:40.013 D/LeakCanary( 3323): Heap dump timestamp: 1594207899988
07-08 19:31:40.013 D/LeakCanary( 3323): ====================================

从上面打印看出，存在内存泄漏。

同时也生成了/data/user/0/com.la.testleakcanary/files/leakcanary/2020-07-08_19-31-13_439.hprof 。这个文件可以用MAT工具在分析一波。

上面是日志打印的。

如果你的应用有SystemUI，那状态栏上也会有提示相关的信息。（具体我就不写了，可以看参考文章2，这里写得很详细）

解决内存泄漏

对于上面的有两种

onDestory时移除所有的回调和消息

@Override
protected void onDestroy() {
    super.onDestroy();
    //退出时移除所有的回调和消息
    if (null != mHandler) {
        mHandler.removeCallbacksAndMessages(null);
    }
}

使用弱引用

    private static class InnerHandler extends Handler {

        WeakReference<MainActivity> weakReference;

        public InnerHandler(MainActivity activity) {
            weakReference = new WeakReference<MainActivity>(activity);
        }

        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            switch (msg.what) {
                case MSG_DELAY_GO:
                    break;
            }
        }
    }

具体使用，可以访问《Handler内存泄漏之使用静态内部类并持有外部类的弱引用》

小结

其实内存泄露的本质是长周期对象持有了短周期对象的引用，导致短周期对象该被回收的时候无法被回收，从而导致内存泄露。我们只要顺着LeakCaneray的给出的引用链一个个的往下找，找到发生内存泄露的地方，切断引用链就可以释放内存了。

参考文章

1. 《LeakCanary说明文档》
2. 《Android内存泄露检测之LeakCanary的使用》
3. 《性能优化工具（九）-LeakCanary》
4. 《Handler内存泄漏之使用静态内部类并持有外部类的弱引用》
5. 《使用LeakCanary分析并解决Android内存泄露》