Android的LeakCanary的原理分析

场景：最新的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就不会通知泄露点了。

Android的LeakCanary的原理分析

猜你喜欢