一、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源集】的资源。

---

写作不易，耗费心力，如果上面的内容对你有帮助，请随意打赏，让我们坚持下去~