接入LeakCanary检测内存泄露

接入LeakCanary检测内存泄露

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

原来我们看到一个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,也可以方便定位出泄露的原因。

Mark Zhai (翟一帆) wechat
欢迎您扫一扫上面的微信公众号,订阅我们的公众号!
坚持原创技术分享,您的支持将鼓励我继续创作!