VersionCode与VersionName

前言

应用运营知识：VersionCode和VersionName

Android应用开发者和运营团队常遇到因为不明一些Android的概念而造成的困扰。因此准备一些基础知识。

简介

Google为APK定义两属性：VersionCode和VersionName，它们各有用途。

• VersionCode：对消费者不可见，仅用于应用市场、程序内部识别版本、判断新旧等用途。
• VersionName：展示给消费者，消费者通过它认知自己所安装版本，下文所提版本号既是VersionName。

前因后果

大家使用软件和应用，会涉及版本概念。大家知道，Win XP、QQ2012、小米桌面1.6等，之所以有版本，主要因软件产品一直在发展、变化。版本概念可帮助消费者识别不同时期产品。

而展现在消费者面前的版本和开发者内部所用通常是不同版本。开发时通常使用数字作为标志，比如6.1.7600.16385，其实是Win 7第一个正式版版本号，而Win 7 SP1版本号是6.1.7601.17514。这样一串长数字对消费者毫无意义，故在产品发布时通常会起一个较容易理解的名称。下文把Win 7这样用于展示的版本叫做VersionName，6.1.7601.17514这样用于程序标识的版本叫做VersionCode。

早年因软件主要自己负责自己的分发、升级等方面，故版本号相当自由，各家有不同规范。但近年移动设备崛起，AppStore这样应用商店集中分发成为主流。以升级为例，应用商店会责检查消费者手机上应用的版本，并和商店里最新版本比较，若商店里版本较新，消费者手机上版本较旧，便会提醒消费者升级。

对计算机来说，识别新、旧问题，最可靠方式便是数字。数字有很多好处，程序易判断、格式简单不易出错、肉眼易识别等。故Google要求每个应用都在APK安装包中记录该安装包VersionCode，只要拿到该APK文件，便可知道对应VersionCode是多少，应用商店便可以该VersionCode为准，来判断版本。安装包VersionCode数字越大则越新。这样开发者在开发过程中，每有一个新版本只要加大一点数字即可。比如第一个版本VersionCode是1，第二个版本是2。因每天可能产生多个没有发布的版本，故数字增长很快。

经一段时间开发，这个数字会变得较大，比如16385，这时对消费者来讲，该数字其实不太具有可识别性，比如说Win 16385和Win 17514在传达信息方面效果并不好，不利于产品进行市场推广。因此Google也支持在AKP安装包内记录VersionName，叫Win 7、Win Vista都可，这样可满足市场、传播方面需求。这样VersionName其实不具备比较新、旧版本能力，只是用来向消费者展示。

综上所述[VersionCode]对消费者不可见，仅用于应用市场、程序内部识别版本、判断新旧等用途。VersionName展示给消费者，消费者通过它认知自己所安装版本。一般我们说的版本号就是指这个。

常见问题解决方案

1. 同一版本号对应多个VersionCode

同一VersionName(版本号)对应多个VersionCode，这种情况很常见。比如新版本发布后，某商店反馈说存在xxx问题，需修复、定制等操作。于是商务找工程师出一个新版本，考虑是小版本升级，故版本号无变化，但VersionCode已变。

可能遇到问题：若该新版只在部分商店上线，便会出现都是3.1版，A商店版本其实比B商店新。已安装新版本用户仍会被提示升级，这时用户困扰，为何装了3.1还要升级到3.1？部分商店为最新会抓包，导致渠道包流窜，影响运营监控和分析。

解决方案：版本号应和VersionCode一起增长，且一旦发布新版本即在所有渠道上架新版本。

2. 发布一个VersionCode错误的版本

有时因工程师不小心，发布一个VersionCode过大版本。比如1.1.1.20版本VersionCode写成111，而1.1.1.27版本VersionCode写成11127，但后面发布1.1.2版望延续旧的VersionCode，即112。

可能遇到问题：1.1.1.27版用户将无法获得1.1.2版本升级，因在程序看来1.1.1.27版较新，同时，已使用1.1.2版本用户，可能会收到旧版本升级提示，比如降级回旧版。

解决方案：因VersionCode对最终用户不可见，只要增加即可，上文例子，新版VersionCode直接取11200便可。

3. 所发应用有Bug需换回旧版

偶尔遇到版本已经发布，第二天发现有Bug。于是商务同学到各家市场要求退回旧版本。

可能遇到问题：已升级到有Bug版本用户无法回滚到旧版，因此这样直接退回旧版本方式对这些热心升级的用户是非常不负责任的。而且人力召回力度有限，该存在Bug的版本会流传开。

解决方案：不要浪费时间退回旧版，快速修复Bug发布新版本(记得加VersionCode)。若Bug较棘手，建议把旧版本VersionCode改大一些，然后提交新版本，这样便可保证所有用户都能下载、升级到一个相对可靠版本。

更多可查看

https://dev.mi.com/doc/p=62/index.html