AssetBundle增量打包
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了AssetBundle增量打包相关的知识,希望对你有一定的参考价值。
参考技术A最近在给项目做增量打包的功能,之前也有其他项目碰到增量打包差异过大的问题。
这里记录分享下做法与思考过程,主要解决以下两个问题:
首先AssetBundle打包可以概括把给定的资源打成一个或多个AssetBundle。每个AssetBundle包含一个或多个资源,AssetBundle之间存在依赖关系,具体的打包规则应该是每个项目根据资源进行配置的。
第一次全包,相当于给所有的资源文件分配归属AB。第二次增量打包,不仅要对新增的文件分配归属AB,还要把已经删除的文件从AB里面移除,最后确定修改的AB文件列表。Unity 5.0以后的AB打包接口已经支持增量打包,直接使用就可以了。
增量包一致性是指我们在不修改任何资源的情况下,增量包与首包的一致性。正常的情况下如果不修改任何资源,两次打包出来的包应该保持一致。然而由于项目做了较多的预处理,最后发现差异非常大。
通过分析打包日志,发现项目在打包之前的预处理环节处理的资源不能保持一致性。包括CreateAsset,CreatePrefab,ReplacePrefab,SaveScene等行为。对于新创建的资源,由于guid发生变化会导致增量包不一致。对于Prefab和Scene资源,则是尽管Object并没有发生变化,但是Object与Object之间的顺序会发生变化,这也会导致增量包不一致。
最后问题就变成了解决预处理环节资源的一致性问题。
如果把所有预处理修改的资源都提交入库,这样应该就可以解决增量包一致性的问题了。但并不是所有的资源都能这样直接入库,而且自动化环节变手工环节还会有一些其他问题。 这里把修改后资源提交到一个其他库就避免了冲突问题。
然后修改预处理环节的逻辑为,如果资源修改了重新执行,如果资源无修改则直接拷贝库里文件。对于meta文件,则应该不过是否重新生成,都要复用避免guid不一致的问题。再设计一个全局开关来控制新的增量逻辑,如果预处理规则修改了,则可以全部重新生成。正常已经上线是不允许做这样大的改动,不过日常开发过程中修改预处理规则是很常见的,所以需要支持。
修改的资源相当于复制了一份,为了避免重新生成guid,这些资源应该放在Assets目录之外,对于生成出来的资源则没有这方面的限制。
在做完第一步,保持了原始资源的一致性后,增量打包这个事情可以算搞定了。由于资源没有发生变化,所以即使把所有资源都重新打一次包最后的结果也是一样的。不过既然是做增量打包,我们还是要考虑到整包的构建时间过长。所以这里要解决的问题就是打包时间优化。
首先,这里还是包含了两个环节,一个是资源预处理,另外个是资源打包。前面已经讨论过为了资源一致性,我们需要把资源保存下来,没有修改的资源不需要重新生成。这里为节省打包时间,其实做出了巨大贡献。在剖析打包时间的时候,发现ReplacePrefab,SaveScene这些Unity API调用占用了大量的时间。这里并没有多少办法可以优化这些API调用的时间,一个显而易见的好办法就是少调用几次。
对于如何获取修改的资源文件列表,可以通过svn,git等版本控制软件获取。在得到了文件修改列表之后,我们也知道了预处理环节中哪些资源是可以复用的,哪些资源是需要重新执行预处理的。在后面的打包环节也同样是利用这个资源差异列表来做增量。
打包环节的增量就是确定哪些包需要打,这里是根据差异列表计算出哪些AB需要打包。由于AB之间会有依赖关系,所以要递归算出最后需要打包的AB列表。然后根据AB打包列表按打包规则顺序进行打包即可。
资源一致性这个问题可能是大部分项目打包过程中会碰到的,因为Unity没有解决这个问题。这里通过自己保存资源以及维护资源修改列表来解决这个问题。顺便这个做法还能节省很多的构建时间,做增量预处理,一举两得。
其实是在思考过程中突然意识到其实是要做这样一件事情,想到后整个事情并不复杂。
以上是关于AssetBundle增量打包的主要内容,如果未能解决你的问题,请参考以下文章