態(tài)加載與避坑指南)
簡(jiǎn)介這是一份圍繞Cocos Creator打造“大廳多個(gè)子游戲”整合模式的實(shí)戰(zhàn)筆記demo適合需要搭建多玩法入口、獨(dú)立熱更子游戲或模塊化游戲項(xiàng)目的開發(fā)者參考。壓縮包共64個(gè)文件以js腳本為主輔以json配置、meta資源描述、fire場(chǎng)景文件、png/jpg圖片素材、ttf字體及bat工具腳本整體僅7.09MB便于快速下載與對(duì)照學(xué)習(xí)。已有943人學(xué)習(xí)下載。資源演示了大廳作為子游戲入口的設(shè)計(jì)思路覆蓋場(chǎng)景切換、事件監(jiān)聽、資源動(dòng)態(tài)加載、獨(dú)立子游戲熱更新、性能優(yōu)化與打包發(fā)布等關(guān)鍵環(huán)節(jié)目錄按大廳、子游戲及工具模塊劃分配合Readme閱讀可更清晰理解整包集成與獨(dú)立更新兩種模式的區(qū)別。適合希望從零搭建或重構(gòu)多游戲整合框架的Cocos Creator開發(fā)者作為梳理流程、調(diào)試排錯(cuò)和發(fā)布部署的參照。1. CocosCreator大廳子游戲整合先解決怎么把多個(gè)項(xiàng)目裝進(jìn)一個(gè)App做休閑游戲或互動(dòng)內(nèi)容集的人大概率會(huì)在某一天收到這樣的需求手里已經(jīng)有三五個(gè)獨(dú)立跑好的小玩法突然要合成一個(gè)“大廳 子游戲”的 App或者你想做一個(gè)類似內(nèi)置小游戲集的產(chǎn)品主界面是兩排卡片點(diǎn)進(jìn)去玩一局退出還能回到大廳。CocosCreator 里最省事的做法是把所有場(chǎng)景和資源塞進(jìn)同一個(gè)主包但子游戲一多主場(chǎng)景越來越重首屏冷啟動(dòng)越來越慢任何一個(gè)子游戲的小改動(dòng)都要全量發(fā)版成本很快失控。這篇筆記不是一個(gè)泛泛的教程而是順著一個(gè) CocosCreator 大廳子游戲 demo 的項(xiàng)目整合路徑走一遍怎么按 Bundle 拆分大廳和多個(gè)子項(xiàng)目、運(yùn)行時(shí)動(dòng)態(tài)加載、退出卸載、事件通信以及不跑一遍根本想不到的坑。適合準(zhǔn)備把現(xiàn)有單場(chǎng)景工程改造成多子游戲架構(gòu)的開發(fā)者看。2. 架構(gòu)選型為什么“大廳 子項(xiàng)目”不是把多個(gè)項(xiàng)目硬塞進(jìn)一個(gè)包2.1 Asset Bundle 是整合的基石先搞清它是誰Asset Bundle 是 CocosCreator 做資源按需加載的單元。每個(gè) Bundle 在被構(gòu)建后會(huì)生成獨(dú)立的資源清單和配置運(yùn)行時(shí)通過assetManager.loadBundle加載。做大廳 子游戲的項(xiàng)目整合本質(zhì)就是把子游戲相關(guān)的場(chǎng)景、預(yù)制體、貼圖、聲音、腳本代碼全部收進(jìn)各自獨(dú)立的 Bundle 中大廳只保留最精簡(jiǎn)的主包資源。這樣首包體積不會(huì)跟著子游戲數(shù)量漲進(jìn)入子游戲時(shí)才拉取對(duì)應(yīng)包體退出后還能釋放內(nèi)存。在工程里配置 Bundle 其實(shí)很簡(jiǎn)單對(duì)一個(gè)文件夾右鍵選擇“配置為 Bundle”然后在屬性檢查器里給它起名。名字很關(guān)鍵代碼里loadBundle(subgame1)用的就是這個(gè)名字。CocosCreator 在構(gòu)建時(shí)會(huì)把這個(gè)文件夾里的資源按依賴關(guān)系抽離到獨(dú)立的 Bundle 目錄同時(shí)生成一份 Json 記錄資源 uuid、路徑和依賴表。這里有個(gè)容易忽略的點(diǎn)Bundle 不光是美術(shù)資源腳本代碼也會(huì)跟著走。正因?yàn)?Bundle 連代碼都能帶你才能做到“子游戲的邏輯只在你進(jìn)入子游戲時(shí)才加載”。CocosCreator 的 Bundle 和純 C 或其他傳統(tǒng)前端里的模塊加載不太一樣它有自己的一套依賴追蹤和釋放策略。你在編輯器里看到的了一個(gè)文件夾構(gòu)建后可能被拆成多個(gè)依賴層級(jí)這也是為什么要強(qiáng)調(diào)“邊界”這件事。提示Bundle 不是熱更新專屬機(jī)制。不配遠(yuǎn)程服務(wù)器它也能作為本地按需加載的模塊使用。demo 階段可以完全跑在本地后面接熱更只需把 Bundle 的版本和遠(yuǎn)程地址配好即可。2.2 子游戲的邊界哪些該進(jìn)自己的 Bundle哪些必須共享一個(gè)干凈的子游戲 Bundle 邊界應(yīng)該是自包含的子游戲?qū)俚膱?chǎng)景、腳本、UI、交互循環(huán)都放在自己的 Bundle 里公共資源比如大廳風(fēng)格、通用按鈕、工具函數(shù)庫(kù)放在一個(gè)公共 Bundle 或主包。如果子游戲 A 的資源被子游戲 B 引用要么把這兩段資源收進(jìn)公共包要么接受重復(fù)打包別在運(yùn)行時(shí)嘗試去另一個(gè) Bundle 里找資源那樣會(huì)引入加載順序依賴非常容易踩到“資源找不到”的問題。對(duì)于“大廳 子游戲”這種常見玩法我習(xí)慣這樣劃邊界大廳本身一個(gè)常駐場(chǎng)景直屬大廳的 UI、通用組件放到一個(gè) Common Bundle或者直接保留在主包里。每個(gè)子游戲一個(gè)獨(dú)立 Bundle入口是一個(gè)全屏 Prefab 或者一個(gè)獨(dú)立子場(chǎng)景。前者更方便因?yàn)榇髲d節(jié)點(diǎn)不用被切換掉后者適合子游戲內(nèi)部自帶多個(gè)場(chǎng)景的玩法。子游戲依賴的公共數(shù)據(jù)、SDK 對(duì)接層、網(wǎng)絡(luò)請(qǐng)求等抽到commonBundle 并讓多個(gè)子游戲依賴。不要在每個(gè)子游戲里分別復(fù)制一份否則包體和代碼量會(huì)翻倍。還有一條經(jīng)驗(yàn)是越早約定“Bundle 不能跨引用”越好。編輯器里拖拽資源非常順手大廳預(yù)制體上隨手引了一個(gè)子游戲的貼圖構(gòu)建時(shí)這張貼圖就會(huì)被算進(jìn)主包依賴主包就被撐大了。這種錯(cuò)誤構(gòu)建時(shí)不報(bào)錯(cuò)只在后面看包體占比時(shí)才嚇你一跳。后面避坑章會(huì)專門再講。2.3 對(duì)比整包方案為項(xiàng)目整合付出架構(gòu)成本值不值整包和 Bundle 方式最直觀的區(qū)別可以用下面這個(gè)表來看對(duì)比維度整包集成大廳 子游戲 Bundle首包體積會(huì)隨子游戲數(shù)量線性增大首包只包含大廳公共部分首次加載冷屏要等全部資源只等大廳子游戲進(jìn)入時(shí)再加載發(fā)版效率改個(gè)子游戲也要全量發(fā)版子游戲 Bundle 可以獨(dú)立更新內(nèi)存壓力所有子場(chǎng)景資源常駐退出子游戲時(shí)手動(dòng)釋放工程復(fù)雜度低需要處理加載順序和生命周期結(jié)論很直接如果只是兩三個(gè)休閑玩法的教學(xué) demo整包來得省心但只要有“多個(gè)子項(xiàng)目后續(xù)還會(huì)繼續(xù)加”的情況建議首次就把 Bundle 架構(gòu)立起來。項(xiàng)目整合越晚做拆分成本越高。我見過很多團(tuán)隊(duì)一開始用整包頂著后來游戲多了想改大廳子游戲架構(gòu)結(jié)果要?jiǎng)铀袌?chǎng)景引用關(guān)系幾乎沒有后悔藥。等架構(gòu)定了我們?cè)賮砜?demo 怎么落地。實(shí)際跑代碼之前先把幾種加載模式區(qū)分開大廳直接通過loadBundle按需拉包是最常規(guī)的做法如果子游戲之間有切換比如從子游戲 A 直接進(jìn)入子游戲 B大廳要先把 A 的資源釋放再加載 B。這個(gè)順序控制好了整個(gè)項(xiàng)目整合就算成了八成。3. 搭一個(gè)最小 demo在大廳里動(dòng)態(tài)加載子游戲3.1 demo 工程結(jié)構(gòu)三塊東西不要混在我寫代碼前先把工程分層擺出來。假設(shè)一個(gè)最簡(jiǎn)單的演示有大廳和兩個(gè)子游戲assets/ hall/ // 大廳主場(chǎng)景和 UI scenes/ Hall.scene scripts/ HallManager.ts subgames/ sub1/ // 子游戲1這個(gè) Bundle prefab/ SubGame1.prefab scripts/ SubGame1Root.ts res/ ... sub2/ // 子游戲2這個(gè) Bundle prefab/ SubGame2.prefab scripts/ SubGame2Root.ts common/ scripts/ EventBus.ts GameDef.ts操作上在assets/subgames/sub1文件夾右鍵選擇“配置為 Bundle”Bundle 名稱填subgame1。sub2同理。兩個(gè)文件夾里的資源在構(gòu)建時(shí)會(huì)各自獨(dú)立打包。hall文件夾不設(shè)成 Bundle所有資源直接進(jìn)主包方便冷啟動(dòng)。這里有一個(gè)參數(shù)值得強(qiáng)調(diào)Bundle 配置面板里的“目標(biāo)平臺(tái)”可以單獨(dú)控制比如你只想讓subgame1打進(jìn)微信小游戲包而subgame2只用于原生平臺(tái)構(gòu)建配置里可以分開勾選。demo 階段不用管這個(gè)但要知道有這個(gè)能力因?yàn)榇髲d 多子項(xiàng)目的項(xiàng)目整合經(jīng)常需要應(yīng)對(duì)多端發(fā)布。每個(gè)子游戲最好都只有一個(gè)入口 Prefab這樣大廳加載時(shí)只需面對(duì)一個(gè)統(tǒng)一路徑。如果子游戲內(nèi)部還有多個(gè)場(chǎng)景切換由子游戲自己管理大廳不感知。大廳負(fù)責(zé)的是“把子游戲的入口節(jié)點(diǎn)掛到自己的場(chǎng)景下”“退出時(shí)把它從場(chǎng)景移除”。把耦合限制在這兩個(gè)動(dòng)作上后期新增子游戲就只需要加一個(gè) Bundle 配置和一個(gè)入口按鈕映射。3.2 用 Bundle 動(dòng)態(tài)加載子游戲最小代碼先實(shí)現(xiàn)最直接的流程點(diǎn)擊大廳列表里的按鈕加載subgame1這個(gè) Bundle然后從 Bundle 里取出SubGame1.prefab掛到大廳場(chǎng)景下。import { _decorator, Component, Node, Prefab, assetManager, instantiate } from cc; export default class HallManager extends Component { currentNode: Node | null null; enterSubGame(bundleName: string, prefabPath: string) { assetManager.loadBundle(bundleName, (err, bundle) { if (err) { console.error([Hall] loadBundle ${bundleName} failed:, err); return; } const prefab bundle.get(prefabPath, Prefab); if (!prefab) { console.error([Hall] prefab ${prefabPath} not found in bundle); return; } this.currentNode instantiate(prefab); this.currentNode.setParent(this.node.parent ?? this.node); }); } exitSubGame() { this.currentNode?.destroy(); this.currentNode null; } }邏輯很簡(jiǎn)單assetManager.loadBundle是入口回調(diào)成功表示 Bundle 已經(jīng)加載bundle.get直接從已加載的 Bundle 里拿資源。注意instantiate(prefab)出來后掛到大廳 Node 的父節(jié)點(diǎn)下這樣預(yù)制體內(nèi)部的start會(huì)被觸發(fā)。按鈕的click事件綁定時(shí)傳入兩個(gè)字符串參數(shù)比如(subgame1, prefab/SubGame1)。參數(shù)說明loadBundle的bundleName必須和構(gòu)建 Bundle 時(shí)的名字一致默認(rèn)是文件夾名prefabPath是相對(duì) Bundle 的路徑不包含assets/前綴。bundle.get只適合 Bundle 已經(jīng)確認(rèn)加載完的情況如果加載過程還沒結(jié)束get拿不到資源所以更穩(wěn)妥的是用bundle.load。示例里沒有做加載失敗重試實(shí)際項(xiàng)目會(huì)封一層管理器下面繼續(xù)。3.3 用統(tǒng)一的 SubGameManager 管理“進(jìn)入/退出”狀態(tài)只寫上面的方法雖然能跑但大廳里同時(shí)多點(diǎn)幾個(gè)入口或者重復(fù)進(jìn)入同一個(gè)子游戲會(huì)出現(xiàn)多個(gè)節(jié)點(diǎn)疊在一起、事件互相干擾的情況。我習(xí)慣把入口邏輯收攏成一個(gè)管理類維護(hù)“當(dāng)前是否有子游戲在運(yùn)行”的狀態(tài)import { _decorator, Component, Prefab, Node, assetManager, instantiate } from cc; type LoadDone (node: Node) void; export default class SubGameManager extends Component { public currNode: Node | null null; public currentBundleName: string ; enterGame(bundleName: string, prefabPath: string, onDone?: LoadDone) { if (this.currNode) { console.warn([SubGameManager] 已經(jīng)有子游戲在運(yùn)行先退出再進(jìn)入); return; } assetManager.loadBundle(bundleName, (bundleErr, bundle) { if (bundleErr) { console.error(加載 ${bundleName} 失敗, bundleErr); return; } bundle.load(prefabPath, Prefab, (loadErr, prefab) { if (loadErr) { console.error(加載 ${prefabPath} 失敗, loadErr); return; } const node instantiate(prefab); node.setParent(this.node); this.currNode node; this.currentBundleName bundleName; onDone onDone(node); }); }); } exitGame() { if (!this.currNode) return; this.currNode.destroy(); this.currNode null; this.currentBundleName ; } }相比最小示例這里用currNode記錄當(dāng)前子游戲防止重復(fù)進(jìn)入用bundle.load而不是bundle.get規(guī)避了“資源未加載完”的窗期。這個(gè)管理器掛在 Canvas 下的一個(gè)常駐空節(jié)點(diǎn)上子游戲 Prefab 都作為這個(gè)空節(jié)點(diǎn)的子節(jié)點(diǎn)這樣即使大廳 UI 切換層級(jí)子游戲?qū)雍痛髲d層也能保持邏輯隔離。在enterGame里還有個(gè)細(xì)節(jié)成功回調(diào)里做node.setParent(this.node)this.node就是管理器節(jié)點(diǎn)的引用。因?yàn)閠his是管理器的組件實(shí)例this.node才是場(chǎng)景樹上的節(jié)點(diǎn)。如果你把管理器掛在大廳根節(jié)點(diǎn)上那子游戲就是大廳根節(jié)點(diǎn)的直接子節(jié)點(diǎn)退出時(shí)要不要恢復(fù)層級(jí)要看你的設(shè)計(jì)。這里我選擇獨(dú)立掛載規(guī)避一層耦合。4. 項(xiàng)目整合中的通信與生命周期不處理好進(jìn)入退出兩三次就會(huì)出鬼4.1 用事件總線打通大廳與子游戲大廳和子游戲各自獨(dú)立不能直接拿著對(duì)方的組件引用來調(diào)用方法否則會(huì)形成強(qiáng)耦合。常見做法是掛一個(gè)全局事件總線。子游戲要向大廳匯報(bào)分?jǐn)?shù)發(fā)出事件大廳監(jiān)聽事件并更新 UI。一個(gè)極簡(jiǎn)事件總線可以這樣寫import { EventTarget } from cc; const bus new EventTarget(); export function onEvent(name: string, callback: (payload?: any) void) { bus.on(name, callback); return () { bus.off(name, callback); }; } export function emitEvent(name: string, payload?: any) { bus.emit(name, payload); }EventTarget是 CocosCreator 自帶的簡(jiǎn)單事件目標(biāo)不需要引第三方庫(kù)也沒有平臺(tái)差異。用onEvent返回的 off 函數(shù)可以在子游戲銷毀時(shí)解綁防止回調(diào)泄漏。如果你是第一次寫這種跨模塊通信建議把事件名定義成枚舉放進(jìn)common/scripts/GameDef.ts比如export enum GameEvent { SUBMIT_SCORE SUBMIT_SCORE, GAME_EXIT GAME_EXIT, }這樣做的好處是子游戲內(nèi)發(fā)事件時(shí)如果拼錯(cuò)字符串TypeScript 編譯階段就會(huì)報(bào)錯(cuò)而不是運(yùn)行時(shí)靜默丟掉。另一個(gè)隱藏收益是編輯器全局搜索方便重構(gòu)事件名時(shí)可以快速定位所有引用處。事件總線的邊界要克制。如果大廳和子游戲之間交互特別密集比如子游戲內(nèi)有個(gè)進(jìn)度條要實(shí)時(shí)同步到大廳那就不要把每個(gè)進(jìn)度都發(fā)到全局總線否則總線會(huì)變成黑匣子。更好的做法是子游戲進(jìn)入時(shí)大廳把可以用于同步的UIProxy傳給子游戲根節(jié)點(diǎn)子游戲內(nèi)部通過這個(gè)代理更新 UI而不是發(fā)事件。職責(zé)劃分上總線適合一次性的“結(jié)果通知”代理適合持續(xù)性的“狀態(tài)同步”。4.2 子游戲退出時(shí)只銷毀節(jié)點(diǎn)是不夠的子游戲節(jié)點(diǎn)被destroy()后它下面所有組件的onDestroy會(huì)執(zhí)行但不會(huì)自動(dòng)替你恢復(fù)大廳 UI 的狀態(tài)。比如子游戲全屏 UI 把主廳 UI 蓋住了退出時(shí)大廳停留在進(jìn)入前的狀態(tài)這沒問題。問題在別處子游戲里的定時(shí)器、Tween、網(wǎng)絡(luò)輪詢、全局事件監(jiān)聽稍微不干凈就會(huì)殘留在大廳進(jìn)程里。一個(gè)健壯的子游戲入口組件通常會(huì)顯式做清理import { _decorator, Component, Node, Tween } from cc; import { offEvent } from ../common/EventBus; import { GameEvent } from ../common/GameDef; export default class SubGame1Root extends Component { private offFuncs: Array() void []; onLoad() { this.offFuncs.push(offEvent(GameEvent.SUBMIT_SCORE, this.onSubmitScore)); this.scheduleOnce(() { // 子游戲自己的開機(jī)初始化 }, 0.1); } onDestroy() { this.offFuncs.forEach(f f()); this.offFuncs.length 0; Tween.stopAllByTarget(this.node); } private onSubmitScore(score: number) { // 往大廳上報(bào)分?jǐn)?shù) } }關(guān)鍵點(diǎn)在于將所有需要解綁的監(jiān)聽器統(tǒng)一收進(jìn)數(shù)組在onDestroy里一起解除。如果用EventTarget的on就必須持有off引用別在onDestroy里去寫bus.off(SUBMIT_SCORE, 一個(gè)匿名函數(shù))那會(huì)失效因?yàn)槊看温暶髂涿瘮?shù)都是新的引用。Tween.stopAllByTarget(this.node)能停掉針對(duì)該子游戲根節(jié)點(diǎn)的所有緩動(dòng)防止動(dòng)畫殘留在舞臺(tái)上。setInterval這類全局定時(shí)器也必須記得清掉。你可以把setInterval返回的句柄存在組件的私有屬性里在onDestroy里調(diào)用clearInterval。有些開發(fā)者覺得子游戲節(jié)點(diǎn)銷毀了定時(shí)器就會(huì)自動(dòng)消失但實(shí)際不是這樣——定時(shí)器是全局的和節(jié)點(diǎn)生命周期沒有綁定。跑一次進(jìn)入退出循環(huán)如果你在 Console 里看到節(jié)點(diǎn)無法釋放或內(nèi)存增長(zhǎng)先檢查定時(shí)器。4.3 退出子游戲時(shí)清掉 Bundle 里的資源緩存但要小心公共資源恭喜你到了項(xiàng)目整合里最容易出對(duì)錯(cuò)的一個(gè)點(diǎn)。assetManager.loadBundle把 Bundle 加載進(jìn)來之后它會(huì)對(duì) Bundle 內(nèi)的資源建立緩存bundle.releaseAll()能釋放所有屬于該 Bundle 的資源。理論上“退出子游戲并釋放 Bundle”是最理想的內(nèi)存回收方式。但是這里有個(gè)細(xì)節(jié)如果子游戲 Bundle 里引用了commonBundle 里的某個(gè)公共 SpriteFrame 或字體releaseAll()會(huì)把它引用到的公共資源也一起釋放導(dǎo)致其他 Bundle 也使用該公共資源時(shí)出現(xiàn)“資源為空”或黑圖。正確做法是先確認(rèn)依賴關(guān)系。在 CocosCreator 里可以用bundle.getDependencies()查看依賴的資源 uuid再?zèng)Q定哪些該 release 哪些不該動(dòng)。我一般用“引用計(jì)數(shù)”思維做不直接對(duì) Bundle 調(diào)用releaseAll()而是把未共享的資源顯式釋放把公共資源留在公共 Bundle 里讓它在整個(gè)生命周期內(nèi)不因子游戲退出被錯(cuò)誤銷毀。demo 階段最簡(jiǎn)單的是退出時(shí)只看節(jié)點(diǎn)銷毀不做內(nèi)存管理。等真正上生產(chǎn)再按下面的exitGame增強(qiáng)版處理exitGame() { if (!this.currNode) return; const bundle assetManager.getBundle(this.currentBundleName); this.currNode.destroy(); this.currNode null; if (bundle) { bundle.releaseAll(); assetManager.removeBundle(bundle); } }這行代碼寫起來很爽跑起來如果你沒有公共資源引用也沒問題。萬一你遇到了子游戲退出后公共 UI 丟貼圖就是它干的。真遇到那種情況把releaseAll改成只釋放部分資源或者在關(guān)閉子游戲時(shí)暫時(shí)不removeBundle把它留在內(nèi)存里供下一次快速進(jìn)入。這個(gè)權(quán)衡需要結(jié)合你子游戲的數(shù)量和內(nèi)存預(yù)算不是越傾向釋放越好。5. 項(xiàng)目整合避坑這5個(gè)問題我踩過你最好提前知道5.1 加載了子游戲 Prefab但屏幕還是空的現(xiàn)象進(jìn)入大廳點(diǎn)擊按鈕控制臺(tái)沒有任何報(bào)錯(cuò)或者只打了一個(gè)“加載成功”但是屏幕上看不到子游戲任何元素。原因這個(gè)坑十有八九是子游戲 Prefab 的父節(jié)點(diǎn)不對(duì)。如果你的大廳是一個(gè)全屏節(jié)點(diǎn)而子游戲 Prefab 掛到大廳這個(gè)節(jié)點(diǎn)底下并且子游戲內(nèi)部坐標(biāo)計(jì)算受父節(jié)點(diǎn)UIOpacity、Scale影響可能被縮放成 0 或透明也或者掛到了一個(gè)隱藏節(jié)點(diǎn)下面看起來就是“沒出來”。解決先在大廳代碼里給當(dāng)前節(jié)點(diǎn)設(shè)置一個(gè)可視標(biāo)記比如把currentNode.parent設(shè)成 Canvas 節(jié)點(diǎn)下的一個(gè)專門“子游戲?qū)印眲e掛在大廳 UI 的某個(gè)按鈕下面。另外檢查 Prefab 根節(jié)點(diǎn)的active是否為 true。CocosCreator 的預(yù)制體實(shí)例默認(rèn) active 和編輯器里保持一致如果你在 Prefab 編輯器里掛了隱藏根節(jié)點(diǎn)怎么加載都不會(huì)顯示。還想加一道保險(xiǎn)就在SubGameManager.enterGame成功回調(diào)里強(qiáng)制node.active true。5.2 子游戲資源被打進(jìn)主包Bundle 白設(shè)了現(xiàn)象本地跑的時(shí)候一切正常構(gòu)建以后首包體比你預(yù)計(jì)的多打開構(gòu)建產(chǎn)物也沒見子游戲的貼圖資源占比統(tǒng)計(jì)里把子游戲資源算到了主包。原因CocosCreator 的 Bundle 打包遵循“資源究竟從哪里被引用”。當(dāng)大廳場(chǎng)景或大廳里的公共組件直接引用了子游戲 Prefab 的一部分資源比如一個(gè)公共圖集、一個(gè)腳本常量構(gòu)建器會(huì)認(rèn)為這個(gè)資源是主包依賴于是把它默認(rèn)復(fù)制到主包。這樣子游戲內(nèi)部確實(shí)能運(yùn)行但主包已經(jīng)被越界引用撐大了。解決嚴(yán)格檢查跨包引用。建議在子游戲開發(fā)階段就約定大廳腳本只通過 Bundle 加載子游戲所有子游戲內(nèi)部資源都不要在編輯器中拖拽到大廳預(yù)制體的屬性上。如果發(fā)現(xiàn)某個(gè) SpriteFrame 被大廳的管理器引用到了把引用改成運(yùn)行時(shí)通過 Bundle 加載或者把該資源轉(zhuǎn)移到公共 Bundle。這個(gè)坑沒有構(gòu)建報(bào)錯(cuò)只有靠資源管理器的“依賴圖表”來查。5.3 子游戲onLoad被調(diào)用兩次或者沒調(diào)用現(xiàn)象在子游戲腳本里打console.log(load)第一次進(jìn)入打了兩遍退出再進(jìn)又不打了或者反過來第二次進(jìn)入后子游戲的start一直不觸發(fā)。原因很多是加載姿勢(shì)不對(duì)。我們用bundle.load拿到同一個(gè) Prefab 再instantiate每次 instantiate 出來的新節(jié)點(diǎn)都會(huì)跑onLoad但如果節(jié)點(diǎn)沒有 active 地掛到 Canvas 下而是掛到了一個(gè) inactive 節(jié)點(diǎn)下start不會(huì)執(zhí)行onLoad可能延遲或完全不觸發(fā)。另外如果同一個(gè) Prefab 的引用被大廳的多個(gè)按鈕同時(shí)持有點(diǎn)擊時(shí)實(shí)例化兩次就會(huì)看到兩個(gè)onLoad。解決一套嚴(yán)格流程是確保 Prefab 節(jié)點(diǎn)最終的父節(jié)點(diǎn)是 active 的并且setParent之后不要立刻對(duì)父節(jié)點(diǎn)做destroy。想要防御在子游戲入口腳本的onLoad里加守衛(wèi)判斷一個(gè)全局單例是否存在避免重復(fù)初始化。比如if (SubGame1State.isLoaded) return; SubGame1State.isLoaded true;這個(gè)守衛(wèi)還有一個(gè)作用當(dāng)子游戲被異常重復(fù)加載時(shí)不至于同時(shí)跑兩套游戲循環(huán)。5.4 大廳界面被子游戲遮擋退出后界面錯(cuò)位現(xiàn)象從子游戲回到大廳大廳原本的排行榜、頭像或彈窗不見了或者坐標(biāo)整體偏移。原因子游戲 Prefab 通常是全屏的會(huì)蓋在大廳 UI 上面這沒問題。問題出在進(jìn)入子游戲前你手動(dòng)修改過大廳主 UI 節(jié)點(diǎn)的active或?qū)蛹?jí)退出時(shí)沒有恢復(fù)。比如enterGame里順手把大廳主 UIactive false但exitGame忘了把a(bǔ)ctive true。解決狀態(tài)保存與恢復(fù)要在進(jìn)入和退出時(shí)成對(duì)寫。我習(xí)慣維護(hù)一個(gè)SceneUIState對(duì)象記錄進(jìn)入前的節(jié)點(diǎn)active和setSiblingIndex退出時(shí)按記錄恢復(fù)而不是寫死“大廳 UI 一定存在”的假設(shè)。代碼結(jié)構(gòu)類似private savedState: { node: Node; active: boolean }[] []; enterGame() { this.savedState []; for (const uiNode of this.hallUIList) { this.savedState.push({ node: uiNode, active: uiNode.active }); uiNode.active false; } } exitGame() { for (const state of this.savedState) { state.node.active state.active; } this.savedState []; }這樣做能避免“進(jìn)入子游戲時(shí)隱藏大廳退出時(shí)又忘記顯示”的低級(jí)錯(cuò)誤。5.5 構(gòu)建后 Bundle 找不到控制臺(tái)報(bào) 2048現(xiàn)象構(gòu)建出來的版本在真機(jī)上點(diǎn)擊入口回調(diào)函數(shù)能執(zhí)行但err非空錯(cuò)誤碼 2048或者提示Bundle not found編輯器里跑卻正常。原因CocosCreator 的 Bundle 尋址依賴構(gòu)建后的配置。代碼里assetManager.loadBundle(subgame1)的名字需要和構(gòu)建面板里的 Bundle 名稱一致大小寫也必須一致。如果沒在構(gòu)建配置里把該文件夾勾選為“Bundle”或者構(gòu)建時(shí)沒勾選對(duì)應(yīng)平臺(tái)都會(huì)導(dǎo)致運(yùn)行時(shí)找不到。解決打開構(gòu)建面板展開“Bundle 配置”確認(rèn)subgame1和subgame2都被勾選。真機(jī)調(diào)試時(shí)如果用了遠(yuǎn)程資源服務(wù)器要確保服務(wù)器對(duì)應(yīng)目錄有config.json。別前端拿不到資源就猜代碼先用瀏覽器 DevTools 或原生抓包看網(wǎng)絡(luò)請(qǐng)求路徑多半是路徑少了斜杠或者域名不對(duì)。6. 進(jìn)階技巧給大廳到子游戲的加載過程加進(jìn)度和預(yù)取進(jìn)入子游戲如果全都是動(dòng)態(tài)加載真機(jī)從磁盤讀 Bundle 時(shí)用戶會(huì)看到大廳按鈕點(diǎn)擊后卡一兩秒體驗(yàn)很差。我最后的建議是把大加載過程拆成“進(jìn)度條 預(yù)取”兩步。先做一個(gè)簡(jiǎn)單加載面板彈出后開始加載export class LoadingView extends Component { progress: Label; show(bundleName: string, prefabPath: string, done: () void) { this.node.active true; assetManager.loadBundle(bundleName, (bundle) { bundle.load(prefabPath, Prefab, (err, prefab) { if (!err) { done(); this.node.active false; } }); }); } }上面代碼只有回調(diào)沒有進(jìn)度。要顯示進(jìn)度可以在loadBundle的 options 里帶onProgressassetManager.loadBundle(bundleName, { onProgress: (current: number, total: number) { this.progress.string 加載子游戲 ${Math.floor(current / total * 100)}%; } }, (err, bundle) { ... });不過要注意loadBundle的進(jìn)度回調(diào)是整個(gè) Bundle 資源的加載進(jìn)度Bundle 內(nèi)部還有一次loadprefab 的進(jìn)度想要完整表現(xiàn)需要把兩段進(jìn)度做串連。實(shí)踐中我更推薦另一套在大廳空閑時(shí)預(yù)取子游戲 Bundle但只加載配置不實(shí)例化。比如在首屏 UI 加載完成之后調(diào)一次assetManager.loadBundle(subgame1)趁用戶在首頁(yè)瀏覽時(shí)先把 bundle 拉進(jìn)內(nèi)存。等點(diǎn)擊進(jìn)入時(shí)直接從getBundle里取資源速度會(huì)快一個(gè)量級(jí)。預(yù)取代碼// 大廳 onLoad 里預(yù)取 assetManager.loadBundle(subgame1, (err, bundle) { if (!err) { // 只是為了緩存 bundle節(jié)點(diǎn)先不實(shí)例化 console.log([Hall] subgame1 ready); } }); // 點(diǎn)擊時(shí) const bundle assetManager.getBundle(subgame1); if (bundle) { const prefab bundle.get(prefab/SubGame1, Prefab); this.instantiateSub(prefab); }預(yù)取要注意兩點(diǎn)一是別在首屏onLoad里預(yù)取所有子游戲那樣首屏還是會(huì)變慢建議只預(yù)取第一個(gè)入口或用戶最常進(jìn)的那一個(gè)。二是內(nèi)存預(yù)算。預(yù)取占用的內(nèi)存高峰期疊加如果你在低端機(jī)上跑需要根據(jù)占用狀況主動(dòng)釋放不再需要的 Bundle。CocosCreator 提供assetManager.getDependencyStat可以打資源統(tǒng)計(jì)我上線前會(huì)通過它觀察整包內(nèi)存分配。說個(gè)我自己的習(xí)慣每次新增子游戲時(shí)都要反復(fù)確認(rèn)“大廳入口、加載路徑、退出清理”三件事能不能在 3 步內(nèi) trace 通。trace 不通就說明邊界設(shè)計(jì)有問題真正多子游戲上線出問題的往往不是加載邏輯而是狀態(tài)殘留。項(xiàng)目整合做的是工程結(jié)構(gòu)長(zhǎng)期賬別圖一時(shí)方便而放棄結(jié)構(gòu)上的清晰邊界。希望這個(gè)筆記對(duì)你的 CocosCreator 大廳子游戲 demo 有些幫助踩過的坑你已經(jīng)提前知道了。本文還有配套的精品資源點(diǎn)擊獲取