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内存泄露》