背景
现有的项目中，App的升级率不高，虽然中间存在多个强升版本，但是依旧大量存在低版本的用户。轻(比如小bug)则影响用户体验从而损失用户，重(比如支付购买类严重漏洞被利用)则影响公司收益。
分析
可以从两方面来分析此问题。1.原生代码层面，2.接口层面。
原生代码层面分析
可能性1：很多App请求升级接口的逻辑往往放在进入App首页的时候，如果网络调用失败，则App可以继续使用。
解决方案1：可以将上次请求成功的数据进行缓存，如果调用失败则使用缓存数据。
缺点1：如果升级策略回滚，则线上用户仍然使用缓存数据去升级
缺点2：首次无缓存的时候，如果断网，仍然可以绕过
解决方案2：监听网络连接，如果请求失败，在连接上之后，再次请求接口
优点：开发量小，后端资源消耗少
缺点：如果是服务端临时性问题，没法解决（一般情况可忽略此情况）
解决方案3：所有接口添加版本校验逻辑，再返回统一错误码，手机端针对错误码统一处理
优点：覆盖全
缺点1：后端开发量大，如果是新项目，可忽略，如果是旧项目，慎用
缺点2：所有接口都检查，如果同一时间请求多个接口，则造成资源浪费。
解决方案4：同上，但是只是主要流程添加校验逻辑，比如登录、支付等主流程
优点：解决了方案3的缺点
解决方案5：开启一个service，在service中请求更新接口，如果失败，按照时间指数递增，延迟重新获取（2、4、8、16、32、64、128、256、512、1024，单位：秒，可设置次数阀值）直至成功
缺点：如果这几次都没成功，同样可绕过，可以增加阀值大小，也可以达到一定时间长度之后，不要以指数增长，比如2、4、8、16、32、64、128、256、512、1024、1024、1024...
总结：以上方案都可行，根据自身情况具体问题具体分析
可能性2：弹出框在强制升级的时候可以取消
解决方案：设置为不可取消的对话框
可能性3：强制升级的时候，升级过程中（下载、安装等过程），返回App，强制升级框消失
解决方案1：升级框设为不可取消，点击升级的时候，升级框也不会消失
解决方案2：在resume生命周期中添加对应逻辑，确保强升过程中，返回App，升级框再次展示
接口层面分析
可能性1：Android多个渠道配置因人为原因，导致漏配或者忘配
解决方案1：人员培训（和技术无关）
解决方案2：漏配或者忘配的渠道，走兜底方案，取默认官网渠道的配置（注意：渠道变更可能会涉及运营统计数据异常，谨慎采用）
可能性2：升级只考虑最新数据，没有兼容旧的强升数据
现象：比如当前手机版本为1，2为强制升级版本，3为非强制升级版本。从1到3，应该返回强制升级，目前返回非强制
解决方案：修改对应逻辑，如果最新的是非强制，则还要去匹配旧的数据，直至匹配到强升数据为止
更多考虑
后端
1.版本比对（可以在后端处理，也可以在前端处理）
分析：Android有两个字段代表版本，versionCode和versionName。versionCode：整型，比对非常简单。versionName，常见的是x.x.x的格式，但是需要考虑x.x.x.x和xx.xx.xx的格式
2.是否需要区分pad和phone
分析：有些App pad和phone是两套代码，线上的版本号不一致，则需要单独区分处理
3.考虑强制和非强制交替出现的情况
分析：正如上面所说，最新版是非强制升级，但是一旦中间存在强制版本，而低版本请求的时候返回的却是非强制，那么对用户侧影响非常大。一旦中间存在重大漏洞，则会对公司造成经济损失。
4.是否需要区分不同渠道
分析：大部分Android应用会存在多个渠道，多的甚至达到几十个。可能有些渠道审核时间差异或者某些其他原因，就需要针对某些渠道做单独的升级逻辑。
5.是否需要指定版本
分析：一般情况下强制升级的版本很少，普遍都是非强制。比如微信QQ等，很少见强制升级。如果某些旧版本存在致命级别的bug，但是最新版产品要求是非强制升级，这就需要针对有bug的旧版本做强制升级的处理。
既然能够支持指定版本，那么也要支持指定多个版本，因为不可能只有1个版本存在致命问题。
6.是否需要指定某一范围内的版本
分析：同上，某一个致命级别bug藏的够深，存在于多个版本，则需要对涉及的版本做个范围处理
7.考虑是否灰度
分析：一个新功能/技术改造的上线，可能会存在重大bug，如果一下子全量上线，会影响全部用户。采用灰度功能，可以先从部分用户开始，将问题暴露出来，集中整改，再发新版本或者热修复，从而减少对用户的影响。
问题1：但是app一般情况下可以由接口控制升级，也可以由应用市场控制升级，所以没法控制应用市场的灰度逻辑
问题2：灰度逻辑是否针对到user，很多情况下升级接口在登录/未登录都可以请求，未登录的情况下没法指定到人。可以使用token，或者未登录的情况下不能请求灰度的版本，可以根据业务需求具体分析。
手机端
1.可以直接走应用市场更新，点击升级的时候，跳转到指定应用市场，指引用户升级。
2.可以直接走app下载，则需要考虑是否加入断点续传，以及md5校验的功能，因为很多情况下会出现重复下载、安装解析失败等原因。如果apk文件是放到oss阿里云上的话，这些逻辑oss的sdk都已经支持。
总结：
一个健全的系统，应该要考虑以下几点（甚至更多我没有考虑到的地方），然后结合自身业务，最终采用其中的某些点。升级逻辑的控制粒度尽量要细，一旦有问题，降级策略也好针对性处理，对用户的影响就小。
手机端
1.考虑请求升级接口的时机
2.版本比对如果使用versionName的话需要考虑x.x.x.x和xx.xx.xx
3.考虑跳转市场升级，还是自行下载apk升级
4.强制升级框如果不点升级，不应该被取消（包括进入后台再进入前台、下载的时候返回、安装的时候返回等等情况）
5.下载是否考虑断点
6.下载是否考虑校验文件正确性
后端
1.版本比对如果使用versionName的话需要考虑x.x.x.x和xx.xx.xx
2.是否需要区分pad和phone
3.是否需要区分不同渠道
4.是否需要针对指定版本、多个指定版本、版本范围，做特殊处理
5.考虑强制和非强制交替出现的情况
6.考虑是否灰度
7.针对漏配考虑是否添加兜底方案
8.针对非强制，可以考虑添加每日弹框次数功能
补充说明
正常的版本更新，往往非强制要多于强制升级。
如果是非强制升级，则可以支持大于指定版本、小于指定版本、等于（1或N个）指定版本做非强制升级处理。同时会存在针对某些有致命bug的版本做强制升级处理，比如大于指定版本，小于指定版本，等于（1或N个）指定版本
如果是强制升级，则可以支持大于指定版本、小于指定版本、等于（1或N个）指定版本做强制升级处理，同时不应该存在非强制升级的版本判断
