注意:每一次新的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发生时,在用户等待数秒后,仅会弹出一个“应用无响应”的弹窗给用户,这会给用户带来“应用难用”的感觉,极其影响用户体验。
但是,现网中的ANR问题又很难处理,问题包括但不限于:
-
平时的测试难以覆盖,毕竟ANR经常出现在老设备、弱网络环境的场景下,测试难以做到全场景覆盖。
-
对于现网应用的ANR问题,如果问题非必现,则定位难度较高,需要有可以复现问题的实际设备在身边,才能