这几天爆出了好多关于 「 企业微信 」的新闻，这又会是一个超级App吗？这事估计只有哆啦A梦才知道，不过提醒了我好久没写 「 超级App诞生记 」这个系列了，今天就 来翻一下这个话题的牌子，聊一下App的 「 增量更新 」。

我们都知道，一个App的早期发展都是很狂野的，总是要做各种不同的尝试，才能摸清自己的方向。这种狂野的尝试导致的就是快速的版本迭代，每隔一两周就会有一次更新。产品经理当然是很爽的了，自己的想法能够马上得到验证，而对于用户来说，他的感觉就是 「 怎么这App老是更新，每次都是几十兆，这个月的流量全给它费了 」，然后他也许就会选择拒绝更新 。

这个时候，你就应该考虑给App加上一个 「 增量更新 」 的功能了。顾名思义，增量更新就是只将App中有发生改变的部分发送给用户，而不是每次都重新下载一个完整的安装包，这样就可以为用户节约大部分的流量了。这个功能的原理很简单，如果交给你做，你要怎么操作呢？

1. 生成差异包
   首先要做的就是将App的最新安装包(V5)与历史发布版本的安装包(V3)进行差分对比，得到一个差异包 (V5-V3) 。如果有多个历史版本，那么就要用最新包与多个历史包分别对比并生成相应的差异包。这些操作都可以在服务器上用脚本来批量完成，不需要自己动手一个个的来生成。

2. 下发差异包
   当某个老版本(V3)的App开始检查更新的时候，需要将自己当前的版本信息发送给服务端，然后服务端判断后，选择对应的差异包(V5-V3)下发。

3. 合成新包
   当App收到差异包后，就要开始合成新包了，首先就是想法取出当前历史版本的安装包 (V3) ，然后使用与生成差异包相反的办法，将历史包与差异包合成一个新的安装包。

4. 校验完整性
   得到的新安装包你敢直接拿来用吗？反正我是不敢的，因为我并不能确认，这个合成的新包就是我想要的最新安装包 (V5)，在拉取差异包、获取当前历史包、合成新包这些过程中，都是有可能出篓子的，导致最终合成的新包并不完整。所以，在合成新包前，我们需要校验当前历史包的Hash值以及差异包的Hash值，合成新包后，也要校验新包的Hash值，只有这三个Hash值都与预期匹配，我才能确认新包是完整的，并用来进行升级操作。

根据Google Play的统计，大部分应用的增量更新包只有完整包的25%大，可以为用户节约四分之三的升级流量。所以，在你狂野的需求表里面，加上一项增量更新吧，我们要一款环保低碳的超级App～

本文来自给产品经理讲技术（微信公众号：pm_teacher）授权发表，转载请联系原作者，违者必究。