LeakCanary2.0版本原理简单查看

这几天看了一下leakCanary2.0版本的源码，在这里做一下记录。
2.0版本使用kotlin重写的，使用起来也非常简单，省去了在Application中的注册，只需要在build.gradle文件中加入依赖

    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.0'

就可以了，代码上什么都不用写，完全做到了无感知操作。

那么代码上什么都不用写，不用注册它怎么来进行调用，进行内存监测呢？
答案就在AppWatcherInstaller这个类上，它继承了ContentProvider，属于四大金刚，啊 不，四大组件之一。contentProvider的特点就是不用显示调用初始化，在执行完application的初始化后就会调用contentProvider的onCreate()方法。正是利用这一点，leakcanary把注册写在了这里面，有系统自动调用完成，对开发者完全无感知。
初次看leakCananry源码，我分了两部分来看的：1、添加要观察的对象 2、对对象进行观察
第一部分，添加观察对象
在AppWatcherInstaller的onCreate中调用了InternalAppWatcher的install方法
1、检查是否是在主线程（不是的话抛出异常）
2、添加生命周期的回调，在执行onDestory的时候调用objectWatcher的watch方法，观察这个activity的对象是否回收掉了

     ActivityDestroyWatcher.install(application, objectWatcher, configProvider)
//注册fragment的watcher
    FragmentDestroyWatcher.install(application, objectWatcher, configProvider)

//ActivityDestroyWatcher里的部分代码,再执行onDestory的时候开始进行对象检测

    private val lifecycleCallbacks =
       object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
  override fun onActivityDestroyed(activity: Activity) {
    if (configProvider().watchActivities) {
      objectWatcher.watch(
          activity, "${activity::class.java.name} received Activity#onDestroy() callback"
      )
    }
  }
}

以上为注册流程。
第二部分就是检测对象的回收了
检测对象的回收 起始类是ObjectWatcher,顾名思义对象观察器。调用watch方法。ObjectWatcher.watch(watchedObject : Any,description : String)。watch方法里面做了如下操作：
在这个之前要先介绍一下，ObjectWatcher里面有两个集合分别是：
1） private val watchedObjects = mutableMapOf<String, KeyedWeakReference>() 这是一个map集合，用来存放要观察对象的key和弱引用,代码会为每个观察的对象生成一个唯一的key和弱应用
2）private val queue = ReferenceQueue()watchedObjects 这个队列和弱应用联合使用，当弱引用中的对象被回收后，这个弱引用会被放到这个队列中。换句话说就是只要存在这个队列中弱引用，就代表这个弱引用中所包含的对象被回收了。
下面开始watch方法里面的操作。
1、先移除watchedObjects 和queue 集合里面已经回收对象的弱引用。
2、通过uuid为当前观察的对象生成一个唯一的key,并把对象用弱应用包起来，放到watchedObjects 这个集合中，同时把queue 和弱应用关联起来。
3、checkRetainedExecutor.execute {moveToRetained(key) }这里是个延迟任务，延迟五秒后再次执行1操作，这个期间对象可能已经被回收了，所以需要再次移除一次
4、执行了3操作后，就可以通过watchedObjects 集合找到没有被回收的对象了。这时候就可以获取到没有被回收的对象的个数，大于0，进行一次gc操作（gc操作用的是Runtime.getRuntime() .gc()，源码上注释这个操作比system.gc()更可能触发gc操作）。

 var retainedReferenceCount = objectWatcher.retainedObjectCount
if (retainedReferenceCount > 0) {
  gcTrigger.runGc()
  retainedReferenceCount = objectWatcher.retainedObjectCount
}

5、再次获取未被回收的个数,这一步会有几个判断条件
1）如果个数小于5，不做操作等待5秒再次进行检查未回收的个数，一直循环，直到大于等于5个或者等于0个，为了防止频发回收堆造成卡顿。
2）大于5个后，如果处于debug模式，会再等20秒，再次执行4操作。防止debug模式会减慢回收
3）距离上次堆栈分析是否大于等于1分钟，如果没有超过一分钟，也需要再次延迟（1分钟-当前距离上次的时间）再次循环4操作

6、如果上面的条件都符合了，就可以开始进行堆栈的分析了
1）、获取到内容文件 Debug.dumpHprofData(heapDumpFile.absolutePath)
2）、objectWatcher.clearObjectsWatchedBefore(heapDumpUptimeMillis)该操作是去掉以前已经分析过的对象，也就是去除掉之前的没有回收掉的对象，不在本次分析范围内
3）、HeapAnalyzerService开启IntentService服务进行分析 具体分析就不写了，因为还没看懂
4）、把结果插入数据库（泄漏区分了应用本身的内存泄漏和类库的内存泄漏），并且发送通知