Unity学习笔记 - Assets, Objects and Serialization

Assets和Objects

    Asset是存储在硬盘上的文件，保存在Unity项目的Assets文件夹内。好比：纹理贴图、材质和FBX都是Assets。一些Assets以Unity原生格式保存数据，例如材质。另外一些Assets须要经过处理转换到原生格式，例如FBX。

    Object是一系列序列化数据，这些数据描述了具体的资源实例，这能够是Unity使用的任意类型的资源，例如mesh，sprite，audio clip或animation clip。全部的Objects都是UnityEngine.Object的子类。

    大部分Object类型都是Unity内置的，但有两个特殊类型：

    1. ScriptableObject容许开发者定义他们本身的数据类型。这些类型可以由Unity序列化和反序列化，而且在编辑器的Inspector窗口中进行操做。

    2. MonoBehaviour提供了连接到MonoScript的封装。MonoScript是Unity的内部数据类型，其中保存了指向在具体的程序集和命名空间中的具体脚本类的引用。MonoScripte不包含任何实际可执行的代码。

    Assets和Objects之间存在一对多的关系：也就是说，Asset文件内可以包含一个或多个Objects。

 

内部对象引用

    全部的UnityEngine.Objects均可以引用其余的UnityEngine.Objects，被引用的Objects能够和引用的Objects位于同一个Asset文件内，也能够是由其余Asset文件导入的。例如，材质对象一般有一个或多个纹理对象的引用，这些纹理对象一般都是从纹理资源文件导入的（例如PNG或JPG）。

    当序列化的时候，这些对象由两部分分离的数据组成：文件的GUID和Local ID。文件的GUID标记了存储资源的Asset文件。Local ID是局部惟一的（也就是说，在每一个Asset文件中，Local ID都是惟一的），标记了Asset文件中的每一个Object。

    文件的GUID存储在.meta文件中。这些.meta文件是Unity第一次导入Assets时生成的，而且和Asset存储在同一个目录中。下图展现了Diffuse材质及其.meta文件：

    .meta文件中包含了GUID：

    打开材质文件自己，能够看到Local ID：

    若是在场景中有对象使用该材质进行渲染，那么打开场景文件后，就会发现该材质对象由GUID以及Local ID来标记：

 

为何使用GUID和Local ID？

    GUID的功能是提供文件路径的抽象表示。只要使用GUID来关联具体的文件，那么文件在磁盘上的位置就可有可无了。所以能够随意移动文件而不须要更新引用该文件的Objects（由于这些Objects存储的都是文件的GUID）。

    因为一个Asset文件可能包含多个UnityEngine.Object资源，所以须要用Local ID来明确的标记每一个不一样的Object。

    若是一个Asset文件关联的GUID丢失的话，那么全部对该Asset文件中的Objects的引用都将丢失。当.meta文件丢失时，Unity会从新生成。

    Unity维护了具体文件路径与GUID的映射关系。当一个Asset被加载或导入时，就会新增一个映射项，该映射项将Asset的文件路径和Asset文件的GUID链接在一块儿。若是一个Asset的.meta文件丢失但其文件路径没有发生变化的话，Unity能确保从新生成的.meta中记录的GUID是保持不变的。

    若是.meta文件在Unity关闭时丢失，或者Asset文件的路径发生了变化，但.meta文件没有跟着一块儿移动的话，那么全部对该Asset文件中的Objects的引用都将丢失。举个例子，场景中的Cube使用了我建立的材质Diffuse：

Diffuse材质及其.meta文件存储在Assets目录下，若是如今在外部移动Diffuse材质到Assets/Temp目录下，因为没有同时移动其.meta文件，所以Cube对其引用就会丢失：

 

资源及其导入

    非Unity原生资源必须导入进Unity中才能使用，这是经过asset importer完成的。这些improter在资源导入时会被自动调用，同时你也能够用AssetImporter及其子类的API来经过代码调整资源导入过程。

    资源导入的结果是一个或多个UnityEngine.Objects。在Unity中你能够看到一个父对象包含多个子对象，例如sprite atlas：。这些对象都共享同一个GUID，由于他们的源数据来自于同一个Asset文件。Unity使用Local ID来区分他们：

    资源导入过程包含了十分耗时的操做，例如纹理压缩。因此若是每次打开Unity都须要执行一遍资源导入过程的话将会十分低效，所以，Unity将资源导入的结果缓存在Library文件夹中：。具体来讲，存储在以Asset文件的GUID前两个数字命名的文件夹中，这些文件夹位于目录Library/metadata：

实际上即便是Unity原生资源，也会将导入结果存储在对应文件中。可是原生资源不须要很长的转换时间或从新序列化时间。 

   

实例ID

    尽管GUID和Local ID健壮耐用，可是GUID的比较很耗时，而在运行时咱们须要有个十分高效的系统。所以Unity在内部会维护一份缓存，这份缓存将GUID和Local ID转换成独一无二的整数，这些整数被称为Instance ID，每当有新的Objects添加到缓存中时，Instance ID以简单的单调递增的方式进行赋值。缓存维护了Instance ID，GUID和Local ID（这两个定义了Object的源数据在磁盘上的位置）以及Object在内存中的实例（若是Object已经被加载到内存中的话）之间的映射关系。这样UnityEngine.Objects就能够维护相互之间的引用关系。经过Instance ID能够快速找到对应的已经加载的Object，若是对应的Object尚未加载，那么就能够经过GUID和Local ID来找到Object的源数据，而后加载相应的Object。

    应用程序启动时，项目内置对象（好比场景中使用的对象）的数据以及在Resources文件夹中的对象的数据将被初始化到Instance ID缓存中。当运行时有新的资源被导入（好比经过脚本建立的Texture2D对象），以及当从AssetBundle中加载对象时，就会在缓存中添加Instance ID项。Instance ID只有在被认为已通过时的状况下才会从缓存中删除，这种状况发生在一个AssetBundle被卸载时。当一个AssetBundle被卸载时，除了会致使对应的Instance ID被认为已通过时，Instance ID和GUID以及Local ID之间的映射数据也会被从内存中删除。若是AssetBundle被从新加载的话，那么从该AssetBundle中加载的每个对象都会建立一个新的Instance ID。

    须要注意的是在具体平台上的一些特定事件会致使Objects从内存中被删除。好比当iOS上的应用程序被挂起时，图形资源可能会从显存中被删除，若是这些资源是来自一个已经被卸载的AssetBundle，那么Unity就没法从新加载这些资源了，任何对这些资源的引用也将变得无效（例如出现不可见的模型（missing）使用粉色的材质（missing）来渲染）。

 

MonoScript

    一个MonoBehaviour包含了一个对MonoScript的引用，而MonoScript仅仅包含了用于定位到一个具体脚本类所需的信息，他们都不包含脚本类的可执行代码。

    一个MonoScript中包含了三个字符串：一个程序集名，一个类名以及一个命名空间名。

    当Unity构建项目时，会将Assets文件夹下的全部脚本文件编译到Mono程序集中。具体来讲，Unity会为在Assets文件夹中使用的每种不一样的编程语言编译一个程序集，而且会将在Assets/Plugins文件夹中的脚本单独编译到一个程序集中。在Assets/Plugins文件夹外的C#脚本会被编译到Assetmbly-CSharp.dll中，在Assets/Plugins文件夹外的Java脚本会被编译到Assembly-UnityScript.dll中，Assets/Plugins中的脚本会被编译到Assembly-CSharp-firstpass.dll中。

    这些程序集（再加上预编译的程序集）都会被包含在最终的应用程序中：

这些程序集就是MonoScript引用的程序集。和其余资源不一样，全部程序集在应用程序第一次启动时会被所有加载进来。这种方式也是为何一个AssetBundle（或者一个Scene、一个Prefab）中不包含挂载的MonoBehaviour组件中的可执行代码。这种方式使得不一样的MonoBehaviour能够引用共同的具体类。

 

资源生命周期

    有两种加载UnityEngine.Objects的方式：自动加载和显示的手动加载。当一个Instance ID被解引用，其对应的Object当前没有加载到内存中，而且Object的源数据可以被定位到时，Object会被自动加载。Objects还可以显示的在脚本中手动加载，例如新建一个Texture2D或经过AssetBundle.LoadAsset方式加载一个Object。

    若是一个文件GUID和Local ID没有对应的Instance ID，或者一个Instance ID对应的Object没有被加载，而且其对应的GUID和Local ID是无效的话，那么Object就不会被加载，可是引用关系仍旧会被保留，此时在Unity编辑器中就会出现"(Missing)"。

    Objects在下面三种具体的状况下会被卸载： 

    1. 当清理未被引用的Asset时，未被引用的Objects会被自动卸载。当场景切换时或当调用Resources.UnloadUnusedAssets函数时会触发清理未被引用的Asset。

    2. 来自Resources文件夹的Objects在调用Resources.UnloadAsset函数时会被销毁。可是Instance ID会被保留，因此若是在Object被销毁后，有任何先前对该对象的引用被解引用时，Unity会从新经过Instance ID找到GUID和Local ID，而后将该对象再次加载进来。

    3. 来自AssetBundle的Objects在调用AssetBundle.Unload(true)函数时会被当即销毁，同时也会使得Instance ID，GUID和Local ID变得无效，任何对该对象的引用也会变成"(Missing)"。以后在C#中任何对该对象的访问都会引起"NullReferenceException"异常。若是调用AssetBundle.Unload(false)，从AssetBundle加载的Objects不会被销毁，可是Instance ID对应的GUID和Local ID会变得无效，所以若是这些对象被从内存中释放的话，Unity将没法再次加载他们。

 

加载大层级对象

    当序列化Unity GameObjects（例如Prefabs）时，要记住整个层级都会被序列化。也就是说，层级中每一个GameObject及其组件在序列化数据中都会被独立的表示。所以，加载和实例化具备大层级的GameObjects时会有性能影响。

    当实例化GameObjects时，实例化一个具备大层级的GameObject和实例化多个小层级的GameObjects而后将这些GameObjects组合在一块儿相比，须要耗费更多的CPU时间。尽管实例化一个大层级的GameObject不须要组合GameObjects（不须要trampolining和SendTransformChanged回调）的CPU时间，但这些节约的CPU时间远远比不过读取和反实例化大层级数据的时间。

    以前提到，序列化GameObjects时，整个层级中的GameObject及其组件数据都会被序列化 --- 即便这些数据是重复的。好比一个UI中有30个同样的Button，那么Button数据会被序列化30次。在加载时，这些数据都须要从磁盘上进行读取，在加载大层级的GameObjects时，文件读取时间会消耗大量CPU时间。所以，能够把重复对象从整个层级中移出来，再单独实例化后再组合到整个层级中。