稳定性（二）：ANR

组件类 ANR

• 当 AMS 通过 Binder 向应用进程派发跨进程任务时，系统会同步启动一个倒计时器（例如针对 Service 启动的 20 秒阈值），这一“埋炸弹”机制实质上将异步任务转化为带有超时约束的同步契约。应用进程在完成任务后必须通过 Binder 回调主动“拆弹”
• AMS 利用 MainHandler 发送延迟消息实现精确计时
• Android 15 对后台服务施加了更严格的约束：前台服务必须在 3 秒内完成初始化并调用 startForeground()，否则系统将直接触发 ANR。

Input 类 ANR

• InputDispatcher 会通过 socket 与窗口建立事件通道，并在事件派发后启动超时检测。
• 当事件被分发后，系统通过 MonitoredTimeout 机制跟踪其处理状态。
• 默认超时时间为 5000 毫秒（可通过系统属性调整），超时检测采用事件驱动模式，在新事件到达、应用回调完成或周期性心跳检查时触发。
• 一旦检测到超时，系统会通过 WindowManagerService 通知 ActivityManagerService，并收集包括 InputDispatcher 状态及应用进程信息在内的诊断数据，随后可能触发 ANR 弹窗及进程重启流程。
• input事件5秒之内再次有事件才会ANR，如果没有不会弹窗

常见原因

综述：

• 任何的耗时操作
• 线程：阻塞 死锁
• 资源不够：自身消耗 不能释放 系统分配

细分：

• Binder 通信数据量过大
• service binder 的数量达到上限
• SystemServer Binder 锁竞争太多，导致等锁超时
• 频繁 GC 触发 STW 导致主线程暂停，处理事件时间被拉长
• 大量 SharedPerference 同时读写
• SurfaceFlinger 超时
• System Server 中 WatchDog 出现 ANR