本文主要是介绍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() {}//这种写法才是静态方法@JvmStaticfun show2() {}private var dialog:Dialog?=nullfun 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的原理分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
