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 进行分析,打印内存泄露的路径