程序的更新总结

一、更新类型

  程序更新逻辑是软件维护与用户管理的核心环节，根据应用场景、技术实现和用户需求的不同，主要可分为以下六种类型，每种类型在适用性、流程和风险上各有特点：

---

1.1 全量更新（Full Update）

• 核心逻辑：替换整个应用程序或主模块，需下载完整新版本安装包。
• 实现流程：
  1. 版本检测：客户端对比本地版本号与服务器最新版本号（如通过API返回的JSON数据)。
  2. 下载安装包：从服务器获取完整安装包（如APK/IPA文件）。
  3. 覆盖安装：引导用户安装新包，替换旧版本。
• 适用场景：主程序结构重大变更、跨大版本升级（如从V1.0到V2.0）。
• 优缺点：
  • ✅ 兼容性强，减少依赖冲突。
  • ❌ 下载体积大，消耗用户流量；需中断当前应用。

---

1.2 增量更新（Delta Update）

• 核心逻辑：仅下载差异部分（补丁），本地合并生成新版本。
• 关键技术：
  • 差分算法：如bsdiff算法生成新旧版本二进制差异文件。
  • 本地合并：客户端应用补丁文件，重构完整新版本。
• 适用场景：小版本迭代（如V1.0.1 → V1.0.2），带宽敏感环境。
• 案例：Windows系统补丁更新、手游资源包更新。
• 风险：差分计算错误可能导致合并失败，需强校验机制。

---

1.3 热更新（Hot Update）

• 核心逻辑：运行时动态加载新代码，无需重启应用。
• 移动端实现：
  • Android：
    • 代码替换：通过AndFix、JSPatch等框架替换Java方法或类。
    • 插件化：独立模块（如Dex文件）动态加载。
  • iOS：
    • JavaScriptCore：利用JSPatch执行JS脚本修改Objective-C方法（需规避Apple审核限制）。
    • React Native/Flutter：直接更新JS或Dart脚本资源。
• 适用场景：紧急Bug修复、UI微调、活动页面更新。
• 限制：
  • iOS对热更新审核严格，禁止修改核心逻辑。
  • 无法修改原生二进制代码（如SO库）。

---

1.4 静默更新（Silent Update）

• 核心逻辑：无感自动更新，用户无需操作。
• 策略：
  • 后台下载：在WiFi环境下自动下载更新包。
  • 延迟安装：下次启动时应用更新（如标记旧文件，重启替换)。
• 适用场景：安全补丁、后台服务更新。
• 风险：占用磁盘空间，失败时需回滚机制。

---

1.5 强制更新（Forced Update）

• 核心逻辑：强制用户更新，否则禁止使用。
• 触发条件：
  • 安全漏洞（如数据泄露风险）。
  • 旧版本协议不兼容（如API接口废弃）。
• 实现方式：
  • 服务器返回force_update标志，客户端阻塞主流程并弹窗提示。
  • 用户必须点击“立即更新”才能继续。

---

1.6 模块化更新（Modular Update）

• 核心逻辑：按需更新独立功能模块。
• 技术实现：
  • 微服务架构：业务模块解耦，独立部署（如Docker容器）。
  • 动态加载：主程序调用时下载并加载新模块（如Android动态特性模块）。
• 适用场景：大型应用（如电商平台）、功能插件化设计。
• 优势：减少更新体积，支持灰度发布。

---

1.7 更新逻辑对比与选型建议

类型	更新粒度	用户干扰	适用场景	技术复杂度
全量更新	整个应用	高（需安装）	大版本迭代、框架重构	低
增量更新	差异文件	中	小版本优化、带宽受限环境	中
热更新	方法/类级别	低	紧急修复、UI调整	高
静默更新	后台自动处理	无	安全补丁、服务更新	中高
强制更新	阻塞式更新	极高	重大漏洞或协议变更	低
模块化更新	独立功能模块	中	大型应用、插件化架构	高

二、更新时如果程序正在运行的处理方式

2.1 添加标记，重启时替换

  更新的文件命名时添加一些标记，比如 xx_new.exe 。后面等相应的文件不在使用时，替换掉旧文件。

2.2 创建版本号文件夹

  需要原本的项目结构中存在版本号文件夹，当版本号目录下的文件需要更新时，只要新建一个版本号文件夹，然后修改注册表中的相关信息，后续重启是删除旧的版本号文件夹即可。【适用范围小一些】