AndroidManifest:VersionCode和VersionName
Google为APK定义了两个关于版本号属性：VersionCode和VersionName，他们有不同的用途。
VersionCode：对消费者不可见。仅用于应用市场、程序内部识别版本号，推断新旧等用途。
VersionName：展示给消费者，消费者会通过它认知自己安装的版本号，下文提到的版本号号都是说VersionName。
结尾有三个常见问题的解决方式
同一个版本，相应了多个VersionCode怎么办
公布了一个VersionCode错误的版本号怎么办
发出去的应用有Bug要换回旧版，怎么操作？
然后讲讲前因后果
大家在使用软件和应用时，都会涉及到版本号的概念，大家都知道的。比方Win XP，QQ2012，小米桌面1.6。
之所以会有版本号，主要是由于软件产品一直在发展、变化的。
版本号的概念能够帮助消费者识别不同一时候期的产品。
而展如今消费者面前的版本号，和开发人员内部使用的一般是不同的版本号。开发时一般会使用数字作为标志，比方6.1.7600.16385。事实上是Win 7第一个正式版的版本号号，而Win 7 SP1的版本号号是6.1.7601.17514，这样长长一串数字对消费者毫无意义，所以在产品公布时一般会起一个更easy懂的版本号。下文中会把Win 7这种用于展示的版本号叫做[VersionName]，6.1.7601.17514这样用于程序标识的版本号叫做[VersionCode]
早年由于软件主要自己负责自己的分发、升级等方面。所以版本号号也相当自由，各家都有不同的规范。可是近年来移动设备崛起，App Store这种应用商店集中分发成了主流。以升级为例，应用商店会负责检查消费者手机上应用的版本号，并和商店里面最新的版本号比較，假设商店里面的版本号比較新，消费者手机上的版本号比較旧。就会提醒消费者升级。
这就涉及到怎样识别新、旧的问题。
对于计算机来说，最可靠的推断方式就是数字，数字有非常多优点：程序easy推断、格式简单不easy出错、肉眼easy识别等。
所以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、同一个VersionName(版本)。相应了多个VersionCode
这样的情况非经常见，比方说新版本号公布之后，某个商店反馈说存在xxx问题，须要修复、定制等等操作。于是商务找project师出了个新版本号。考虑到是小版本号升级，版本号号没变化，可是VersionCode已经变了。
可能遇到的问题：假设这个新版仅仅在部分商店上线。就会出现都是3.1版，A商店的版本号事实上比B商店的新。
已经安装了新版本号的用户。还会被提示升级，这时候用户会困扰。为什么我装了3.1还要升级到3.1？部分商店为了最新会抓包。导致渠道包流窜，影响运营监控和分析。
解决方式：a.版本号号应该和VersionCode一起涨。并且一旦公布新版本号，就在全部渠道上架新版。
2、公布了一个VersionCode错误的版本号
有时候由于project师不小心，公布了一个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版本号的用户，可能会收到旧版本号的升级提示，比并降级回旧版
解决方式：事实上非常easy。由于VersionCode对终于用户是不可见的。仅仅要添加就好了。上文的样例，新版VersionCode直接取11200就齐活了。
3、公布了一个有Bug的版本号。好捉急
偶尔会遇到版本号已经公布了。第二天突然发现，糟糕，有Bug，用户開始骂了！
于是商务同学到各家市场要求退回旧版本号。
可能遇到的问题：已经升级到有Bug版本号的用户是无法回滚到旧版的，因此这样直接退回旧版本号的方式对这些热心升级的用户是很不负责任的。
并且人肉召回的力度实在有限，这个有Bug的版本号一定会流传的。
解决方式：最好是不要浪费时间退回旧版，赶紧修复Bug发个新版本号(记得加VersionCode)，假设Bug比較棘手，临时无法修复，仅仅能退回旧版本号。这时建议把旧版本号的VersionCode改大一些后，提交新版本号，这样能够保证全部用户都能下载/升级到一个相对可靠的版本号。
以上就是关于Android应用版本号的一些建议。
希望对大家有帮助。
版权声明：本文博客原创文章。博客，未经同意，不得转载。
