1. 不要把“性能优化”理解成若干零散技巧
很多团队的优化方式是：
- 卡了就查 DrawCall
- 崩了就减图片
- 包大了就拆分包
- 音频爆了就改格式
这些都没错，但本质上还是“点状修补”。
真正线上稳定的项目，通常会把性能问题拆成 4 条主线：
- 包体预算
- 内存预算
- 渲染预算
- 切场景/切玩法时的资源生命周期
如果没有预算，优化就无法形成共识；如果没有生命周期设计，资源就会“加得上去、下不来”。
2. 微信小游戏上的首要矛盾，通常不是 CPU，而是“内存 + 资源释放失控”
Cocos 官方文档里很明确：微信小游戏常见内存包含图片、字体、音频、Canvas、业务脚本等多个部分，而基础库本身就是高占用常驻项，所以项目可优化空间主要集中在贴图、字体、音频和业务资源管理上。
这意味着一个非常重要的工程判断：
不要只盯帧率，要先盯峰值内存和切场景后的回落情况。
在 SLG 或中度项目中，最常见的不是“单帧慢”，而是：
- 地图进一次没事，来回切三次出问题
- 打开几个系统页签后，内存不回落
- 战斗结束返回主城，旧资源还挂着引用
- UI 看起来关闭了，但动态图集、Prefab、音频句柄还没释放
这类问题单靠“某个优化技巧”很难解决，必须引入资源分层。
3. 资源分层，才是项目中后期最值钱的架构动作
实战里建议把资源至少分成 4 层：
A. 常驻层
适合长期存在、重复复用、加载成本高的资源：
- 通用 UI 图集
- 核心字体
- 登录后主流程必须用到的基础 Prefab
- 常驻音效
原则：少而精，不要把“以后可能会用”也塞进常驻。
B. 场景层
跟主城、世界地图、战斗场景强绑定的资源。
进入场景加载，退出场景统一释放。
C. 系统层
背包、邮件、活动、排行、联盟等功能页资源。
按需加载，关闭后延迟回收或基于 LRU 回收。
D. 瞬时层
引导、弹窗、特效、短生命周期动画、一次性剧情资源。
用完即卸，不参与常驻。
这个分层的价值在于：团队可以围绕“资源属于哪一层”来协作，而不是每个人各写各的load/release。
4. 比“会加载”更重要的是“知道谁在持有资源”
很多 Cocos 项目资源卸不掉，不是没调用释放，而是对象引用链没断。常见坑包括：
- 单例缓存了节点或 SpriteFrame
- 全局事件没解绑，组件实例还活着
- 定时器/Promise 回调持有组件闭包
- 动态创建的节点被对象池或父节点挂住
- AssetManager 释放了 Asset，但业务层还在引用
建议在项目里建立一个轻量资源句柄模型，不要让业务代码直接到处resources.load。
用统一入口记录：
- 谁发起加载
- 归属哪个场景/系统
- 引用计数是多少
- 何时允许释放
下面给一个精简 TS 示例：
type ResOwner = string; interface ResRecord<T> { asset: T; refs: Set<ResOwner>; } class ResKeeper<T> { private map = new Map<string, ResRecord<T>>(); add(key: string, asset: T, owner: ResOwner) { const rec = this.map.get(key); if (rec) { rec.refs.add(owner); return; } this.map.set(key, { asset, refs: new Set([owner]) }); } release(key: string, owner: ResOwner): boolean { const rec = this.map.get(key); if (!rec) return false; rec.refs.delete(owner); if (rec.refs.size === 0) { // 这里再接 Cocos 的真正释放逻辑 this.map.delete(key); return true; } return false; } dump() { return [...this.map.entries()].map(([key, rec]) => ({ key, refCount: rec.refs.size, owners: [...rec.refs], })); } }这类代码不复杂，但在项目里能极大减少“为什么释放不掉”的黑盒感。
5. 渲染优化不要只盯 DrawCall，要看“无效复杂度”
很多团队一提优化就先查 DrawCall，这当然重要，但微信小游戏里还有几类常被忽略的无效开销：
- 过多透明叠层 UI
- 频繁节点激活/反激活造成的批量脏标记
- 文本过多、频繁刷新
- Mask、特效、粒子在低端机上成本过高
- 列表没有虚拟化，长列表一次性创建完
Cocos 社区文章也反复提到一些版本能力提升，比如 3.8.4 中的性能增强与 WASM 能力，对特定模块如 Box2D 有很大帮助。但这类引擎升级只能放大“正确架构”的收益，不能替代业务层治理。
对于 SLG 项目，最值得优先排查的渲染点通常是：
1）大地图 UI 与世界元素是否混在同一刷新节奏
地图对象、飘字、头像、行军线、建筑状态、任务提示，如果都在同一帧更新，卡顿会非常明显。
2）列表是否做了虚拟化
邮件、战报、排行、联盟成员、背包等，都是典型高频长列表。
3）文本刷新是否过度
倒计时、战力变化、资源跳字，如果每帧更新文本，会很伤。
4）特效是否分级
高配显示完整特效，低配降级粒子数、贴图尺寸、播放数量。
6. 微信小游戏平台上，iOS 与 Android 的优化策略不能完全一样
官方文档明确聚焦过 iOS 微信小游戏的内存优化，强调需要结合内存构成去做释放与排查。
这在实战上意味着：
- iOS 更怕峰值内存
- Android 更常见长时间运行后抖动和碎片问题
- 同一份资源策略，在两端未必收益一致
工程上建议把设备策略分档：
- 低端机：低清贴图、弱特效、短缓存、激进回收
- 中端机：平衡策略
- 高端机：保体验，适度保留缓存
不要一套策略跑全机型。
7. 版本升级带来的收益，要转化成“项目规则”
Cocos 3.8.4 提到小游戏平台相关性能提升，包括 WASM/Box2D 性能收益明显；3.8.6 继续优化包体。
但团队更应该问的是：
- 我们当前项目哪些模块受益？
- 升级后是否需要同步调整构建参数？
- 是否要更新性能基线数据？
- 是否要修改老模块的加载/缓存策略？
升级引擎不是终点，落地规则才是终点。
8.实战建议
建议 1：先建立一张“性能预算表”
每个项目都应该有一页共享文档，至少包含：
- 启动阶段可接受时长
- 主城常驻内存目标
- 大地图峰值内存目标
- 战斗场景峰值内存目标
- 单界面最大节点数
- 长列表是否必须虚拟化
- 低端机允许的特效等级
- 切场景后内存回落目标
没有这张表，优化永远在争论。
建议 2：给资源打“归属标签”
所有动态资源在加载时都标记：
- 所属场景
- 所属系统
- 是否常驻
- 是否允许缓存
- 最晚释放时机
这样排查内存问题时，不会只看到“资源很多”，而是能知道哪类资源失控
建议 3：把“切场景回收”做成自动流程
不要依赖开发同学手动写一堆释放代码。
建议在场景切换管线中统一做：
- 停事件
- 停定时器
- 清对象池
- 断节点引用
- 释放场景层资源
- 采样切换前后内存日志
这样才能真正形成闭环。
建议 4：列表、文本、特效，优先做平台分级
这是最容易出收益的一组：
- 长列表全部虚拟化
- 倒计时合帧刷新，不要每个组件自己跑
- 特效分档播放
- 大量文本减少频繁 set string
- 大地图飘字/提示做限流
这些优化不花哨，但线上最稳。
建议 5：升级到 3.8.x 后，关注引擎能力是否真正被启用
公开资料显示，Cocos 3.8.4 在性能和 WASM 相关能力上有明显增强，尤其提到微信小游戏平台上的 Box2D 性能收益；3.8.6 继续改进微信小游戏包体优化。
如果项目正好有物理、包体、性能瓶颈，值得结合当前版本重新评估构建配置和模块启用方式。
可参考资料
- Cocos 官方文档：iOS 微信小游戏内存与性能优化指南
Cocos Creator 3.8 手册 - iOS 微信小游戏内存与性能优化指南
- Cocos 官方论坛：Cocos Creator 3.8.4 来了，更快更稳更好用
Cocos Creator 3.8.4 来了，更快更稳更好用！ - Creator 3.x - Cocos中文社区
- Cocos 官方论坛：Cocos Creator 3.8.6 社区版公测贴
[已发布] Cocos Creator 3.8.6 社区版公测贴【3.14】 - Creator 3.x - Cocos中文社区
- CSDN：用 Cocos Creator 开发微信小游戏：从环境配置到包体优化实战
用Cocos Creator开发微信小游戏：从环境配置到包体优化实战-CSDN博客
