您的位置:首页 > 其它

LeakCanary 原理浅析

2017-11-26 15:53 330 查看


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详解引用泳道图

 规划
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: