LeakCanary原理解析

相信很多人知道LeakCanay是square公司出的一个内存泄漏检测开源库，其使用也非常简单，在Application的onCreate中进行装载就可以，我们看下：

if (LeakCanary.isInAnalyzerProcess(this)) {
          //如果当前进程在内存泄漏检测进程中，则不需要再进行其他的初始化和LeakCanary的装载
            // This process is dedicated to LeakCanary for heap analysis.
            // You should not init your app in this process.
            return;
}
//装载LeakCanary
LeakCanary.install(this);

它的使用是非常简单，但是你了解怎么检查内存泄漏的？它是否可以检测所有的内存泄漏？
我们先看下LeakCanary.install的实现：

public static RefWatcher install(Application application) {
    return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
        .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
        .buildAndInstall();
  }

LeakCanary的install内部使用了链式编程方式一一对调用对应的函数，最后返回RefWatcher对象。其主要工作有：
一、创建RefWatcher对象的构造者
二、配置RefWatcher对象的构造者：设置内存泄漏检测结果处理Class；设置内存泄漏忽略的列表
三、构建RefWatcher，并装载内存泄漏检测器开始检测

一、创建RefWatcher对象的构造者

先看下install方法调用的第一个方法refWatcher方法要做什么：

public static AndroidRefWatcherBuilder refWatcher(Context context) {
    return new AndroidRefWatcherBuilder(context);
  }

它很简单，创建一个RefWatcher类的构造器，并返回此构造器。

二、配置RefWatcher对象的构造者

1、设置内存泄漏检测结果处理Class
install方法中创建AndroidRefWatcherBuilder之后，调用listenerServiceClass方法，设置内存泄漏检测结果处理Class：

public AndroidRefWatcherBuilder listenerServiceClass(
      Class<? extends AbstractAnalysisResultService> listenerServiceClass) {
    return heapDumpListener(new ServiceHeapDumpListener(context, listenerServiceClass));
  }

public final T heapDumpListener(HeapDump.Listener heapDumpListener) {
    this.heapDumpListener = heapDumpListener;
    return self();
  }

listenerServiceClass先将内存检测结果处理Class包装成dump heap的监听者，再将其赋值给成员变量heapDumpListener，接着返回AndroidRefWatcherBuilder
2、设置内存泄漏忽略的列表
install中，设置完内存泄漏检测结果处理Class，调用excludedRefs设置内存泄漏忽略列表：

public final T excludedRefs(ExcludedRefs excludedRefs) {
    this.excludedRefs = excludedRefs;
    return self();
  }

忽略列表是怎么来的，在此不展开说，感兴趣的自己去看下其源码。

二、构建RefWatcher，并装载内存泄漏检测器开始检测

install方法最后调用buildAndInstall方法构建RefWathcer对象，并装载内存泄漏器进行内存监听。
这里有两个动作，一个是构建RefWatcher对象，二是装载内存泄漏器并进行内存监听：
1、构建RefWatch对象
我们看下buildAndInstall方法中构建RefWatcher的片段：

public RefWatcher buildAndInstall() {
    RefWatcher refWatcher = build();
    //...省略
}

调用build方法构建RefWatcher对象，我们看下build方法的实现：

public final RefWatcher build() {
    if (isDisabled()) {
      //不可以，返回Disable对象
      return RefWatcher.DISABLED;
    }
    //这是在install中设置的内存泄漏忽略列表对象
    ExcludedRefs excludedRefs = this.excludedRefs;
    if (excludedRefs == null) {
      excludedRefs = defaultExcludedRefs();
    }
    //在install方法中设置的内存泄漏监听者
    HeapDump.Listener heapDumpListener = this.heapDumpListener;
    if (heapDumpListener == null) {
      heapDumpListener = defaultHeapDumpListener();
    }
    
    DebuggerControl debuggerControl = this.debuggerControl;
    if (debuggerControl == null) {
      //设置过，所以才有默认的调试控制器
      debuggerControl = defaultDebuggerControl();
    }

    HeapDumper heapDumper = this.heapDumper;
    if (heapDumper == null) {
      //未设置过，设置为默认的堆抓取对象
      heapDumper = defaultHeapDumper();
    }

    WatchExecutor watchExecutor = this.watchExecutor;
    if (watchExecutor == null) {
      //未设置过，设置为默认的每次观察执行器
      watchExecutor = defaultWatchExecutor();
    }

    GcTrigger gcTrigger = this.gcTrigger;
    if (gcTrigger == null) {
      //未设置过，设置为默认的GC触发器
      gcTrigger = defaultGcTrigger();
    }
    //创建引用对象RefWatcher观察者，并返回
    return new RefWatcher(watchExecutor, debuggerControl, gcTrigger, heapDumper, heapDumpListener,
        excludedRefs);
  }

buildAndInstall首先是构建出引用对象观察者RefWatcher
2、装载内存泄漏器并进行内存监听
buildAndInstall创建引用对象观察者之后，使用此观察者装载内存泄漏检测器并监听引用对象：

public RefWatcher buildAndInstall() {
    //构建引用对象观察者
    RefWatcher refWatcher = build();
    if (refWatcher != DISABLED) {
      //如果允许检测内存泄漏
      //设置暂时内存泄漏分析结果
      LeakCanary.enableDisplayLeakActivity(context);
      //调用ActivityRefWatcher的install装载内存泄漏检测器
      ActivityRefWatcher.install((Application) context, refWatcher);
    }
    //返回引用对象观察者
    return refWatcher;
  }

buildAndInstall内部通过ActivityRefWatcher.install方法装载内存泄漏检测器，我们看下其实现：

public static void install(Application application, RefWatcher refWatcher) {
    new ActivityRefWatcher(application, refWatcher).watchActivities();
  }

它先创建一个ActivityRefWatcher对象，在调用ActivityRefWatcher对象的watchActivities方法，从命名上看我们可以大胆的猜测其观察的是Activity的引用对象。ok，我们继续看下watchActivities的实现：

public void watchActivities() {
    // Make sure you don't get installed twice.
    //注销之前设置的监听Activity生命周期
    stopWatchingActivities();
    //调用Android中application的registerActivityLifecycleCallbacks方法监听Activity的生命周期
    application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
  }

  public void stopWatchingActivities() {
    //注销监听Activity生命周期
    application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
  }

//监听Activity生命周期对象
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
      new Application.ActivityLifecycleCallbacks() {
        @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        }

        @Override public void onActivityStarted(Activity activity) {
        }

        @Override public void onActivityResumed(Activity activity) {
        }

        @Override public void onActivityPaused(Activity activity) {
        }

        @Override public void onActivityStopped(Activity activity) {
        }

        @Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
        }

        @Override public void onActivityDestroyed(Activity activity) {
          //Activity 销毁时回调onActivityDestroyed
          ActivityRefWatcher.this.onActivityDestroyed(activity);
        }
      };

watchActivities的核心是创建ActivityRefWatcher对象，并调用Application并注册监听Activity的生命周期。当Activity销毁时，会回调ActivityRefWatcher对象的onActivityDestroyed方法检测此Activity是否被回收内存。
ok，至此LeakCanary的install流程解析完，大家再回顾一下上面的流程，其实我们可以发现LeakCanary的内存泄漏检测是有局限性的，它只能检测与Activity相关的对象是否存在内存泄漏的可能，因为install的整体流程下来只有去监听Activity的生命周期，然后根据Activity销毁时去检测Activity和其相关的对象是否存在内存泄漏，其他组件类似Service、Brocast、ContentProvider等并没有看到有检测内存泄漏的逻辑。故LeakCanary只能检测Activity以及与Activity相关的对象是否存在内存泄漏，其他的它是无法检测的。

四、检测对象是否存在内存泄漏

上面的几个步骤分析了LeakCanary装载的流程，以及分析到Activity销毁时回调ActivityRefWatcher.this.onActivityDestroyed方法去检测分析Activity或者与Activity相关的对象是否存在内存泄漏。
Activity销毁时
我们看下Activity销毁时调用的onActivityDestroyed方法：

void onActivityDestroyed(Activity activity) {
    refWatcher.watch(activity);
  }

onActivityDestroyed方法中调用RefWatcher对象的watch方法：

public void watch(Object watchedReference) {
    watch(watchedReference, "");
  }

watch方法又调用其重载方法：

public void watch(Object watchedReference, String referenceName) {
    //...忽略
    //逻辑当前开始检测的时间
    final long watchStartNanoTime = System.nanoTime();
    //生成一个随机唯一id，作为与此引用对象（Activity）关联的标识
    String key = UUID.randomUUID().toString();
    //记录此key
    retainedKeys.add(key);
    //创建引用对象与id关联的弱引用对象
    final KeyedWeakReference reference =
        new KeyedWeakReference(watchedReference, key, referenceName, queue);
    //调用异步方法内存泄漏检测
    ensureGoneAsync(watchStartNanoTime, reference);
  }

watch方法又调用ensureGoneAsync方法进行异步检测分析。
在这里重点介绍下KeyedWeakReference：

final class KeyedWeakReference extends WeakReference<Object> {
  public final String key;
  public final String name;

  KeyedWeakReference(Object referent, String key, String name,
      ReferenceQueue<Object> referenceQueue) {
    super(checkNotNull(referent, "referent"), checkNotNull(referenceQueue, "referenceQueue"));
    this.key = checkNotNull(key, "key");
    this.name = checkNotNull(name, "name");
  }
}

KeyedWeakReference继承了WeakReference，它也是弱引用的实现类，一般我们创建弱引用对象时都是只传与之关联的对象，这里还传递使用了一个WeakReferenceQueue，这个用来干嘛的？这个queue它的作用是用来存放已经被回收的弱引用对象，如果queue中有这个弱引用就代表这个弱引用所关联的对象已经被回收；而如果queue中没有这个弱引用对象则代表这个弱引用所关联的对象还没被回收，是存在内存泄漏的可能性。
LeakCanary就是根据WeakReference这个Queue的特性来检测对象是否存在内存泄漏的，下面的分析会讲解到的。
回到我们的正题，我们继续往下分析ensureGoneAsync方法：

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

ensureGoneAsync方法调用watchExecutor的execute方法执行实现异步，最终进入异步子线程中实现ensureGone方法。
watchExecutor这个对象看起来像是线程池，但其实它不是，Retryable也不是Runnable的子类或者子接口。watchExecutor的核心工作是将检测任务发到UI线程中，然后再发到子线程，通过子线程调度。其子线程是通过ThreadHandler实现的，具体的代码实现在这里不做讲解分析，有兴趣的自己去看。
ok，我们继续往下方向，到这个ensureGone方法：

Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    //记录gc的开始时间
    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;
    }
    //对象还没被回收
    //调用GC方法触发GC
    gcTrigger.runGc();
    //删除已经被回收的弱引用对象
    removeWeaklyReachableReferences();
    if (!gone(reference)) {
      //对象还没被回收
      //记录开始抓取堆内存快照的时间
      long startDumpHeap = System.nanoTime();
      //记录gc使用的时长
      long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
      //通过heapDumper的dumpHeap方法抓取堆内存快照，并返回存储堆内存快照文件
      File heapDumpFile = heapDumper.dumpHeap();
      if (heapDumpFile == RETRY_LATER) {
        // Could not dump the heap.
        //抓取堆内存快照失败，则稍后再试
        return RETRY;
      }
      //记录抓取堆内存快照
      long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
      //调用analyze对堆内存快照进行内存分析
      heapdumpListener.analyze(
          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
              gcDurationMs, heapDumpDurationMs));
    }
    //返回分析完成的状态
    return DONE;
  }

ensureGone方法主要是确认引用对象是否已经被回收，其核心工作分为5大步骤：
4.1、判断引用对象是否已经被回收：
判断引用对象是否已经被回收是通过removeWeaklyReachableReferences和gone方法配合完成的。removeWeaklyReachableReferences方法是判断弱引用队列Queue是否存在已经被回收的引用对象，如果他们的key相等代表已经被回收，我们看下其方法的实现：

private void removeWeaklyReachableReferences() {
    KeyedWeakReference ref;
    while ((ref = (KeyedWeakReference) queue.poll()) != null) {
      //遍历弱引用队列queue，并出队
      //从retainedKeys集合中移除被回收弱引用所关联的key
      retainedKeys.remove(ref.key);
    }
  }

private boolean gone(KeyedWeakReference reference) {
    //判断retainedKeys集合中是否存在弱引用对象所关联的key，存在代表未被回收，不存在已经被回收
   //取反，返回true代表引用对象已经被回收；返回false代表引用对象未被回收
    return !retainedKeys.contains(reference.key);
  }

根据上面介绍的WeakReference弱引用，传递队列Queue时，这个Queue是用来存储已经被回收的弱引用，所以LeakCanary使用了弱引用的这特性，根据这个特性来判断是否与弱引用对象所关联的引用对象是否已经被回收。removeWeaklyReachableReferences遍历Queue将被回收的弱引用所关联key从retainedKeys集合中移除；然后判断引用对象是否已经被回收在gone中只要判断引用对象关联key在retainedKeys中不存在即可。
4.2、触发GC进行垃圾收集和回收，再判断引用对象是否已经被回收：
经历4.1步骤之后，如果对象还存活，则使用GC触发器runGc触发GC进行垃圾收集和回收，然后走一次步骤1.1的流程
4.3、抓取堆内存快照：
经历GC之后，如果引用对象还存活，则说明引用存在内存泄漏的可能性。此时LeakCanary就尝试去抓取堆内存快照:

File heapDumpFile = heapDumper.dumpHeap();

抓取的堆内存快照存放在hprof文件中，它抓取堆内存快照是是通过Debug类进行抓取，我们看下其实现：

try {
      Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
      cancelToast(toast);
      return heapDumpFile;
    }

public static void dumpHprofData(String fileName) throws IOException {
        VMDebug.dumpHprofData(fileName);
    }

通过Debug类的dumpHprofData方法抓取堆内存快照，而dumpHprofData方法调用的nativie方法，通过虚拟机内部实现堆内存快照的抓取。
4.4、分析堆内存快照：
抓取堆内存快照之后，就对堆内存快照文件进行分析：

heapdumpListener.analyze(
          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
              gcDurationMs, heapDumpDurationMs));

我们看下分析的流程：

@Override public void analyze(HeapDump heapDump) {
    checkNotNull(heapDump, "heapDump");
    //调用runAnalysis
    HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);
  }

public static void runAnalysis(Context context, HeapDump heapDump,
      Class<? extends AbstractAnalysisResultService> listenerServiceClass) {
    //将堆内存快照传到Service中分析
    Intent intent = new Intent(context, HeapAnalyzerService.class);
    intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName());
    intent.putExtra(HEAPDUMP_EXTRA, heapDump);
    context.startService(intent);
  }

分析堆内存快照是将堆内存的相关信息传到HeapAnalyzerService进行分析处理，而HeapAnalyzerService又是IntentService的子类，所以最后进入onHandleIntent方法：

@Override protected void onHandleIntent(Intent intent) {
     //...省略
    //取出监听分析结果的类名
    String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA);
    //取出堆内存快照信息类
    HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA);
    //创建堆内存分析类
    HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs);
    //调用堆内存分析类的checkForLeak方法进行分析，并得到一个内存分析结果类对象AnalysisResult 
    AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey);
    //调用sendResultToListener方法，将堆内存信息、分析结果交给结果监听者进行处理
    AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);
  }

onHandleIntent的核心是取出传递过来的堆内存信息，创建堆内存分析类，使用这个类进行堆内存分析，得到堆内存分析结果类，最后将这个分析结果发送给监听者，让结果监听者处理这个分析结果。
至于HeapAnalyzer是怎么分析的，这里就不展开说，它的核心思想就是根据GC Root和引用链已经hprof协议文件的解析，这部分比较复杂，就不展开介绍了（hprof协议）
我们看下结果监听者是怎么处理分析结果的：

public static void sendResultToListener(Context context, String listenerServiceClassName,
      HeapDump heapDump, AnalysisResult result) {
    Class<?> listenerServiceClass;
    try {
      //根据分析结果监听者的类名，得到对应的Class对象
      listenerServiceClass = Class.forName(listenerServiceClassName);
    } catch (ClassNotFoundException e) {
      throw new RuntimeException(e);
    }
    //将分析结果发送到结果监听者的Service中进行处理分析结果
    Intent intent = new Intent(context, listenerServiceClass);
    intent.putExtra(HEAP_DUMP_EXTRA, heapDump);
    intent.putExtra(RESULT_EXTRA, result);
    context.startService(intent);
  }

这里的分析结果监听者对应的是我们再分析LeakCanary的install时设置的那个监听者者Class，它就是DisplayLeakService，DisplayLeakService是AbstractAnalysisResultService的子类，而AbstractAnalysisResultService又是IntentService的子类，我们看下AbstractAnalysisResultService的onHandleIntent：

@Override protected final void onHandleIntent(Intent intent) {
    //取出堆内存快照信息和分析结果信息
    HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAP_DUMP_EXTRA);
    AnalysisResult result = (AnalysisResult) intent.getSerializableExtra(RESULT_EXTRA);
    try {
      //将堆内存信息和分析结果信息传给onHeapAnalyzed方法进行处理
      onHeapAnalyzed(heapDump, result);
    } finally {
      //noinspection ResultOfMethodCallIgnored
      //最后删除堆内存快照文件
      heapDump.heapDumpFile.delete();
    }
  }

DisplayLeakService重写了onHeapAnalyzed方法，我们看下其实现：

@Override protected final void onHeapAnalyzed(HeapDump heapDump, AnalysisResult result) {
    //格式化内存泄漏检测结果信息
    String leakInfo = leakInfo(this, heapDump, result, true);
    //...省略
    if (!shouldSaveResult) {
      //通知栏标题
      contentTitle = getString(R.string.leak_canary_no_leak_title);
      //通知栏内容
      contentText = getString(R.string.leak_canary_no_leak_text);
      pendingIntent = null;
    } else if (resultSaved) {
      //生成pendingIntent，用于点击通知时所打开Activity的意图
      pendingIntent = DisplayLeakActivity.createPendingIntent(this, heapDump.referenceKey);

      if (result.failure == null) {
        //分析结果失败的信息为空，代表有内存泄漏
        String size = formatShortFileSize(this, result.retainedHeapSize);
        String className = classSimpleName(result.className);
        if (result.excludedLeak) {
          //通知栏标题，是系统内部引起的泄漏，可以忽略的内存泄漏
          contentTitle = getString(R.string.leak_canary_leak_excluded, className, size);
        } else {
        //通知栏标题，非系统引起的内存泄漏，不可忽略的内存泄漏
          contentTitle = getString(R.string.leak_canary_class_has_leaked, className, size);
        }
      } else {
        //通知栏标题，分析失败
        contentTitle = getString(R.string.leak_canary_analysis_failed);
      }
      //通知栏内容
      contentText = getString(R.string.leak_canary_notification_message);
    } else {
      //通知栏标题
      contentTitle = getString(R.string.leak_canary_could_not_save_title);
      //通知栏内容
      contentText = getString(R.string.leak_canary_could_not_save_text);
      pendingIntent = null;
    }
    // New notification id every second.
    int notificationId = (int) (SystemClock.uptimeMillis() / 1000);
    //显示内存检测结果通知
    showNotification(this, contentTitle, contentText, pendingIntent, notificationId);
    afterDefaultHandling(heapDump, result, leakInfo);
  }

分析结果的处理主要是将分析结果通过通知栏的方式显示，如果存在内存泄漏则可以通过点击通知打开查看内存泄漏的引用链关系。

ok，至此，LeakCanary的实现原理解析完了，我们总结下：
1、LeakCanary只能检测Activity已经与Activity相关联的对象
2、它的实现是通过：

• 监听Activity的生命周期，在onDestroy时，去分析这个要销毁的Activity以及与的相关的对象是否存在内存泄漏
• 采用了弱引用和弱引用Queue的特性进行判断引用对象即Activity是否已经被回收
• 如果GC之后引用对象还存活，那么通过Debug的dumpHprofData方法调用nativie方法让虚拟机去抓取堆内存快照
• 根据堆内存快照文件的格式hprof协议、GC ROOT、GC引用链的原理进行解析、分析堆内存快照，得到分析结果信息类
• 将分析结果通过通知栏的方式显示出来，如果存在内存泄漏则当点击通知栏时会打开DispalyLeakActivity将内存泄漏的信息展示处理

！！！这里特别强调：LeakCanary只能分析Activity以及与Activity相关的对象是否存在内存泄漏，其它的它是无法检测出是否有内存泄漏的。