Resources文件夹
这是关于Unity 5中资产，资源和资源管理的系列文章的第3章。
本章讨论资源系统。这个系统允许开发人员在一个或多个名为Resources的文件夹中存储Assets，并使用Resources API 在运行时从这些Assets加载或卸载对象。
2.1。资源系统的最佳实践
不要使用它。
这个强烈的建议有几个原因：
-
使用Resources文件夹会使细粒度的内存管理变得更加困难
-
资源文件夹使用不当会增加应用程序启动时间和构建时间
- 随着Resources文件夹数量的增加，对这些文件夹中的Assets的管理变得非常困难
-
资源系统降低了项目向特定平台提供自定义内容的能力，并消除了增量内容升级的可能性
- AssetBundle Variants是Unity在每台设备上调整内容的主要工具
2.2。正确使用资源系统
有两个特定用例，其中资源系统可以提供帮助，而不会妨碍良好的开发实践：
-
Resources文件夹的简易性使其成为快速原型的优秀系统。但是，当项目进入完全生产阶段时，应该消除Resources文件夹的使用。
-
如果内容是：在一些简单的情况下，Resources文件夹可能很有用：
-
通常在整个项目的生命周期中都需要
-
不是内存密集型的
-
不容易修补，或者不会跨平台或设备变化
-
用于最小的自举
第二种情况的示例包括用于托管预制件的MonoBehaviour单例，或包含第三方配置数据的ScriptableObjects，例如Facebook App ID。
2.3。资源的序列化
在构建项目时，名为“Resources”的所有文件夹中的Assets和Objects将合并为一个序列化文件。此文件还包含元数据和索引信息，类似于AssetBundle。如AssetBundle文档中所述，此索引包括一个序列化查找树，用于将给定Object的名称解析为其相应的File GUID和Local ID。它还用于在序列化文件正文中的特定字节偏移处定位Object。
在大多数平台上，查找数据结构是平衡搜索树，其构造时间以O（n log（n））速率增长。随着Resources文件夹中对象数量的增加，这种增长也会导致索引的加载时间增长超过线性。
此操作是不可跳过的，并且在应用程序启动时发生，同时显示初始非交互式启动屏幕。已经观察到初始化包含10,000个资产的资源系统在低端移动设备上消耗多秒，即使资源文件夹中包含的大多数对象实际上很少需要加载到应用程序的第一个场景中。