前段时间公司业务调整，新开了新的移动端的项目，所以和朋友聊到了“版本号”和“版本更新所需的数据表设计”。

SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。

一般来讲大部分的软件版本号分3段，比如 A.B.C

A 表示大版本号，一般当软件整体重写，或出现不向后兼容的改变时，增加A，A为零时表示软件还在开发阶段。 
B 表示功能更新，出现新功能时增加B 
C 表示小修改，如修复bug，只要有修改就增加C 

除了版本号之外还会有一些修饰的词，比如： 
alpha: 内部版本 
beta: 测试版 
rc: 即将作为正式版发布 
lts: 长期维护 

但老实讲，知名的项目没有几个是遵守上述规则的。 
商业软件完全取决于老板的意思，有时候还会配合宣传任意地来更改版本号。 
而历史悠久的开源项目，往往会有自己的规则，例如Linux用奇数版本表示开发板，偶数版本表示正式版等等。 

随着 Github 的出现，越来越多的人可以参与到贡献开源代码的活动中，版本号规则越来越混乱。 

Github 起草了一个具有指导意义的，统一的版本号表示规则，称为 Semantic Versioning(语义化版本表示). 该规则规定了版本号如何表示，如何增加，如何进行比较，不同的版本号意味着什么。

除此之外，作为产品，日常工作涉及版本更新，更是家常便饭，尤其是安卓产品，面对碎片化的渠道，总有些蛋蛋的忧桑，所以一张可扩展的数据表显得尤为重要。

起初我也有些凌乱，后来找朋友问了一下，具体如下：

checkversion | CREATE TABLE `checkversion` (

`id` int(11) NOT NULL,

`app_id` varchar(5) NOT NULL,  //各产品APP_ID

`app_name` varchar(20) NOT NULL, //各产品APP_名称  `client_version` varchar(20) NOT NULL, //客户端版本号

`client_useragent` varchar(500) NOT NULL, //各渠道版本 ，以逗号分隔，可升级多渠道，全渠道用all，主要是区分多渠道的不同升级，比如腾讯某个渠道，并不让你升级到最新版本，则就可以不加上腾讯渠道。

`client_useragent_name` varchar(100) DEFAULT NULL, //渠道名称（防止泄露一般不填写）

 `download_url` varchar(100) NOT NULL, //升级下载网址 

 `update_id` int(11) NOT NULL DEFAULT '0', //关键是这个字段，记录本次版本应该升级到最新版本号，如本次为2，最新为3，则最新版本号的ID记录为15，则填15， 最新的记录则为0. 每一次APP升级请求API都会将低版本的记录自动更新为3

 `update_log` varchar(500) DEFAULT '', //升级日志

 `update_install` int(11) NOT NULL DEFAULT '0' COMMENT '是否强制安装', 

  PRIMARY KEY (`id`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8   

再配上后台的自动或手动管理，就比较强大了，当然这个理解起来会有些别扭，但是使用起来却是任你升级变化万千，我都可以包容。

 

大家都知道，版本号一般由以下几部分组成：

1. 主版本号
2. 次版本号
3. 修正版本号
4. 编译版本号
例如：2.1.3 ，3.7.5，10.2.0
在比较版本号时，正确的做法应该是，主版本号和主版本号比较，次版本号和次版本号比较等等，也就是把版本号分割，对应的组成之间进行比较，如下：

/**
* 版本号比较
*
* @param version1
* @param version2
* @return
*/
public static int compareVersion(String version1, String version2) {
if (version1.equals(version2)) {
return 0;
}
String[] version1Array = version1.split("\\.");
String[] version2Array = version2.split("\\.");
Log.d("HomePageActivity", "version1Array=="+version1Array.length);
Log.d("HomePageActivity", "version2Array=="+version2Array.length);
int index = 0;
// 获取最小长度值
int minLen = Math.min(version1Array.length, version2Array.length);
int diff = 0;
// 循环判断每位的大小
Log.d("HomePageActivity", "verTag2=2222="+version1Array[index]);
while (index < minLen
&& (diff = Integer.parseInt(version1Array[index])
- Integer.parseInt(version2Array[index])) == 0) {
index++;
}
if (diff == 0) {
// 如果位数不一致，比较多余位数
for (int i = index; i < version1Array.length; i++) {
if (Integer.parseInt(version1Array[i]) > 0) {
return 1;
}
}

for (int i = index; i < version2Array.length; i++) {
if (Integer.parseInt(version2Array[i]) > 0) {
return -1;
}
}
return 0;
} else {
return diff > 0 ? 1 : -1;
}
}
结果说明：0代表相等，1代表version1大于version2，-1代表version1小于version2

通过此方法便可以直接进行android 版本号大小比较了,方法直接拿来用即可.
---------------------
作者：程大龙
来源：CSDN
原文：https://blog.csdn.net/qq_25749749/article/details/79847922
版权声明：本文为博主原创文章，转载请附上博文链接！

 

 

 

 

 

 

APP产品初期如何搭建简单有效的版本管理机制

APP产品初期，往往需要快速迭代，小步快跑。那也就意味着不会有过多的时间进行详细的APP版本规划。在该背景下，产品经理该如何搭建简单有效的版本管理机制？

▎前言.APP版本管理结构

我们不追求非常严密的流程制度，那样并不适合初创项目的节奏规律。对于初创项目，我们采取小步快跑的策略，将业务搭起来并顺利跑通，是我们的首要目标！所以接下来我们讨论的是如何搭建APP版本管理的"骨架"~

  App版本更新接口的设计 随笔 第1张  

▎1.应用市场账号及物料准备

1.1应用市场账号

开发的APP最终是需要通过应用市场去推广的，如Android的华为应用市场、iOS的APP Store。所以第一步，选择应用市场；第二步，注册开发者账号。

选择应用市场

不需要覆盖所有的应用市场，只需要覆盖主流的应用市场即可。

  App版本更新接口的设计 随笔 第2张  

注册开发者账号

我们登录各大应用市场的开发者网址后，申请企业开发者账号，所需要的物料除了《营业执照》和公司的邮箱以外，其余的统统都根据注册流程按部就班的填写即可。当然，记住使用Excel备份：

  App版本更新接口的设计 随笔 第3张  

1.2物料准备

物料准备就是实打实的体力活，但是这个体力活要做好不容易，比如到底需要准备什么物料，这些物料的规格要求又是怎么样的，如何去落实和管理。我特意为大家整理了一份完整版物料表格，以该表格作为一份CheckList，事半功倍~

  App版本更新接口的设计 随笔 第4张  

▎2."蓝湖"设计协助平台搭建

一个APP必然会由众多的页面组成，也必然会有众多的参与者，包括产品狗、设计屎、还有后来者。万物多则乱之，而后乱则管之。我们借用"蓝湖"产品设计在线协助平台来管理我们的页面，并邀请不同模块负责的团队成员维护自己的页面，给出简单的交互与标注。

  App版本更新接口的设计 随笔 第5张  

▎3.第三方数据服务接入/统计

数据分析是任何产品绕不开的一环，而目前市面上提供数据服务的供应商也比较成熟，可以选择一家主流的，让开发小哥哥接入其数据服务的SDK即可。如我目前所使用的第三方talkingData，通过其实现数据收集及基本的数据分析（累计用户、新增用户、版本使用分布、日活、留存等）。

  App版本更新接口的设计 随笔 第6张  

▎4.APP迭代节奏制定

产品初期，往往需要快速迭代，小步快跑。所以我们制定的迭代周期是双周。通过快速的迭代周期，快速校验产品功能是否符合市场预期，或者功能优化是否有效。当然，迭代管理也是一门学问，涉及项目管理，我们不必过于深入。只要借助腾讯系的TAPD项目管理系统来协助我们完成即可。

  App版本更新接口的设计 随笔 第7张  

▎5.应用市场提审策略

应用市场提审相当具有博弈性。

和谁博弈？和iOS应用市场的审核人员博弈（本质是和审核规则博弈）；博弈什么？博弈能否过审上架APP Store；为什么要博弈？没办法，APP Store具有巨大的流量资源，同时其对上架的要求非常高，主要体现在[资质]上。

言归正传，什么场景下我们需要重点关注应用市场的提审策略？当我们的业务涉及以下敏感业务时，需要重点关注提审策略：

①非持牌金融机构提供的金融服务，例如P2P借款、导流给其它网贷平台。

②订阅、游戏内货币、游戏关卡、优质内容等虚拟充值类业务，例如Q币充值、爱奇艺会员。

③提供真实货币的游戏、彩票或竞猜活动，例如下注、扑克、一元购。

④涉及到假冒侵权的业务，例如A货、未授权的大牌销售。

如果涉及到上述的敏感业务，还想成功上架的话，那只有一招——巧妙的绕过去（骗审）。我们设计屏蔽逻辑，在审核期间与过审后采取不同的状态：

  App版本更新接口的设计 随笔 第8张  

▎6.应用市场ASO管理

这是一个轻松的话题，什么是ASO，无非就是应用市场的排名优化，提高曝光。那我们要如何做？很简单，找人刷单。刷关键词、刷评论、刷下载量。反正，给钱，大爷~

  App版本更新接口的设计 随笔 第9张  

▎7.版本过程资料管理

这个也简单，每个版本要把安装包、原型稿、设计稿、交互稿、需求范围列表等物料整理好，并在固定的文件夹保存好，作为公用资源即可。



作者：猩猩相嘻
链接：https://www.jianshu.com/p/a458c8c2e4ac
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

 

 

App版本更新接口的设计

 

工作这几年碰到的版本检测升级的接口也算是五花八门，啥样的都有，但肯定有的功能是有个apk的下载链接，能间接或直接提示你是强制还是非强制更新：

  • 间接是指提供你后台最新版本号，让你自己与本地版本号通过比较得出是否升级或强制升级；
  • 直接就是后台接口直接返回个Boolean类型告诉你是强制或者非强制更新。

个人认为一个好的版本检测接口需要设计的更灵活更清晰用起来更方便，下面就我理解的接口设计如下（如思路有误，欢迎指正）：

总字段如下(并不是所有字段都要返回给客户端)：
  1.最新版本号 ：newVersion 2.最小支持版本号 : minVersion 3.apk下载url : apkUrl 4.更新文案 : updateDescription 5.是否有更新 : isUpdate 6.是否强制更新 : forceUpdate 可选字段： 7.apk文件大小：apkSize 8.apk的文件MD5值：md5

方案一（前端处理逻辑）：
前端调用获取当前服务器端最新版本信息的接口，然后根据返回的服务器端最新版本信息与客户端当前版本信息进行比较，此处需要后端提供最新版本号 ：newVersion 、 最小支持版本号 : minVersion 、apk下载url : apkUrl 、更新文案 : updateDescription 这四个字段。如下表：

字段 字段描述
newVersion 最新版本号
minVersion 最小支持版本号
apkUrl apk下载url
updateDescription 更新文案

客户端逻辑如下：

  1. 如果currentVersion < newVersion,则有更新信息；
    • 如果currentVersion < minVersion,则需要强制更新；
    • 如果currentVersion >= minVersion,则不需要强制更新;
  2. 如果currentVersion == newVersion，则没有更新信息。

客户端对应的流程图：

  App版本更新接口的设计 随笔 第10张 更新处理逻辑放客户端.png
前端处理逻辑不足之处：
对指定版本进行强制更新可能不是那么好，可是为什么要对指定版本进行更新呢？
此处做个假设：你的应用当前线上运行版本为V2.1.1, V2.1.2两个版本用户量比较多，又快要发布V2.1.3了，此时发现V2.1.2有个bug需要修复一下，然后在V2.1.3修复后发布了，当时感觉小问题就非强制更新（ 毕竟强制更新比较反感），过了几天查看V2.1.1, V2.1.2版本的用户量依然不减，升级的积极性不高啊，可是现在发现V2.1.2的这个bug风险很大，一旦出问题要卷铺盖走人的地步，那就要强制更新了，可又不想影响V2.1.1和V2.1.3版本的用户（ 对强制更新比较反感），此时想到要是能对V2.1.2一个版本强制更新就好了。
备注：此场景只是一个假设，当然即便碰到这个假设，只要前期设计的合理都能解决，比如：

 

  • 后端说我再多返回一个字段forceUpdateList给你，内容为指定版本强制更新的版本号列表，只要当前版本在该列表中就强制更新。（此方案前端表示想哭）
  • 或者不想要强制更新的版本号列表也可以，给你个字段forceUpdateVersion表示需要强制更新的版本信息,用正则匹配，如果匹配到的版本号就强制更新。（前端能做，后端也能做，看谁能说服谁了）
  • 可能也有人会说热修复或者插件化表示不担心，那就绕过吧，此处目的是为了分析版本升级的最优方案。

方案二(后端处理逻辑)：
在客户端请求参数中添加当前版本号currentVersion传输给后台，由后台根据客户端传过来的当前版本号currentVersion做相应的判断后给出是否强制更新。
后端逻辑如下：

  1. 根据是否有特殊需求可指定某个版本必须强制更新，如currentVersion == XXX,则forceUpdate = true;
  2. 如果currentVersion < newVersion,则isUpdate = true；
    • 如果currentVersion < minVersion,则forceUpdate = true；
    • 如果currentVersion >= minVersion,则forceUpdate = false;
  3. 如果currentVersion == newVersion，则isUpdate = false.

后端逻辑对应流程图：

  App版本更新接口的设计 随笔 第11张 更新处理逻辑放后端.png

 

结论：
返回客户端的字段仅需要apk下载url : apkUrl、更新文案 : updateDescription、是否有更新 : isUpdate 、 是否强制更新 : forceUpdate 这四个字段即可。如下表：

字段 字段描述
apkUrl apk下载url
updateDescription 更新文案
isUpdate 是否有更新
forceUpdate 是否强制更新

总结：
细心的你可能会发现上面的可选字段apkSize和md5并没有用到，既然是可选字段也就是可用可不用，根据需要决定是否采用，这里来讲下他们的用处。

  • apk文件大小apkSize
    这个用处可以说出于考虑用户体验，需要在升级弹框出来展示给用户将要更新的内容多大，让用户决定在非WIFI状态是否要更新，不能为了拉用户下载量或所谓的UV数直接让用户在不知道大小的情况下去直接下载（土豪用户绕路）。
  • apk的文件MD5值
    这个主要是出于安全考虑吧，因为文件内容固定的话对应的md5是一样的，我们可以通过这个md5值来和下载的apk的md5值进行比较去保证我们从服务器更新下载的apk是一个完整的未被篡改的安装包，也就是说如果我们下载的apk的md5值和服务器返回的md5值相等，则说明我们下载的apk是完整的，且没有被相关有心人处理过的apk。

综上所述，这个版本更新的处理逻辑客户端和后端谁来做都可以，无关乎懒不懒的问题，个人感觉灵活性后端比客户端方便多了，当然客户端也能做，只是客户端做起来前期准备工作要考虑周全，各种场景都要考虑进去（还是会存在一些未知场景），不然只能下个版本实现了，考验你设计能力的时候到了。以上纯属个人见解，如有更好的方案，欢迎指教。



作者：闲庭CC
链接：https://www.jianshu.com/p/f7394d871542
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

 

扫码关注我们
微信号：SRE实战
拒绝背锅 运筹帷幄