前言

相比于发生应用程序崩溃，发生ANR更加让人头大，主要原因是崩溃发生的时候会在Logcat中打印出发生异常的位置，开发人员很容易就能定位到崩溃并解决，显然ANR没那么轻松；但是我们大可不必这么忧伤，因为有问题就会有解决办法，解决不了，只是因为没有用对方法

1. 导出ANR日志信息，根据日志信息，判断确认发生ANR的包名类名，进程号，发生时间，导致ANR原因类型等。
2. 关注系统资源信息，包括ANR发生前后的CPU，内存，IO等系统资源的使用情况。
3. 查看主线程状态，关注主线程是否存在耗时、死锁、等锁等问题，判断该ANR是App导致还是系统导致的。
4. 结合应用日志，代码或源码等，分析ANR问题发生前，应用是否有异常，其中具体问题具体分析。

导出ANR日志

ANR问题发生时，系统会收集ANR相关的日志信息，CPU使用情况，trace日志也就是各线程执行情况等信息，生成一个traces.txt的文件并且放在/data/anr/路径下。

注意：每一次新的ANR问题的发生，会把之前的ANR信息覆盖掉。

我们可以通过adb命令将traces文件导出到本地。

adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>

读取关键日志信息

1）在log中找到ANR发生信息： Traces文件中的关键字，例如：

09-24 15:20:20.211 1001 1543 1570 XXXXXXX： ANR in xxxxxx