LeakCanary 的原理总结如下
-
监听 Activity 的生命周期
-
在 onDestroy 5s之后,创建相应的 Refrence 和 RefrenceQueue,并启动后台进程去检测
-
一段时间之后,从 RefrenceQueue 读取,若读取不到相应 activity 的 Refrence,有可能发生泄露了,这个时候,再促发 gc,一段时间之后,再去读取,若在从 RefrenceQueue 还是读取不到相应 activity 的 refrence,可以断定是发生内存泄露了
-
发生内存泄露之后,dump,分析 hprof 文件,找到泄露路径(使用 haha 库分析)
其中,比较重要的是如何确定是否发生内存泄露,而如何确定发生内存泄露最主要的原理是通过 Refrence 和 RefrenceQueue。悄悄地提醒你一下,面试必备。
Refrence 和 RefrenceQueue,以及set集合结合判断是否发生了内存泄漏
Activity Destory 5s之后,
1.将 activity引用加入set集合
2.创建该activity的弱引用,并制定WeakReferencequeue。(该弱引用被gc后,会自动加入到WeakReferencequeue中)
3.判断WeakReferencequeue中是否含有activity的弱引用,如果有将activity的弱引用从set集合中移除。如果没有证明有可能发生了泄漏。
4.执行gc, 再次判断WeakReferencequeue, 如果还是没有证明,set集合不会执行retainedKeys.remove(ref.key);, set集合中还是有activity的引用,证明发生了内存泄漏。
参考资料:
看完这篇 LeakCanary 原理分析,又可以虐面试官了!