帧耗时、内存与加载性能

级别：首作必学诊断，专项优化按需。 优化先有目标设备、可复现场景和测量结果，再选择改动。

先给问题分类

现象	优先观察
点击后偶尔停顿	长任务、垃圾回收、资源解码与实例化
持续帧率偏低	CPU 更新、UI 重建、渲染提交与 GPU 压力
多玩几局后退出	内存峰值、泄漏、资源未释放
首次进入很慢	下载、解压、加载、场景激活各阶段
只有部分手机异常	纹理格式、引擎后端、系统与微信版本

建立一个测量基线

固定版本与设备，在冷启动、连续重开、切后台恢复和进入新关卡时记录。把加载拆为可观察阶段，记录总时长与失败率。只比较同样条件下的改动前后结果。

FPS 是汇总指标；帧耗时的高分位和最大长帧更接近卡顿体验。小样本记录保留原始值，不要伪造稳定百分位。开发工具和调试开关自身也可能影响性能，最终应补充接近发布配置的验证。

常见低成本改进

• 不在每帧重建所有文字、列表和节点，状态变化后再更新。
• 在加载阶段创建大量对象，或分批处理，避免玩家操作时集中实例化。
• 对贴图使用合适尺寸与平台支持格式；检查图集、遮罩和材质切换。
• 结束场景时解除监听、停止任务、释放自己拥有的对象引用。
• 先修复持续增长，再讨论对象池；池本身也会保留内存。

这些是诊断方向，不能保证某项改动在每个项目都提速。渲染合批减少的开销，需要通过实际帧分析确认。

内存峰值与长期增长

区分 JavaScript 堆、原生或引擎资源、纹理等不同部分。切关时新旧资源短暂共存可能形成峰值，即使最终释放正常也会出问题。

连续玩若干局后观察是否回到相近基线；如果持续上升，查看场景节点、事件监听、闭包、缓存和资源引用。一次 GC 后堆变小不能证明所有纹理已经释放。

给首作写性能验收

选择你实际能测试的目标设备，记录可接受的启动时间、交互卡顿和连续运行情况。门槛由玩法和设备决定，别照搬历史文章里的通用内存上限。

练习：给一次关卡加载分段计时，找出最长阶段，再只做一个对应修改。完成标准：有同条件对照数据，并说明改善范围与尚未覆盖的设备。

参考：Cocos 微信 iOS 内存与性能指南。其中历史机型与数值用于理解诊断背景，不作为所有当前设备的固定阈值。