Android LeakCanary
sunbinkang 人气:0场景:最新的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就不会通知泄露点了。
加载全部内容