本文详细讲解了Unity引擎各种类型文件的信息内容、用法和使用场景，帮助研发团队对于引擎文件进行更好的理解和掌握。
一、Unity项目中Assets目录下常见的文件类型
在Unity3d中一般存在这么几种文件：
资源文件
代码文件
序列化文件
文本文档
非序列化文件
Meta文件
1、资源文件
2、代码文件
代码文件包括所有的代码文件、代码库文件、Shader文件等。在导入时，Unity会进行一次编译。
3、序列化文件（数据文件）
序列化文件通常是指Unity能够序列化的文件，一般是Unity自身的一些类型，比如Prefab(预制体)、Unity3d(场景)文件、Asset(ScriptableObject)文件、Mat文件(材质球)，这些文件能够在运行时直接反序列化为对应类的一个实例。
4、文本文档
文本文档比较特殊，它不是序列化文件，但是Unity可以识别为TextAsset。很像资源文件，但是又不需要资源文件那样进行设置和转化，比如txt、xml文件等等。
5、非序列化文件
非序列文件是Unity无法识别的文件，比如一个文件夹也会被认为是一个文件，但是无法识别。
6、Meta文件
Meta文件在Unity中的作用非常关键，它有2个作用：
定义在它同目录下，同名的非Meta文件的唯一ID：GUID。而对于Unity的序列化文件来说，引用的对象用的就是这个GUID。所以一旦Meta中的GUID变更了，就要注意，它很可能引起一场引用丢失的灾难。
二、Meta文件详解——Unity GUID/LocalID系统
由于Meta文件的重要性，这里先说说Meta文件的数据结构。Meta文件实质上是一个文本文档，只是采用的是一种叫做YAML的格式来写的（见Description of the Format）。Unity中的序列化文件都是用这个格式类写的，比如Prefab、场景等（后文会继续）。
我们使用Nodepad 打开一个Meta文件，然后在菜单中将语言设置为YAML，如下图所示：
这是一个Asset文件（ScriptableObject）的meta文件
1、GUID
所以在每次svn提交时如果发现有Meta文件变更，一定要打开看一下。看看这个Guid是否被更改。理论上是不需要更改的。
2、ImportSetting数据
后面比较重要的数据是ImportSetting数据。根据不同的文件类型，它的数据是不同的ImportSetting数据，比如上面的NativeFormatImporter、ModelImporter、AudioImporter等等。只要对照Inspector面板中的条目，都可以看懂每一行的意义。
所以知道这个之后，我们可以发现，假如我们把一个文件和这个文件的Meta文件从一个Unity工程复制到另一个Unity工程中，它的配置是不会变的（以前在2个工程手动裁剪同一个模型的20个动画真是傻到家了，直接将这个Fbx和它的Meta文件拷贝过去就行！）。
3、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面板中的数据）
之后就是场景中的物件的数据
1、GameObject数据
展开第一个GameObject数据，可以看到这个的Name就是Main Camera（如果你的第一个GameObject数据不是Main Camera也没关系，下面肯定某一个是Main Camera，展开那个数据也是一样的结构）。
这个物体上有4个组件，一一对应下面的数据。这就是物体内的引用关系。每一个Unity对象都会有一个FileID，然后在需要引用时，使用这些FileID即可。所以在实例化一个这样的GameObject时，只要依照次序，依次创建物体，组件，初始化数据并进行引用绑定即可在场景中生成一个实例。
在Hierarchy面板中选中Main Camera可以看到如图所示，所有的组件的LocalIdentfierInFile的值就是刚刚在Notepad 中看到的数据：
这里有一点，我们看到有一个叫做InstanceID的数据。这个是Unity中一个实例的ID。每一个Unity实例都会有一个InstanceID。在运行时，可以使用UnityEngine.Object的GetInstanceID获取。但是要注意的是，每一次运行，相当于重新生成了新的实例，所以这个值是可变的。
2、组件数据
在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 ;
看到数据想必都明白了。
3、Prefab数据
在YAML的最下面有一个数据是Prefab数据：
看起来很复杂，但是实际上，它就保存了最重要的几个数据：
Modification：每个组件的修改数据列表，但凡修改的数据，都会在这里体现。
ParentPrefab：表示是哪一个Prefab。
所以上面的数据就是GUID为27f1445c35c923741a22e4948c4da980的Prefab，修改后的FileID为4126423848245890的一堆数据和FileID为1854796474342856的Name数据。
通过打开我们制作的Cube的Prefab文件及其meta文件，我们可以看到，Meta文件中的GUID就是那个，而Prefab中存在4126423848245890（Transform）和1854796474342856（GameObject）
OK，至此，序列化文件的数据和引用的原理都已完毕。
也欢迎大家来积极参与U Sparkle开发者计划，简称”US”，代表你和我，代表UWA和开发者在一起！
近期精彩回顾
【虚幻引擎学习之路】渲染模块之光照系统
【万象更新】看完性能简报，想不优化好都难！
【厚积薄发】50次游戏性能的深度优化，得出了这五条“毒鸡汤”
UWA问答：用心解决“你”的每一个问题！
