- 结合应用日志,代码或源码等,分析ANR问题发生前,应用是否有异常,其中具体问题具体分析。
2.2 导出ANR日志
ANR问题发生时,系统会收集ANR相关的日志信息,CPU使用情况,trace日志也就是各线程执行情况等信息,生成一个traces.txt的文件并且放在/data/anr/路径下。
注意:每一次新的ANR问题的发生,会把之前的ANR信息覆盖掉。
我们可以通过adb命令将traces文件导出到本地。
adb root
adb shell ls /data/anr
adb pull /data/anr/
2.3 读取关键日志信息
1)在log中找到ANR发生信息:
Traces文件中的关键字,例如:
09-24 15:20:20.211 1001 1543 1570 XXXXXXX: ANR in xxxxxx
09-24 15:20:20.211 1001 1543 1570 XXXXXXX: PID: xxxxx
09-24 15:20:20.211 1001 1543 1570 XXXXXXX: Reason: xxxxxx
其中:
-
ANR in中,包括导致ANR的包名,类名
-
PID 中,为发生ANR的进程PID
-
Reason 中,为导致ANR的原因,例如keyDispatchingTimedOut
2)找到CPU Usage信息
09-24 15:20:20.211 1001 1543 1570 XXXXXX: CPUusage from xxx to xxx ago xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
09-24 15:20:20.211 1001 1543 1570 XXXXXX: CPUusage from xxx to xxx later xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
其中
-
ago 表示ANR发生前的CPU的使用情况
-
later表示ANR发生后的CPU的使用情况
-
重点关注xxx%TOTAL: xxx% user + xxx% kernel + xxx% iowait,可通过这几项了解到CPU的占用情况。
2.4 具体分析
分析CPU usage以后,如若还是无法找出问题原因,则需要进一步分析trace文件。traces文件中详细记录了发生ANR前后该进程的各个线程的Stack,一般从主线程的stack入手分析,查看分析ANR问题发生前,应用是否有异常。
其中不同场景下的ANR问题情况不大相同,需要具体情况具体分析,此处就不展开详细描述。
3、ANR问题难点及破题思路
3.1 ANR难点
用户在应用内的绝大部分操作,比如按钮点击,加载资源,页面跳转等操作,都需要有App的主动反馈,但ANR发生时,在用户等待数秒后ÿ