整包和增量包的区别魅族

整包是一个完整的系统升级包，而增量包则只是更新一些文件。

根据八分网资料显示，整包是指完整的系统升级包，包含了完整的系统镜像，可以覆盖手机的所有分区，而增量包是指仅包含了升级的部分文件的升级包，它只更新已有的文件，不会修改系统的其他部分。

如果想要彻底升级系统，或者系统出现了严重问题，建议使用整包升级。如果只想升级一些文件，或者不想清除数据，建议使用增量包升级。

最近在给项目做增量打包的功能，之前也有其他项目碰到增量打包差异过大的问题。

这里记录分享下做法与思考过程，主要解决以下两个问题：

首先AssetBundle打包可以概括把给定的资源打成一个或多个AssetBundle。每个AssetBundle包含一个或多个资源，AssetBundle之间存在依赖关系，具体的打包规则应该是每个项目根据资源进行配置的。

第一次全包，相当于给所有的资源文件分配归属AB。第二次增量打包，不仅要对新增的文件分配归属AB，还要把已经删除的文件从AB里面移除，最后确定修改的AB文件列表。Unity 50以后的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没有解决这个问题。这里通过自己保存资源以及维护资源修改列表来解决这个问题。顺便这个做法还能节省很多的构建时间，做增量预处理，一举两得。

其实是在思考过程中突然意识到其实是要做这样一件事情，想到后整个事情并不复杂。