本文内容主要翻译自下面这篇文章
https://unity3d.com/cn/learn/tutorials/topics/best-practices/guide-assetbundles-and-resources?playlist=30089 A guide to AssetBundles and Resources
第二部分 Resources文件夹
这部分讨论Resources系统。这个系统允许开发者在一个或者多个Resources目录里面存储Asset,并能够使用Resources API在运行时加载和卸载Objects。
1.1 Resources系统的最佳实践
最佳实践就是不要使用它。
这个强烈的建议理由如下:
- 使用Resources文件夹使得内存管理更加困难。
- 不正确的使用Resources文件夹会使得项目编译发布和发布后的应用程序启动时间变长。
- 随着Resources文件夹的增多,管理里面的Assets变得困难。
- Resources系统降低了发布平台独立的定制内容的能力,并且使得增量内容更新变得不可能。
- AssetBundle变量是unity的发布针对不同设备可定制内容的主要工具。
1.2 Resources系统的正确使用
Resources系统有两个特殊的使用案例而不与最佳实践相冲突
- Resources系统非常适于快速开发原型和实验,因为他非常简单易用。当项目推进到完整产品时,强烈建议排除掉Resources文件夹。
- Resources文件夹适合一些琐碎的资源,比如Resources文件夹里面的资源都是很小,或者整个项目生命周期都需要。这些内容都不需要打补丁。也即跨平台和设备时都不会变化。
适合第二种情况的例子比如有全局用的预制品,上面挂载一些单例MonoBehaviour脚本。或者是第三方配置资源,比如FaceBook App ID。
2.3 Resources序列化
当项目编译的时候所有Resources目录下的Asset都被序列化进一个文件。这个文件和AssetBundle一样也包含meta数据和索引信息。索引信息包含object名字到GUID和localID的查找树。也用来定位一个对象在文件内的字节偏移等信息。
查找树在大部分的平台上是平衡树。她的构造时间是O(Nlog(n)),n是Object数量。数量的增长造成加载时间不是线性增长。
当应用启动时,这个操作是不能跳过的。在很慢的移动设备上面初始化一个包含10000个资源的resource系统,可以观察到会消耗好多秒,虽然这些文件大部分都不需要加载到第一个关卡里面。