【Unity优化】资源管理系列02：Resources 最佳实践

一、Resources 的序列化与加载

在上一篇提到过，Resources 文件夹下所有 Assets 和 Objects，在打包项目的时候，会被序列化为一个二进制文件。

这个文件类似下一篇要提到的 AssetBundle，包含了元数据和索引信息。其中，索引信息包含了一个序列化的查找树，用于将 Object 的名字解析为 GUID+LocalID；同时，也被用于确定 Object 在序列化文件中的字节偏移。查找树的时间复杂度要比线性高，因此文件越多，初始化索引的加时间越长。

在游戏启动，默认 splash 界面显示时，开始加载所有的索引信息。在低端移动设备上，上万个资源的索引加载（如上篇提到的，此时应该也在初始化 InstanceID 缓存），可能耗时数秒。因为 Rrsources 文件夹内的有些资源第一个场景并不需要，或者整个游戏都很少用到甚至没用到，所以这一步会产生不必要的时间、内存消耗。

二、为什么要少用 Resources

1、正如上一节提到的，Resources 文件夹下所有 Assets 和 Objects 会被打包进一个序列化文件。并且在游戏启动时，无论是否需要用到，所有资源的索引信息会被一起加载（同时生成 InstanceID 缓存条目）。这就造成了不必要的时间、内存消耗。为了避免包含游戏不需要的资源，就需要手动剔除，这也带来资源管理困难。

2、使细粒度的内存管理变得困难（Resources load 出来的资源，是可以通过 Unload 卸载的，所以并不明白官方提出这点的原因）。

3、不能热更新。

三、可以使用 Resources 的情况

1、游戏各个场景都需要的资源；

2、不占内存的资源（用来存储配置数据的 ScriptableObjects，比如 APP ID）；

3、不需要热更新，或者在所有平台、设备资源没变化的资源

4、启动游戏所需资源

四、Resources 中资源生命周期

通过 Load 方法加载进内存，通过 Unload 方法卸载资源。

上一篇也提到过，Resources 中资源比较特殊，虽然 Object 被卸载了，但是它的 InstanceID 和 GUID+LocalID 都会被保留且有效。如果之后有脚本字段或者其他 Object 再次引用了已被卸载的 Object，则该 Object 将被自动加载。