用Perfetto透视Flutter混合工程启动加载全流程

这一篇接着我们系列的加载性能话题，前几篇聊过Flutter混合工程的启动流程，也聊过Android侧的trace工具，这次把两者串起来：用perfetto同时观察Flutter和Android两个层面的加载过程。

做性能优化最忌讳没有现场就下手猜，而perfetto能把App从进程诞生、Activity建立、Flutter engine初始化、Dart首帧到Surface上屏的整个过程原样录下来。这篇文章适合正在被启动白屏、首帧慢、混合页面卡顿问题折腾的同学，跟着跑完一遍，你能独立抓取一份可分析的trace，并且能清楚指出耗时瓶颈到底在Android层还是Flutter层。

1. 加载过程的全貌：Flutter和Android其实是两条线在跑

1.1 一条App启动，两条执行路线

一个Flutter应用在Android上加载，很多人把它理解成“先启动Activity，再启动Flutter”，但实际情况要复杂得多。从perfetto的视角看，这是两条相对独立又必须协作的执行路线。

第一条是Android侧的执行流。应用进程被孵化器创建，ActivityThread开始跑，目标Activity被实例化，接着是View树构建、Window attach、Surface创建，最后交给SurfaceFlinger合成显示。这一侧牵扯大量系统服务：WindowManager负责窗口层级，ActivityTaskManager管理任务栈，Binder贯穿整个通信过程。这些系统行为全部会在perfetto里留下可追踪的slice。

第二条是Flutter侧的执行流。FlutterEngine创建后，Dart isolate初始化，Widgets binding启动，然后执行build、layout、paint流程，最后raster线程生成layer tree提交给GPU。这条线主要在Flutter自己的线程上运行，与Android主线程并不在一个线程里，而是通过vsync信号和Surface做交接。

关键就在“交接”这个环节。如果只盯App内部日志，你只能看到自己埋点的时间点；如果只看Flutter的Timeline，你会漏掉Android系统侧在干什么。只有把两条线放在同一根时间轴上对比，才能判断白屏到底卡在“Flutter还没有渲染出来”还是“渲染好了但Android没有合成上屏”。

1.2 为什么偏偏用perfetto，而不是其他方式

之前也试过其他工具，各自有各自的问题。

Android Studio的CPU Profiler用起来方便，点一下按钮就能看到调用栈和线程活动，但它更偏向交互式分析，而且对启动过程这种“从系统侧拉起来”的场景，容易漏掉进程创建阶段的事件。应用自己的日志只能证明某个时间点被执行了，无法解释线程为什么在那个时间点没有schedule到CPU上。Flutter自带Timeline可以看Dart侧的事件，但和Android系统事件割裂，两边的时钟对起来很麻烦。

perfetto的优势是系统级、无侵入、跨进程。它直接在内核持续追踪层采集数据，应用不用加agent，也不影响性能，录到的是整机所有进程在同一时间轴上的行为。你既能看到目标App的线程调度，也能看到SurfaceFlinger、system_server、CPU频率和GPU活动。对启动加载这种多进程协作场景，这是最合适的观察手段。

1.3 抓取前的环境准备

动手之前先把基础环境确认好。需要一台Android 10以上的设备，开发者选项里打开USB调试。先跑一下命令确认perfetto可用：adb shell perfetto --version，正常会返回版本号。如果设备上报错或者提示命令不存在，多半是系统镜像太老，建议换一台新系统设备。

Flutter项目要打一个profile构建包，命令是flutter build apk --profile。为什么要profile而不是debug或者release？debug包性能太差，测出来的数据失真；release包会把Flutter engine的大量timeline事件关掉，很多关键阶段标记看不到。profile模式保留了timeline信息，同时性能表现接近release，是做启动分析的常规选择。

分析阶段需要访问ui.perfetto.dev，这是一个浏览器端的trace分析工具，直接把pull下来的文件拖进去就能看，不需要额外安装桌面软件。

2. 完整抓取一次带Flutter标记的trace

2.1 命令行抓取：最简单的一条命令

先给最简单的方案，一条adb命令搞定采集。打开终端，执行：

adb shell "perfetto -o /data/misc/perfetto-traces/startup_trace.perfetto-trace -t 15s -b 64mb sched freq idle am wm gfx view"

稍微拆解一下参数。

-o指定输出路径，写到/data/misc/perfetto-traces这个目录下，普通shell用户就有写权限。-t 15s是采集时长，启动过程一般10到20秒足够覆盖。-b 64mb是buffer大小，buffer太小容易丢尾部事件，分析首帧最怕丢数据，宁可大一点。

后面的sched freq idle am wm gfx view是数据源categories，每一个都有具体含义：

• sched：线程调度事件，看关键线程什么时候被拉到CPU上；
• freq：CPU频率变化；
• idle：CPU核的空闲状态；
• am：ActivityManager事件，能看到进程启动和Activity创建；
• wm：WindowManager事件，窗口attach和relayout；
• gfx和view：渲染相关，包含Choreographer和doFrame等信息。

顺序也很重要。抓取之前先执行的这几步，很多人会忽略导致trace里看不到启动第一帧：

adb logcat -c adb shell am force-stop 你的包名

然后启动perfetto采集，紧接着用另一个终端执行：

adb shell am start -W 你的包名/你的启动Activity

am start -W会输出一个TotalTime，这个东西可以作为辅助参考。但要注意，它统计的是Activity启动完成时间，并不完全等于Flutter首帧上屏时间，两者之间的差值本身就可能是问题。

抓完之后，从设备上把trace拉回来：

adb pull /data/misc/perfetto-traces/startup_trace.perfetto-trace ./startup_trace.perfetto-trace

拉到本地后，拖到ui.perfetto.dev就能打开。

注意：如果设备上提示perfetto权限不足，去开发者选项里把“系统跟踪”打开，部分深度定制系统需要额外授权。

2.2 需要更细粒度时，用配置文件替代命令行

命令行虽然方便，但事件种类只能选固定的几个，而且没法设置更细的参数。遇到需要观察Binder通信或者调整buffer策略的情况，建议用文本配置文件。

先把配置文件写好：

buffers { size_kb: 65536 } duration_ms: 15000 data_sources { config { name: "linux.ftrace" ftrace_config { ftrace_events: "sched/sched_switch" ftrace_events: "sched/sched_wakeup" ftrace_events: "power/cpu_frequency" } } } data_sources { config { name: "atrace" atrace_config { categories: "gfx" categories: "view" categories: "am" categories: "wm" app_name: "你的包名" } } }

这个配置同时启用了内核ftrace事件和atrace的应用层事件，app_name用于只追踪指定应用的atrace标记，避免其他App噪音干扰。

然后push到设备并执行：

adb push config.pbtx /data/local/tmp/ adb shell "perfetto --txt -c /data/local/tmp/config.pbtx -o /data/misc/perfetto-traces/custom_trace.perfetto-trace"

--txt表示配置是文本格式，有些老版本Android设备只支持二进制protobuf格式，遇到报错就查一下设备上perfetto --help的说明。配置文件最大的价值是可以精确控制想要哪些事件，buffer策略也更灵活。

2.3 在关键位置打点，给trace加“路标”

默认情况下，采集到的trace里能看到系统事件和Flutter engine的部分事件，但业务代码具体什么时候跑到哪里，还是需要自己埋点。埋点的好处是快速对齐“业务时间”和“系统时间”，不用靠猜。

Android宿主侧，在Activity的onCreate里加：

import android.os.Trace; @Override protected void onCreate(Bundle savedInstanceState) { Trace.beginSection("AppStartup_onCreate"); super.onCreate(savedInstanceState); // 业务逻辑 Trace.endSection(); }

Flutter侧，需要引入Timeline：

import 'package:flutter/foundation.dart'; void main() { Timeline.startSync('AppStartupDart'); runApp(MyApp()); Timeline.finishSync(); }

这些打点会出现在perfetto的atrace事件流里，用搜索一查就能定位。我的习惯是每个关键阶段都埋，比如FlutterEngineCache_put、Activity_onResume、FirstFrame_Callback，名字统一带项目前缀，后续批量统计也好用。

2.4 拉出trace，用Perfetto UI快速定位关键区间

trace文件拖进ui.perfetto.dev之后，第一件事不是看细节，而是把视野缩放到启动时间段。整个trace可能有15秒，而启动过程往往只有头几百毫秒到一两秒。

几个快捷键是必须记住的。W和S是放大和缩小时间轴，A和D左右平移，按住鼠标可以框选区域，双击某个slice会直接跳转到它所在的线程和上下文。按M键可以在当前位置打一个临时标记，做阶段对比非常方便。右上角的搜索框支持正则表达式，输入flutter能看到所有Flutter相关事件，输入Rasterizer能看到栅格化过程。

左侧面板可以勾选显示Thread States、CPU Slices等行，分析线程为什么等待时这一步一定要打开。把线程状态行拖出来，颜色越深越说明线程在阻塞等待，绿色通常代表正在运行，浅色代表可运行但没有被调度。

3. 从Trace里拆解Flutter加载的关键阶段

3.1 先认清几条核心线程

围绕着一张加载trace，主要关注下面这几条线程。Flutter不同版本的线程命名有差异，常见形式是主线程叫main，Flutter engine线程叫1.ui、2.raster、0.platform这样的组合，压测机型上可能还会带进程号后缀。先找到包含ui、raster、platform的线程，确认它们归属你的App进程。

加载阶段，platform线程会先忙一阵，做引擎初始化和插件注册；ui线程开始跑Dart代码；raster线程要到第一帧需要显示时才正式干活；Android的main线程则全程参与Activity生命周期。四个线程谁先谁后、谁等谁，就是加载耗时的本质。

3.2 按阶段标记把加载流程切开看

在perfetto里搜关键字flutter，能看到engine侧的一串事件。不同版本命名不完全一样，但通常能找到这几类：

• flutter::Shell::Shell或者类似名字：Shell创建，引擎初始化起点；
• Dart isolate初始化相关事件：包含Dart VM启动、加载快照或内核文件；
• flutter::Rasterizer::Draw：栅格化线程真正绘制layer tree的slice，通常比较长；
• 与vsync相关的事件：UI帧调度开始；
• firstFrameRasterized或带first frame字样的标记：Flutter侧首帧栅格化完成。

分析思路是沿着时间轴，从进程诞生开始，找到引擎初始化起点，再找到Dart isolate完成点，然后找到ui线程第一次BeginFrame到EndFrame的区间，最后定位Rasterizer::Draw结束处。这个过程可以切成四段：进程和Activity建立、引擎初始化、Dart首帧构建、栅格化上屏。哪一段占比最长，就往哪个方向继续深挖。

Perfetto的搜索框支持正则表达式，可以输入^flutter批量过滤，把所有Flutter事件列出来。但不要指望所有版本引擎事件名完全一致，看到的是1.ui的线程在某个时间段里有长slice，就知道Dart侧在跑重量级逻辑。

3.3 Android侧的启动事件和Surface事件怎么看

分析的主角虽然是Flutter，但Android侧的Activity启动和Surface流程同样重要。在trace里搜索am_proc_start可以定位进程创建时间，搜索wm_task_created能看到任务栈创建，startActivity相关slice能对应到系统拉起Activity的时间点。

Android系统的启动事件和Flutter事件是交替出现的，可对比的关键点有两处。第一处是进程创建到FlutterEngine创建之间的间隔，这段时间纯粹消耗在系统孵化和Activity创建上；第二处是Flutter首帧Ready到SurfaceFlinger实际合成本文之间的间隔，这期间可能在等Surface attach或者等待vsync信号。

如果日志里已经看到了Flutter首帧完成，但屏幕一直白屏，十有八九问题在SurfaceFlinger合成或者View attach流程。这时候把视野拉到SurfaceFlinger进程上，看它的onTransaction和queueBuffer相关slice，能看到合成究竟卡在哪里。

3.4 别把两个“首帧”搞混了

这是排查时最容易被绕进去的地方。Flutter侧的“首帧”和Android侧的首帧并不是同一个东西。

Flutter的firstFrameRasterized表示layer tree已经在raster线程上栅格化完成，GPU命令已经生成。Android侧的首帧是指SurfaceFlinger把这块buffer真正合成到屏幕上。两个时间点之间至少隔着一次buffer队列提交和一次vsync同步。极端情况下，Flutter首帧完成得很早，但surface一直在等待状态，用户看到的仍然是白屏——这种情况如果只用Flutter的日志排查，永远找不到答案。

定位两个时间点，就是从firstFrameRasterized事件和SurfaceFlinger的提交事件中间的时间差入手。之后再把RenderThread上的queueBuffer事件一起考虑，基本能还原一次完整的上屏链路。

4. 典型耗时瓶颈与排查方向

4.1 一次典型的双端耗时对比

之前接手一次启动优化，现象是某App冷启动接近1秒，用户感知明显。当时的第一步就是把日志埋点和perfetto trace一起抓了。

trace打开之后，先看整体区间：从am_proc_start到firstFrameRasterized大概700ms出头，这比预期要高。继续往下切，发现FlutterEngine的Shell创建其实只占了一小段，Dart isolate初始化也不是大头，真正的长slice出现在main线程上的View构建阶段——一段很厚的inflate相关slice，同时ui线程大量时间处于浅色等待状态。也就是说，Flutter侧已经准备好执行Dart逻辑了，结果因为Android主线程还在做Window相关的活，vsync信号迟迟没有送来。

处理方式是把一部分不依赖Window的初始化逻辑延后，同时把FlutterEngine预热提前。改完再抓一轮trace，main线程的inflate区间明显变薄，ui线程开始干活的时间点提前了，整体首帧时间压缩了约200ms。

这个例子的价值在于：只看日志会以为是Flutter引擎慢，实际瓶颈在Android主线程的窗口建立流程上。两边的trace数据摆在一起，结论才不会被带偏。

4.2 底部曲线怎么读：频率和空闲状态

Perfetto界面下方通常会有CPU Frequency、CPU Idle、CPU Slices曲线。这些曲线看起来不起眼，但读懂了能快速判断是计算瓶颈还是调度瓶颈。

CPU频率曲线如果在大负载时段一直贴着最高频，说明当前是真实计算压力；如果频率起不来，一直低水平运行，就要考虑供电策略、温控降频或者系统负载不高但任务长期得不到调度。CPU Idle曲线则能看出整体系统空闲程度，如果设备整体很忙，其他进程占着核心，你的App线程就只能排队。

观察线程调度要配合CPU Slices行：绿色表示线程正在某个核上执行，浅色表示线程处于Runnable但没抢到CPU，深色表示阻塞等待。如果整条时间线上绿色很短、浅色很长，说明App线程在等待调度器分配核心，这时候硬编码减少业务逻辑意义不大，看看是不是启动阶段线程开太多，还是在跑重量级后台任务抢占了cpu。

4.3 线程状态和GPU瓶颈的交叉判断

当Rasterizer::Draw这种slice特别长时，先不要急着下结论说GPU不行。要看对应的freq曲线：如果栅格化阶段频率拉满，说明确实在做大量计算，可以考虑减少重叠效果、检查离线渲染路径；如果频率不高，slice却很长，大概率不是算力问题，而是shader编译、buffer分配或者等某个同步对象。

RenderThread上的queueBuffer阻塞是另一个常见坑。当queueBuffer事件间隔很大，往往意味着SurfaceFlinger或BufferQueue没能及时消费提交的buffer，这回过头来又会影响raster线程的下一次绘制。遇到这种情况，优先检查是不是窗口Surface尺寸与Flutter生成的buffer不一致，或者设备启用了某种裁剪合成策略。

还有一条经验：ui线程slice过长的情况里，有很大比例不是算法本身慢，而是后续的vsync被错过。ui线程跑太久，错过了下一次vsync信号，整个帧就得推迟到下一拍，视觉上就表现为首帧或滑动卡顿。perfetto里能看到Choreographer相关事件，对比BeginFrame和物理vsync之间的时间偏移，就能看出是不是这个原因。

5. 让分析可复现：从Trace里的信息到实际优化动作

5.1 用SQL查询批量统计关键slice耗时

Perfetto UI自带一个Query分析页签，支持用SQL查询slice数据。分析完单条trace后，可以用同一套SQL批量统计优化前后的变化，非常方便。

SELECT name, count(*) AS cnt, round(avg(dur / 1e6), 2) AS avg_ms, round(sum(dur / 1e6), 2) AS total_ms FROM slice WHERE name GLOB '*flutter*' OR name GLOB '*Rasterizer*' OR name GLOB '*inflate*' GROUP BY name ORDER BY total_ms DESC;

这段SQL会列出所有与Flutter和栅格化相关的slice的调用次数、平均耗时和总耗时。跑出来的结果比肉眼在时间轴上框选要准确得多，尤其在对比两个版本的trace时，可以直接给出量化结论。

建议每次抓trace都保留一份带版本号和时间戳的命名：比如trace_20240101_rel100_before.perfetto-trace和trace_20240110_rel101_after.perfetto-trace。时间久了，这些文件就是性能回归的证物。之前在排查一个偶现的卡顿时，靠的就是三天前留的baseline trace，直接对比出多出来的一个shader编译耗时段，否则单看一次trace很难确认什么才算异常。

5.2 从trace数据反推代码层面的优化策略

trace告诉你“耗时在哪”，代码改动要回答“怎么把耗时降下去”。如果耗时段集中在Android主线程的inflate和relayout，思路是减少启动阶段Android View层级，或者把FlutterEngine预热提前，让两条线并行起来。如果耗时段在Dart侧build和layout，属于组件树太复杂，需要考虑减少首帧页面元素，用异步加载替代同步等待。

这里踩过一个坑：启动阶段为了做预加载，开了好几个后台线程去拉配置和图片，结果perfetto显示这些线程把CPU核心吃满，Flutter的ui线程反而长时间等待调度。优化了一阵业务逻辑都没效果，直到把trace的CPU Slices拉出来才发现是自研的后台任务在捣乱。延迟到首帧结束再启动这些任务，问题立刻缓解。所以优化启动性能的原则之一是不要在启动阶段额外制造线程竞争，预加载听上去很理想，但代价经常被忽略。

5.3 形成“先录现场，再改代码”的固定工作流

工具本身不难，难的是养成的分析习惯。我自己固定下来的一套流程是：每次大版本改造前后，在固定的测试机、固定的网络和充电状态下，抓一份profile模式的冷启动trace。采集完成后先跑一遍SQL看关键slice统计，再人工核对一次Rasterizer::Draw和inflate的拖影情况，最后留档保存。

三五个版本下来，这些trace数据会形成一个性能基线库。某次发布后发现用户反馈变卡，把当期的trace和基线库一拉出来，变化一目了然。这比靠记忆和日志猜问题靠谱太多。Flutter和Android加载过程的坑很隐蔽，但trace不会说谎，记录也不会说谎。