,文章

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

文章目录

前言

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

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

使用

在app build.gradle 中加入引用:

dependencies {
    //leakcanary 2.4
    implementation 'com.squareup.leakcanary:plumber-android:2.4'
}

在项目中加入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内存泄漏之使用静态内部类并持有外部类的弱引用
发表评论