Cocos Creator 新資源管理系統剖析

v2。4 開始，Cocos Creator 使用 完全重構了資源底層，提供了更加靈活強大的資源管理方式，也解決了之前版本資源管理的痛點（資源依賴與引用），本文將帶你深入瞭解 Creator 的新資源底層。

目錄

資源與構建

理解與使用 AssetBundle

新資源框架剖析

載入管線

檔案下載

檔案解析

依賴載入

資源釋放

1。資源與構建

1。1 creator 資原始檔基礎

在瞭解引擎如何解析、載入資源之前，我們先來了解一下這些資原始檔（圖片、Prefab、動畫等）的規則。

在 creator 專案目錄下有幾個與資源相關的目錄：

assets 所有資源的總目錄，對應 creator 編輯器的資源管理器

library 本地資源庫，預覽專案時使用的目錄

build 構建後的專案預設目錄

在 目錄下，creator 會為每個資原始檔和目錄生成一個同名的檔案，meta 檔案是一個 json 檔案，記錄了資源的版本、uuid 以及各種自定義的資訊（在編輯器的屬性檢查器中設定），比如 prefab 的 meta 檔案，就記錄了我們可以在編輯器修改的 和 等屬性。

在 目錄下的 目錄，資原始檔名會被轉換成 ，並取 uuid 前2個字元進行目錄分組存放，creator 會將所有資源的 到 目錄的對映關係，以及資源和 meta 的最後更新時間戳放到一個名為 的檔案中，如下所示：

與 目錄下的資源相比， 目錄下的資源合併了 檔案的資訊。檔案目錄則只在 中記錄， 目錄並沒有為目錄生成任何東西。

1。2 資源構建

在專案構建之後，資源會從 目錄下移動到構建輸出的 目錄中，基本只會匯出參與構建的場景和 目錄下的資源，及其引用到的資源。指令碼資源會由多個 js 指令碼合併為一個 js，各種 檔案也會按照特定的規則進行打包。

我們可以在 的配置介面和專案的構建介面，為 Bundle 和專案設定：

1。2。1 圖片、圖集、自動圖集

https：//docs。cocos。com/creator/manual/zh/asset-workflow/sprite。html

https：//docs。cocos。com/creator/manual/zh/asset-workflow/atlas。html

https：//docs。cocos。com/creator/manual/zh/asset-workflow/auto-atlas。html

匯入編輯器的每張圖片都會對應生成一個 檔案，用於描述 的資訊。

如下所示，預設情況下專案中所有的 的 檔案會被壓縮成一個，如果選擇無壓縮，則每個圖片都會生成一個 的 檔案。

如果將紋理的 屬性設定為 ，Creator 還會自動生成了 型別的 檔案。

圖集資源除了圖片外，還對應一個圖集 ，這個 json 包含了 資訊，以及每個碎圖的 資訊。

自動圖集在預設情況下只包含了 資訊，在勾選內聯所有 的情況下，會合並所有 。

1。2。2 Prefab與場景

https：//docs。cocos。com/creator/manual/zh/asset-workflow/prefab。html

https：//docs。cocos。com/creator/manual/zh/asset-workflow/scene-managing。html

場景資源與 資源非常類似，都是一個描述了所有節點、元件等資訊的 檔案，在勾選內聯所有 的情況下， 引用到的 會被合併到 所在的 檔案中。

如果一個 被多個 引用，那麼每個 的 檔案都會包含該 的資訊。

而在沒有勾選內聯所有 的情況下， 會是單獨的 檔案。

1。2。3 資原始檔合併規則

當 Creator 將多個資源合併到一個 檔案中，我們可以在 中的 欄位找到被打包的資源資訊，一個資源有可能被重複打包到多個 中。

下面舉一個例子，展示在不同的選項下，creator 的構建規則：

a。png 一個單獨的Sprite型別圖片

dir/b。png、c。png、AutoAtlas dir目錄下包含2張圖片，以及一個AutoAtlas

d。png、d。plist 普通圖集

e。prefab 引用了SpriteFrame a和b的prefab

f。prefab 引用了SpriteFrame b的prefab

下面是按不同規則構建後的檔案，可以看到，無壓縮的情況下生成的檔案數量是最多的，不內聯的檔案會比內聯多，但內聯可能會導致同一個檔案被重複包含，比如 和 這兩個 都引用了同一個圖片，這個圖片的 會被重複包含，合併成一個 則只會生成一個檔案。

預設選項在絕大多數情況下都是一個不錯的選擇。

如果是 平臺

，建議勾選內聯所有 這可以減少網路 ，提高效能。

原生平臺

則不建議勾選，這可能會增加包體大小以及熱更時要下載的內容。

對於一些緊湊的 （比如載入該 Bundle 就需要用到裡面所有的資源），我們可以配置為合併所有的 。

2。 理解與使用 Asset Bundle

2。1 建立 Bundle

是 creator 2。4 之後的資源管理方案，簡單地說，就是透過目錄來對資源進行規劃，按照專案的需求將各種資源放到不同的目錄下，並將目錄配置成 。

能夠起到以下作用：

加快遊戲啟動時間

減小首包體積

跨專案複用資源

方便實現子游戲

以Bundle為單位的熱更新

的建立非常簡單，只要在目錄的屬性檢查器中勾選配置為 即可，其中的選項官方文件都有比較詳細的介紹。

其中關於壓縮的理解，文件並沒有詳細的描述，這裡的壓縮指的並不是 zip 之類的壓縮，而是透過 的方式，把多個資源的 檔案合併到一個，達到減少 的目的。

在選項上打勾非常簡單，真正的關鍵在於如何規劃 。規劃的原則在於減少包體、加速啟動以及資源複用。根據遊戲的模組來規劃資源是比較不錯的選擇，比如按子游戲、關卡副本、或者系統功能來規劃。

會自動將資料夾下的資源，以及資料夾中引用到的其它資料夾下的資源打包（如果這些資源不是在其它 Bundle 中），如果我們按照模組來規劃資源，很容易出現多個 共用了某個資源的情況。

可以將公共資源提取到一個 中，或者設定某個 有較高的優先順序，構建 的依賴關係，否則這些資源會同時放到多個 中（如果是本地 Bundle，這會導致包體變大）。

2。2 使用 Bundle

關於載入資源https：//docs。cocos。com/creator/manual/zh/scripting/load-assets。html

關於釋放資源https：//docs。cocos。com/creator/manual/zh/asset-manager/release-manager。html

的使用也非常簡單，如果是 目錄下的資源，可以直接使用 來載入。

如果是其他自定義 （本地 Bundle 或遠端 Bundle 都可以用 Bundle 名載入），可以使用 來載入 ，然後使用載入後的 物件，來載入 中的資源。

對於原生平臺

，如果 被配置為遠端包，在構建時需要在構建釋出面板中填寫資源伺服器地址。

原生或小遊戲平臺下

，我們還可以這樣使用 Bundle：

如果要載入其它專案的遠端 ，則需要使用 的方式載入（其它專案指另一個 cocos 工程）

如果希望自己管理 的下載和快取，可以放到本地可寫路徑，並傳入路徑來載入這些

其它注意項：

載入   僅僅只是載入了 的配置和指令碼而已， 中的其它資源還需要另外載入

目前原生的 並不支援 zip 打包，遠端包下載方式為逐檔案下載，好處是操作簡單，更新方便，壞處是 io 多，流量消耗大

不同 下的指令碼檔案不要重名

一個 依賴另一個 ，如果 沒有被載入，載入 時並不會自動載入 ，而是在載入 中依賴 的那個資源時報錯

3。 新資源框架剖析

v2.4重構後的新框架程式碼更加簡潔清晰，我們可以先從宏觀角度瞭解一下整個資源框架

，資源管線是整個框架最核心的部分，它規範了整個資源載入的流程，並支援對管線進行自定義。

公共檔案：

定義了一堆公共函式，如 、、 等等

定義了一堆公共函式，如 、、 等等

定義了 方法，將 物件反序列化為 物件，並設定其 屬性

控制資源的依賴列表，每個資源的所有依賴都放在 成員變數中

通用快取類，封裝了一個簡易的鍵值對容器

定義了一些全域性物件，主要是 和 物件，如載入好的 、下載完的 以及 等

Bundle 部分：

的配置物件，負責解析 的 檔案

類，封裝了 以及載入解除安裝 內資源的相關介面

內建 資源的封裝，可以透過 訪問

管線部分：

管理管線，提供統一的載入解除安裝介面

管線框架

實現了管線的管道組合以及流轉等基本功能

定義了一個任務的基本屬性，並提供了簡單的任務池功能

定義了一個資源下載項的基本屬性，一個任務可能會生成多個下載項

預處理管線

將請求引數轉換成 物件（並查詢相關的資源配置），  負責轉換真正的

過濾出需要進行 轉換的資源，並呼叫

下載管線

提供下載音效的方法，使用 標籤進行下載

提供下載圖片的方法，使用 標籤進行下載

提供下載檔案的方法，使用 進行下載

提供下載指令碼的方法，使用 標籤進行下載

支援下載所有格式的下載器，支援併發控制、失敗重試、

解析管線

建立 、、 等物件的工廠

呼叫 下載資源，並解析依賴

對下載完成的檔案進行解析

其它 提供資源釋放介面、負責釋放依賴資源以及場景切換時的資源釋放 在非 WEB 平臺上，用於管理所有從伺服器上下載下來的快取 處理打包資源，包括拆包，載入，快取等等

3。1 載入管線

creator 使用管線（）來處理整個資源載入的流程，這樣的好處是

解耦了資源處理的流程，將每一個步驟獨立成一個單獨的管道，管道可以很方便地進行復用和組合，並且方便了我們自定義整個載入流程，我們可以建立一些自己的管道，加入到管線中，比如資源加密。

內建了條管線

，普通的載入管線、預載入、以及資源路徑轉換管線，最後這條管線是為前面兩條管線服務的。

3。1。1 啟動載入管線【載入介面】

接下來，我們看一下一個普通的資源是如何載入的

，比如最簡單的 ，在 方法中，呼叫了 ，在 方法中，建立了一個新的任務，並呼叫正常載入管線 的 方法執行任務。

注意要載入的資源路徑，被放到了 中、是一個物件，物件包含了 和 等欄位。

由兩部分組成 和 。 由以下管線組成 、， 實際上只建立了一個子任務，然後交由 執行。對於載入一個普通的資源，子任務的 和 與父任務相同。

3。1。2 transformPipeline 管線【準備階段】

由 和 兩個管線組成， 的職責是為每個要載入的資源生成 物件並初始化其資源資訊（AssetInfo、uuid、config等）：

先將 轉換成陣列進行遍歷，如果是批次載入資源，每個載入項都會生成；

如果輸入的 是 ，則先將 複製到 身上（實際上每個 都會是 ，如果是 的話，第一步就先轉換成 了）

對於 型別的 ，先檢查 ，並從 中提取 ，對於 型別的資源，則從其依賴的 中獲取 ，找不到 就報錯

型別和 型別與 型別的處理基本類似，都是要拿到資源的詳細資訊

型別會從 中取出指定路徑的資訊，然後批次追加到 尾部（額外生成載入項）

型別是遠端資源型別，無需特殊處理

的初始資訊，都是從 物件中查詢的， 的資訊則是從 自帶的 檔案中初始化的，在打包 的時候，會將 中的資源資訊寫入 中。

經過 方法處理後，我們會得到一系列 ，並且很多 都自帶了 和 等資訊， 方法會為每個 構建出真正的載入路徑，這個載入路徑最終會轉換到 中。

3。1。3 load管線【載入流程】

方法做的事情很簡單，基本只是建立了新的任務，在 中執行每個子任務。

如其函式名所示，就是載入一個資源的管線，它分為2步， 和 ：

方法：

用於下載資原始檔，由 負責下載的實現， 會將下載完的檔案資料放到 中。

方法：

用於將載入完的資原始檔轉換成我們可用的資源物件：

對於原生資源

，呼叫 進行解析，該方法會根據資源型別呼叫不同的解析方法

資源呼叫 方法，根據 資料反序列化出 物件，並放到 中

圖片資源會呼叫 、或方法解析影象格式（但不會建立物件）

音效資源呼叫 方法進行解析

資源呼叫 方法進行解析

對於其它資源

，如果 在 中，則標記為完成，並新增引用計數；否則，根據一些複雜的條件來決定是否載入資源的依賴。

3。2 檔案下載

creator 使用 來完成下載的工作，當要下載一個檔案時，

有2個問題需要考慮：

該檔案是否被打包了？

比如由於勾選了內聯所有 ，導致 的 檔案被合併到 中

當前平臺是原生平臺還是 web 平臺？

對於一些本地資源，原生平臺需要從磁碟讀取。

3。2。1 Web 平臺的下載

web 平臺的 實現如下：

用一個 陣列來管理各種資源型別對應的下載方式

使用 快取來避免重複下載

使用 佇列來處理併發下載同一個資源時的回撥，並保證時序

支援了下載的優先順序、重試等邏輯