Service ANR完整拆解：从触发条件到日志定位与规避方法

不知道你有没有遇到过这样的情况正在使用的App突然熄掉屏幕中央弹出一个带着“关闭应用”和“等待”按钮的对话框标题是“××应用未响应”下面一行小字写着“服务未响应”。很多人都下意识去logcat里搜“ANR in Service”但真正想知道“这个对话框是怎么被拉起来的”“为什么超时时间有时候是20秒有时候是200秒”的人往往要去翻ActivityManagerService和ActiveServices的源码。这篇文章就以Service ANR为主线从触发条件、消息调度、判定逻辑到实际排查手段完整拆一遍这条链路。我尽量不堆源码行号但会把关键路径上的类、方法名和判定原则说清楚读者不管是做应用开发还是做系统开发看完都能回答两个问题Service ANR到底是怎么发生的遇到之后第一件该做的事是什么文章末尾也会分享一些我在真机和系统侧调试时踩过的坑希望能帮你少走几圈弯路。1. 先厘清Service ANR在三类经典ANR中的位置1.1 Android里不只有一种ANR输入、广播、服务三兄弟Android系统里最常见的ANR有三大类InputDispatching Timeout、BroadcastReceiver Timeout、Service Timeout。它们都叫ANR但触发场景完全不同。输入ANR是用户触摸事件超过5秒没人处理广播ANR是前台广播10秒没执行完、后台广播60秒没执行完Service ANR则是Service的生命周期回调在限定时间内没有完成。这三类ANR背后对应的是三个不同的系统模块输入ANR由InputDispatcher和InputManagerService负责广播ANR由BroadcastQueue负责而Service ANR由ActiveServices负责。它们最终都汇合到同一个地方——AMSActivityManagerService的“错误处理”逻辑也就是让对话框出现、让traces落盘的那一段。在项目排查中经常遇到的误区是应用弹了“未响应”对话框大家习惯性先看logcat里的ANR in ...却忽略了这行日志前面的类型关键词。比如ANR in com.example.app只表示进程发生了ANR具体是BroadcastReceiver还是Service要看后面的Reason:字段。Executing service com.example/.ServiceName才说明是Service ANR。搞清楚类型排查方向完全不同。1.2 前台20秒、后台200秒Service超时时间从哪里来Service ANR的判定标准中最被人熟知的数字是“前台服务20秒后台服务200秒”。这两个值在Android源码中确实是硬编码的定义在ActiveServices相关的常量里核心逻辑是这样的static final int SERVICE_TIMEOUT 20 * 1000; // 前台Service static final int SERVICE_BACKGROUND_TIMEOUT 200 * 1000; // 后台Service从Android 8.0之后还引入了允许系统通过config_anrTimeout之类配置调整的通道但我个人在大多数机型上测下来默认值基本就是上面这两个。前台服务的20秒好理解用户正在和界面交互系统状态栏里还有个常驻通知挂着服务迟迟起不来会直接影响体验所以系统只给20秒。后台服务则宽松得多因为用户看不见系统允许它慢慢跑给200秒等超过这个限度再把它判为ANR。这里有个细节很关键超时时间不是从startService被调用的那一刻开始算的而是从ServiceRecord进入“executing状态”那一刻开始算。也就是说AMS把Service生命周期回调的任务派发给应用进程应用进程真正开始执行onCreate、onStartCommand这些方法时闹钟才被埋下。如果任务排队排了很久实际留给业务代码的时间会更短这一点在低端机上尤其明显。2. 一条startService请求是如何一步步走进“超时闹钟”的2.1 startService的入口从应用进程到AMS先从应用侧看。ActivityThread收到handleBindService或handleCreateService的消息之前startService这个动作其实已经跨过一次Binder了。应用进程里的Context.startService最终会调用到AMS的startService方法整个过程类似于一次远程调用App进程向system_server进程发起请求ActivityManagerService接到请求后不直接返回结果给应用而是把服务工作交给ActiveServices去编排。ActiveServices是AMS内部一个专门管理Service的类。接到startServiceLocked后它会检查这个服务是否已经在运行、进程是否存在、是否需要创建进程如果一切都通过就进入真正的启动阶段。这中间牵涉到进程优先级调整、ServiceRecord状态流转等可以单独开一篇文章讲。对ANR来说最重要的动作发生在随后安排的“执行回调并启动计时”里。2.2 创建ServiceRecord并埋下SERVICE_TIMEOUT_MSGActiveServices在决定让目标进程创建并执行Service时会先调用一个关键方法bumpServiceExecutingLocked。这个方法会做三件事把ServiceRecord的executingStart设置为当前时间把executing嵌套计数加一然后向AMS的mHandler发送一条延时消息。这条消息就是SERVICE_TIMEOUT_MSG。消息的携带参数很讲究msg.obj是ServiceRecord本身msg.arg1则是超时时长。如果这个Service是前台服务arg1就是20秒否则就是200秒。也就是说从bumpServiceExecutingLocked这一刻起系统已经模拟了一个“闹钟”——如果没人把这个闹钟关掉到点之后系统就会去检查这个Service到底有没有完成它正在执行的事情。在AOSP中scheduleServiceTimeoutLocked的核心逻辑就是这个延时消息的发送void scheduleServiceTimeoutLocked(ProcessRecord proc, ServiceRecord service) { // 构造SERVICE_TIMEOUT_MSG携带ServiceRecord和超时时间 Message msg mAm.mHandler.obtainMessage(SERVICE_TIMEOUT_MSG, service); boolean isForeground service.isForeground; msg.arg1 isForeground ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT; mAm.mHandler.sendMessageDelayed(msg, msg.arg1); }这里需要注意一个容易混淆的细节executingStart是一个单调递增的时间戳它记录的是“执行开始时间”而超时判断用的是“当前时间减去executingStart是否超过限制”。换句话说只要业务代码一直没返回这个差值就会一直变大。到了20秒或200秒的边界AMS的Handler线程就会收到那声“闹钟响”。2.3 生命周期执行完闹钟怎么被撤掉既然有埋闹钟的动作就有关闹钟的动作。应用进程在handleCreateService或handleStartService执行完业务回调后会通过Binder回调AMS的serviceDoneExecuting最终走到ActiveServices.serviceDoneExecutingLocked。这个方法里会减少executeNesting计数并且如果嵌套计数归零就顺手把那个还没到期的SERVICE_TIMEOUT_MSG从消息队列里移除。这种“埋消息-执行任务-撤消息”的设计本质上是一场赛跑业务代码执行完并回调AMS的速度如果快于超时时间一切太平如果慢于超时时间系统就会走ANR判定流程。所以Service ANR的直接原因说白了就是业务线程没能按时向AMS“交差”。真实项目中常常出现一种状况onStartCommand里做了耗时的JSON解析或者大文件读写业务代码在超时前跑完了但AMS的消息移除动作因为system_server进程本身繁忙被延迟处理。结果就是主线程明明没卡系统还是弹了“服务未响应”。这种情况虽然不多见但排查难度比较大后面我会专门展开。3. 超时到期后AMS如何判定这个Service真的“无响应”了3.1 SERVICE_TIMEOUT_MSG来了之后先不急着弹窗当Handler线程把SERVICE_TIMEOUT_MSG取出来时系统并不会立刻弹窗杀进程而是会再做一轮校验。这一步很多人漏看了它直接关系到你对ANR流程的认知。AMS收到这条消息后会执行serviceTimeout方法。它会根据消息里携带的ServiceRecord把当前时间与service.executingStart timeout去做比较。如果当前时间还没超过预算说明消息可能被Handler早处理了几百毫秒此时直接放弃判定。只有确实超过了系统才会继续往下走。同时系统还要确认这个ServiceRecord还处在“正在执行”的状态也就是executeNesting大于0而且service.app字段指向的进程对象还活着。一旦发现Service已经执行完毕、只是回调晚了一点同样不会判ANR。换句话说ANR不是“消息超时”就自动触发而是“消息超时 任务状态确实还挂着”双重确认后的结果。3.2 appNotRespondingtraces落盘、杀进程、弹窗的起点确认Service真的超时后serviceTimeout会调用AMS的错误处理入口通常表现为appNotResponding或后续版本的AMSErrors.appNotResponding。这一步是整个ANR机制的总闸门后续所有事情都从这里分叉。appNotResponding里做的事情非常多但可以归纳成三条主线收集现场信息把/data/anr/traces.txt路径下的进程调用栈写出来同时抓取各线程的Java栈和Native栈还会记录内存信息、CPU使用率排名等。决定要不要弹窗系统会根据App在前台还是后台、开发者选项里有没有开启“显示后台ANR”、系统是否处于锁屏等场景决定是直接弹“未响应”对话框还是静默处理完就杀掉进程。准备善后在用户点击“关闭”或系统强制杀进程之前AMS会调用killProcessGroup或Process.killProcess把目标进程结束避免一个病恹恹的进程继续在系统里占着位。弹窗本身不是判定动作的终点只是一个面向用户的交互入口。对无头服务的后台ANR系统可能完全不弹窗直接把traces写进DropBox然后悄悄杀掉进程。这也是为什么很多线上Bug统计平台只上报了ANR in Service却没有任何用户反馈的画面——因为用户根本看不到对话框。3.3 关键判断条件executingStart、executeNesting与进程状态把源头源码摊开看决定Service ANR成立的条件可以简化为三个超时消息到点时now - r.executingStart r.executingStart timeout中的timeout值已经耗尽r.executeNesting 0说明任务还挂在执行栈上r.app ! null proc ! null proc.processName...说明目标进程还在运行。只要这三个条件同时成立系统就不会再等业务代码的返回直接把它定性为Service ANR。所以排查Service ANR时最该问的问题是onCreate、onStartCommand或onBind这些方法到底为什么没有按时Binder回调AMS的serviceDoneExecuting是栈顶卡住了还是线程根本来不及执行4. 高频触发场景与traces特征先知道去哪儿找根因4.1 主线程同步等待Binder远端调用Service生命周期方法跑在主线程主线程卡住的最典型场景是做了同步Binder调用。比如在onStartCommand里调用了一个跨进程接口而远端服务本身也卡了或者远端服务所在的system_server进程Binder线程池已经满了。此时主线程会卡在BinderProxy.transactNative上迹象就是traces文件里主线程栈顶出现binder_thread_read或IPCThreadState.waitForResponse。这类问题的迷惑性很强先卡的可能是一个内容提供者或系统服务的Binder线程但最先掉进ANR的是主线程。我在处理一个后台音乐播放器的ANR时就遇到过onStartCommand里调了MediaSessionManager的某个接口而那个机型恰逢系统进程在重启媒体服务Binder调用等不到远端响应整个Service就被判了ANR。4.2 死锁与锁竞争两个线程互相等锁的典型现场Service ANR的另一个高发原因是锁竞争最常见的是主线程持有一个锁同时去等另一个线程持有的锁而那个线程又在等主线程手里的锁。Java层的synchronized、ReentrantLock、还有经典的“等待唤醒丢失”问题都会让主线程的栈停在park或wait上。这个在traces里特别容易辨认主线程栈顶是java.lang.Object.wait后面跟着一行at com.example... synchronized而另一个线程栈顶正好在同一个对象的notify附近。还有一种少见但很要命的锁竞争发生在system_server内部如果AMS或ActivityManagerGlobalLock被某个卡住的调用持有App侧的startService请求就算只是排队也会迟迟得不到回应。最后体现出来的不一定是Service生命周期超时而是进程长时间无法完成服务回调。这时traces里主线程可能并没有卡它甚至还在正常跑业务代码真正卡的是AMS的binder调用。这类问题已经超出App自身代码的范围需要检查system_server的traces。4.3 业务代码太重磁盘IO、大计算、网络等待堆满了主线程第三种高频场景最直白——onCreate和onStartCommand里塞了太多东西。我见过有人直接在Service的onCreate里做数据库全量升级几百MB的数据操作把主线程整整占住了30秒前台20秒一过系统立刻判定ANR。也有人把网络库的同步请求放在onStartCommand里一次超时重试就漏到了25秒。这种场景的特点非常清晰traces里主线程栈指向业务代码栈顶往往是一个new File、db.query、或OkHttp的同步execute调用。它不是死锁、不是跨进程等待就是单纯的慢。只要把耗时操作挪到子线程、WorkManager或协程里问题就能解决。下面用表格总结一下三类根因的特征方便对照排查根因类型主线程栈顶特征其他线程特征定位方向Binder同步调用卡住BinderProxy.transactNative、binder_thread_read远端线程可能也卡在Binder检查远端服务、system_server是否异常锁竞争/死锁Object.wait、LockSupport.park另一个线程持有同一把锁检查锁的获取顺序、超时等待策略业务代码耗时过高文件IO、网络请求、复杂计算基本正常无堵塞代码Review改用子线程5. 快速定位Service ANR的四个调试手段5.1 复现让一个Service稳定触发ANR调试的第一步是稳定复现。最简单的方式是写一个Demo在Service的onCreate里把主线程卡住21秒以上前台Service就能稳定触发。推荐用SystemClock.sleep而不是Thread.sleep因为前者不会被中断更能模拟卡死状态public class TestService extends Service { Override public void onCreate() { super.onCreate(); SystemClock.sleep(21000); } Override public IBinder onBind(Intent intent) { return null; } }启动前台服务时记得加startForeground或者通过startService的方式在App处于前台时触发。这样一次ANR的文件现场就有了。如果不想写代码也可以把Settings.Global.HIDE_ERROR_DIALOGS关闭然后在开发者选项里打开“显示所有ANR”配合adb shell am start -n快速拉起目标服务。但纯靠线上复现很费时间还是本地小Demo效率最高。5.2 直接抓取ANR日志DropBox和traces双管齐下真正的生产环境不能加SystemClock.sleep那就依赖系统落下的日志。Android每次发生ANR系统除了向DropBox写入system_app_anr事件还会把最快的调用栈写入/data/anr/下的traces文件。常用的排查命令是adb shell dumpsys activity processes | grep -i anr adb shell dumpsys dropbox --print system_app_anr adb shell ls /data/anr adb pull /data/anr/traces.txt需要注意Android版本不同traces文件可能叫traces.txt也可能是traces_xxx这种按进程拆分的文件。如果线上权限不足可以用adb bugreport拿到完整的ANR现场里面会自动包含dropbox和traces的关键信息。拿到文件的第一件事不是看主线程而是看“Cmd line”是否符合刚才崩溃的进程名。5.3 读traces的技巧主线程、system_server、CPU负载一起看很多人拿到traces后就盯着主线程看这其实不全面。一次Service ANR的traces会被分割成三块有价值的信息主线程调用栈看它最后停在哪判断是死锁、Binder等待还是耗时任务。目标进程其余线程看有没有持锁的线程、GC线程是否高频、binder线程池是否耗尽。系统进程system_server相关线程看AMS的Handler线程有没有被什么操作长时间占住。我在排一个疑难ANR时发现主线程栈干干净净停在Looper.loop附近根本不像卡死。后来看到system_server的binder线程全部处于waiting to lock状态才意识到是整个system_server侧发生了Binder线程池打满。主线程虽然在等一次ipc响应但真正的病根在系统侧。如果你只盯着自己进程的栈看这个case永远也找不到答案。5.4 观看实时因子dumpsys activity service与CPU排行如果问题偶尔复现比较适合在事发时快速抓dumpsys。dumpsys activity services会列出当前所有ServiceRecord的状态重点关注字段executingStart和isForeground。当某个Service的executingStart距离当前时间已经很久时它很可能正在走向ANR。CPU排行同样重要因为系统判ANR时会附带一份CPU统计。如果一个App后台持续占用高CPU主线程迟迟得不到调度即使业务代码逻辑没问题也会被活活拖到超时。低端机上特别容易这样CPU忙不过来了代码执行速度远慢于正常水平20秒可能只够做完正常5秒能做完的事。6. 容易被忽略的边角场景与长期经验6.1 200秒不是免死金牌它会被系统繁忙“吃掉”很多人看到后台Service有200秒就觉得非常安全甚至把大型数据库迁移直接放在后台Service里做。实际上200秒是一个闹钟预算前提是进程能持续被调度、主线程能够正常往下跑。如果设备本身处于低内存状态、进程被系统限制在后台帧率、或者CPU被其他高频任务占满那200秒的时间损耗会远超你的预估。我经历过一个非常极端的案例App在后台跑一个上报服务正常状态下一两秒就能执行完结果某低端机上竟然连续报Service ANR。看traces发现主线程只做了一次小型的数据库查询但它前后经过了几个小时的延迟因为进程被系统深度冻结执行被打散。这种ANR代码层面几乎无解唯一的出路是拉高进程优先级或者改用WorkManager这种延迟可容忍的任务机制。6.2 ANR弹窗之后进程不一定会被立刻杀很多开发者以为只要弹了ANR进程马上就会被杀掉。实际情况是系统弹窗之后会等用户点击“关闭”或“等待”。用户如果点了“等待”进程不会死只是那笔ANR记录已经写入系统。这一点在做线上监控时尤其重要不要用进程是否存活来判断ANR是否发生要以DropBox和/data/anr/里的记录为准。如果你的错误监测平台通过监听进程死亡来堆ANR那后台静默ANR可能漏掉一大半。推荐用FileObserver监听/data/anr/目录或者直接在系统侧接ActivityManagerInternal.notifyAnr回调才能抓到完整的ANR事件。6.3 “等待”按钮背后ANR的恢复机制和陷阱用户在ANR对话框上点了“等待”表面上看进程又能继续了但潜在风险并没有完全解除。Service的生命周期回调一旦超时AMS的ServiceRecord状态可能已经处于一种“执行未完成”的边界情况即使业务代码随后跑完了并回调了serviceDoneExecuting系统也要做一堆状态清理。有些版本的老机器上这里还会引发后续的ServiceCarlock问题导致服务再也无法被stop。所以线上如果允许最好把耗时任务彻底移出主线程不要把希望寄托在“系统给了等待机会”上面。同一个Service频繁ANR就算次次点等待最终也会被系统加入“已损坏服务”名单后续再启动就容易被直接跳过或快速判定失败。6.4 关于Service ANR监控的一点点经验框架层面做ANR监控很多人会想到用ApplicationThread做代理或者在主线程Looper里埋dispatch的时间统计。但Service ANR和Input ANR不一样它的触发完全在AMS侧单纯监控主线程卡顿并不能完全覆盖Service生命周期超时的情况。更可靠的方式是定期轮询ActivityManager的进程状态和ServiceRecord执行状态或者接入系统能力直接监听/data/anr/文件变化。我个人在实际项目中试过很多套方案最后觉得性价比最高的是在应用内设置一个低精度的“心跳”业务方在Service的关键生命周期方法入口埋点开始执行时记录时间结束回调时记录时间如果某个生命周期方法超过前台20秒或后台200秒先于系统的ANR弹窗上报自己埋的“风险事件”。这套方案不需要系统权限而且能覆盖系统不弹窗的后台ANR场景。写在最后的实战体会Service ANR这条链路看起来是一条简单的“起服务-计时-超时弹窗”流水线但真正排查起来你会发现它串起了Binder机制、主线程调度、system_server状态、进程优先级等一大片内容。我自己的习惯是每次遇到新的ANR都先把traces里主线程、进程内其他线程、system_server三份栈都扫一遍再结合dumpsys和DropBox交叉确认基本能避免80%的误判。最后再分享一个容易翻车的细节如果你在traces里看到主线程停在ActivityThread.handleStartService附近不要急着说“就是Service启动太慢”。handleStartService后面跟着的ICallback调用栈会显示真正慢的地方有可能是系统在等你的代码返回也有可能是system_server的binder线程池满了。先确认对端再在自己的代码里找罪证这是我处理了若干个“假Service ANR”之后悟出来的经验。