AssetBundle粒度规划

整理来自UWA问答 AssetBundle 粒度规划

（1）AssetBundle粒度建议不宜过细，特别是一个资源一个AB。粒度过细，一方面会导致加载IO次数过多，从而增大了硬件设备耗能和发热的压力；另一方面，Android平台上在不Unload的情况下，每个AssetBundle的加载，其每个文件的SerializedFile内存占用均为512KB（远高于其他平台），所以当内存中贮存了大量AssetBundle时，其SerializedFile的内存占用将会非常巨大同时。
（2）为了提高加载方面的性能，粒度不宜过粗。一方面， WWW加载会形成一个比较大的WebStream，一般来说是压缩AB的4~5倍，会占用比较高的内存；另一方面，当AB较大（比如大于5MB）时，其加载开销会很大。所以，我们对此做了一些实验，发现将AB压在1MB以下是一个加载比较可以接受的情况。不过随着LZ4的引入，很多情况已经变化了，基于其Chunk的加载特点，AB加载很快，且内存占用要比之前小很多。所以LZ4的AB其实可以考虑更加粗粒度一些。
**（3）对于需要热更新的AB，需要考虑实际情况控制AB的大小，粒度不宜过粗。**我们打ab的目的是进行资源的增量更新，如果规划的不好就会出现我本来只更新一小部分资源（几十k），但是更新ab的时候需要更新几m；
建议
（1）即便是LZ4的AssetBundle，其加载方式不同，加载效率也可能完全不一致，以下三种不同方式从加载AB到AB.Load的耗时对比。可以看出，New WWW加载出现了明显的时间差异。因此，尽可能建议通过LoadFromFile(Async)来对AB进行加载。

（2）对于AB的打包，尽可能把逻辑上同时出现（一个Prefab中非Share的Asset）、小而细碎的资源（Shader、Material、粒子系统等）尽可能打包在一起，并通过LoadAll来进行加载，因为这样会带来更好的加载效率。

（3）根据依赖树进行的最优打包策略（这里不考虑加载因素），公共资源单独打ab，独立资源打到一起，再将shader字体等其他细碎并且需要常驻内存的资源打包到一起，启动游戏的时候常驻内存。