flavor android build,android BuildType和BuildFlavor
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 庫，有的是遠程庫。
方案
image.png
屏幕快照 2020-06-19 下午1.38.36.png
BuildType，構建類型，主要針對開發生命周期的不同階段進行配置。一個模塊或者項目，默認有兩種類型，release 和 debug。 debug 類型下 debuggable 屬性是 true，從而使得我們可以打斷點進行調試。debug 類型在打包的時候，會使用默認的自動生成的簽名，對于 release 類型來說，發布的時候需要使用我們自己的密鑰進行簽名。同時，我們還可以在發布的時候，進行代碼混淆。
signingConfigs {
a {
}
release {
}
defaultSigning {
keyAlias 'xxx'
keyPassword 'xxx'
storeFile file('xxxxx')
storePassword 'xxxx'
}
}
resnginConfings 里邊可以隨便命名寫配置名字，如：a,release,defaultSigning直接在buildTypes 的類型里邊配置 signingConfig來配置
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
debuggable false
signingConfig signingConfigs.defaultSigning
}
debug {
}
buildToolsVersion '28.0.3'
}
你建立幾個buildType，在buildFlavor就會出現幾個類型
屏幕快照 2020-06-19 下午1.37.38.png
注意：
屏幕快照 2020-06-19 下午2.16.32.png
你在Active Build Variant選擇了那個，那個文件夾中的java的顏色就變成深藍色，res文件夾就變成res的文件夾了
如何使用構建變體
上一節，說了什么是構建變體，但是，我們該怎么使用以滿足我們的需求呢？有兩個地方，給我們帶來了可能性：BuildConfig 和 SourceSet(源集)。
BuildConfig
也許你已經注意到了上面 productFlavor 中的
buildConfigField "String", "NAME", "\"免費版\""
事實上，對于每一種變體，都會有一個 BuildConfig 與之一一對應。
我們來看看構建變體free.debug 的BuildConfig：
public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String APPLICATION_ID = "com.ygs.test.free.debug";
public static final String BUILD_TYPE = "debug";
public static final String FLAVOR = "free";
public static final int VERSION_CODE = 1;
public static final String VERSION_NAME = "1.0-free";
// Fields from product flavor: free
public static final String NAME = "免費版";
}
這些字段都是靜態常量，在項目中，我們都可以通過 BuildConfig 直接訪問。比如，你可以通過 BuildConfig.DEBUG 判斷當前版本是否是 debug 版本；可以通過 BuildConfig.FLAVOR 判斷當前的 productFlavor，已決定是否啟用某個功能。當然，我們也可以自定義字段，比如
把格式說一下 buildConfigField("常量類型","常量名稱","常量值")
buildConfigField "String", "NAME", "\"免費版\""
flavorDimensions "mode"
productFlavors{
dev{
dimension "mode"
buildConfigField("String", "HTTP_BASE", '"https://www.xxx.com/dev/"')
buildConfigField("boolean", "UPDATE", "true")//那里需要用了,直接BuildConfig.UPDATE就取出來了,就這么簡單
}
tes{
dimension "mode"
buildConfigField("String", "HTTP_BASE", '"https://www.xxx.com/tes/"')
buildConfigField("boolean", "UPDATE", "false")
}
pro{
dimension "mode"
buildConfigField("String", "HTTP_BASE", '"https://www.xxx.com/pro/"')
buildConfigField("boolean", "UPDATE", "false")
}
}
可以用來配置清單文件里面的值
這個最常用的就是在清單文件里面需要配置app_key,app_id的時候了,很多的三方SDK是需要配置這個東西的,比如某盟,某語音等等一大堆,這個時候,開發是用的key和id肯定不能正是環境也用,或者給不同的客戶打不同的包,用的也不能一樣,這是后,需要進行一些配置:
在清單文件(AndroidManifest)里面,application節點下這樣配置:
android:name="app_id"
android:value="${app_id_value}" />//占位符
android:name="app_key"
android:value="${app_key_value}" />
在剛剛的productFlavors下面這樣配置:
productFlavors{
dev{
dimension "mode"
buildConfigField("String", "HTTP_BASE", '"https://www.xxx.com/dev/"')
manifestPlaceholders = [app_id_value : "123456"
,app_key_value : "654321"]
}
tes{
dimension "mode"
buildConfigField("String", "HTTP_BASE", '"https://www.xxx.com/tes/"')
manifestPlaceholders = [app_id_value : "111111"
,app_key_value : "222222"] //替換兩個以上的用逗號隔開
}
pro{
dimension "mode"
buildConfigField("String", "HTTP_BASE", '"https://www.xxx.com/pro/"')
manifestPlaceholders = [app_id_value : "223344"
,app_key_value : "556677"]
}
}
上述這些字段，無論是自定義的，還是默認的，都可以成為我們在項目中的判斷條件。
image.png
SourceSet
所以源集，即代碼和資源的分組。這可能有點抽象，舉個栗子，src/main 就是一個源集。
每個 buildType 可以有一個源集，每個 buildFlavor 可以有一個源集，每個 buildVariant 同樣可以有一個源集。
其中，src/main 這個源集是所有源集所共有的，除此之外，源集之間互斥。
image.png
如上圖所示，一共有三個源集：freeDebug、freeRelease、main。
注意，freeDebug、freeRelease 實際上是使用 buildVariant 的構建的源集，需要和構建變體的名字一樣(當然可以通過配置修改這種默認行為)。
這里有幾點注意事項：
對于 java 文件來講，freeDebug 中不能出現和 main 中一樣在同一個包下類名相同的 java 文件，因為他們之間是共享關系，相當于將 main 中的所有 java 和 freeDebug 合并在一起。如果出現兩個相同名字的 java 文件，會報錯。freeDebug 和 freeRelease 不同，它們所有的資源都是互斥的，相互不影響，因為我們在構建的時候，也只能選擇其中一種進行構建。假設我們選擇了 freeDebug，那么 freeRelease 就會被剔除在外。
對于 res 文件夾下的這些資源文件，freeDebug 和 freeRelease 這些源集之間同樣是互斥的，相互沒有任何影響。但是對于不同源集和 main之間，卻存在著資源合并或替換的情況。
對于 drawable 及其相關文件夾下的圖片而言，freeDebug 中的圖片會直接覆蓋 main 中的同名圖片。對于 layout 文件夾下的布局文件也是這樣。
但是，對于 values 文件夾下的 xml 文件來說，確是文件內容的合并。比如在源集 main 中的 strings.xml 中
App
Hello world!
在源集 freeDebug 中的 strings.xml 中
FreeDebug
它們合并之后就是
FreeDebug
Hello world!
最后，非常重要的一點，合并或者替換時會遵照優先級：
buildVariant > buildType > buildFlavor> main > 庫依賴項
總結
以上是生活随笔為你收集整理的flavor android build,android BuildType和BuildFlavor的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android 手机号码去重,第135天
- 下一篇： C语言编写Scheme解释器,C语言编写