ANR的全称是Application No Responding，即应用程序无响应，具体是一些特定的Message(Key Dispatch、Broadcast、Service)在应用的UI线程（主线程）没有在规定的时间内处理完，进而触发ANR异常。
ANR由消息处理机制保证，Android在系统层实现了一套精密的机制来发现ANR，核心原理是消息调度和超时处理。ANR机制主体实现在系统层，所有与ANR相关的消息，都会经过系统进程system_server调度，具体是ActivityManagerService服务，然后派发到应用进程完成对消息的实际处理，同时，系统进程设计了不同的超时限制来跟踪消息的处理。 一旦应用程序处理消息不当，超时限制就起作用了，它收集一些系统状态，譬如CPU/IO使用情况、进程函数调用栈，最后报告用户有进程无响应了(ANR对话框)。
2. ANR分类
ANR一般有三种类型：
a. KeyDispatchTimeout （默认5s，主要类型）
这个主要是按键或触摸事件在特定时间内无响应，一般Android平台默认超时时间是5s会报anr，不过有些平台会修改这个时间，比如MTK有些平台就是8s的超时时间。这类超时会有ANR提示框弹出，用户可以选择forceStop或者继续等待。
b. BroadcastTimeout （默认 前台10s、后台60s）
这个主要是BroadcastRecevier在规定时间无法处理完成。前台广播超时时间是10s,后台广播超时是60s,这类超时没有提示框弹出。
c. ServiceTimeout （默认 前台20s、后台200s 小概率类型）
Service在规定时间内无法处理完成操作，即会报出服务超时，这类ANR同样没有提示框出现。超时时间，前台Service是20s，后台Service是200s。
场景1：低内存anr：查看CPU，手机内存低导致anr时，一般以下两个进程CPU使用率高，手机会出现大量应用anr：
35% 90/mmcqd/0: 0% user + 35% kernel
18% 49/kswapd0: 0% user + 18% kernel
场景2： 某一个进程的cpu使用率高，导致当前进程无法获取资源，可以根据trace查看是哪个进程在工作；
场景3：主线程卡死： 1）主线程等待其他线程锁waiting to lock； 2） 主线程繁忙；3）主线程对应的native调用栈卡住；
场景4：Activity resume、restart或pause太慢，导致无焦点窗口问题，通常会有黑屏白屏等现象；
场景5：省电精灵智能省电模式冻结后台进程，resume activity时，没有及时解冻，产生无焦点窗口anr；
场景6：其它进程Binder线程耗尽（ProcessState.cpp中指定最大binder线程数，如maxThreads:32），导致当前进程卡在IPCThreadState::talkWithDriver；
场景7：Input dispatching timed out：接收输入事件的窗口出现异常，丢失焦点，伴随冻屏现象
场景8：monkey启动大量对象GC耗时久导致anr。从dumpsys中可以看到启动很多window，从log中看GC耗时很久；
场景9：抓取整机log导致anr。此类问题中，adbd、bugreport、chargelogcat等进程CPU使用率高；
场景10：Framework缺陷导致无焦点窗口问题，activity已经正常resume了（am_on_resume_called），dumpsys中mFocusedWindow为null。
苏公安网备 32011402010933号