背景：应用更新在软件开发维护领域属于高频使用的场景，作为基础模块，决定软件的使用稳定和达到预期软件使用效果，重要性不言而喻。应用在更新后受应用市场上架审核的影响，客户端和服务端无法同步保持代码，服务端通常需要兼容多个版本的客户端，在特别的版本功能下，需要强制让客户端更新到最新版本来使用。当前由于现有的应用更新方案存在不稳定，存在问题，需要解决。
当前不稳定的更新推送：
- 能够跳过强制更新，例如在发布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 判断推送客户端