玩轉(zhuǎn)Unity資源，對(duì)象和序列化
來源：
未知 |
責(zé)任編輯：CHH |
發(fā)布時(shí)間： 2017-06-22 14:20 | 瀏覽量：
本文將從Unity3d編輯器和運(yùn)行時(shí)兩個(gè)角度出發(fā)，主要探討以下兩方面內(nèi)容：Unity序列化系統(tǒng)內(nèi)部細(xì)節(jié)以及Unity如何維護(hù)不同對(duì)象之間的強(qiáng)引用。另外還會(huì)討論對(duì)象與資源的技術(shù)實(shí)現(xiàn)差別。
譯注：除非特別說明，下文中所有的“資源”均指代“Asset”。
本文內(nèi)容是理解在Unity中如何高效加載和卸載資源的基礎(chǔ)。正確的資源管理對(duì)縮短加載時(shí)間并減少內(nèi)存占用來說至關(guān)重要。今天先為大家分享上半部分內(nèi)容。
1.1. 深入理解資源和對(duì)象
在理解Unity如何確保萬無一失地管理數(shù)據(jù)之前，首先要知道Unity是如何識(shí)別并序列化數(shù)據(jù)的。首先第一點(diǎn)，要正確區(qū)分資源（Asset）和對(duì)象（UnityEngine.Objects）。
Asset
資源（Asset）是硬盤中的文件，存儲(chǔ)在Unity工程的Assets文件夾內(nèi)。例如，紋理（Texture），材質(zhì)（Material）和FBX文件等，它們都是資源。一些資源的數(shù)據(jù)格式是Unity原生支持的，例如材質(zhì)。有些資源則需要轉(zhuǎn)換為原生的數(shù)據(jù)格式后才能被Unity使用，例如FBX文件。
UnityEngine.Object
UnityEngine.Object，或者說以大寫字母O開頭的Object——對(duì)象，代表序列化數(shù)據(jù)的集合，表示某個(gè)資源的具體實(shí)例。它可以是Unity引擎使用的任何類型的資源，例如網(wǎng)格，Sprite，音頻剪輯或動(dòng)畫剪輯。所有的對(duì)象（Object）都是UnityEngine.Object基類的子類。
特殊的Object類型
幾乎所有的對(duì)象（Object）類型都是內(nèi)建的，其中有兩種比較特殊的類型。
ScriptableObject為開發(fā)者提供了一套便捷的系統(tǒng)，供開發(fā)者自定義數(shù)據(jù)類型。這些類型可以被Unity直接序列化或反序列化，并在Unity編輯器的檢視器窗口中進(jìn)行操作。
MonoBehaviour提供了鏈接MonoScript的容器。MonoScript是一種內(nèi)部數(shù)據(jù)類型，Unity用它保存對(duì)某個(gè)特定程序集和命名空間中特定腳本類的引用，MonoScript本身不包含任何實(shí)際的可執(zhí)行代碼。
一對(duì)多關(guān)系
資源（Asset）與對(duì)象（Object）是一種一對(duì)多的關(guān)系，即一個(gè)資源文件可能會(huì)包括多個(gè)Object。
1.2. 對(duì)象之間的引用
所有UnityEngine.Objects都可以引用其他的UnityEngine.Objects。這里“其他的Object”可能存在于相同的資源文件中，或需要從其他資源文件導(dǎo)入。例如，一個(gè)材質(zhì)Object通常有一個(gè)或多個(gè)紋理Object的引用。這些紋理Object一般是從一個(gè)或多個(gè)紋理資源文件中導(dǎo)入的（例如PNG或JPG文件）。
序列化后，這些引用由兩部分?jǐn)?shù)據(jù)組成：文件GUID和本地ID。文件GUID用于識(shí)別資源（Asset）文件中目標(biāo)資源（Resource）的存儲(chǔ)位置。而本地唯一(1)的ID負(fù)責(zé)識(shí)別單個(gè)資源文件中的Object，因?yàn)橐粋€(gè)資源文件可能會(huì)包含多個(gè)Object。
文件GUID(.meta)
文件GUID存儲(chǔ)于.meta文件中。Unity會(huì)在首次導(dǎo)入資源文件時(shí)生成.meta文件，并和資源文件一起存儲(chǔ)在相同的目錄中。
上述的識(shí)別和引用系統(tǒng)可以使用文本編輯器查看：
創(chuàng)建一個(gè)全新的Unity工程，更改編輯器設(shè)置，將Edit - Project Settings - Editor中的Version Control設(shè)為Visible Meta Files，并將Asset Serialization設(shè)為文本。
新建材質(zhì)并向工程中導(dǎo)入一個(gè)紋理。將材質(zhì)賦給場(chǎng)景中的一個(gè)立方體，保存場(chǎng)景。
使用文本編輯器打開這個(gè)材質(zhì)對(duì)應(yīng)的.meta文件。在文件頂端附近會(huì)有一行被標(biāo)示為“guid”，該行定義了材質(zhì)資源文件的文件GUID。
1
本地ID(具體文件)
如需查看本地ID，使用文本編輯器打開材質(zhì)文件，材質(zhì)Object的定義大致如下：
2
在上面的例子中，前面有&符號(hào)的數(shù)字就是材質(zhì)的本地ID。如果這個(gè)材質(zhì)的Object位于一個(gè)文件GUID為“abcdefg”的資源文件中，則該材質(zhì)Object的唯一識(shí)別符就是文件GUID“abcdefg”和本地ID“2100000”的組合。
1.3. 為什么要用文件GUID和本地ID？
工作流程
在Unity中，為什么要使用文件GUID和本地ID這套系統(tǒng)呢？答案是為穩(wěn)定服務(wù)，也是為了提供一套靈活的、無關(guān)具體平臺(tái)的工作流程。文件GUID提供了文件存儲(chǔ)位置的抽象，這樣一個(gè)文件GUID就對(duì)應(yīng)一個(gè)具體的文件，這個(gè)具體的文件存儲(chǔ)在什么位置也就無關(guān)緊要了。因此我們才能隨意移動(dòng)這個(gè)文件而不破壞所有相關(guān)Object對(duì)這個(gè)文件的引用。
任何資源（Asset）文件中都可能含有（或通過導(dǎo)入產(chǎn)生）多個(gè)UnityEngine.Object資源（Resource），因此需要一個(gè)本地ID來對(duì)其中的Object做明確區(qū)分。
如果與資源文件相關(guān)聯(lián)的文件GUID丟失，則所有對(duì)該資源文件中的Object的引用都會(huì)被破壞。這就是必須保證.meta文件具有和資源文件相同的文件名并存儲(chǔ)在同一目錄下的原因。注意Unity會(huì)重新生成丟失或被刪除的.meta文件。
Unity編輯器維護(hù)映射表
Unity編輯器負(fù)責(zé)維護(hù)一張文件路徑與文件GUID之間關(guān)系的映射表。只要資源文件被讀取或?qū)?，這個(gè)映射關(guān)系就會(huì)被建立，映射會(huì)將資源的具體位置和資源的文件GUID進(jìn)行關(guān)聯(lián)。Unity編輯器處于打開狀態(tài)時(shí)，假設(shè)一個(gè)文件的.meta意外丟失，并且該資源文件的路徑?jīng)]有改變，編輯器可以保證這個(gè)資源會(huì)被分配到相同的文件GUID。
如果在Unity編輯器處于關(guān)閉狀態(tài)時(shí)丟失.meta文件，或資源文件被移動(dòng)但沒有移動(dòng)對(duì)應(yīng)的.meta文件時(shí)，所有對(duì)資源文件中的Object的引用都會(huì)丟失。
1.4. 復(fù)合資源和導(dǎo)入器
資源導(dǎo)入器
正如前面深入理解資源與對(duì)象中所說的一樣，不能被Unity直接支持的資源類型必須經(jīng)過導(dǎo)入才可以使用——使用資源導(dǎo)入器來完成。這些導(dǎo)入器是自動(dòng)調(diào)用的，您也可以使用AssetImporter在腳本中調(diào)用API及其子類。例如，在導(dǎo)入單獨(dú)的紋理資源例如PNG和JPG時(shí)，TextureImporter API提供了導(dǎo)入時(shí)要使用的相關(guān)設(shè)置的訪問。
導(dǎo)入過程最終的產(chǎn)物是一系列UnityEngine.Object。在Unity編輯器中，這些對(duì)象會(huì)具體表現(xiàn)為父資源下的多個(gè)子資源，例如作為Sprite Atlas導(dǎo)入的紋理材質(zhì)，其下屬會(huì)有多個(gè)嵌套的Sprite。每一個(gè)對(duì)象都會(huì)使用相同的文件GUID，因?yàn)樗鼈兊脑磾?shù)據(jù)都存儲(chǔ)在同一個(gè)資源文件中。它們?cè)诩y理資源中的具體區(qū)分工作則使用本地ID來完成。
Library文件夾
導(dǎo)入過程中會(huì)將源資源轉(zhuǎn)換為匹配Unity編輯器中選定的目標(biāo)平臺(tái)的格式。導(dǎo)入過程可能會(huì)牽涉一些重量級(jí)操作，例如紋理壓縮。如果每次打開Unity編輯器時(shí)都要執(zhí)行這些操作，那效率就太低了。
為了解決這一問題，我們將資源導(dǎo)入的結(jié)果緩存在Library文件夾中。具體就是，導(dǎo)入進(jìn)程的結(jié)果將會(huì)存儲(chǔ)在以資源文件GUID頭兩位作為名稱的文件夾中。這些文件夾位于 Library/metadata/ 目錄下。各個(gè)不同的對(duì)象會(huì)被序列化后存儲(chǔ)在一個(gè)二進(jìn)制文件中，文件使用資源文件的GUID來命名。
這對(duì)所有資源都是一樣的，不僅僅是非原生資源。只不過Unity原生支持的資源不需要對(duì)其進(jìn)行轉(zhuǎn)換或序列化處理。
上半部分的內(nèi)容主要介紹了資源（Asset）和對(duì)象（UnityEngine.Objects）的區(qū)別，以及文件GUID和本地ID二者的關(guān)聯(lián)和差異。下半部分將為大家介紹第三種ID：對(duì)象的實(shí)例ID，并看看這些ID對(duì)資源在內(nèi)存與顯存中的加載和卸載分別有著怎樣的作用。
Footnotes(腳注)
在文件中，本地ID是唯一的。即在一個(gè)資源文件中，里面包含的本地ID都是不重復(fù)的。
在內(nèi)部，這種緩存被稱為PersistentManager。實(shí)際的轉(zhuǎn)換工作在在Unity的C++ Remapper類中進(jìn)行，Remapper類沒有提供任何C# API調(diào)用接口。
運(yùn)行時(shí)創(chuàng)建資源的示例是在腳本中創(chuàng)建Texture2D對(duì)象：var myTexture = new Texture2D(1027, 768);
程序運(yùn)行時(shí)對(duì)象并沒有被卸載卻被從內(nèi)存中移除的情況通常會(huì)發(fā)生在Unity失去了對(duì)圖形內(nèi)容的控制的時(shí)候。例如，當(dāng)手機(jī)應(yīng)用被掛起并被強(qiáng)制在后臺(tái)運(yùn)行。這種情況下，手機(jī)操作系統(tǒng)通常會(huì)將所有的圖形資源從GPU顯存中強(qiáng)行卸載。之后APP再回到前臺(tái)運(yùn)行時(shí)，Unity不得不重新向GPU上傳需要的材質(zhì)、著色器和網(wǎng)格數(shù)據(jù)，以便恢復(fù)場(chǎng)景的正常渲染。
1.5. 序列化和實(shí)例
實(shí)例ID
盡管文件GUID和本地ID已準(zhǔn)備妥當(dāng)，它們可以強(qiáng)有力地維護(hù)資源之間的關(guān)系，但還有一個(gè)問題，GUID比較效率低下，我們需要為運(yùn)行時(shí)準(zhǔn)備一個(gè)效率更高的解決方案。Unity在內(nèi)部維護(hù)著一個(gè)緩存表(2)，負(fù)責(zé)將文件GUID和本地ID轉(zhuǎn)換成為整數(shù)數(shù)值，這個(gè)數(shù)值在本次會(huì)話中是唯一的，稱作實(shí)例ID。實(shí)例ID會(huì)簡(jiǎn)單地以單調(diào)遞增的方式分配給緩存中新注冊(cè)的對(duì)象。
緩存負(fù)責(zé)維護(hù)實(shí)例ID與文件GUID和本地ID定義的對(duì)象源數(shù)據(jù)位置以及對(duì)象在內(nèi)存中的地址（如果存在）的映射。 這樣Unity就能夠強(qiáng)而有力地保證它們互相之間的引用關(guān)系。通過解析實(shí)例ID，我們能夠快速找到并返回ID對(duì)應(yīng)的已載入實(shí)例。如果目標(biāo)沒有被加載，則Unity會(huì)通過文件GUID和本地ID解析獲得對(duì)象的源數(shù)據(jù)，實(shí)時(shí)載入對(duì)象。
啟動(dòng)時(shí)，實(shí)例ID緩存與所有工程內(nèi)建的對(duì)象（例如在場(chǎng)景中被引用），以及Resources文件夾下的所有對(duì)象，都會(huì)一起被初始化。如果在運(yùn)行時(shí)(3)導(dǎo)入了新的資源，或從AssetBundle中載入了新的對(duì)象，緩存會(huì)被更新并為這些對(duì)象添加相應(yīng)條目。實(shí)例ID僅在失效時(shí)才會(huì)被從緩存中移除，當(dāng)提供了指定文件GUID和本地ID的AssetBundle被卸載時(shí)就會(huì)產(chǎn)生移除操作。
卸載AssetBundle會(huì)使實(shí)例ID失效，實(shí)例ID與其文件GUID和本地ID之間的映射會(huì)被刪除以便節(jié)省內(nèi)存。重新載入AssetBundle后，載入的每個(gè)對(duì)象都會(huì)獲得一個(gè)新的實(shí)例ID。
關(guān)于AssetBundle隱式卸載的更深層次討論，參考AssetBundle Usage Patterns中的管理已加載資源章節(jié)。
注意事項(xiàng)(IOS上掛起狀態(tài))
注意在某些平臺(tái)上，有一些系統(tǒng)事件會(huì)使得對(duì)象在內(nèi)存中被強(qiáng)行卸載。例如iOS平臺(tái)上，當(dāng)一個(gè)app處于掛起狀態(tài)時(shí)，圖形資源就會(huì)從顯存中卸載。如果這些對(duì)象都來自于一個(gè)已被卸除的AssetBundle時(shí)，Unity將無法再次從源數(shù)據(jù)處加載這些對(duì)象。任何已有的對(duì)這些對(duì)象的引用都會(huì)失效。這個(gè)例子中，導(dǎo)致的后果就是出現(xiàn)網(wǎng)格不可見（丟失），或模型的紋理和材質(zhì)呈現(xiàn)為洋紅色（Shader丟失）。
提示
提示：在運(yùn)行時(shí)，對(duì)上述控制流程的描述并非完全準(zhǔn)確。文件GUID和本地ID的比較操作在載入負(fù)擔(dān)較重時(shí)的效率也會(huì)下降。構(gòu)建Unity工程時(shí)，文件GUID和本地ID，確切地說會(huì)被映射到一種更簡(jiǎn)單的格式中。不過概念還是大致相同的，在考慮“運(yùn)行時(shí)”的時(shí)候以文件GUID和本地ID的工作方式為思路還是有一些參考意義的。
這也是在運(yùn)行時(shí)資源的文件GUID無法被調(diào)取的原因。
1.6.MonoScripts
理解MonoBehaviour很重要的一點(diǎn)是知道它有一個(gè)對(duì)MonoScript的引用。MonoScript的用途非常簡(jiǎn)單，里面包括了定位某個(gè)具體的編程類所需要的信息。這兩種對(duì)象都沒有程序類的可執(zhí)行代碼。
一個(gè)MonoScript含有三個(gè)字符串：程序庫名稱，類名稱，命名空間。
程序庫(dll)
構(gòu)建工程時(shí)，Unity會(huì)收集Assets文件夾中獨(dú)立的腳本文件并將它們編譯，組成一個(gè)Mono程序庫。要特別說明的是，Unity會(huì)將Assets目錄中的語言分開編譯，Assets/Plugins目錄中的腳本同理。Plugins子目錄之外的C#腳本會(huì)放在Assembly-CSharp.dll中。而Plugins及其子目錄中的腳本則放置在Assembly-CSharp-firstpass.dll中，以此類推。
這些程序庫（加上預(yù)編譯好的DLL程序庫）將被包含在最終構(gòu)建的Unity應(yīng)用程序中。這些程序庫都會(huì)被MonoScript所引用。與其他類型的資源不同，Unity應(yīng)用程序中的所有應(yīng)用程序都會(huì)在程序第一次啟動(dòng)時(shí)被加載。
MonoScript就是為什么AssetBundle（或一個(gè)場(chǎng)景，一個(gè)Prefab）中的MonoBehaviour組件不包含有任何實(shí)際可執(zhí)行代碼的原因。這樣就可以讓不同的MonoBehaviour引用某個(gè)共享類，即便這些MonoBehaviour不在同一個(gè)AssetBundle中。
1.7.資源（Resource）生命周期
UnityEngine.Objects從內(nèi)存中加載或卸載的時(shí)間點(diǎn)是定義好的。為了縮短程序載入時(shí)間，管理應(yīng)用程序的內(nèi)存足跡，理解UnityEinge.Object的資源生命周期是很重要的。
加載UnityEngine.Object的兩種方式
有兩種加載UnityEngine.Object的方式：自動(dòng)加載或外部加載。
當(dāng)對(duì)象的實(shí)例ID與對(duì)象本身解引用，對(duì)象當(dāng)前未被加載到內(nèi)存中，而且可以定位到對(duì)象的源數(shù)據(jù)，此時(shí)對(duì)象會(huì)被自動(dòng)加載。對(duì)象也可以外部加載，通過在腳本中創(chuàng)建對(duì)象或調(diào)用資源加載API來載入對(duì)象（例如AssetBundle.LoadAsset）。
對(duì)象加載后，Unity會(huì)嘗試修復(fù)任何可能存在的引用關(guān)系，通過將每個(gè)引用的文件GUID和本地ID轉(zhuǎn)化成為實(shí)例ID的方式。
一旦對(duì)象的實(shí)例ID被解引用且滿足以下兩個(gè)標(biāo)準(zhǔn)時(shí)，對(duì)象會(huì)被強(qiáng)制加載：
實(shí)例ID引用了一個(gè)沒有被加載的對(duì)象。
實(shí)例ID在緩存中存在對(duì)應(yīng)的有效GUID和本地ID。
這種情況通常會(huì)在引用被加載并解析后很短的一段時(shí)間內(nèi)發(fā)生。
如果文件GUID和本地ID沒有實(shí)例ID，或一個(gè)已卸載對(duì)象的實(shí)例ID引用了非法的文件GUID和本地ID，則引用本身會(huì)被保留，但實(shí)際對(duì)象不會(huì)被加載。在Unity編輯器中表現(xiàn)為“（空）”引用。在運(yùn)行的應(yīng)用程序中，或場(chǎng)景視圖里，“（空）”對(duì)象通常以多種方式表示，這取決于丟失對(duì)象的類型：網(wǎng)格會(huì)變得不可見，紋理呈現(xiàn)為洋紅色等等。
對(duì)象被卸載的三種情況
對(duì)象被卸載有以下三種情況：
閑置資源清理進(jìn)程開始后，一些對(duì)象會(huì)被自動(dòng)卸載。該過程通常會(huì)在切換場(chǎng)景切不保留原場(chǎng)景（例如調(diào)用了非疊加的場(chǎng)景切換API Application.LoadLevel），或者腳本中調(diào)用了Resources.UnloadUnusedAssets時(shí)自動(dòng)觸發(fā)。該進(jìn)程僅卸載沒有被引用的對(duì)象：對(duì)象僅在Mono變量不存在對(duì)其的引用，且不存在引用該對(duì)象的其他活動(dòng)對(duì)象時(shí)被卸載。
Resources目錄中的對(duì)象可以通過調(diào)用Resources.UnloadAsset API主動(dòng)卸載。卸載后對(duì)象的實(shí)例ID會(huì)保持可用狀態(tài)，對(duì)文件GUID和本地ID的條目會(huì)被保留且仍然有效。如果有Mono變量或其他有指向該對(duì)象的活動(dòng)對(duì)象引用了被Resources.UnloadAsset卸載的對(duì)象，則該對(duì)象會(huì)在任意有效的引用被解引用時(shí)立刻重新加載。
調(diào)用AssetBundle.Unload(true) API時(shí)，加載自AssetBundle的對(duì)象會(huì)被立刻自動(dòng)卸載。該操作會(huì)釋放對(duì)象實(shí)例ID的文件GUID和本地ID引用，任何對(duì)卸載對(duì)象的引用都會(huì)變成“（空）”引用。C#腳本中，任何試圖訪問已卸載對(duì)象上的方法和屬性都會(huì)導(dǎo)致拋出空引用異常（NullReferenceException）。
如果調(diào)用了AssetBundle.Unload(false)，被卸載的AssetBundle中仍然處于激活狀態(tài)的對(duì)象不會(huì)被回收，但Unity會(huì)釋放其實(shí)例ID的文件GUID和本地GUID引用。之后假如它們被從內(nèi)存中卸載，只剩下對(duì)這些被卸載對(duì)象額引用，Unity無法再次重新加載這些對(duì)象(4)。
1.8.載入大型結(jié)構(gòu)樹（Hierarchies）
當(dāng)序列化含有大量Unity游戲?qū)ο蟮慕Y(jié)構(gòu)樹時(shí)（例如序列化Prefab），要記住一點(diǎn)，即整個(gè)結(jié)構(gòu)樹都會(huì)被完全序列化。這就是說，結(jié)構(gòu)樹中的每一個(gè)游戲?qū)ο蠛徒M件都會(huì)在序列化數(shù)據(jù)中單獨(dú)表示。這會(huì)對(duì)游戲?qū)ο蠼Y(jié)構(gòu)的載入與實(shí)例化的耗時(shí)帶來有趣的影響。
假設(shè)一個(gè)代碼塊實(shí)例化了一定數(shù)量的游戲?qū)ο螅Y(jié)構(gòu)樹非常龐大的單個(gè)Prefab的實(shí)例化，會(huì)比分別實(shí)例化結(jié)構(gòu)樹的多個(gè)模塊然后運(yùn)行時(shí)組合花費(fèi)更多的CPU時(shí)間。
深度分析底層數(shù)據(jù)后發(fā)現(xiàn)，實(shí)例化和喚醒游戲?qū)ο笏ㄙM(fèi)的CPU時(shí)間在各種情況下大致是相同的，單個(gè)獨(dú)立的Prefab的實(shí)例化和喚醒僅需非常少量的CPU時(shí)間（因?yàn)椴恍枰猼ranmpolining和SendTransformChanged回調(diào)）。但是，這些細(xì)小的時(shí)間節(jié)省相對(duì)于花在讀取和序列化數(shù)據(jù)上的時(shí)間是很不值的。
正如之前提到的，序列化單獨(dú)的Prefab時(shí)，每個(gè)游戲?qū)ο蠛推浣M件都會(huì)被分開序列化——即便數(shù)據(jù)是重復(fù)的。一個(gè)有30個(gè)獨(dú)立元素的UI界面中，Unity會(huì)為這些元素序列化30次，這就會(huì)產(chǎn)生大量的序列化數(shù)據(jù)。載入時(shí)，所有30個(gè)重復(fù)元素的游戲?qū)ο蠛徒M件在被轉(zhuǎn)化為新實(shí)例對(duì)象之前都需要從硬盤中進(jìn)行讀取。正是這里討論的讀取時(shí)間決定了實(shí)例化大型Prefab的性能花銷。
Unity支持嵌套Prefab之后，對(duì)于有載入大型結(jié)構(gòu)體游戲?qū)ο笮枨蟮墓こ潭裕霚p少這類工程的載入時(shí)間，可以考慮將大型Prefab中的可重用元素分開存儲(chǔ)到不同的Prefab中，并在運(yùn)行時(shí)對(duì)它們進(jìn)行實(shí)例化，而不是完全依靠Unity的序列化和Prefab系統(tǒng)。
Footnotes(腳注)
在文件中，本地ID是唯一的。即在一個(gè)資源文件中，里面包含的本地ID都是不重復(fù)的。
在內(nèi)部，這種緩存被稱為PersistentManager。實(shí)際的轉(zhuǎn)換工作在在Unity的C++ Remapper類中進(jìn)行，Remapper類沒有提供任何C# API調(diào)用接口。
運(yùn)行時(shí)創(chuàng)建資源的示例是在腳本中創(chuàng)建Texture2D對(duì)象：var myTexture = new Texture2D(1027, 768);
程序運(yùn)行時(shí)對(duì)象并沒有被卸載卻被從內(nèi)存中移除的情況通常會(huì)發(fā)生在Unity失去了對(duì)圖形內(nèi)容的控制的時(shí)候。例如，當(dāng)手機(jī)應(yīng)用被掛起并被強(qiáng)制在后臺(tái)運(yùn)行。這種情況下，手機(jī)操作系統(tǒng)通常會(huì)將所有的圖形資源從GPU顯存中強(qiáng)行卸載。之后APP再回到前臺(tái)運(yùn)行時(shí)，Unity不得不重新向GPU上傳需要的材質(zhì)、著色器和網(wǎng)格數(shù)據(jù)，以便恢復(fù)場(chǎng)景的正常渲染。
到此整個(gè)Unity內(nèi)部資源管理與對(duì)象引用及序列化的內(nèi)容就結(jié)束了，希望看完本文的你對(duì)如何合理分配Unity項(xiàng)目結(jié)構(gòu)都有了比較清晰的概念。
更多精彩，盡在匯寶盆：http://www.594ljc.cn/resource
譯注：除非特別說明，下文中所有的“資源”均指代“Asset”。
本文內(nèi)容是理解在Unity中如何高效加載和卸載資源的基礎(chǔ)。正確的資源管理對(duì)縮短加載時(shí)間并減少內(nèi)存占用來說至關(guān)重要。今天先為大家分享上半部分內(nèi)容。
1.1. 深入理解資源和對(duì)象
在理解Unity如何確保萬無一失地管理數(shù)據(jù)之前，首先要知道Unity是如何識(shí)別并序列化數(shù)據(jù)的。首先第一點(diǎn)，要正確區(qū)分資源（Asset）和對(duì)象（UnityEngine.Objects）。
Asset
資源（Asset）是硬盤中的文件，存儲(chǔ)在Unity工程的Assets文件夾內(nèi)。例如，紋理（Texture），材質(zhì)（Material）和FBX文件等，它們都是資源。一些資源的數(shù)據(jù)格式是Unity原生支持的，例如材質(zhì)。有些資源則需要轉(zhuǎn)換為原生的數(shù)據(jù)格式后才能被Unity使用，例如FBX文件。
UnityEngine.Object
UnityEngine.Object，或者說以大寫字母O開頭的Object——對(duì)象，代表序列化數(shù)據(jù)的集合，表示某個(gè)資源的具體實(shí)例。它可以是Unity引擎使用的任何類型的資源，例如網(wǎng)格，Sprite，音頻剪輯或動(dòng)畫剪輯。所有的對(duì)象（Object）都是UnityEngine.Object基類的子類。
特殊的Object類型
幾乎所有的對(duì)象（Object）類型都是內(nèi)建的，其中有兩種比較特殊的類型。
ScriptableObject為開發(fā)者提供了一套便捷的系統(tǒng)，供開發(fā)者自定義數(shù)據(jù)類型。這些類型可以被Unity直接序列化或反序列化，并在Unity編輯器的檢視器窗口中進(jìn)行操作。
MonoBehaviour提供了鏈接MonoScript的容器。MonoScript是一種內(nèi)部數(shù)據(jù)類型，Unity用它保存對(duì)某個(gè)特定程序集和命名空間中特定腳本類的引用，MonoScript本身不包含任何實(shí)際的可執(zhí)行代碼。
一對(duì)多關(guān)系
資源（Asset）與對(duì)象（Object）是一種一對(duì)多的關(guān)系，即一個(gè)資源文件可能會(huì)包括多個(gè)Object。
1.2. 對(duì)象之間的引用
所有UnityEngine.Objects都可以引用其他的UnityEngine.Objects。這里“其他的Object”可能存在于相同的資源文件中，或需要從其他資源文件導(dǎo)入。例如，一個(gè)材質(zhì)Object通常有一個(gè)或多個(gè)紋理Object的引用。這些紋理Object一般是從一個(gè)或多個(gè)紋理資源文件中導(dǎo)入的（例如PNG或JPG文件）。
序列化后，這些引用由兩部分?jǐn)?shù)據(jù)組成：文件GUID和本地ID。文件GUID用于識(shí)別資源（Asset）文件中目標(biāo)資源（Resource）的存儲(chǔ)位置。而本地唯一(1)的ID負(fù)責(zé)識(shí)別單個(gè)資源文件中的Object，因?yàn)橐粋€(gè)資源文件可能會(huì)包含多個(gè)Object。
文件GUID(.meta)
文件GUID存儲(chǔ)于.meta文件中。Unity會(huì)在首次導(dǎo)入資源文件時(shí)生成.meta文件，并和資源文件一起存儲(chǔ)在相同的目錄中。
上述的識(shí)別和引用系統(tǒng)可以使用文本編輯器查看：
創(chuàng)建一個(gè)全新的Unity工程，更改編輯器設(shè)置，將Edit - Project Settings - Editor中的Version Control設(shè)為Visible Meta Files，并將Asset Serialization設(shè)為文本。
新建材質(zhì)并向工程中導(dǎo)入一個(gè)紋理。將材質(zhì)賦給場(chǎng)景中的一個(gè)立方體，保存場(chǎng)景。
使用文本編輯器打開這個(gè)材質(zhì)對(duì)應(yīng)的.meta文件。在文件頂端附近會(huì)有一行被標(biāo)示為“guid”，該行定義了材質(zhì)資源文件的文件GUID。
1
本地ID(具體文件)
如需查看本地ID，使用文本編輯器打開材質(zhì)文件，材質(zhì)Object的定義大致如下：
2
在上面的例子中，前面有&符號(hào)的數(shù)字就是材質(zhì)的本地ID。如果這個(gè)材質(zhì)的Object位于一個(gè)文件GUID為“abcdefg”的資源文件中，則該材質(zhì)Object的唯一識(shí)別符就是文件GUID“abcdefg”和本地ID“2100000”的組合。
1.3. 為什么要用文件GUID和本地ID？
工作流程
在Unity中，為什么要使用文件GUID和本地ID這套系統(tǒng)呢？答案是為穩(wěn)定服務(wù)，也是為了提供一套靈活的、無關(guān)具體平臺(tái)的工作流程。文件GUID提供了文件存儲(chǔ)位置的抽象，這樣一個(gè)文件GUID就對(duì)應(yīng)一個(gè)具體的文件，這個(gè)具體的文件存儲(chǔ)在什么位置也就無關(guān)緊要了。因此我們才能隨意移動(dòng)這個(gè)文件而不破壞所有相關(guān)Object對(duì)這個(gè)文件的引用。
任何資源（Asset）文件中都可能含有（或通過導(dǎo)入產(chǎn)生）多個(gè)UnityEngine.Object資源（Resource），因此需要一個(gè)本地ID來對(duì)其中的Object做明確區(qū)分。
如果與資源文件相關(guān)聯(lián)的文件GUID丟失，則所有對(duì)該資源文件中的Object的引用都會(huì)被破壞。這就是必須保證.meta文件具有和資源文件相同的文件名并存儲(chǔ)在同一目錄下的原因。注意Unity會(huì)重新生成丟失或被刪除的.meta文件。
Unity編輯器維護(hù)映射表
Unity編輯器負(fù)責(zé)維護(hù)一張文件路徑與文件GUID之間關(guān)系的映射表。只要資源文件被讀取或?qū)?，這個(gè)映射關(guān)系就會(huì)被建立，映射會(huì)將資源的具體位置和資源的文件GUID進(jìn)行關(guān)聯(lián)。Unity編輯器處于打開狀態(tài)時(shí)，假設(shè)一個(gè)文件的.meta意外丟失，并且該資源文件的路徑?jīng)]有改變，編輯器可以保證這個(gè)資源會(huì)被分配到相同的文件GUID。
如果在Unity編輯器處于關(guān)閉狀態(tài)時(shí)丟失.meta文件，或資源文件被移動(dòng)但沒有移動(dòng)對(duì)應(yīng)的.meta文件時(shí)，所有對(duì)資源文件中的Object的引用都會(huì)丟失。
1.4. 復(fù)合資源和導(dǎo)入器
資源導(dǎo)入器
正如前面深入理解資源與對(duì)象中所說的一樣，不能被Unity直接支持的資源類型必須經(jīng)過導(dǎo)入才可以使用——使用資源導(dǎo)入器來完成。這些導(dǎo)入器是自動(dòng)調(diào)用的，您也可以使用AssetImporter在腳本中調(diào)用API及其子類。例如，在導(dǎo)入單獨(dú)的紋理資源例如PNG和JPG時(shí)，TextureImporter API提供了導(dǎo)入時(shí)要使用的相關(guān)設(shè)置的訪問。
導(dǎo)入過程最終的產(chǎn)物是一系列UnityEngine.Object。在Unity編輯器中，這些對(duì)象會(huì)具體表現(xiàn)為父資源下的多個(gè)子資源，例如作為Sprite Atlas導(dǎo)入的紋理材質(zhì)，其下屬會(huì)有多個(gè)嵌套的Sprite。每一個(gè)對(duì)象都會(huì)使用相同的文件GUID，因?yàn)樗鼈兊脑磾?shù)據(jù)都存儲(chǔ)在同一個(gè)資源文件中。它們?cè)诩y理資源中的具體區(qū)分工作則使用本地ID來完成。
Library文件夾
導(dǎo)入過程中會(huì)將源資源轉(zhuǎn)換為匹配Unity編輯器中選定的目標(biāo)平臺(tái)的格式。導(dǎo)入過程可能會(huì)牽涉一些重量級(jí)操作，例如紋理壓縮。如果每次打開Unity編輯器時(shí)都要執(zhí)行這些操作，那效率就太低了。
為了解決這一問題，我們將資源導(dǎo)入的結(jié)果緩存在Library文件夾中。具體就是，導(dǎo)入進(jìn)程的結(jié)果將會(huì)存儲(chǔ)在以資源文件GUID頭兩位作為名稱的文件夾中。這些文件夾位于 Library/metadata/ 目錄下。各個(gè)不同的對(duì)象會(huì)被序列化后存儲(chǔ)在一個(gè)二進(jìn)制文件中，文件使用資源文件的GUID來命名。
這對(duì)所有資源都是一樣的，不僅僅是非原生資源。只不過Unity原生支持的資源不需要對(duì)其進(jìn)行轉(zhuǎn)換或序列化處理。
上半部分的內(nèi)容主要介紹了資源（Asset）和對(duì)象（UnityEngine.Objects）的區(qū)別，以及文件GUID和本地ID二者的關(guān)聯(lián)和差異。下半部分將為大家介紹第三種ID：對(duì)象的實(shí)例ID，并看看這些ID對(duì)資源在內(nèi)存與顯存中的加載和卸載分別有著怎樣的作用。
Footnotes(腳注)
在文件中，本地ID是唯一的。即在一個(gè)資源文件中，里面包含的本地ID都是不重復(fù)的。
在內(nèi)部，這種緩存被稱為PersistentManager。實(shí)際的轉(zhuǎn)換工作在在Unity的C++ Remapper類中進(jìn)行，Remapper類沒有提供任何C# API調(diào)用接口。
運(yùn)行時(shí)創(chuàng)建資源的示例是在腳本中創(chuàng)建Texture2D對(duì)象：var myTexture = new Texture2D(1027, 768);
程序運(yùn)行時(shí)對(duì)象并沒有被卸載卻被從內(nèi)存中移除的情況通常會(huì)發(fā)生在Unity失去了對(duì)圖形內(nèi)容的控制的時(shí)候。例如，當(dāng)手機(jī)應(yīng)用被掛起并被強(qiáng)制在后臺(tái)運(yùn)行。這種情況下，手機(jī)操作系統(tǒng)通常會(huì)將所有的圖形資源從GPU顯存中強(qiáng)行卸載。之后APP再回到前臺(tái)運(yùn)行時(shí)，Unity不得不重新向GPU上傳需要的材質(zhì)、著色器和網(wǎng)格數(shù)據(jù)，以便恢復(fù)場(chǎng)景的正常渲染。
1.5. 序列化和實(shí)例
實(shí)例ID
盡管文件GUID和本地ID已準(zhǔn)備妥當(dāng)，它們可以強(qiáng)有力地維護(hù)資源之間的關(guān)系，但還有一個(gè)問題，GUID比較效率低下，我們需要為運(yùn)行時(shí)準(zhǔn)備一個(gè)效率更高的解決方案。Unity在內(nèi)部維護(hù)著一個(gè)緩存表(2)，負(fù)責(zé)將文件GUID和本地ID轉(zhuǎn)換成為整數(shù)數(shù)值，這個(gè)數(shù)值在本次會(huì)話中是唯一的，稱作實(shí)例ID。實(shí)例ID會(huì)簡(jiǎn)單地以單調(diào)遞增的方式分配給緩存中新注冊(cè)的對(duì)象。
緩存負(fù)責(zé)維護(hù)實(shí)例ID與文件GUID和本地ID定義的對(duì)象源數(shù)據(jù)位置以及對(duì)象在內(nèi)存中的地址（如果存在）的映射。 這樣Unity就能夠強(qiáng)而有力地保證它們互相之間的引用關(guān)系。通過解析實(shí)例ID，我們能夠快速找到并返回ID對(duì)應(yīng)的已載入實(shí)例。如果目標(biāo)沒有被加載，則Unity會(huì)通過文件GUID和本地ID解析獲得對(duì)象的源數(shù)據(jù)，實(shí)時(shí)載入對(duì)象。
啟動(dòng)時(shí)，實(shí)例ID緩存與所有工程內(nèi)建的對(duì)象（例如在場(chǎng)景中被引用），以及Resources文件夾下的所有對(duì)象，都會(huì)一起被初始化。如果在運(yùn)行時(shí)(3)導(dǎo)入了新的資源，或從AssetBundle中載入了新的對(duì)象，緩存會(huì)被更新并為這些對(duì)象添加相應(yīng)條目。實(shí)例ID僅在失效時(shí)才會(huì)被從緩存中移除，當(dāng)提供了指定文件GUID和本地ID的AssetBundle被卸載時(shí)就會(huì)產(chǎn)生移除操作。
卸載AssetBundle會(huì)使實(shí)例ID失效，實(shí)例ID與其文件GUID和本地ID之間的映射會(huì)被刪除以便節(jié)省內(nèi)存。重新載入AssetBundle后，載入的每個(gè)對(duì)象都會(huì)獲得一個(gè)新的實(shí)例ID。
關(guān)于AssetBundle隱式卸載的更深層次討論，參考AssetBundle Usage Patterns中的管理已加載資源章節(jié)。
注意事項(xiàng)(IOS上掛起狀態(tài))
注意在某些平臺(tái)上，有一些系統(tǒng)事件會(huì)使得對(duì)象在內(nèi)存中被強(qiáng)行卸載。例如iOS平臺(tái)上，當(dāng)一個(gè)app處于掛起狀態(tài)時(shí)，圖形資源就會(huì)從顯存中卸載。如果這些對(duì)象都來自于一個(gè)已被卸除的AssetBundle時(shí)，Unity將無法再次從源數(shù)據(jù)處加載這些對(duì)象。任何已有的對(duì)這些對(duì)象的引用都會(huì)失效。這個(gè)例子中，導(dǎo)致的后果就是出現(xiàn)網(wǎng)格不可見（丟失），或模型的紋理和材質(zhì)呈現(xiàn)為洋紅色（Shader丟失）。
提示
提示：在運(yùn)行時(shí)，對(duì)上述控制流程的描述并非完全準(zhǔn)確。文件GUID和本地ID的比較操作在載入負(fù)擔(dān)較重時(shí)的效率也會(huì)下降。構(gòu)建Unity工程時(shí)，文件GUID和本地ID，確切地說會(huì)被映射到一種更簡(jiǎn)單的格式中。不過概念還是大致相同的，在考慮“運(yùn)行時(shí)”的時(shí)候以文件GUID和本地ID的工作方式為思路還是有一些參考意義的。
這也是在運(yùn)行時(shí)資源的文件GUID無法被調(diào)取的原因。
1.6.MonoScripts
理解MonoBehaviour很重要的一點(diǎn)是知道它有一個(gè)對(duì)MonoScript的引用。MonoScript的用途非常簡(jiǎn)單，里面包括了定位某個(gè)具體的編程類所需要的信息。這兩種對(duì)象都沒有程序類的可執(zhí)行代碼。
一個(gè)MonoScript含有三個(gè)字符串：程序庫名稱，類名稱，命名空間。
程序庫(dll)
構(gòu)建工程時(shí)，Unity會(huì)收集Assets文件夾中獨(dú)立的腳本文件并將它們編譯，組成一個(gè)Mono程序庫。要特別說明的是，Unity會(huì)將Assets目錄中的語言分開編譯，Assets/Plugins目錄中的腳本同理。Plugins子目錄之外的C#腳本會(huì)放在Assembly-CSharp.dll中。而Plugins及其子目錄中的腳本則放置在Assembly-CSharp-firstpass.dll中，以此類推。
這些程序庫（加上預(yù)編譯好的DLL程序庫）將被包含在最終構(gòu)建的Unity應(yīng)用程序中。這些程序庫都會(huì)被MonoScript所引用。與其他類型的資源不同，Unity應(yīng)用程序中的所有應(yīng)用程序都會(huì)在程序第一次啟動(dòng)時(shí)被加載。
MonoScript就是為什么AssetBundle（或一個(gè)場(chǎng)景，一個(gè)Prefab）中的MonoBehaviour組件不包含有任何實(shí)際可執(zhí)行代碼的原因。這樣就可以讓不同的MonoBehaviour引用某個(gè)共享類，即便這些MonoBehaviour不在同一個(gè)AssetBundle中。
1.7.資源（Resource）生命周期
UnityEngine.Objects從內(nèi)存中加載或卸載的時(shí)間點(diǎn)是定義好的。為了縮短程序載入時(shí)間，管理應(yīng)用程序的內(nèi)存足跡，理解UnityEinge.Object的資源生命周期是很重要的。
加載UnityEngine.Object的兩種方式
有兩種加載UnityEngine.Object的方式：自動(dòng)加載或外部加載。
當(dāng)對(duì)象的實(shí)例ID與對(duì)象本身解引用，對(duì)象當(dāng)前未被加載到內(nèi)存中，而且可以定位到對(duì)象的源數(shù)據(jù)，此時(shí)對(duì)象會(huì)被自動(dòng)加載。對(duì)象也可以外部加載，通過在腳本中創(chuàng)建對(duì)象或調(diào)用資源加載API來載入對(duì)象（例如AssetBundle.LoadAsset）。
對(duì)象加載后，Unity會(huì)嘗試修復(fù)任何可能存在的引用關(guān)系，通過將每個(gè)引用的文件GUID和本地ID轉(zhuǎn)化成為實(shí)例ID的方式。
一旦對(duì)象的實(shí)例ID被解引用且滿足以下兩個(gè)標(biāo)準(zhǔn)時(shí)，對(duì)象會(huì)被強(qiáng)制加載：
實(shí)例ID引用了一個(gè)沒有被加載的對(duì)象。
實(shí)例ID在緩存中存在對(duì)應(yīng)的有效GUID和本地ID。
這種情況通常會(huì)在引用被加載并解析后很短的一段時(shí)間內(nèi)發(fā)生。
如果文件GUID和本地ID沒有實(shí)例ID，或一個(gè)已卸載對(duì)象的實(shí)例ID引用了非法的文件GUID和本地ID，則引用本身會(huì)被保留，但實(shí)際對(duì)象不會(huì)被加載。在Unity編輯器中表現(xiàn)為“（空）”引用。在運(yùn)行的應(yīng)用程序中，或場(chǎng)景視圖里，“（空）”對(duì)象通常以多種方式表示，這取決于丟失對(duì)象的類型：網(wǎng)格會(huì)變得不可見，紋理呈現(xiàn)為洋紅色等等。
對(duì)象被卸載的三種情況
對(duì)象被卸載有以下三種情況：
閑置資源清理進(jìn)程開始后，一些對(duì)象會(huì)被自動(dòng)卸載。該過程通常會(huì)在切換場(chǎng)景切不保留原場(chǎng)景（例如調(diào)用了非疊加的場(chǎng)景切換API Application.LoadLevel），或者腳本中調(diào)用了Resources.UnloadUnusedAssets時(shí)自動(dòng)觸發(fā)。該進(jìn)程僅卸載沒有被引用的對(duì)象：對(duì)象僅在Mono變量不存在對(duì)其的引用，且不存在引用該對(duì)象的其他活動(dòng)對(duì)象時(shí)被卸載。
Resources目錄中的對(duì)象可以通過調(diào)用Resources.UnloadAsset API主動(dòng)卸載。卸載后對(duì)象的實(shí)例ID會(huì)保持可用狀態(tài)，對(duì)文件GUID和本地ID的條目會(huì)被保留且仍然有效。如果有Mono變量或其他有指向該對(duì)象的活動(dòng)對(duì)象引用了被Resources.UnloadAsset卸載的對(duì)象，則該對(duì)象會(huì)在任意有效的引用被解引用時(shí)立刻重新加載。
調(diào)用AssetBundle.Unload(true) API時(shí)，加載自AssetBundle的對(duì)象會(huì)被立刻自動(dòng)卸載。該操作會(huì)釋放對(duì)象實(shí)例ID的文件GUID和本地ID引用，任何對(duì)卸載對(duì)象的引用都會(huì)變成“（空）”引用。C#腳本中，任何試圖訪問已卸載對(duì)象上的方法和屬性都會(huì)導(dǎo)致拋出空引用異常（NullReferenceException）。
如果調(diào)用了AssetBundle.Unload(false)，被卸載的AssetBundle中仍然處于激活狀態(tài)的對(duì)象不會(huì)被回收，但Unity會(huì)釋放其實(shí)例ID的文件GUID和本地GUID引用。之后假如它們被從內(nèi)存中卸載，只剩下對(duì)這些被卸載對(duì)象額引用，Unity無法再次重新加載這些對(duì)象(4)。
1.8.載入大型結(jié)構(gòu)樹（Hierarchies）
當(dāng)序列化含有大量Unity游戲?qū)ο蟮慕Y(jié)構(gòu)樹時(shí)（例如序列化Prefab），要記住一點(diǎn)，即整個(gè)結(jié)構(gòu)樹都會(huì)被完全序列化。這就是說，結(jié)構(gòu)樹中的每一個(gè)游戲?qū)ο蠛徒M件都會(huì)在序列化數(shù)據(jù)中單獨(dú)表示。這會(huì)對(duì)游戲?qū)ο蠼Y(jié)構(gòu)的載入與實(shí)例化的耗時(shí)帶來有趣的影響。
假設(shè)一個(gè)代碼塊實(shí)例化了一定數(shù)量的游戲?qū)ο螅Y(jié)構(gòu)樹非常龐大的單個(gè)Prefab的實(shí)例化，會(huì)比分別實(shí)例化結(jié)構(gòu)樹的多個(gè)模塊然后運(yùn)行時(shí)組合花費(fèi)更多的CPU時(shí)間。
深度分析底層數(shù)據(jù)后發(fā)現(xiàn)，實(shí)例化和喚醒游戲?qū)ο笏ㄙM(fèi)的CPU時(shí)間在各種情況下大致是相同的，單個(gè)獨(dú)立的Prefab的實(shí)例化和喚醒僅需非常少量的CPU時(shí)間（因?yàn)椴恍枰猼ranmpolining和SendTransformChanged回調(diào)）。但是，這些細(xì)小的時(shí)間節(jié)省相對(duì)于花在讀取和序列化數(shù)據(jù)上的時(shí)間是很不值的。
正如之前提到的，序列化單獨(dú)的Prefab時(shí)，每個(gè)游戲?qū)ο蠛推浣M件都會(huì)被分開序列化——即便數(shù)據(jù)是重復(fù)的。一個(gè)有30個(gè)獨(dú)立元素的UI界面中，Unity會(huì)為這些元素序列化30次，這就會(huì)產(chǎn)生大量的序列化數(shù)據(jù)。載入時(shí)，所有30個(gè)重復(fù)元素的游戲?qū)ο蠛徒M件在被轉(zhuǎn)化為新實(shí)例對(duì)象之前都需要從硬盤中進(jìn)行讀取。正是這里討論的讀取時(shí)間決定了實(shí)例化大型Prefab的性能花銷。
Unity支持嵌套Prefab之后，對(duì)于有載入大型結(jié)構(gòu)體游戲?qū)ο笮枨蟮墓こ潭裕霚p少這類工程的載入時(shí)間，可以考慮將大型Prefab中的可重用元素分開存儲(chǔ)到不同的Prefab中，并在運(yùn)行時(shí)對(duì)它們進(jìn)行實(shí)例化，而不是完全依靠Unity的序列化和Prefab系統(tǒng)。
Footnotes(腳注)
在文件中，本地ID是唯一的。即在一個(gè)資源文件中，里面包含的本地ID都是不重復(fù)的。
在內(nèi)部，這種緩存被稱為PersistentManager。實(shí)際的轉(zhuǎn)換工作在在Unity的C++ Remapper類中進(jìn)行，Remapper類沒有提供任何C# API調(diào)用接口。
運(yùn)行時(shí)創(chuàng)建資源的示例是在腳本中創(chuàng)建Texture2D對(duì)象：var myTexture = new Texture2D(1027, 768);
程序運(yùn)行時(shí)對(duì)象并沒有被卸載卻被從內(nèi)存中移除的情況通常會(huì)發(fā)生在Unity失去了對(duì)圖形內(nèi)容的控制的時(shí)候。例如，當(dāng)手機(jī)應(yīng)用被掛起并被強(qiáng)制在后臺(tái)運(yùn)行。這種情況下，手機(jī)操作系統(tǒng)通常會(huì)將所有的圖形資源從GPU顯存中強(qiáng)行卸載。之后APP再回到前臺(tái)運(yùn)行時(shí)，Unity不得不重新向GPU上傳需要的材質(zhì)、著色器和網(wǎng)格數(shù)據(jù)，以便恢復(fù)場(chǎng)景的正常渲染。
到此整個(gè)Unity內(nèi)部資源管理與對(duì)象引用及序列化的內(nèi)容就結(jié)束了，希望看完本文的你對(duì)如何合理分配Unity項(xiàng)目結(jié)構(gòu)都有了比較清晰的概念。
更多精彩，盡在匯寶盆：http://www.594ljc.cn/resource
- Tags：Unity教程
-
分享到：
相關(guān)文章
網(wǎng)友評(píng)論
您需要登錄后才可以發(fā)帖 登錄 | 立即注冊(cè)
關(guān)閉
- 用戶名：
- 密 碼：
- 驗(yàn)證碼：
看不清？ 點(diǎn)擊更換
- 忘記密碼？
全部評(píng)論：0條
推薦
熱門
