一、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源集】的资源。
写作不易,耗费心力,如果上面的内容对你有帮助,请随意打赏,让我们坚持下去~