使用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