1.1 Resources详解
我觉得,Resources之所以能被广泛的使用,是因为它的使用非常简单,并且是同步加载。一般来说,正式的商业项目,对外发布资源的时候都是使用AssetBundles的方式进行。AssetBundles的方式有很多缺点,比如:
1、无法直观的看到包内的资源情况
2、异步加载,需要写比较繁琐的回调处理
3、调试的时候,无法通过Hierarchy直接定位到资源。
4、使用之前需要花费时间进行打包,尤其是在开发时候,调整资源频繁,如果忘记打包可能导致表现BUG。
前面我们也说了,Unity处理资源就2种方式,Resources和AssetBundles。那么既然AssetBundles开发期这么不好用,大部分时候就使用Resources代替了。
那么问题来了,使用Resources就没问题了嘛?
1.2 Resources 目录的最佳实践
在讲缺点之前,先看一下Unity官方对于Resources使用的最佳实践:
不!要!使!用!它!
不要惊讶,这就是官方的态度。出于几点原因,Unity并不希望大家过渡使用Resources,是因为 :
1、Resources会让内存管理变的困难,因为它的所有资源是初始化全部加载,并且常驻内存。
2、Resources内的资源会增加应用程序的启动时间和构建时长。
3、Resources内的资源无法增量更新。这是现在手机游戏开发的致命点。
所有官方建议,使用AssetBundles。。。呃~陷入了沉思。
其实也不用太在意了,经过多年的开发,其实早就累积了解决方案。后面会稍微提一下,但是最大的解决方案还是我们这个系列的主题 Addressable Asset System。不过这是后话了,等下会讲一下在没有出这套东西的时候是怎么解决的。
2.1 哪些情况我们可以使用Resources
Resources有它的致命性,但是存在即合理。它还是有它的一些使用场景的,比如:
1、某些资源是项目整个生命周期都必须要用的。
2、有些很重要,但是却不怎么占内存的。
3、不怎么需要变化,并且不需要进行平台差异化处理的。
4、用于系统启动时候最小引导的。
另外还有一种情况就是,当你需要给老板快速展示一些效果,或者要快速完成Demo、或者要写一些教程、文章、分享等展示方案的时候,可以节省时间。但是要注意,一旦你决定要把既定的工程用于正式生产的时候,请一定把它用AssetBundles重写。
2.2 Resources的序列化
如前文所说,构建项目的时候,所有的Resources目录下的文件会被合并为一个序列化文件。该文件会有自己的metadata信息和索引信息。内部用红黑树实现资源查找,用于索引相应的File GUID和Local ID,并且它还要记录在序列化文件中的偏移量。
官方的实际测试数据,一个拥有10000个assets的Resources目录,在低端移动设备上的初始化需要5-10秒甚至更长。但其实,这些assets并不会在一开始就全部用到。