Android 基础之 ANR

ANR概述

首先，ANR(Application Not responding)是指应用程序未响应，Android系统对于一些事件需要在一定的时间范围内完成，如果超过预定时间能未能得到有效响应或者响应时间过长，都会造成ANR。ANR由消息处理机制保证，Android在系统层实现了一套精密的机制来发现ANR，核心原理是消息调度和超时处理。

其次，ANR机制主体实现在系统层。所有与ANR相关的消息，都会经过系统进程(system_server)调度，然后派发到应用进程完成对消息的实际处理，同时，系统进程设计了不同的超时限制来跟踪消息的处理。 一旦应用程序处理消息不当，超时限制就起作用了，它收集一些系统状态，譬如CPU/IO使用情况、进程函数调用栈，并且报告用户有进程无响应了(ANR对话框)。

然后，ANR问题本质是一个性能问题。ANR机制实际上对应用程序主线程的限制，要求主线程在限定的时间内处理完一些最常见的操作(启动服务、处理广播、处理输入)， 如果处理超时，则认为主线程已经失去了响应其他操作的能力。主线程中的耗时操作，譬如密集CPU运算、大量IO、复杂界面布局等，都会降低应用程序的响应能力。

哪些场景会造成ANR？

（1）Service Timeout:Service在特定的时间内无法处理完成
（2）BroadcastQueue Timeout：BroadcastReceiver在特定时间内无法处理完成
（3）ContentProvider Timeout：内容提供者执行超时
（4）inputDispatching Timeout: 按键或触摸事件在特定时间内无响应。

ANR机制

ANR机制可以分为两部分：
ANR监测机制：Android对于不同的ANR类型(Broadcast, Service, InputEvent)都有一套监测机制。
ANR报告机制：在监测到ANR以后，需要显示ANR对话框、输出日志(发生ANR时的进程函数调用栈、CPU使用情况等)。

整个ANR机制的代码也是横跨了Android的几个层：
App层：应用主线程的处理逻辑；
Framework层：ANR机制的核心，主要有AMS、BroadcastQueue、ActiveServices、InputmanagerService、InputMonitor、InputChannel、ProcessCpuTracker等；
Native层：InputDispatcher.cpp；

Provider超时机制遇到的比较少，暂不做分析；Broadcast目前主要想说两个知识点：

第一：无论是普通广播还是有序广播，最终广播接受者的onreceive都是串行执行的，可以通过Demo进行验证；

第二：通过Demo以及框架添加相关日志，都验证了普通广播也会有ANR监测机制，ANR机制以及问题分析文章认为只有串行广播才有ANR监测机制，后续再会专门讲解Broadcast发送及接收流程，同时也会补充Broadcast ANR监测机制；本文主要以Servie处理超时、输入事件分发超时为例探讨ANR监测机制。

面试题

ANR 出现的情况有几种？ 怎么分析解决 ANR 问题？
ANR(Application Not responding)。Android中，主线程(UI线程)如果在规定时内没有处理完相应工作，就会出现ANR。具体来说，ANR会在以下几种情况中出现:
(1) 输入事件(按键和触摸事件)5s内没被处理
(2) BroadcastReceiver的事件(onRecieve方法)在规定时间内没处理完(前台广播为10s，后台广播为60s)
(3) service 前台20s后台200s未完成启动
(4) ContentProvider的publish在10s内没进行完

分析ANR问题，需要结合Log以及trace文件。具体分析流程，可参照以下两篇文章：
Android ANR问题总结
anr分析

总结

1. ANR的监测机制：首先分析Service和输入事件大致工作流程，然后从Service，InputEvent两种不同的ANR监测机制的源码实现开始，分析了Android如何发现各类ANR。在启动服务、输入事件分发时，植入超时检测，用于发现ANR。
2. ANR的报告机制：分析Android如何输出ANR日志。当ANR被发现后，两个很重要的日志输出是：CPU使用情况和进程的函数调用栈，这两类日志是我们解决ANR问题的利器。
3. 监测ANR的核心原理是消息调度和超时处理。
4. 只有被ANR监测的场景才会有ANR报告以及ANR提示框。