性能：先找到瓶颈，再选择优化
“把代码优化一下”很难得到可靠结果。先把问题描述成可测量现象：在哪台设备、什么操作后、帧时间怎样变化、内存是否持续增长。
平均 FPS 不是全部。 即使平均值不错，偶尔一次很长的帧也会让拖拽明显卡顿。
四类常见瓶颈
| 观察 | 可能方向 | 先看什么 |
|---|---|---|
| 一次操作产生长帧 | 主线程计算、实例化、布局重建 | CPU 时间线与调用栈 |
| 透明特效多时变慢 | GPU、透明叠加、填充 | 渲染负载与覆盖面积 |
| 定期停顿 | 分配与 GC 或周期性任务 | 分配来源和触发时间 |
| 玩久后闪退 | 内存峰值或持续增长 | 纹理、音频、资源引用与池容量 |
先稳定复现，记录测量条件。Development Build、Deep Profile 和采集模块本身可能有开销；不同条件的数据不能直接混在一起比较。
对象池适合什么
频繁创建和销毁的短寿命物品、特效或提示，可以复用对象。对象池减少部分分配和初始化成本，但会保留对象与资源，增加基础内存。
Unity 已有 UnityEngine.Pool.ObjectPool<T> 等能力，可以先复用。回收不只是 SetActive(false)：还要清理事件、计时器、动画、选择态、数据引用和临时材质。
16 格棋盘不必为了“高级”就引入复杂池。先测量重复创建是否真的造成问题，再选择最简单的复用方式。
经常有效的第一批检查
- 不变的配置和组件查找放到初始化，避免每帧重复处理。
- 分数没变化时，不持续改文本或触发布局。
- 排查热路径上的字符串拼接、临时集合和不必要分配。
- 资源按使用寿命分组，减少同时驻留和加载峰值。
- 控制透明全屏效果、实时光照与高分辨率纹理。
这些是调查方向，不是“不用某个语法就一定快”的禁令。最终以目标设备测量为准。
性能任务怎样给 AI
设备与版本：……。复现步骤：……。观测到合成时主线程尖峰约……，主要样本为……。请先解释证据，再提出最小修改；比较修改前后的同一操作，并检查内存与画面是否退化。
验收需要连续操作、长时间游玩、前后台和热机状态。微信真机与编辑器环境不同，平台可用的分析工具也要结合 SDK 确认。