我們在編輯器中看到的資源,在建構之後會進行一些轉化,本章将揭開Creator對資源進行的處理。
資源處理的整體規則
首先我們将Creator的開發和運作劃分為以下幾個場景:
編輯器
當我們将資源放到編輯器中時,Creator會為每個資源生成唯一的uuid以及meta檔案,并在項目的library目錄下生成對應的json檔案來描述這個資源的資訊,而uuid與資源的映射關系被放在library目錄下的uuid-to-mtime.json檔案中。由于資源的引用關系是靠uuid來維系的,是以我們可以在Creator中随意地修改資源檔案名、移動資源路徑,而不用擔心資源的關聯丢失問題。
我們在編輯器中編輯的prefab、anim、場景等檔案本質上是一個json檔案,Cocos Creator 設計了一套json規則用于描述各種資源,prefab的json描述了prefab的結構以及每個節點的屬性,但部分屬性會放到meta檔案中,一般是針對該資源在編輯器中的設定。
預覽
預覽的時候使用的是library目錄下的資源,不僅僅是項目assets目錄下的所有資源(包括未被引用到的資源),引擎提供的一些預設資源也可以在library目錄下找到。預覽的模闆位于引擎安裝目錄下的resources/static/preview-templates,程式的啟動腳本為boot.js。
建構
項目建構之後,資源會從library目錄下移動到建構輸出的目錄中,基本隻會導出參與建構的場景和resources目錄下的資源,及其引用到的資源。腳本資源會由多個js腳本合并為一個js,各種json檔案也會按照特定的規則進行打包(所謂的packAssets)。
各種資源的處理
-
基礎圖檔
圖檔的meta檔案大概如下所示,除了ver和uuid之外,還有3個屬性:
- Type有sprite和raw兩種,如果選擇了raw,那麼就不會有subMetas等屬性,而且在Creator的資料總管面闆中可以發現這個圖檔左邊的小箭頭消失了。
- WrapMode為環繞模式,包含clamp內插補點和repeat重複兩種,但這裡的設定在Creator中一般是無效的,因為在Sprite元件中是用Type進行控制,它提供了九宮格、平鋪、填充等方式。
- FilterModel提供了3種內插補點過濾選項,Point點內插補點、Bilinear雙線性內插補點、Trilinear三線性內插補點,性能依次下降,效果依次提升。
這裡的subMetas描述了一個SpriteFrame資訊,詳情可參考Sprite元件
{
"ver": "2.0.0",
"uuid": "a0576798-bdf4-4f06-972e-5557dee6ee1b",
"type": "sprite",
"wrapMode": "clamp",
"filterMode": "bilinear",
"subMetas": {
"boss_b_hp1": {
"ver": "1.0.3",
"uuid": "5425ad9a-e2e0-4c6e-825b-c3ea43b09e4e",
"rawTextureUuid": "a0576798-bdf4-4f06-972e-5557dee6ee1b",
"trimType": "auto",
"trimThreshold": 1,
"rotated": false,
"offsetX": 0,
"offsetY": 0,
"trimX": 0,
"trimY": 0,
"width": 78,
"height": 78,
"rawWidth": 78,
"rawHeight": 78,
"borderTop": 0,
"borderBottom": 0,
"borderLeft": 0,
"borderRight": 0,
"subMetas": {}
}
}
}
這樣的一個圖檔會在library/imports/xx目錄下生成3個檔案(如果将圖檔的type設定為raw則不會有SpriteFrame對應的json檔案),分别是以圖檔uuid為檔案名的json檔案和png,以及SpriteFrame的uuid為檔案名的json檔案。
Texture對應的json檔案内容如下,每一個紋理都會生成一個這樣的重複的檔案:
{
"__type__": "cc.Texture2D",
"content": "0"
}
SpriteFrame對應的json檔案内容如下:
{
"__type__": "cc.SpriteFrame",
"content": {
"name": "boss_b_hp1",
"texture": "a0576798-bdf4-4f06-972e-5557dee6ee1b",
"atlas": "",
"rect": [
0,
0,
78,
78
],
"offset": [
0,
0
],
"originalSize": [
78,
78
]
}
}
在建構之後,資源會被導出到res目錄下,json檔案放在import目錄下,png等資源檔案放在raw-assets目錄。
-
圖集資源
圖集分為plist和圖檔兩個檔案,圖集圖檔的meta和普通圖檔的meta一樣,而plist檔案的meta記錄了圖集中所有碎圖的資訊。主要有ver、uuid、rawTextureUuid、size、type以及subMetas等屬性,subMetas記錄了每一個碎圖的meta資訊,結構和普通圖檔的meta一樣。
{
"ver": "1.2.4",
"uuid": "315d61c8-b6c8-4635-b517-f868dd8b3495",
"rawTextureUuid": "01979186-b9a2-4130-a307-a2eacb5fe30f",
"size": {
"width": 1024,
"height": 1024
},
"type": "Texture Packer",
"subMetas": {
"role1001-move1.png": {
"ver": "1.0.3",
"uuid": "8e225dbc-7905-416f-a7ac-0730893ad30d",
"rawTextureUuid": "01979186-b9a2-4130-a307-a2eacb5fe30f",
"trimType": "auto",
"trimThreshold": 1,
"rotated": false,
"offsetX": 0,
"offsetY": -52,
...
在library目錄下會生成plist的json檔案,type為cc.SpriteAtlas,記錄了圖集中所有spriteFrames的uuid,每一個碎圖都會有一個描述其SpriteFrame的json檔案生成。最後,圖檔檔案照常會有一個Texture和SpriteFrame的json生成。
{
"__type__": "cc.SpriteAtlas",
"_name": "role1001.plist",
"_objFlags": 0,
"_native": "",
"_spriteFrames": {
"role1001-move1": {
"__uuid__": "8e225dbc-7905-416f-a7ac-0730893ad30d"
},
"role1001-move2": {
"__uuid__": "7e0641ef-5974-4c2d-bad3-80c59a3195d8"
},
...
建構之後,cc.SpriteAtlas與所有的cc.SpriteFrame會合為一個json,而圖檔本身仍然會導出cc.Texture和cc.SpriteFrame的json。
【合并初始場景依賴的所有json】會讓所有用到的json都合并成一個。【内聯所有SpriteFrame】會将所有用到的SpriteFrame的json資訊複制到引用它們的場景或prefab的json中,如果是單獨的一個SpriteFrame,會被直接合并。(這種情況下,其他場景加載該資源時如何處理?即該資源已經被打包到其他場景或prefab中。多個prefab同時引用時誰能打包到該資源呢?加載一個打包資源中的一個json,是否會直接加載該json包中的所有json)
-
AutoAtlas自動圖集
AutoAtlas可以自動将目前目錄以及子目錄下所有的圖檔進行合圖,他的meta檔案描述了合圖的規則,如最大尺寸、是否允許旋轉、是否強制圖檔轉為正方形、尺寸是否為2的幂、使用的合圖算法等等...
{
"ver": "1.1.0",
"uuid": "691bdbcd-78c9-41da-864f-481d1af5c8ff",
"maxWidth": 1024,
"maxHeight": 1024,
"padding": 2,
"allowRotation": true,
"forceSquared": false,
"powerOfTwo": true,
"heuristices": "BestAreaFit",
"format": "png",
"quality": 80,
"contourBleed": false,
"paddingBleed": false,
"filterUnused": false,
"subMetas": {}
}
而在library目錄下,AutoAtlas隻會生成一個簡單的json檔案,在預覽的時候,AutoAtlas不會發生任何作用。
{
"__type__": "cc.SpriteAtlas",
"_name": "AutoAtlas"
}
建構之後,會生成cc.SpriteAtlas類型的一個json檔案,記錄所有碎圖的uuid。AutoAtlas所在目錄下的碎圖會合成一張,而它們的SpriteFrame資訊則不會像plist圖集一樣合并到圖集的json檔案中,而是每個SpriteFrame一個json檔案。
{
"__type__": "cc.SpriteAtlas",
"_spriteFrames": {
"building_01": {
"__uuid__": "d47RnkKqBHw6xXpAKXUDWt"
},
"building_02": {
"__uuid__": "a8CDt9ghBA5LzcZdD79OcY"
},
"building_03": {
"__uuid__": "f4JnL6lkFFjZC9QkBYLbZM"
},
"building_04": {
"__uuid__": "0cwdvX5/pBXYpf4xhZG+I+"
},
"building_05": {
"__uuid__": "64GzrRUetDzreLftZ9Unt5"
}
}
}
-
場景與prefab
場景和prefab類似,都是用一個json檔案來描述節點樹。json檔案首先描述一個數組,數組的第一個元素(下标0)描述的是該資源的類型以及該資源特定的屬性,接下來是一個一個的節點、元件對象,每個對象都描述了自身的各種屬性,以及它們和其它對象的關系,其中的__id__字段對應的值表示目前json數組的下标。
[
// 數組的第一個元素,資源概述
{
"__type__": "cc.prefab", // 類型,場景的__type__為cc.SceneAsset
"_name": "",
"_objFlags": 0,
"_native": "",
"data": { // 資料(該prefab的根節點id),場景為scene字段
"__id__": 1
},
"optimizationPolicy": 0, // 建立優化政策(場景無該選項)
"asyncLoadAssets": false // 是否開啟延遲加載資源(場景無該選項)
},
// 數組的第二個元素,prefab的根節點,其name為Base,有2個子節點,id為2和5
{
"__type__": "cc.Node",
"_name": "Base",
"_objFlags": 0,
"_parent": null,
"_children": [
{
"__id__": 2
},
{
"__id__": 5
}
],
"_tag": -1,
"_active": true,
"_components": [],
"_prefab": {
"__id__": 8
},
"_id": "",
"_opacity": 255,
"_color": {
"__type__": "cc.Color",
"r": 255,
"g": 255,
"b": 255,
"a": 255
},
"_cascadeOpacityEnabled": true,
"_anchorPoint": {
"__type__": "cc.Vec2",
"x": 0.5,
"y": 0.5
},
"_contentSize": {
"__type__": "cc.Size",
"width": 0,
"height": 0
},
"_rotationX": 0,
"_rotationY": 0,
"_scaleX": 1,
"_scaleY": 1,
"_position": {
"__type__": "cc.Vec2",
"x": 0,
"y": 0
},
"_skewX": 0,
"_skewY": 0,
"_localZOrder": 0,
"_globalZOrder": 0,
"_opacityModifyRGB": false,
"groupIndex": 0
},
{
...
},
// Sprite元件的資料,它挂載在本數組中下标為2的Node上(第三個元素)
{
"__type__": "cc.Sprite",
"_name": "",
"_objFlags": 0,
"node": {
"__id__": 2
},
"_enabled": true,
"_spriteFrame": {
// 所有的__uuid__都指向了一個新的資源
"__uuid__": "d4ed19e4-2aa0-47c3-ac57-a402975035ad"
},
"_type": 0,
"_sizeMode": 1,
"_fillType": 0,
"_fillCenter": {
"__type__": "cc.Vec2",
"x": 0,
"y": 0
},
"_fillStart": 0,
"_fillRange": 0,
"_isTrimmedMode": true,
"_srcBlendFactor": 770,
"_dstBlendFactor": 771,
"_atlas": null
},
{
"__type__": "cc.prefabInfo",
"root": {
"__id__": 1
},
"asset": {
"__id__": 0
},
"fileId": "acUWY0/UZLeZdVqtcRkZuq",
"sync": false
},
...
]
- 關于資源依賴和prefab嵌套
- 場景和prefab依賴的資源,我們都可以在它們的json檔案中,找到__uuid__這樣的屬性,通過這個字段記錄了資源間的依賴。
- 檢視了最新的CocosCreator2.x,目前的prefab還不支援真正意義上的嵌套,目前的嵌套prefab本質上是将一個prefab的内容拷貝到另一個prefab中。
- 關于挂載腳本
- 自定義的腳本元件挂載到prefab或場景的某節點時,在json檔案中生成的元件對象的__type__對應的是該腳本的23位uuid。
- 腳本定義了資源類變量,可在屬性檢查器中拖拽資源賦給腳本變量的,prefab會記錄該資源的__uuid__,如果拖拽了prefab自身的節點,則記錄其__id__
// 元件的__type__為腳本的23位uuid
"_components": [
{
"__type__": "b8386waIgRGVJwXT7yno4pm",
"node": {
"__id__": 1
},
// myRootNode和mySpriteFrame為腳本中的2個變量,在屬性檢查器中拖拽的
"myRootNode": { // myRootNode記錄着目前prefab中id為2的節點
"__id__": 2
},
"mySpriteFrame": { // mySpriteFrame記錄着一個外部的SpriteFrame的uuid
"__uuid__": "40t3EpX7tCnq5b2lM2bG8F"
},
}
],
Scene和prefab對應的meta檔案比較簡單,prefab包含了建立優化政策選項,Scene包含了是否自動釋放資源選項,他們都包含了是否延遲加載資源的選項。大緻如下所示:
// prefab的meta檔案内容
{
"ver": "1.0.0",
"uuid": "c7d921c2-6021-4613-93bd-6201de418e24",
"optimizationPolicy": "AUTO",
"asyncLoadAssets": false,
"subMetas": {}
}
// scene檔案的meta檔案内容
{
"ver": "1.0.0",
"uuid": "2afc2a6e-f61e-4f46-8a52-af34d838a4b0",
"asyncLoadAssets": false,
"autoReleaseAssets": false,
"subMetas": {}
}
在library目錄下,以及建構目錄中,prefab和scene基本是json檔案本身内容的一個複制。可能會根據prefab和scene的選項稍微修改json數組首元素的内容(比如添加asyncLoadAssets字段)。
-
Creator動畫
Creator動畫儲存在anim檔案中,每一個anim都是一個動畫Clip。我們可以在Creator中的資料總管右鍵/建立/Animation Clip來建立新的anim動畫檔案。要使用動畫我們需要為一個節點挂載Animation元件,然後将anim檔案拖拽到Animation元件的clips屬性中。關于Creator動畫的更多詳情可以參考官方文檔 https://docs.cocos.com/creator/manual/zh/animation/ 。
anim檔案本質是一個json檔案,它的内容大緻如下,除了Creator标準的json字段,以及Clip的全局屬性(wrapMode、speed等)外,curveData字段記錄所有的動畫資訊,events字段記錄了該動畫中所有的幀事件。它的meta檔案隻記錄了ver、uuid以及一個空的subMetas。
{
"__type__": "cc.AnimationClip",
"_name": "1",
"_objFlags": 0,
"_native": "",
"_duration": 0.25,
"sample": 60,
"speed": 1,
"wrapMode": 1,
"curveData": {
"paths": {
"build_b_2": {
"props": {
"position": [
{
"frame": 0,
"value": [
39,
29
]
},
{
"frame": 0.25,
"value": [
109,
29
]
}
]
}
}
}
},
"events": [
{
"frame": 0.25,
"func": "",
"params": []
}
]
}
該檔案會被直接拷貝到library目錄下,建構之後會直接導出該檔案。
-
聲音音效類資源
聲音音效資源的meta檔案非常簡單,目前唯一的一個自定義屬性就是downloadMode,即聲音的加載模式,有Web Audio和DOM Audio兩種。前者相容性更好,但會占用更多的記憶體,故建議短音效用Web Audio,長音樂使用DOM Audio。
{
"ver": "2.0.0",
"uuid": "ab548e86-4fca-4320-a8a0-0c1a714d1443",
"downloadMode": 0,
"subMetas": {}
}
在library目錄下,Creator會為每個聲音資源生成一個以uuid為命名的json檔案,以及将聲音檔案以uuid命名。json檔案的内容如下:
{
"__type__": "cc.AudioClip",
"_name": "music_logo",
"_objFlags": 0,
"_native": ".mp3",
"loadMode": 0
}
建構之後library目錄下的json和聲音檔案會被複制到建構目錄下的import和raw-assets目錄中。
-
Spine骨骼動畫
每個Spine都是由json(Creator暫時不支援skel格式)、atlas、png三個檔案組成,它們的meta檔案非常簡單,沒有什麼特殊的資訊。
在library目錄下,png會生成對應的SpriteFrame和Texture的json,以及圖檔自身。atlas會生成一個簡單的json檔案,如下所示。骨骼json會進行轉換,變成Creator标準的資源格式json,以uuid命名,在目前目錄下會建立一個以uuid命名的目錄,放着轉換前的Spine json檔案,名為raw-skeleton.json。(Creator格式的json比原Spine的json要大不少)
{
"__type__": "cc.Asset",
"_name": "raptor",
"_native": ".atlas"
}
建構之後,png對應的SpriteFrame、Texture的json,以及Atlas的json。Spine本身的json會轉換成Creator标準的資源格式json輸出到建構目錄下,而且raw-skeleton.json并不在建構目錄中。
-
腳本資源的處理
在Creator中支援TS和JS腳本,這裡不讨論如何編寫腳本。腳本的meta檔案中有幾個有意思的屬性,與Plugin相關,意為是否将該腳本作為插件導入。對第三方插件或者底層插件,有可能需要選中Plugin選項,這樣的腳本簡稱插件腳本(未勾選該選項的為普通腳本)。腳本插件在打包時是不會參與建構的。
關于該選項的詳細介紹可以檢視 https://docs.cocos.com/creator/manual/zh/scripting/plugin-scripts.html 。
{
"ver": "1.0.5",
"uuid": "8c87839a-4fd0-4b9e-9363-23bbf1bd16ef",
"isPlugin": false,
"loadPluginInWeb": true,
"loadPluginInNative": true,
"loadPluginInEditor": false,
"subMetas": {}
}
在library目錄下,TS會被編譯成JS腳本,所有的JS腳本都會以其uuid命名存儲。與JS檔案一起生成的還有map檔案(這裡放着編譯前的原檔案内容和路徑等相關資訊)。
建構之後所有的TS和JS腳本會被編譯成JS,打包到一個project.dev.js檔案中。建構一般會生成4個js,記錄所有資源相關設定的settings.js,啟動腳本main.js,開發者的代碼project.dev.js以及cocos引擎cocos2d-js.js。如果開啟了調試模式,建構出來的js會被精簡為一行,剔除所有的注釋和空行換行,并自動将一些變量名進行混淆,使用更簡短的命名,而不影響代碼執行的效果。如果開啟了Source Maps,建構代碼時會生成map檔案,否則不會生成。
我們可以在Creator編輯器中的項目菜單/項目設定/子產品設定下選擇剔除我們不需要用到的子產品,進而精簡cocos2d-js.js檔案的大小(新一代的js打包工具如rollup.js已經可以支援到在打包的時候自動根據引用到的代碼去剔除無用代碼)。
-
字型資源的處理
CocosCreator的字型可以分為3類,系統字、BMFont以及TTF字型。系統字不需要額外的字型資源,而是使用内置的系統字型。BMFont的資源是一張圖檔以及一個fnt。而TTF字型的資源是一個TTF檔案。
fnt資源的meta檔案如下所示,指定了fontSize,以及使用的紋理。
{
"ver": "2.1.0",
"uuid": "e2fd9257-452a-4ae2-a932-e567c5fd6e91",
"textureUuid": "1afd96d7-225c-484b-ab27-fe12902096d6",
"fontSize": 32,
"subMetas": {}
}
在library目錄下,除了圖檔相關的Texture、SpriteFrame等json。fnt檔案會被轉成一個cc.BitmapFont的json檔案,檔案内容如下所示,_fntConfig描述了fnt字型的字号、寬高、圖集以及每一個字在圖集中的坐标尺寸等資訊。
{
"__type__": "cc.BitmapFont",
"_name": "b0",
"_objFlags": 0,
"_native": "",
"fntDataStr": "",
"spriteFrame": {
"__uuid__": "a3e89811-562f-4a58-943f-895c807f087b"
},
"fontSize": 32,
"_fntConfig": {
"commonHeight": 32,
"fontSize": 32,
"atlasName": "b0_0.png",
"fontDefDictionary": {
"36": {
"rect": {
"x": 81,
"y": 0,
"width": 79,
"height": 111
},
"xOffset": 0,
"yOffset": 0,
"xAdvance": 79
},
...
建構之後,cc.BitmapFont和SpriteFrame這2個json會被合并(我們往往需要同時使用到它們)。
TTF的meta檔案隻有ver、uuid和空的subMetas字段。在library目錄下會生成一個以TTF資源的uuid命名的json檔案,在相同目錄下有一個以TTF資源的uuid目錄,目錄下放着ttf資源。
{
"__type__": "cc.TTFFont",
"_name": "BlackHanSans-Regular",
"_objFlags": 0,
"_native": "BlackHanSans-Regular.ttf"
}
建構後該json檔案會剔除_objFlags字段後導出,而TTF檔案會導出到raw-assets目錄下。
-
粒子資源的處理
粒子資源大緻可以分為plist和prefab兩種:
- 對于plist粒子,存在圖檔使用Base64編碼合并到plist檔案中,和引用外部粒子圖檔的差別。plist的meta檔案隻有ver、uuid和空的subMetas字段。在library目錄下會生成plist和它對應的json檔案,如下所示,如果是帶紋理的粒子,會生成對應的Texture和SpriteFrame的json。建構之後會導出plist的json檔案,在raw-assets中導出plist檔案,如果引用了外部紋理也會導出紋理對應的圖檔和json。
{
"__type__": "cc.ParticleAsset",
"_name": "p_star_fly",
"_objFlags": 0,
"_native": ".plist",
"texture": {
"__uuid__": "1544eed3-42e4-46fc-a392-0c4d8b1b9847"
}
}
- prefab類型的粒子和普通的prefab一樣,library目錄下會生成prefab的json檔案(包含所有的粒子屬性)以及粒子的plist檔案(library目錄下預設會有一些内置的粒子系統)。而建構之後,如果粒子系統的File字段指定了一個plist檔案,建構出來的raw-assets目錄中會導出plist,而導出的粒子json是一個比較簡短的json(因為大部分的屬性都定義在plist檔案中了),除非我們在編輯器中編輯了自定義的屬性。
資源打包規則
在了解了Creator對單個資源的處理之後,我們要對Creator資源打包規則做更深入的分析。對于資源打包,我們主要關注的2點是IO和包體,json的合并可以減少IO操作,在某些情況下也可能增大包體。
關于圖檔的合并
在Creator建構後每一個圖檔都會生成一個描述cc.Texture2D的json以及一個cc.SpriteFrame的json,而其中所有的cc.Texture2D.json都會被合并成一個,應該說一個項目在建構之後,正常來說最多隻會有一個cc.Texture2D的json,隻是它的data字段會很長。不論圖檔是來自不同目錄的圖檔、圖集、自動圖集、Spine、粒子系統或者BMFont等等,都不影響它們的cc.Texture2D.json被合并。
{
"type": "cc.Texture2D",
"data": "0|0|0|0|0|0|0|0|0|0|0|0"
}
圖檔對應的SpriteFrame又會被怎樣合并呢?預設的情況下(即不考慮依賴和建構選項的情況)隻有plist圖集和BMFont字型這兩種資源的SpriteFrame會有合并的操作。plist的json會與圖集中所有的SpriteFrame的json合并為一個json。BMFont字型的fnt對應的json會與SpriteFrame合并為一個json。
接下來我們來看一下資源依賴的情況,使用prefab去引用各種類型的資源,json又會如何合并呢?prefab引用的所有資源中,隻有單個圖檔和自動圖集中的SpriteFrame會被合并到prefab的json中。
如果我們在建構時勾選了“内聯所有SpriteFrame”,json又會如何合并呢?除了單個圖檔和自動圖集,prefab中用到的圖集的SpriteFrame也會被合并進來,但圖集的合并是拷貝,也就是說原來的圖集和圖集中所有SpriteFrame合并的那個json仍然存在。
如果我們的資源同時被多個prefab引用,在這種情況下,是否勾選“内聯所有SpriteFrame”又會有怎樣的差別呢?
- 不勾選的情況下,圖集多個prefab共同引用的部分SpriteFrame會被提取出來進行合并(單張圖檔和AutoAtlas)。共同部分至少需要2個SpriteFrame,比如說A和B,每一個引用到公共SpriteFrame的prefab必定同時引用到A和B,如果有一個prefab隻引用了A,那麼A和B就不會被合并。
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLicmbw5iNDFnNhZ0LcVTMvwlMx8CX4EDMy8CXt92YugXM4FmLxM3Lc9CX6MHc0RHaiojIsJye.png)
- 勾選的情況下,不存在共用資源的說法,每個prefab都會合并它用到的SpriteFrame(單張圖檔、AutoAtlas、圖集),如果這些資源被多個prefab引用,那麼會被複制到每一個prefab的json中。
前面介紹了prefab的依賴對建構打包的影響,在Creator中,除了prefab可以去引用資源外,場景也可以引用外部資源,但正常情況下場景不會去将其引用的SpriteFrame打包進來。在勾選了“内聯所有SpriteFrame”的情況下,場景的json才會去合并引用到的SpriteFrame。
在勾選了“合并初始場景依賴的所有JSON”後,初始場景引用到的所有json都會被合并到初始場景的json檔案中,這種合并不是拷貝,而是将場景引用到的所有資源的json檔案合并到一起(除了SpriteFrame外,還有粒子json、plist圖集完整json、Spine骨骼json、BMFont字型json、動畫json等等)。如果沒有勾選“内聯所有SpriteFrame”,這些json隻會放在啟動場景的json中,不會影響包體。值得一提的是圖檔的cc.Texture2D這個json,所有被初始場景引用到的紋理會從這個json中剝離,并合并到初始場景。