Unity Resources资源管理的优点和痛点

我觉得，Resources之所以能被广泛的使用，是因为它的使用非常简单，并且是同步加载。一般来说，正式的商业项目，对外发布资源的时候都是使用AssetBundles的方式进行。AssetBundles的方式有很多缺点，比如：

1、无法直观的看到包内的资源情况

2、异步加载，需要写比较繁琐的回调处理

3、调试的时候，无法通过Hierarchy直接定位到资源。

4、使用之前需要花费时间进行打包，尤其是在开发时候，调整资源频繁，如果忘记打包可能导致表现BUG。

前面我们也说了，Unity处理资源就2种方式，Resources和AssetBundles。那么既然AssetBundles开发期这么不好用，大部分时候就使用Resources代替了。

那么问题来了，使用Resources就没问题了嘛？

在讲缺点之前，先看一下Unity官方对于Resources使用的最佳实践：

不！要！使！用！它！

不要惊讶，这就是官方的态度。出于几点原因，Unity并不希望大家过渡使用Resources，是因为 ：

1、Resources会让内存管理变的困难，因为它的所有资源是初始化全部加载，并且常驻内存。

2、Resources内的资源会增加应用程序的启动时间和构建时长。

3、Resources内的资源无法增量更新。这是现在手机游戏开发的致命点。

所有官方建议，使用AssetBundles。。。呃~陷入了沉思。

其实也不用太在意了，经过多年的开发，其实早就累积了解决方案。后面会稍微提一下，但是最大的解决方案还是我们这个系列的主题 Addressable Asset System。不过这是后话了，等下会讲一下在没有出这套东西的时候是怎么解决的。

Resources有它的致命性，但是存在即合理。它还是有它的一些使用场景的，比如：

1、某些资源是项目整个生命周期都必须要用的。

2、有些很重要，但是却不怎么占内存的。

3、不怎么需要变化，并且不需要进行平台差异化处理的。

4、用于系统启动时候最小引导的。

另外还有一种情况就是，当你需要给老板快速展示一些效果，或者要快速完成Demo、或者要写一些教程、文章、分享等展示方案的时候，可以节省时间。但是要注意，一旦你决定要把既定的工程用于正式生产的时候，请一定把它用AssetBundles重写。

如前文所说，构建项目的时候，所有的Resources目录下的文件会被合并为一个序列化文件。该文件会有自己的metadata信息和索引信息。内部用红黑树实现资源查找，用于索引相应的File GUID和Local ID，并且它还要记录在序列化文件中的偏移量。

官方的实际测试数据，一个拥有10000个assets的Resources目录，在低端移动设备上的初始化需要5-10秒甚至更长。但其实，这些assets并不会在一开始就全部用到。