给产品经理讲技术丨超级App诞生记(三)

【文章摘要】一个App的早期发展都是很狂野的。

【相关推荐】

给产品经理讲技术丨超级APP诞生记(二)

给产品经理讲技术丨超级APP诞生记(一)

给产品经理讲技术丨没线，并不可怕？

给产品经理讲技术丨提需求的正确姿势是什么

给产品经理讲技术丨产品后悔药来了，讲讲热补丁技术

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

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

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

• 生成差异包

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

• 下发差异包

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

• 合成新包

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

• 校验完整性

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

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

PS：如果你有什么技术上的困惑，可以在微信公众账号pm_teacher留言骚扰我，就当你多了一个搞技术的朋友，有点小牛B哦！

欢迎添加微信公众号：给讲技术