现在手机游戏的常规更新方案都是在启动时下载所有资源更新,游戏质量高的、用户粘性大的有底气,先安装2个G,启动再更新2个G,文件小了玩家还觉得品质不行不想玩。
最近在做微信、抖音小游戏,使用他们提供的资源缓存方案,现在要转成Android APP, 也想用这种边下边玩的机制把首包做小。
其实很简单,直接用Unity内部的Caching机制即可,但是因为没怎么接触过,一开始用的就是那种启动时下载资源更新的方案,反而绕了一些弯路。
资源方案:AssetBundle (现在推Addressable的比较多,解决了AssetBundle难以处理的一些问题,但是比较久的项目肯定都对AssetBundle进行了相应的封装来处理这些问题,没有本质区别)
1. 打包AssetBundle时获取hash
调用自己封装的SBP ContentPipeline.BuildAssetBundles()
, 遍历IBundleBuildResults.BundleInfos
可以取到对应的hash和crc,
如果用旧的BuildPipeline.BuildAssetBundles()
, 也可以通过manifest取到对应的hash,但如果想拿到crc,需要手动传参数进去。
另外,需要设置打包压缩格式为LZ4。默认的LZMA会重新压缩成LZ4,造成比较明显的卡顿。
2. 加载AB时的缓存机制
C#
var uwr = UnityWebRequestAssetBundle.GetAssetBundle(url, hash, crc);
怎么样,是不是非常简单?只需要填上hash参数,就可以依靠Unity内部机制实现边下边玩。hash
也不一定是hash,实际作用只是一个版本号,只要请求的时候对应的版本的资源在缓存中存在,就会下载新的,否则就读缓存中的,如果不填这个参数就是默认值0)
crc参数是用来校验的,如果AB和调用时的crc对不上,uwr.downloadHandler.error
会表现出来,并且取不到资源。默认值0表示不进行校验
3. 优缺点
优点自然是非常简单,改一下就能用,如果要部分资源放进包里,部分资源边下边玩,改一下判断就行。
缺点是没法精细操作,资源出问题了最简单粗暴的就是直接Caching.ClearCache
,没有办法对单个文件进行完整性检查。