cocos-creator

Cocos Creator 最佳实践

何时用

• 编写任何 Cocos Creator TypeScript 组件脚本前。
• 发现内存持续上涨、资源释放后再加载仍占用内存时。
• 节点引用丢失、组件生命周期回调顺序不符合预期时。
• EventTarget 事件监听器未被正确注销，导致重复触发或内存泄漏时。
• prefab 频繁 instantiate/destroy 造成帧率抖动时。

核心规则

1. 组件化：@property 暴露，生命周期时序清楚

规则： 逻辑封装在继承自 Component 的脚本里，Inspector 可调属性用 @property 装饰器声明；onLoad 做自身初始化，start 做跨组件依赖初始化，onEnable/onDisable 管理激活态资源，onDestroy 清理一切外部引用。

为什么： AI 生成 Creator 组件时最常见的错误是在 onLoad 里调用另一个组件的方法——但另一个组件的 onLoad 还没执行，得到 undefined 或抛出"Cannot read property of undefined"。新手则把所有逻辑都堆进 start，onEnable/onDisable 完全不用，导致节点被反复激活时调度器和事件重复注册，表现为每激活一次组件，事件就多响应一次。正确的分层：onLoad = 自身组件引用缓存；start = 订阅事件、跨节点通信；onEnable = 恢复运行状态；onDisable = 暂停运行状态；onDestroy = 注销事件、释放资源。

怎么做：

• @property(cc.Node) targetNode: cc.Node = null!; — Inspector 拖拽赋值，不在代码里 find。
• onLoad 里只缓存 this.getComponent、this.node.getChildByName 等本节点树内的引用。
• 跨节点通信（如 GameManager）的引用在 start 里获取，保证对方 onLoad 已完成。
• onDestroy 里注销所有 EventTarget 监听器，停止所有 tween，清空定时器。

---

2. 节点引用：缓存引用，prefab 高频对象用对象池

规则： 节点或组件引用在 onLoad 里缓存成私有字段，绝不在 update 或高频函数里调用 find、getChildByName、getComponent；频繁实例化销毁的对象（子弹、特效、列表项）用 NodePool 管理，不用 instantiate + destroy。

为什么： node.getChildByName("xxx") 是线性遍历子节点树，在 update 里每帧调用、节点树稍大时就能感受到 CPU 消耗。AI 写原型代码时习惯"需要用谁就 find 谁"，在单个脚本里看起来没问题，但一旦场景有几十个同类组件并发运行，性能立刻崩塌。对象池的价值：移动端 instantiate 一个复杂 prefab 耗时可达数十毫秒（涉及资源解析、组件初始化），批量生成敌人或特效时直接造成卡顿帧；NodePool 复用已有节点，激活耗时降一个数量级。新手不用对象池的另一个原因是不知道如何处理"归还时重置状态"——容易留下上次使用的残留数据。

怎么做：

• onLoad 里：this._hpBar = this.node.getChildByName("HPBar").getComponent(cc.ProgressBar);。
• 对象池声明：private _bulletPool: cc.NodePool = new cc.NodePool("BulletController");（参数为组件名，归还时调用该组件的 unuse 钩子重置状态）。
• 借出：const node = this._bulletPool.size() > 0 ? this._bulletPool.get() : cc.instantiate(this.bulletPrefab);。
• 归还：this._bulletPool.put(node);，在 BulletController 的 unuse() 里重置速度、血量、特效状态。
• onDestroy 里：this._bulletPool.clear(); 释放池内所有节点。

---

3. 事件解耦：EventTarget 通信，监听必须 off