接入LeakCanary检测内存泄露

接入LeakCanary检测内存泄露

前几天square在Github上发布了他们的内存泄漏检测库，LeakCanary，短短几天star已经接近3000，研究了一下后，发现其对QZone也很有价值。

原来我们看到一个toast弹出内存泄露，但是也看不出什么相关信息，所以只能直接忽略。一个内存泄露既需要测试同学dump HPROF再用MAT和Finder分析提单，开发同学接到单后又要在去分析HPROF看是哪里HOLD住了对象导致内存泄露，对之前没接触过这方面工作的人还是需要一定学习成本，且比较浪费时间成本。很多潜在的问题可能没有覆盖到，而一直藏在那里消耗内存。

通过LeakCanary，我们可以降低测试和修复成本，并发现更多的潜在内存泄露。

这里不多介绍接入细节，我们简单看下原理和效果。

【原理】

LeakCanary通过square自家的HAHA来自动化分析Android heap dumps，内部基于MAT, vshor/mat，AndroMAT来做Java和Android特定的heap分析，亮点则是其将需要人工分析的事情做到了完全自动化，并给出能帮助快速定位修复内存泄露的信息。

在Application中使用LeakCanary.install(this)后，LeakCanary就会自动install一个ActivityRefWatcher来自动化检测activity是否在onDestroy后有泄露。具体步骤大致是

1. 自动把activity加入到KeyedWeakReference

2. 在background线程中，检查onDestroy后reference是否被清除，且没有触发gc

3. 如果reference没有被清除，则dump heap到一个hprof文件并保存到app文件系统中

4. 在一个单独进程中启动HeapAnalyzerService，HeapAnalyzer使用HAHA来分析heap dump。

5. HeapAnalyzer在heap dump中根据reference key找到KeyedWeakReference。

6. HeapAnalyzer计算出到GC Roots的最短强引用路径来判断是否存在泄露，然后build出造成这个泄露的引用链。

7. 结果被传回来app进程的DisplayLeakService，并展示一个泄露的notification。

square称从用了LeakCanary后，发现并修复了很多他们app中的内存泄露，而且找到了一些Android SDK中的泄露，最终减少了94%因为OOM错误导致的crash。

【可深入的点】

由于该工具是基于Activity、Fragment的onDestroy触发的，且有些泄露并不是必现的，所以考虑可以基于自动化测试来做完整的覆盖，并批量输出内存泄露的信息，借助其输出的log，也可以方便定位出泄露的原因。