Android系统ANR机制：AMS、InputManager、BroadcastQueue等组件角色归纳总结

角色拆解与职责定位

当一个ANR发生时，很多人只会盯着logcat看 ANR in 那行。但说实话，这背后是多个系统组件协同工作的结果。搞懂它们的职责，你排查日志时就能一眼看出问题出在哪个环节。

我平时看ANR日志，有个习惯——先不看堆栈，而是先根据日志前缀猜是谁报的。比如看到 Input event dispatching timed out，我直接就往IMS和WMS那边想了。说白了，不同组件报出来的ANR，排查方向截然不同。

AMS——服务端的“首席调度官”

AMS里面有一个 ProcessRecord，专门用来追踪每个App进程的状态。一旦它发现某个进程超时了（比如Service的 onStartCommand 执行了20秒还没完），就会向该进程发送SIGQUIT信号，强制收集堆栈信息，最终弹出ANR对话框。

嗯，这里要注意：AMS监控的范围很广，Service、ContentProvider、BroadcastReceiver的超时最终都由它兜底。我个人习惯，遇到 Timeout executing service 这种日志时，第一时间去查 dumpsys activity processes，看进程在等什么锁，或者是不是在执行耗时的文件操作。

InputManagerService——用户交互的“守门人”

你想想看，用户最烦的是什么？是点屏幕没反应。所以IMS的职责非常简单粗暴：监控输入事件。从触摸屏到按键，任何事情都必须迅速传递给焦点窗口。如果事件在5秒内没有被 Looper 调度并处理掉，IMS会直接通知AMS：“这个App不行了，它不响应触摸了。”

为什么是5秒？因为这个时间是人能感知到“卡顿”的临界点。Input ANR在日志里特征非常明显——你会看到 Input event dispatching timed out，后面跟着等待的window和事件详情。我曾经遇到一个案例，同事在 onDraw 里做图片缩放，直接卡住了主线程，IMS 5秒一到就报了ANR。

BroadcastQueue——广播的“调度员”

广播机制里有两个队列：前台 BroadcastQueue 超时10秒，后台 BroadcastQueue 超时60秒。这个设计挺有意思的，因为后台广播对时效性要求不高，所以系统会多给你一些时间。

但是很多人不知道，有序广播是一环扣一环的。任何一个Receiver卡住了，后面的都得等着。我之前遇到一个三方广告SDK，在 onReceive 里做网络请求，导致整个前台广播队列被堵死，其他广播全发不出去。最诡异的是，这种问题不一定会直接ANR，但会让系统感觉“慢慢吞吞”，最后触发其他超时。

说白了，onReceive 不是让你干活的地方，它只是个“传令兵”。

WindowManagerService——焦点与窗口的“档案馆”

WMS不直接监控超时，但它负责维护窗口的焦点。当IMS拿到一个触摸事件时，它会问WMS：“现在焦点窗口是谁？” 然后IMS才能把事件发给正确的App。所以WMS是Input ANR链路里必不可少的一环。

它们的关系用一个图来表示会更清楚：

超时类型与关键指标