1、触发条件
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调用情况.
出现ANR的一般有以下几种类型:
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
2、原因以及如何避免
- CPU满负荷,I/O阻塞
解决办法:文件读写或数据库操作放在子线程异步操作
- 主线程阻塞或主线程数据读取
解决办法:避免死锁的出现,使用子线程来处理耗时操作或阻塞任务
3、ANR分析办法
3.1 看Log
搜索关键字“Wrote stack traces to '/data/anr/traces.txt'”,在这附近产看anr的原因
如“WaitingInMainSignalCatcherLoop”,主线程等待超时
3.2 traces.txt ,使用adb命令把这个文件从手机里导出来
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的可能性不大,但是具体是不是还需要进一步分析