1.添加依赖:
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
用法
监控 Activity 泄露
我们经常把 Activity 当作为 Context 对象使用,在不同场合由各种对象引用 Activity。所以,Activity 泄漏是一个重要的需要检查的内存泄漏之一。
//在自己的Application中添加如下代码
public static RefWatcher getRefWatcher(Context context) {
App application = (App) context.getApplicationContext();
return application.refWatcher;
}
//在自己的Application中添加如下代码
private RefWatcher refWatcher;
@Override
public void onCreate() {
super.onCreate();
//在自己的Application中添加如下代码
refWatcher = LeakCanary.install(this);
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//在自己的应用初始Activity中加入如下两行代码
RefWatcher refWatcher = MyApp.getRefWatcher(this);
refWatcher.watch(this);
}
一个配置好了的 RefWatcher
实例。它同时安装了 ActivityRefWatcher
来监控 Activity 泄漏。即当 Activity.onDestroy()
被调用之后,如果这个 Activity 没有被销毁,logcat 就会打印出如下信息告诉你内存泄漏发生了。
* com.example.leakcanary.MainActivity has leaked:
* GC ROOT thread java.lang.Thread.<Java Local> (named 'AsyncTask #1')
* references com.example.leakcanary.MainActivity$2.this$0 (anonymous class extends android.os.AsyncTask)
* leaks com.example.leakcanary.MainActivity instance
* Reference Key: c4d32914-618d-4caf-993b-4b835c255873
* Device: Genymotion generic Google Galaxy Nexus - 4.2.2 - API 17 - 720x1280 vbox86p
* Android Version: 4.2.2 API: 17
* Durations: watch=5100ms, gc=104ms, heap dump=82ms, analysis=3008ms
!!! notes
LeakCanary 自动检测 Activity 泄漏只支持 Android ICS 以上版本。因为 Application.registerActivityLifecycleCallbacks()
是在 API 14 引入的。如果要在 ICS 之前监测 Activity 泄漏,可以重载 Activity.onDestroy()
方法,然后在这个方法里调用 RefWatcher.watch(this)
来实现。
监控 Fragment 泄漏
public abstract class BaseFragment extends Fragment {
@Override
public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = App.getRefWatcher(getActivity());
refWatcher.watch(this);
}
}
当 Fragment.onDestroy()
被调用之后,如果这个 fragment 实例没有被销毁,那么就会从 logcat 里看到相应的泄漏信息。
监控其他泄漏
...
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(someObjNeedGced);
当 someObjNeedGced
还在内存中时,就会在 logcat 里看到内存泄漏的提示。
在 debug 版本上,集成 LeakCanary 库,并执行内存泄漏监测,而在 release 版本上,集成一个无操作的 wrapper ,这样对程序性能就不会有影响。
原理
LeakCanary 流程图

LeakCanary 的机制如下:
RefWatcher.watch()
会以监控对象来创建一个KeyedWeakReference
弱引用对象- 在
AndroidWatchExecutor
的后台线程里,来检查弱引用已经被清除了,如果没被清除,则执行一次 GC - 如果弱引用对象仍然没有被清除,说明内存泄漏了,系统就导出 hprof 文件,保存在 app 的文件系统目录下
HeapAnalyzerService
启动一个单独的进程,使用HeapAnalyzer
来分析 hprof 文件。它使用另外一个开源库 HAHA。HeapAnalyzer
通过查找KeyedWeakReference
弱引用对象来查找内在泄漏HeapAnalyzer
计算KeyedWeakReference
所引用对象的最短强引用路径,来分析内存泄漏,并且构建出对象引用链出来。- 内存泄漏信息送回给
DisplayLeakService
,它是运行在 app 进程里的一个服务。然后在设备通知栏显示内存泄漏信息。
几个有意思的代码
如何导出 hprof 文件
File heapDumpFile = new File("heapdump.hprof");
Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
可以参阅 AndroidHeapDumper.java 的代码。
如何分析 hprof 文件
这是个比较大的话题,感兴趣的可以移步另外一个开源库 HAHA,它的祖先是 MAT。
如何使用 HandlerThread
可以参阅 AndroidWatchExecutor.java的代码,特别是关于 Handler, Loop 的使用。
怎么知道某个变量已经被 GC 回收
可以参阅 RefWatcher.java 的 ensureGone()
函数。最主要是利用 WeakReference
和 ReferenceQueue
机制。简单地讲,就是当弱引用 WeakReference
所引用的对象被回收后,这个 WeakReference
对象就会被添加到 ReferenceQueue
队列里,我们可以通过其 poll()
方法获取到这个被回收的对象的 WeakReference
实例,进而知道需要监控的对象是否被回收了。
关于内存泄漏
内存泄漏可能很容易发现,比如 Cursor 没关闭;比如在 Activity.onResume()
里 register 了某个需要监听的事件,但在 Activity.onPause()
里忘记 unregister 了;内存泄漏也可能很难发现,比如 LeakCanary 示例代码,隐含地引用,并且只有在旋转屏幕时才会发生。还有更难发现,甚至无能为力的内存泄漏,比如 Android SDK 本身的 BUG 导致内存泄漏。AndroidExcludedRefs.java 里就记录了一些己知的 AOSP 版本的以及其 OEM 实现版本里存在的内存泄漏。