背景：应用更新在软件开发维护领域属于高频使用的场景，作为基础模块，决定软件的使用稳定和达到预期软件使用效果，重要性不言而喻。应用在更新后受应用市场上架审核的影响，客户端和服务端无法同步保持代码，服务端通常需要兼容多个版本的客户端，在特别的版本功能下，需要强制让客户端更新到最新版本来使用。当前由于现有的应用更新方案存在不稳定，存在问题，需要解决。背景：应用更新在软件开发维护领域属于高频使用的场景，作为基础模块，决定软件的使用稳定和达到预期软件使用效果，重要性不言而喻。应用在更新后受应用市场上架审核的影响，客户端和服务端无法同步使用兼容接口，服务端通常需要兼容多个版本的客户端，在特别的版本功能下，需要强制让客户端更新到最新版本来使用新业务。当前由于现有的应用更新方案存在不稳定的问题，需要解决。
当前不稳定的更新推送：
- 能够跳过强制更新，例如在发布3.0.0这个版本后，推送强制更新3.0.0, 2.9.0可以正常更新版本2.8.0 可能可以跳过更新；或者在推送3.0.1可选更新，2.9.0的老用户未在3.0.0的期间内正更新到3.0.0, 2.9.0的用户就可以跳过3.0.1的更新，继续使用2.9.0的客户端，这样某些功能就会和预期不致，甚至报错。
- 用户在非更新页面可以跳过更新检测，目前客户端接收更新是在用户打开首页时调用指定的接口来获取更新指令，如果用户长时间停在其它任何页面，无法及时收到推送更新。
原因：
- 该问题在设计时只考虑的可选更新和强制更新 两种类型，未考虑继承关系，当用户暂停使用，恢复使用时面临可选更新时，则可能会跳过上个版本的强制更新
- 该问题是移动端考虑电池性能，只在用户启动时检查版本，其它页面则不处理
解决方案：
- 服务端全接口下发版本更新指令，客户端全接口接收更新指令，当服务端发布更新后，用户可以在任意的页面收到更新通知，按更新需要强制或可选更新，为了不造成打断用户的糟糕体验，客户端也可以在部分接口时保持静默，如下单、支付等接口。
- 服务端判断强更指令，跨版本，可选更新存在时，逻辑判断强更到最新，如3.0.0强更后，发布3.0.1可选更新，客户端等于3.0.0时，可选更新，低于3.0.0时，3.0.1转为强更，用户直接更新到最新版本，对于版本的控制由服务端决定，去除客户端的判断不准确性。
实现：
- 客户端全接口 请求 header 中上送版本号、设备标识、设备型号
- 版本号：用于更新对比版本的依据，客户端应保证版本的唯一性，参照：版本号命名规范。
- 设备标识：Android、iOS 判断推送客户端类型。
- 设备型号：Huawei/p30、Oppo/a20、Xiaomi/xpro、iphone/15pro 等，1. 用于判断客户端推送渠道，不同应用商店可按渠道单独推送更新。2. 日志记录，用于分析日志查错使用。
- 服务端全接口 响应 header 中返回 更新类型、更新版号、更新说明。
- 更新类型：强制更新、可选更新，当客户端接收到强制更新指令时，弹窗提示，按类型是否可以更新，部分接口适当忽略，如支付和下单接口。更新规则参照：版本号命名规范，跨版本可选更新继承强更等逻辑在此实现。
- 更新版号：升级版本号。
- 更新说明：发布更新的详情说明内容。
- 后台增加版本发布、列表页面、，增加版号发布内容及相应功能
- 版本列表：查看历史及当前版本号，统计和展现版本占用户比例。
- 发布：新增版号推送更新，推送指定型号（Android、iOS）、市场渠道（华为、小米、Oppo）、内更新（安卓无市场），内容等。
- 撤销/回滚：当新推送的版本出现重大异常问题时，及时撤回推送。已推送更新的，强制用户降级到旧版本（部分使用）