Unity的AssetBundle使用总结

Unity的AssetBundle使用总结

  • 一、AssetBundle的压缩方式对比
  • 二、AssetBundle的依赖拆分策略
  • 三、AssetBundle的卸载策略

AssetBundle作为Unity引擎的资源加载管理和热更新手段,在各大项目内普遍的使用着。AssetBundle使用方式简单,只要设置AssetBundleName,然后打包出文件,在运行过程中加载就可以使用,但很多细节上的问题,会影响实际使用的效果。
之前我也写过很多篇文章介绍AssetBundle的使用和依赖拆分策略。这几年来陆陆续续也做了不少项目,在里面遇到了一些问题,所以想重新终结一下。
这篇文章会讨论三个问题:
1、AssetBundle的压缩方式对比
2、AssetBundle的依赖拆分策略
3、AssetBundle的卸载策略

一、AssetBundle的压缩方式对比

Unity默认的打包AssetBundle压缩方式是LZMA,我们也可以通过打包参数BuildAssetBundleOptions的UncompressedAssetBundle指定不压缩,或者ChunkBasedCompression来指定使用LZ4方式压缩。
不压缩,自然也不需要解压缩,所以打包和加载的速度会快一些。但不压缩会让AssetBundle容量很大很多,这样会让安装包变大,还有用户下载热更新时也会变大很多。
下面主要对比的是LZMA和LZ4的使用情况。
这里拿了一个项目的一部分模型作为测试,把所有预设都打包成同一个AssetBundle,分别使用了LZMA和LZ4的压缩方式。
1、容量:
LZMA:160Mb
LZ4:219Mb
可以看出,用LZ4打包出来的AssetBundle,容量会比LZMA的大30%左右,这个和网上看到的结论是相符合的。
但实际上这个容量的大小差别还是很有争议性的,因为这里面的资源全部都是prefab,没有scene文件。我之前的项目曾经试过LZ4比LZMA大了一倍多的,我暂时没有很仔细的找出变大的资源是哪些,但那个项目使用的场景比较多,场景都是直接打包成AssetBundle的,估计和这个有点关系。
2、加载速度:
以下通过同样的加载方式来测试:
1.加载这个包含了所有模型的AssetBundle,使用AssetBundle.LoadFromFile方法加载
2.使用LoadAsset方法读取AssetBundle内的一个模型,并让他实例化在场景里面
首先是LZMA压缩方式的AssetBundle:
Unity的AssetBundle使用总结_第1张图片
在LoadFromFile方法里面,消耗了11909毫秒。
然后是LZ4压缩方式的AssetBundle:
Unity的AssetBundle使用总结_第2张图片
在LoadFromFile方法里面,消耗了84毫秒。
这两者之间的差距已经非常明显了,完全不是一个数量级里面的。

3、内存:
首先是在完全没加载任何东西前,unity本身的内存截图如下:
Unity的AssetBundle使用总结_第3张图片
然后是加载LZMA的AssetBundle之后的内存:
Unity的AssetBundle使用总结_第4张图片
最后是加载LZ4的AssetBundle之后的内存:
Unity的AssetBundle使用总结_第5张图片
可以看出,LZMA的AssetBundle加载完之后,比LZ4的AssetBundle加载完的总内存增加了250Mb左右。但是从单帧采样来看,却看不出他们之前的区别,只知道是Unity本身占用的内存。
根据官方文档的说法LZMA是一个整体打成压缩包。LZ4是每个文件单独再打成压缩包再放在一起。所以加载LZ4的时候,AssetBundle只是一个引用,可以单独的提取LZ4压缩包里面的个别文件来使用。
而LZMA作为一个整体,必须一起加载到内存里面去。LZMA加载完之后,是会解压缩然后再次打包成LZ4的格式存在于内存里面,然后再加载的。
如果按照Unity官方的这个说法,那么LZMA的加载速度慢,还有内存大,就是必然的事情了。
对比可以看出,LZ4无论从加载速度还是内存方面都要比LZMA好很多。唯一的缺点就是容量会大,具体比LZMA大多少,这需要具体的情况去分析。
虽然LZ4很多优点,但有些项目还是不能愉快的使用,因为对于买量游戏来说,安装包的包体大小决定了买量的成本,为了减少包体容量,研发团队很有可能宁愿牺牲性能来换取容量上的减少。这真是一个可悲的现实。

二、AssetBundle的依赖拆分策略

这是一个一直在讨论的问题,想要做到的目的很明确:
1、AssetBundle之间不要有冗余的资源
2、下载容量小
3、加载速度快
4、内存占用少

在讨论这个问题之前,先要看游戏实际的情况。
有些游戏,根本不需要考虑依赖拆分的问题。比如格斗游戏,用dlc来增加角色,每个角色就是一个资源包,角色与角色之间也没什么太多的共用资源。这种情况下,每个角色打成一个bundle,简单快捷。
但这种情况毕竟不多见。正常的项目,美术资源之间重复利用反而是经常出现的。所以说刚才那几个问题还是需要考虑。
对于第一个问题,如果想完全没有冗余资源,很容易做到,只要把资源的所有依赖都单独打包AssetBundle,比如一个模型,他使用了一个fbx,一个材质球,一张贴图,三个动画文件。那么我们就把他们全部单独打包,包括模型预设本身,我们生成7个AssetBundle,就完全不会有冗余了,就算其他模型用到了相同的网格模型或者贴图,也不会有问题。
但这样简单粗暴的处理方式,将会产生其他的问题。
1、AssetBundle文件本身每个文件都会有一些文件本身的数据在里面的,我们可以成为文件头信息。虽然资源没有冗余了,但是由于文件多了,文件头的信息加起来也会变多,使得总容量变大了。
2、由于文件变多了,导致玩家下载文件的数量也变多。如果有从网上下载过资源都应该知道,下载文件数量多的时候,每个文件需要建立新的连接来下载,甚至很多小文件只有几Kb或者几十Kb,这样是达不到用户最大网速下载的,除非游戏开多线程来下载这些文件,不然总的下载速度是比下载单独一个文件要慢比较多。
3、加载散文件时,我们需要先查依赖列表,然后逐个文件去加载依赖的AssetBundle,也会比单独加载一个AssetBundle慢。但这个过程耗时比较少,所以一般来说感觉不明显。
4、在内存占用方面,实际上差别会比较大。
同样一个模型加载,我用了2种不同的方式:
第一种是所有依赖的资源打在同一个AssetBundle里面,序列化文件占用只有一个,占用内存99kb
在这里插入图片描述
第二种是把依赖全部打散成单独的AssetBundle里面,序列化文件占用有14个,占用内存0.7mb。
Unity的AssetBundle使用总结_第6张图片
一个模型占用了0.7mb,如果游戏里面使用的资源多起来,AssetBundle多起来了,就会比较恐怖了。这是一个较为大型的游戏的内存,可以看到AssetBundle有1688个,占用了86.3mb。这部分只是单纯的AssetBundle占用,不包括他们本身的资源比如网格模型、材质球、贴图等。
Unity的AssetBundle使用总结_第7张图片
从上面的结果看,AssetBundle打得多了,实在是没有好处。
于是我们得出结论,AssetBundle的数量尽量减少一些。但减少到多少合适呢?
如果不需要考虑玩家下载更新,只是单纯的把资源变成AssetBundle来加载,用LZ4的压缩方式来说,整个游戏的资源打在一起,的确是很好的选择。这样加载最快,也不会有任何的冗余。但从实际情况出发,如果只是为了加载资源,完全不需要更新的话,也没有必要用到AssetBundle了,直接用Resource.Load就行了。

我自己在实际项目中使用过三种策略:
1、所有资源都打散为单独的AssetBundle
2、一个单独个体的模型包含依赖打成一个AssetBundle
3、根据依赖引用数量来判断某个资源是否需要打成AssetBundle
第1种方式,是最简单快捷的解决了资源冗余的问题。这是绝对的不可能有冗余。而且由于都是拆散之后的资源,所以其中某一个资源被修改了,一般都不会影响到别的文件,在版本更新的时候,玩家实际需要下载的文件容量应该是最小化的。但缺点刚才已经分析过,由于文件多,导致了玩家下载时会慢,必须开多线程同时下载才能达到正常的网速。然后加载时会让内存变大。
第2种方式,文件少,下载和加载的次数变少了很多。但由于资源之间会有比较多的冗余,导致了打出来的AssetBundle总体容量会变大不少。然后加载到内存里面时,冗余的资源会产生重复的资源内存分配,比如用到同一张贴图的十个模型,加载到内存里面,这张相同的贴图由于是从十个不同的AssetBundle加载的,所以内存里面会有十张一模一样的贴图存在,导致内存占用变大。然后如果这张共用的贴图被修改了,那么下次版本更新,用到这张贴图的十个模型的AssetBundle都需要玩家重新下载。所以我感觉这种做法有点得不偿失,是否能使用,要取决于资源的复用情况多不多,如果多,不建议这样做。
第3种方式,把直接用于加载的预设全部列出来,逐个预设打成一个AssetBundle,然后检查这些预设依赖到哪些文件。如果资源文件只被一个预设用到了,就不需要打包AssetBundle,但如果资源文件被2个或2个以上的预设用到了,那么这个资源就需要单独打包。这种方式比起全部打散依赖的方式,最终打出来的AssetBundle数量会少很多,也基本可以保证没有冗余文件。但也不是完全完美的。假如一个资源一开始只会被一个预设用到,后来变成和另外一个预设共用了,那么打包的时候,为了把共用的资源分离出来,原预设和这个资源都需要重新打包。如果经常有这种情况出现,可能热更新时需要更新的文件会随着共用资源变多而越来越多。
从总体的优缺点来看,第3种方式应该是比较合理的处理方式。

三、AssetBundle的卸载策略

对于AssetBundle的卸载,一般都是出于对内存控制的考虑。
想达到这样的目的:
1、AssetBundle尽量占用内存少
2、在不需要使用该AssetBundle里面的资源时,及时的释放资源
为了让AssetBundle尽量少占用内存, LZ4的压缩方式明显比LZMA要适合很多。但加载进来之后,什么时候该卸载资源,这是一个比较复杂的问题。
在写这篇文章之前,我看了网上一些文章的分享。有些文章建议,在加载完AssetBundle之后,加载资源本身,然后立刻把AssetBundle释放,使用Unload(false)的方式。这样就可以没有AssetBundle的内存占用,当资源不再使用的时候,可以用Resources.UnloadUnusedAssets( )方法来释放没用的资源,从而达到内存释放的目的。
这样做其实会存在几个问题:
1、假如资源存在资源依赖的重用,比如一张贴图被多个模型资源使用,那么在分别加载这些模型时,由于前一个资源的AssetBundle已经被释放了,加载下一个资源的时候,重复利用的资源比如贴图,就会需要再次加载AssetBundle然后生成。
对于Unity来说,一个AssetBundle被释放然后再重新加载,虽然还是同一个AssetBundle同一份资源,但他们之间的资源是不会有任何关联的,所以加载到的图片虽然是同一张,但在内存里面会有两份独立的图片资源。这样就会导致内存冗余,如果资源一直重复加载并且得不到合理的释放,就会变成内存泄露导致崩溃。
这个我感觉Unity的底层如果可以再进一步的优化,让加载到的相同资源在内存里面只会有一份,就能解决这个问题。但那毕竟是Unity内部的事情,我们不能把希望寄托在他能解决上。
2、假如资源被代码引用着,比如把LoadAsset出来的Object保存起来,方便下一次实例化之类。那么就算场景里面用到该资源的GameObject都已经被删除了,但还是不能通过UnloadUnusedAssets来释放,如果没有额外的资源管理策略,这些资源将会一直占用着内存而且不会释放。
3、如果AssetBundle加载完之后就立刻释放,一些被依赖得比较多的资源,将会反复的加载和卸载,导致了无谓的性能消耗。

基于这些问题,我并不建议加载完资源之后立刻卸载AssetBundle。
我的思路是这样的:
1、每一个加载的AssetBundle都受到管理,记录每个AssetBundle依赖了哪些AssetBundle,并且记录从单个AssetBundle里面LoadAsset过的所有资源。
2、每一个加载出来的资源都可以判断得到当前是否有被使用
3、找合适的时机检查资源使用情况,如果一个AssetBundle里面加载过的资源都没有被使用,这个AssetBundle本身又没有被其他资源依赖着,那么这个AssetBundle就可以释放。

要记录AssetBundle及其依赖的加载情况,是非常容易的事情,因为这都是我们主动去做的事情。比如加载一个AssetBundle,我们肯定知道,用到了哪些依赖,我们也是从AssetBundleManifest.GetAllDependencies里面查找然后加载的。这时候,我们要记录加载过的AssetBundle,然后被依赖的AssetBundle做计数器,是很简单的事情。
然后对于单个Asset的加载,也是通过LoadAsset方法主动加载的,所以加载过的资源也是可以逐个AssetBundle做一个记录的。
这个思路里面,最难的一点,是怎样去判断每一个加载出来的资源是否正在被使用。
被使用的情况有3种:
1.资源被实例化为GameObject放在场景里面使用。
2.资源被赋予在某个Component的属性里面,比如图片Sprite被指定在Image组件上。
3.资源被存在代码里面,比如把Object存在某个类里面方便实例化时使用。
这3种情况,如果都不存在的时候,使用Resources.UnloadUnusedAssets( )是可以把某个已加载到内存里面的Asset释放掉的。但释放的过程并没有结果返回,所以我们不知道释放了哪一些资源。
这时候,我们可以使用C#的弱引用(System.WeakReference)机制来判断一个资源是否被释放。弱引用的原理大概是这样的:一般的对象存在某个代码里面时,不管是UnloadUnusedAssets还是System.GC.Collect,都是不能释放的,但弱引用的对象,是可以被上面两种手段清空的。所以我们可以把资源存在弱引用里面,当资源真的被释放掉之后,我们就可以通过判断弱引用里面的对象是否已经为空,来判断这个对象是否有其他地方用到。
具体的步骤如下:
1、每个AssetBundle加载完之后,存在一个计数器里面。然后给每个AssetBundle建立一个管理的对象,里面单独管理自己加载过的Asset。
2、对某个AssetBundle进行LoadAsset时,用AssetName作为key,把加载出来的Object对象创建一个弱引用的对象,存到字典里面。代码大概如下。
Unity的AssetBundle使用总结_第8张图片
3、找一个合适的时机,比如切换场景之类本身卡顿不会很明显的时候,调用UnloadUnusedAssets和System.GC.Collect。
4、隔一段时间,检查一下刚才保存的弱引用里面,资源是否还存活。代码大概如下:
Unity的AssetBundle使用总结_第9张图片
5、当确定某个AssetBundle里面加载过的资源都已经没有在使用时,我们还要判断一下,当前AssetBundle有没有被其他AssetBundle依赖。这时候第一步的计数器就起作用了,如果被依赖数为0,那就是可以释放了。释放的时候,看当前的AssetBundle还有没有依赖到别的AssetBundle。如果有,把所有依赖的计数器减一。然后再看看被减一的计数器有没有已经为0的,继续释放。
6、释放的时候,最好不要立刻就Unload(true)。建议是先把可以释放的AssetBundle放到一个队列里面,等1分钟之后再释放。这是怕有些时候逻辑会在释放完某些资源之后,又立刻去申请使用,这时候其实AssetBundle是不需要释放的,释放了还需要重新加载回来,有无谓的消耗。

这个流程下来,一般就能比较好的管理AssetBundle和Asset的使用和卸载了。但需要注意几点潜规则:
1、在调用UnloadUnusedAssets和System.GC.Collect之后,如果立刻检查弱引用,很有可能并没有立刻判断到对象已经被释放。因为UnloadUnusedAssets本身是一个AsyncOperation,是异步的。所以需要隔一段时间判断一次。
2、注意一个GameObject被Destroy之后,并不一定真正的被释放掉了。假如这个GameObject是被某个类的变量引用着,就算GameObject被Destroy了,但实际上只要引用他的对象一直不清空,当前的这段内存是不会释放的。
这个问题其实很常发生,因为Destroy了某个Unity的GameObject之后,用代码判断某个引用这GameObject的变量时,的确可以判断得到对象为空了。所以很多人在Unity里面写代码的时候,都不习惯清空保存的变量。但其实可以做一个实验,我们可以写一个public的变量,然后把一个GameObject赋予给他,最后把GameObject删掉,回头在Inspector面板里面看看,你会发现这个变量会变成Missing,而不是None。Missing的意思是,这里引用的guid不为空,但引用的具体值可能找不到了。
3、如果决定要使用弱引用来判断资源,就不要再用其他代码把资源存起来了,比如很多人会另外建立一个管理类,先存起一个资源,等别人再次请求的时候,直接返回这个资源用于实例化之类。而是应该用弱引用的对象来做这个事情。因为如果用其他代码来存,那么只要代码不释放,弱引用也就永远判断不到他有没有真的没被使用。而且弱引用本身就把这个资源存在target参数里面,只要先判断一下target是否为空,如果不为空就返回使用就可以了。如果弱引用里面的资源被释放了,就再在AssetBundle里面加载出来。
Unity的AssetBundle使用总结_第10张图片

你可能感兴趣的:(unity相关)