Android Gradle 技巧之一: Build Variant 相關
阿新 • • 發佈:2019-02-18
Build Variant
android gradle 外掛,允許對最終的包以多個維度進行組合。
BuildVariant = ProductFlavor x BuildType
兩個維度
最常見的就是這樣:
productFlavors { pro { } fre { } } lintOptions { abortOnError false } buildTypes { debug { } release { } }
其中,buildTypes 一般都會有 debug 或者release,標示編譯的型別,通常在混淆程式碼、可調式、資源壓縮上做一些區分。
productFlavor 則為了滿足“同一個project,根據一個很小的區分,來打不同的包”這個需求。
這兩個維度的組合,會產生如下包:
- proDebug
- proRelease
- freDebug
- proRelease
更多的維度
flavorDimensions 'abi', 'version' productFlavors { pro { dimension 'version' } fre { dimension 'version' } arm { dimension 'abi' } mips { dimension 'abi' } } buildTypes { debug { } release { } }
productFlavor 本身定義了2個維度,記上 buildType,則有三個維度,會產生如下的包:
- armProDebug
- armProRelease
- armFreDebug
- armFreRelease
- mipsProDebug
- mipsProRelease
- mipsFreDebug
- mipsFreRelease
其中每個維度組合,都可以設定本身的 dependency、test source。下面做一個舉例。
Flavor 與 Dependency
需求
module 中有若干個 flavors,例如:fre 和 pro,分別依賴不同的庫,這些庫有的是本地 jar 庫,有的是遠端庫。
方案
遍歷 Build Variant
需求
Bugtags 的 android sdk,有一個自動上傳符號表功能, 在最初,是這樣配置的:
apply plugin: 'com.bugtags.library.plugin'
bugtags {
appKey "APP_KEY"
appSecret "APP_SECRET"
mappingUploadEnabled false
}
後來,我們增加了一個 beta-live 的機制,用來區分測試和上線的 APP,這樣,同一個 APP,就有兩套 APP_KEY 和 APP_SECRET 了,很明顯上方的配置方式就不在適用。
方案
android gradle 外掛提供了 android.applicationVariants 索引來遍歷所有的 build variant
後來,我們採取了一個方案,遍歷 Build Variant,設定 extension 資訊來相容這種需求。
afterEvaluate {
android.applicationVariants.each { variant ->
def bugtagsAppKey = null;
def bugtagsAppSecret = null;
if (variant.name.contains("debug")) {
bugtagsAppKey = 'APP_KEY_BETA'
bugtagsAppSecret = 'APP_SECRET_BETA'
} else if (variant.name.contains("release")) {
bugtagsAppKey = 'APP_KEY_LIVE'
bugtagsAppSecret = 'APP_SECRET_LIVE'
}
variant.ext.bugtagsAppKey = bugtagsAppKey
variant.ext.bugtagsAppSecret = bugtagsAppSecret
}
}
apply plugin: 'com.bugtags.library.plugin'
總結
本文主要是介紹了 build variant 的概念,還介紹了兩個日常應用案例。希望對大家有幫助。
參考資料
有問題?在文章下留言或者加 qq 群:453503476,希望能幫到你。
想要及時收到最新部落格文章,請關注:
『mobdev』微信公眾號二維碼