大概可以分为以下几步：
((1) 监测Activity 的生命周期的 onDestroy() 的调用。
(2) 当某个 Activity 的 onDestroy() 调用后，便对这个 activity 创建一个带 ReferenceQueue 的弱引用，并且给这个弱引用创建了一个 key 保存在 Set集合 中。
(3) 如果这个 activity 可以被回收，那么弱引用就会被添加到 ReferenceQueue 中。
(4) 等待主线程进入 idle(即空闲)后，通过一次遍历，在 ReferenceQueue 中的弱引用所对应的 key 将从 retainedKeys 中移除，说明其没有内存泄漏。
(5) 如果 activity 没有被回收，先强制进行一次 gc，再来检查，如果 key 还存在 retainedKeys 中，说明 activity 不可回收，同时也说明了出现了内存泄漏。
(6) 发生内存泄露之后，dump内存快照，分析 hprof 文件，找到泄露路径（使用 haha 库分析），发送到通知栏
LeakCanary对于内存泄漏的检测非常有效，但也并不是所有的内存泄漏都能检测出来。
<1>无法检测出Service中的内存泄漏问题
<2>如果最底层的MainActivity一直未走onDestroy生命周期(它在Activity栈的最底层)，无法检测出它的调用栈的内存泄漏。
所以说LeakCanary针对Activity/Fragment的内存泄漏检测非常好用，但是对于以上检测不到的情况，还得配合Android Monitor + MAT 来分析。