Tag：Unity文件,Unity文件引用,Meta文件,GUID,FileID,LocalID
本文介紹unity工程中的文件類型，文件引用原理和meta文件的yaml結構等
參考文檔：
Unity項目中Assets目錄下常見的文件類型
在unity3d中一般存在這么幾種文件
- 資源文件(Imported Asset)
- 代碼文件
- 序列化文件(Native Asset)
- 文本文檔
- 非序列化文件
- meta文件
資源文件(ImportedAsset)
資源文件指一些創建好的，並且不再修改的文件。這樣的文件一般是美術設計師，音頻視頻設計師創造的文件，比如FBX文件，貼圖文件，音頻文件，視頻文件，動畫文件（雖然動畫文件可以被認為是配置文件，不過在由於一般不會去做修改，所以也認為是資源文件）。像這類文件，unity中都會在導入時進行轉化。每一個類型都對應一個AssetImporter,比如AudioImporter，TextureImporter，ModelImport等等。在unity中點擊這樣的資源，在Inspector面板會出現設置界面，如下圖所示是一個FBX的設置界面：
代碼文件
代碼文件包括所有的代碼文件，代碼庫文件，shader文件等，在導入時，unity會進行一次編譯。
序列化文件(Native Asset):
序列化文件通常是指unity能夠序列化的文件，一般是unity自身的一些類型。比如prefab(預制體)，unity3d(場景)文件，asset(ScriptableObject)文件.mat文件(材質球)，這些文件能夠在運行時直接反序列化為對應類的一個實例。
文本文檔
文本文檔比較特殊，它不是序列化文件，但是unity可以識別為TextAsset。很像資源文件，但是又不需要資源文件那樣進行設置和轉化。比如txt、xml文件等等。
非序列化文件
非序列文件是Unity無法識別的文件，比如一個文件夾也會被認為是一個文件，但是無法識別。
Meta文件
meta文件在unity中的作用非常關鍵，它有2個作用
- 定義在它同目錄下，同名的非meta文件的唯一ID：GUID。而對於unity的序列化文件來說，引用的對象用的就是這個GUID。所以一旦meta中的GUID變更了，就要注意，它很可能引起一場引用丟失的災難
- 存儲資源文件的ImportSetting數據。在上文中資源文件是有ImportSetting數據的，這個數據正數存儲在meta文件中。ImportSetting中專門有存儲Assetbundle相關的數據。這些數據幫助編輯器去搜集所有需要打包的文件並分門別類。所以每一次修改配置都會修改meta文件。
Meta文件詳解——Unity GUID/LocalID系統
由於meta文件的重要性，這里先說說meta文件的數據結構。meta文件實質上是一個文本文檔，只是采用的是一種叫做YAML的格式來寫的（見Description of the Format）。unity中的序列化文件都是用這個格式類寫的，比如prefab，場景等（后文會繼續）。
我們使用nodepad++打開一個meta文件，然后在菜單中將語言設置為YAML，如下圖所示：
這是一個asset文件（ScriptableObject）的meta文件
GUID
guid是meta中最最最重要的數據。這個guid代表了這個文件，無論這個文件是什么類型（甚至是文件夾）。換句話說，通過GUID就可以找到工程中的這個文件，無論它在項目的什么位置。在編輯器中使用AssetDatabase.GUIDToAssetPath和AssetDatabase.AssetPathToGUID進行互轉。
所以在每次svn提交時如果發現有meta文件變更，一定要打開看一下。看看這個guid是否被更改。理論上是不需要更改的。
ImportSetting數據
后面比較重要的數據是ImportSetting數據。根據不同的文件類型，它的數據是不同的ImportSetting數據，比如上面的NativeFormatImporter，ModelImporter，AudioImporter等等。只要對照Inspector面板中的條目，都可以看懂每一行的意義。
所以知道這個之后，我們可以發現，假如我們把一個文件和這個文件的meta文件從一個Unity工程復制到另一個Unity工程中，它的配置是不會變的。（以前在2個工程手動裁剪同一個模型的20個動畫真是傻到家了，直接將這個fbx和它的meta文件拷貝過去就行！）
FileID（LocalID）
有一個問題是，如果是一個圖集，下面有若干個圖片，那么，這個GUID怎么對應一個文件呢？是的，對於一個文件下有多個文件的情況，就需要另外一個ID來表示，這就是LocalID。更習慣用meta文件中的名字FileID。
FileID存儲方式有2種
- 對於資源文件，非序列化文件，由於一般不會去更改源文件，所以FileID存儲在meta文件中。以下是一個fbx文件的meta文件
- 對於序列化文件，自身數據里面會存儲自身的FileID，也會記錄所有子文件的FileID（更多關於序列化文件的數據，見下文）。比如對於這樣的AnimatorController。它本身的數據如下，除了本身的FileID為9100000外，記錄了4個AnimatorClip的FileID。而meta文件中只有自身的FileID
回到本節一開始的問題，如果是圖集，因為是圖片本身是資源文件，所以會有FileID存儲在對應的meta文件中。打開任意一個圖集，比如以下這個圖集對應的meta文件
至此就是整個Unity的GUID/LocalID系統的基礎了。通過GUID找到任何一個文件，通過FileID找到其中的某個子文件。
序列化文件詳解——Unity文件引用系統
上文已經提到，對於所有的序列化文件，unity采用的是YAML來書寫。所以對於一個unity3d(場景)文件，prefab文件，材質，控制器等，都可以用文本文檔軟件打開。這里還是用Notepad++打開。
為了能夠簡潔地說明問題，我們在unity中創建一個新的場景，然后創建2個Cube，一個做成Prefab。如圖所示：
保存之后，用Notepad++打開這個1.unity3d。然后在菜單中設置語言為YAML。
可以看到大概的數據
- OcclusionCullingSettings裁剪數據（菜單Window->Occlusion面板中的數據）
- RenderSettings（菜單Window->Lighting->Settings面板中的部分數據）
- LightmapSettings（菜單Window->Lighting->Settings面板中的其他部分數據）
- NavMeshSettings（菜單Window->Navigation面板中的數據）
- 之后就是場景中的物件的數據
GameObject數據
展開第一個GameObject，可以看到這個的Name就是Main Camera。這個物體上有4個組件，一一對應下面的數據。這就是物體內的引用關系。每一個Unity對象都會有一個FileID，然后在需要引用時，使用這些FileID即可。所以在實例化一個這樣的GameObject時，只要依照次序，依次創建物體，組件，初始化數據並進行引用綁定即可在場景中生成一個實例。
我們在Inspector面板中的右上角點擊，然后選擇Debug轉成Debug模式下的Inspector面板
在Hierarchy面板中選中Main Camera可以看到如圖所示，所有的組件的LocalIdentfierInFile的值就是剛剛在Notepad++中看到的數據
這里有一點，我們看到有一個叫做InstanceID的數據。這個是unity中一個實例的ID。每一個Unity實例都會有一個InstanceID。在運行時，可以使用UnityEngine.Object的GetInstanceID獲取。但是要注意的是，每一次運行，相當於重新生成了新的實例，所以這個值是可變的。（更多細節參考《Unity編輯器下和運行時的加載過程》）
組件數據
在GameObject之后就是這個GameObject的組件數據（不知道次序會不會亂，理論上不影響）。每一個組件的數據基本上就是這個組件的一堆參數了。可以結合Unity中這個組件的面板來了解每一個數據的意義。
這里有一個問題，比如這里有一個組件是FlareLayer，但是在YAML里面只是一個Behaviour（所有Behaviour組件都看不到類型名字），怎么樣才能知道他是一個FlareLayer？
可以看到在這個數據上方，在FileID左邊我們看到一個124。對，這個就是FlareLayer。請參考YAML Class ID Reference，每一個unity類型都有一個對應的數字。
那么自定義腳本類呢？
我們創建一個Test腳本，繼承MonoBehaviour。里面什么都不寫。添加到Main Camera物體上。保存場景然后回到Notepad++。
可以看到多了一個MonoBehaviour，並且這個里面有一個m_Script數據，指向對應的GUID及其FileID。上文我們已經說了，任何一個文件都可以通過GUID找到，然后通過FileID找到它內部的子文件。所以這樣就能識別出這個具體是什么類了。
我們往Test中寫2個字段
public int A;
public Test RefTest;
在Main Camera中，設置Test腳本的A值為111，RefTest設置為自身。保存后回到Notepad++;
看到數據想必都明白了。
可以往Test中寫一些其他類型的數據，看看這些序列化數據放在YAML的哪個位置！這里不再展開（這些數據和編輯器的SerializedProperty息息相關）
Prefab數據
在YAML的最下面有一個數據是Prefab數據
看起來很復雜，但是實際上，它就保存了最重要的幾個數據
- Modification：每個組件的修改數據列表，但凡修改的數據，都會在這里體現。
- ParentPrefab：表示是哪一個Prefab。
所以上面的數據就是GUID為161b04a3180d83a4080b19801daaf356的Prefab，修改后的FileID為4040867914032966的一堆數據和FileID為1205630099335284的Name數據。
通過打開我們制作的Cube的Prefab文件及其meta文件，我們可以看到，meta文件中的GUID就是那個，而Prefab中存在4040867914032966（Transform）和1205630099335284（GameObject）
OK，至此，序列化文件的數據和引用的原理都已完畢
個人博客請訪問：http://www.cnblogs.com/CodeGize/