场景：最新的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内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！