2026/9/18 17:40:31
FEATURED · 精选文章 
1. 先给坑分个类Cocos Creator 的问题为什么总集中在几块做 Cocos Creator 项目尤其是从原型一路做到上线 APK 的团队几乎都会经历同一个阶段预览跑得好好的真机一装就出问题。这不是运气差而是引擎本身横跨了资源管理、节点生命周期、渲染合批、原生桥接、平台适配五条链路任何一条链路上的假设不成立表现都是白屏闪退卡顿这种高度同质化的现象。所以我习惯在动手排查之前先把问题按链路归类而不是一上来就翻代码。这篇文章整理的是我在几个中重度 2D 项目里踩过的坑覆盖资源加载与释放、生命周期时序、性能瓶颈定位、打包 APK、跨平台差异和远程资源更新六块。内容偏向能直接抄作业的排查流程和参数配置适合已经上手 Cocos Creator、被线上问题折磨过的开发者也适合刚接手中型项目、想提前避坑的人。文中提到的 API 以 Creator 3.x 为主2.x 的差异我会单独标注因为这些差异恰恰是当年最容易翻车的地方。我个人的分类逻辑很简单按数据从哪来、什么时候被用、什么时候被扔这条主线切成四块资源层资源从 bundle 加载进来引用计数怎么增减什么时候真正释放。逻辑层Node 和 Component 的生命周期顺序事件、定时器、协程的挂载与注销。渲染层DrawCall 为什么降不下来合批为什么突然断了Label 为什么在真机上模糊。原生层构建工具链版本对不上JNI 层报错包名和签名配置错误。1.1 从引擎运行链路倒推故障高发区Cocos Creator 3.x 的运行时大致可以看成一条单向数据流assetManager负责把资源从磁盘或网络搬进内存并生成Asset实例Node树负责组织逻辑结构和层级RenderScene把节点上的渲染组件抽成渲染条目batcher2D再做合批下发到 GPU最后通过native层或者小游戏平台的适配层与宿主环境交互。这个链路里越靠前的环节出错表现越底层也越难定位。举个具体例子。很多人遇到真机黑屏第一反应是渲染问题去查相机、查 Layer、查 Z 顺序。但实际排查下来相当一部分是资源层的锅——比如某个关键预制体在onLoad阶段异步加载还没完成节点已经被加入场景渲染条目生成时引用的贴图还是空的。这种问题在浏览器预览里往往被网络缓存和更宽松的时序掩盖真机上磁盘 IO 慢一点、启动初始化顺序变一点就直接暴露了。我把这些年遇到的高频故障按链路做了个粗略统计当然样本不严谨但趋势是明显的链路典型表现排查难度占比感受资源层白屏、图片错位、内存持续上涨中高约三成逻辑层报错后逻辑中断、重复触发、空引用中约三成渲染层帧率掉、DrawCall 高、文字模糊中约两成原生/平台层构建失败、启动闪退、权限异常高约两成这张表的价值不在数字而在于提醒自己别默认问题出在你最熟的那一层。1.2 排查的三个基本纪律第一条纪律是先定层再定函数。判断层次有个很省事的办法加一个空场景只放最基础的节点看问题还在不在。空场景正常说明引擎和平台层没问题锅在业务资源或逻辑空场景就崩那八成是环境、原生配置或者引擎版本的问题。这一步花五分钟能省掉后面几小时的乱翻。第二条纪律是先复现再修。能稳定复现的 bug 才有资格被修。如果只在特定机型、特定网络、特定操作序列下出现第一件事是把这个序列记录下来做成一份可重复执行的复现步骤而不是靠猜。我见过太多团队直接改代码试试看改完问题没了过两周换个机型又冒出来因为根因从来没被确认。第三条纪律是用二分法隔离而不是靠阅读。资源加载卡住就在加载前后各打一条日志把范围砍一半节点树出问题就把可疑子树临时从场景里摘掉。二分法的成本是加日志和注释代码收益是把我觉得变成我确认。在生命周期和事件回调这类时序问题上二分法的效率远超通读代码。2. 资源与内存大部分闪退和卡顿的真正源头资源管理是 Cocos Creator 里最容易被低估的一块。引擎给了resources.load、bundle.load、assetManager.releaseAsset这些 API看起来很直观但引用计数是个隐形的状态机只要有一处addRef没配对的decRef资源就永远不会被回收。移动端内存本来就紧纹理又是内存大户一个 2048×2048 的 RGBA8888 贴图就是 16MB十几张贴图不释放低端机直接 OOM 闪退。2.1 resources 与 bundle 的引用计数真相先说一个很多人不知道的细节通过resources.load或bundle.load加载资源引擎内部会做一次引用计数 1这个计数在加载完成时由assetManager持有。你调用assetManager.releaseAsset(asset)才会真正尝试释放而且释放的前提是引用计数归零。如果你在代码里手动调用过asset.addRef()那必须自己decRef()否则releaseAsset只是把计数减到 1资源还挂在缓存里。更隐蔽的是依赖资源。加载一个 Prefab它会连带加载它引用的贴图、材质、Spine 骨骼数据。你释放了 Prefab但这些依赖资源不会自动跟着走因为它们的引用计数还挂着。Creator 提供了assetManager.releaseUnusedAssets()它会遍历并释放引用计数为 0 的资源。我的做法是在场景切换的时机显式调用一次配合自己维护的资源清单做校验。import { assetManager, resources, Prefab, Node, instantiate } from cc; // 加载并记录方便后续统一释放 private loadedAssets: Asset[] []; loadPrefab(path: string, cb: (p: Prefab) void) { resources.load(path, Prefab, (err, prefab) { if (err) { console.error([res] load fail, path, err); return; } this.loadedAssets.push(prefab); cb(prefab); }); } // 场景退出时统一清理 releaseAll() { this.loadedAssets.forEach(a assetManager.releaseAsset(a)); this.loadedAssets.length 0; // 兜底清掉引用计数为 0 的依赖资源 assetManager.releaseUnusedAssets(); }这里有个取舍要讲清楚。不做精细释放、只靠releaseUnusedAssets兜底开发期最省事但线上内存会呈现出锯齿状曲线峰值很危险。做精细释放代码量大、容易漏一旦漏掉就是内存泄漏。我的折中方案是核心战斗场景做精细释放并加自动化校验外围 UI 场景靠兜底加定时巡检。这个巡检我一般写成一个定时任务每隔三十秒打一条资源数量和总内存的日志出问题时能直接对比前后的数值变化。注意releaseAsset对正在被渲染的节点上的资源调用可能导致贴图丢失、画面变花。释放前务必确认没有存活的节点还在引用它。2.2 纹理、图集与包体的三角权衡纹理压缩、图集合并、包体大小这三者永远在互相拉扯。我的经验是把资源分成三类分别处理第一类是背景和大图特点是尺寸大、复用率低、对画质有要求。这类资源建议走纹理压缩安卓上常用的 ETC2/ASTC 能在画质损失可接受的前提下把显存占用压到原来的四分之一到六分之一。代价是导入和构建时间变长而且不同 GPU 支持的格式不同需要多套配置。第二类是UI 图标和按钮特点是小而多、复用率高。这类必须走图集一方面减少材质切换带来的 DrawCall另一方面减少纹理绑定次数。Creator 的自动图集Auto Atlas可以按文件夹自动打包配置好maxWidth之后基本不用管。第三类是特效序列帧这是包体杀手。一张 512×512 的序列帧图集30 帧就是 30 张贴图包体分分钟涨几 MB。我的处理方式是降低序列帧分辨率、压缩色彩位数或者干脆用 shader 做程序化动画替代一部分序列帧。这里给一组我在移动端项目里验证过的参数区间供参考资源类型建议单边尺寸上限压缩格式备注全屏背景2048ETC2/ASTC视机型分级降级UI 图集1024RGBA8888 不压缩保证文字和细线清晰角色立绘1024ETC2/ASTC保留单独一张全身图特效序列帧512压缩 降帧优先考虑 shader 替代计算一下就能感受到差别一张 2048×2048 的 RGBA8888 贴图占 16MB转成 ETC2 后大约 4MB一个场景有八张贴图省下来的就是近 100MB 的显存。这在低端安卓机上就是能玩和闪退的分界线。2.3 一套可复用的资源释放检查流程光靠读代码很难确认资源到底释放干净了没有。我一般用这套流程做验收进入目标场景等场景完全加载完记录assetManager.assets.getTotalCount()和当前内存sys或平台提供的内存查询接口安卓可通过原生扩展拿。执行一次完整的场景往返进入战斗、退出战斗、返回主界面重复三轮。每轮结束后记录同样的两个数值观察是否单调上升。如果数值持续上涨把加载清单里引用计数大于 0 的资源 ID 打出来逐个对照代码。三轮之后内存如果回到基线附近说明释放链路是通的如果每轮涨个十几 MB那基本可以确定有资源没被释放。这个流程不需要任何高级工具纯日志就能跑是我用过性价比最高的内存验收方式。3. 生命周期与节点树那些时有时无的诡异 bug生命周期相关的 bug 有个共同特征本地必现、线上偶发而且日志往往只能看到一句某对象的某个属性为空。根因通常有两类一类是执行顺序假设错误另一类是访问了已经销毁的对象。3.1 onLoad、onEnable、start 的执行顺序陷阱Creator 的组件生命周期顺序是onLoad→onEnable→start→update。看起来简单但有两个坑。第一个坑是同一帧内多个节点的初始化顺序不确定。你在一棵子树里依赖另一棵子树的onLoad结果比如 A 节点在onLoad里读 B 节点上组件的数据如果 A 先于 B 初始化读到的是空值。浏览器预览时节点顺序碰巧对打包真机后构建产物的节点遍历顺序可能变化问题就冒出来了。第二个坑是动态添加的节点其组件生命周期触发时机。通过instantiate创建的预制体onLoad会在addChild之后触发但start要等到当前帧结束、下一帧开始才执行。如果你在addChild之后立刻访问该组件在start里初始化的字段一定拿到空值。我采用的写法是关键初始化不放start而是显式提供一个init方法在addChild之后主动调用。这样做的好处是初始化时机完全可控不依赖引擎的调度。const node instantiate(this.enemyPrefab); this.node.addChild(node); // 不依赖 start主动注入依赖 const comp node.getComponent(Enemy); comp.init(this.playerNode, this.damageTable);这个模式多写几十行代码但换来了时序的确定性。在多人协作的项目里这种确定性比省代码重要得多。3.2 节点销毁后的野引用与定时器泄漏node.destroy()只是把节点标记为待销毁真正的清理发生在当前帧末尾。在这期间节点的组件依然存活update甚至可能再跑一帧。更麻烦的是如果别的模块持有这个节点的引用在销毁之后调用它的方法Creator 会抛出对象已被销毁的错误而这个错误会直接中断当前帧后续的逻辑。我的习惯是在所有跨模块持有的节点引用上做双层校验isValid(node) node.isValid。isValid是 Creator 提供的全局方法用来判断对象是否已被销毁。有人觉得这样写很啰嗦但线上因为一句野引用导致整帧逻辑中断的代价远大于多写几个判断。定时器这块有三个层次很多人混着用this.schedule(cb, interval)挂在组件自身的调度器上组件销毁时会自动清理相对安全。setTimeout/setInterval属于宿主环境不会随组件销毁自动清理必须在onDestroy里手动clearTimeout/clearInterval。协程和 Promise 链await之后的代码在对象销毁后依然会执行必须靠isValid判断。我踩过最典型的一次是网络请求回调用 Promise 封装了 HTTP 请求请求返回后在回调里更新 UI但用户已经在等待期间切走了场景节点被销毁回调一执行就报错。修复方式是在回调入口统一加一层校验把已销毁对象的回调直接丢弃。注意setInterval造成的泄漏是渐进式的它不会立刻报错而是让 CPU 占用慢慢爬升加上回调里引用的对象无法被回收最终表现为玩十几分钟后开始卡。3.3 事件监听的登记与注销规范事件这块有一张必须背下来的对照表因为它直接决定注销策略事件来源是否自动注销注销方式this.node.on()节点销毁时自动失效无需手动但建议显式 off自定义EventTarget不会必须手动 off全局输入input.on()不会必须手动 off全局事件director.on()不会必须手动 off动画Animation事件跟随组件组件销毁时清理我见过最贵的一次事故就是在一张常驻界面上注册了全局输入监听每次打开界面加一个关闭时没注销玩了二十分钟后单次点击触发了上百个回调帧率直接塌掉。修复很简单在onDisable里统一注销但排查过程花了整整一天。我的做法是把注册和注销写成配对的方法放在同一个文件、相邻的位置代码审查时一眼就能看出有没有配平。onEnable() { input.on(Input.EventType.TOUCH_START, this.onTouchStart, this); EventBus.on(game-over, this.onGameOver, this); } onDisable() { input.off(Input.EventType.TOUCH_START, this.onTouchStart, this); EventBus.off(game-over, this.onGameOver, this); }这里强调一个细节off的第三个参数必须和on时的target一致否则注销不掉。这是新手最容易犯的错因为引擎不会报错只是静默地留下一个监听。4. 性能优化从帧率掉到 30 说起性能问题的排查有个基本原则先看指标再看代码。不做指标采集就去翻代码优化等于闭着眼睛改配置。4.1 DrawCall 与合批的判定条件2D 渲染的 DrawCall 数量取决于合批是否成功。合批成立需要同时满足几个条件同一个相机、同一个渲染层、相同的材质实例、相同的纹理或同属一张自动图集、顶点数据在渲染序列中连续。任何一条不满足合批就断DrawCall 就涨。最常见的断批原因是节点顺序被打乱。比如你有一个列表每个条目是一个图标加一段文字图标来自图集 A文字来自图集 B。如果节点顺序是 A、B、A、B 交替那就断成四批如果把所有 A 的节点排在前面、所有 B 的排在后面就合成了两批。这个优化不需要改任何资源只调整同级节点的顺序收益立竿见影。第二个常见原因是Label 的缓存模式选错。Creator 的 Label 有三种缓存模式BITMAP预生成位图性能最好适合内容不变的静态文本、CHAR按字符缓存适合频繁变化的文本如分数、倒计时、NONE系统字体性能最差但最省纹理内存。UI 上大量的静态文字如果用了NONE会额外产生大量 DrawCall因为系统字体渲染走的是完全不同的路径无法与图集合批。第三个原因是材质实例被意外复制。如果你在运行时修改了材质属性引擎可能会克隆一份材质实例出来克隆之后材质 ID 变化合批自然断掉。所以对共享材质尽量用MaterialInstance之外的统一参数控制或者接受断批的代价评估是否值得。4.2 逻辑帧与渲染帧解耦很多项目会做逻辑帧和渲染帧的分离让战斗逻辑固定以 30 帧或 20 帧推进渲染帧跟随设备刷新率。这样做的好处是逻辑结果可复现不同设备打出来的伤害计算一致。代价是要处理好两个帧率之间的插值否则角色移动会看起来一跳一跳。实现上的关键点是逻辑帧的累加器。我一般这样写每帧累加真实时间当累加值超过逻辑帧间隔时执行一次逻辑更新并把累加值减去间隔。这样即便某一帧卡顿逻辑依然按既定节奏推进只是会补执行多次。const LOGIC_DT 1 / 30; private acc 0; update(dt: number) { // 限制单帧最大补偿次数避免卡顿后长时间追帧 this.acc Math.min(this.acc dt, LOGIC_DT * 5); while (this.acc LOGIC_DT) { this.acc - LOGIC_DT; this.stepLogic(LOGIC_DT); } this.interpolateRender(this.acc / LOGIC_DT); }那个Math.min的限制非常关键。不加的话从后台切回前台时可能积压了大量时间一次性补执行几百次逻辑直接卡死。这个坑我在真机上真切地遇到过加了限制之后才解决。物理系统也是类似的逻辑。PhysicsSystem有fixedTimeStep和maxSubSteps两个参数默认是 1/60 和 1。如果设备掉帧到 30物理每帧只走一步会显得很慢如果提高maxSubSteps又会带来额外开销。我的选择是在不需要高精度物理的场景直接关掉自动模拟改成手动step完全由自己的逻辑帧驱动。4.3 用 Profiler 定位瓶颈的先后顺序Creator 自带 Profiler 面板可以显示 FPS、DrawCall、内存、节点数、渲染时间等指标。定位性能问题我按照固定的顺序看第一步看FPS 曲线区分是持续低帧还是间歇性掉帧。持续低帧说明渲染或逻辑负载本身就重间歇掉帧说明有周期性任务比如定时生成对象、定时 GC。第二步看DrawCall超过 60 就要开始警惕超过 100 基本可以确定有合批问题。第三步看渲染时间如果渲染时间不高但 FPS 依然低说明瓶颈在逻辑层或者 JS 执行。第四步看内存曲线如果是锯齿状持续上升就是内存泄漏如果是台阶状上升然后突然下降是正常的 GC 行为。这套顺序看起来简单但能避免很多人一上来就去看节点数的误区。节点数多不等于性能差一万个不渲染的纯逻辑节点开销远小于一百个频繁切换材质的渲染节点。5. 打包 APK 全流程踩坑记录从编辑器里点一下构建到真机上跑起来中间隔着一整条原生工具链每一步都可能崩。我把这条链路上的问题拆成准备、构建、瘦身三个阶段。5.1 环境与工具链准备在 Creator 的偏好设置里需要配置三项外部程序路径Android SDK、JDK、NDK。这三者的版本必须和当前 Creator 版本匹配版本不对通常会报一些非常含糊的编译错误比如找不到某个头文件或者 gradle 直接语法错误。我的一般做法是不要用系统全局安装的 JDK 和 NDK而是下载官方推荐的版本放在独立的目录里单独指向。这样做的原因是引擎不同大版本对工具链的要求会变全局环境升级一次就可能把旧项目搞崩。独立的工具链目录虽然多占几十 GB 磁盘但换来的是项目之间互不干扰。构建 Android 包的流程大致是这样在 Creator 构建面板选择 Android 平台填写包名applicationId比如全部小写的域名倒写形式。指定 keystore 文件和别名、密码。调试包可以留空由工具链自动生成临时签名但正式包必须用自己的 keystore。选择目标架构arm64-v8a是目前的主流armeabi-v7a用于兼容老设备两者都选会让包体翻倍。设置目标 API 等级需要满足各应用商店的最低要求。点击构建生成的原生工程在build/android/proj目录下。用 Android Studio 打开该工程继续打包或者在工程根目录执行 gradle 的 assemble 任务。我个人的偏好是尽量用命令行构建把构建命令写成脚本。这样做的好处是构建过程可复现、可交给自动化而且命令行报错信息比 GUI 完整得多排查问题时省事。5.2 构建报错速查下面这张表是我这些年攒下来的高频报错对照按报错关键字整理可以直接拿去搜或对照排查报错关键字常见根因处理方向sdk location not foundSDK 路径未配置或含中文空格换成纯英文无空格路径unsupported class file versionJDK 版本与 gradle 要求不匹配按引擎推荐版本安装独立 JDKninja: build stoppedNDK 版本不匹配或编译缓存损坏换推荐 NDK清理构建缓存duplicate resources资源目录里存在重名文件统一资源命名规范INSTALL_FAILED_NO_MATCHING_ABIS设备架构不在构建产物中补齐对应 ABI启动即闪退无日志原生层静态初始化异常或签名问题用 logcat 抓完整堆栈这张表里最值得说的是最后一条。启动即闪退是最难受的情况因为看不出任何信息。这时候必须用adb logcat抓日志并且过滤出自己应用的进程重点看三类信息一是FATAL EXCEPTION的完整堆栈二是UnsatisfiedLinkError这类原生库加载失败三是系统层面的权限拒绝记录。很多闪退根本不是引擎的问题而是原生扩展里的静态代码块抛了异常或者缺少必需的权限声明。注意构建缓存是把双刃剑。改配置后如果报错让
Cocos Creator 真机闪退卡顿排查：资源、生命周期与打包 APK
1. 先给坑分个类Cocos Creator 的问题为什么总集中在几块做 Cocos Creator 项目尤其是从原型一路做到上线 APK 的团队几乎都会经历同一个阶段预览跑得好好的真机一装就出问题。这不是运气差而是引擎本身横跨了资源管理、节点生命周期、渲染合批、原生桥接、平台适配五条链路任何一条链路上的假设不成立表现都是白屏闪退卡顿这种高度同质化的现象。所以我习惯在动手排查之前先把问题按链路归类而不是一上来就翻代码。这篇文章整理的是我在几个中重度 2D 项目里踩过的坑覆盖资源加载与释放、生命周期时序、性能瓶颈定位、打包 APK、跨平台差异和远程资源更新六块。内容偏向能直接抄作业的排查流程和参数配置适合已经上手 Cocos Creator、被线上问题折磨过的开发者也适合刚接手中型项目、想提前避坑的人。文中提到的 API 以 Creator 3.x 为主2.x 的差异我会单独标注因为这些差异恰恰是当年最容易翻车的地方。我个人的分类逻辑很简单按数据从哪来、什么时候被用、什么时候被扔这条主线切成四块资源层资源从 bundle 加载进来引用计数怎么增减什么时候真正释放。逻辑层Node 和 Component 的生命周期顺序事件、定时器、协程的挂载与注销。渲染层DrawCall 为什么降不下来合批为什么突然断了Label 为什么在真机上模糊。原生层构建工具链版本对不上JNI 层报错包名和签名配置错误。1.1 从引擎运行链路倒推故障高发区Cocos Creator 3.x 的运行时大致可以看成一条单向数据流assetManager负责把资源从磁盘或网络搬进内存并生成Asset实例Node树负责组织逻辑结构和层级RenderScene把节点上的渲染组件抽成渲染条目batcher2D再做合批下发到 GPU最后通过native层或者小游戏平台的适配层与宿主环境交互。这个链路里越靠前的环节出错表现越底层也越难定位。举个具体例子。很多人遇到真机黑屏第一反应是渲染问题去查相机、查 Layer、查 Z 顺序。但实际排查下来相当一部分是资源层的锅——比如某个关键预制体在onLoad阶段异步加载还没完成节点已经被加入场景渲染条目生成时引用的贴图还是空的。这种问题在浏览器预览里往往被网络缓存和更宽松的时序掩盖真机上磁盘 IO 慢一点、启动初始化顺序变一点就直接暴露了。我把这些年遇到的高频故障按链路做了个粗略统计当然样本不严谨但趋势是明显的链路典型表现排查难度占比感受资源层白屏、图片错位、内存持续上涨中高约三成逻辑层报错后逻辑中断、重复触发、空引用中约三成渲染层帧率掉、DrawCall 高、文字模糊中约两成原生/平台层构建失败、启动闪退、权限异常高约两成这张表的价值不在数字而在于提醒自己别默认问题出在你最熟的那一层。1.2 排查的三个基本纪律第一条纪律是先定层再定函数。判断层次有个很省事的办法加一个空场景只放最基础的节点看问题还在不在。空场景正常说明引擎和平台层没问题锅在业务资源或逻辑空场景就崩那八成是环境、原生配置或者引擎版本的问题。这一步花五分钟能省掉后面几小时的乱翻。第二条纪律是先复现再修。能稳定复现的 bug 才有资格被修。如果只在特定机型、特定网络、特定操作序列下出现第一件事是把这个序列记录下来做成一份可重复执行的复现步骤而不是靠猜。我见过太多团队直接改代码试试看改完问题没了过两周换个机型又冒出来因为根因从来没被确认。第三条纪律是用二分法隔离而不是靠阅读。资源加载卡住就在加载前后各打一条日志把范围砍一半节点树出问题就把可疑子树临时从场景里摘掉。二分法的成本是加日志和注释代码收益是把我觉得变成我确认。在生命周期和事件回调这类时序问题上二分法的效率远超通读代码。2. 资源与内存大部分闪退和卡顿的真正源头资源管理是 Cocos Creator 里最容易被低估的一块。引擎给了resources.load、bundle.load、assetManager.releaseAsset这些 API看起来很直观但引用计数是个隐形的状态机只要有一处addRef没配对的decRef资源就永远不会被回收。移动端内存本来就紧纹理又是内存大户一个 2048×2048 的 RGBA8888 贴图就是 16MB十几张贴图不释放低端机直接 OOM 闪退。2.1 resources 与 bundle 的引用计数真相先说一个很多人不知道的细节通过resources.load或bundle.load加载资源引擎内部会做一次引用计数 1这个计数在加载完成时由assetManager持有。你调用assetManager.releaseAsset(asset)才会真正尝试释放而且释放的前提是引用计数归零。如果你在代码里手动调用过asset.addRef()那必须自己decRef()否则releaseAsset只是把计数减到 1资源还挂在缓存里。更隐蔽的是依赖资源。加载一个 Prefab它会连带加载它引用的贴图、材质、Spine 骨骼数据。你释放了 Prefab但这些依赖资源不会自动跟着走因为它们的引用计数还挂着。Creator 提供了assetManager.releaseUnusedAssets()它会遍历并释放引用计数为 0 的资源。我的做法是在场景切换的时机显式调用一次配合自己维护的资源清单做校验。import { assetManager, resources, Prefab, Node, instantiate } from cc; // 加载并记录方便后续统一释放 private loadedAssets: Asset[] []; loadPrefab(path: string, cb: (p: Prefab) void) { resources.load(path, Prefab, (err, prefab) { if (err) { console.error([res] load fail, path, err); return; } this.loadedAssets.push(prefab); cb(prefab); }); } // 场景退出时统一清理 releaseAll() { this.loadedAssets.forEach(a assetManager.releaseAsset(a)); this.loadedAssets.length 0; // 兜底清掉引用计数为 0 的依赖资源 assetManager.releaseUnusedAssets(); }这里有个取舍要讲清楚。不做精细释放、只靠releaseUnusedAssets兜底开发期最省事但线上内存会呈现出锯齿状曲线峰值很危险。做精细释放代码量大、容易漏一旦漏掉就是内存泄漏。我的折中方案是核心战斗场景做精细释放并加自动化校验外围 UI 场景靠兜底加定时巡检。这个巡检我一般写成一个定时任务每隔三十秒打一条资源数量和总内存的日志出问题时能直接对比前后的数值变化。注意releaseAsset对正在被渲染的节点上的资源调用可能导致贴图丢失、画面变花。释放前务必确认没有存活的节点还在引用它。2.2 纹理、图集与包体的三角权衡纹理压缩、图集合并、包体大小这三者永远在互相拉扯。我的经验是把资源分成三类分别处理第一类是背景和大图特点是尺寸大、复用率低、对画质有要求。这类资源建议走纹理压缩安卓上常用的 ETC2/ASTC 能在画质损失可接受的前提下把显存占用压到原来的四分之一到六分之一。代价是导入和构建时间变长而且不同 GPU 支持的格式不同需要多套配置。第二类是UI 图标和按钮特点是小而多、复用率高。这类必须走图集一方面减少材质切换带来的 DrawCall另一方面减少纹理绑定次数。Creator 的自动图集Auto Atlas可以按文件夹自动打包配置好maxWidth之后基本不用管。第三类是特效序列帧这是包体杀手。一张 512×512 的序列帧图集30 帧就是 30 张贴图包体分分钟涨几 MB。我的处理方式是降低序列帧分辨率、压缩色彩位数或者干脆用 shader 做程序化动画替代一部分序列帧。这里给一组我在移动端项目里验证过的参数区间供参考资源类型建议单边尺寸上限压缩格式备注全屏背景2048ETC2/ASTC视机型分级降级UI 图集1024RGBA8888 不压缩保证文字和细线清晰角色立绘1024ETC2/ASTC保留单独一张全身图特效序列帧512压缩 降帧优先考虑 shader 替代计算一下就能感受到差别一张 2048×2048 的 RGBA8888 贴图占 16MB转成 ETC2 后大约 4MB一个场景有八张贴图省下来的就是近 100MB 的显存。这在低端安卓机上就是能玩和闪退的分界线。2.3 一套可复用的资源释放检查流程光靠读代码很难确认资源到底释放干净了没有。我一般用这套流程做验收进入目标场景等场景完全加载完记录assetManager.assets.getTotalCount()和当前内存sys或平台提供的内存查询接口安卓可通过原生扩展拿。执行一次完整的场景往返进入战斗、退出战斗、返回主界面重复三轮。每轮结束后记录同样的两个数值观察是否单调上升。如果数值持续上涨把加载清单里引用计数大于 0 的资源 ID 打出来逐个对照代码。三轮之后内存如果回到基线附近说明释放链路是通的如果每轮涨个十几 MB那基本可以确定有资源没被释放。这个流程不需要任何高级工具纯日志就能跑是我用过性价比最高的内存验收方式。3. 生命周期与节点树那些时有时无的诡异 bug生命周期相关的 bug 有个共同特征本地必现、线上偶发而且日志往往只能看到一句某对象的某个属性为空。根因通常有两类一类是执行顺序假设错误另一类是访问了已经销毁的对象。3.1 onLoad、onEnable、start 的执行顺序陷阱Creator 的组件生命周期顺序是onLoad→onEnable→start→update。看起来简单但有两个坑。第一个坑是同一帧内多个节点的初始化顺序不确定。你在一棵子树里依赖另一棵子树的onLoad结果比如 A 节点在onLoad里读 B 节点上组件的数据如果 A 先于 B 初始化读到的是空值。浏览器预览时节点顺序碰巧对打包真机后构建产物的节点遍历顺序可能变化问题就冒出来了。第二个坑是动态添加的节点其组件生命周期触发时机。通过instantiate创建的预制体onLoad会在addChild之后触发但start要等到当前帧结束、下一帧开始才执行。如果你在addChild之后立刻访问该组件在start里初始化的字段一定拿到空值。我采用的写法是关键初始化不放start而是显式提供一个init方法在addChild之后主动调用。这样做的好处是初始化时机完全可控不依赖引擎的调度。const node instantiate(this.enemyPrefab); this.node.addChild(node); // 不依赖 start主动注入依赖 const comp node.getComponent(Enemy); comp.init(this.playerNode, this.damageTable);这个模式多写几十行代码但换来了时序的确定性。在多人协作的项目里这种确定性比省代码重要得多。3.2 节点销毁后的野引用与定时器泄漏node.destroy()只是把节点标记为待销毁真正的清理发生在当前帧末尾。在这期间节点的组件依然存活update甚至可能再跑一帧。更麻烦的是如果别的模块持有这个节点的引用在销毁之后调用它的方法Creator 会抛出对象已被销毁的错误而这个错误会直接中断当前帧后续的逻辑。我的习惯是在所有跨模块持有的节点引用上做双层校验isValid(node) node.isValid。isValid是 Creator 提供的全局方法用来判断对象是否已被销毁。有人觉得这样写很啰嗦但线上因为一句野引用导致整帧逻辑中断的代价远大于多写几个判断。定时器这块有三个层次很多人混着用this.schedule(cb, interval)挂在组件自身的调度器上组件销毁时会自动清理相对安全。setTimeout/setInterval属于宿主环境不会随组件销毁自动清理必须在onDestroy里手动clearTimeout/clearInterval。协程和 Promise 链await之后的代码在对象销毁后依然会执行必须靠isValid判断。我踩过最典型的一次是网络请求回调用 Promise 封装了 HTTP 请求请求返回后在回调里更新 UI但用户已经在等待期间切走了场景节点被销毁回调一执行就报错。修复方式是在回调入口统一加一层校验把已销毁对象的回调直接丢弃。注意setInterval造成的泄漏是渐进式的它不会立刻报错而是让 CPU 占用慢慢爬升加上回调里引用的对象无法被回收最终表现为玩十几分钟后开始卡。3.3 事件监听的登记与注销规范事件这块有一张必须背下来的对照表因为它直接决定注销策略事件来源是否自动注销注销方式this.node.on()节点销毁时自动失效无需手动但建议显式 off自定义EventTarget不会必须手动 off全局输入input.on()不会必须手动 off全局事件director.on()不会必须手动 off动画Animation事件跟随组件组件销毁时清理我见过最贵的一次事故就是在一张常驻界面上注册了全局输入监听每次打开界面加一个关闭时没注销玩了二十分钟后单次点击触发了上百个回调帧率直接塌掉。修复很简单在onDisable里统一注销但排查过程花了整整一天。我的做法是把注册和注销写成配对的方法放在同一个文件、相邻的位置代码审查时一眼就能看出有没有配平。onEnable() { input.on(Input.EventType.TOUCH_START, this.onTouchStart, this); EventBus.on(game-over, this.onGameOver, this); } onDisable() { input.off(Input.EventType.TOUCH_START, this.onTouchStart, this); EventBus.off(game-over, this.onGameOver, this); }这里强调一个细节off的第三个参数必须和on时的target一致否则注销不掉。这是新手最容易犯的错因为引擎不会报错只是静默地留下一个监听。4. 性能优化从帧率掉到 30 说起性能问题的排查有个基本原则先看指标再看代码。不做指标采集就去翻代码优化等于闭着眼睛改配置。4.1 DrawCall 与合批的判定条件2D 渲染的 DrawCall 数量取决于合批是否成功。合批成立需要同时满足几个条件同一个相机、同一个渲染层、相同的材质实例、相同的纹理或同属一张自动图集、顶点数据在渲染序列中连续。任何一条不满足合批就断DrawCall 就涨。最常见的断批原因是节点顺序被打乱。比如你有一个列表每个条目是一个图标加一段文字图标来自图集 A文字来自图集 B。如果节点顺序是 A、B、A、B 交替那就断成四批如果把所有 A 的节点排在前面、所有 B 的排在后面就合成了两批。这个优化不需要改任何资源只调整同级节点的顺序收益立竿见影。第二个常见原因是Label 的缓存模式选错。Creator 的 Label 有三种缓存模式BITMAP预生成位图性能最好适合内容不变的静态文本、CHAR按字符缓存适合频繁变化的文本如分数、倒计时、NONE系统字体性能最差但最省纹理内存。UI 上大量的静态文字如果用了NONE会额外产生大量 DrawCall因为系统字体渲染走的是完全不同的路径无法与图集合批。第三个原因是材质实例被意外复制。如果你在运行时修改了材质属性引擎可能会克隆一份材质实例出来克隆之后材质 ID 变化合批自然断掉。所以对共享材质尽量用MaterialInstance之外的统一参数控制或者接受断批的代价评估是否值得。4.2 逻辑帧与渲染帧解耦很多项目会做逻辑帧和渲染帧的分离让战斗逻辑固定以 30 帧或 20 帧推进渲染帧跟随设备刷新率。这样做的好处是逻辑结果可复现不同设备打出来的伤害计算一致。代价是要处理好两个帧率之间的插值否则角色移动会看起来一跳一跳。实现上的关键点是逻辑帧的累加器。我一般这样写每帧累加真实时间当累加值超过逻辑帧间隔时执行一次逻辑更新并把累加值减去间隔。这样即便某一帧卡顿逻辑依然按既定节奏推进只是会补执行多次。const LOGIC_DT 1 / 30; private acc 0; update(dt: number) { // 限制单帧最大补偿次数避免卡顿后长时间追帧 this.acc Math.min(this.acc dt, LOGIC_DT * 5); while (this.acc LOGIC_DT) { this.acc - LOGIC_DT; this.stepLogic(LOGIC_DT); } this.interpolateRender(this.acc / LOGIC_DT); }那个Math.min的限制非常关键。不加的话从后台切回前台时可能积压了大量时间一次性补执行几百次逻辑直接卡死。这个坑我在真机上真切地遇到过加了限制之后才解决。物理系统也是类似的逻辑。PhysicsSystem有fixedTimeStep和maxSubSteps两个参数默认是 1/60 和 1。如果设备掉帧到 30物理每帧只走一步会显得很慢如果提高maxSubSteps又会带来额外开销。我的选择是在不需要高精度物理的场景直接关掉自动模拟改成手动step完全由自己的逻辑帧驱动。4.3 用 Profiler 定位瓶颈的先后顺序Creator 自带 Profiler 面板可以显示 FPS、DrawCall、内存、节点数、渲染时间等指标。定位性能问题我按照固定的顺序看第一步看FPS 曲线区分是持续低帧还是间歇性掉帧。持续低帧说明渲染或逻辑负载本身就重间歇掉帧说明有周期性任务比如定时生成对象、定时 GC。第二步看DrawCall超过 60 就要开始警惕超过 100 基本可以确定有合批问题。第三步看渲染时间如果渲染时间不高但 FPS 依然低说明瓶颈在逻辑层或者 JS 执行。第四步看内存曲线如果是锯齿状持续上升就是内存泄漏如果是台阶状上升然后突然下降是正常的 GC 行为。这套顺序看起来简单但能避免很多人一上来就去看节点数的误区。节点数多不等于性能差一万个不渲染的纯逻辑节点开销远小于一百个频繁切换材质的渲染节点。5. 打包 APK 全流程踩坑记录从编辑器里点一下构建到真机上跑起来中间隔着一整条原生工具链每一步都可能崩。我把这条链路上的问题拆成准备、构建、瘦身三个阶段。5.1 环境与工具链准备在 Creator 的偏好设置里需要配置三项外部程序路径Android SDK、JDK、NDK。这三者的版本必须和当前 Creator 版本匹配版本不对通常会报一些非常含糊的编译错误比如找不到某个头文件或者 gradle 直接语法错误。我的一般做法是不要用系统全局安装的 JDK 和 NDK而是下载官方推荐的版本放在独立的目录里单独指向。这样做的原因是引擎不同大版本对工具链的要求会变全局环境升级一次就可能把旧项目搞崩。独立的工具链目录虽然多占几十 GB 磁盘但换来的是项目之间互不干扰。构建 Android 包的流程大致是这样在 Creator 构建面板选择 Android 平台填写包名applicationId比如全部小写的域名倒写形式。指定 keystore 文件和别名、密码。调试包可以留空由工具链自动生成临时签名但正式包必须用自己的 keystore。选择目标架构arm64-v8a是目前的主流armeabi-v7a用于兼容老设备两者都选会让包体翻倍。设置目标 API 等级需要满足各应用商店的最低要求。点击构建生成的原生工程在build/android/proj目录下。用 Android Studio 打开该工程继续打包或者在工程根目录执行 gradle 的 assemble 任务。我个人的偏好是尽量用命令行构建把构建命令写成脚本。这样做的好处是构建过程可复现、可交给自动化而且命令行报错信息比 GUI 完整得多排查问题时省事。5.2 构建报错速查下面这张表是我这些年攒下来的高频报错对照按报错关键字整理可以直接拿去搜或对照排查报错关键字常见根因处理方向sdk location not foundSDK 路径未配置或含中文空格换成纯英文无空格路径unsupported class file versionJDK 版本与 gradle 要求不匹配按引擎推荐版本安装独立 JDKninja: build stoppedNDK 版本不匹配或编译缓存损坏换推荐 NDK清理构建缓存duplicate resources资源目录里存在重名文件统一资源命名规范INSTALL_FAILED_NO_MATCHING_ABIS设备架构不在构建产物中补齐对应 ABI启动即闪退无日志原生层静态初始化异常或签名问题用 logcat 抓完整堆栈这张表里最值得说的是最后一条。启动即闪退是最难受的情况因为看不出任何信息。这时候必须用adb logcat抓日志并且过滤出自己应用的进程重点看三类信息一是FATAL EXCEPTION的完整堆栈二是UnsatisfiedLinkError这类原生库加载失败三是系统层面的权限拒绝记录。很多闪退根本不是引擎的问题而是原生扩展里的静态代码块抛了异常或者缺少必需的权限声明。注意构建缓存是把双刃剑。改配置后如果报错让 
