1 概述
Android的ANR主要有两种方式：
1. 通过handler的延迟机制超时触发ANR
Service、BroadcastReceiver、ContentProvider都是通过Hander机制触发ANR
2. Input事件触发ANR
ANR的发生的场景有：
- service timeout:前台服务在20s未执行完，后台服务200s未执行完。
- BroadcastQueue timeout:前台广播在10s未执行完，后台广播在60s未执行完。
- ContentProvider timeout: ContentProvider在发布时超过10s未执行完。
- InputDispatching Timeout：输入分发事件超过5s未执行完。
ANR的过程总体就是：装炸弹、拆炸弹、引爆炸弹
2 ANR触发机制
2.1. Service Timeout
2.1.1 图解：
-
客户端(App进程)向中控系统(system_server进程)发起启动服务的请求
-
中控系统派出一名空闲的通信员(binder_1线程)接收该请求，紧接着向组件管家(ActivityManager线程)发送消
息，埋下定时炸弹
-
通讯员1号(binder_1)通知工地(service所在进程)的通信员准备开始干活
-
通讯员3号(binder_3)收到任务后转交给包工头(main主线程)，加入包工头的任务队列(MessageQueue)
-
包工头经过一番努力干完活(完成service启动的生命周期)，然后等待SharedPreferences(简称SP)的持久化；
-
包工头在SP执行完成后，立刻向中控系统汇报工作已完成
-
中控系统的通讯员2号(binder_2)收到包工头的完工汇报后，立刻拆除炸弹。如果在炸弹倒计时结束前拆除炸弹则相安无事，否则会引发爆炸(触发ANR)
系统代码执行:
在文章startService启动流程可以知道Service的生命周期和启动流程。
2.1.2 系统代码执行:
2.1.2.1 装弹
在ActiveServices.realStartServiceLocked()方法中开始真正执行Service的生命周期方法，并开始装炸弹的开始。
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
// handle发送延迟消息，如果在规定时间还没有被取消，则证明方法执行时间长，则抛ANR异常。
bumpServiceExecutingLocked(r, execInFg, "create");
//...
try {
//调用Service对应onCreate()方法
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo),
app.getReportedProcState());
} catch (DeadObjectException e) {
mAm.appDiedLocked(app, "Died when creating service");
throw e;
} finally {
//...
}
}
// 通过Handler发送延迟时间，到时间内没被取消则抛ANR异常
private final void bumpServiceExecutingLocked(ServiceRecord r, boolean fg, String why) {
....
// 发送Handler
scheduleServiceTimeoutLocked(r.app);
}
// 发送延迟消息
void scheduleServiceTimeoutLocked(ProcessRecord proc) {
if (proc.executingServices.size() == 0 || proc.thread == null) {
return;
}
Message msg = mAm.mHandler.obtainMessage(
ActivityManagerService.SERVICE_TIMEOUT_MSG);
msg.obj = proc;
//当超时后仍没有remove该SERVICE_TIMEOUT_MSG消息，则执行service Timeout流程
mAm.mHandler.sendMessageDelayed(msg,
proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT);
}
static final int SERVICE_TIMEOUT = 20 * 1000;
static final int SERVICE_BACKGROUND_TIMEOUT = SERVICE_TIMEOUT * 10;
复制代码
在执行生命周期的方法前会通过bumpServiceExecutingLocked()方法进行装炸弹，通过Handler机制发送一个标志为SERVICE_TIMEOUT_MSG的延迟消息，如果是前台则20s,是后台则200s执行。
2.1.2.2 拆弹
在执行完Service的生命周期方法后就会执行拆弹，比如onCreate()方法在Application.handleCreateService()执行完毕：
private class ApplicationThread extends IApplicationThread.Stub {
// 创建对应的Service并执行onCreate()方法
private void handleCreateService(CreateServiceData data) {
try {
....
// 调用service.attach绑定资源文件
service.attach(context, this, data.info.name, data.token, app,
ActivityManager.getService());
// 调用 service.onCreate()方法
service.onCreate();
try {
// onCreate()执行完成，拆弹过程，最终调用到ActiveServices.serviceDoneExecutingLocked方法
ActivityManager.getService().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
} catch (Exception e) {
//...
}
}
// AMS
public void serviceDoneExecuting(IBinder token, int type, int startId, int res) {
synchronized (this) {
if (!(token instanceof ServiceRecord)) {
Slog.e(TAG, "serviceDoneExecuting: Invalid service token=" + token);
throw new IllegalArgumentException("Invalid service token");
}
mServices.serviceDoneExecutingLocked((ServiceRecord) token, type, startId, res);
}
}
// ActiveServices
private void serviceDoneExecutingLocked(ServiceRecord r, boolean inDestroying,
boolean finishing) {
//...
// 取消SERVICE_TIMEOUT_MSG消息，拆出炸弹
mAm.mHandler.removeMessages(ActivityManagerService.SERVICE_TIMEOUT_MSG, r.app);
//...
}
复制代码
如果在生命周期方法内执行完，会回调AMS的方法，解除SERVICE_TIMEOUT_MSG延迟发送的消息。
2.1.2.3 引爆弹
如果Service方法在规定时间内没有执行完成，则会执行AMS.MainHandler的SERVICE_TIMEOUT_MSG类型的消息：
// AMS
final class MainHandler extends Handler {
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case SERVICE_TIMEOUT_MSG: {
mServices.serviceTimeout((ProcessRecord) msg.obj);
}
break;
}
}
}
// ActiveServices
void serviceTimeout(ProcessRecord proc) {
// 如果超时，调用appNotResponding()方法
if (anrMessage != null) {
mAm.mAnrHelper.appNotResponding(proc, anrMessage);
}
}
复制代码
如果超时则会触发ANR,调用 mAm.mAnrHelper.appNotResponding()方法。
2.2. BroadcastReceiver Timeout
- broadcast跟service超时机制大抵相同，对于静态注册的广播在超时检测过程需要检测SP，如下图所示。
2.2.1 图解：
-
客户端(App进程)向中控系统(system_server进程)发起发送广播的请求
-
中控系统派出一名空闲的通信员(binder_1)接收该请求转交给组件管家(ActivityManager线程)
-
组件管家执行任务(processNextBroadcast方法)的过程埋下定时炸弹
-
组件管家通知工地(receiver所在进程)的通信员准备开始干活
-
通讯员3号(binder_3)收到任务后转交给包工头(main主线程)，加入包工头的任务队列(MessageQueue)
-
包工头经过一番努力干完活(完成receiver启动的生命周期)，发现当前进程还有SP正在执行写入文件的操作，便
将向中控系统汇报的任务交给SP工人(queued-work-looper线程)
-
SP工人历经艰辛终于完成SP数据的持久化工作，便可以向中控系统汇报工作完成
-
中控系统的通讯员2号(binder_2)收到包工头的完工汇报后，立刻拆除炸弹。如果在倒计时结束前拆除炸弹则相安无事，否则会引发爆炸(触发ANR)
（说明：SP从8.0开始采用名叫“queued-work-looper”的handler线程，在老版本采用newSingleThreadExecutor创建的单线程的线程池）
- 如果是动态广播，或者静态广播没有正在执行持久化操作的SP任务，则不需要经过“queued-work-looper”线程中 转，而是直接向中控系统汇报，流程更为简单，如下图所示：
可见，只有XML静态注册的广播超时检测过程会考虑是否有SP尚未完成，动态广播并不受其影响。SP的apply将修改的数据项更新到内存，然后再异步同步数据到磁盘文件，因此很多地方会推荐在主线程调用采用apply方式，避免阻塞主线程，但静态广播超时检测过程需要SP全部持久化到磁盘，如果过度使用apply会增大应用ANR的概率，Google这样设计的初衷是针对静态广播的场景下，保障进程被杀之前一定能完成SP的数据持久化。因为在向中控系统汇报广播接收者工作执行完成前，该进程的优先级为Foreground级别，高优先级下进程不但不会被杀，而且能分配到更多的CPU时间片，加速完成SP持久化。
2.2.2 系统代码执行:
2.2.2.1 装弹
在文章广播的注册、发送原理流程可以了解，发送广播后调用之行对应的广播接收器的方法，对应的方法在BroadcastQueue.processNextBroadcast()：
public final class BroadcastQueue {
final void processNextBroadcastLocked(boolean fromMsg, boolean skipOomAdj) {
BroadcastRecord r;
// 处理当前有序广播
do {
// 获取BroadcastRecord
final long now = SystemClock.uptimeMillis();
r = mDispatcher.getNextBroadcastLocked(now);
//当广播处理时间超时，则强制结束这条广播
if (mService.mProcessesReady && !r.timeoutExempt && r.dispatchTime > 0) {
if ((numReceivers > 0) &&
(now > r.dispatchTime + (2 * mConstants.TIMEOUT * numReceivers))) {
broadcastTimeoutLocked(false); // forcibly finish this broadcast
forceReceive = true;
r.state = BroadcastRecord.IDLE;
}
}
//...
if (r.receivers == null || r.nextReceiver >= numReceivers
|| r.resultAbort || forceReceive) {
if (r.resultTo != null) {
//...
//处理广播消息消息，调用到onReceive()
performReceiveLocked(r.callerApp, r.resultTo,
new Intent(r.intent), r.resultCode,
r.resultData, r.resultExtras, false, false, r.userId);
//...
}
//拆炸弹
cancelBroadcastTimeoutLocked();
r = null;
looped = true;
continue;
}
//..
} while (r == null);
//获取下一个receiver的index
int recIdx = r.nextReceiver++;
if (!mPendingBroadcastTimeoutMessage) {
long timeoutTime = r.receiverTime + mTimeoutPeriod;
//装炸弹，设置广播超时时间，发送BROADCAST_TIMEOUT_MSG
setBroadcastTimeoutLocked(timeoutTime);
}
//...
}
// 装弹
final void setBroadcastTimeoutLocked(long timeoutTime) {
if (!mPendingBroadcastTimeoutMessage) {
Message msg = mHandler.obtainMessage(BROADCAST_TIMEOUT_MSG, this);
mHandler.sendMessageAtTime(msg, timeoutTime);
mPendingBroadcastTimeoutMessage = true;
}
}
}
复制代码
通过setBroadcastTimeoutLocked()方法进行装弹。
2.2.2.2 拆弹
通过上面的processNextBroadcastLocked()方法可知，调用cancelBroadcastTimeoutLocked()进行拆弹。
// 拆弹
final void cancelBroadcastTimeoutLocked() {
if (mPendingBroadcastTimeoutMessage) {
mHandler.removeMessages(BROADCAST_TIMEOUT_MSG, this);
mPendingBroadcastTimeoutMessage = false;
}
}
复制代码
2.2.2.3 引爆弹
通过BroadcastHandler的BROADCAST_TIMEOUT_MSG类型的消息的执行，进行引爆炸弹。
public void handleMessage(Message msg) {
switch (msg.what) {
case BROADCAST_TIMEOUT_MSG: {
synchronized (mService) {
// 调用broadcastTimeoutLocked()方法
broadcastTimeoutLocked(true);
}
}
break;
}
}
final void broadcastTimeoutLocked(boolean fromMsg) {
...
// 如果超时，调用AMS.mAnrHelper.appNotResponding
if (!debugging && anrMessage != null) {
mService.mAnrHelper.appNotResponding(app, anrMessage);
}
}
复制代码
最后也是调用AMS.mAnrHelper.appNotResponding()方法
2.3. ContentProvider Timeout
provider的超时是在provider进程首次启动的时候才会检测，当provider进程已启动的场景，再次请求provider并不会触发provider超时。
2.3.1 图解:
-
客户端(App进程)向中控系统(system_server进程)发起获取内容提供者的请求
-
中控系统派出一名空闲的通信员(binder_1)接收该请求，检测到内容提供者尚未启动，则先通过zygote孵化新进程
-
新孵化的provider进程向中控系统注册自己的存在
-
中控系统的通信员2号接收到该信息后，向组件管家(ActivityManager线程)发送消息，埋下炸弹
-
通信员2号通知工地(provider进程)的通信员准备开始干活
-
通讯员4号(binder_4)收到任务后转交给包工头(main主线程)，加入包工头的任务队列(MessageQueue)
-
包工头经过一番努力干完活(完成provider的安装工作)后向中控系统汇报工作已完成
-
中控系统的通讯员3号(binder_3)收到包工头的完工汇报后，立刻拆除炸弹。如果在倒计时结束前拆除炸弹则相安无事，否则会引发爆炸(触发ANR)
2.3.2 系统代码执行:
2.3.2.1 装弹
ContentProvider的注册在启动进程的时候就开始执行，在注册的过程中会向AMS绑定Application，如果有ContentProvider就装弹，方法在AMS.attachApplicationLocked()方法中：
// AMS
private boolean attachApplicationLocked(@NonNull IApplicationThread thread,
int pid, int callingUid, long startSeq) {
//...
boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);
List<ProviderInfo> providers = normalMode ? generateApplicationProvidersLocked(app) : null;
if (providers != null && checkAppInLaunchingProvidersLocked(app)) {
// 装弹
Message msg = mHandler.obtainMessage(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG);
msg.obj = app;
mHandler.sendMessageDelayed(msg,
ContentResolver.CONTENT_PROVIDER_PUBLISH_TIMEOUT_MILLIS);
}
}
public static final int CONTENT_PROVIDER_PUBLISH_TIMEOUT_MILLIS = 10 * 1000;
复制代码
在绑定Application时，会判断是否有ContentProvider时会装炸弹进行一个CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG消息的延迟发送。
2.3.2.2 拆弹
在AT.installContentProviders()安装完后会调用AMS.publishContentProviders()方法进行拆弹。
public final void publishContentProviders(IApplicationThread caller,
List<ContentProviderHolder> providers) {
...
// 拆弹，移除CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG消息
mHandler.removeMessages(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG, r)
}
复制代码
2.3.2.3 引爆弹
如果消息没被移除则引爆炸弹,CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG的handler在AMS.MainHandler中，
public void handleMessage(Message msg) {
switch (msg.what) {
case CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG: {
ProcessRecord app = (ProcessRecord) msg.obj;
synchronized (ActivityManagerService.this) {
processContentProviderPublishTimedOutLocked(app);
}
}
break;
}
}
private final void processContentProviderPublishTimedOutLocked(ProcessRecord app) {
//移除死亡的provider
cleanupAppInLaunchingProvidersLocked(app, true);
//移除mProcessNames中的相应对象
mProcessList.removeProcessLocked(app, false, true,
ApplicationExitInfo.REASON_INITIALIZATION_FAILURE,
ApplicationExitInfo.SUBREASON_UNKNOWN,
"timeout publishing content providers");
}
复制代码
2.4. InputDispatching Timeout
input的超时检测机制跟service、broadcast、provider截然不同，为了更好的理解input过程先来介绍两个重要线程的相关工作：
- InputReader线程负责通过EventHub(监听目录/dev/input)读取输入事件，一旦监听到输入事件则放入到InputDispatcher的mInBoundQueue队列，并通知其处理该事件；
- InputDispatcher线程负责将接收到的输入事件分发给目标应用窗口，分发过程使用到3个事件队列：
- mInBoundQueue用于记录InputReader发送过来的输入事件；
- outBoundQueue用于记录即将分发给目标应用窗口的输入事件；
- waitQueue用于记录已分发给目标应用，且应用尚未处理完成的输入事件
input的超时机制并非时间到了一定就会爆炸，而是处理后续上报事件的过程才会去检测是否该爆炸，所以更像是扫雷的过程，具体如下图所示。
2.4.1 图解：
-
InputReader线程通过EventHub监听底层上报的输入事件，一旦收到输入事件则将其放至mInBoundQueue队列，并唤醒InputDispatcher线程
-
InputDispatcher开始分发输入事件，设置埋雷的起点时间。先检测是否有正在处理的事件(mPendingEvent)，如果没有则取出mInBoundQueue队头的事件，并将其赋值给mPendingEvent，且重置ANR的timeout；否则不会从mInBoundQueue中取出事件，也不会重置timeout。然后检查窗口是否就绪(checkWindowReadyForMoreInputLocked)，满足以下任一情况，则会进入扫雷状态(检测前一个正在处理的事件是否超时)，终止本轮事件分发，否则继续执行步骤3。对于按键类型的输入事件，则outboundQueue或者waitQueue不为空，对于非按键的输入事件，则waitQueue不为空，且等待队头时间超时500ms
-
当应用窗口准备就绪，则将mPendingEvent转移到outBoundQueue队列
-
当outBoundQueue不为空，且应用管道对端连接状态正常，则将数据从outboundQueue中取出事件，放入waitQueue队列
-
InputDispatcher通过socket告知目标应用所在进程可以准备开始干活
-
App在初始化时默认已创建跟中控系统双向通信的socketpair，此时App的包工头(main线程)收到输入事件后，会层层转发到目标窗口来处理
-
包工头完成工作后，会通过socket向中控系统汇报工作完成，则中控系统会将该事件从waitQueue队列中移除。
input超时机制为什么是扫雷，而非定时爆炸呢？是由于对于input来说即便某次事件执行时间超过timeout时长，只要用户后续在没有再生成输入事件，则不会触发ANR。 这里的扫雷是指当前输入系统中正在处理着某个耗时事件的前提下，后续的每一次input事件都会检测前一个正在处理的事件是否超时（进入扫雷状态），检测当前的时间距离上次输入事件分发时间点是否超过timeout时长。如果前一个输入事件，则会重置ANR的timeout，从而不会爆炸。
2.4.2 系统代码执行：
InputReader 不断的从EventHub中监听是否有Input事件，InputReader把事件分发给InputDispatcher。 InputDispatcher调用dispatchOnce()方法开始把事件分发给对应的View,就从InputDispatcher的分发开始监控ANR，InputDispatcher的ANR区间是查找窗口findFocusedWindowTargetsLocked()方法到resetANRTimeoutsLocked()重置方法。
void InputDispatcher::dispatchOnce() {
...
// 调用dispatchOnceInnerLocked进行分析
dispatchOnceInnerLocked(&nextWakeupTime);
}
void InputDispatcher::dispatchOnceInnerLocked(nsecs_t*nextWakeupTime) {
nsecs_t currentTime = now();
// ...
// 重置标记
resetANRTimeoutsLocked();
switch (mPendingEvent -> type) {
case EventEntry::TYPE_KEY: {
...
// key类型
done = dispatchKeyLocked(currentTime, typedEntry, & dropReason, nextWakeupTime);
break;
}
case EventEntry::TYPE_MOTION: {
...
done = dispatchMotionLocked(currentTime, typedEntry,
& dropReason, nextWakeupTime);
break;
}
default:
ALOG_ASSERT(false);
break;
}
}
void InputDispatcher::resetANRTimeoutsLocked() {
// 将mInputTargetWaitCause设置为INPUT_TARGET_WAIT_CAUSE_NONE
mInputTargetWaitCause = INPUT_TARGET_WAIT_CAUSE_NONE;
mInputTargetWaitApplicationToken.clear();
}
复制代码
在分发之前会调用resetANRTimeoutsLocked()方法，重置mInputTargetWaitCause标记为：INPUT_TARGET_WAIT_CAUSE_NONE。接着根据下发的类型，寻找对应的窗口，比如KEY类型，则调用dispatchKeyLocked()方法。
bool InputDispatcher::dispatchKeyLocked(nsecs_t currentTime, KeyEntry*entry,
DropReason*dropReason, nsecs_t*nextWakeupTime) {
// 寻找目标窗口
int32_t injectionResult = findFocusedWindowTargetsLocked(currentTime,
entry, inputTargets, nextWakeupTime);
// 给目标窗口分发事件
dispatchEventLocked(currentTime, entry, inputTargets);
return true;
}
int32_t InputDispatcher::findFocusedWindowTargetsLocked(nsecs_t currentTime,
const EventEntry*entry, std::vector<InputTarget>&inputTargets, nsecs_t*nextWakeupTime) {
...
// 检查窗口不能input的原因
reason = checkWindowReadyForMoreInputLocked(currentTime,
focusedWindowHandle, entry, "focused");
if (!reason.empty()) {
// 调用handleTargetsNotReadyLocked()方法
injectionResult = handleTargetsNotReadyLocked(currentTime, entry,
focusedApplicationHandle, focusedWindowHandle, nextWakeupTime, reason.c_str());
goto Unresponsive;
}
...
return injectionResult;
}
int32_t InputDispatcher::handleTargetsNotReadyLocked(nsecs_t currentTime,const EventEntry*entry,const sp<InputApplicationHandle>&applicationHandle,const sp<InputWindowHandle>&windowHandle,
nsecs_t*nextWakeupTime, const char*reason) {
// 在resetANRTimeoutsLocked方法中，mInputTargetWaitCause为INPUT_TARGET_WAIT_CAUSE_NONE
if (mInputTargetWaitCause != INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY) {
// DEFAULT_INPUT_DISPATCHING_TIMEOUT为5s
nsecs_t timeout;
if (windowHandle != nullptr) {
timeout = windowHandle -> getDispatchingTimeout(DEFAULT_INPUT_DISPATCHING_TIMEOUT);
} else if (applicationHandle != nullptr) {
timeout = applicationHandle -> getDispatchingTimeout(
DEFAULT_INPUT_DISPATCHING_TIMEOUT);
} else {
timeout = DEFAULT_INPUT_DISPATCHING_TIMEOUT;
}
// 要等到下次调用resetANRTimeoutsLocked时才能进
mInputTargetWaitCause = INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY;
// 当前时间加上5s
mInputTargetWaitTimeoutTime = currentTime + timeout;
mInputTargetWaitTimeoutExpired = false;
mInputTargetWaitApplicationToken.clear();
}
if (mInputTargetWaitTimeoutExpired) {
return INPUT_EVENT_INJECTION_TIMED_OUT;
}
if (currentTime >= mInputTargetWaitTimeoutTime) {
// 当前时间超过设定的5s，后执行onANRLocked()的ANR方法
onANRLocked(currentTime, applicationHandle, windowHandle,
entry -> eventTime, mInputTargetWaitStartTime, reason);
return INPUT_EVENT_INJECTION_PENDING;
} else {
// Force poll loop to wake up when timeout is due.
if (mInputTargetWaitTimeoutTime < *nextWakeupTime){
*nextWakeupTime = mInputTargetWaitTimeoutTime;
}
return INPUT_EVENT_INJECTION_PENDING;
}
}
复制代码
在分发一次事件时，会调用resetANRTimeoutsLocked将标记为INPUT_TARGET_WAIT_CAUSE_NONE,所以第一次事件会设置一个5s后的超时时间，并把标记设置为INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY，如果下次事件来临时当前的时间超过上次设置的5s时间就会调用onANRLocked()方法产生ANR。
void InputDispatcher::onANRLocked(
nsecs_t currentTime, const sp<InputApplicationHandle>&applicationHandle,
const sp<InputWindowHandle>&windowHandle,
nsecs_t eventTime, nsecs_t waitStartTime, const char*reason) {
float dispatchLatency = (currentTime - eventTime) * 0.000001f;
float waitDuration = (currentTime - waitStartTime) * 0.000001f;
// 收集ANR现场信息
time_t t = time(nullptr);
struct tm tm;
localtime_r( & t, &tm);
char timestr[ 64];
strftime(timestr, sizeof(timestr), "%F %T", & tm);
mLastANRState.clear();
mLastANRState += INDENT "ANR:\n";
mLastANRState += StringPrintf(INDENT2"Time: %s\n", timestr);
mLastANRState += StringPrintf(INDENT2"Window: %s\n",
getApplicationWindowLabel(applicationHandle, windowHandle).c_str());
mLastANRState += StringPrintf(INDENT2"DispatchLatency: %0.1fms\n", dispatchLatency);
mLastANRState += StringPrintf(INDENT2"WaitDuration: %0.1fms\n", waitDuration);
mLastANRState += StringPrintf(INDENT2"Reason: %s\n", reason);
//dump信息
dumpDispatchStateLocked(mLastANRState);
//将ANR命令加入commandQueue
CommandEntry * commandEntry = postCommandLocked(
& InputDispatcher::doNotifyANRLockedInterruptible);
commandEntry -> inputApplicationHandle = applicationHandle;
commandEntry -> inputChannel = windowHandle != nullptr ?
getInputChannelLocked(windowHandle -> getToken()) : nullptr;
commandEntry -> reason = reason;
}
复制代码
在下次执行InputDispatcher.dispatchOnce时会先执行commandQueue的队列命令，这里把InputDispatcher::doNotifyANRLockedInterruptible放入到了队列。
void InputDispatcher::doNotifyANRLockedInterruptible(CommandEntry*commandEntry) {
mLock.unlock();
//mPolicy是指NativeInputManager
nsecs_t newTimeout = mPolicy -> notifyANR(
commandEntry -> inputApplicationHandle,
commandEntry -> inputChannel ? commandEntry -> inputChannel -> getToken() : nullptr,
commandEntry -> reason);
mLock.lock();
resumeAfterTargetsNotReadyTimeoutLocked(newTimeout,
commandEntry -> inputChannel);
}
复制代码
mPolicy -> notifyANR通过JNI最终调用到InputManagerService.notifyANR()方法：
// InputManagerService
private long notifyANR(InputApplicationHandle inputApplicationHandle, IBinder token,
String reason) {
return mWindowManagerCallbacks.notifyANR(inputApplicationHandle,
token, reason);
}
复制代码
这里的mWindowManagerCallbacks是InputManagerCallback对象
//InputManagerCallback
public long notifyANR(InputApplicationHandle inputApplicationHandle, IBinder token,
String reason) {
final long startTime = SystemClock.uptimeMillis();
try {
return notifyANRInner(inputApplicationHandle, token, reason);
} finally {
}
}
private long notifyANRInner(InputApplicationHandle inputApplicationHandle, IBinder token,
String reason) {
...
// 调用AMS的inputDispatchingTimedOut()方法
long timeout = mService.mAmInternal.inputDispatchingTimedOut(windowPid, aboveSystem,
reason);
return 0; // abort dispatching
}
复制代码
最终调用到AMS.inputDispatchingTimedOut()方法
// AMS
long inputDispatchingTimedOut(int pid, final boolean aboveSystem, String reason) {
if (checkCallingPermission(FILTER_EVENTS) != PackageManager.PERMISSION_GRANTED) {
throw new SecurityException("Requires permission " + FILTER_EVENTS);
}
ProcessRecord proc;
long timeout;
synchronized (this) {
synchronized (mPidsSelfLocked) {
proc = mPidsSelfLocked.get(pid);
}
timeout = proc != null ? proc.getInputDispatchingTimeout() : KEY_DISPATCHING_TIMEOUT_MS;
}
// 调用inputDispatchingTimedOut
if (inputDispatchingTimedOut(proc, null, null, null, null, aboveSystem, reason)) {
return -1;
}
return timeout;
}
boolean inputDispatchingTimedOut(ProcessRecord proc, String activityShortComponentName,
ApplicationInfo aInfo, String parentShortComponentName,
WindowProcessController parentProcess, boolean aboveSystem, String reason) {
// 调用appNotResponding方法
mAnrHelper.appNotResponding(proc, activityShortComponentName, aInfo,
parentShortComponentName, parentProcess, aboveSystem, annotation);
return true;
}
复制代码
还是执行appNotResponding()方法。
3 ANR超时阈值
不同组件的超时阈值各有不同，关于service、broadcast、contentprovider以及input的超时阈值如下表：
3.1 前台与后台服务的区别
系统对前台服务启动的超时为20s，而后台服务超时为200s，那么系统是如何区别前台还是后台服务呢？来看看ActiveServices的核心逻辑：
ComponentName startServiceLocked(...) {
final boolean callerFg;
if (caller != null) {
final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
callerFg = callerApp.setSchedGroup != ProcessList.SCHED_GROUP_BACKGROUND;
} else {
callerFg = true;
}
...
ComponentName cmp = startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
return cmp;
}
在startService过程根据发起方进程callerApp所属的进程调度组来决定被启动的服务是属于前台还是后台。当发起方进程不等于ProcessList.SCHED_GROUP_BACKGROUND(后台进程组)则认为是前台服务，否则为后台服务，并标记在ServiceRecord的成员变量createdFromFg。
什么进程属于SCHED_GROUP_BACKGROUND调度组呢？进程调度组大体可分为TOP、前台、后台，进程优先级（Adj）和进程调度组（SCHED_GROUP）算法较为复杂，其对应关系可粗略理解为Adj等于0的进程属于Top进程组，Adj等于100或者200的进程属于前台进程组，Adj大于200的进程属于后台进程组。关于Adj的含义见下表，简单来说就是Adj>200的进程对用户来说基本是无感知，主要是做一些后台工作，故后台服务拥有更长的超时阈值，同时 后台服务属于后台进程调度组，相比前台服务属于前台进程调度组，分配更少的CPU时间片。
前台服务准确来说，是指由处于前台进程调度组的进程发起的服务。这跟常说的fg-service服务有所不同，fg-service是指挂有前台通知的服务。
3.2 前台与后台广播超时
前台广播超时为10s，后台广播超时为60s，那么如何区分前台和后台广播呢？来看看AMS的核心逻辑
BroadcastQueue broadcastQueueForIntent(Intent intent) {
final boolean isFg = (intent.getFlags() & Intent.FLAG_RECEIVER_FOREGROUND) != 0;
return (isFg) ? mFgBroadcastQueue : mBgBroadcastQueue;
mFgBroadcastQueue = new BroadcastQueue(this, mHandler, "foreground", BROADCAST_FG_TIMEOUT, false);
mBgBroadcastQueue = newBroadcastQueue(this, mHandler, "background", BROADCAST_BG_TIMEOUT, true);
}
根据发送广播sendBroadcast(Intent intent)中的intent的flags是否包含FLAG_RECEIVER_FOREGROUND来决定把该 广播是放入前台广播队列或者后台广播队列，前台广播队列的超时为10s，后台广播队列的超时为60s，默认情况下 广播是放入后台广播队列，除非指明加上FLAG_RECEIVER_FOREGROUND标识。
后台广播比前台广播拥有更长的超时阈值，同时在广播分发过程遇到后台service的启动(mDelayBehindServices)会 延迟分发广播，等待service的完成，因为等待service而导致的广播ANR会被忽略掉；后台广播属于后台进程调度 组，而前台广播属于前台进程调度组。简而言之，后台广播更不容易发生ANR，同时执行的速度也会更慢。
另外，只有串行处理的广播才有超时机制，因为接收者是串行处理的，前一个receiver处理慢，会影响后一个receiver；并行广播通过一个循环一次性向所有的receiver分发广播事件，所以不存在彼此影响的问题，则没有广播超时。
前台广播准确来说，是指位于前台广播队列的广播。
3.3 前台与后台ANR
除了前台服务，前台广播，还有前台ANR可能会让你云里雾里的，来看看其中核心逻辑：
final void appNotResponding(...) {
...
synchronized (mService) {
isSilentANR = !showBackground && !isInterestingForBackgroundTraces(app);
...
}
...
File tracesFile = ActivityManagerService.dumpStackTraces(
true, firstPids,
(isSilentANR) ? null : processCpuTracker,
(isSilentANR) ? null : lastPids,
nativePids);
synchronized (mService) {
if (isSilentANR) {
app.kill("bg anr", true);
return;
}
...
//弹出ANR选择的对话框
Message msg = Message.obtain();
msg.what = ActivityManagerService.SHOW_NOT_RESPONDING_UI_MSG;
msg.obj = new AppNotRespondingDialog.Data(app, activity, aboveSystem);
mService.mUiHandler.sendMessage(msg);
}
}
决定是前台或者后台ANR取决于该应用发生ANR时对用户是否可感知，比如拥有当前前台可见的activity的进程，或者拥有前台通知的fg-service的进程，这些是用户可感知的场景，发生ANR对用户体验影响比较大，故需要弹框让用户决定是否退出还是等待，如果直接杀掉这类应用会给用户造成莫名其妙的闪退。
后台ANR相比前台ANR，只抓取发生无响应进程的trace，也不会收集CPU信息，并且会在后台直接杀掉该无响应的进程，不会弹框提示用户,前台ANR准确来说，是指对用户可感知的进程发生的ANR 。
4 ANR爆炸现场
对于service、broadcast、provider、input发生ANR后，中控系统会马上去抓取现场的信息，用于调试分析。收集的信息包括如下：
-
将am_anr信息输出到EventLog，也就是说ANR触发的时间点最接近的就是EventLog中输出的am_anr信息
-
收集以下重要进程的各个线程调用栈trace信息，保存在data/anr/traces.txt文件
- 当前发生ANR的进程，system_server进程以及所有persistent进程
- audioserver, cameraserver, mediaserver, surfaceflinger等重要的native进程
- CPU使用率排名前5的进程
-
将发生ANR的reason以及CPU使用情况信息输出到main log
-
将traces文件和CPU使用情况信息保存到dropbox，即data/system/dropbox目录
-
对用户可感知的进程则弹出ANR对话框告知用户，对用户不可感知的进程发生ANR则直接杀掉
整个ANR信息收集过程比较耗时，其中抓取进程的trace信息，每抓取一个等待200ms，可见persistent越多，等待时间越长。关于抓取trace命令，对于Java进程可通过在adb shell环境下执行kill -3 [pid]可抓取相应pid的调用栈；对于Native进程在adb shell环境下执行debuggerd -b [pid]可抓取相应pid的调用栈。对于ANR问题发生后的蛛丝马迹(trace)在traces.txt和dropbox目录中保存记录。
有了现场信息，可以调试分析，先定位发生ANR时间点，然后查看trace信息，接着分析是否有耗时的message、binder调用，锁的竞争，CPU资源的抢占，以及结合具体场景的上下文来分析，调试手段就需要针对前面说到的message、binder、锁等资源从系统角度细化更多debug信息，这里不再展开，后续再以ANR案例来讲解。
作为应用开发者应让主线程尽量只做UI相关的操作，避免耗时操作，比如过度复杂的UI绘制，网络操作，文件IO操作；避免主线程跟工作线程发生锁的竞争，减少系统耗时binder的调用，谨慎使用sharePreference，注意主线程执行provider query操作。简而言之，尽可能减少主线程的负载，让其空闲待命，以期可随时响应用户的操作。
回答:
最后，来回答文章开头的提问，有哪些路径会引发ANR? 答应是从埋下定时炸弹到拆炸弹之间的任何一个或多个路径执行慢都会导致ANR（以service为例），可以是service的生命周期的回调方法(比如onStartCommand)执行慢，可以是主线程的消息队列存在其他耗时消息让service回调方法迟迟得不到执行，可以是SP操作执行慢，可以是system_server进程的binder线程繁忙而导致没有及时收到拆炸弹的指令。另外ActivityManager线程也可能阻塞，出现的现象就是前台服务执行时间有可能超过10s，但并不会出现ANR。
发生ANR时从trace来看主线程却处于空闲状态或者停留在非耗时代码的原因有哪些？可以是抓取trace过于耗时而错过现场，可以是主线程消息队列堆积大量消息而最后抓取快照一刻只是瞬时状态，可以是广播的“queued-worklooper”一直在处理SP操作。
