如何更好的维护Android App Version Code

提交到GooglePlay的每个Android App都需要能够区分版本,要么通过升级versionName (例如从1.0.0 –> 1.0.1),要么升级versionCode(例如从1 –> 2)。其它的Android应用商店,应该也是同样的要求。在实际开发中,versionName的维护可能会和VCS的tag关联起来,而且可能会有市场需求(例如某个重大更新会升级打版本), 因此会得到良好的维护。而versionCode对普通用户来说是不可见的,完全是为了满足应用商店的要求去设置,所以可能经常出现忘记修改导致重复无法提交的情况,这个时候再重新打包提交又要花费不少时间。如果考虑到CI,那更需要自动维护versionCode了。

那么怎么减轻维护versionCode心智负担呢?

很容易想到的一点,是记录下当前已经使用的versionCode,下一次再build时将其自增,然后更新记录。这种方法的优点是,可以每次递增1,很符合直觉。缺点是,需要维护记录,如果存在多台机器同时build的情况,维护的代价就更大。

另外一种方法是无状态的,我们理解了versionCode完全是给应用商店区分版本用的,那么就可以丢弃只能按1递增的执念,只需保证其在同一个versionName下不重复即可。假如我们第一个版本发布的时间是t0, 假如我们提交应用的频率不会超过每天1个,那么某次构建的versionCode可以根据其构建开始的时间tn来计算:days(tn-t0) + 1days() 函数计算经过的天数。t0可以硬编码到实现函数中,也不一定需要是第一个版本构建的准确时间,只是需要一个初始时间。如果每天提交的包可能超过一个,那么可以将公示改造为计算经过的 小时 , 原理都是相同的。值得注意的是,提交应用商店的频率和build的频率是不同的概念,如果有多台机器build,它们build的versionCode可能相同,但这并不冲突,因为我们只会在同一时刻提交一个包。

GooglePlay对versionCode的要求是小于 2100000000 (21亿),正常情况下build的频率绝对不会需要担心溢出。还要要特别注意versionCode只能递增,实现适合自己的算法后先小心调试。