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语言编写