性能：先确认瓶颈，再减少工作
“优化一下”很难验收。更好的问题是：“目标低端机同屏 100 个对象时，持续运行是否达到目标帧率，内存是否稳定，点击是否有明显延迟？”
五种成本分别看
| 成本 | 可能的现象 | 排查方向 |
|---|---|---|
| CPU | 游戏逻辑多时帧时间增长 | update、物理、布局、脚本循环 |
| GPU/渲染 | 特效与半透明叠加后变慢 | 覆盖面积、材质切换、批次 |
| 内存 | 长时间运行或进出关卡后增长 | 纹理、音频、未释放引用、池上限 |
| 加载 | 首屏或切关等待过长 | 启动依赖、包分发、远程资源 |
| 分配与回收 | 周期性卡顿 | 每帧临时对象、频繁实例化 |
不要只盯 Draw Call：减少批次未必能解决大量逻辑计算；压缩下载包也不等于纹理解码后内存一定小。
建立一次可复现的测量
例如怀疑每帧更新大量 Label，可先改为数据变化时更新，保持对象数量、设备与测试时长一致，再比较帧时间。不要同时换图集、改物理与减少对象，否则无法知道原因。
优先检查这些浪费
没有变化却每帧刷新 UI；反复查找节点；同一个资源重复加载；滚动列表一次创建全部条目；短特效没有回收；对象池没有容量策略；后台状态仍执行不必要任务。
对象池也会占用内存，不是越大越好。只在证据支持时添加，明确最大缓存、场上数量和退出清理。
验收应包含长时间与反复进入
测试首次进入与缓存命中；连续游玩；反复进出同一关；弹窗开关；网络失败重试；切后台再恢复。目标机型与可接受指标由项目制定，不把本文示意 GIF 的流畅程度当性能证据。
给 AI：“先给测量步骤与瓶颈假设，附修改前后可比较指标。不要无证据重构整个项目，也不要把桌面浏览器性能当微信低端真机结果。”