导致ANR的几种情况

KeyDispatchTimeout（5s）：按键或触摸事件在特定时间内无法处理完成
BroadcastTimeout（前台10s，后台60s）：广播在特定时间内无法处理完成
ServiceTimeout（前台20S，200S后台）：服务在特定的时间无法处理完成另外还有ProviderTimeout看门狗和等导致的ANR

常见的原因

A.耗时操作，如复杂的layout，庞大的for循环，IO等。
B.被Binder 对端block
C.被子线程同步锁block
D.Binder被占满导致主线程无法和SystemServer通信
E.得不到系统资源（CPU/RAM/IO）
其中ABCD比较好分析，而E比较困难。

应用ANR产生的时候，ActivityManagerService的appNotResponding方法就会被调用，然后在文件中写入/data/anr/traces.txt ANR相关信息。

通常发生了ANR，ActivityManager会打印报错信息：

日志分析：

ANR日志打印了的基本信息，我们可以分析CPU使用率得知ANR的简单情况;如果CPU使用率很高，100％接近，可能在进行大规模的计算更可能的英文陷入死循环;如果使用CUP率很低，说明主线程被阻塞了，并且当IOWAIT很高，可能是主线程在等待I / O操作的完成。
对于ANR只是分析日志很难知道问题所在，我们还需要通过跟踪文件分析栈调用情况。

traces.txt是如何生成的

当APP（APP包括系统和用户APP）进程出现ANR，应用响应慢或看门狗的监视没有得到回馈时，系统会倾倒此时的进程之上，线程进程中的运行状态就都到这个跟踪转储文件中了。每次发生ANR，这个文件都会被清空，写入新的内容。如果想查看以前发生ANR的信息，可以去查看文件DB。

DropBox中的日志

traces.txt只保留最后一次发生时的信息ANR的Android 2.2开始增加了功能的Dropbox，保留历史上发生的所有的ANR日志。
“/数据/系统/保管箱” DB是指定的文件存放位置。
天3日志保存的最长时间