LeakCanary 原理浅析

 

Terraria 关注

2016.12.30 13:47 字数 862 阅读 727评论 2喜欢 7

自顶向下，用图简化，不落代码陷阱，不入细节迷障。

Android 应用内存泄漏问题，一直是性能优化的重点。在不清楚内存泄漏的大致范围时，通过人为测试模拟重现或无目的地分析 heap dump等方法来检测，都太繁琐、耗时且定位不准。

什么是内存泄漏？

在 Java 世界中，一切对象都有生命周期，如同人的寿命。人死灯灭，入轮回，转世投胎。Java 对象的生命周期结束后，将被 GC 回收，原先占用的内存会有新的用途。但凡是总有例外，就如孙悟空可以修改生死谱长生不死，聂小倩能残存人间人鬼相恋。Java 对象有时也会”长死不死“，GC 拿它没有办法，这种情况就是内存泄漏。造成这种情况的原因是：Java 对象被另一个生命周期更长对象持有，具有 可达性 ，这并不是我们想要的。

问：有没有一种简单直接且能有效定位内存泄漏位置的方法呢？

答：有，那就是 LeakCanary 。我们可以简单地人为：将一个 App 作为输入，通过LeakCanary 检测后，就会得到内存泄漏位置结果（如果存在的话）。

LeakCanary

知其然知其所以然，LeakCanary 如此强大实用，那么：LeakCanary 是怎么实现的？

• Android 应用的整个生命周期由其组件的生命周期组成，如下图中所示。用户使用应用的过程中，在不同界面之间跳转，每个界面都经历着”生死“的转换，可在此建立检测点。Activity/Fragment 都有 onDestory() 回调方法， 进入此方法后，Activity/Fragment生命周期结束，应该被回收。

简述声明周期

• 然后我们需要解决：如何得到未被回收的对象。ReferenceQueue+WeakReference+手动调用 GC可实现这个需求。

  WeakReference 创建时的参数，传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束，一旦被 GC 检查到，GC 将会把该对象添加到 ReferenceQueue 中，待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue，它可能存在内存泄漏。

获得未被回收的 Object

• 找到了未被回收的对象，如何确认是否真的内存泄漏？这里可以将问题转换为：未被回收的对象，是否被其他对象引用？找出其最短引用链。VMDebug + HAHA 完成需求。

  VM 会有堆内各个对象的引用情况，并能以hprof文件导出。HAHA 是一个由 square 开源的 Android 堆分析库，分析 hprof 文件生成Snapshot对象。Snapshot用以查询对象的最短引用链。

解析hprof

• 找到最短引用链后，定位问题，排查代码将会事半功倍。

如下泳道图分析， LeakCanary 各个模块如何配合达到检测目的。

泳道图

泳道图源自参考链接

参考引用链接

LeakCanary

LeakCanary: Detect all memory leaks!

Wrangling Dalvik: Memory Management in Android

HAHA

Android Doc - How to analyze the heap dump

LeakCanary源码分析第二讲－RefWatcher详解引用泳道图

 规划