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

20 评论 38281 浏览 259 收藏 7 分钟

后台如何实现对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需要对历史版本有重新的了解。

上述实现方式,在To C的产品中应用较多,其劣势也可以人为规避,对于上述劣势如果大家有解决方案,也欢迎各位留言交流。

以最新版本为更新依据的实现策略

话不多说,我们同样先来看一张原型图:

以上图为例,依旧关注版本管理列表相关内容,其中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。产品之路修远兮,需要上下而求索。

 

作者:张小墨,微信公众号:月光坦克(moontank1918),某美股上市互联网公司产品经理。

本文由 @张小墨 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 希望可以讲一些版本发布后的功能,比如是否可以撤回?机制是?

    来自北京 回复
  2. app进行迭代几个版本后,才做版本更新弹窗提示,之前旧的版本是否可以实现版本更新弹窗提示

    回复
  3. 第一种策略方案 “是否为最新版本”这个判断没必要吧?

    来自山东 回复
  4. 基于历史版本的更新策略,修改版本号时进行校验,是比对上传的版本和当前最新版本的安装包文件吗?

    来自北京 回复
  5. 大佬,iOS不是在官方渠道进行版本更新么,也可以在自己后台上传么?

    来自北京 回复
    1. 这里分为两种,一种是发布到App Store的,一种是企业内部应用,但是不管是那种,最终的版本管理还是在自己的管理后台的,只是发布在App Store的,在管理后台只需要配置下载地址就好了,但是强制更新与非强制更新等策略还是需要在自己的管理后台实现

      来自北京 回复
    2. 这个后台其实就是控制app的更新弹窗的,和提审过程没关系啊

      来自广东 回复
  6. 我这里也没有动版本无效是指什么?

    回复
    1. 可以参考前一个读者的问题回复

      回复
  7. 比如版本无效是指什么,有效是指什么,小白恰好碰到这个需求,求教

    来自北京 回复
    1. 在不同的升级实现逻辑下,这里的版本状态的定义是不同的,我用“以历史版本为更新依据的实现策略”的举个例子,这里的状态包括:最新版本;提示升级;强制升级;不提示升级,且最新版本有且只能有一个,用户侧安装的App版本不同,对应的版本状态也就不用,如果用户A使用的是“强制升级”版本状态的App,那当用户启动App进行版本校验后,就会给用户进行“强制更新”提示。

      来自北京 回复
    2. 有效无效的问题产生在“以最新版本为更新依据的实现策略“
      麻烦以这个为例解释一下诶

      来自四川 回复
    3. 以最新版本为更新依据,相对粗暴,此时的版本状态就两种:有效和无效,有效的版本有且只有一个就是最新版本。看这个有效状态的是否强制更新,就决定了历史版本以何种方式更新至最新版。

      来自北京 回复
    4. 对失效的版本记录,进行编辑有什么意义呢,失效的版本去掉编辑按钮是不是更合理

      来自江苏 回复
    5. 我觉得应该是表述语言有点歧义,如果将有效状态换成最新版本,无效状态换成历史版本,可能不会产生那么多歧义

      来自上海 回复
    6. 历史版本的编辑有何意义呢,兄台能跟我说下吗,我实在是理解不了,编辑历史版本的意义

      来自江苏 回复
  8. 请问,版本状态的定义是什么呢?

    来自北京 回复
  9. 以最新版本为更新依据的实现策略,这个可以优化一下,避免劣势。1、检测当前版本,如果当前版本不是最新版本时。2、先处理“强制更新”的策略

    来自上海 回复
  10. ,热更新是不是不需要进行后台设置?热更新不是也可以实现更新吗

    来自广东 回复
    1. 是的,不过iOS系统从2017年就在管控热更新了,就是热更新可以跳过App Store的审核,所以现在一般在iOS系统下,很少有人用热更新了

      来自北京 回复