当前位置：首页 > news >正文

ANR原理篇 - ANR原理总览

news 2025/9/7 23:18:05

系列文章目录

提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加
例如：第一章 Python 机器学习入门之pandas的使用

文章目录

系列文章目录
前言
ANR流程概览
ANR触发机制
一、service超时机制
二、broadcast超时机制
三、provider超时机制
四、input超时机制
ANR信息收集
Question

前言

不论从事安卓应用开发，还是安卓系统研发，应该都遇到应用无响应（ANR，Application Not Responding）问题，当应用程序一段时间无法及时响应，则会弹出ANR对话框，让用户选择继续等待，还是强制关闭。

那么哪些场景会造成ANR呢？
Service Timeout:比如前台服务在20s内未执行完成；
BroadcastQueue Timeout：比如前台广播在10s内未执行完成
ContentProvider Timeout：内容提供者,在publish过超时10s;
InputDispatching Timeout: 输入事件分发超时5s，包括按键和触摸事件。

ANR流程概览

我们通过一张流程图来了解整个ANR的流程：
在这里插入图片描述
无论是哪种类型的ANR，哪怕是native层的ANR，最终也会通知到AnrHelper类的appNotResponding方法。所以，我们从这个方法开始了解整个ANR的流程。我们用来区分ANR的四种不同类型，其实也就是appNotResponding这个方法中的annotation不同而已，而ANR本身是不去分类型的。

appNotResponding方法中，主要是生成AnrRecord对象，加入到mAnrRecords集合中。然后调用startAnrConsumerIfNeeded方法。
startAnrConsumerIfNeeded方法主要是通过cas进行判断，避免两个ANR线程同时执行。如果没有冲突的话，则开启AnrConsumerThread线程，对mAnrRecords中的对象进行消费。
AnrConsumerThread的run方法中，就是从mAnrRecords中取出对象，这些对象第一条中添加的。通过AnrRecord自身的appNotResponding方法进行消费。
appNotResponding方法就是整个ANR流程的核心执行逻辑了。总结一下，其实主要分为两大块：
- 生成ANR的相关log以及日志并打印或保存
- 触发ANR超时机制，弹出应用无响应的框

ANR日志生成可查看ANR原理篇 - ANR信息收集过程
下面篇章，主要看下ANR触发机制。

ANR触发机制

ANR是一套监控Android应用响应是否及时的机制，可以把发生ANR比作是引爆炸弹，整个流程包含三部分组成：
1.埋定时炸弹：中控系统(system_server进程)启动倒计时，在规定时间内如果目标(应用进程)没有干完所有的活，则中控系统会定向炸毁(杀进程)目标。
2.拆炸弹：在规定的时间内干完工地的所有活，并及时向中控系统报告完成，请求解除定时炸弹，则幸免于难。
3.引爆炸弹：中控系统立即封装现场，抓取快照，搜集目标执行慢的罪证(traces)，便于后续的案件侦破(调试分析)，最后是炸毁目标。
常见的ANR有service、broadcast、provider以及input。
更多细节详见下面两篇：
ANR原理篇 - service/broadcast/provider超时机制
ANR原理篇 - Input超时机制

一、service超时机制

下面来看看埋炸弹与拆炸弹在整个服务启动(startService)过程所处的环节：
在这里插入图片描述
图解：

客户端(App进程)向中控系统(system_server进程)发起启动服务的请求
中控系统派出一名空闲的通信员(binder_1线程)接收该请求，紧接着向组件管家(ActivityManager线程)发送消息，埋下定时炸弹
通讯员1号(binder_1)通知工地(service所在进程)的通信员准备开始干活
通讯员3号(binder_3)收到任务后转交给包工头(main主线程)，加入包工头的任务队列(MessageQueue)
包工头经过一番努力干完活(完成service启动的生命周期)，然后等待SharedPreferences(简称SP)的持久化；
包工头在SP执行完成后，立刻向中控系统汇报工作已完成
中控系统的通讯员2号(binder_2)收到包工头的完工汇报后，立刻拆除炸弹。如果在炸弹倒计时结束前拆除炸弹则相安无事，否则会引发爆炸(触发ANR)

更多细节详见startService启动过程分析。

二、broadcast超时机制

broadcast跟service超时机制大抵相同，如下图所示。
在这里插入图片描述
图解：

客户端(App进程)向中控系统(system_server进程)发起发送广播的请求
中控系统派出一名空闲的通信员(binder_1)接收该请求转交给组件管家(ActivityManager线程)
组件管家执行任务(processNextBroadcast方法)的过程埋下定时炸弹
组件管家通知工地(receiver所在进程)的通信员准备开始干活
通讯员3号(binder_3)收到任务后转交给包工头(main主线程)，加入包工头的任务队列(MessageQueue)
包工头经过一番努力干完活(完成receiver启动的生命周期)，然后等待SP工人完成SP数据的持久化工作，便可以向中控系统汇报工作完成
中控系统的通讯员2号(binder_2)收到包工头的完工汇报后，立刻拆除炸弹。如果在倒计时结束前拆除炸弹则相安无事，否则会引发爆炸(触发ANR)

对于静态注册的广播在超时检测过程，还多一个步骤：需要检测SP，位于第6步和第7步之间。
SP的apply将修改的数据项更新到内存，然后再异步同步数据到磁盘文件，因此很多地方会推荐在主线程调用采用apply方式，避免阻塞主线程，但静态广播超时检测过程需要SP全部持久化到磁盘，如果过度使用apply会增大应用ANR的概率，更多细节详见系统SharedPreferences工作过程。

Google这样设计的初衷是针对静态广播的场景下，保障进程被杀之前一定能完成SP的数据持久化。因为在向中控系统汇报广播接收者工作执行完成前，该进程的优先级为Foreground级别，高优先级下进程不但不会被杀，而且能分配到更多的CPU时间片，加速完成SP持久化。更多细节详见Android Broadcast广播机制。

三、provider超时机制

provider的超时是在provider进程首次启动的时候才会检测，当provider进程已启动的场景，再次请求provider并不会触发provider超时。
在这里插入图片描述
图解：

客户端(App进程)向中控系统(system_server进程)发起获取内容提供者的请求
中控系统派出一名空闲的通信员(binder_1)接收该请求，检测到内容提供者尚未启动，则先通过zygote孵化新进程
新孵化的provider进程向中控系统注册自己的存在
中控系统的通信员2号接收到该信息后，向组件管家(ActivityManager线程)发送消息，埋下炸弹
通信员2号通知工地(provider进程)的通信员准备开始干活
通讯员4号(binder_4)收到任务后转交给包工头(main主线程)，加入包工头的任务队列(MessageQueue)
包工头经过一番努力干完活(完成provider的安装工作)后向中控系统汇报工作已完成
中控系统的通讯员3号(binder_3)收到包工头的完工汇报后，立刻拆除炸弹。如果在倒计时结束前拆除炸弹则相安无事，否则会引发爆炸(触发ANR)

更多细节详见理解ContentProvider原理。

四、input超时机制

input的超时检测机制跟service、broadcast、provider截然不同，
为了更好的理解input过程先来介绍两个重要线程的相关工作：

InputReader线程负责通过EventHub(监听目录/dev/input)读取输入事件，一旦监听到输入事件则放入到InputDispatcher的mInBoundQueue队列，并通知其处理该事件；
InputDispatcher线程负责将接收到的输入事件分发给目标应用窗口，分发过程使用到3个事件队列：
- mInBoundQueue用于记录InputReader发送过来的输入事件；
- outBoundQueue用于记录即将分发给目标应用窗口的输入事件；
- waitQueue用于记录已分发给目标应用，且应用尚未处理完成的输入事件；

input的超时机制并非时间到了一定就会爆炸，而是处理后续上报事件的过程才会去检测是否该爆炸，所以更像是扫雷的过程，具体如下图所示：
在这里插入图片描述

图解：

InputReader线程通过EventHub监听底层上报的输入事件，一旦收到输入事件则将其放至mInBoundQueue队列，并唤醒InputDispatcher线程
InputDispatcher开始分发输入事件，设置埋雷的起点时间。先检测是否有正在处理的事件(mPendingEvent)，如果没有则取出mInBoundQueue队头的事件，并将其赋值给mPendingEvent，且重置ANR的timeout；否则不会从mInBoundQueue中取出事件，也不会重置timeout。然后检查窗口是否就绪(checkWindowReadyForMoreInputLocked)，满足以下任一情况，则会进入扫雷状态(检测前一个正在处理的事件是否超时)，终止本轮事件分发，否则继续执行步骤3。
- 对于按键类型的输入事件，则outboundQueue或者waitQueue不为空，
- 对于非按键的输入事件，则waitQueue不为空，且等待队头时间超时500ms
当应用窗口准备就绪，则将mPendingEvent转移到outBoundQueue队列
当outBoundQueue不为空，且应用管道对端连接状态正常，则将数据从outboundQueue中取出事件，放入waitQueue队列
InputDispatcher通过socket告知目标应用所在进程可以准备开始干活
App在初始化时默认已创建跟中控系统双向通信的socketpair，此时App的包工头(main线程)收到输入事件后，会层层转发到目标窗口来处理
包工头完成工作后，会通过socket向中控系统汇报工作完成，则中控系统会将该事件从waitQueue队列中移除。

input超时机制为什么是扫雷，而非定时爆炸呢？
是由于对于input来说即便某次事件执行时间超过timeout时长，只要用户后续在没有再生成输入事件，则不会触发ANR。这里的扫雷是指当前输入系统中正在处理着某个耗时事件的前提下，后续的每一次input事件都会检测前一个正在处理的事件是否超时（进入扫雷状态），检测当前的时间距离上次输入事件分发时间点是否超过timeout时长。如果完成前一个输入事件，则会重置ANR的timeout，从而不会爆炸。

ANR信息收集

对于service、broadcast、provider、input发生ANR后，中控系统会马上去抓取现场的信息，用于调试分析。收集的信息包括如下：

将am_anr信息输出到EventLog，也就是说ANR触发的时间点最接近的就是EventLog中输出的am_anr信息
收集以下重要进程的各个线程调用栈trace信息，保存在data/anr/traces.txt文件
- 当前发生ANR的进程，system_server进程以及所有persistent进程
- audioserver, cameraserver, mediaserver, surfaceflinger等重要的native进程
- CPU使用率排名前5的进程
将发生ANR的reason以及CPU使用情况信息输出到main log
将traces文件和CPU使用情况信息保存到dropbox，即data/system/dropbox目录
对用户可感知的进程则弹出ANR对话框告知用户，对用户不可感知的进程发生ANR则直接杀掉

整个ANR信息收集过程比较耗时，其中抓取进程的trace信息，每抓取一个等待200ms，可见persistent越多，等待时间越长。

关于抓取trace命令，对于Java进程可通过在adb shell环境下执行kill -3 [pid]可抓取相应pid的调用栈；
对于Native进程在adb shell环境下执行debuggerd -b [pid]可抓取相应pid的调用栈。
对于ANR问题发生后的蛛丝马迹(trace)在traces.txt和dropbox目录中保存记录。
更多细节详见理解Android ANR的信息收集过程

有了现场信息，可以调试分析，先定位发生ANR时间点，然后查看trace信息，接着分析是否有耗时的message、binder调用，锁的竞争，CPU资源的抢占，以及结合具体场景的上下文来分析，调试手段就需要针对前面说到的message、binder、锁等资源从系统角度细化更多debug信息，这里不再展开，后续再以ANR案例来讲解。

作为应用开发者应让主线程尽量只做UI相关的操作，避免耗时操作，比如过度复杂的UI绘制，网络操作，文件IO操作；避免主线程跟工作线程发生锁的竞争，减少系统耗时binder的调用，谨慎使用sharePreference，注意主线程执行provider query操作。简而言之，尽可能减少主线程的负载，让其空闲待命，以期可随时响应用户的操作。

Question

有哪些路径会引发ANR?
答案是从埋下定时炸弹到拆炸弹之间的任何一个或多个路径执行慢都会导致ANR（以service为例），可以是service的生命周期的回调方法(比如onStartCommand)执行慢，可以是主线程的消息队列存在其他耗时消息让service回调方法迟迟得不到执行，可以是SP操作执行慢，可以是system_server进程的binder线程繁忙而导致没有及时收到拆炸弹的指令。另外ActivityManager线程也可能阻塞，出现的现象就是前台服务执行时间有可能超过10s，但并不会出现ANR。

发生ANR时从trace来看主线程却处于空闲状态或者停留在非耗时代码的原因有哪些？
可以是抓取trace过于耗时而错过现场，可以是主线程消息队列堆积大量消息而最后抓取快照一刻只是瞬时状态，可以是广播的“queued-work-looper”一直在处理SP操作。

致谢：
理解Android ANR的触发原理
http://gityuan.com/2016/07/02/android-anr/
ANR信息收集过程
http://gityuan.com/2016/12/02/app-not-response/
Intpu原理分析
http://gityuan.com/2017/01/01/input-anr/
彻底理解安卓应用无响应机制
http://gityuan.com/2019/04/06/android-anr/
ANR显示和日志生成原理讲解