这部分主要讨论了Resources系统使用的相关问题。Resources目录允许开发者在一个或者多个Resources目录下存放Asset文件，在运行时可以通过Resources系统的相关API去加载和卸载Asset中的Object对象。
Resources系统的最佳实践方式
最好不要使用Resources系统。原因如下：
- 使用Resources目录会导致粒度管理内存变得困难。
- Resources文件夹的不合理使用会导致启动时间很长，而且会增加包的体积。
- 随着Resources目录的增加，这些文件夹内的Asset管理也会很复杂。
- Resources文件夹的使用还会影响针对不同平台分发特定内容的功能以及更新，而AssetBundle变量可以针对不同的设备或者平台进行控制。
可以使用Resources系统的少数情况
Resources在某些特殊的情境下也是可以使用的，但是需要满足如下的情况，否则还是建议不要使用：
Resources系统对于原型开发和实验阶段的产品而言比较好，因为简单容易使用。但是，最后确定推出产品的时候，还是应该去掉Resources系统的管理，改用AssetBundle系统。
Resources在其他的情境下使用需要满足如下的条件：
- Resources里面不能存放太多内容，而且不能有非常占据内存的资源。
- 整个工程运行过程中都始终需要这部分的内容。
- 这部分的内容极少需要被替换，不需要做补丁。
- 和平台与设备无关，所有平台上都有这部分的内容。
第二种情况适用的例子包括：持有单例MonoBehaviour的全局Prefab【照相机Prefab】或者某个Asset包含第三方的配置数据文件，如Facebook APP id这些内容。
Resources系统的序列化
所有命名为Resources文件夹中的Asset和Object在打包过程中都会被处理成一个单一的序列化文件，这个文件和AssetBundle文件类似，包含metadata和索引信息，索引信息是一个序列化之后的查找树结构，用来将给定的Object的名称和对应的文件GUID和局部ID建立联系，还包括用来在序列化之后的文件中Object的偏移量。
在大部分平台上，这个查找树的数据结构是一个平衡二叉树【在大多数平台上，是通过std::multimap的C++标准模板库实现的】，构建复杂度是O(N·log(N))，N代表查找树中的Object数目。随着Resources系统中文件数目的增加，复杂度的增长速度是快于线性增长的。
这个操作在启动阶段是不可避免的，初始化一个超过10000个Asset的Resources系统在低端设备上超过数十秒，尽管这些Asset在第一个游戏场景中根本不会被用到。
