之前接到一个特别棘手的反馈线上出现一批ANRlogcat里能看到系统弹了“Application Not Responding”但反复拉取 /data/anr/ 下生成的 traces 文本主线程的调用栈却平平无奇看起来都是常态代码。后来我把这类问题的定位方式分享给同事同事给了一句很精确的概括“这类ANR是需要Perfetto分析的ANR。”这句话点醒了我——普通ANR靠读取系统生成的CPU调用栈就能定案但有些ANR问题根本不在“当时主线程正在执行什么Java代码”。它可能卡在锁等待上线程没有被系统调度进CPU或者CPU频率过低导致某段耗时操作被放大了。这些信息传统日志给不了。Perfetto的强项是把进程、线程、内核调度、CPU频率、Binder调用、锁竞争全部放在同一条时间线上让你用显微镜看现场。这篇就来讲讲什么样的ANR必须要上Perfetto怎么用Perfetto一次把这类问题查到底以及我在实操中踩过的坑和沉淀下来的排查套路。内容适合有一定Android经验、正在和线上ANR缠斗的开发者也适合刚开始接触Perfetto但不知道从哪里下手的同学。1. 这个项目的起因那些“一眼看不出问题”的ANR1.1 什么样的ANR会把我们逼到Perfetto面前先说我在某业务线遇到的三种典型场景它们都符合“需要Perfetto分析的ANR”这个定义。第一种主线程在等子线程。系统日志里能看到主线程阻塞在 Object.wait 或者 ConditionVariable持有锁的却是某个工作线程但那个工作线程本身没有异常它的调用栈只是停在业务代码的普通位置。这时候你得搞清楚它到底是被什么阻塞了、等了多久、中间有没有被调度。第二种主线程看起来在正常执行但整体速度奇慢。日志里调用栈是“正在执行某动画”或“正在处理某消息”可这次执行的时间明显超出预期。CPU频率、热限频、核心迁移这些因素在主线程调用栈里完全看不出来。第三种主线程甚至没有被调度。Perfetto的调度追踪能清楚看到“主线程处于R状态但一直没上CPU”说明它一直排在runnable队列里系统根本来不及给它分配运行时间。这种问题如果你只看ANR文本栈会以为主线程“消失了”其实它还在排队。这三种情况都属于典型的高难度ANR。普通方法排查它们的思路通常是加大日志、复现、打点、看耗时分布。但打点只能回答“哪里慢了”回答不了“为什么慢”更看不到系统层面的调度、负载和锁竞争。1.2 传统ANR排查工具为什么不够用Android系统在发生ANR时会把ANR原盘、主线程及各进程的Java栈写到 /data/anr/ 下Logcat里也会打印部分信息。这套机制对大多数ANR是有效的主线程无响应栈里通常会显示主线程正在执行的代码位置如果是死锁多线程的栈能直接看到互相持有的锁如果主线程在做耗时IO栈里往往能看到文件读取或数据库操作的调用。可问题是栈只能说明“那一刻”程序执行到了哪里它证明不了“为什么停留在这里”。比如现象文本栈能看到文本栈看不到主线程等待子线程主线程停在 wait子线程为什么慢子线程是否被抢占了CPUBinder调用阻塞主线程停在 binder transaction对端进程是否有响应Binder线程池是否耗尽CPU调频降频看不到当前CPU频率、调度器是否发生限频线程排队没上CPU停在R状态排队时长、被谁抢占、核心是否被隔离当排查方向从“代码执行路径”转向“系统资源搏弈”时就必须引入Perfetto这类基于内核Trace的系统级工具。2. 重新认识ANR的判定机制为什么光看调用栈会有盲区2.1 ANR的触发标准与系统判定链路ANR全称Application Not Responding系统通过“超时无响应”两个维度来判定。核心超时包括输入事件分发超时触摸、按键等事件在5秒内没被处理完广播超时前台广播约10秒后台广播约60秒未执行完服务超时前台服务约20秒后台服务约200秒未完成ContentProvider超时新版本系统对Provider启动也有阈值约束。超时发生后系统会做两件事一是弹ANR对话框给用户二是把当前各进程线程的调用栈全部收集起来生成trace文件。这个机制收集的就是“某一瞬态的观察结果”相当于事故发生后立刻拍了一张全体快照。这个快照的问题在于它把“连续的过程”变成了“离散的某一帧”。如果主线程在等待一个网络请求栈里永远是wait不管这个请求是300毫秒还是3秒你看到的都差不多。快照也区分不了“正在进行的合理等待”和“被外部拖住的无谓等待”。2.2 从日志看ANR哪些线索藏在字里行间Logcat中ANR日志通常包含几段信息ANR in com.example.app (com.example.app/.MainActivity) Reason: Input dispatching timed out ... CPU usage from 0ms to 2047ms later (2020-07-01 12:00:00): ...这些信息里面“Reason”字段和“CPU usage”字段值得仔细看。“CPU usage”一栏会列出各进程的CPU占用它能告诉你系统整体负载高不高、嫌疑进程是不是在疯狂占CPU。但日志有一层很难绕过的透明墙它给不出时间线和因果关系。CPU usage统计的是“某一段窗口内的平均值”它看不出某个线程在10毫秒级别上的调度抖动。Perfetto的ftrace数据能做到毫秒级切片能还原每个线程在每个核心上运行了多久、被谁抢占了、休眠后谁唤醒的它。2.3 为什么Perfetto能弥补调用栈的盲区Perfetto追踪的数据来源之一是Linux内核的ftrace它记录的是调度器事件、CPU频率变化、中断、锁等待等底层事件。举个例子Perfetto能回答这几个关键问题主线程在ANR前10秒内到底在CPU上跑了多少毫秒睡眠了多少毫秒主线程醒来后是立刻被调度到了CPU还是排队排了800毫秒在那段时间里系统总负载是多少是哪个进程占了绝大多数CPUCPU频率有没有被限制是否因为高负载或温度触发了降频这些数据组合在一起才能把“栈显示的代码”和“真实的机器行为”对应起来。用生活类比来说普通ANR日志等于目击证人的口头描述“他当时站在银行柜台前”Perfetto等于银行的监控录像“他从9点03分开始排队9点04分被前面的人挡着没挤进去9点05分窗口才开放”。后者才能定责。3. Perfetto工具选型与基本概念先花10分钟搞懂再上手3.1 三种典型用法从“快速看症状”到“精确做手术”如果你刚接触Perfetto不建议直接上命令行先走最简单的路径开发者选项里的“系统跟踪”功能。具体路径是设置-开发者选项-系统跟踪开启后系统会录制一段时间录完生成一个.perfetto-trace文件。这个功能录制的数据源覆盖了CPU调度、内存、显示等常见模块足够完成初步诊断。如果你想针对特定路径做精确复现那就用命令行的perfetto工具。它能自定义数据源、buffer大小和录制时长适合固定场景。更进阶的用法是用trace_processor做SQL查询对所有trace数据进行结构化分析。它可以回答“这个线程总共跑了多久”这类聚和性问题还能配合脚本批量处理多个trace文件。三种用法是层层递进的关系先用系统跟踪快速定位你要看的大方向再用命令行做精确采集最后用SQL把关键数据量化成证据。3.2 核心概念Track、Slice、Packet、ThreadPerfetto界面本质上是一个“多轨时间线”。Track一条条横轴轨道可以理解成“一路机位”。每个进程、每个线程、每个CPU核心都有自己的track。Slice轨道上一段段彩色矩形块代表某个函数或事件的持续区间。比如主线程执行某个方法的耗时就画成一个slice。PacketTrace文件中携带的一条条原始数据记录。包括sched_switch线程切换、cpu_frequencyCPU频率变化等。线程状态分为Running在CPU上跑、Runnable可运行但正在排队、Sleeping阻塞或休眠、Uninterruptible Sleep不可中断的眠经常对应磁盘IO。第一次打开trace难免眼花缭乱我的建议是压根不要管全貌先找到目标线程自己的track把其他轨折叠起来只看这一个线程在时间维度上的状态变化。3.3 为什么选Perfetto而不是老式systrace或atrace老项目里可能会有systrace这时候有同学会问systrace继续用不行吗systrace的底层数据采集也依赖ftrace和Perfetto在很多基础事件上同源但Perfetto在几个重要方向上是完全碾压式的采集端的配置能力可以精确控制数据源、buffer大小、丢事件策略分析端支持SQL查询可以进行程序化分析而不是肉眼盯图自带强大的UI支持轨迹缩放、搜索、对比甚至collision检查对现代多核CPU、多进程、GPU等复杂场景支持更好。如果你已经熟悉systrace的工作方式转Perfetto成本很低因为很多术语是相通的。时间线思维和调度分析的方向是完全一样的。4. 实操全流程用Perfetto完整定位一次ANR这一章我用一次实操来串讲。假设场景某App有一个页面打开偶发ANR用户反馈“有时候点进去就卡死”logcat显示的Reason是“Input dispatching timed out”但ANR文本栈看起来正常。我们怀疑是调度或锁竞争但现在用Perfetto把它查清楚。4.1 环境准备与数据源配置先用命令行采集。连接设备后确认perfetto可用adb shell perfetto --version如果设备系统版本较新自带perfetto基本都能用。接着准备一份精确的采集配置比如下面的pbtx文本buffers { size_kb: 262144 fill_policy: RING_BUFFER } data_sources { config { name: linux.ftrace ftrace_config { ftrace_events: sched/sched_switch ftrace_events: sched/sched_wakeup ftrace_events: sched/sched_blocked_reason ftrace_events: task/task_newtask ftrace_events: power/cpu_frequency ftrace_events: power/cpu_idle ftrace_events: irq/irq_handler_entry ftrace_events: irq/irq_handler_exit } } } data_sources { config { name: linux.process_stats } } data_sources { config { name: android.log android_log_config { log_ids: LID_DEFAULT } } } data_sources { config { name: linux.sys_stats sys_stats_config { meminfo_period_ms: 1000 } } }这段配置我解释一下buffer大小设成256MB用环形缓冲录制时间到了之后保留最后一段数据ftrace事件里重点要了sched_switch、sched_wakeup和sched_blocked_reason这是还原线程状态切换的关键android.log可以把Logcat日志一并写到trace里方便后续把业务日志和调度时间线对齐。录制指令采用后台方式adb shell perfetto -o /data/misc/perfetto-traces/xxx.perfetto-trace \ -c /data/misc/perfetto-traces/config.pbtx \ -t 30s这里有个细节-t 30s表示录制30秒先在后台启动录制再开始复现操作顺序非常重要。如果你的操作脚本需要打桩或者预热建议在录制启动前就先完成不然前面几十秒全是无效空档。4.2 触发一次ANR并观察现场启动录制后立刻去操作页面建议用脚本做连续点击或刷新把触发概率抬到100%。如果运气好一次就触发可以等ANR对话框出现后再等23秒确保系统把ANR的栈信息dump完毕再停止录制adb shell perfetto --stop把产物拉到本地adb pull /data/misc/perfetto-traces/xxx.perfetto-trace .如果是在线上环境很多时候拿不到这种主动录制的trace。但系统会在ANR发生时自动生成一份perfetto trace位置可能由于版本不同而分布在不同目录。你可以先去/data/anr/目录找找有些系统会把trace以.trace或.perfetto-trace形式保留。线下定位阶段主动录制仍然是效率最高的方式。4.3 打开trace四个视角排优先级把trace拖进官方Perfetto UI后第一件事不是乱翻而是从下面四个视角一层层看。第一个视角“进程CPU总览”。看可疑App进程在整个录制时间窗里CPU占用是偏高还是偏低。如果全场只有5%的CPU说明主线程基本在高频等待如果CPU占用在ANR前后冲到90%以上就要怀疑是不是CPU被打满导致排队。第二个视角“主线程状态流”。找到主线程的track缩小时间窗到ANR前5秒看主线程的颜色状态。Perfetto里Running是绿色Runnable是蓝色Sleeping是白色。为什么建议看这里因为只有这里能区分“卡在锁”和“排队没上CPU”这两种完全不同的故障模式。第三个视角“关键Slice耗时”。如果主线程在运行看它执行了哪个slice、要多久。比如某种资源加载的slice从50ms变成2000ms说明是在业务代码里被拖住需要继续看它内部有没有更细的sleep。第四个视角“CPU调度真相”。把目标App所有线程的track都展开查看CPU的sched_switch事件找出是谁抢占了主线程、或者主线程等待的某个锁持有线程一直没有运行的原因。这一步能定位到跨线程锁竞争。4.4 用SQL把结论变成硬证据肉眼看完时间线之后建议用trace_processor把关键指标提取出来做数值上的确认。trace_processor --query SELECT utid, state, SUM(dur) AS total_dur FROM thread_state WHERE state ! R AND utid 123 GROUP BY state上面这个SQL的意思可以理解为把tid为123这个线程按线程状态分组算它每个状态各花了多长时间。如果Running的时间占比只有20%而Runnable占到40%那么主线程“排队没上CPU”的概率就非常大。再配合一段SQL找到主线程最后一次唤醒到实际运行之间的间隔SELECT ts, name FROM sched WHERE utid 123 ORDER BY ts DESC LIMIT 20如果发现主线程在好几毫秒后才被调度执行那就说明调度器响应慢了通常是系统负载过高。这些查询结果保留下来可以和业务同学、系统开发同学对线比张口就说“感觉卡了”有说服力得多。4.5 从trace到修复方案的三级决策看完数据修复方向大致分三级。一级是业务层修复如果结论是主线程本身执行了耗时操作比如文件读写、复杂计算那就把操作拆到子线程或者加缓存。二级是并发层修复如果结论是跨线程锁竞争比如主线程在等某个工作线程释放锁而该工作线程又被另一个线程阻塞那么优化方向是对锁的顺序、粒度做调整。三级是系统层问题如果结论是CPU没空、频率太低、核心被占用那要做的往往是错峰降载、压低某些后台任务的优先级甚至调整系统端的CPU配置。真实情况往往是混合的——既有业务耗时又有调度排队。这时不要贪快拿Perfetto证据里最占比重的那一条主线先去改改完再复测一次流程你会发现决策效能完全不一样。5. 常见问题与排查技巧实录这些坑我替你踩过了5.1 问题与定位速查表现象第一时间看的Track常见根因确认方法主线程状态大部分是白色Sleeping主线程track等锁、等Binder、等IO看等待唤醒的事件来源主线程蓝色Runnable频繁CPU核心track、其他线程track系统负载高、被抢占看sched_switch中的prev_comm主线程绿色Running但slice特别长CPU频率track、主线程slice降频、代码执行慢、JIT对比前后频率变化子线程持有锁但长时间没运行子线程track、CPU负载子线程优先级低、被压榨看子线程整体运行时间占比ANR前后CPU占用全程偏低系统进程track进程被冻结、后台限制看进程的freeze状态这个速查表不是万能钥匙但它能帮你在打开trace后先走一遍最稳妥的排查顺序。实际执行时我会建议先看“主线程的Runnable状态比例”这个核心指标它最能区分两类最不同的根因。5.2 避坑经验和独家心得第一个坑是buffer开得太大或太小。太小导致关键事件被丢掉尤其是ftrace事件密集时ANR前后那段最关键的调度数据反而被环形缓冲覆盖了。我一般的建议是起手256MB临时录制场景小到64MB也够但如果录到系统级trace不要在同一份trace里同时录太多数据源否则大文件打开直接卡爆内存。第二个坑是过度依赖Up解“线程长时间没Running就等于卡死”的判断。线程状态需要和CPU频率、系统进程负载联合起来看。比如同一个线程在低负载状态下跑得好好的但系统一旦高负载它就永远排不上队这种根因完全在系统侧不应只优化业务代码。第三个坑是本来要复现问题结果因为操作太快或太慢导致问题堆叠。举个例子连续点击导致主线程消息队列里堆积了二三十个事件ANR前5秒的trace里全是待处理的消息这看起来是“主线程慢”实际上是你复现时的操作手法放大了干扰。所以操作手法要做到既有节奏感又能精确触发不能狂点到底。第四个坑是拿线上自动生成的trace直接跟线下对比时说“对不上”。线上环境的数据源、路径、调度器配置可能都有差异。我会建议先在测试环境里用同一套配置跑到稳定复现再回到线上抽查不要一把梭地只看线上trace。5.3 线上ANR怎么办没有主动录制也能用Perfetto很多人问线上用户设备不可能提前录制怎么办其实Android系统在ANR发生时可能自动保存了一份perfetto trace。部分版本会把trace文件放到/data/anr/另外系统日志里还可能有“ANR in ... trigger”与其他崩溃信息一起被传回后台。你可以通过以下命令尝试拉取adb shell ls -l /data/anr/ adb shell ls -l /data/misc/perfetto-traces/拉回来后同样用Perfetto UI加载。这些线上trace通常默认只含调度相关的数据没有业务slice所以能和代码打点关联起来的点不多。但依然可以看两个指标主线程的调度延迟和系统负载。如果发现主线程Runnable占比极高说明线上环境CPU竞争压力确实大这个结论已经足够驱动优化了。遇到一次疑难ANR我个人的习惯是先把线上自动化trace的数据拿来做宏观判断把问题定性成“调度问题”或“业务问题”再决定要不要线下去精确录制。6. 写在最后想清楚“要验证什么”再动手录trace回到“需要Perfetto分析的ANR”这个命题上我的经验是Perfetto的适用场景非常明确它就是给你回答“主线程为什么慢、为什么没运行、为什么运行了还在等”的。但它的门槛也在这里——它给的是高密度底层信息你要么有清晰的问题要么会被淹没在数据里。我在某次排查里本来想验证“子线程持锁时间太长”结果Perfetto一跑发现子线程实际运行时间很少是它根本没被调度。这个转折完全依靠Perfetto的调度数据才能完成验证后者用更少时间压到同样的结论却少走了一半弯路。给刚上手的同学一个建议别急着录大trace先把一条主线程的状态流看顺。能看出Running、Runnable、Sleeping的区别能看懂sched_switch和wakeup事件再开始谈复杂排查。Perfetto的核心心法是“先定性再定量”先确认方向对不对再把所有证据拉出来最后才动手改代码。如果你现在手里正有一个查不清楚的ANR别再去猜了。打开Perfetto录一份30秒的trace从主线程的状态开始看。很多时候真相就在你眼前挂着。