【原创】Android 系统稳定性 - ANR（一）
注意：产生这种ANR的前提是要有输入事件，如果用户没有触发任何输入事件，即便是主线程阻塞了，也不会产生ANR，因为InputDispatcher没有分发事件给应用程序，当然也不会检测处理超时和报告ANR了。

主线程在执行BroadcastReceiver的onReceive函数时10秒内没有执行完毕

? ? ? ??BroadcastReceiver（简称BR）的onReceive函数运行在主线程中，当这个函数超过10秒钟没有返回就会触发ANR。不过对这种情况的ANR系统不会显示对话框提示，仅是输出log而已。

主线程在执行Service的各个生命周期函数时20秒内没有执行完毕

? ? ? ? Service的各个生命周期函数也运行在主线程中，当这些函数超过20秒钟没有返回就会触发ANR。同样对这种情况的ANR系统也不会显示对话框提示，仅是输出log。

?

三种ANR中只有第1种会显示系统提示对话框，因为用户正在做界面交互操作，如果长时间没有任何响应，会让用户怀疑设备死机了，大多数人此时会开始乱按，甚至拔出电池重启，给用户的体验肯定是非常糟糕的。

? ? ? ? 三种ANR发生时都会在log中输出错误信息，你会发现各个应用进程和系统进程的函数堆栈信息都输出到了一个/data/anr/traces.txt的文件中，这个文件是分析ANR原因的关键文件，同时在日志中还会看到当时的CPU使用率，这也是重要信息，在后面的章节会详细介绍如何利用它们分析ANR问题。

这三种ANR不是孤立的，有可能会相互影响。例如一个应用程序进程中同时有一个正在显示的Activity和一个正在处理消息的BroadcastReceiver，它们都运行在这个进程的主线程中。如果BR的onReceive函数没有返回，此时用户点击屏幕，而onReceive超过5秒仍然没有返回，主线程无法处理用户输入事件，就会引起第1种ANR。如果继续超过10秒没有返回，又会引起第2种ANR。

?