leackCanary:内存泄漏检测工具
blockCanary:ANR检测工具

leakCanary实现原理:
(1) 监测Activity 的生命周期的 onDestroy() 的调用。
(2) 当某个 Activity 的 onDestroy() 调用后，便对这个 activity 创建一个带 ReferenceQueue 的弱引用，并且给这个弱引用创建了一个 key 保存在 retainedKeys 中。
(3) 在 Android 的 Framework 中，当一个 Activity 被 destroy 后一般会产生一次 gc，并且还会产生一个 idle。
(4) 如果这个 activity 可以被回收，那么弱引用就会被添加到 ReferenceQueue 中。
(5) 等待主线程进入 idle后，通过一次遍历，在 ReferenceQueue 中的弱引用所对应的 key 将从 retainedKeys 中移除，说明其没有内存泄漏。
(6) 如果 activity 没有被回收，先强制进行一次 gc，再来检查，如果 key 还存在 retainedKeys 中，说明 activity 不可回收，同时也说明了出现了内存泄漏。

总结
(1) 从大的层面上来看，LeakCanary 的核心包括了用于监测内存泄漏的 leakcanary-watcher
以及用于分析 hprof 的 leakcanary-analyzer 两个大的模块。leakcanary-watcher 中的核心类是 RefWatcher ，而 leakcanary-analyzer 中的核心类是 HeapAnalyzer。对于应用开发者来说，掌握 leakcanary-watcher 的原理会更适用一些。
(2) leakcanary-watcher 监测内存的核心原理是，监测 Activity/Fragment 组件的生命周期，
组件在进入 onDestroy 后，一般的 framework 会主动 gc 一次，如果没有则还会强制 gc 一次。
同时，还利用了弱引用在一次 gc 后便会进入到内存回收的状态的原理从而判断当前被监测的组件是否发生了内存泄漏。
(3) leakcanary-analyzer 负责 hprof 的分析，这个模块其实只是对 haha 库的所提供的 api 的应用，
就像我们拿着 leakcanary 编写自己的业务代码一样。这里不作深入的分析，
而是放到下一篇 haha 库相关的文章里再来详细分析。

blockCanary:
因为UI更新界面都是在主线程中进行的，所以在主线程中做耗时操作可能会造成界面卡顿，而主线程的Looper早已经在APP启动的时候Android framework里面创建了main looper，那么一个线程对应一个Looper，Looper当中有一个MessageQueue，专门用来接收Handler发送过来的msg，并且在looper()方法中循环去从MessageQueue中去取msg，然后执行，而且是顺序执行的，那么前面一个msg还没处理完，loop()就会等待它处理完了才会再去执行下一个msg，如果前面一个msg处理很慢，那就会造成卡顿了，在msg.target.dispatchMessage(msg)前有：
if (logging != null) {
logging.println(“>>>>> Dispatching to “ + msg.target + “ “ +
msg.callback + “: “ + msg.what);
}

而在dispatchMessage执行完了之后，又有：
if (logging != null) {
logging.println(“<<<<< Finished to “ + msg.target + “ “ + msg.callback);
}

所以，我们只需要计算打印 这两天log的时间差，就能得到dispatchMessage的耗时，android提供了Looper.getMainLooper().setMessageLogging(Printer printer)来设置这个logging对象，所以只要自定义一个Printer，然后重写println(String x)方法即可实现耗时统计了，所以原理真的很简单