一、前言

我看到过有些教程说是直接在data/anr/traces.txt可以找到ANR日志，但是这个方法其实可以说是过时的了，我在AS上使用Device File Explorer查看虚拟机的文件目录，也没有找出来traces.txt这么一个文件。所以，本篇文章讲的是目前依然有用的方式–使用adb命令。

二、操作步骤

2.1 配置adb环境变量

需要先找到Android Studio的SDK存放的目录，因为本人没有修改过SDK存放目录，所以我的目录为
C:\Users\Administrator\AppData\Local\Android\Sdk\platform-tools

先复制C:\Users\Administrator\AppData\Local\Android\Sdk\platform-tools这个路径，然后在桌面上右键“此电脑”->属性->高级系统设置->环境变量

接着编辑系统变量“Path”，如下图：

然后点击右上角的“新建”，将刚才复制的sdk存放路径粘贴、保存即可，如下图：

2.2 使用adb命令

配置保存好了环境变量之后，按下Window+R，输入cmd，如下图：

点确定之后就打开了一个黑色命令窗口，输入adb，可以看到Android Debug Bridge的版本，如下图：

然后，输入adb bugreport anrlog.zip命令，如下图，

当然，需要打开Android Studio上的虚拟机，或者使用你的真机连接电脑（连接一台设备即可，不然会报错）。注意打开手机的开发人员选项，开启USB调试即可（至于怎么开启USB调试模式，大概的操作就是在手机系统的设置里，不停地点击版本号，具体操作相信你也知道，不知道的可自行百度）。
等进度跑完了之后，会生成anrlog.zip这个文件，我的是位于C:\Users\Administrator目录下，如下图

然后将这个压缩文件解压，会生成如下图的一堆文件：

这个占用空间较大的bugreport-sdk_gphone_x86-RSR1.201013.001-2022-10-17-22-11-49.txt，就是我们要分析的文件，使用Notepad++打开它（当然你也可以使用其他应用打开），然后搜索VM TRACES AT LAST ANR，如下图：

上面显示出了最近一次ANR发生的时间，我们再继续往下翻一点，如下图：

看吧，到这里连Activity的名称还有导致ANR对应代码的行数都显示出来了，你应该知道怎么做才能修复ANR了吧。
这个ANR是我故意制造的，就是使用线程池的时候，指定的“拒绝策略”为CallerRunsPolicy，指定这种拒绝策略，线程池在拒绝任务的时候，会直接把这个任务给打回去，这个任务是在主线程提交的，自然打回给主线程了。主线程是不能执行耗时任务的，超过了5秒，事件没有得到及时分发，就会出现ANR。要解决我这个ANR，使用其他拒绝策略即可，例如DiscardPolicy，这种拒绝策略是直接将新来的任务丢弃掉了，不会打回给主线程执行，自然就不会出现ANR。当然，想要深度学习线程池，还得阅读其他资料，这里就不再细说了。