LeakCanary 2 源码解析（一）为什么2.0不再需要在A

问题1：为什么2.0不再需要在Application中手动初始化？：

大家可能在升级到2.0的时候注意到——官网的开始指南发生了变化⬇

image.png
2.0版本只需要添加debug依赖就可以完成接入了
（what？1.0的时候不是还要在Application里onCreate方法中完成初始化吗？）

如何实现的呢？

首先，让我们在leakcanary的官方git仓库中，
找到官方说明中提示直接依赖的leakcanary-android文件夹，
打开之后，发现里面什么都没有，
发现里面只是做一个依赖。

leakcanary-android的build.gradle

让我们跟着指示打开leakcanary-android-core文件夹，
然而这个文件夹中也并没有与初始化相关的东西。
在core的build.gradle中，我们发现了

leakcanary-android-core的build.gradle

让我们继续打开leakcanary-object-watcher-android文件夹，
在其清单文件中，我们发现注册了一个provider

leakcanary-object-watcher-android的清单文件

我们知道写在application标签下中的provider会在app进程启动的时候自动注册。
那么在这个provider中干了什么事呢？让我们进去AppWatcherInstaller看看

AppWatcherInstaller.kt

ok，在provider的onCreate方法中我们终于找到了初始化的第一步
InternalAppWatcher.install(application)

image.png

与初始化相关的就是ActivityDestroyWatcher和FragmentDestroyWatcher的install方法

让我们先看ActivityDestroyWatcher的install

image.png

ok，到这里和leakcanary2.0之前的初始化方法一样了， 都是注册监听了application的ActivityLifecycleCallback。

总结

ok，让我们回到一开始的问题。
1，由于我们添加了LeakCanary2的依赖，而在他依赖的leakcanary-object-watcher-android工程中，注册了一个provider。
2，当app进程启动的时候，会自动创建注册这个provider，并执行其中的onCreate方法。
3，在这个onCreate方法中，调用了LeakCanary的install方法，创建各自的watcher，并注册监听了application的ActivityLifecycleCallback。