撇开那种几乎每次都搬出 NPC 角色固定说明的 app 更新说明(是,Facebook app 就是在说你 XD),其实大部分的应用程序更新,都是可以用简单的条列说明来让使用者快速掌握此次更新的差异到底在哪。类似这样的比对方式,也可让更新以更有效率的补丁方式来减肥(压缩)每次更新的文件尺寸。

针对 Google Play 上的应用程序,Google 在今年初时就已采用了 BSDiff 的差分更新技术,可与原本的主程序文件尺寸相较之下,达到平均约 47% 的文件尺寸压缩成效。今天,他们则是又再推了一个新的逐档(File-by-File)算法,将可更进一步将平均的压缩率表现提高到至少 65%。

甚至在有些应用程序如 Netflix 的近期补丁中,更是达到 92% 的更新档压缩效果(采用 BSDiff 则为约 52%)。以上听起来好像省下了不少流量压力 -- 根据 Google 估算,至少一天就可省下约 6PB 的文件量!不过这样的演算法可是将仰赖更多移动设备的运算性能呢。Google 那一端会先将开发者提供的旧文件与更新后的文件解压缩来比对差异之处,再产生一个描述 Patch 档(所以文件才会更小)。而设备在下载到这个「更新」后,会解压缩旧的应用程序文件来按图索骥加入这些更新项目,然后再压缩制成 APK 来完成更新。

没错,由于这比起以往下载后就安装更新的简单动作多了需要运算的步骤,所以除了在执行前设备上的 APK 需要与服务器上的完全一致之外,多了的比对运算程序也不意外地将带来更多的耗电与性能占用。因此,Google 目前将会把这样的更新方式限制在「自动更新」之下。

根据官方的描述,File-by-File 的更新耗时也会因手机的运算性能而有所差异。基本上如果是 2015 年以后的设备,大致都可以用每秒 1MB 来估算可能的更新安装耗费时间,倘若是更入门或者更旧处理器的机型的话,就将耗时更久。是说,反正应该也是手机在充电闲置时才会做这样的动作,用运算来换取耗费较少的网络资源,其实也是个不错的方式。

只是不知道未来假若将此运算法运用到一般的更新上的话,下载时间 vs. 比对安装时间不知道哪边会比较省时,应该会是个很有趣的议题。