（转）Android 系统稳定性 - ANR

转自：http://rayleeya.iteye.com/blog/1955652

如果你是一个Android应用程序开发人员，你的人生中不可避免的三件事情是：死亡、缴税和ANR。这么说是夸张了，但是由于Android本身的设计，以及应用程序和系统在开发过程中的缺陷，经常会在测试过程中遇到各种各样的ANR问题。在功能性的测试中还少一些，主要是在压力测试中（例如Monkey测试）会遇到非常多的ANR问题。本章的目的就是汇总笔者在工作中遇到的各种ANR问题，将其归纳总结出一套分析和处理ANR问题的方法，希望能够通过这套方法为大家提供思路，有效的减少大家处理ANR问题的时间。同时也会给出一些避免ANR的最佳实践，更多的从预防做起，更少的做事后补救。

考虑到看本文的读者大多是有实际经验的开发人员，我会尽量少的提到一些基础的概念，我也希望给大家更多的“干货”。

本章的主要内容如下：

• ANR简介（什么是ANR、为什么会有ANR、ANR的异常长什么样）
• 如何分析ANR（引起ANR的原因分类、分析ANR的利器）
• 实例讲解
• 避免ANR的最佳实践（从错误中吸取教训）

ANR简介
ANR是“Application Not Responding”的缩写，即“应用程序无响应”。在Android中，ActivityManagerService（简称AMS）和WindowManagerService（简称WMS）会监测应用程序的响应时间，如果应用程序主线程（即UI线程）在超时时间内对输入事件没有处理完毕，或者对特定操作没有执行完毕，就会出现ANR。对于输入事件没有处理完毕产生的ANR，Android会显示一个对话框，提示用户当前应用程序没有响应，用户可以选择继续等待或者关闭这个应用程序（也就是杀掉这个应用程序的进程）。

为什么会有ANR
如上所述，ANR的产生需要同时满足三个条件：

• 主线程：只有应用程序进程的主线程响应超时才会产生ANR。
• 超时时间：产生ANR的上下文不同，超时时间也会不同，但只要在这个时间上限内没有响应就会ANR。
• 输入事件/特定操作：输入事件是指按键、触屏等设备输入事件，特定操作是指BroadcastReceiver和Service的生命周期中的各个函数，产生ANR的上下文不同，导致ANR的原因也会不同。

针对这三个条件，有以下三种情况会触发ANR，详细说明如下。

主线程对输入事件在5秒内没有处理完毕