1. 写在前面为什么还需要再聊 ANR如果你已经处理过几轮 ANR 问题你一定有过这种经历线上偶现“应用无响应”日志却干干净净Logcat 里没有异常堆栈主线程 trace 看起来只是停在一个普通方法上。你把 trace、CPU 信息、内存信息都拉下来却找不到一个能直接拍板的“元凶”。这种问题往往不是简单的主线程死循环或 sleep而是多个子系统耦合在一起或者由特定时序、特定机型、特定业务状态触发的复杂场景。ANR 全称 Application Not Responding系统通过一套超时机制来判定应用是否“无响应”。这套机制覆盖了输入事件派发、广播执行、服务执行、内容提供者启动等多个入口。你在网上能搜到很多基础排查文章讲的无非是“看 trace 里主线程在干嘛”但一旦遇到真正的复杂场景照搬这些套路往往要花很长时间才能有点头绪。这篇文章不讲“ANR 是什么”这种入门概念而是直接聚焦复杂场景下的定位思路与根因分析。我会从系统判定机制出发拆解几个我实际处理过的案例把 trace 分析、日志采样、复现实验、代码走查这些步骤串成一套可复用的方法论。适合已经被线上 ANR 困扰、想系统提升排查能力的 Android 开发同学尤其是负责性能优化或线上稳定性维护的工程师。2. 复杂场景定位的前提先把“系统如何判定 ANR”吃透2.1 别把 ANR 当成一个“异常”它是一套超时状态机很多开发者看到“ANR”就本能地去找 crash 堆栈这个习惯在复杂场景下会害死人。crash 是 RuntimeException 或 native abort程序真的挂了堆栈能直接告诉我们哪里出了问题。但 ANR 不一样它只是一个进程被系统判定为“超过指定时间没有完成某类操作”的状态进程可能还活着业务线程可能还在正常运行只是主线程卡在某个关键路径上。系统对 ANR 的判定分散在多个系统服务里。输入事件由 InputDispatcher 监控看看事件从派发到被应用消费是否超时广播由 ActivityManagerService 统计看看 BroadcastReceiver 在 onReceive 里是否执行过久服务、ContentProvider 同样有各自的超时阈值。不同 Android 版本的阈值不一样不同厂商还会改甚至同一台设备上不同场景的超时时间都不同。我见过不少同学只看/data/anr/traces.txt里的主线程堆栈就下结论这在简单场景下确实有效但复杂场景下经常误判。原因很简单ANR trace 是系统在超时那一刻抓取的快照主线程当前卡住的位置往往只是结果不是原因——真正的原因可能是持锁线程一直占着锁主线程只是 Blocked 在等待可能是 Input 事件在前台 Activity 还没起来之前就派发了可能是 Binder 调用等待系统服务响应而系统服务本身被别的进程拖住了。所以要定位复杂 ANR第一件事就是把“系统判定机制”和“应用侧表现”分开看。trace 截图只是应用侧的“案发现场”系统侧的时间点、事件流、CPU 占用、内存压力才是完整证据链。2.2 系统判定机制细节从三类典型超时说开去来看三类最常遇到的 ANR 类型。第一类InputDispatching Timeout。这是最常见的一类用户触摸屏幕或按键后事件已经派发到应用进程但应用在规定时间内没有完成事件处理。注意这里有一个容易忽视的点系统并不是只要主线程在 busy 就会判定 ANR而是 InputDispatcher 等待应用的 finish 回调超时才会触发。如果主线程在死循环里转圈Input 事件无法被消费最终会超时如果主线程只是排队等待但事件处理被其他逻辑阻塞同样会超时。判定时机取决于“事件从派发到处理完成”的耗时而不只是主线程当前正在执行的函数。第二类Broadcast Timeout。分前台和后台前台广播超时时间很短通常是 10 秒左右不同版本有差异后台广播超时时间则宽松很多。很多复杂场景里的广播超时并不是 onReceive 里真有阻塞逻辑而是广播处理被 Binder 调用拖住或者被 onReceiver 里启动的异步任务间接影响而 onReceive 本身已经返回。这块是不少团队容易踩坑的地方——明明 trace 显示 onReceive 已经执行完了为什么还会出现广播 ANR因为系统统计的是整个广播分发过程包括 receiver 所在进程的调度队列、cold start 耗时、Binder 通信耗时这些都会累计进超时判断。第三类Service Timeout 与 ContentProvider Timeout。Service 的 ANR 通常出现在onStartCommand或onCreate里执行了重量级操作。ContentProvider 的 ANR 比较隐蔽应用冷启动首次访问 provider 时如果 provider 的onCreate耗时过长系统会在客户端等待时直接判定超时这种问题在启动链路优化中非常常见。其实归纳下来ANR 的本质就是一句话系统给某个消息处理路径设定了一个 deadline应用没有在 deadline 前完成处理而且系统觉得责任在应用。所以真正高级的定位是围绕“这条路径上到底哪一段耗时超标”来展开而不是只看主线程卡点。3. 拿到一份 ANR 报告复杂场景的第一步还原现场3.1 别急着看堆栈先整理证据时间线线上 ANR 的常见数据来源有哪些/data/anr/traces.txt或dropbox目录下的anr_*文件、Logcat 里的ANR in ...日志、events_log里的 am_anr 日志、system_log里的系统服务日志以及厂商自带的性能日志。如果你们接入了自建崩溃平台或 APM可能还有额外的 trace 和线程采样。我个人的习惯是先不打开 traces.txt 看具体堆栈而是先把所有能拿到的日志按时间线排列搞清楚事件顺序。举个例子假设日志里写着ANR in com.example.app (com.example.app/.MainActivity)对应的时间点、进程 CPU 使用率、am_anr日志里的详细信息、以及 ANR 前 3 秒内 Logcat 有没有应用自身打印的业务日志这些都必须先列出来。还原现场有一个关键技巧在am_anr日志里有一个reason字段系统会明确写出触发原因。比如reasonInput dispatching timed out (Waiting because the focused window has not been finished processing the input event...)。这个 reason 已经把范围缩小了——是输入超时不是广播或服务。很多同学不留意这个字段直接翻到普通线程堆栈里去大海捞针其实是耽误时间。3.2 Trace 文件的正确阅读顺序从整体到局部拿到 traces.txt 后我推荐按这个顺序去读先看文件头部是否有----- pid xxx at yyy -----和Cmd line: ...确认这份 trace 对应的进程和抓取时间点。如果一份 traces.txt 里有多个进程片段优先找目标 ANR 进程的部分。找到目标进程后先看main prio5 tid1这个线程这是主线程。把它的状态Running、Blocked、Waiting、Native和当前堆栈记下来。再看Binder:xxxx_x等 Binder 线程的堆栈以及FinalizerDaemon、FinalizerWatchdogDaemon、RenderThread等关键线程。特别是 RenderThread如果它阻塞可能间接影响主线程事件消费。查看进程 CPU 使用情况。trace 文件里如果包含CPU usage from ...片段会列出各个进程的 CPU 占用比例以及 ANR 进程内各线程的 CPU 时间。这部分信息量极大能直接告诉你主线程是真正在跑Running还是阻塞等待Blocked/Waiting。简单总结如果主线程是 Running 状态且 CPU 时间很高大概率是主线程在执行高耗时计算或者死循环如果主线程是 Blocked 状态就要看它等待的锁被谁持有如果是 Native 或者 Waiting则要结合 Binder 调用、JNI、系统服务 IPC 来考虑。4. 复杂场景根因分析的核心技术手段4.1 锁分析从主线程阻塞到“谁持有锁”复杂 ANR 里锁等待占了相当大的比例。主线程堆栈往往长这样at com.example.business.DataManager.getData(DataManager.java:120) - waiting to lock 0x123456 (a java.lang.Object) held by thread com.example.business.NetworkThread at com.example.ui.MainActivity.loadData(MainActivity.java:80) at com.example.ui.MainActivity.onResume(MainActivity.java:45)这条堆栈说明主线程在等待DataManager.getData方法里的对象锁而这个锁被NetworkThread持有。如果 NetworkThread 只是正常执行几毫秒主线程不会 ANR但如果 NetworkThread 本身在做网络请求且没有超时或者持锁后又在等待另一个锁就可能发生锁链式阻塞。我处理过一个印象很深的案例主线程等待锁 A持锁线程是某个后台线程。这个后台线程获取锁 A 后又去等待锁 B而锁 B 的持有者是 Binder 线程。Binder 线程又在等待主线程处理某个 Binder 请求。四个线程形成环形等待直接死锁。主线程的 ANR 只是表象真正的根因是锁顺序设计不合理导致死锁。定位锁问题时光靠 traces.txt 里的主线程堆栈不够还要把持锁线程的堆栈也抓下来逐个排查锁的依赖链。系统在生成 ANR trace 的时候会为每个线程打印堆栈而且 Java 层waiting to lock、locked这些关键字会标注线程锁状态。如果你发现一个线程堆栈里同时出现locked 0x...和waiting to lock 0x...这就是一个锁链节点。从工程角度说解决这类问题有两条路第一条是规范锁的使用能不用锁就不用锁必须用锁时保证锁粒度足够小且锁顺序一致第二条是针对动态锁链死锁用可视化工具比如jstack的补丁版甚至自研死锁检测去记录锁获取路径。Android 上虽然不像后端 JVM 那么方便但你可以在代码里对关键锁加上超时获取机制用tryLock替代synchronized在获取失败时打进日志。这个改造成本不高收益却很明显。4.2 Binder 调用分析主线程看起来没事其实是卡在 IPC 上Binder 是 Android 进程间通信的基石但大部分业务代码不会直接出现android.os.BinderProxy.transact以外的明显特征。主线程调用系统服务或跨进程服务时会进入 Binder 驱动等待此时线程状态可能是Binder或Native。如果系统服务响应慢或者另一个进程卡死Binder 调用就会一直等待。复杂场景里有一种特殊情况主线程调用自己进程里的另一个 Binder 服务而该 Binder 服务的执行线程池已满或死锁导致主线程的 Binder 调用长时间得不到响应。这种情况在 trace 里往往表现为主线程停在BinderProxy.transactNative或SomeAIDL$Stub.onTransact但那个 Binder 服务所在进程的某个 Binder 线程堆栈可能是 Blocked 状态。定位 Binder 超时有几个实用技巧。第一抓取 trace 时留意Binder:xxx线程数量如果核心 Binder 线程全部阻塞往往是某个系统服务有问题。第二在 Logcat 中搜索binder_sample或am_anr相关日志Android 的 Binder 统计日志会记录耗时调用。第三对于跨应用 Binder尽量在 debug 环境下用systrace或 Perfetto 抓取一段时间内所有 Binder 调用的耗时分布这比临时加日志要高效得多。我在实际排查中有一个固定动作如果 ANR trace 里主线程停在 Binder 调用上我会立刻检查这段 Binder 调用是否在一段时间内反复出现并配合dumpsys activity processes查看目标服务进程是否处于无响应状态。如果是跨进程调用还要留意对方进程是不是被系统杀死后冷启动重连这会放大 Binder 调用的耗时。4.3 输入事件派发超时的隐藏规律为什么用户“感觉到卡”和 ANR 往往有延迟输入事件相关的 ANR 有一个迷惑性规律用户往往先感觉到“卡”然后才在几秒后弹出 ANR 弹窗。这个“延迟”其实源于 InputDispatcher 对事件队列的批量处理。如果主线程在一段时间内持续繁忙但每段忙碌都小于单次超时阈值可能不会触发 ANR但如果某个事件已经等得足够久系统会直接把这次等待记录为一次 ANR。这种场景下的 trace 分析很容易误判主线程在 ANR 时刻可能正在执行一个无关紧要的方法——真正拖垮操作的耗时动作已经过去了或者主线程正在等待下一个事件。所以我建议在分析输入类 ANR 时一定要结合events_log里的am_anr详细信息并利用dumpsys window查看当前焦点窗口、输入通道状态看一看是不是有input channel is not responding的早期信号。另外一个容易被忽略的点输入事件不只看触摸事件键盘事件、轨迹球、游戏手柄等同样会触发 InputDispatching Timeout。在车载、游戏盒子这类设备上如果系统层持续注入按键事件而应用主线程被其他任务占用也会频繁出现输入 ANR。5. 实操案例拆解两个典型复杂场景的完整定位过程5.1 案例一主线程 Blocked 在后台上报组件的锁里现象线上反馈某版本在低端机上 ANR 率升高主要发生在从列表页进入详情页的时候。看 traces 文件主线程堆栈停在ReportManager.upload(ReportManager.java:210)状态是 Blocked等待的锁是一个静态对象。第一反应可能是这个上报组件自身有问题于是很多人会把优化目标直接定为“给上报组件加锁改造”。但这是典型的没有分析根因就动代码。我重新整理了数据主线程waiting to lock 0x...持有者线程堆栈显示它正在执行DBHelper.insert()。持有者线程本身并没有死在 DB 操作上而是DBHelper.insert()内部又触发了ContentProvider操作这个操作在等待一个 Binder 响应。Binder 响应从com.android.providers.media回来而 media provider 在 ANR 期间恰恰有高延迟。也就是说根因不是上报组件的锁设计问题而是主线程等待一个最终依赖媒体库响应的锁。这个锁被后台线程拿住后台线程自己也在等待一个很慢的外部服务。这个案例的教训是锁只是中间环节要看清楚锁链的全貌。如果只优化锁的持有时间而不解决 media provider 的慢调用问题还会以其他形式出现。最终我们做的是把上报组件的动作完全移出主线程调用路径同时给 DB 操作增加了超时控制并且优化了后台线程的持锁策略主线程不再等待持有者的锁。5.2 案例二动态壁纸与主线程的 RenderThread 交织阻塞现象某一类机型上用户在桌面滑动时应用偶发 ANR弹窗显示是桌面或系统 UI但我们自己的应用也收到了影响。排查时发现我们的进程不算 ANR 主体但用户反馈的却是我们的应用打开很卡、点击无响应。这类问题一般不会出现在常规的 ANR 监控里因为它是间接影响。我们通过 Perfetto 抓了一段系统级的 trace发现我们的 App 在启动时向系统申请 Surface 的帧而 RenderThread 的dequeueBuffer等待超过了 3 秒。原因不是应用自身耗时长而是系统 SurfaceFlinger 在压力下用长时间阻塞来处理图层合成同时壁纸进程也在高频刷新。主线程虽然没有明显慢操作但等待 RenderThread 同步渲染结果导致用户感知到卡顿最终 App 的输入事件也出现了超时。这个场景的定位难点在于应用侧 trace 里主线程可能是 idle 或轻量任务但系统侧SurfaceFlinger的同步已经是瓶颈。处理思路有两条一是和系统团队配合优化 SurfaceFlinger 的图层合成策略二是应用侧在启动链路中降低 Surface 申请的频率避免在系统高压时期抢占渲染资源。这类跨进程、跨系统的案例是“复杂场景”四个字的典型写照。如果你只盯着自己的主线程堆栈很难找到真正的根因。5.3 案例三广播 ANR 的“幽灵复现”现象线上出现前台广播 ANR主线程 trace 显示BroadcastReceiver.onReceive并没有太重的逻辑代码审查也确认 onReceive 里就是做了一个startActivity跳转。诡异的是在测试环境里复现不出来线上却能偶现。深入排查后才发现onReceive 里的startActivity虽然没有耗时操作但它启动的是一个冷启动 Activity而且这个 Activity 的onCreate里有一个同步初始化操作要等一个网络请求的超时时间最长 5 秒。广播 ANR 的判定是从 onReceive 执行开始计时的但某些 Android 版本上系统会等待BroadcastReceiver的goAsync结果或者等待进程变为前台状态。冷启动 Activity 的耗时消耗在这个窗口里整体可能就超过了广播超时阈值。复制这段代码逻辑的耗时原因是onCreate里的同步网络请求使用了CountDownLatch.await(5, TimeUnit.SECONDS)。它不是 ANR trace 里出现在堆栈上的直接执行路径吗其实会只是 trace 是在超时后抓的如果网络请求在超时前已经返回你会在 trace 里看不到任何异常。所以这类问题有很强的“幽灵复现”特性——你试了一次它可能恢复正常你再试一次它又触发了。解决方式也不复杂把 Activity 的onCreate里的同步等待改成异步初始化或者改成启动页先展示、真正需要数据时再加载。但更重要的是这次排查过程提供了一个教训ANR 的根因不一定要在 trace 里直接对应到堆栈而应该把 trace、业务逻辑、系统行为三者结合起来判断。6. 复杂场景排查方法论的沉淀6.1 一个可复用的 ANR 分析流程经过多次实战我总结了一套流程把它固化成了团队排查 ANR 的标准动作第一步收集完整证据。不要只拿一个 traces.txt 就开始排查。至少应该同时拿到am_anr日志、LogcatANR 前 5 秒、进程 CPU 占用快照、内存状态。如果条件允许用 Perfetto 抓系统 trace能看到更完整的跨进程交互。第二步确定 ANR 类型。从am_anr的 reason 字段入手判断是输入、广播、服务还是 provider 超时。这个步骤最大的作用是把问题域从“整个应用”缩小到“某一条消息处理链路”。第三步标记事件时间线。找到 ANR 判定时间点反推 5-10 秒内应用侧和系统侧的关键事件。比如ANR 前发生了什么业务动作用户点击了什么页面做了什么跳转有没有执行网络任务这个阶段要像做法医鉴定一样严谨把时间线拉平。第四步分析主线程状态。主线程 Running、Blocked、Waiting、Native 分别对应不同的排查方向。第五步检查锁与 Binder。如果主线程是 Blocked顺着waiting to lock找锁持有者如果主线程停 Binder调用链上是否有transactNative和onTransact。第六步从代码逻辑逆向确认。如果 trace 和日志都正常就要回到代码里看看 ANR 触发时间点前主线程和关键后台线程各自在做什么。特别注意onResume、onCreate、onReceive、onStartCommand这些生命周期回调里是否有潜在的耗时逻辑。第七步复现实验与验证。任何根因分析最终都要能解释“为什么线上会偶现”。如果无法稳定复现要考虑设置降级开关、加日志、用 Monkey 做压力测试来暴露问题。6.2 那些“trace 没体现”的隐藏延误项除了主线程堆栈本身还有一类非常容易漏掉的延误项。第一个是类加载与首次初始化。Java 类的clinit、静态块的执行都发生在首次访问时。如果首次访问发生在主线程而类加载又需要反射加载大量类耗时可能达到几百毫秒甚至几秒。这类问题在 hook 了系统 API 或者使用 APK 分包加载后尤其明显。trace 里往往显示主线程停在某个普通方法上但实际上是在等类加载器完成工作。第二个是低频回调与队列积压。有些操作不是直接在调用入口执行的而是通过 Handler 发送 Message 后延后处理。如果 MessageQueue 里积压了大量消息主线程处理完才能处理关键消息这种排队时间会计入 ANR但 trace 不一定能体现出“积压了多少”。第三个是系统资源受限。低内存、存储 IO 繁忙、CPU 被其他进程抢占这些系统层面的问题不会直接显示在应用堆栈里但会让所有操作的耗时成倍增加。尤其要留意lmkd杀进程、kswapd频繁回收内存这类系统级事件。第四个是慢盘 IO复杂场景不一定有直接的 SynchronousQueue 等待但SharedPreferences的apply在系统 IO 繁忙时容易触发文件锁等待主线程的getSharedPreferences也可能被文件锁阻塞。这类问题在低内存机上尤其明显。6.3 为什么“根因分析”比“定位卡点”重要“定位卡点”是找到主线程卡在哪个函数“根因分析”是搞清楚为什么这个函数会卡以及它在什么条件下会卡。这两者之间隔着大量的系统知识、运行环境和业务逻辑理解。比如我们前面案例里的锁问题如果只是定位到ReportManager.upload卡住你会去优化 upload 方法。但把整个锁链打通后再看会发现即使 upload 方法优化得再好只要 media provider 慢问题依然存在。只有从根因层面去解耦才能真正解决。再比如另一个常见场景WindowManager的addView在主线程执行如果页面初始化时频繁增加窗口耗时也会超过输入事件阈值。定位是addView卡住根因却可能是业务侧在短时间内高频弹窗或悬浮窗创建。如果你只做addView方法级别的优化可能根本压不住问题。我做 ANR 优化的最大体会是所有卡点层级的解决都只是止血根因层级的解决才能让系统长期稳定。这也是为什么我一直强调把排查的重心放在“为什么会在特定场景下超时”而不是停留在“这个函数耗时多久”。7. 工具选型与最佳实践搭配7.1 从 SDK 基础能力到自建监控排查 ANR 时工具链越丰富定位效率越高。我的日常组合是Logcat events_log 是基础几乎所有问题都能从这里找到第一手线索。尤其是am_anr日志中的 reason 和am_proc_died附近的事件能帮你快速定位系统侧触发条件。/data/anr/traces.txt是离线分析的基石但抓取时机滞后不适合实时监控。如果做线上监控建议在 ANR 发生后的第一时间主动抓取 custom trace用Debug.dumpJavaBacktrace()或者系统接口抓取所有线程堆栈上传到平台。同时采集主线程的 message 队列情况、Looper 耗时、关键业务埋点方便后续做聚合分析。BlockCanary 这类“在线阻塞监控”工具也很有价值它通过 Choreographer 检测帧刷新延迟来发现主线程卡顿。它定位不了系统级 ANR但能帮助你提前发现潜在的卡顿点。Perfetto 是系统级 trace 分析的利器尤其在分析跨进程调用的场景比如 SurfaceFlinger、WindowManager 和 App 之间的交互能让我们直观地看到 Binder 调用的耗时和等待。Android 10 以上的设备基本都支持Windows 上用record trace或tracebox也可以。在比较复杂的场景里Perfetto 比直接读原生 Kernel trace 省力得多。7.2 自建线上 ANR 监控的几个工程要点如果团队已经有 APM 平台你可以在上面加一个 ANR 采集模块。这里有几个工程要点第一个要点是采集时机要快。ANR 发生后系统会有几秒的延迟才弹窗我们要在这一段间隔里尽可能抓到完整状态。你可以监听ANRManager的 callback或者用Application.registerActivityLifecycleCallbacks配合 Handler 监控主线程卡顿来触发一次 dump。如果等系统最终弹窗了再抓主线程的状态可能已经恢复。第二个要点是数据维度要全。除了主线程堆栈你还要采集关键 Binder 线程堆栈、CPU 使用率、内存状态、Looper 消息队列信息、正在执行的事务 ID。这些维度能帮你快速区分进程内和进程外的问题。第三个要点是聚合分析比单条 trace 更重要。单条 trace 是“点”把多个相同 root cause 的 trace 聚合起来看才能发现模式。比如某段时间所有 ANR 都发生在bindApplication阶段说明问题出在 Application 初始化如果都发生在一次页面跳转说明页面创建链路上有共性卡点。这种聚合分析能让你从被动接工单变成主动发现隐患。7.3 实用技巧如何从系统日志中快速定位 ANR 触发时间点当日志里出现ANR in ...时立即去查紧接着的am_anr日志。am_anr后面的详细信息会告诉你这是哪一类的 ANR、发生在哪个进程、当时进程的 CPU 使用率是多少。这个字段比你自己肉眼去猜要准得多。另外关于 ANR 时间点尽量用am_anr日志里附带的时间戳而不是应用自己打印的时间。因为应用的时间戳有时会有几秒偏差尤其是在进程卡死之后Logcat 缓冲区里的时间戳会漂移。也要养成一个习惯在发布前灰度阶段就打开文件描述符监控和线程间死锁检测开关有条件的可以通过Debug.startMethodTracing采样启动路径和关键操作的耗时。很多线上复杂 ANR 在灰度期间就已经有迹象只是还没有达到用户可感知的阈值。提前埋点能在问题变大之前就把根因抓到。8. 常见问题与排查技巧实录8.1 ANR trace 里主线程不是卡死而是正常状态这是我被问得最多的一类问题。解决办法是检查am_anr的 reason看看是不是广播或服务类超时而不是输入事件。如果是广播或服务超时主线程此时可能已经在处理后续消息所以 trace 里看不到明显的卡点。此时要往“广播处理过程中是否发送了异步任务”的方向查重点检查goAsync、PendingResult的使用是否正确。8.2 同一份 trace 反复出现但线上卡死条件各不相同这说明根因可能不是偶发而是触发条件被日志丢弃了。建议增加自定义 trace 采集模块记录关键的 Message 处理耗时。比如在 Activity.onResume 的入口和出口分别打点统计耗时在页面跳转前记录当前主线程 MessageQueue 是否有积压。这样即使下一次 ANR 发生时 trace 里依然没有异常我们也能通过埋点数据还原前几秒的业务执行路径。8.3 低端机与高端机表现差异极强低端机上容易触发 ANR 的场景通常是内存和 CPU 抢占严重尤其是在多任务切换时。这种场景里的 ANR 不是某一个函数性能差而是系统整体资源不足。处理思路不是去优化单个方法而是从应用整体资源占用量考虑减少主线程非必要工作避免在 Activity 启动时做密集的 Adapter 数据填充降低内存分配频率。8.4 反复出现但不在每个版本都现这类问题往往是历史遗留的锁等待、Binder 调用慢、系统服务异常。每当你以为修完一个新的触发条件又冒出来。我的经验是遇到这类问题先别急着改代码而是花时间把这一模块的锁依赖关系和 Binder 调用链梳理清楚画成图别用 mermaid 画直接纸笔或绘图软件然后集中处理所有锁和慢调用不要只修触发位置。8.5 无法从日志定位到具体事务当 trace 里出现MessageQueue.next且主线程空闲但 ANR 已经发生多半是系统侧等待时间太长而不是应用阻塞。比如InputDispatcher等待窗口创建或者窗口已经不可见但系统还在派发事件。这种问题要配合 WindowManager 日志去看焦点窗口状态单靠应用侧修改往往无效。我强烈建议每个有线上 ANR 困扰的团队都建立一个自己的“ANR 案例库”记录每一次 case 的触发类型、原始 trace、时间线、根因和解决方案。后续新同学接手问题时最先查的就是案例库效率会高很多。9. 实操心得几个能直接抄作业的优化动作如果要给刚接触 ANR 优化的同学几个具体动作我建议照这个顺序来做第一个动作在 Application 的attachBaseContext阶段就开一个独立线程执行初始化把主线程里的非必要初始化全部挪走包括埋点 SDK、图片缓存、推送注册等。这个过程能直接消除很多启动期的 ANR 和卡顿。第二个动作给主线程的 Looper 设置一个setMessageLogging的观察者统计每个 message 的执行耗时方便定位卡在哪个 Message 上。这是成本最低、见效最快的监控手段很多 APM 工具的原理就是这个只不过你在 debug 环境里先手动加一遍往往就能抓到一些线上问题的前兆。第三个动作统一管理所有主线程上的网络请求和本地 IO。主线程上的本地 IO 虽然在小样本里看起来很快但遇到慢盘或 IO 抢占时几百毫秒的耗时也很有可能。网络请求更是高风险操作必须异步化。第四个动作对主线程持有的锁做审计。在主线程访问synchronized方法或ReentrantLock的地方加上锁等待超时监控。如果超时时间超过 200ms则记录下来。上线后通过 APM 查看是否有高频主线程锁等待把这个作为核心指标之一。做完这四个动作线上 ANR 率通常会有一个明显下降。这不是玄学而是减少了大部分主线程非必要工作的系统风险。剩下的疑难杂症再进入本文提到的复杂场景定位流程。最后再分享一个小技巧当你拿到一份 ANR trace 不知从何下手时可以先用CPU usage信息看主线程的 CPU 使用。如果主线程 CPU 占比极高那一定是代码自身在飙 CPU如果主线程 CPU 很低但卡住那是等待外部资源。前者是算法问题后者是锁、Binder、IO 或系统服务问题。这个二分法能帮你少走很多弯路。