第 11010、11020 篇分别讲了 Insights 和 stat 命令，这一篇把它们串成一条实战路径：怎么从"帧时间超标"走到"某个函数占 4ms"，以及 GameThread 上反复出现的那些元凶。工具链基于 UE5.3，平台剖析器以 macOS 的 Instruments 为例（Windows 侧对应 VTune/Superluminal，思路一致）。
从剪刀差说起
stat unit 给出三个数：Frame、Game、Draw（渲染提交线程）。先看的不是绝对值，是Game 和 Frame 的关系：
- Frame ≈ max(Game, Draw, GPU)：三者并行，帧时间由最慢的那个决定。优化 Game 3ms 对 Frame 没影响的情况比比皆是——先看清楚瓶颈在哪条线程，再决定干什么；
- Game 远大于 Draw 且 Frame 跟着 Game 走：典型 GameThread 瓶颈，本篇的主角；
- Game 和 Draw 都不大但 Frame 大：瓶颈在 GPU 或同步点，去 11040 篇。
60fps 的预算 16.6ms，30fps 是 33.3ms。GameThread 的一帧在引擎侧拆成 Tick（世界更新）、GC 增量、AsyncLoading 回调收口几块，用公式记：
$$T_{game} = T_{tick} + T_{gc} + T_{load} + T_{other}$$
定位就是逐块做减法：Insights 的 Timing 视图里这几块都有对应轨道（Frame、GameThread、GarbageCollection、AsyncLoad），哪块鼓起来先看哪块。
GameThread 长胖的原因清单
按我遇到的频率排，每一条都带过验证方法：
- Actor Tick 泛滥。几百个 Actor 开着
PrimaryActorTick，每个都做点小计算，加起来就是数毫秒。验证：stat game里看 Tick 时间，或者 Insights 里按 Inclusive 时间排序，Tick 函数族霸榜即是。治理手段不用多说：关掉不需要 Tick 的、能降频的降频（TickInterval）、把分散的小 Tick 合并成一个管理器统一驱动； - UMG/Slate 每帧失效。绑定（Bind）每帧求值、没有
SInvalidationPanel缓存的复杂 UI，一帧重排重绘几次。验证：Insights 里 Slate 轨道，Paint/ArrangeChildren高频出现就是； - 蓝图 VM 热点。每帧的 For 循环里做字符串拼接、
Cast To滥用（每个 Cast 都是一次接口查询），在纯蓝图项目里能吃掉一两个毫秒。验证：Insights 能看到蓝图函数的符号（stat namedevents或直接函数名），热点函数带ExecuteUbergraph前缀； - GC 增量。UObject 数量大到几十万后，哪怕增量 GC（每帧扫一片）也要摊几百微秒，全量 Purge 偶尔插入一帧就是十几毫秒的尖刺。验证：GarbageCollection 轨道看增量耗时分布，
obj list看对象总数是否失控； - 同步加载。
LoadObject/FlushAsyncLoading直接出现在 GameThread——这是 11060 篇的专题，这里只要会认：Insights 里 LoadPackage 挂在 GameThread 轨道上就是； - 日志。每帧
UE_LOG的格式化 + 输出刷新在 Shipping 关掉，但 Development 包里是真实开销，日志风暴还能把帧时间打出毛刺； - 物理同步查询。GameThread 上的
LineTrace/Overlap走 Chaos 的同步路径，场景复杂时单次几毫秒。验证：Insights 里FPhysicsScene相关符号。
这份清单的价值在于每个元凶都有可观测的签名（某个轨道鼓起来、某类函数霸榜）， profiling 不是猜谜，是逐条排除。
两条下沉路径：Instrumentation 与采样
从"哪块"到"哪个函数"有两条路，互为补充：
- Instrumentation：
SCOPE_CYCLE_COUNTER(Stat_XXX)打点，统计的是精确时间，但只覆盖打了点的地方，且打点本身有几十纳秒开销，打在太细的函数上会污染数据。适合确认"就是这块"，以及上线后长期监控（stat showframe能看到自己定义的组）； - 采样：平台剖析器（Instruments 的 Time Profiler、VTune）按固定间隔（一般 1ms 或更细）抓调用栈，不需要打点，能看到包括第三方库在内的全部热点，统计精度受采样率限制。适合探索期——不知道热点在哪时，先采样看火焰图，再决定往哪打
SCOPE_CYCLE_COUNTER。
顺序上我建议：Insights 定线程和阶段 → 平台采样定函数族 → 关键路径补 SCOPE_CYCLE_COUNTER 做长期可观测。反过来的做法是盲区采样，漏掉没打点的代码。
Amdahl 账：别优化错对象
优化前算一笔账。设热点占帧时间比例为 $p$，优化后加速 $s$ 倍，新帧时间：
$$T' = T\left(1 - p + \frac{p}{s}\right)$$
两个常用推论：$p = 50\%, s = 2$ 时帧时间降 25%，帧率提升 33%——不是"翻倍"；$p = 5\%$ 的函数哪怕优化到零，帧时间也只降 5%。采样火焰图里排第三的函数值不值得动，用这个公式一算就知道。反过来，如果被 Insights 判定瓶颈在 GPU，GameThread 上的一切优化对帧率的影响都是零——先确认 $p$，再投入。
观测成本与误区
- Insights 的 trace 本身有开销（CPU 通道大约几个百分点），绝对帧时比平时低一点是常态，看相对分布不受影响；
SCOPE_CYCLE_COUNTER不要打在循环体内部的细粒度函数上，打点的固定开销会盖过被测时间；- Release/Shipping 符号裁掉后采样只剩地址，剖析用 Development 或 Test 构建，别把 Development 的绝对数字当线上表现，看结构不看绝对值。
流程闭环：剪刀差定线程 → 轨道定阶段 → 采样定函数 → 公式定值不值 → 打点留监控。每一步都有明确的判据，剩下的只是按图施工。