LeakCanary工作原理笔记

1.参考
（1）LeakCanary原理解析：https://blog.csdn.net/xiaohanluo/article/details/78196755
（2）https://github.com/square/leakcanary/wiki/FAQ#how-does-it-work
2. 理解笔记
（1）内存泄漏是指一个对象在该被回收的时候，未被回收。
（2）检测内存泄漏需要解决的问题是：
（a）监听到一个对象该被回收的时机
（b）在该被回收的时机判断是否被回收，若未被回收则内存泄漏。
3.LeakCanary的理解
（1）【监听】通过对Activity的Destroy注册监听，获取到Activity该被回收的时机
（2）【检测】通过对Activity的弱引用，在Activity的Destroy执行后，弱引用队列中是否有Activity判断是否发生内存泄漏，如果没有则可能存在泄漏；再手动进行一次gc，如果还是没有的话，则Activity内存泄漏。
[note:
1.弱引用会在GC的时候被回收.
2.WeakReference 创建时，可以传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束，一旦被 GC 检查到，GC 将会把该对象添加到 ReferenceQueue 中，待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue，它可能存在内存泄漏]
（3）【分析】拿待分析的Activity对象在heap堆信息中查找强引用关系，报出。
4.LeakCanary的局限，无法对Service的内存泄漏进行分析；对于一直不执行Destroy方法的Activity也无法分析内存泄漏。

5.关于弱引用参考:
https://blog.csdn.net/ly969434341/article/details/51518877