如何制定便捷的资源管理方案

工具:

Unity的资源来源有三个:一是Unity自动打包资源,二是资源,三是AssetBundle。

Unity自动打包资源,也就是说在Unity场景中直接使用的资源会随着场景自动打包到游戏中,场景加载时这些资源会被Unity自动加载。只要这些资源放在Unity项目目录的Assets文件夹中,程序就不需要关心它们的打包和加载,这也意味着这些资源是静态加载的。但是在实际的游戏开发中,我们通常是动态创建GameObject,资源是动态加载的,这样的资源并不多。

Resources Resources意味着可以在Unity项目的Assets目录下构建一个Resources文件夹。所有放在这个文件夹下的资源,无论是否被场景使用,都会被打包到游戏中,并且可以被资源动态加载。加载方法。这是平时开发常用的资源加载方式,但缺点是资源直接打包到游戏包中,不能增量更新。

AssetBundle资源是指我们可以通过编辑器脚本将资源打包成多个独立的资产捆绑包。这些AssetBundle是从游戏包中分离出来的,可以通过WWW类加载。AssetBundle的使用非常灵活:它可以用于子分发。比如大部分页游资源都是随着游戏进度增量下载,或者有些手游资源太大,渠道要求的包限制在100M,所以你只能把一开始玩不了的内容做成增量包,在玩家玩的时候通过网络下载。AssetBundle也可以用于自动增量更新,我们将在下面讨论。

与之前的Unity5版本相比,AssetsBundle的打包过程得到了简化。在打包之前,需要通过代码设置需要打包的资源,自己建立包的依赖关系。Unity5可以通过每个资源检查器底部的AssetBundle下拉指定资源需要打包到哪个包中,如果没有指定,则不打包。打包过程只需要一句话,Unity5会根据依赖关系自动生成所有的包。每个包还会生成一个清单文件,该文件描述了包的大小、crc验证、包之间的依赖关系等。通过这个manifest打包工具,可以判断下一次打包哪些包发生了资源变化,只打包资源发生变化的包,加快了打包速度。Manifest只供打包工具本身使用,发布包时不需要。

有必要提一下自动生成依赖关系。Unity确实会自动为你建立依赖关系,前提是你所依赖的资源已经在Inspector中设置了BundleName。如果没有,Unity会把这个公共资源重复的打在多个使用过的包里,因为这个公共资源并不在一个独立的包里,Unity不会智能的发现它对你是公共的,然后生成一个公共包。更深的坑是,如果你共享一个FBX模型,你为这个模型设置BundleName是不够的,还必须设置它使用的纹理和材质,否则模型共享而纹理不共享,得到的纹理仍然打包成多个包。因此,最好通过编辑器脚本来设置BundleName。

方案:

这就是Unity所能提供的一切。大家自己玩吧:如何制定一个方便的资源管理方案,可以方便开发和发布更新包?在开发过程中使用AssetsBundle是不合适的,因为开发中经常会添加和更新资源,每次添加或更新都要生成AssetsBundle,非常麻烦。而且我们需要做的是自动更新而不是分包下载,也就是说游戏发布的时候这些资源应该都在游戏包里,所以不应该从AssetsBundle加载。

分析完需求,方案出来了:资源还是放在Resources下面,但是这些资源也会打包成AssetBundle。代码中所有加载资源的地方都是通过自己的ResourceManager加载的,由资源管理器决定是否调用资源。Load加载资源或从AssetsBundle加载资源。在开发环境(编辑器)中,这些资源显然是直接从资源中加载的,发布的完整安装包资源也是从资源中加载的。只有在有增量版本的情况下,游戏主程序才会去服务器下载增量AssetBundle,然后从AssetBundle加载资源。

实现:

我们在实现中首先要考虑的是AssetBundle的粒度,即每个AssetBundle包含多少资源。增量包的最小粒度是AsssetBundle。如果单个AssetBundle过大,只要这个AssetBundle中有一个资源发生变化,就需要重新下载整个资产Bundle,浪费流量和玩家等待时间。如果单个资产包太小,极端的情况是每个资源一个资产包。虽然更新是最小化的,但是它带来了额外的开销:AssetBundle本身是有大小的,并且需要花费时间来查找和加载AssetBundle。大家都把东西拷贝到u盘里了,拷贝一个1G的文件比拷贝1千个1M的文件快多了。更合理的方法是基于逻辑。比如每个角色可以有一个独立的AssetBundle,一些常用的UI资源可以放入一个AssetBundle,每个场景的独立UI资源可以放入一个独立的AssetBundle。这样,预加载资源也很方便。每个场景需要几个bundle加载几个bundle,不相关的资源不会加载。