页面“感觉卡”，第一步应该测什么？

测试说“这个页面感觉有点卡”，开发打开代码，先加 const、拆 Widget、减少 setState。改完以后，大家再凭手感判断有没有变快。

问题在于，“卡”可能是滚动掉帧，也可能是点击后迟迟没有反馈、接口回来后解析太慢，或者首屏内容出现得晚。它们不是同一种问题。

核心结论：第一步不是测 Rebuild 次数，也不是看平均 FPS，而是固定一个具体操作，记录“用户动作到可见结果”的时间线。只有先确定慢在哪个阶段，后面的指标才有意义。

先把“卡”改写成一句可测的话

“订单页很卡”无法复现，也无法比较。可以改成：

点击订单后，加载态多久出现；
数据返回后，内容多久完成显示；
快速滚动列表时，哪些帧超过预算；
页面首次打开时，首个界面和主要内容分别何时可见。

一次只选一个场景，并固定设备、构建模式、数据量、网络条件和操作步骤。否则两次结果的差异可能来自环境，而不是代码修改。

这条链路中任何一段变慢，用户都可能只说一句“卡”。

不同的“卡”，第一指标不同

现象	第一批指标	先回答的问题
滚动、动画不顺	单帧 UI 与 Raster 耗时、慢帧位置	是哪一帧没按时完成？
点击后没反应	输入到首次反馈的耗时	事件没处理，还是反馈出现太晚？
内容出现很慢	请求、解析、状态提交、首帧各阶段耗时	时间花在网络还是本地？
首次打开慢	TTID、TTFD	首个界面和完整内容分别多晚？

TTID（Time to Initial Display）关注初始界面何时显示，TTFD（Time to Full Display）关注主要内容何时完整可用。它们不能用一个“页面耗时”混在一起。

滚动卡，先看慢帧而不是平均 FPS

在 60 Hz 屏幕上，每帧间隔约为 16.7 ms；120 Hz 约为 8.3 ms。少数帧明显超时，平均 FPS 仍可能看起来不错，但用户已经感到停顿。

在目标真机的 Profile 模式下，用 DevTools Performance 录制问题发生的短时间窗口，先看：

慢帧是否稳定出现在同一操作；
UI 侧还是 Raster 侧超出帧预算；
慢帧附近发生了哪些业务事件。

UI 侧慢，再检查同步计算、Build、Layout 和 Paint 记录；Raster 侧慢，再检查大图、复杂绘制、滤镜和纹理相关工作。两边都正常，点击却迟迟没有结果，就应继续查网络、平台调用和业务等待，不要硬在 Widget 树里找原因。

给业务链路留下时间节点

只有 Flutter 帧图时，经常只能看到“这一帧很慢”，却不知道它对应哪个业务动作。可以用 TimelineTask 标记关键节点：

import 'dart:developer';
 
Future<void> loadOrderDetail() async {
  final task = TimelineTask()..start('load_order_detail');
 
  try {
    setState(() => _loading = true);
    await WidgetsBinding.instance.endOfFrame;
    task.instant('loading_visible');
 
    final order = await orderRepository.loadOrder(orderId);
    task.instant('data_ready');
 
    if (!mounted) return;
    setState(() {
      _order = order;
      _loading = false;
    });
    await WidgetsBinding.instance.endOfFrame;
    task.instant('content_visible');
  } catch (_) {
    if (mounted) setState(() => _loading = false);
    rethrow;
  } finally {
    task.finish();
  }
}