性能优化

你在解决什么问题

帧率不达标、画面卡顿、帧时间忽高忽低——这些都是症状，不是病因。更常见的情况是：团队直接开始"优化"，加对象池、合批、删分配，一轮下来帧率没动，代码复杂度倒是上去了。原因很简单：没测量过的目标是错的靶子。

这个技能针对的是性能工作中方法论的缺失，而不是提供一袋通用技巧。它假设你已经能打开引擎自带的 profiler，但不知道该先改什么、改完如何验证。

技能的工作方式

核心方法始终是同一个循环：profile → find the one bottleneck → fix that → measure again。技能把这条循环拆成可执行的关键步骤：

• 定义目标并复现：把"帧率低"转成可量化目标（如桌面 60 FPS = 16.67 ms/frame），并找到能稳定复现的最差场景。"偶尔变慢"无法修复，可复现的尖峰才可以。
• 先剖析再动手：用引擎 profiler 读取整帧预算，判断 CPU 还是 GPU 是瓶颈，而不是凭直觉改代码。
• 使用 release/optimized 构建测量：editor 和 debug 构建的 profiler 数据不可靠（编辑器开销、编译器未优化）。
• 只修最大的单项开销：在代表性场景、代表性硬件上找到最贵的那处，修完再测，确认有效才继续。

技能还覆盖了几种杠杆最高的修复手段：

• 对象池（object pooling）
• draw call / batch 合并
• 消除每帧分配与 GC 尖峰
• 设置资源（asset）预算

同时，技能会指引你找到各引擎自带的 profiler，并与 physics-tuning 技能配合处理仿真开销。

适用边界

• 物理相关的抖动、穿透（tunneling）、timestep 问题应使用 physics-tuning，不在本技能范围。
• 具体引擎的 profiler UI 和渲染设置需要查询对应引擎技能（godot-export 覆盖部分构建设置，引擎核心技能覆盖其余部分）。本技能提供的是跨引擎的通用方法和共享修复手段。
• 黄金法则：先测量，再动手。 没有测量过的代码不值得优化。