组件类 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
