稳定性问题探讨 1-ANR问题分析的几个点

书接前文
稳定性问题探讨-说明

引言

开发过程中，经常遇到这种情况，有兄弟说，哥给咋讲讲 anr问题怎么搞。我说官方有介绍(google官方关于anr的介绍)，还有文档，大家好好看一下，很简单的。就有兄弟会说，你就告诉一下简单的办法怎么定位，我又不是搞系统的。好吧，本文写点简单定位方法。但是话说回来，任何技术问题，要完整彻底解决，还是需要搞清楚来龙去脉，真正原理。所以建议大家不要偷懒，深挖现象背后的原因。

ANR产生后生成的线索文件

ANR机制本身就是为了防止差的用户体检，是完全android系统工程师为大家埋下的雷。这个雷既然是工程师设计的，那就可以被工程师控制，比如像我们通常说按键5s内时间处理不完的anr，这个5s在一些低端手机上被修改为8s甚至10s。还有就是ANR产生后，相关的“现场”是会被保留下来。比如出现ANR的时候生成的trace文件。比如在events log、main log、system log上有相关的ANR信息。bugreport中也有一些有用的信息，帮我们分析ANR产生的原因。

各个平台厂商不同，会在ANR的时候生成的“线索”有所不同。这里给大家先列一下，比较有用的几给文件：

1. trace 这是google官方给建议的anr现场文件路径在设备中 /data/anr/traces.txt
2. events log 里面有比较清晰的系统消息信息，分析events log可以比较快的确定问题发生窗口；代码中以 EventLog.writeEvent 打印 可以用命令 logcat -b events 抓取
3. main log 每个进程自己的log信息的打印 可以用命令 logcat -b main 抓取
4. system log 系统log的打印 以Slog打印 可以用命令 logcat -b system 抓取
5. radio log telephony bt wifi 相关的log打印出来 可以用命令 logcat -b radio 抓取
6. kernel log 底层kernel log 命令 dmesg 或者 cat /proc/kmsg抓取
7. bugreport 里面包含进程信息 event main system radio kernel 的log 信息比较全，google提case就是需要提供 bugreport 可以用 adb bugreport 抓取
8. tomestone native crash会生成tomestone 路径在 /data/tombstones
9. dropbox java层crash生成dropbox 路径在 /data/system/dropbox
10. screencap anr时候的截图，有些平台有，有些没有。

通过trace文件定位ANR的问题

ANR例子
写了给例子在github上通过例子，通过分析trace定位ANR原因

写了最常见的3种anr的例子，代码见github https://github.com/wangpengjie/AnrDemo/。

任何例子，点2下都会出现ANR提示

1. 如上说从adb pull /data/anr/trace.txt取出 trace文件
2. trace文件最顶端会有发生问题的时间点 和进程号 以及进程名。
   
3. 确保进程名 和进程 id 进程时间是我们要调查的，如果不一直那就很难有说服里。
   比如说从events log看我们有8次anr，当前拿到的trace是10:46:25的信息。所以这次调查分析只针对10:46:25的pid为14643的com.wangpengjie.anrdemo进程，这是整个分析的前提。
   
4. 只分析主线程
   
5. 分析本进程其它线程的相同的锁的地方
   
6. 结合代码找到问题点
   

如果没有trace文件怎样定位ANR

有trace的anr是比较好分析的，但实际开发过程中总会遇到log不全，没有trace的情况，没有trace就没法分析了吗？有如下方法可以试试。

1. events log中找到关键字 am_anr,定位anr问题，时间点和进程号是两个重要线索，怎么很快的定位到anr发生的时间点呢？event log信息简洁集中通过搜索am_anr快速定位到第一次发生anr的时间点。找到发生anr的进程号 和进程名称
   进程 pid 14643
   进程名称 com.wangpengjie.anrdemo
   发生时间点 10:42:07.378
   07-21 10:42:07.378 1614 1628 I am_anr : [0,14643,com.wangpengjie.anrdemo,9
   

2. 得到时间点 进程号后再看 main log找那个时间窗口的关键log打印比如
   main log中会打出进程明显的持锁信息(通常会打印anr进程自己打出的警告以上级别的log)
   

3. System log中的 ANR in
   ANR in 中的信息是刚学会分析ANR 问题的“法宝”。用的最多的是cpu占用过高。一看到cpu超过60%，心中一丝窃喜，直接帅锅给系统。这种做法不可取哦。！
   
   现在好多平台cpu都是多核，cpu达到100%都不能说明就是系统卡顿导致的anr。
   还要说明，系统ANR in 往往比event log中的am_anr会慢很多。具体慢多少需要根据场景而定，所以建议以event log中的am_anr作为时间窗口起点比较好。
   那ANR in 能看到哪些信息呢?
   Reason: ANR 原因，这个在evnent log中也可以看到作用不大。原因可以定位anr的时间窗口，比如按键类型的anr那分析的时候只需要在event log的am_anr 之前5s的时间窗口中分析就行。
   Load: 0.06 / 0.05 / 0.05 cpu负载，这个可以看到是否是系统性能整体慢的参考指标。但是各个平台这个参数又不统一。所以参考价值不大。
   TOTAL: 这个是整体cpu占用情况如果能够看到kernel占用比较多，可以考虑是否是系统问题

4. 那如何证明系统卡顿导致的anr呢？
   如果真实系统引起的卡顿在event log中搜索dvm_lock_sample，往往系统卡顿的时候
   dvm_lock_sample会打印出系统主线程的一些主要方法耗费了多少时间。
   dvm_lock_sample: [system_server,1,Binder:1614_A,22,AlarmManagerService.java,1072,-,2496,4]
   进程名,是否主线程1是0否,线程号,花费时间,文件名,申请锁行数，持锁文件名，持锁行数,采样频率