摘要：前言在日常的开发过程中,许多刚入行的开发者在apk打包命名、应用迭代版本的档案留存管理上都比较混乱——产生这些问题的原因无外乎以下两种:一是之前没有相关的操作经验、头尾不能兼顾;一是公司没有制定对应的规范、无有效参照范例。当然,所谓的规范在业内不会存在唯一的标准与格式(对于规范的理解,本人认为是相对容易让大众接受、理解、掌握的行为准则),所以,本文的目的在于探讨、交流、引导,还望各位不吝赐教。常见的apk打包命名规则如下:[应用名称][版本号][版本类型][打包时间]

在日常的开发过程中,许多刚入行的开发者在apk打包命名、应用迭代版本的档案留存管理上都比较混乱——产生这些问题的原因无外乎以下两种:

一是之前没有相关的操作经验、头尾不能兼顾; 一是公司没有制定对应的规范、无有效参照范例。 当然,所谓的规范在业内不会存在唯一的标准与格式(对于规范的理解,本人认为是相对容易让大众接受、理解、掌握的行为准则),所以,本文的目的在于探讨、交流、引导,还望各位不吝赐教。

[应用名称][版本号][版本类型][打包时间][渠道号].apk

填写app的名称,如NSDF。

填写当前应用的版本号,目前主流的格式为x.x.x(主版本号.次版本号.修改编号),如0.0.1、1.5.11。

主版本号一般以0位起始数字(有些以1为起始数字) 第一位数字表示我们应用的主版本号为1,当次版本号>9时,主版本号+1,次版本号重新从0开始;

第一个小数点后的数字表示我们的次版本号,当版本内容发生较大改动(功能、界面)发生改变时,次版本号+1,修改编号重新从0开始;

第二个小数点后的数字表示我们应用的修改编号,当我们在当前次要版本进行相关的BUG修复、性能提升而对产品的功能、界面没有较大的影响时(即用户主观上不能明显感受到),一般是修改编号在原有基础上+1累计即可。

版本类型一般分为alpha(内部测试版)、beta(公测版)、rc(Release Candidate/预上线版本)、release(线上版本)四种版本。

内部测试版,属于刚完成研发阶段未进行测试且潜在BUG较多的版本,该版本一般部署测试环境,主要提供给内部人员、专业的测试人员进行体验验证。

公共测试版,在alpha版的基础上做过一些修改,但任然存在部分缺陷且后期功能方面还会有所增加,该版本已经可以部署预上线/线上环境了,主要用于提供给特定的忠实用户体验,内部演示汇报,产品、测试人员二次验证等。

预上线(候选)版本,该版本的功能不会发生改变,在beta版本的基础上,完成了当前版本全部功能的设计并修复了大部分的BUG,是一个比较稳定的版本,已经可以用来放在应用市场上供用户使用,在这个版本以及下面的release版本中,我们可以放心的部署线上环境了。

线上(发行)版本,该版本已经完成对所有BUG的修复及功能模块优化,基本上不会再发生改动,是适用于所有用户群体的稳定版本。 为了简化版本类型分类,也可以分为alpha、beta、release三个版本类型标记。

apk的打包时间我们使用年月日时分组成,其中年份取值后两位(如2016取值16),月、日各占两位不足两位补零(如1月2日应取值0102),时、分取值与月、日相似。

如当前时间为2016年1月2日6时5分,打包时间值为1601020605。

在应用中增加渠道号的标识可以有效帮助我们快速了解应用在各个渠道(应用市场–区分数据统计来源)上的统计状态(下载量、收益、日志信息等),一般情况下,在产品官网发布的版本渠道号一般为空。

其它应用市场的渠道号可以自己编辑设置,示例如下:

百度应用市场的渠道号可以为Baidu, 豌豆荚的为Wandoujia。

打包好的apk名称为: Flash Go-debug-v1.0.0-201812211141.apk Flash Go是我的apk名称.