稳定性问题探讨 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信息的打印 可以用命令 logc