免初始化:
一行就能搞定
dependencies {
// debugImplementation because LeakCanary should only run in debug builds.
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.7'
}
ContentProvider
在经过对源码的阅读后，发现其实人家是基于CP这个对于绝大数开发来说，基本没用到的四大组件之一来做的，真的是服了哈哈。查看他的leakcanary-leaksentry 模块的AndroidManifest.xml文件，可以看到下面的内容：
<?xml version="1.0" encoding="utf-8"?>
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.squareup.leakcanary.leaksentry"
>
<application>
<provider
android:name="leakcanary.internal.LeakSentryInstaller"
android:authorities="${applicationId}.leak-sentry-installer"
android:exported="false"/>
</application>
</manifest>
接着我们去看下那LeakSentryInstaller这个类到底做了什么。
internal class LeakSentryInstaller : ContentProvider() {
override fun onCreate(): Boolean {
CanaryLog.logger = DefaultCanaryLog()
val application = context!!.applicationContext as Application
InternalLeakSentry.install(application)
//骚操作在这里，利用系统自动调用CP的onCreate方法来做初始化
return true
}
override fun query(
uri: Uri,
strings: Array<String>?,
s: String?,
strings1: Array<String>?,
s1: String?
): Cursor? {
return null
}
override fun getType(uri: Uri): String? {
return null
}
override fun insert(
uri: Uri,
contentValues: ContentValues?
): Uri? {
return null
}
override fun delete(
uri: Uri,
s: String?,
strings: Array<String>?
): Int {
return 0
}
override fun update(
uri: Uri,
contentValues: ContentValues?,
s: String?,
strings: Array<String>?
): Int {
return 0
}
}
我们看到这个CP类，没做任何的CURD操作，全是空的，就纯粹利用系统会回调这个接口来做初始化，帮助开发偷懒，省去调用写初始化逻辑。
个人看待这个，觉得得分两部门 好处：确实带来了 "免侵入",不需要业务人员写任何代码。一般启动的顺序是 Application->attachBaseContext =====>ContentProvider->onCreate =====>Application->onCreate =====>Activity->onCreate 所以对于大多数场景，写在CP的初始化的实际是足够优先了！！
LeakCanary原理
(1) 监测Activity 的生命周期的 onDestroy() 的调用。
(2) 当某个 Activity 的 onDestroy() 调用后，便对这个 activity 创建一个带 ReferenceQueue 的弱引用，并且给这个弱引用创建了一个 key (uuid)保存在 Set集合 中。
(3) 如果这个 activity 可以被回收，那么弱引用就会被添加到 ReferenceQueue 中。
(4) 等待主线程进入 idle(即空闲)后，通过一次遍历，在 ReferenceQueue 中的弱引用所对应的 key 将从 retainedKeys 中移除，说明其没有内存泄漏。
(5) 如果 activity 没有被回收，先强制进行一次 gc，再来检查，如果 key 还存在 retainedKeys 中，说明 activity 不可回收，同时也说明了出现了内存泄漏。
(6) 发生内存泄露之后，dump内存快照，分析 hprof 文件，找到泄露路径（使用 haha 库分析），发送到通知栏
WeakReference类型的Activity与ReferenceQueque关联之后,WeakReference正常回收之后,引用会在ReferenceQueque:
LeakCanary的核心原理即使用ReferenceQueue对Activity进行监测。当Activity执行完onDestory后，就将Activity放入到WeakReference中。然后将这个WeakReference类型的Activity与ReferenceQueque关联，此时查看ReferenceQueque中是否有这个WeakReference对象。如果没有，则执行GC，再次查看，如果还没有则证明这个Activity发生了内存泄漏。然后用HaHa这个开源库去分析dump之后的heap内存。
ReferenceQueue
ReferenceQueue是一个链表结构的存储队列，节点是reference，节点之间通过next连接。ReferenceQueue的意义在于能够在外部对queue中的引用进行监控。当引用中的对象没回收后可以对引用对象本身继续做一些清理操作。使用ReferenceQueue结合弱引用（或者软引用）可以监测弱引用中的对象是否被回收。如果弱引用中的对象被回收，那么弱引用会被加入到这个关联的ReferenceQueue中。
// 引用队列
ReferenceQueue<Object> queue = new ReferenceQueue<>();
Object obj = new Object()
// 将queue与WeakReference关联
WeakReference weakRef = new WeakReference<Object>(obj,queue);
obj = null;
// 调用GC进行垃圾回收
System.gc();
// 从队列中取出 reference
//当reference被成功回收后，可以从queue中获取到该引用
Reference<?> reference = queue.remove();
if (reference != null){
System.out.println("对象已被回收: "+ reference.get()); // 对象为null
}
上述代码中将ReferenceQueue与WeakReference关联，如果WeakReference中的obj对象被回收了，那么WeakReference就会被加入到这个ReferenceQueue中。
因此，可以使用该方法来检测对象是否被回收。
Java 中的 WeakReference 是弱引用类型，每当发生 GC 时，它所持有的对象如果没有被其他强引用所持有，那么它所引用的对象就会被回收，同时或者稍后的时间这个 WeakReference 会被入队到 ReferenceQueue. LeakCanary 中对内存泄露的检测正是基于这个原理。
实现要点：
当一个 Object 需要被回收时，对应生成一个 key ，封装到自定义的 KeyedWeakReference 中，并且在 KeyedWeakReference 的构造器中传入自定义的 ReferenceQueue。
同时将这个 KeyedWeakReference 缓存一份到 Map 中（ ObjectWatcher.watchedObjects ）
最后主动触发 GC，遍历自定义 ReferenceQueue 中所有的记录，并根据获取的 KeyedWeakReference 里 key 的值，移除 Map 中相应的项。
「经过上面 3 步之后，还保留在 Map 中的就是：应当被 GC 回收，但是实际还保留在内存中的对象，也就是发生泄漏了的对象。」
