LeakCanary–原理及应用
一、简介
1.1 名字由来
LeakCanary ,直译为泄露的金丝雀,名称来源于一个关于金丝雀的故事。在17世纪的英国,煤矿业还没发展出检测瓦斯泄露探测仪,于是矿工们在下矿井时就带一只金丝雀。金丝雀对瓦斯及其敏感,稍微有瓦斯泄漏,它就会停止歌唱,浓度再高一些,金丝雀就会直接中毒身亡。而这时候,人比他皮糙肉厚一些,人类迟钝的感觉是完全没有意识到瓦斯的存在的。如果此时再不及时逃出矿坑,那么死的就是矿工了,正式借用了这层寓意,才起了LeakCanary这个名字,正如这个组件的功能一样,这个组件意在像检测瓦斯泄露的金丝雀一样,在危险发生之前,提前的检测内存泄露。
1.2 功能简介
LeakCanary是一个专门针对于Android的 内存泄露检测的库,LeakCanary通过对Android框架内部知识的了解,监听Activity与fragment的生命周期,实现对Activity,Fragment,Fragment View和ViewModel实例的内存泄露的监控,被监控的对象,在垃圾回收的5秒后没有回收掉的话,这个对象就会被认为是被保留了,和潜在内存泄露的
1.3 发展史
起始版本,仅Activity的监控
1.6.1 版本,加入了对Fragment的监控
1.6.2版本,加入了对Fragment view的监控
2.2版本,加入了对ViewModel的监控
正如功能简介中描述的一样,LeakCanary通过对Android框架内部知识的了解,来实现的泄露监控,从发展史上我们也能看到,随着对android代码了解的加深,其检测能力,也逐渐丰富
1.4 官网网址
https://square.github.io/leakcanary/fundamentals/
二、接入方式
2.1 接入:
dependencies {
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.3'
}
2.2 验证接入是否成功:
通过Logcat 查看 输出打印 D LeakCanary: LeakCanary is running and ready to detect leaks
三、检测与分析
3.1、检测
当按照接入方式接入成后,正常操作APP即可,当有内存泄露发生时,会在在桌面生成内存泄露的图标,点击进入后可以查看相关的堆栈信息
3.2、分析
1.读懂泄露的信息
├─ :表示一个java对象
│ ↓ :下面一行的对象的一个实例被对当前行的对象引用
**╰→:**表示泄露的对象
2.读取顺序,从泄露的位置向前读
3.3、举例:
具体实例
四、运作原理
1、源码解读:
阅读源码前,请思考几个问题:
它是如何做到仅一行配置代码就完成监控的
它是在什么时机,去判断是否存在内存泄露的
它是通过什么原理,来判断是否存在内存泄露的
2、总结:
它是如何做到仅一行配置代码就完成监控的
1.ContentProvider的onCreate的调用时机是在application onCreate之前调用的,即在应用启动时,完成了自身代码的调用,降低了接入方在java代码层面上的接入成本
2.通过占位符的方式,简化了接入方在manifest文件上的接入成本
3.debugImplementation 仅在debug模式下生效,降低了使用implementation时需要依赖空包的接入成
它是在什么时机,去判断是否存在内存泄露的
1.Activity:通过在Application中注册registerActivityLifecycleCallbacks绑定Activity生命周期回调,并在onActivityDestroyed回调中监控Activity
2.Fragment:通过在Application中注册registerActivityLifecycleCallbacks绑定Activity生命周期回调,并在onActivityCreated回调中,通过在Activity中注册注册FragmentLifecycleCallbacks回调,并在onFragmentDestroyed回调时,监控fragment
3.Fragment View:通过在Application中注册registerActivityLifecycleCallbacks绑定Activity生命周期回调,并在onActivityCreated回调中,通过在Activity中注册注册FragmentLifecycleCallbacks回调,并在onFragmentViewDestroyed回调中监控Fragment View
4.ViewModel:针对AndroidX库中的Activity,对于Activit,在onActivityCreated回调中注册监听,对于Fragment,在onFragmentCreated回调中注册监听,,,在ViewModel的onCleared回调中监控ViewModel
它是通过什么原理,来判断是否存在内存泄露的
是利用了WeakRefrence + RefrenceQueue的机制(仅被弱引用持有的对象,当对象被回收时,会存入到引用队列中),从引用队列中不断的获取对象,将已确认被GC的对象剔除,剩余未被回收的对象则定义为可能泄露的对象,当达到一定的判断条件时,通知用户内存泄露
五、个人理解
AppWatcher.objectWatcher.watch(myDetachedView, “View was detached”)
阅读完源码,说下个人对下面这个方法的理解。android是在不断发展完善的,就像viewmodel一样,是新增的检测类型,这个方法的作用,就是当我们自定义了一些存在生命周期的东西时,在改对象生命周期结束的时候,可以手动的调用这个方法,来监控自定义对象的生命周期