技能介绍

游戏掉帧通常不是单点问题：帧率忽高忽低、Update 里偶发卡顿、移动端热降频、或达不到 60 FPS 目标时，团队容易凭直觉去“优化看起来最慢的地方”。结果往往是热行微调没有收益，反而引入了池化、批合并等额外复杂度。

真正可控的性能工作是一套测量纪律：先剖析，再找单一最大成本，修复，然后重测。这个技能把这条闭环固化成可复用流程，而不是零散技巧合集。

核心流程分为 7 步：

定义目标并复现最差场景：把“感觉有点慢”换算成 16.67 ms/frame 这类数字，并找到可重复的最坏场景。
剖析后再改代码：读取总帧时间，以及 CPU（逻辑、物理、脚本）与 GPU（渲染）的耗时切分。
判断瓶颈在 CPU 还是 GPU：GPU 偏重时处理 draw call、overdraw、shader 与分辨率；CPU 偏重时处理脚本、物理与分配。
只修最大成本：优先做算法层降载，例如减少工作量、缓存、空间分区或降低执行频率，再套用通用手段。
同场景重测：确认帧时间确实下降，用数据决定保留或回滚。
设置预算与资产上限：为每个子系统设定每帧 ms 预算，并加入纹理、三角形和 draw call 等资产预算。
汇报实测数字：提供优化前后的帧时间对比，而不是“应该更快了”。

该技能同时覆盖高频修复模式：对象池、批合并与实例化、消除 Update 内的逐帧分配与 GC 尖峰、处理透明物体叠加导致的 overdraw，以及 LOD/剔除和移动端热设计等资产预算建议。

不要在编辑器或 debug 构建上得出结论，它们会引入编辑器开销且缺少编译器优化；应在目标硬件的 release 构建上测量。
先确认 CPU/GPU 切分，避免在错误一侧微调。
用对象池替换热点循环中的实例化与销毁，减少碎片与 GC 抖动。
原型阶段不必过早扭曲设计；先让玩法成立，再按测量数据优化。
具体物理抖动、固定步长预算与休眠刚体属于 physics-tuning；特定引擎的 profiler 界面与渲染配置属于对应引擎技能，本技能聚焦跨引擎方法与通用修复。

详细内容可参考技能包内 references/profiling-and-budgets.md，包含各引擎剖析流程、CPU/GPU 分流图、池管理器与预算检查清单。