LeakCanary 源码详解（1）

leakcanary-android-sample 使用示例
leakcanary-object-watcher-android 自动注册
leakcanary-object-watcher-android-core 各种Watcher 的实现。
先总体说一下原理，有个大致框架了解，看完后可以回过头再看看这段话：通过监听Activity的onDestory，手动调用GC，然后通过ReferenceQueue+WeakReference（利用weakReference表示弱引用，其实就是包装了一个强引用，GC的时候，这个被包装的强引用能被释放掉。如果有ReferenceQueue的话，在释放的时候就把这个Reference放到ReferenceQueue里面），来判断Activity对象是否被回收，然后结合dump Heap的hpof文件，以前是通过Haha开源库分析泄露的位置，现在是用了shark库，但库的作用是一样的，都是用来解析hprof文件，定位内存泄漏发生的位置。
LeakCanary 是怎么完成自动注册的，不需要添加任何初始化注入代码？
是利用android系统的app的启动流程中先启动contentProvider 然后是Application的oncreate方法。所以注册代码在LeakCanary的一个contentProvider中。
插播一个，如果有人遇到无法运行sample模块的，准确说是提示安装成功，但设备上不显示无任何反应，找不到sample app。
我来回切换这个选项再安装就可以了，切换成nothing 然后再切换回来default apk就可以了

然后我们再提出一个问题，内存泄露是怎么检测到的？这也是LeakCanary的核心原理了。
在AppWatcher的manalinstall方法中 调用了很多Watcher的install方法，我们看其中的一个ActiivityWatcher ,监测Activity，里面的实现很简单，看图例1 在install方法的时候注入lifeCycleCallback回调,这样就能在activity destory的时候回调ActivityLifecyclerCallbacks的onActivityDestoryed方法，这就到图例2中在这个回调方法中ActivityWatcher 做了什么，调用了 reachabilityWatcher.expectWeaklyReachable方法，

点进去你会发现是个接口方法
它的实现，正是ObjectWatcher.看它是怎么传递进ActivityWatcher的，会在AppWatcher里面给ActivityWatcher传递参数objectWatcher
我们再看一下，这个对象是什么，是ObjectWatcher。

看一下这个对象是怎么实现的，画的部分应该就是核心代码了，也是最容易误解的地方，下一篇分析吧
待续。。。
下一篇：LeakCanary源码详解(2)