LeakCanary原理

1. LeakCanary是帮忙我们查询内存泄露的，只需要简单的继承，当发生内存泄露时，就会在手机的桌面上生成内存泄露的文件，.hprof 文件。

打开文件大概如下图，帮助我们分析内存泄露的原因

2. 原理

通过registerActivityLifecycleCallbacks 检测Activity的生命周期。 在Activity执行onDestroy时，开始检测。

检测之前，介绍一下LeakCanary的一个核心的类。

KeyedWeakReference。它是弱引用的子类。我们看一下它的构造函数

参数Object refernce:  是这个弱引用指向的对象。

参数ReferenceQueue<Object>  referenceQueue:   这个是是一个队列，如果弱引用指向的对象被GC回收，那么对象就会被添加到此队列中。 所以我们可以判断，如果一个对象出现在了referenceQueue中，我们就可以认为它已经被GC回收，不存在内存泄露。

 

回到在Activity执行onDestroy时，开始检测。

//生成一个随机的Key,和Activity对应

String key = UUID.randomUUID().toString();

//把这个key添加到retainedKeys，retainedKeys是还没有被GC回收的activity的Key的集合

this.retainedKeys.add(key);

// 生成一个弱引用KeyedWeakReference指向我的要destory的activity

//watchedReference 是要destory的activity. 

//传入queue，用来收集稍后被GC回收的activity对象

final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, this.queue);

// 向handler发送一个ensureGone操作，注意这是一个Idle类型的只有handler空闲才会执行，所以不会阻塞正常的操作。

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

***************准备工作做好了，等待handler空闲执行ensureGone方法******************

ensureGone的时候，handler已经忙完了，正常来说onDestory已经都执行结束了，我们的Activity正常来说应该被回收了。

从queue中不断poll出对象，获取到对应的Key, 并从retainedKeys删除对应的key.

因为queue中的对象被GC回收，所以把他从retainedKeys除去

queue为null后，判断ensureGone传入的reference的key是否已经不存在在retainedKeys中了。

如果不存在证明确实被GC回收。不用管了，这个activity没发生内存泄露

如果还在，那么 this.gcTrigger.runGc(); 再执行一次GC操作。在从queue中不断poll出对象，获取到对应的Key, 并从retainedKeys删除对应的key.....判断ensureGone传入的reference的key是否已经不存在在retainedKeys中了。

如果retainedKeys找不到对应的key，说明确实被GC回收。不用管了，这个activity没发生内存泄露

如果还存在在retainedKeys说明Activity发生内存泄露。

File heapDumpFile = this.heapDumper.dumpHeap(); dump出内存文件。由于这个过程比较耗时，启动 HeapAnalyzerService ，HeapAnalyzerService通过调用HeapAnalyzer的checkForLeak方法进行内存分析。最终用到

eclipse mat 进行分析，打印内存泄露的路径