移动端版本更新方案，支持灰度发布，强制更新，控制更新范围，更新平台等操作

随着程序业务量的上升，让整体用户全部版本更新时越来越提心吊胆，担心出问题，所以需要引入灰度发布机制，并且有些业务和现有业务冲突，必须让用户强制更新才能使用新功能，还有一些更新只想提示指定范围的用户，所以现整理一套版本更新方案，以供大家参考。

基础概念：

最新版本号    ——  管理员等程序上线通过审核后，把当前程序的最新版本号手动录入后台管理系统，以做更新校验用。

是否出弹框    ——  在程序首页是否出更新提示的弹框。

是否强制更新 ——  在程序首页出更新提示的弹框，并且此弹框是否能被关闭。

更新范围         ——  根据用户的类型，地域范围和当前版本号等信息判断是否要提示更新。

更新内容         ——  弹框内的更新提示文案。

对应平台         ——  判断这次更新提示适用于哪个平台（防止iOS和Android版本号和更新内容不统一）。

设置/检测版本 —— 在设置界面增加用户直接检测版本的按钮，如果最新版本号大于当前版本号，就出更新弹框，可以选择关闭或去更新。

根据此设计方案

Cms管理系统只需考虑对更新提示信息的录入操作，除了上图的录入内容，还需注意最好每次的录入都保存一条记录，防止更新过程中，对之前的版本记录不清楚，并且更新提示发布时可以设定生效时间，以防录入错误马上生效。

移动端只需请求接口时上传自己的token，当前程序版本号和平台类型，然后接受返回数据，在首页只需根据“是否出弹框”，“是否强制更新”，“更新内容”，“版本号”四个字段进行业务判断处理。在设置/检测更新界面，只需根据“更新内容”，“版本号”两个字段判断是否出更新提示。

服务接口端需要接受移动端的token，当前程序版本号和平台类型，然后和Cms管理系统录入的更新信息作对比，确定返回给移动端怎么样的提示信息。

后记

如果上图的更新提示方案既不想让用户频繁刷新更新接口，又想完全拦截住老版本的冲突业务，还可以在程序所有接口上加版本号的公共参数，如果接口判断是老版本号，已经不支持现有业务，可以在接口公共返回值层面提示用户更新。