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的原理详解的文章就介绍到这了,更多相关android leakcanary内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！