Android ANR治理实战：从监控体系到系统性优化

1. 刚接到 ANR 治理这个需求时我在想什么先说个真实经历。去年年中我们应用在线上陆续暴露出几类卡顿和“无响应”问题用户的反馈渠道里出现频率最高的词是“卡死”“点了没反应”“过一会儿闪退”。后台聚合到的系统日志里ANR in ...这个关键字出现得越来越频繁。当时团队几个同学的第一反应是“先把最近提交的代码排查一遍”但翻了将近一周改了若干可疑模块问题依旧间歇性复发。我意识到这已经不是一两处代码 bug 能解释的事而是整个应用在特定场景下的系统性问题。ANRApplication Not Responding的直译是“应用无响应”。它不像崩溃那样会立刻留下一个异常堆栈也不会在测试阶段稳定复现。它更像是系统在后台悄悄给你的应用记了一笔“超时账”等用户明显感知到界面卡住时问题其实已经发生了很久。真正做过线上 ANR 治理的人都会有一个体会能拿到一份完整的 ANR 现场数据比修复十段可疑代码更有价值。这篇文章想聊的是我在处理 ANR 问题过程中沉淀下来的一套思路——怎么理解 ANR 的触发机制、怎么搭建有效的监控与数据体系、怎么从根源上做系统性优化而不是“头痛医头、脚痛医脚”。它适合两类人看一类是已经遇到线上 ANR 问题、正在排查但感觉“无从下手”的 Android 开发另一类是准备牵头做稳定性治理、想建立一套完整方法论的技术负责人。如果你还停留在“ANR 就是主线程耗时太长”的认知阶段那这篇文章或许能帮你打开一个更大的视角。2. ANR 的本质是系统对“无响应”做了量化判断2.1 先搞清楚系统里的“计时器”从哪来一聊到 ANR最容易想到的是主线程卡顿。但这个认知只说对了一半。ANR 的本质是 Android 系统对“应用交互无响应”的量化判决而“无响应”的判定有多个维度和多条路径。系统在运行过程中会不断地向应用进程发送各类消息、事件或调用。当这些请求在特定时间内没有得到应有的反馈system_server进程中的AMSActivityManagerService就会触发 ANR 弹窗或写入日志。换个更容易理解的说法系统手上有一堆秒表你每接一个关键任务它就按下计时超时未完成就会被记为一次“失信行为”。哪些操作会被计时常见的有这几类输入事件分发Input dispatching用户触摸屏幕后事件要在 5 秒内完成分发与处理否则算超时。广播接收BroadcastReceiver的onReceive执行超时前台广播 10 秒后台广播在某些版本上 60 秒不同 Android 版本存在差异。服务启动与绑定Service的生命周期回调超时前台服务 20 秒后台服务 200 秒。ContentProvider启动进程启动或 provider 初始化超过一定时间会被视为 ANR。这些时间阈值在不同版本上有细小的差别但核心思路一致系统在给你“响应窗口”窗口内完成皆大欢喜超出窗口就记录现场、提示用户“继续等待”或“关闭应用”。2.2 输入事件的“5 秒窗口”为什么最关键实际线上数据里输入分发型 ANR 占比最高。它的触发逻辑可以细分成三层事件从屏幕驱动到窗口再由窗口分发给应用应用处理完后再绘制反馈。只要某一层出现了拥堵“无响应”就会被记录。有个细节很值得留意输入 ANR 并不完全等价于主线程卡死 5 秒以上。系统重点检查的是事件事件是否被及时处理如果主线程正在处理一个耗时的 Binder 调用或等待锁释放事件就会排在 Looper 消息队列里迟迟得不到执行。这时候即使主线程 CPU 占用不高同样会触发 ANR。我遇到过一类典型案例某个列表页的OnClick事件里触发了网络请求请求回调里再执行数据库读写数据库又是跨进程访问整个链路在极端情况下耗了 7 秒。从 CPU 利用率看主线程并不忙它大部分时间在等待但对用户来说就是“点击没反应”。这种类型如果不看系统 ANR trace 文件里的waiting for lock信息很难定位到真正的瓶颈。2.3 容易被忽略的 CPU 饥饿型 ANR除了四大组件和输入事件还有一类容易被忽略的 ANR 是CPU 饥饿型。当系统整体负载过高你的应用进程虽然线程都在“努力干活”但分不到足够的 CPU 时间片关键任务的执行时间被无限拉长最终也会触发 ANR。这类问题在低端机型、多任务场景下特别常见。出现 CPU 饥饿时ANR trace 文件里的主线程堆栈往往看起来“什么也没干”——它可能正在执行一次极普通的TextView.setText但因为进程拿不到 CPU普通得不能再普通的操作也变成了压死系统的“最后一根稻草”。想要区分是“主线程自身卡顿”还是“CPU 饥饿”可以观察/data/anr/下生成的 trace 文件里CPU usage概况部分。如果系统整体 CPU 占用接近 100%并且你的应用进程 CPU 占用也不低那大概率不是单点代码问题而要从整体资源占用和后台任务密度入手治理。我从实践中的体会是理解 ANR 的多路径触发机制是后续治理工作的基础。你连系统在计时的“入口”都没弄明白又怎么可能做到精准优化3. 监控与数据建设没有高质量现场谈不上排查3.1 基础信息的采集要有“标准化思维”ANR 触发的第一时间系统会在/data/anr/目录下生成 trace 文件。线上环境拿不到 root 权限时可以通过FileObserver监听 ANR 目录文件的变化再把文件内容拉取出来上传。这是行业内比较成熟的线上 ANR 监控方案之一。拿到原始 trace 文件后不能直接丢到日志系统里就完事。我见过不少团队“守株待兔”式地收集了几百份 trace等真正要用的时候发现大部分文件的堆栈相同问题场景的信息严重缺失根本没法做归因分析。有效做法是提前做好以下标准化动作解析Cmd line: com.xxx.xxx确认进程名和 ANR 类型。抓取CPU usage段记录进程 CPU 占用、系统整体负载。截取主线程堆栈、Binder 线程堆栈、正在等待锁的线程。记录触发时间、系统版本、机型、应用版本、页面路径。这些字段要提前定好格式统一入库。只有数据字段稳定了后续才能做聚合分析才能在几分钟内筛选出“哪类机型、哪个版本、哪个页面出现的 ANR 最多”。3.2 现场快照环境信息比堆栈更值钱很多人看 ANR trace 只会盯着主线程的堆栈这一步会错过大量关键线索。我的经验是ANR 的堆栈只是“果”环境和线程状态才是“因”。比如一份 trace 里主线程卡在了Binder:3283_A的调用等待上而看完整的线程列表你发现应用有 80 多个线程其中有一大半线程都阻塞在某个统一的连接池锁上。这类信息只有结合全局线程快照才能看出来。为了更准确地还原现场除了系统 trace 之外我还会同步采集这些数据应用内存快照Available Memory、低内存 kill 相关指标。关键用户操作路径用户点击到哪个页面、触发什么业务逻辑。前后台切换状态、网络状况。设备剩余存储空间、电量等环境维度。这些现场信息在后续判断“这是个例还是普遍问题”时起到决定性作用。一个 App 在低端机上因为内存压力触发 ANR 的概率和它在中高端机上因为某段代码缺陷触发 ANR 的概率是完全不同的两个层次的问题治理策略也有天壤之别。3.3 线上聚合学会从海量日志里分辨“假重点”有一个容易踩的坑聚合统计时机器按主线程堆栈的“出现次数”排序排在最前面的永远是那几个高频模块但修复它们可能对整体 ANR 率的影响并不大。后来我改用“ANR 率 × 单次影响用户数 × 单次卡顿时长”的优先级算法。举个例子某个模块的 ANR 出现次数只占 2%但这 2% 的用户集中在机型 A 上且每次 ANR 前用户都完成了“下单流程”那么它的优先级就高于那些次数多但都发生在后台空闲场景的卡顿。聚合维度的设计建议包含这几类系统版本维度、机型维度、应用版本维度、页面维度、网络状态维度。每个维度拉出来的 TOP 列表都有不同的优化指向。版本维度指向回归问题机型维度指向兼容问题页面维度指向业务逻辑问题。做监控数据体系本质上是在搭建一个“回溯现场”的能力。数据不全时排查靠猜数据全了排查靠比。这两种效率不在一个量级。4. 从两个真实场景复盘 ANR 治理的全过程4.1 场景一主线程直接做文件读取被 StorageManager 卡住线上某反馈较多的模块用户连续点击相册图片时偶发 ANR。拿到 trace 后主线程堆栈停在FileUtils.copyFile相关的文件读取逻辑上。一开始大家都以为只是文件太大、拷贝太慢方案是加异步处理。但仔细看 trace发现线程实际卡在StorageManager的一个跨进程调用上。应用读取文件时会先向系统服务查询存储设备的挂载状态和剩余空间而系统服务这一侧因为同时处理大量类似请求出现阻塞导致我们应用的调用一直等不到响应。这个案例的启发有二文件操作本身的耗时并不等价于真正的性能瓶颈。当文件读取涉及跨进程查询时主线程的卡顿可能是“间接等待”导致的。即使迁移到子线程也要关注线程池满负载导致的排队问题。采取的治理措施包括将文件拷贝、压缩、上传等操作统一收敛到子线程专用线程池并使用内存缓存避免重复读取小文件在核心路径上通过预查询存储状态提前规避系统服务的繁忙时段将部分 FileProvider 跨进程读取改为应用内直接访问。4.2 场景二线程池被打爆关键业务链路“等不到线程”另一个案例来自首页信息流。用户快速滑动时页面偶尔卡住出现“黑屏几秒”或点击无反应。trace 里主线程堆栈并不复杂甚至看不出明显的耗时操作但应用线程总数异常高大量线程处于waiting状态。进一步排查发现信息流模块早期开发时为了“性能更好”每来一条数据就 new 一个线程去处理图片解码后来虽然替换成了统一线程池但线程池的阻塞队列被设计得过大任务峰值期间阻塞队列堆积超过 2000 个任务。图片解码本身不算慢但堆积的任务把工作线程全部占满其余所有需要线程池的后台任务都在排队连主线程要访问某个 Binder 服务时对应的同步回调也只能排队等待。这类问题的本质是线程资源分配失控。它不直接体现在主线程堆栈上却通过资源挤兑间接拖垮了主线程。治理动作分几步走把图片解码线程池改造成有界队列模式队列满了以后拒绝新任务并采用“最近最少使用”淘汰策略把核心业务链路单独划分专用线程池与图片解码等非核心任务隔离对线程池的核心线程数和最大线程数设置监控指标超过阈值触发告警。改造之后信息流模块的 ANR 率下降了一半以上。5. 系统性的优化策略线程、IO、锁与 Binder 调用5.1 线程治理规范化先定规则再谈性能线程是消耗资源的最小单位但恰恰是很多团队治理最随意的地方。命名随意、数量不设上限、生命周期管理缺失这些问题叠加起来会在高并发场景下造成严重的资源挤兑。线程规范化的几个要点必须命名ImgDecode-Thread-1、NetWork-Thread-2这种命名在排查时能大幅节省定位时间。统一线程池每个业务模块自己管理线程池严禁到处new Thread。统一线程池能控制总线程数避免无限增长。有界队列队列容量要结合业务峰值合理估算不能“想着越大越好”。队列越大延迟响应越明显。核心线程复用避免频繁创建销毁线程带来的调度开销。线程治理的目标不是“消灭线程”而是让线程的使用变得可预测、可管理、可追溯。5.2 IO 治理把“慢操作”从主线程彻底拆走主线程不适合做任何可能阻塞的操作这个原则大家都知道但实际落地时经常出问题。原因是很多 IO 操作看起来“挺快”比如读取一个SharedPreferences、获取一次系统时间但放在低端机上、系统繁忙时这些“挺快”的操作会放大成几百毫秒甚至秒级。IO 治理的常规操作清单目录遍历、文件统计、图片加载、数据库查询、SharedPreferences 提交全部切到子线程。对高频读取的小文件做内存缓存比如配置类 JSON 文件。启动阶段针对预热提前加载启动时需要读的关键文件避免冷启动时在关键路径上做同步读取。了解系统服务调用的“隐含耗时”像PackageManager查询、LocationManager获取最后已知位置等操作虽然调用很“简单”但背后都有跨进程通信和系统服务处理的开销。5.3 锁竞争优化解决“多线程等着同一把钥匙”的问题锁竞争是 ANR 的常见元凶之一。当多个线程同时访问共享资源一个线程持有锁迟迟不释放其他线程只能排队等待。如果这些“其他线程”是主线程的依赖方或者主线程正在等待其中一个线程的结果ANR 就会发生。优化锁竞争可以从这几个方面下手缩小锁粒度原来锁整个方法改成只锁需要同步的那一段代码。减少锁持有时间不要在持锁状态下做 IO、网络等耗时操作。考虑读写分离读多写少的场景用ReentrantReadWriteLock替代完全互斥的synchronized。避免锁嵌套多个锁叠加容易形成死锁或“等待链”尽量设计成一次性获取所有资源。有一个容易被忽视的细节synchronized修饰在方法上时锁的范围是整个方法体。重构时建议把synchronized放在方法内部的最小代码块。这一点改动虽然不起眼在高频调用场景下对主线程等待时间的影响很明显。5.4 Binder 调用轻量化少跨进程、少等反馈Binder 是 Android 系统里非常核心的跨进程通信机制。应用与系统服务、应用与应用之间的很多交互都要通过 Binder。跨进程调用有固定的开销并且如果系统服务侧繁忙调用方会长时间阻塞等待。治理思路有这些合并跨进程调用比如查询多个系统属性时不要一个属性一个属性地调用尽量合并成一次调用。避免在主线程做 Binder 同步调用能异步就异步等回调回来再刷新 UI。留意隐式 Binder 调用PackageManager、ActivityManager、WindowManager的很多方法内部都有 Binder 开销调用时要有意识地评估。6. 从“单点修复”到“系统性优化”借鉴数据治理的方法论6.1 为什么单点排查往往治标不治本回到开头的问题。为什么当初我们团队“改了若干个可疑模块问题还是复发”现在回想起来症结就在于我们一直在做单点排查看到主线程卡在某段代码就优化那段代码但没想清楚这段代码为什么会在那个时间点卡住。一个 ANR 的背后往往是线程资源、系统环境、业务调用链、设备性能多个因素叠加的结果。这让我联想到很多团队推动数据治理时的经历。数据治理里有一句常说的话“数据的问题常常不是数据本身的问题而是流程和机制的问题。”ANR 治理也是同理。举一个网上经常被提到的“美的主数据治理”里的案例一颗螺丝钉坏了如果只替换螺丝钉过段时间还会坏如果分析螺丝钉为什么会坏发现是固定方式不对再往上分析发现是设计规范缺失。最后要改的不是某颗螺丝钉而是整个设计规范。6.2 建立“可观测、设门槛、能回溯”的闭环机制系统性优化要求我们从“被动救火”转向“主动防控”关键是建立一套完整的闭环机制第一层是可观测。所有关键路径的耗时、线程池状态、ANR 现场信息都要有数据。没有观测就没有评估没有评估就没有优化方向。第二层是设门槛。把 ANR 率、主线程卡顿率、关键接口耗时纳入版本发布的准入门槛超过阈值不允许发布。很多团队做稳定性治理做不下去不是因为技术不够而是因为“改坏了也没人知道”没有强制约束。第三层是能回溯。线上问题可以通过聚合数据快速定位到模块、页面、机型而不是靠用户反馈一句“很卡”来回猜。这整个机制的本质是把一次性的“问题修复”变成持续的“质量经营”。6.3 分级治理不同级别的 ANR 用不同策略最后分享一个实用的分级治理策略。不是所有 ANR 都值得投入同样多资源去修复要按影响面和控制力来分级P0 级高频、影响大量用户、阻塞核心业务流程立即介入专项小组推进修复。P1 级中频、有明确触发路径纳入当个迭代重点优化。P2 级低频、只发生在特定机型或特定网络环境建立观测持续跟踪。P3 级单例问题、发生在极端场景记录归档作为后续优化参考。分级治理能避免团队把精力浪费在“永远修不完的偶发问题”上把人力集中到影响最大的方向。根据我个人实操几十次 ANR 治理下来的体会ANR 治理最难的从来不是某个技术难点而是你能不能从“补丁思维”切换到“体系思维”。今天修一个卡顿、明天优化一个 IO永远追着问题跑人累效果也有限。反过来先把监控做扎实、把线程和 IO 规则立起来、把关键链路的性能门槛卡住你会发现真正需要修的“点”越来越少因为大部分问题在发生之前就被机制挡住了。这篇内容如果对你有用可以直接按照里面的监控采集规范和数据聚合方法去试一遍。先跑通一个模块的 ANR 采集再扩大范围体系就会慢慢长出来。祝你少看几个让人头秃的 trace 文件。