日常开发测试中，我们经常会遇到各种ANR问题，ANR的全称是application not responding，即应用程序无响应。

ANR产生的原因：

在Android中，一般情况下，四大组件均是工作在主线程中的，Android中的Activity Manager和Window Manager会随时监控应用程序的响应情况，如果因为一些耗时操作（网络请求或者IO操作）造成主线程阻塞一定时间（例如造成5s内不能响应用户事件或者BroadcastReceiver的onReceive方法执行时间超过10s），那么系统就会显示ANR对话框提示用户对应的应用处于无响应状态。

总结：

1. 只有主线程才会产生ANR，主线程就是UI线程；

2. 必须发生某些输入事件或特定操作，比如按键或触屏等输入事件，在BroadcastReceiver或Service的各个生命周期调用函数；

3. 主线程超过5秒没有将输入事件处理完毕；主线程在执行BroadcastReceiver的onReceive()函数时10秒内没有处理完毕；主线程在Service的各个生命周期函数时20秒内没有处理完毕；

4. 主线程执行了耗时操作，比如数据库操作或网络编程

5. 其他进程（就是其他程序）占用CPU导致本进程得不到CPU时间片，比如其他进程的频繁读写操作可能会导致这个问题。

发生ANR时系统的处理：

1.弹出一个对话框

2.将ANR信息输出到各个日志文件中

    当发生ANR时，会将ANR相关的信息，例如ANR产生的原因，CPU的状态统计信息，进程方法调用堆栈信息输出到各个日志文件中。通过分析这些日志文件，可以找出ANR发生的时间，以及ANR产生的原因。ANR日志信息记录在event.txt、main.txt、system.txt以及trace.txt文件中

    发生ANR时，对应的应用会收到SIGQUIT异常终止信号，dalvik虚拟机就会自动在/data/anr/目录下生成trace.txt文件，traces.txt文件是一个ANR记录文件，用于开发人员调试，目录位于/data/anr中，这个文件记录了在发生ANR时刻系统各个线程的执行状态，获取这个文件是不需要root权限的，下面的命令可以将traces.txt文件拷贝到当前目录下：

adb pull /data/anr

3.将ANR信息输出到Logcat

各种日志介绍：

event日志

　　在event日志中，通过查找am_anr关键字，查询ANR相关的日志信息，通过event日志，可以确定是否发生了ANR，以及发生ANR的应用程序，以及ANR发生的时间点。

main日志

    对于输入事件的ANR，可以在main日志里面查找InputDispatcher关键字，查看ANR发生的原因。搜索关键Log:am_anr,InputDispatcher，am_anr（通用的ANR第一时间点的Log，Input超时的时候有可能会有延迟）,InputDispatcher(当有Input超时的时后，该Log打印时间点是ANR第一发生的时间点)，

    am_anr log都是由 (User|1|5),(pid|1|5),(Package Name|3),(Flags|1|5),(reason|3)组成的，我们根据reason去分类ANR类型，然后根据不同的类型从am_anr开始点，往回看相应的timeout时间的Log，大致看一下timeout时间内，我们的应用，或者系统都在做什么。

其中的Reason信息可以给出ANR产生原因的一些详细信息，

·输入事件处理引起的ANR，提示信息格式为：“Inputdispatching timed out [anr reason]”

·Service处理引起的ANR，提示信息格式为：“Executingservice [Package name]/[Short class name]”

·Broadcast处理引起的ANR，提示信息格式为：“Broadcast of [Intent focused byBroadcast receiver]

system日志

        在system日志中，可以查找关键字ANR in关键字，查看ANR发生时的CPU的状态信息，以及ANR发生的原因，通过system日志，可以看到ANR发生时，CPU的使用情况，如果CPU使用量接近100%，说明当前设备很忙，有可能是CPU饥饿导致了ANR；如果CPU使用量很少，则说明主线程被阻塞了。

trace日志

    trace文件记录了在发生ANR时刻系统各个线程的执行状态。可以通过搜索Cmd line关键字，查找记录的进程包名。然后查看对应进程的方法调用堆栈，分析ANR发生时的方法调用信息。

trace日志的关键信息：

    trace文件顶部的线程信息一般是ANR的元凶，如果你的应用出现在了trace文件的顶部，那么很有可能是因为你的应用造成了ANR。

   死锁或者主线程等待也是ANR高发的原因

ANR的解决办法：

1. UI线程尽量只做跟UI相关的工作；

2. 耗时的工作放在子线程中执行，例如数据库操作、I/O耗时操作放在子线程中去操作；

3. BroadcastReceiver要执行耗时操作时应启动一个service，将耗时操作交给service来完成。

4. 避免在IntentReceiver里启动一个Activity，因为它会创建一个新的画面，并从用户当前运行的程序上抢夺焦点。如果应用在相应Intent广播时需要显示画面，应该使用Notification Manager实现。

5. 要尽量保证主线程执行工作干净利落，一个消息循环执行时间最好不超过100ms到200ms，对于一些脏活累活可以交给AsyncTask、HandlerThread、IntentService或者另外起的新线程来完成。

参考：

ANR问题简析：https://blog.csdn.net/qzh123456/article/details/78737791

android ANR分析：https://blog.csdn.net/yxz329130952/article/details/50087731