Android ANR简介

ANR（App not respond）是Android定义的一种稳定性问题类型；系统发出关键消息，同时发出此消息的超时消息。处理逻辑有两种情况：

1. 关键消息被执行，超时消息被清除；ANR不会发生
2. 超时消息被执行；触发ANR机制，通知AMS抓取堆栈，生成dropbox内容，kill目标进程

本专栏分为以下章节详细解析ANR：
稳定性问题ANR-input
稳定性问题ANR-广播
稳定性问题ANR-service
稳定性问题ANR- Activity
稳定性问题ANR-provide

简介

ANR检测点逻辑都在system_server进程中，假设如果system_server出现hang的场景，ANR逻辑有可能就不会被触发。而且ANR都是针对Android app的机制。因此每种机制中都会依据App当时的状态，如前台还是后台等行为，进行特殊处理。

本专栏中的所有代码实例基于android-14.0.0_r2
源码路径：http://aospxref.com/android-14.0.0_r2/

问题触发

所有的ANR都是AMS（ActivityManagerService）发起，执行appNotResponding保存问题的现场；执行的关键信息分为以下步骤：
第一步：在logcat event buffer中记录ANR发生
代码路径：链接

EventLog.writeEvent(EventLogTags.AM_ANR, mApp.userId, pid, mApp.processName,
                    mApp.info.flags, annotation);

第二步：收集当前活跃的进程和Android核心服务的pid，抓取java堆栈和native堆栈

StackTracesDumpHelper.dumpStackTraces

dump stack有两种方式：

1. java进程首先发送kill -3 pid信号，由进程自身的signalcatch线程消费，如果超时使用native dump方式进行保存堆栈
2. native进程使用kill -35 pid信号，此方式会有tombstoned进程负责保存native堆栈

第三步：在Dropbox中新增ANR问题记录

mService.addErrorToDropBox("anr", mApp, mApp.processName, activityShortComponentName,
                parentShortComponentName, parentPr, null, report.toString(), tracesFile,
                null, new Float(loadingProgress), incrementalMetrics, errorId);

第四步：干掉进程；分为两种情况：前台进程弹框由用户决策；后台进程直接kill

问题分析

简单的ANR问题可以使用Android提供的如上原生方式就能定位问题；按上面流程走一遍，确定发生时间，获取anr trace文件；trace文件保存在两个地方：

1. /data/anr/目录下，有anr开头，内容中包含包名，进程pid等信息
2. /data/system/dropbox/目录下，有data_app_anr或者system_app_anr开头的文件，内容多了logcat和一些系统信息

疑难ANR

分析此类问题需要对ANR的机制有所了解，此篇概括性的介绍一下ANR的机制，每一种类型的ANR产生原理在后面的文章中做分析；
ANR发生的主要原因是从am_anr记录时间点，之前的一段时间内，有一个重要的message没有被app的主线程消费导致的，如：前台input类ANR是有一个motionevent or keyvevent事件5s内没有被消费，广播前台ANR是广播发出5s内，主线程没有执行finishreceiver函数等等。
如上，分析此类问题原生的Android机制就捉襟见肘。只能看trace文件和logcat去定位问题，大多数问题是无法定位的，很多ANR的trace都停留着ibc的nextpollonce函数上。
针对此类比较复杂的ANR，在后面文章中分享如果增加机制去定位问题。