一、BuildType 屬性以及方法。
下面簡要介紹下BuildType的屬性以及方法,更多詳情,可以參閱:
BuildType詳情
1、屬性
屬性 | 描述 |
---|---|
applicationIdSuffix | 應用程序標識后綴。 |
consumerProguardFiles | ProGuard規則文件要包含在已發布的AAR中。 |
debuggable | 這個構建類型是否應該生成可調試的apk。 |
embedMicroApp | 是否應使用此構建類型將鏈接的Android Wear應用程序嵌入到變體中。 |
javaCompileOptions | 配置Java編譯選項。 |
jniDebuggable | 此構建類型是否配置為生成具有可調試本機代碼的APK。 |
manifestPlaceholders | 明示占位符 |
minifyEnabled | 是否為此構建類型啟用了Minify。 |
multiDexEnabled | 是否為此變體啟用了Multi-Dex。 |
multiDexKeepFile | 指定將被編譯到主dex文件中的其他類的文本文件。 |
multiDexKeepProguard | 具有附加ProGuard規則的文本文件用于確定哪些類被編譯到主dex文件中。 |
name | 此構建類型的名稱。 |
proguardFiles | 返回要使用的ProGuard配置文件。 |
pseudoLocalesEnabled | 是否在APK中生成偽語言環境。 |
renderscriptDebuggable | 構建類型是否配置為生成具有可調試RenderScript代碼的apk。 |
renderscriptOptimLevel | 由renderscript編譯器使用的優化級別。 |
shrinkResources | 是否啟用未使用資源的收縮。默認值為false |
signingConfig | 簽名配置。 |
testCoverageEnabled | 是否為此構建類型啟用了測試覆蓋率。 |
useJack 棄用 | 是否應該使用實驗杰克工具鏈。 |
versionNameSuffix | 版本名稱后綴。 |
zipAlignEnabled | zipalign是否啟用此構建類型。 |
2、方法
方法 | 描述 |
---|---|
buildConfigField(type, name, value) | 向生成的BuildConfig類添加一個新字段。 |
consumerProguardFile(proguardFile) | 添加要包含在已發布的AAR中的proguard規則文件。 |
consumerProguardFiles(proguardFiles) | 添加要包含在已發布的AAR中的proguard規則文件。 |
externalNativeBuild(action) | 配置本機構建選項。 |
initWith(that) | 從給定的構建類型復制所有屬性。 |
proguardFile(proguardFile) | 添加一個新的ProGuard配置文件。 |
proguardFiles(files) | 添加新的ProGuard配置文件。 |
resValue(type, name, value) | 添加新生成的資源。 |
resValue(type, name, value) | 添加新生成的資源。 |
setProguardFiles(proguardFileIterable) | 設置ProGuard配置文件。 |
二、構建類型(Building type)的應用
- 1、可以在模塊級 build.gradle 文件的 android {} 代碼塊內部創建和配置構建類型。
- 2、當創建新模塊時,Android Studio 會自動為您創建debug和release這兩種構建類型。
下面我們通過一個案例,來熟悉BuildType以及源集的配置,并驗證以下事項:
- 1、每一個構建類型(BuildingType),都會產生對應的一個APK。
- 2、源集的加載優先級。
備注:想要看到運行效果或者想要動手配置的同學,請移駕Github。
下面的案例,使用了一個類庫DemosAndApi,該類庫用于快速構建Demos演示或者Api程序。
1、創建或者配置構建類型(Building type):
applicationIdSuffix
:應用程序標識后綴。
versionNameSuffix
:版本名稱后綴。
initWith
:允許您從其他構建類型復制其配置。
android {
...
defaultConfig {...}
buildTypes {
release {// 備注:"release"類型的構建類型
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {// 備注:"debug"類型的構建類型
applicationIdSuffix ".debug"
}
jnidebug {
// 復制 構建類型=“debug”的配置
initWith debug
applicationIdSuffix ".jnidebug"
jniDebuggable true
}
}
}
2、添加源集目錄。
上面的配置,為模塊新增加了jnidebug
源集,那么,我們可以在工程中,為其配置源集目錄。
關于源集,可以參考這篇文章。Android Studio Set of source 代碼源集
工程文件樹,展示如下:
3、配置源集文件。
在每個源集中,我們都只有一個MainActivity,該類展示在界面上展示當前所處于的源集或者所對應的構建類型。詳情請參閱源碼。
4、執行編譯
- 4.1、選擇AndroidStudio左下角的Build Variants來配置需要編譯的類型。
- 4.2、每一種構建類型都編譯完畢后,我們查閱:
app/build/outputs
目錄可以看到,相應的apk已經生成了。
5、Overlay覆蓋機制。
我們先通過比較debug、release、jnidebug三種構建類型的運行結果:
- 5.1、debug 源集的apk運行效果:
類庫DemosAndApi為我們加載了debug和main源集的頁面,并且頁面來自各自源集的配置。
5.2、release運行結果
Github源碼庫中有release構建類型的運行結果,在此就不在貼出來了。5.3、jnidebug的運行結果
jnidebug是我們新建的構建類型,它的運行結果如下:
在此處,我們看到jnidebug的運行效果不一樣了,這是因為,我們在jnidebug的源集中,重新定義了main源集的資源。
<resources>
······
<string name="app_name_jnidebug_label">app/jnidebug/jnidebug_MainActivity</string>
<string name="app_name_main_label">app/main/main_MainActivity_來自jnidebug源集的覆蓋</string>
</resources>
在這里延伸出來一個概念,資源的overlay,在BuildType中,資源存在覆蓋機制,存在優先級。
構建變體 > 構建類型[BuildType] > 產品風味[ProductFlavor] > 主源集[main] > 庫依賴項
從上面的優先級來看,main源集的優先級 是比較低的,也就是說,【新創建的源集】可以覆蓋【main源集】的資源。
寫作不易,耗費心力,如果上面的內容對你有幫助,請隨意打賞,讓我們堅持下去~