我有一台 Ubuntu 电脑和一部 Android 手机，但我一直很困惑，为什么 Ubuntu 上的默认更新管理器和手机上的 Google Play 不通过计算现有版本与新版本之间的差异来更新现有版本的应用程序。我确信其他操作系统也是如此（这就是为什么这个问题不在 Ask Ubuntu 或 Android 爱好者中）
例如，考虑一下谷歌地图（截至 2012 年 4 月 18 日）。“新功能”部分显示它包含一个关键错误修复。可以肯定地说，很多代码都没有修改，但是，当您更新应用程序时，它会下载超过 6 MB，就像是全新安装一样。
为什么更新服务器不能计算已安装版本的差异（像 git 一样）并只发送差异？对所有版本都这样做真的那么难吗？节省带宽难道不是主要动机吗？
编辑 2016 年 12 月 6 日：谷歌刚刚宣布他们将使用逐个文件修补来更新 Android APK -节省数据：应用更新大小减少 65%
答案1
有三个级别可以通过仅传输差异来优化下载大小。
包级别仅传输更新的包。这已经完成了。如果你查看包的下载大小，你会发现大多数包都非常小。因此这可以节省最多的带宽。
包内的文件仅传输软件包内已更改的文件。软件包管理不仅仅是将文件复制到固定位置。有些配置文件可能已自动适应您的系统。可能会有手动更改。如果不先上传已安装的文件，很难可靠地找出差异。
内部文件差异大多数文件（尤其是大文件）都是二进制文件。如果要修补的文件有细微变化（例如不同的构建时间戳），则很难想象二进制文件有可靠的修补算法。另一方面，对于文本文件，git 应用的旧 diff 和 patch 算法可能效果很好，但可能不值得付出努力。
另一个问题是，你不知道哪个旧版本会被更新。用户可能跳过了中间的更新。当然，包管理器可以请求服务器发送与某个版本的差异，但这会给服务器带来巨大的负担来生成差异。我怀疑服务器维护者会允许这样做。
概括：可以轻松可靠地完成的事情已经完成了。剩下的工作由软件包管理员负责制作小软件包，以保持更新较小。
答案2
从根本上讲，这对开发人员来说在技术上很难。而且带宽很便宜——或者说，费用由用户买单。
Google Chrome 投入了大量精力开发 Chrome 二进制文件的增量更新http://blog.chromium.org/2009/07/smaller-is-faster-and-safer-too.html。
Fedora 开发了“delta rpm”来发送增量包更新。有趣的是，由于我的计算机网络连接很快但处理器很慢，因此这些更新对我来说安装起来实际上更慢。