HUNTER-HAITAO.github.io

App版本升级策略

App升级更新方式包括：强制更新、提示更新、不提示更新。

后台主要有两种方案实现对App版本更新的管理

• 以历史版本（即用户所用版本）为更新依据的实现策略
• 以最新版本为更新依据的实现策略

以历史版本（即用户所用版本）为更新依据的实现策略

原型图如下：

上述App的iOS版共存在4个版本：2.0（当前最新版本）、1.2、1.1与1.0，其中iOS与Android最新版本有且只能各有一个，修改版本状态时需进行控制。

在例子中，2.0为最新版本，1.2为提示升级、1.1为强制升级、1.0为不提示升级。各版本用户启动App后，依照用户所用版本的状态给予用户相应的升级提示。

这种实现方案的核心在于：历史版本均有各自的状态，根据历史版本的状态决定前端的更新方式。

校验流程图如下：

• 优点：

  灵活控制各个历史版本的升级方式，可以指定修复相应的历史版本，不会造成大规模的“误伤”；

• 缺点：

  每次发版都需要对历史版本进行状态修改，如果接口变动对历史版本产生影响，需明确出对哪些历史版本有影响，也就要求了上传新版本的项目负责人需要对历史版本有重新的了解。

以最新版本为更新依据的实现策略

原型图如下：

以上图为例，其中iOS与Android版本状态为有效（也就是最新版本）有且只能各有一个，该部分修改版本状态时需进行控制。

这种实现方案的核心在于：只需要关注当前生效版本（即最新版本）的更新方式即可。

其校验流程如下：

• 优点：

  简单直接，无需了解历史版本所用的接口信息

• 缺点：

  1. 存在“误伤”，会扩大强制更新用户的范围，举个例子，新上线版本存在重大BUG，需要重新发版，针对存在BUG的版本需强制更新，这样的场景下，上述更新方式会强迫所有用户强制更新，扩大了伤害范围。

  1. 用户不连贯使用时，会产生漏洞，举个例子，用户使用1.0版本，1.1版本强制更新，1.2版本非强制升级，在1.1到1.2期间，用户未启动App，当用户再次使用App时，当前最新版本为1.2，版本检查为非强制更新，这样的场景，就影响了用户的正常使用，因为用户错过了1.1的强制更新，极有可能影响接口正常使用。

  关于缺点中的第2个问题可用的解决方案：在版本更新校验时，可增加一项校验，用户使用版本与最新版本之间如果存在强制更新版本，则该次升级即为强制更新。