1. 项目概述为什么我们要深入CCObject.js如果你在Cocos Creator项目里写过几行代码那么CCObject这个名字你一定不陌生。无论是场景里的一个节点cc.Node还是你挂在节点上的一个自定义脚本组件它们最终都继承自这个看似不起眼的基类。很多开发者尤其是刚上手的新手可能会觉得这只是一个“底层的东西”知道有这么回事就行没必要深究。但在我实际开发中遇到的很多“诡异”问题比如内存泄漏、组件生命周期回调不触发、属性序列化异常追根溯源往往都和CCObject的内部机制有关。简单来说CCObject是Cocos Creator引擎运行时对象系统的基石。它定义了所有可被引擎管理的游戏对象的基本行为准则如何被创建和销毁生命周期管理、如何保存和加载序列化、如何被编辑器识别和操作元信息。不理解CCObject你就很难理解为什么你的组件onLoad之后start才执行为什么destroy()了节点但内存没释放干净或者为什么在编辑器里调整的属性在运行时又变回了默认值。这次源码分析我们不搞“走马观花”而是带着实际开发中的问题深入到CCObject.js文件里看看这个基石到底是怎么搭建的。我会结合我踩过的坑和调试经验把那些文档里没写的、但至关重要的实现细节和设计逻辑挖出来。无论你是想优化性能、解决疑难杂症还是单纯想对引擎有更深的掌控力这次“掘地三尺”都会让你有所收获。2. 核心架构与设计思想拆解2.1 CCObject的定位不止是一个基类打开Cocos Creator的引擎源码目录找到CCObject.js你可能会惊讶于它的代码量并不算特别庞大。但它的设计非常精炼和核心。它的定位远不止是提供一个class让其他类来extends那么简单。我们可以从三个维度来理解它的核心职责第一生命周期沙箱的管理者。在Cocos Creator里对象的生老病死不是完全由JavaScript的垃圾回收GC机制决定的。引擎需要介入这个过程以确保在对象销毁时能正确地清理它与其他引擎模块如渲染、物理、事件系统的关联。CCObject通过内部的_destroying、_destroyed等状态标志以及destroy方法建立了一套标准的销毁流程。这保证了即便你直接对某个对象置为null引擎也能通过自己的引用计数或管理机制在合适的时机触发完整的清理。第二序列化与反序列化的协议制定者。这是CCObject非常关键的一个功能。编辑器里你配置的每一个属性最终都需要被保存到.scene或.prefab文件中并在运行时被正确地还原出来。CCObject通过_serialize、_deserialize等内部方法以及配套的cc.Class的properties定义定义了一套属性如何被“扁平化”成JSON又如何从JSON“重建”的规则。理解这套规则你才能明白如何自定义一个复杂数据结构的序列化或者为什么某些动态赋值的属性不会被保存。第三元信息系统的承载者。为了让编辑器能够识别和友好地编辑各种对象CCObject与cc.Class系统紧密耦合承载着类的属性类型、默认值、范围、提示文本等元信息。这些信息在编辑时用于绘制属性检查器在运行时用于类型检查和反序列化时的类型转换。2.2 与cc.Class的共生关系这里有一个非常重要的概念需要厘清CCObject和cc.Class不是同一个东西但它们协同工作构成了Creator对象系统的“一体两面”。cc.Class是一个类定义系统。它用于声明一个类定义它的构造函数、方法、属性包括属性的元信息。你可以把它看作一个功能更强大的、为编辑器定制的“语法糖”或元编程工具。cc.Class创建出来的类其原型链的根部通常是CCObject。CCObject是一个基类实现。它提供了上述生命周期、序列化等具体的方法实现。一个由cc.Class定义的类如果指定了extends: cc.Component或其他继承自CCObject的类那么它的实例就拥有了CCObject提供的所有能力。用代码来比喻cc.Class({ extends: cc.Component, ... })这个过程生成了一个继承自cc.Component而cc.Component继承自CCObject的新类。这个新类的实例首先是一个CCObject然后才是一个cc.Component最后才是你的自定义组件。CCObject的属性和方法是所有这些实例的“底层公分母”。3. 核心源码逐行解析与关键方法实现让我们深入到具体的代码中。我以某个版本的Cocos Creator源码为例进行分析核心逻辑在不同版本间是稳定的。请注意以下分析会省略一些边缘条件和非常具体的校验代码聚焦于主流程和核心逻辑。3.1 构造函数与初始化_ctor和_onCreate当你调用new一个继承自CCObject的对象时实际上会触发一系列精细的初始化步骤。// 简化示意代码非源码逐字抄录 function CCObject () { // 内部标识初始化 this._objFlags 0; // 用于编辑器唯一标识的UUID this._id generateUUID(); // 引用计数用于资源管理等场景 this._refCount 0; // 对象名称常用于调试 this._name ; // 序列化相关数据 this._$erialized null; // 生命周期状态正在销毁、已销毁 this._destroying false; this._destroyed false; // 调用原型链上的 _ctor 方法如果存在 // 注意这个_ctor是由cc.Class系统在构建类时注入的它包装了用户定义的ctor或onLoad if (this._ctor) { this._ctor(); } }关键点解析UUID (_id): 每个CCObject实例都有一个全局唯一的标识符。这是编辑器进行资源引用比如一个材质球引用一张纹理的关键。即使对象在内存中的地址变了只要_id不变引用关系就能保持。_ctor与onLoad: 这里容易混淆。用户通过cc.Class定义的ctor构造函数或被cc.Class包装后的onLoad生命周期方法最终都会被引擎整合到_ctor这个内部方法中。在组件的初始化流里_ctor的调用意味着组件实例已被创建并挂载到节点上但节点的整个激活流程可能还未完成。这解释了为什么在ctor或onLoad里访问兄弟节点或父节点有时可能不安全。_objFlags: 这是一个位掩码bitmask用于高效地存储多个布尔状态。例如可能用不同的位来表示“对象是否持久化”、“是否来自预制体”、“是否正在被序列化”等。使用位运算进行状态判断和设置性能远高于使用多个独立的布尔属性。3.2 销毁流程destroy()背后的故事对象的销毁是内存管理的重中之重。一个不完整的销毁是内存泄漏的温床。CCObject的destroy方法设计得非常谨慎。// 简化示意 CCObject.prototype.destroy function () { // 1. 防止重复销毁 if (this._destroying || this._destroyed) { return; } this._destroying true; // 2. 触发预销毁回调如果存在 if (this._preDestroy) { this._preDestroy(); } // 3. 执行具体的销毁逻辑 this._doDestroy(); // 4. 清理引擎内部对该对象的引用 // 例如从渲染队列、物理世界、事件监听器中移除 this._unregisterIfAttached(); // 5. 标记为已销毁并清理主要属性以切断引用 this._destroyed true; this._destroying false; this._$erialized null; // ... 清理其他内部引用 // 6. 最终如果可能建议将对象引用置为null // 但实际清理由调用者负责这里只是改变了对象内部状态 };关键点与避坑指南_destroying状态锁这个标志位确保了销毁逻辑的幂等性。即使多次调用destroy()也不会导致重复清理或错误。在你自己的代码中如果涉及复杂的清理逻辑借鉴这个模式是非常好的实践。_preDestroy钩子这是一个内部钩子允许子类如cc.Component在引擎执行核心清理之前先执行自己的清理工作。例如组件可能会在这里移除所有它注册的事件监听器。注意这不是公开给用户的onDestroy。用户的onDestroy生命周期回调通常是在_doDestroy或类似阶段被触发的。引用切断_doDestroy和后续的清理工作核心目标是将该对象从引擎的所有管理系统中“摘除”。这比等待JavaScript的GC要主动和及时得多。一个常见的错误是在自定义组件中通过闭包或者将方法作为回调传递给其他系统如setInterval,Promise.then导致组件实例被意外引用即使调用了destroy引擎也无法将其完全释放。务必在onDestroy中手动清理这些外部引用。_destroyed标志的用途在引擎的其他地方可以通过检查obj._destroyed来快速判断一个对象是否可用避免在已销毁的对象上执行操作导致错误。3.3 序列化的魔法_serialize与_deserialize序列化是编辑器与运行时协作的桥梁。理解这个过程能帮你解决很多属性“存不住”或“读不对”的问题。// 序列化将对象状态转换为可存储的纯数据 CCObject.prototype._serialize function (serializingContext) { // 1. 获取由cc.Class properties定义声明的、需要序列化的属性列表 const props this.__props__; // 这是一个由cc.Class生成的元信息数组 const result {}; for (const prop of props) { const key prop.key; const value this[key]; // 2. 根据属性定义的type进行序列化转换 // 例如cc.Vec2类型需要被转换为 {x: 0, y: 0} 这样的普通对象 const serializedValue serializeValue(value, prop.type, serializingContext); if (serializedValue ! undefined) { result[key] serializedValue; } } // 3. 可能还会包含一些引擎内部的元信息如__type__类标识 result.__type__ this.__classname__; return result; }; // 反序列化从纯数据恢复对象状态 CCObject.prototype._deserialize function (data, initializingContext) { const props this.__props__; for (const prop of props) { const key prop.key; if (data.hasOwnProperty(key)) { // 1. 根据属性定义的type将存储的数据转换回运行时类型 const deserializedValue deserializeValue(data[key], prop.type, initializingContext); // 2. 将值赋给实例 this[key] deserializedValue; } } // 3. 处理完成后可能会触发一些后置回调 this._postDeserialize this._postDeserialize(); };关键点与实操心得只有properties里定义的属性才会被序列化这是最核心的规则。如果你在ctor或任何方法里动态给this添加了一个属性如this.myDynamicData {}它默认是不会被保存到预制体或场景中的。你必须将其声明在properties中。类型转换 (serializeValue/deserializeValue)这是序列化的精髓。对于基本类型number, string, boolean直接存储。对于引擎类型cc.Vec2,cc.Color,cc.Node则需要特殊处理cc.Vec2被转换成{x: 0, y: 0}。cc.Node等引用类型存储的是目标节点的UUID_id。在反序列化时引擎会根据这个UUID去当前场景或资源池中查找对应的对象实例重新建立引用关系。如果找不到比如引用的节点被删了这个属性就会是null。__type__的作用当反序列化一个嵌套对象比如一个属性是自定义类时引擎需要知道用哪个构造函数来创建这个对象。__type__字段存储了类的唯一标识符通常是cc.Class时指定的name引擎用它来查找并实例化正确的类。自定义序列化对于特别复杂的数据结构你可以重写_serialize和_deserialize方法实现完全自定义的序列化逻辑。但绝大多数情况下依靠properties系统和内置的类型转换已经足够。4. 从源码看实际开发中的疑难杂症与解决方案理解了原理我们就能诊断和解决一些实际开发中令人头疼的问题。4.1 问题一为什么我的组件onLoad里获取不到父节点/子节点源码视角组件的_ctor包含了你的onLoad被调用时该组件实例已经被创建并关联到了一个节点this.node已可用。但是整个节点的父子关系树可能尚未完全构建或激活。特别是当你在一个节点的onLoad里试图通过this.node.parent或this.node.children访问尚未完成初始化的其他节点时可能得到null或不完整的列表。解决方案将依赖节点关系的初始化代码移到start生命周期中。start会在所有组件的onLoad都执行完毕且节点树完全激活后才被调用此时节点关系是稳定的。使用延迟一帧的方法。在onLoad中使用this.scheduleOnce(() { ... }, 0)或将操作包裹在setTimeout(fn, 0)中可以确保当前帧的所有初始化逻辑都执行完毕。利用节点的事件。监听节点自身的cc.Node.EventType.PARENT_CHANGED或cc.Node.EventType.CHILD_ADDED事件在关系变化时再进行操作。4.2 问题二调用了destroy()但内存没有释放如何排查源码视角destroy()方法只完成了引擎内部的清理。如果内存没有释放根本原因一定是该对象仍然被某些JavaScript可达的引用链保持着导致GC无法回收。排查清单全局变量或缓存检查是否将对象或其一属性尤其是数组、对象赋值给了某个全局变量、模块级的缓存对象、静态属性等。闭包引用事件监听是最常见的坑。你是否在组件中使用了this.node.on(‘click’, this.callback, this)但没有在onDestroy中对应地使用this.node.off(‘click’, this.callback, this)即使第三个参数是this在某些旧版本或复杂情况下闭包也可能导致引用残留。定时器或异步回调setInterval、setTimeout、Promise、axios回调等。如果这些回调函数内部引用了组件实例this并且没有在组件销毁前清除定时器或取消异步操作那么组件就无法被释放。其他对象的属性是否被其他存活的对象作为属性持有例如一个全局的游戏管理器持有了一个已经destroy的角色的引用。引擎内部模块这种情况较少但如果你通过非标准API与引擎底层交互也可能造成残留。使用Chrome DevTools的Memory面板拍摄堆快照Heap Snapshot对比destroy前后的快照查看该对象类型的实例数量并分析其引用保留路径Retainers是定位这类问题最有效的方法。4.3 问题三自定义类的复杂属性如对象数组如何正确序列化假设你有一个属性itemList: { default: [], type: MyItemClass }其中MyItemClass也是由cc.Class定义的。你可能会发现在编辑器里配置好的数组运行时读出来却是空的或不对。源码视角对于声明为type: MyItemClass的属性序列化系统期望MyItemClass本身也继承自CCObject并且其属性也被正确定义。对于数组它会遍历数组中的每个元素对每个元素执行序列化。正确做法确保MyItemClass继承自cc.Object或其它CCObject子类。cc.Class({ extends: cc.Object, ... })。在MyItemClass中也用properties定义其需要保存的属性。为itemList提供正确的默认值。default: []会创建一个空数组但数组里每个元素需要在代码中或编辑器里创建。如果你希望默认就有一些数据可以使用default: () [new MyItemClass(), new MyItemClass()]工厂函数。注意直接写default: [new MyItemClass()]是错误的这会导致所有实例共享同一个数组引用。在编辑器中编辑将组件挂到节点上后在属性检查器中你可以点击itemList数组旁边的“”号添加新元素。每个添加的元素其属性都可以像普通组件一样在检查器中展开和编辑前提是MyItemClass的定义正确。5. 高级技巧与性能优化启示5.1 利用_objFlags进行高效状态判断在你自己编写需要高频调用的工具类或管理器时可以借鉴_objFlags的设计。例如你有一个游戏实体对象它可能有多种状态VISIBLE,ENABLED,SELECTED,PERSISTENT等。// 定义标志位 const MyEntityFlags { VISIBLE: 1 0, // 1 ENABLED: 1 1, // 2 SELECTED: 1 2, // 4 PERSISTENT: 1 3, // 8 }; class MyEntity { constructor() { this._flags 0; } // 设置标志 setFlag(flag, value) { if (value) { this._flags | flag; // 添加标志 } else { this._flags ~flag; // 清除标志 } } // 检查标志 hasFlag(flag) { return (this._flags flag) ! 0; } // 切换标志 toggleFlag(flag) { this._flags ^ flag; } } // 使用 let entity new MyEntity(); entity.setFlag(MyEntityFlags.VISIBLE, true); entity.setFlag(MyEntityFlags.ENABLED, true); if (entity.hasFlag(MyEntityFlags.VISIBLE)) { // 实体可见 }这种方式比使用多个布尔属性this.isVisible,this.isEnabled在内存占用和判断速度上都有优势尤其是在对象数量非常多的时候。5.2 谨慎使用__props__等内部属性进行高级操作在调试或开发一些高级工具时你可能会访问到CCObject实例的__props__、__classname__等内部属性。这些属性是引擎cc.Class系统注入的用于存储元信息。注意这些属性通常以下划线开头表明它们是引擎内部使用的其结构和行为可能在未来的引擎版本中发生变化且不保证向后兼容。在生产代码中应尽量避免直接依赖和操作这些内部属性。如果确实需要动态获取或操作属性元信息请优先查阅引擎是否提供了公开的API如cc.js.getClassName等。5.3 理解实例化与克隆的差异CCObject及其子类通常支持clone方法。clone()会创建一个当前对象的新实例并复制其当前的状态通常是可序列化的属性。这与new操作符不同new MyComponent()创建一个全新的实例所有属性使用properties中定义的default默认值。myComp.clone()创建一个新的实例但其属性值复制自myComp的当前值。在实现对象池Object Pool时clone非常有用。你可以预制一个“模板”对象然后通过clone来快速创建状态一致的新对象而不是每次都new并重新配置。