自动关联目录：性能方法论

1. 定位

这一页不讲任何具体优化手段，只讲"怎么让优化这件事可验证"。

一句话定位：没有指标和复测的优化等于没做——你不知道改好了没有，也不知道什么时候又退化回去。

2. 先定义指标

在动手前必须说清楚：

问题	例子
目标帧率是多少？	60 fps（16.6ms）/ 30 fps
目标分辨率与画质档？	1080p + High
目标机型是什么？	最低配机型，不是开发机
场景基准是什么？	固定一段回放 / 固定关卡点位
可接受的内存峰值？	例如 ≤ 1.5 GB

"在我的机器上很流畅"不是指标。目标机型、固定场景、固定画质档，三者缺一不可。

3. 测量纪律

纪律	说明
先测后改	没有基线就无法判断改动有效
一次只改一处	同时改三处，无法归因
固定场景复测	用同一段回放或同一点位
多次取中位数	单次结果噪声大
测打包版本	编辑器与打包差异很大
关掉调试可视化	可视化本身有成本
在目标机型上测	开发机的核心数与 GPU 都不同
移动端还要清缓存	见下

容易被测量本身欺骗的地方

陷阱	处理
驱动 PSO 缓存掩盖卡顿	加 `-clearPSODriverCache`（见 PSO 预缓存）
高核心开发机掩盖加载问题	`-corelimit=8`（同上）
异步计算让 GPU 计时失真	`r.RDG.AsyncCompute 0`，仅用于分析
CPU-bound 时 `stat gpu` 不可靠	用 `profilegpu` 或平台工具（见 GPU 剖析）
抓帧工具本身拖慢帧率	固定帧率（DumpGPU 的 `FixedTickRate`）

4. 定位瓶颈的顺序

1. stat unit → Game / Draw / GPU 谁高
   ├─ Game 高 → [CPU 剖析](/334e1c78.html)（游戏线程）
   ├─ Draw 高 → [CPU 剖析](/334e1c78.html)（渲染线程 / 剔除）
   └─ GPU 高 → [GPU 剖析](/01d9ef35.html)
2. 都不高但帧率低？→ 同步点：Flush、加载、VSync、帧率上限
3. 有尖峰？→ [加载与卡顿](/c6dc2cca.html)
4. 内存问题？→ [内存剖析](/583c14e2.html)
5. 移动端发热后变慢？→ [移动端功耗与发热](/d02da1dc.html)（**时间维度**）

"四项都不高但帧率低"几乎总是同步问题，不要去优化渲染或逻辑。

5. 优化顺序（收益从大到小）

层级	手段	典型收益
1	降分辨率 / 屏幕百分比	最大，且立竿见影
2	砍全屏 pass 数量	大（尤其移动端）
3	减少加载量（流式、剔除）	大
4	减少 draw call（实例化、合并）	中
5	简化材质指令数	中
6	减少三角形	小（除非极端）

"减少三角形"排在最后，这是很多人搞反的一点——在现代 GPU 上，填充率与带宽通常比三角形数更早成为瓶颈。

6. 防回归

手段	说明
CI 上的性能基线	固定场景自动跑，超阈值报警
包体监控	见包体分析
崩溃与稳定性	见崩溃与 Dump
改动后必须复测	写进流程，不靠自觉
记录每次优化的数据	半年后能回答"当时为什么这么做"

7. 代价与权衡

做法	收益	代价	什么时候不该做
严格测量流程	结论可信	前期慢	从不做——这是必须的
只优化不看指标	快	等于没做	—
在高端机调优	省事	结论不适用于目标机型	永远要在最低配机型验
一次性优化	快	很快退回	必须配 CI 基线
微优化	局部变快	可能牺牲可维护性	先做量级大的那几项

8. 踩坑与排查

坑	现象	怎么验证
优化完没效果	改的不是瓶颈	回到 `stat unit` 重新定位
优化完更慢	引入了新成本	复测对比
编辑器流畅、打包卡	配置差异	必须测打包版本
只在开发机测	目标机型崩	在最低配机型验
没清 PSO 驱动缓存	卡顿测不出来	`-clearPSODriverCache`
开着可视化测	数据偏高	关掉
只测一次	结论不稳	多次取中位数
一段时间后又变慢	没有防回归	CI 性能基线