ANR的产生原因：
只有当UI线程响应超时才会引起ANR，超时产生原因一般有两种。
1.当前的事件没有机会得到处理，例如UI线程正在响应另一个事件，当前事件由于某种原因堵塞了。
2.当前的事件正在处理，但是由于耗时太长没能及时完成。
根据ANR产生的原因不同，超时时间也不同，从本质上讲，产生ANR的原因有三种，大致可以对应到Android中四大组件中的三个（Activity/View、BroadcastReceiver和service）
KeyDispatchTimeout
最常见的一种类型，原因是View的按键事件或者触摸事件在特定事件5秒内无法得到响应。
BroadcastTimeout
原因是BroadcastReceiver的onReceiver()运行在主线程中，在特定的时间内10秒无法完成处理。
ServiceTimeout
比较少出现的一种类型，原因是Service的各个生命周期函数在特定的时间20秒内无法完成处理
ANR的定位和分析：
在工作中难点在于大家不知道怎么定位，现在我告诉大家，如果大家项目中出现的ANR以后，那么大家可以结合Logcat日志和生成的位于手机内部存储的/data/anr/traces.txt文件进行定位和分析，仔细阅读日志会帮你定位到哪个类，哪一行代码。
ANR的避免与检测：
产生ARN的原因就是 ：主线程发生了耗时操作，堵塞了
下面我先介绍一下主线程中如何检测：
严格模式StrictMode 是Android SDK 提供的一个用来检测代码中是否存在违规操作的工具，主要检测两大类问题：
线程策略ThreadPolicy
detectCustomSlowCalls：检测自定义耗时操作。
detectDiskReads：检测是否存在磁盘读取操作。
detectDiskWrites：检测是否存在磁盘写入操作。
detectNetword：检测是否存在网络操作。
虚拟机策略：VmPolicy
detectActivityLeaks：检测是否存在Activity泄露
detectLeakedClosableObjects：检测是否存在未关闭的Closable对象泄露
detectLeadkedSqLiteObjects：检测是否存在Sqlite对象泄露
setClassInstanceLimit：检测类实例个数是否超过限制。
所以ThreadPolicy是用来检测可能存在的主线程耗时操作，解决这些检测到的问题，就能够减少应用ANR的概率。需要注意的是我们只能在Debug模式下使用它。在Application中初始化即可。
另一种方式主线程中的如何检测
BlockCanary是一个非侵入式的性能监控函数库，它的用法和leakCanary类似，只不过后者是控制内存泄漏的。而BlockCanary只要用来监控应用主线程的卡顿。它的基本原理是利用主线程的消息队列处理机制，通过对比消息分发开始和结束的时间点来判断是否超过设定的时间，如果是，则判断未主线程卡顿。
详细使用请看BlockCanary官网说明。
