A.耗时操作，如复杂的layout，庞大的for循环，IO等。 B.被Binder 对端block C.被子线程同步锁block D.Binder被占满导致主线程无法和SystemServer通信 E.得不到系统资源（CPU/RAM/IO）
log打印了ANR的基本信息,我们可以分析CPU使用率得知ANR的简单情况;如果CPU使用率很高,接近100%,可能是在进行大规模的计算更可能是陷入死循环;如果CUP使用率很低,说明主线程被阻塞了,并且当IOwait很高,可能是主线程在等待I/O操作的完成.
对于ANR只是分析Log很难知道问题所在,我们还需要通过Trace文件分析stack调用情况.
1:KeyDispatchTimeout（常见）
input事件在`5S`内没有处理完成发生了ANR。
logcat日志关键字：`Input event dispatching timed out`
2:BroadcastTimeout
前台Broadcast：onReceiver在`10S`内没有处理完成发生ANR。
后台Broadcast：onReceiver在`60s`内没有处理完成发生ANR。
logcat日志关键字：`Timeout of broadcast BroadcastRecord`
3:ServiceTimeout
前台Service：`onCreate`，`onStart`，`onBind`等生命周期在`20s`内没有处理完成发生ANR。
后台Service：`onCreate`，`onStart`，`onBind`等生命周期在`200s`内没有处理完成发生ANR
logcat日志关键字：`Timeout executing service`
4：ContentProviderTimeout
ContentProvider 在`10S`内没有处理完成发生ANR。 logcat日志关键字：timeout publishing content providers
源码分析anr触发原理
2、原因以及如何避免- CPU满负荷，I/O阻塞
解决办法：文件读写或数据库操作放在子线程异步操作
- 主线程阻塞或主线程数据读取
解决办法：避免死锁的出现，使用子线程来处理耗时操作或阻塞任务
3、ANR分析办法 3.1 看Log
搜索关键字“Wrote stack traces to '/data/anr/traces.txt'”，在这附近产看anr的原因
如“WaitingInMainSignalCatcherLoop”，主线程等待超时
adb pull /data/anr/traces.txt
traces.txt默认会被导出到Android SDK的platform-tools目录 ，产生新的ANR，原来的 traces.txt 文件会被覆盖
3.3 Java线程调用分析jstack {pid}
3.4 DDMS分析ANR问题
使用DDMS的Update Threads工具可以分为如下几步
- 选择需要查看的进程
- 点击Update Threads按钮
- 在Threads视图查看该进程的所有线程状态
并不是trace文件包含的应用就一定是造成ANR的帮凶，应用出现在trace文件中，只能说明出现ANR的时候这个应用进程还活着，trace文件的顶部则是触发ANR的应用信息。因此，如果你的应用出现在了trace文件的顶部，那么很有可能是因为你的应用造成了ANR，否则是你的应用造成ANR的可能性不大，但是具体是不是还需要进一步分析
