1. 为什么你的Perfetto Trace里看不到自己的埋点很多朋友在刚开始用Perfetto做性能分析时都踩过同一个坑明明在代码里辛辛苦苦加好了Trace.beginSection和ATRACE_BEGIN抓出来的trace文件里却死活找不到自己埋的“执行块”。折腾半天最后发现trace根本没生效那种感觉就像一拳打在了棉花上。我刚开始用的时候也遇到过当时在一个第三方App的NDK层埋了点信心满满地抓了trace结果在Perfetto UI里翻来覆去就是找不到。后来才发现问题出在一个叫TAG的东西上。简单来说Perfetto为了性能考虑不是所有埋点都会记录它需要你明确告诉系统“嘿我现在要记录ATRACE_TAG_APP这个类别的信息”。如果没告诉它或者告诉的方式不对你的埋点就会被直接忽略。这里有个关键区别也是新手最容易混淆的地方系统级代码AOSP原生开发和普通App/SDK开发开启Trace的方式是完全不同的。对于做系统开发比如修改Android Framework的朋友你用的是platform private的API。你可以在代码里通过#define ATRACE_TAG ATRACE_TAG_AUDIO或其他系统TAG来指定一个类别。抓trace时你需要在命令里带上对应的类别参数比如sched freq am wm gfx等等。系统会根据你代码里定义的TAG和命令行参数做“与”运算只有匹配的TAG才会被记录。但对于绝大多数普通App开发者你用的是SDK或NDK提供的公开API。这时你的代码里不能也没法指定ATRACE_TAG_GRAPHICS这类系统TAG。SDK/NDK API默认只使用一个特殊的TAGATRACE_TAG_APP。这个TAG的开关不是通过命令行里加gfx、view这些参数来控制的而是由一个独立的机制管理。这个机制的核心是一个系统属性debug.atrace.tags.enableflags。对于ATRACE_TAG_APP系统还会额外检查当前进程名是否匹配一个特定的“调试应用”列表。只有当你通过-a参数指定了你的App包名并且ATRACE_TAG_APP这个位在属性值中被启用时你在App里打的点才会出现在trace中。所以如果你在第三方App里埋了Trace却没看到99%的原因就是抓取trace的命令里漏掉了开启ATRACE_TAG_APP的关键参数。下面我们就来看看具体怎么解决。2. 实战为你的App代码添加Perfetto埋点知道了原理我们来动手实操。我会分Java和C两种情况把系统级platform private和普通App级SDK/NDK的写法都讲清楚。你可以对照自己的开发场景直接套用。2.1 线程内同步代码块最常用这是最最常见的场景用来测量一段同步执行代码的耗时。记住一个原则有Begin就必须有End而且要成对出现最好用try-finally块包起来确保异常时也能结束Trace。Java (Platform Private - 系统开发用)如果你在修改AOSP源码比如在frameworks/base/下面加代码可以用这个方法。你需要先引入android.os.Trace并且可以指定一个系统TAG。import android.os.Trace; import static android.os.Trace.TRACE_TAG_AUDIO; // 引入你想用的TAG public void playSound(String path) { // 开始一个根片段名字叫PlaySound Trace.traceBegin(TRACE_TAG_AUDIO, PlaySound); try { // 嵌套一个子片段测量打开音频设备的时间 Trace.traceBegin(TRACE_TAG_AUDIO, OpenAudioDevice); try { SoundDevice dev openAudioDevice(); } finally { Trace.traceEnd(TRACE_TAG_AUDIO); // 结束OpenAudioDevice } for (int i 0; i bufferCount; i) { Trace.traceBegin(TRACE_TAG_AUDIO, SendBuffer); try { sendAudioBuffer(dev, ...); } finally { Trace.traceEnd(TRACE_TAG_AUDIO); // 结束SendBuffer } // 这里演示记录一个计数器比如缓冲区的使用量 Trace.setCounter(TRACE_TAG_AUDIO, SndBufferUsage, dev.getBufferUsage()); } } finally { Trace.traceEnd(TRACE_TAG_AUDIO); // 结束最外层的PlaySound } }用这种方式你在抓trace时需要开启对应的TAG例如在perfetto命令中加上audio这个数据源。C (Platform Private - 系统开发用)对应Native层的系统代码通常在frameworks/native/或system/目录下。需要包含cutils/trace.h头文件。// 首先在文件顶部定义你要使用的TAG类别 #define ATRACE_TAG ATRACE_TAG_AUDIO #include cutils/trace.h void PlaySound(const char* path) { ATRACE_BEGIN(PlaySound); // 测量打开音频设备的时间 ATRACE_BEGIN(OpenAudioDevice); struct snd_dev* dev OpenAudioDevice(); ATRACE_END(); // 结束OpenAudioDevice for (int i 0; i bufferCount; i) { ATRACE_BEGIN(SendBuffer); SendAudioBuffer(dev, ...); ATRACE_END(); // 结束SendBuffer // 记录一个整数计数器 ATRACE_INT(SndBufferUsage, dev-buffer.used_bytes); } ATRACE_END(); // 结束最外层的PlaySound }C的写法更简洁ATRACE_BEGIN和ATRACE_END会自动匹配最近的一对。Java (SDK - 普通App开发用)这才是大多数Android应用开发者需要用的。你只能使用android.os.Trace类中公开的方法而且不能指定TAG所有调用都隐式使用ATRACE_TAG_APP。import android.os.Trace; public void playSound(String path) { // 注意这里用的是 beginSection() 和 endSection()没有TAG参数 Trace.beginSection(PlaySound); try { Trace.beginSection(OpenAudioDevice); try { SoundDevice dev openAudioDevice(); } finally { Trace.endSection(); // 结束OpenAudioDevice } for (int i 0; i bufferCount; i) { Trace.beginSection(SendBuffer); try { sendAudioBuffer(dev, ...); } finally { Trace.endSection(); // 结束SendBuffer } // 记录计数器 Trace.setCounter(SndBufferUsage, dev.getBufferUsage()); } } finally { Trace.endSection(); // 结束PlaySound } }代码看起来和系统级很像只是方法名和参数少了TAG。但关键在于要让这些埋点生效抓trace的命令必须特殊处理我们会在第4节详细讲。C (NDK - 普通App的Native开发用)如果你的App有JNI或纯Native模块需要在C层埋点就用NDK提供的API。需要包含android/trace.h头文件。#include android/trace.h #include unistd.h void PlaySound(const char* path) { ATrace_beginSection(PlaySound); // 测量打开音频设备的时间 ATrace_beginSection(OpenAudioDevice); struct snd_dev* dev OpenAudioDevice(); ATrace_endSection(); // 结束OpenAudioDevice for (int i 0; i bufferCount; i) { ATrace_beginSection(SendBuffer); SendAudioBuffer(dev, ...); ATrace_endSection(); // 结束SendBuffer // 记录计数器 ATrace_setCounter(SndBufferUsage, dev-buffer.used_bytes); } ATrace_endSection(); // 结束PlaySound }NDK API的函数名加了ATrace_前缀并且同样没有TAG参数。它的生效条件和Java SDK一样依赖于ATRACE_TAG_APP是否被启用。2.2 记录数值变化的计数器Counter有时候我们不光想知道一段代码执行了多久还想观察某个变量随时间的变化趋势比如内存使用量、队列长度、FPS等。这时就需要用计数器Counter。计数器可以在任何线程、任何地方被更新它在Perfetto UI里会显示为一条随时间波动的折线。Java (Platform Private)import android.os.Trace; import static android.os.Trace.TRACE_TAG_AUDIO; public void updateBufferStats(SoundDevice dev) { // 不像同步块计数器没有begin/end直接设置值即可 // 这个值会在Trace中作为一个名为SndBufferUsage的计数器被记录 Trace.setCounter(TRACE_TAG_AUDIO, SndBufferUsage, dev.getBufferUsedBytes()); }C (Platform Private)#define ATRACE_TAG ATRACE_TAG_AUDIO #include cutils/trace.h void UpdateBufferStats(struct snd_dev* dev) { // 记录一个整型值 ATRACE_INT(SndBufferUsage, dev-buffer.used_bytes); // 如果需要记录64位整数用ATRACE_INT64 // ATRACE_INT64(TotalBytesProcessed, totalBytes); }Java (SDK) C (NDK)SDK和NDK的计数器API同样去掉了TAG参数其他用法一致。// Java SDK Trace.setCounter(SndBufferUsage, dev.getBufferUsedBytes());// C NDK ATrace_setCounter(SndBufferUsage, dev-buffer.used_bytes);计数器的妙用在于你可以把它放在一个定时器或循环里持续更新某个状态值。在分析卡顿问题时如果你同时能看到“主线程耗时块”和“渲染队列长度”这个计数器就能一眼看出是不是因为队列堆积导致了延迟。2.3 跨越线程的异步任务跟踪前面讲的都是“同步块”要求begin和end必须在同一个线程内按顺序执行。但现代应用大量使用异步编程一个任务可能在不同线程间切换。比如你点击按钮触发一个网络请求这个请求在后台线程执行完成后回到主线程更新UI。如果用同步块你只能分别跟踪主线程和后台线程的两段无法在视觉上将它们关联成一个完整的“用户旅程”。这时就需要异步跟踪Async Trace。它的核心思想是给一个逻辑上相关的开始和结束事件打上同一个“cookie”通常是一个自增ID这样Perfetto就能把它们连接起来形成一个跨线程、跨时间的“异步片段”。Java (Platform Private)假设我们跟踪一个用户点击后发起的异步加载任务。import android.os.Trace; import static android.os.Trace.TRACE_TAG_NETWORK; public class MyActivity extends Activity { private AtomicInteger lastJobId new AtomicInteger(0); private static final String ASYNC_TRACK_NAME UserJourney; private void onLoadButtonClicked() { // 生成一个唯一ID来标识这次异步操作 int jobId lastJobId.incrementAndGet(); // 在UI线程标记异步任务开始 Trace.asyncTraceForTrackBegin(TRACE_TAG_NETWORK, ASYNC_TRACK_NAME, LoadUserProfile, jobId); // 模拟一个网络请求在后台线程执行 new Thread(() - { // 模拟网络延迟 SystemClock.sleep(800); // 在后台线程标记同一个异步任务结束 Trace.asyncTraceForTrackEnd(TRACE_TAG_NETWORK, ASYNC_TRACK_NAME, jobId); }).start(); } }在Perfetto UI里你会看到一个名为“UserJourney”的独立轨道Track上面有一个从“LoadUserProfile”开始到结束的条块清晰地展示了这个异步任务的完整生命周期无论它跨越了哪几个线程。C (Platform Private)Native层的异步跟踪逻辑类似。#define ATRACE_TAG ATRACE_TAG_NETWORK #include cutils/trace.h #include atomic static constexpr const char* kTrackName UserJourney; static std::atomicint gLastJobId{0}; void OnButtonClicked() { int jobId gLastJobId; // 异步任务开始 ATRACE_ASYNC_FOR_TRACK_BEGIN(kTrackName, LoadUserProfile, jobId); std::thread([jobId]() { std::this_thread::sleep_for(std::chrono::milliseconds(800)); // 异步任务结束传入相同的jobId ATRACE_ASYNC_FOR_TRACK_END(kTrackName, jobId); }).detach(); }Java (SDK) C (NDK)SDK/NDK的异步API同样简化了不需要指定TAG和Track名称SDK API的Track概念被弱化了。// Java SDK private AtomicInteger lastJobId new AtomicInteger(0); private void onLoadButtonClicked() { int jobId lastJobId.incrementAndGet(); Trace.beginAsyncSection(LoadUserProfile, jobId); // 开始 new Thread(() - { SystemClock.sleep(800); Trace.endAsyncSection(LoadUserProfile, jobId); // 结束 }).start(); }// C NDK #include android/trace.h #include atomic static std::atomicint gLastJobId{0}; void OnButtonClicked() { int jobId gLastJobId; ATrace_beginAsyncSection(LoadUserProfile, jobId); // 开始 std::thread([jobId]() { std::this_thread::sleep_for(std::chrono::milliseconds(800)); ATrace_endAsyncSection(LoadUserProfile, jobId); // 结束 }).detach(); }异步跟踪对于分析复杂的、事件驱动的交互流程特别有用比如页面加载、数据同步、动画序列等。3. 进阶技巧让埋点更高效、更清晰掌握了基本写法我们再来看看如何让埋点代码更健壮以及如何利用Perfetto的一些高级特性。技巧一利用宏和RAII简化代码在C中我们可以利用对象的构造和析构函数自动匹配begin和end避免因提前返回或异常导致end丢失。系统其实已经提供了ATRACE_CALL()和ATRACE_NAME()这样的宏。#define ATRACE_TAG ATRACE_TAG_GRAPHICS #include utils/Trace.h // 注意这里用的是utils/Trace.h它封装了cutils/trace.h void MyRenderingFunction() { ATRACE_CALL(); // 自动以当前函数名作为片段名 // ... 你的渲染代码 } void AnotherFunction() { { ATRACE_NAME(PrepareResources); // 作用域仅限于这个大括号内 // ... 准备资源的代码 } // 离开作用域时Trace自动结束 // ... 其他代码 }ATRACE_CALL()本质上就是创建了一个局部对象在构造函数里调ATRACE_BEGIN析构函数里调ATRACE_END。这样写既安全又省事。技巧二动态生成Trace名称有时候我们希望Trace的名字能包含一些运行时信息比如DecodeFrame_1024x768。直接拼接字符串再传给ATRACE_BEGIN比较麻烦。我们可以用ATRACE_FORMAT这个宏需要包含gui/TraceUtils.h。#include gui/TraceUtils.h void DecodeFrame(int width, int height, int frameId) { // 像printf一样格式化字符串非常方便 ATRACE_FORMAT(DecodeFrame_%dx%d_id%d, width, height, frameId); // ... 解码逻辑 }技巧三为第三方库代码添加“观测点”如果你在分析一个卡顿问题怀疑是某个第三方库比如图片加载库、网络库内部耗时但你没法改它的源码怎么办一个实用的技巧是在你的代码里在调用该库前后加上Trace。如果这个库内部也恰巧有埋点很多流行库都有你甚至能看到更详细的内部划分。// 在你的App代码中包裹对第三方库的调用 Trace.beginSection(Glide.loadImage); try { Glide.with(context).load(url).into(imageView); } finally { Trace.endSection(); }这样即使Glide库内部的Trace因为TAG问题没抓到你至少有一个“Glide.loadImage”的总耗时块可以帮助你定位瓶颈是否在这个库的调用上。4. 关键一步正确抓取包含App埋点的Trace代码埋好了但如果抓取命令不对一切白搭。这是让App埋点生效的最关键一步。我们直接上命令。对于系统级platform private埋点你的命令里需要包含对应的TAG类别。比如你的代码用了ATRACE_TAG_AUDIO抓取时就要加上audio这个数据源。# 使用adb shell perfetto命令 adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto-trace -t 10s \ sched freq idle am wm audio gfx view binder_driver hal dalvik input res memory # 或者使用官方封装好的脚本推荐 ./record_android_trace -o my_trace.perfetto-trace -t 10s -b 32mb \ sched freq idle am wm audio gfx view binder_driver hal dalvik input res memory对于App级SDK/NDK埋点必须使用-a参数指定你的App包名来开启ATRACE_TAG_APP。这是很多教程里没强调但实际开发中最容易出错的地方。# 假设你的App包名是 com.example.myapp # 方法1使用adb shell perfetto关键是要加 -a package_name adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto-trace -t 10s \ -a com.example.myapp \ # - 就是这行 sched freq idle am wm gfx view binder_driver hal dalvik input res memory # 方法2使用record_android_trace脚本同样加 -a 参数 ./record_android_trace -o my_trace.perfetto-trace -t 10s -b 32mb \ -a com.example.myapp \ # - 这里 sched freq idle am wm gfx view binder_driver hal dalvik input res memory为什么必须加-a我们回顾一下第1节讲的原理。系统在判断是否记录ATRACE_TAG_APP的埋点时会检查两个条件debug.atrace.tags.enableflags属性中ATRACE_TAG_APP对应的位是否被置为1。当前进程名是否在通过-a参数指定的应用列表中。当你执行带-a参数的perfetto命令时工具会帮你完成这两件事设置属性位并把你的包名加入调试列表。只有这样你在App里调用Trace.beginSection()和ATrace_beginSection()打的点才会被系统记录下来。一个完整的实战抓取流程确保手机通过USB连接adb devices能看到设备。编译并安装你的App包含埋点代码。启动你的App进入你想要分析的场景比如一个复杂的页面。在电脑终端执行抓取命令记得替换包名./record_android_trace -o /tmp/app_trace.perfetto-trace -t 15s -b 64mb \ -a com.example.myapp \ sched freq idle am wm gfx view binder_driver hal dalvik input res memory命令开始执行后立即在手机上操作比如滑动列表、点击按钮重现性能问题。15秒后脚本会自动将trace文件拉取到本地/tmp/app_trace.perfetto-trace并尝试在浏览器中打开ui.perfetto.dev加载它。5. 在Perfetto UI中定位和分析你的埋点抓取成功文件也打开了面对Perfetto UI密密麻麻的时间线怎么快速找到自己的埋点呢第一步筛选和搜索Perfetto UI左侧有一个搜索框。你可以直接输入你埋点时用的片段名比如“PlaySound”或“LoadUserProfile”。搜索结果会高亮显示在时间线上。同时在界面顶部的轨道Track列表中你应该能看到以你进程名如com.example.myapp命名的轨道点开它里面通常会有“Thread X”的子轨道你的同步块就显示在这些线程轨道上。异步块则可能会出现在一个独立的“Async”轨道里。第二步解读时间线找到你的片段后重点关注这几个信息长度Duration片段的横向宽度直接代表了它的执行时间。把鼠标悬停在上面会弹出详细面板显示精确的起止时间和耗时。层级Depth嵌套的beginSection会显示为上下堆叠的条块帮你理解函数调用栈。计数器Counter如果你埋了setCounter它通常会显示在对应轨道上方的一个独立图表里是一条连续的折线。你可以看到这个值随时间的变化结合同步块分析“队列长度激增是否导致了处理延迟”这类问题。第三步关联系统事件这是Perfetto比旧版Systrace强大的地方。你的App代码片段不是孤立的。你可以同时看到CPU频率和调度你的代码运行时CPU是在高频运行还是被降频了线程有没有被频繁切换系统负载同一时间其他进程或系统服务如system_server在忙什么是不是它们的活动抢占了CPU资源导致你的App卡顿渲染流水线SurfaceFlinger, Choreographer对于UI卡顿可以看你的主线程工作是否错过了VSync信号导致掉帧。举个例子你发现一个“DecodeImage”的片段耗时200ms。光看这个你只知道它慢。但结合系统事件你发现在这200ms期间CPU小核频率很低而且binder通信非常频繁。那么优化方向就明确了可能是低功耗模式限制了CPU或者进程间通信开销太大。你可以尝试申请更高的CPU频率或者优化binder调用次数。第四步使用切片Slice和计数器Counter分析在Perfetto UI的查询框Query (SQL)里你可以用SQL-like的语法进行更强大的分析。比如找出你的App中耗时最长的Top 5片段SELECT name, dur / 1e6 as dur_ms FROM slice WHERE track_id IN ( SELECT id FROM track WHERE name GLOB *com.example.myapp* ) ORDER BY dur DESC LIMIT 5;或者计算某个异步任务的平均耗时SELECT AVG(dur) / 1e6 as avg_dur_ms FROM slice WHERE name LoadUserProfile AND type async_event;这些分析能帮你从海量数据中快速定位关键瓶颈。6. 避坑指南与最佳实践根据我这些年的经验总结几个常见的“坑”和应对建议坑1埋点不生效症状代码加了命令执行了trace里找不到。排查检查命令App开发务必确认命令里有-a your.package.name。检查TAG系统开发确认代码里的ATRACE_TAG定义和命令里的数据源匹配例如代码用ATRACE_TAG_AUDIO命令要加audio。检查权限确保你的App有android.permission.DUMP权限系统应用或debug包通常有。极简测试写一个最简单的测试按钮里面只做beginSection和endSection排除业务逻辑干扰。坑2Trace对性能有影响吗结论有但很小。在发布release版本中务必通过编译开关或运行时判断将其关闭。做法// 定义一个DEBUG常量在发布构建时为false if (BuildConfig.DEBUG) { Trace.beginSection(MySection); } try { // ... 业务逻辑 } finally { if (BuildConfig.DEBUG) { Trace.endSection(); } }C中可以用宏或条件编译来实现类似效果。Perfetto本身的开销很低但频繁的字符串操作和函数调用在性能敏感路径上仍需注意。坑3Trace名字太长或动态生成开销大建议Trace名字尽量简短、有意义。避免在循环内部动态拼接字符串作为Trace名。如果必须包含动态信息考虑使用ATRACE_INT记录一个ID然后在分析时通过其他日志关联。坑4过度埋点trace文件巨大建议有策略地埋点。不要在每个函数入口都加。聚焦在已知的性能热点。跨组件/模块的边界。执行时间可能较长的操作网络I/O、文件I/O、复杂计算。用户交互的关键路径。 可以先广泛埋点定位问题区域问题解决后移除不必要的埋点只保留核心监控点。最佳实践清单成对使用用try-finally或C RAII确保每个begin都有对应的end。命名清晰名字要能直接反映代码意图如Bitmap.decode、Network.fetchUserData。分层嵌套合理使用嵌套来体现调用关系但不宜过深一般3-4层足够。区分同步/异步跨线程的任务使用异步跟踪让逻辑链路更清晰。善用计数器用计数器跟踪队列长度、缓存大小、FPS等变化量。发布版本关闭通过配置开关彻底关闭Trace逻辑。与日志结合在Trace片段开始或结束时打一条对应的Log便于在Logcat和Perfetto时间线之间交叉验证。性能优化是一个“观察-假设-验证”的循环。Perfetto和代码埋点为你提供了强大的“观察”能力。当你把代码的关键路径变成Perfetto时间线上一个个可视化的片段后那些隐藏的性能瓶颈就会无处遁形。从今天开始试着在你的下一个性能优化任务中有目的地添加一些埋点你会发现自己对代码执行过程的理解会上一个全新的台阶。