App版本更新：后台实现策略梳理

　　后台如何实现对App版本更新的管理？本文中梳理了两种App版本更新的实现策略，分别以历史版本和最新版本为更新依据进行展开介绍，供大家参考讨论。
　　App升级更新方式包括：强制更新、非强制提示更新、非强制不提示更新等，这些内容我们可以依靠常识总结出来，但管理后台不是上传新安装包就可以实现版本管理的，如何通过管理后台实现对App版本的管理，以及对历史版本的处理逻辑等内容更加值得我们去研究。
　　简言之，本文阐述与解决的问题是：后台如何实现对App版本更新的管理？
　　版本更新等功能是App的基础功能，没有经历项目从0到1的过程，接触这部分功能模块就会少一些，这也是想要和大家分享的这部分经验的原因。
　　回顾做过的项目，本文中梳理了两种App版本更新的实现策略，供大家参考讨论。
　　以历史版本为更新依据的实现策略
　　标题有点绕嘴，我们不妨先看一张原型图：
　　以上图为例，暂时忽略上传新版本安装包与列表查询区，只关注版本管理列表中iOS的相关内容。
　　上述App的iOS版共存在4个版本：2。0（当前最新版本）、1。2、1。1与1。0，其中iOS与Android最新版本有且只能各有一个，修改版本状态时需进行校验。
　　在例子中，2。0为最新版本，1。2为提示升级、1。1为强制升级、1。0为不提示升级。各版本用户启动App后，依照用户所用版本的状态给予用户相应的升级提示。
　　这种实现方案的核心在于：历史版本均有各自的状态，根据历史版本的状态决定前端的更新方式。
　　校验流程如下：
　　上述策略的优缺点如下：
　　策略优势：灵活控制各个历史版本的升级方式，可以指定修复相应的历史版本，不会操成大规模的“误伤”；
　　策略劣势：每次发版都需要对历史版本进行状态修改，如果接口变动对历史版本产生影响，需明确出对那些历史版本有影响，也就要求了上传新版本的PM需要对历史版本有重新的了解。
　　上述实现方式，在ToC的产品中应用较多，其劣势也可以人为规避，对于上述劣势如果大家有解决方案，也欢迎各位留言交流。
　　以最新版本为更新依据的实现策略
　　话不多说，我们同样先来看一张原型图：
　　以上图为例，依旧关注版本管理列表相关内容，其中iOS与Android版本状态为有效（也就是最新版本）有且只能各有一个，该部分修改版本状态时需进行校验。
　　当前版本状态为有效，看对应的强制更新状态：
　　a、如最新版本为强制更新，则用户启动App后需要强制更新（所用版本不是最新版本）；
　　b、如最新版本为非强制，则为提示更新（如需要非提示更新，可以再增加一个字段校验，本文不再赘述）。
　　这种实现方案的核心在于：根据最新版本的状态决定前端的更新方式。
　　其校验流程如下：
　　上述策略的优缺点如下：
　　策略优势：简单直接，无需了解历史版本所用的接口信息；
　　策略劣势：
　　存在“误伤”，会扩大强制更新用户的范围，举个例子，新上线版本存在重大BUG，需要重新发版，针对存在BUG的版本需强制更新，这样的场景下，上述更新方式会强迫所有用户强制更新，扩大了伤害范围。
　　用户不连贯使用时，会产生漏洞，举个例子，用户使用1。0版本，1。1版本强制更新，1。2版本非强制升级，在1。1到1。2期间，用户未启动App，当用户再次使用App时，当前最新版本为1。2，版本检查为非强制更新，这样的场景，就影响了用户的正常使用，因为用户错过了1。1的强制更新，极有可能影响接口正常使用。
　　可用的解决方案：在版本更新校验时，可增加一项校验，用户使用版本与最新版本之间存在强制更新版本，则该次升级即为强制更新，使用该方案可以解决劣势中的问题2。
　　几句总结的话
　　上述两种解决方案各有利弊，都存在很大的可优化空间，本文权作抛砖引玉，希望大家可以在基础性功能设计上有些参考。
　　很多时候，能把白菜炒好吃的厨师才是好厨师，能把基础功能设计完善的PM才是好的PM。产品之路修远兮，需要上下而求索。