使用leakcanary 检测Android内存泄漏

一、概述

leakcanary是什么？ 官方给出的定义是 “A memory leak detection library for Android and Java”  Android 和 Java 内存泄露检测库

虽然java和android使用虚拟机帮助开发者管理了内存，但是仍然会有未注意到的引用持有了应该被释放的对象，此时，就会造成内存泄漏。当泄漏的内存不断的积累，我们就会看到一个我们很不愿意看到的现象 ——

java.lang.OutOfMemoryError

过去，我们习惯使用MAT来分析内存泄漏问题，但这种分析需要一定的经验，且并不高效，往往定位一个小的内存泄漏，需要进行反复对比。那么使用leakcanary是否能简单高效的查出内存泄漏呢，让我们来看看。

二、如何使用

使用leakcanary非常简单。

第一步：你需要在gradle中添加依赖

第二步：你需要继承application，并加载leakcanary

到这里leakcanary就加载完成了，此时在android3.0及以上版本中的activity就已经被监控了。如果你需要检测activity以外的实例，则你要在继承application的类中返回出refWatcher对象用来监控实例。

第三步：使用watcher监控你认为可能泄露的实例

在android3.0 以上的版本，watcher会自动监控activity，如果是3.0以下的android版本，则需要手动在onDestroy中监控。

那除了activity之外，我们很多情况下，会需要查看一下fragment是否泄露，那么，只需要在fragment的onDestroy中，加入监控即可。



除了view相关的对象之外，一些数据实例也很有可能被泄露，如一些被静态引用所持有的对象。这个时候，我们可能也需要对这些实例进行监控。那么只需要在你认为实例将要被释放的时候，将该实例监控起来。



到这里你的所有代码工作都完成啦！

第六步：运行你的程序，并使你的操作覆盖尽可能多的场景

在操作的过程中，很可能就已经出现了内存泄漏，如果你监控的对象出现了内存泄漏，则你可能会看到如下提示：



这里就是说LoadingActivity中的.instance变量持有了一个LoadingActivity实例，导致实例无法释放，出现了内存泄漏。

三、leakcanary 原理浅析

leakcanary是如何确定一个被监控的对象泄漏了呢，简单来说，检测分为以下几步：

1、RefWatcher.watch() 会以监控对象来创建一个 KeyedWeakReference 弱引用对象。

2、在 AndroidWatchExecutor 的后台线程里，检查弱引用是否已经被清除了，如果没被清除，则执行一次 GC。

3、如果弱引用对象仍然没有被清除，则说明内存泄漏了，系统就导出 hprof 文件，保存在 app 的文件系统目录下。

4、HeapAnalyzerService 启动一个单独的进程，使用 HeapAnalyzer 来分析 hprof 文件。它使用另外一个开源库 HAHA。

5、分析完成后，内存泄漏信息送回给 DisplayLeakService，它是运行在 app 进程里的一个服务。然后在设备通知栏显示内存泄漏信息。

原理很浅显易懂，那么我们来看一下源码。

任何一个leakcanary的使用都是从install开始的，那么install函数究竟做了什么呢？

/**
* Creates a {@link RefWatcher} that works out of the box, and starts watching activity
* references (on ICS+).
*/
public static RefWatcher install(Application application) {
return install(application, DisplayLeakService.class,
AndroidExcludedRefs.createAppDefaults().build());
}

/**
* Creates a {@link RefWatcher} that reports results to the provided service, and starts watching
* activity references (on ICS+).
*/
public static RefWatcher install(Application application,
Class<? extends AbstractAnalysisResultService> listenerServiceClass,
ExcludedRefs excludedRefs) {
if (isInAnalyzerProcess(application)) {
return RefWatcher.DISABLED;
}
enableDisplayLeakActivity(application);
HeapDump.Listener heapDumpListener =
new ServiceHeapDumpListener(application, listenerServiceClass);
RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);
ActivityRefWatcher.installOnIcsPlus(application, refWatcher);
return refWatcher;
}

我们可以看出，applicate的进程不能和分析进程处于同一进程，否则会返回DISABLE。接下来是enableDisplayLeakActivity，这是启用显示内存泄漏堆栈的信息页面。然后会new一个ServiceHeapDumpListener，这是用于监听Dump信息的服务service，传输进去的类是DisplayLeakService，很明显，这就是在通知栏中显示内存泄漏堆栈信息的服务，这里也可以看出，我们可以自定义通知栏中显示的信息。最后，初始化了两个watcher，一个是返回的refWatcher，一个是activityRefWatcher。这个refWatcher是用于返回给上层进行其他监听，这个后面会讲；而activityRefWatcher里，监听了activity的生命周期，也就是之前说的，在install的时候，activity会被自动监听的原因了。

接下来，我们看一下refWatcher.watch做了什么

/**
* Identical to {@link #watch(Object, String)} with an empty string reference name.
*
* @see #watch(Object, String)
*/
public void watch(Object watchedReference) {
watch(watchedReference, "");
}

/**
* Watches the provided references and checks if it can be GCed. This method is non blocking,
* the check is done on the {@link Executor} this {@link RefWatcher} has been constructed with.
*
* @param referenceName An logical identifier for the watched object.
*/
public void watch(Object watchedReference, String referenceName) {
checkNotNull(watchedReference, "watchedReference");
checkNotNull(referenceName, "referenceName");
if (debuggerControl.isDebuggerAttached()) {
return;
}
final long watchStartNanoTime = System.nanoTime();
String key = UUID.randomUUID().toString();
retainedKeys.add(key);
final KeyedWeakReference reference =
new KeyedWeakReference(watchedReference, key, referenceName, queue);

watchExecutor.execute(new Runnable() {
@Override public void run() {
ensureGone(reference, watchStartNanoTime);
}
});
}

从注释中可以看出，watch是一个用于检测引用是否被回收的非阻塞方法。

这里主要做两件事，一个是将创建的弱引用加到引用队列中去，一个是在watchExecutor线程中调用 ensureGone函数。

下面我们看一下ensureGone函数

void ensureGone(KeyedWeakReference reference, long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();

long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
removeWeaklyReachableReferences();
if (gone(reference) || debuggerControl.isDebuggerAttached()) {
return;
}
gcTrigger.runGc();
removeWeaklyReachableReferences();
if (!gone(reference)) {
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);

File heapDumpFile = heapDumper.dumpHeap();

if (heapDumpFile == HeapDumper.NO_DUMP) {
// Could not dump the heap, abort.
return;
}
long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
heapdumpListener.analyze(
new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
gcDurationMs, heapDumpDurationMs));
}
}

这里可以看出，在一段时间后，这里回去判断引用是否被移除了，如果没有被移除，则执行一次gc，若引用还没有被移除，则认为很可能泄露了。

此时将Dump文件保存下来，用install时创建的listener去调用一个方法，在另一个进程中去执行对的分析。这里的分析使用的是另一个叫HAHA的开源库，这里就不展开来讲了。

BTW: 这里有两个tips分享给大家

1、leakcanary1.5 以上的版本做了很大的改动，如果sdk或者as较老，work不了1.5的版本的话，可以尝试1.4或者1.3的版本

2、后面的分析耗时较久，虽然有调用栈可以定位问题，但是能弄清操作更好，所以有时在你认为进行了很有可能导致泄漏的操作的时候，可以暂停操作一小会。

最后贴出 github源码地址：
https://github.com/square/leakcanary