Android中的LeakCanary的原理详解
时间：2022-09-12 10:16:44 | 栏目：Android代码 | 点击：次
场景：最新的leakCanary2.8.1：
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.8.1'
原理：首先就是我们在引入最新的依赖包，什么都不用干了，因为他的初始化在清单文件中注册了contentProvider（），把初始化放到了这里面的onCreate（）去初始化了，在初始化的过程中，他会用application监听观察对象activity、fragment等对象的生命周期的变化，当执行销毁的生命周期，他就会用对应ActivityWatch--->ObjectWatch来观察你这个销毁的对象，那怎么观察呢？将对象加入到弱引用对象，并把这个弱引用和一个引用队列Queue来绑定（同时把这个弱引用先添加到一个map的观察列表），这样的话当主动Gc的时候，如果没有泄露，就会回收这个activity观察对象，并会把这个弱引用加入到引用队列中去，我们就可以去判断这个引用队列有没有值，有就代表没泄露，否则为queue.poll()取出来为null就泄露了，最后会把这个泄露对象的弱引用添加到一个set集合，叫做retained objects，最终会使用shark库（原来是haha分析库）去查询泄露的地方生成Dump文件，把分析结果发通知给开发者。
通知点击：告知retained objects---点击-->Dumping Heap---自动-->Analyzing heap
如何看这个分析的结果：
上面两个图就是这个泄露对象的引用链关系，最后就是存在泄露的对象LoginActivity，那为什么泄露就得往上去寻找，发现是在Dialog单例中持有了context（即LoginActivity对象），及时走了destory也不会销毁这个对象，因为被GcRoot一直持有。
这是引起内存泄漏的代码：
object LoadingDialog {
//内部生成的时候，根据INSTANCE 看起来感觉是静态，因为可以LoadingDialog.show()
//其实是伪静态
fun show() {
}
//这种写法才是静态方法
@JvmStatic
fun show2() {
}
private var dialog:Dialog?=null
fun show(context: Context) {
cancel()
dialog = Dialog(context)
dialog?.setContentView(R.layout.dialog_loading)
dialog?.setCancelable(false)
dialog?.setCanceledOnTouchOutside(false)
dialog?.show()
}
fun cancel() {
dialog?.dismiss()
}
}
解决就是，把dialog用完要置为null
fun cancel() {
dialog?.dismiss()
dialog = null;
}
这样leakCanary就不会通知泄露点了。