Resource文件夹（转）

最近换项目，中间有了几天“间歇期”，正好可以抽空读一读这篇文章，读起来并不轻松，英语水平有限，尝试理解其中的含义概念，有些段落反反复复看了多次，在这里把笔记分享出来，这也是对知识的一次总结。

初学Unity时，都会将资源放到Resources目录下，并通过Resources相关的API加载访问，非常的便利，但随着使用和学习的深入，尤其是正式商业项目的开发，Resources文件夹，不推荐使用！

 

image.png

WHY?

1.不恰当的使用Resources，会增加程序的启动和版本构建的时长（increase application startup time and the length of builds），因此会让内存管理变得困难。

Assets下，可以放置任意多个命名为Resources的文件夹，这些文件夹在版本构建时，会合并成一个序列化文件，这个序列化文件包括了metadata和indexing information。

indexing information包括了一个平衡的搜索树（On most platforms, the lookup data structure is a balanced search tree），我们可以通过Resources API 传递路径名字去找到资源在Resources下的位置，平衡的搜索树是为了保证我的时间复杂度在O(n log(n)) ,提高资源查找的速度。

Resources 的这2点因素，会导致构建时间和启动时间变长。

：发生在构建阶段，合并所有命名为Resources的文件夹下的资源并序列化的时间。
：发生在运行阶段(non-interactive splash screen)，在Unity启动时，会创建indexing information,平衡搜索树的时间。

所以，Resources下的的资源越多，耗时就越多，是线性增长的。

如果Resoruces下的子文件夹嵌套特别深，递归的成本也会越大。

创建balanced search tree是在真机设备上发生的，在一些低端机设备，可能会有数秒的耗时，并且这个过程，是一定会执行，不可跳过的。

2.Resources文件夹下的资源是无法进行动态更新的，是直接压缩并包含在平台可执行文件中。

资源的动态更新要使用AssetBundle，但现在，Unity 建议使用Addressable System，在上一款项目中使用到，当时还在preview版本，开发了快一个月，才release，替开发者节省了很多工作，稍后会研究一下AAS的使用。

Resources这么不受待见，难得一无是处了吗？

并不是这样，下面两种情况使用Resources还是很有价值的。

1.原型,Demo，测试案例验证开发的阶段，因为Resources的设计及使用，非法的方便，只要把文件放进去，通过API加路径名称直接使用，这样会加快我们原型开发的事速度，但切换回正式环境以后，Resources一定要替换掉。

2.一些基本配置数据，如App id，一些小的prefabs，一些非内存密集型的文件，即小文件，不随设备平台变化，比较“佛系”的资源。