现在手机游戏的常规更新方案都是在启动时下载所有资源更新，游戏质量高的、用户粘性大的有底气，先安装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时的缓存机制
var uwr = UnityWebRequestAssetBundle.GetAssetBundle(url, hash, crc);
怎么样，是不是非常简单？只需要填上hash参数，就可以依靠Unity内部机制实现边下边玩。hash也不一定是hash，实际作用只是一个版本号，只要请求的时候对应的版本的资源在缓存中存在，就会下载新的，否则就读缓存中的，如果不填这个参数就是默认值0）
crc参数是用来校验的，如果AB和调用时的crc对不上，uwr.downloadHandler.error会表现出来，并且取不到资源。默认值0表示不进行校验
3. 优缺点
优点自然是非常简单，改一下就能用，如果要部分资源放进包里，部分资源边下边玩，改一下判断就行。
缺点是没法精细操作，资源出问题了最简单粗暴的就是直接Caching.ClearCache，没有办法对单个文件进行完整性检查。