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版本状态为有效(也就是最新版本)有且只能各有一个,该部分修改版本状态时需进行控制。
这种实现方案的核心在于:只需要关注当前生效版本(即最新版本)的更新方式即可。
其校验流程如下:
-
优点:
简单直接,无需了解历史版本所用的接口信息
-
缺点:
- 存在“误伤”,会扩大强制更新用户的范围,举个例子,新上线版本存在重大BUG,需要重新发版,针对存在BUG的版本需强制更新,这样的场景下,上述更新方式会强迫所有用户强制更新,扩大了伤害范围。
- 用户不连贯使用时,会产生漏洞,举个例子,用户使用1.0版本,1.1版本强制更新,1.2版本非强制升级,在1.1到1.2期间,用户未启动App,当用户再次使用App时,当前最新版本为1.2,版本检查为非强制更新,这样的场景,就影响了用户的正常使用,因为用户错过了1.1的强制更新,极有可能影响接口正常使用。
关于缺点中的第2个问题可用的解决方案:在版本更新校验时,可增加一项校验,用户使用版本与最新版本之间如果存在强制更新版本,则该次升级即为强制更新。