摘要：前言在日常的開發過程中,許多剛入行的開發者在apk打包命名、應用迭代版本的檔案留存管理上都比較混亂——產生這些問題的原因無外乎以下兩種:一是之前沒有相關的操作經驗、頭尾不能兼顧;一是公司沒有制定對應的規範、無有效參照範例。當然,所謂的規範在業內不會存在唯一的標準與格式(對於規範的理解,本人認為是相對容易讓大眾接受、理解、掌握的行為準則),所以,本文的目的在於探討、交流、引導,還望各位不吝賜教。常見的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(線上版本)四種版本。

alpha

內部測試版,屬於剛完成研發階段未進行測試且潛在BUG較多的版本,該版本一般部署測試環境,主要提供給內部人員、專業的測試人員進行體驗驗證。

beta

公共測試版,在alpha版的基礎上做過一些修改,但任然存在部分缺陷且後期功能方面還會有所增加,該版本已經可以部署預上線/線上環境了,主要用於提供給特定的忠實使用者體驗,內部演示彙報,產品、測試人員二次驗證等。

rc(Release Candidate)

預上線(候選)版本,該版本的功能不會發生改變,在beta版本的基礎上,完成了當前版本全部功能的設計並修復了大部分的BUG,是一個比較穩定的版本,已經可以用來放在應用市場上供使用者使用,在這個版本以及下面的release版本中,我們可以放心的部署線上環境了。

release

線上(發行)版本,該版本已經完成對所有BUG的修復及功能模組優化,基本上不會再發生改動,是適用於所有使用者群體的穩定版本。
為了簡化版本型別分類,也可以分為alpha、beta、release三個版本型別標記。

打包時間

apk的打包時間我們使用年月日時分組成,其中年份取值後兩位(如2016取值16),月、日各佔兩位不足兩位補零(如1月2日應取值0102),時、分取值與月、日相似。

如當前時間為2016年1月2日6時5分,打包時間值為1601020605。

渠道號

在應用中增加渠道號的標識可以有效幫助我們快速瞭解應用在各個渠道(應用市場–區分資料統計來源)上的統計狀態(下載量、收益、日誌資訊等),一般情況下,在產品官網釋出的版本渠道號一般為空。

其它應用市場的渠道號可以自己編輯設定,示例如下:

百度應用市場的渠道號可以為Baidu,
豌豆莢的為Wandoujia。