LeakCanary基本解析

大家知道Android系统对app的内存有一个上限，如果代码风格不好，业务庞大，时间紧没有代码评审来约束，是很容易引起OOM异常的，通常我们碰到这种问题，需要用profile工具去仔细的分析和排查，才能找到可能的原因。现在向大家介绍LeakCanary，是一款监测内存泄露的工具，由大名鼎鼎的Square公司开发并开源。

基本用法

参见LeakCanary官方的介绍，一步搞定！
官网介绍的方法非常简单，可以自动监测Activity泄露，原理很直接，就是用application的ActivityLifeCycleCallback，在onActivityDestroyed时去watch。那我们遵循这个套路，自己构建一个RefWatcher，就可以做到监听任何一个实例，只需要在该实例理论上应该销毁的时候watch一下就可以了。此处说销毁并不是真的要销毁，而是没有引用，也就是所谓的jvm内存管理的不可达状态。

原理

jvm内存管理

我们知道，java相对C++有一个巨大的好处就是可以不用做复杂且容易出错的内存管理，jvm有一个内存回收器会周期性的回收不用的内存，细节性的东西很多，也不影响我们理解LeakCanary的原理，我们暂且跳过。只需知道jvm会自动帮我们回收不需要的内存，但是还是有内存泄露的可能。

总体设计图

Main.jpg

核心类介绍

LeakCanary

入口类。接口很简单，简单到只有一个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 refWatcher(application).listenerServiceClass(DisplayLeakService.class)
        .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
        .buildAndInstall();
  }

/** Builder to create a customized {@link RefWatcher} with appropriate Android defaults. */
  public static AndroidRefWatcherBuilder refWatcher(Context context) {
    return new AndroidRefWatcherBuilder(context);
  }

对设计模式有了解，或者看过一些开源框架的代码，可能知道这块使用了Builder模式，这个Builder其实很好理解，个人认为主要的使用场景，就是在构建一个实例时，有太多参数可以配置，如果都放到构造函数去做，那就显得太罗嗦，接口不简洁。使用setter，好像也不太好，我们希望实例构建后直接是可用状态。关于AndroidRefWatcherBuilder和RefWatcherBuilder后面会有介绍。install方法返回RefWatcher，接下来我们就看看这个RefWatcher。

RefWatcher

顾名思义，引用监控，它可以说是一个调度类，从判断泄漏，内存堆日志分析，结果展示，这些功能都在RefWatcher里面串起来

/**
 * Watches references that should become weakly reachable. When the {@link RefWatcher} detects that
 * a reference might not be weakly reachable when it should, it triggers the {@link HeapDumper}.
 *
 * <p>This class is thread-safe: you can call {@link #watch(Object)} from any thread.
 */
public final class RefWatcher {
private final WatchExecutor watchExecutor;
  private final DebuggerControl debuggerControl;
  private final GcTrigger gcTrigger;
  private final HeapDumper heapDumper;
  private final Set<String> retainedKeys;
  private final ReferenceQueue<Object> queue;
  private final HeapDump.Listener heapdumpListener;
  private final ExcludedRefs excludedRefs;
}

先了解这里的每一个成员：

• WatchExecutor 提供后台线程支持以及重试的机制
• DebuggerControl 提供debug状态的判断，调试时有可能持有引用，规避误报泄漏
• GcTrigger 触发gc，尽量避免dump heap
• HeapDumper
• retainedKeys 存储所有监控的引用key，key是在watch时UUID生成的
• ReferenceQueue<Object> 监控系统gc的结果
• HeapDump.Listener dump完成的回调，可以认为是analysis的入口
• ExcludedRefs 预置的忽略引用，Android系统的已知内存泄漏，就可以不用管了

AndroidRefWatcherBuilder

这个类就是通常的Builder写法，只是多了一个RefWatcherBuilder基类，看整个包结构就知道LeakCanary的设计不只是用于Android，而是在java的外面再包一层android实现，这样扩展性好，watcher层定义行为和流程，android层对应具体的实现。

主流程

前面已经把主要的准备工作都介绍了，现在我们开始看看到底是如何监听泄漏的。

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

    ensureGoneAsync(watchStartNanoTime, reference);
  }

1. 记录当前时间
2. 生成key，生成KeyedWeakReference，记录弱引用和key

 private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
    watchExecutor.execute(new Retryable() {
      @Override public Retryable.Result run() {
        return ensureGone(reference, watchStartNanoTime);
      }
    });
  }

  @SuppressWarnings("ReferenceEquality") // Explicitly checking for named null.
  Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    long gcStartNanoTime = System.nanoTime();
    long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);

    removeWeaklyReachableReferences();

    if (debuggerControl.isDebuggerAttached()) {
      // The debugger can create false leaks.
      return RETRY;
    }
    if (gone(reference)) {
      return DONE;
    }
    gcTrigger.runGc();
    removeWeaklyReachableReferences();
    if (!gone(reference)) {
      long startDumpHeap = System.nanoTime();
      long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);

      File heapDumpFile = heapDumper.dumpHeap();
      if (heapDumpFile == RETRY_LATER) {
        // Could not dump the heap.
        return RETRY;
      }
      long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
      heapdumpListener.analyze(
          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
              gcDurationMs, heapDumpDurationMs));
    }
    return DONE;
  }

常见泄露场景

1. 匿名内部类和非静态内部类 隐式持有外部类的引用
2. 注册了引用，没有解注册

reference

开源项目之LeakCanary源码分析
LeakCanary核心原理源码浅析