第二章：更新机制核心概念
好，咱们正式开始聊自动更新的核心概念。说实话，这部分内容看起来基础，但很多团队翻车就翻在这些地方。我自己带过好几个项目，每次复盘时发现，版本号管理混乱、更新包类型选错、策略设计不合理，这三个问题几乎占了故障原因的八成。
2.1 版本号管理
版本号这东西，说白了就是给软件贴个标签。但你别小看这个标签，它决定了你能不能精准定位问题。
我个人习惯用语义化版本号，格式是：主版本号.次版本号.修订号。举个例子：2.1.3。
- 主版本号：做了不兼容的API改动时递增。比如从v1跳到v2，意味着老版本可能没法直接升级。
- 次版本号：新增了功能，但向后兼容。比如从2.1到2.2，加了个新功能，老功能不受影响。
- 修订号：修了bug或做了小优化。比如从2.1.3到2.1.4，只是修复了一个崩溃问题。
重要提醒：版本号不是随便写的。我见过一个项目，版本号从1.0直接跳到2.0，结果用户反馈说「我明明升级了，怎么界面没变？」——因为开发团队只是改了个版本号，功能根本没变。这会让用户失去信任。
我在项目中遇到过最头疼的事：版本号冲突。客户端上报的版本号是1.2.3，但服务端记录的却是1.2.3-beta。你想想看，这怎么判断哪个更新？后来我强制要求：所有版本号必须统一格式，不允许出现「1.2.3-beta」这种非标准写法。要么用1.2.3，要么用1.2.3.1000（内部构建号）。
2.2 更新包类型
更新包类型，说白了就是「怎么把新代码发给用户」。主要有三种：全量包、增量包、差分包。
2.2.1 全量包
全量包最简单粗暴——把整个应用打包成一个文件，用户下载后直接覆盖安装。优点是实现简单，缺点是用户每次都要下载几百兆甚至上G的数据。
我记得有个项目，用户量几百万，每次发全量包，CDN带宽费用高得吓人。后来我们算了一笔账：一个100MB的全量包，100万用户下载，光带宽成本就够买几台服务器了。
2.2.2 增量包
增量包只包含新版本相对于旧版本的变化部分。比如你只改了一个配置文件，增量包可能只有几KB。用户下载后，客户端自己把增量内容合并到旧版本中。
这里有个坑：增量包依赖旧版本。如果用户跳过了某个版本，比如从v1.0直接升级到v3.0，增量包可能就失效了。我建议的做法是：保留最近3个版本的增量包，同时提供一个全量包作为兜底。
2.2.3 差分包
差分包是增量包的升级版。它用算法（比如bsdiff）对比新旧两个版本的二进制文件，生成一个「差异文件」。这个差异文件比增量包更小，但生成和合并的计算成本更高。
我曾经在一个嵌入式项目里用过差分包。设备存储空间只有64MB，全量包根本放不下。差分包只有10MB左右，完美解决了问题。但代价是：每次生成差分包需要跑十几分钟的算法，而且设备端合并时CPU占用很高。
| 类型 | 包大小 | 生成成本 | 合并成本 | 适用场景 |
|---|---|---|---|---|
| 全量包 | 大 | 低 | 低 | 首次安装、兜底方案 |
| 增量包 | 中 | 中 | 中 | 常规更新 |
| 差分包 | 小 | 高 | 高 | 存储受限、带宽受限 |
我的建议：对于移动端应用，优先使用增量包。对于桌面端或IoT设备，如果网络条件差，可以考虑差分包。但无论选哪种，一定要保留全量包作为降级方案。
2.3 更新策略
更新策略决定了「什么时候更新」和「用户能不能拒绝」。常见的三种策略：静默更新、强制更新、可选更新。
2.3.1 静默更新
静默更新就是用户完全无感知的情况下完成更新。后台下载、后台安装、后台重启。听起来很美好，但风险也最大。
我曾经在一个金融App里用过静默更新，结果出事了：新版本有个bug，导致支付页面白屏。用户完全不知道更新了，还以为是自己手机坏了。从那以后，我定了个规矩：静默更新只适用于修复非关键bug或优化性能，绝对不能用于功能变更。
2.3.2 强制更新
强制更新就是「不更新就别想用」。用户打开App，弹出一个对话框，只有「立即更新」一个按钮。这种策略适用于安全漏洞修复或重大功能变更。
但强制更新有个副作用：用户反感。你想想看，用户正急着用App，突然被强制更新，体验极差。我建议的做法是：给用户一个缓冲期。比如第一次弹窗提示「3天后强制更新」，第二次弹窗提示「1天后强制更新」，最后才真正强制。
2.3.3 可选更新
可选更新最温和。用户可以选择「稍后再说」，也可以选择「立即更新」。适用于非紧急的功能更新或体验优化。
但可选更新也有问题：用户可能永远不更新。我见过一个项目，可选更新上线半年，更新率不到30%。后来我们加了「版本过期提醒」：如果用户使用的版本超过3个月，就自动转为「建议更新」。
避坑指南：我曾经在一个项目中，把「强制更新」和「静默更新」混用了。结果用户手机在后台被强制更新，然后新版本有bug，导致App闪退。用户完全不知道发生了什么，只能卸载重装。那次事故让我明白：强制更新必须让用户知情，静默更新必须保证稳定性。
2.4 版本号与更新策略的联动
版本号不是孤立的，它和更新策略紧密相关。我一般这样设计：
- 修订号变化（如2.1.3 → 2.1.4）：静默更新或可选更新。因为只是修bug，不影响功能。
- 次版本号变化（如2.1 → 2.2）：可选更新。因为新增了功能，用户可以选择是否体验。
- 主版本号变化（如2.x → 3.0）：强制更新。因为可能涉及不兼容的改动，旧版本必须升级。
嗯，这里要注意：这个规则不是绝对的。比如安全漏洞修复，即使只是修订号变化，也应该强制更新。我一般会在服务端配置一个「更新策略表」，根据版本号和漏洞等级动态决定策略。
好了，核心概念就这些。下一章咱们聊聊更新包的生成和分发，那才是真正动手的地方。