Unity5 如何做资源管理和增量更新

工具

Unity 中的资源来源有三个途径：一个是Unity自动打包资源，一个是Resources，一个是AssetBundle。

Unity自动打包资源是指在Unity场景中直接使用到的资源会随着场景被自动打包到游戏中，这些资源会在场景加载的时候由unity自动加载。这些资源只要放置在Unity工程目录的Assets文件夹下即可，程序不需要关心他们的打包和加载，这也意味着这些资源都是静态加载的。但在实际的游戏开发中我们一般都是会动态创建GameObject，资源是动态加载的，因此这种资源其实不多。
Resources资源是指在Unity工程的Assets目录下面可以建一个Resources文件夹，在这个文件夹下面放置的所有资源，不论是否被场景用到，都会被打包到游戏中，并且可以通过Resources.Load方法动态加载。这是平时开发是常用的资源加载方式，但是缺点是资源都直接打包到游戏包中了，没法做增量更新。
AssetBundle资源是指我们可以通过编辑器脚本来将资源打包成多个独立的AssetBundle。这些AssetBundle和游戏包是分离的，可以通过WWW类来加载。AssetBundle的使用很灵活：可以用来做分包发布，例如大多数页游资源是随着游戏的过程增量下载的，或者有些手游资源过大，渠道要求发布的包限制在100M以内，那只能把一开始玩不到的内容做成增量包，等玩家玩到的时候通过网络下载。AssetBundle 也可以用来做我们下面讨论的自动增量更新。

Unity5相比之前的版本，AssetsBundle的打包过程有所简化。之前打包需要通过代码来设置需要打入包的资源并自己建立包的依赖关系，Unity5可以通过每个资源Inspector底部的AssetBundle下拉来指定该资源要打入哪个包，不指定就是不打包。打包过程只需要BuildPipeline.BuildAssetBundles一句话就行了，Unity5会根据依赖关系自动生成所有的包。每个包还会生成一个manifest文件，这个文件描述了包大小、crc验证、包之间的依赖关系等等，通过这个manifest打包工具在下次打包的时候可以判断哪些包中的资源有改变，只打包资源改变的包，加快了打包速度。manifest只是打包工具自己用的，发布包的时候并不需要。

关于自动生成依赖关系这个有必要提下，Unity确实会自动给你建立依赖关系，前提是你依赖的资源必须已经在Inspector中设置了BundleName。如果没有，Unity会把这个公用的资源重复打到多个用到的包中，因为这个公用资源不在一个独立的包中，Unity也不会智能地给你发现它是公用的，然后生成一个公用包。更深的坑在于，如果你公用的是一个FBX模型，你只给这个模型设置BundleName还不行，它用到的贴图，材质都要设，否则模型是公用了，贴图没有公用，结果贴图还是被打包到多个包中了。所以设置BundleName这个工作最好还是由编辑器脚本来完成。

方案

Unity提供的就这些了，下面就自己发挥：如何做一个方便的资源管理方案，既可以开发时方便，又可以方便发布更新包呢？开发过程全用AssetsBundle是不合适的，因为开发中资源经常添加和更新，每次添加或者更新都生成一下AssetsBundle才能运行是很麻烦的。而且我们要做的是自动更新而不是分包下载，这也就是说在发布游戏的时候这些资源应该都是在游戏包中的，所以他们也不该从AssetsBundle加载。

分析完需求，方案也就出来了：资源还是放在Resources下面，但是这些资源同时也会打包到AssetBundle中。代码中所有加载资源的地方都通过自己的ResourceManager来加载，由ResourceMananger来决定是调用Resources.Load来加载资源还是从AssetsBundle加载。在开发环境下(Editor)这些资源显然是直接从Resources加载的，发布的完整安装包资源也是从Resources加载，只有当有一个增量版本时，游戏主程序才会去服务器把增量的AssetBundle下载下来，然后从AssetBundle加载资源。

实现

实现中我们首先要考虑的是AssetBundle的粒度，即每个AssetBundle包含多少资源。增量包的最小粒度就是AsssetBundle，如果单个AssetBundle过大，只要这个AssetBundle中有一个资源改变了就需要重新下载整个AssetBundle，浪费流量和玩家的等待时间；如果单个AssetBundle过小，极端情况是每个资源一个AssetBundle，虽然实现了更新最小化，但是带来了额外开销：AssetBundle本身也是有大小的，而且查找加载AssetBundle也是需要时间的。大家都往U盘里面拷过东西，拷一个1G的文件比拷1千个1M的文件要快很多。比较合理的做法是根据逻辑来，例如每个角色可以有独立的AssetBundle，公用的一些UI资源可以打到一个AssetBundle里面，每个场景独立的UI资源可以打成独立的AssetBundle。这样做资源预加载的时候也方便，每个场景需要用到几个Bundle就加载几个Bundle,无关的资源不会被加载。

下面要考虑的是如何来确定一个资源是从Resources加载还是AssetBundle加载。为此我们需要一个配置文件resourcesinfo。这个文件随打包过程自动生成。里面包含了资源版本号version，所有包的名字，每个包的HashCode以及每个包里面包含的资源的名字。HashCode直接可以从Unity生成的manifest中得到（AssetBundleManifest.GetAssetBundleHash），用来检查包的内容是否发生变化。这个resourceinfo每次打包AssetBundle时都会生成一个，发布增量时将它和新的Bundle一起全部复制到服务器上。同时在Resources文件夹下也存一份，随完整安装包发布，这就保证了新安装游戏的玩家手机上也有一份完整的资源配置文件，记录了这个完整包包含的资源。

当游戏启动时，首先请求服务器检查版本号，前端用的版本号就是Resources下面的这个resourcesinfo中的version。服务器比对这个版本号来告诉前端是否需要更新。如果需要更新，前端就去获取服务器端的新resourcesinfo，然后比对里面每个bundle的HashCode，把HashCode不同的bundle记录下来，然后通过WWW类来下载这些发生改变的bundle，当然如果服务器版的resourcesinfo中包含了本地resourceinfo中所没有的Bundle，这些Bundle就是新增的，也需要下载下来。所有下载完成后，前端将这个新的resourceinfo保存到本地存储中，后面前端的所有操作都将以这个resourceinfo为准而不再是Resources下面的resourceinfo了。Resources下的resourceinfo可以退出历史舞台了，除非一种情况：本地存储的resourceinfo被认为删除了。手机端玩家清理应用的数据就会造成下载的bundle以及resourceinfo被删除。没关系，这时候前端由于找不到外部的resourceinfo了，还会使用Resources下面的resourceinfo和服务器比对，把新的bundle重新下载下来。

现在从哪里加载资源就很明确了：ResourceMananger先读取resourcesinfo，知道了游戏中所有的Bundle和每个Bundle包含的资源，然后去外部存储查找这些Bundle是否存在，如果存在，就记录下这个Bundle的资源应该从外部的AssetBundle加载，如果不存在，就从内部的Resources加载。在开发过程（Editor）中，由于不存在外部存储的bundle，资源自然都是从Resources加载的，达到了我们开发方便的目的。这个过程隐含了一点：不是所有的资源都需要有BundleName而被打包到AssetBundle中，游戏内不需要后续更新的资源就不要设置BundleName，它们不会被打包更新，这样的资源ResourceManager在resourceinfo中是找不到的，直接去Resources文件夹下面读取就行了。

加载AssetBundle，我们直接使用WWW类而不用WWW.LoadFromCacheOrDownload, 因为我们的资源在游戏开始的时候已经下载到外部存储了，不要再Download也不要再Cache。注意WWW类加载是异步的，在游戏中我们需要同步加载资源的地方就要注意把资源预加载好存在ResourceManager中，不然等用的时候加载肯定要写异步代码了。大部分时候我们应该在一个场景初始化时就预加载好所有资源，用的时候直接从ResourceManager的缓存取就可以了。

资源加载卸载

最后简单说下资源的加载卸载，这个网上也有很多文章介绍。
从我理解来看Resources是一个缺省自动打包的特殊AssetBundle。无论从WWW还是AssetBundle.CreateFromFile创建AssetBundle其实是创建了一个文件内存镜像。这时候是没有Asset的。AssetBundle.LoadAsset 和Resource.Load才真正创建出了Asset，而Instaniate复制了这个Asset。注意这个复制有两种，学C++的都知道浅拷贝和深拷贝，这里的复制有的是正真的复制，有的是引用。为什么要这样呢？因为有些游戏资源是只读的，像贴图Texture，这么大而且只读，当然不需要再去完全复制一份。但像GameObject这种资源它的属性是可以通过脚本改变的，必须要复制一份。所以一个资源从AssetBundle到场景中被实例化，其实有3块内存被创建，这3快内存的释放是有不同方法的。

文件内存镜像是通过AssetBundle.Unload(false)来释放的。
Instaniate出来的Object内存通过Object.Destory来释放。
AssetBundle.Unload(true)不单会释放文件内存镜像，还会释放AssetBundle.Load创建的Assets。这个方法是不安全的，除非你能保证这些Assets没有Object在引用，否则就出问题了。
Resources.UnloadAsset和Resources.UnloadUnusedAssets可以用来释放Asset。

下面这个图很直观：

这是老Unity的图，Unity5已经把AssetBundle.Load 改成了AssetBundle.LoadAsset。这个改动让我们更明确了Load出来的是Asset这块内存区域。什么时候把Resource.Load也改了吧。

注意事项（坑）

Resources.Load方法传入的资源路径需是从Resources文件夹下一级开始的相对路径且不能包含扩展名；而AssetBundle.LoadAsset方法传入的资源名需是从Assets文件开始的全路径且要包含扩展名。路径不区分大小写，建议全用小写，因为AssetBundle.GetAllAssetNames方法返回的资源名都是小写的。
Unity5打包AssetBundle时会自动处理依赖关系，但是在运行时加载的时候却不会，程序需要自己处理，先加载依赖包。
AssetBundle.CreateFromFile不能加载压缩过的AssetBundle，所以我们只能用WWW来异步加载AssetBundle。
目前我用的Unity5.0.2f1的Resources.Load方法在手机端比原来慢了很多，如果以前可以不缓存每次用的时候都调用Resource.Load现在就不行了。频繁的调用会导致明显的性能开销，不知道是不是Bug。

原文地址：http://blog.csdn.net/ring0hx/article/details/46376709