牛客高级系列专栏：

安卓

• 想通关安卓面试，请看：《150道安卓高频面试题目录及答案链接》
• 想通关安卓系统面试，请看：《140道安卓系统Framework面试题目录及答案链接》
• 想进阶安卓开发，请看：《Android进阶知识体系解析_15大安卓进阶必备知识点》
• 想了解安卓APP完整开发流程，请看：《安卓APP完整开发流程》
• 想掌握安卓App性能优化，请看：《安卓性能优化讲解和实战专栏》
• 想掌握Gradle语法，制作Gradle插件，请看：《安卓Gradle语法解析和实践大全》

嵌入式

• 想通关嵌入式面试，请看： 《111道嵌入式面试题目录及答案链接》
• 想多掌握几个嵌入式项目，请看：《6个嵌入式项目交流分享（附源码）》

本人是2020年毕业于广东工业大学研究生：许乔丹，有国内大厂CVTE和世界500强企业安卓开发经验，网上安卓资料千千万，笔者将继续维护专栏，一杯奶茶价格不止提供答案解析，承诺提供专栏内容免费技术答疑，直接咨询即可。助您快速掌握安卓App完整开发流程！

正文开始⬇

1、为何需要定制不同的APK

在 Android 开发中，同一个工程需要定制不同的 APK 通常是为了满足不同的业务需求或客户需求。这些不同的需求可能包括以下几个方面：

• 功能差异：不同的业务需求可能导致应用程序有不同的功能，例如特定的业务流程、特殊的功能模块和组件等。比如开发一个聊天APP，普通版本不支持发送图片功能，只有VIP版本才支持。这时候工程里肯定是要有包含图片发送功能的代码，只是打包为普通APP时，不打包该部分的代码罢了。
• 外观差异：不同的客户可能有不同的品牌和视觉识别，因此需要根据其品牌和设计要求个性化定制应用程序的外观和交互设计，最常见的就是同一个工程可以编译出的不同的APK的图标和名称。
• 功能配置差异：某些应用程序功能可能需要定制特定的参数和配置。比如用于debug的APK不应该配置混淆，因为混淆会增加编译耗时，又会导致出错时堆栈信息不容易追述的问题。

在应用程序建立后，定制不同的 APK 通常需要对应用程序进行以下步骤：

• 根据实际需求，在应用程序中添加或删除某些功能/模块。
• 根据品牌和视觉识别，修改应用程序的图标、主题、颜色等。
• 根据客户要求，配置应用程序的一些参数或者接口。

针对不同的需要使用不同的签名证书，以保证不同 APK 的独立分发和更新。 因此，通过制定和分发定制版本的 APK，可以让用户获得更专业、有针对性的产品和服务。

2、构建变体

定制不同的APK，有一个专业的术语叫做“构建变体”。构建变体主要由build.gradle的两个参数决定：

• build types:定义一个产品的不同开发周期，最常见的就是debug和release两个开发周期，相信这两个大家都很熟悉；
• product flavors:定义多个不同的产品，就像上述说的聊天APP可以分为普通版本和VIP版本两个产品，里面的功能会有所差异；

一个工程可以编译出的APK的个数 = build types数值 * product flavors数值。举个例子，此时定义了debug和release两个开发阶段，且定义了聊天APP普通版本和VIP版，那么此时就有以下2 * 2 = 4个APK包：

• 普通版本debug包；
• 普通版本release包；
• VIP版本debug包；
• VIP版本release包；

那么我们实际演示下，打开app子模块的build.gradle，添加如下代码：

# 
buildTypes { //定义release和debug两个开发阶段
    release {
        minifyEnabled true
        signingConfig signingConfigs.config
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
    debug {
        minifyEnabled false
        signingConfig signingConfigs.config
    }
}

flavorDimensions "version"  //定义一个维度：“版本”

productFlavors {
    normal { //普通产品
        dimension "version" // 该产品属于的维度是“版本”
        applicationIdSuffix ".normal" //在应用程序的包名称中添加.normal后缀
    }
    VIP { //VIP产品
        dimension "version" // 该产品属于的维度是“版本”
        applicationIdSuffix ".vip"//在应用程序的包名称中添加.vip后缀
    }
}

• flavorDimensions：我们通过productFlavors定义的产品，需要指定一个“维度”，因为现在定义了普通版本产品和VIP版本产品，所以可以指定的维度就是“版本”。再举一个例子，如果我们定义的产品是游戏，分为“剧情版”和“动作版”两种游戏，那么就可以设置一个维度叫“style“（风格）；
• dimension：指定产品属于的纬度；
• applicationIdSuffix：在应用程序的包名称中添加一个后缀

此时在Build Variants里面就可以查到这4个变体。

3、buildTypes和productFlavors常见的配置

除了上面例子所用到的配置，buildTypes和productFlavors里面常见的配置如下：

3.1 buildTypes

• debuggable: 当前构建类型是否为调试模式。默认为 true。
• jniDebuggable: 当前构建类型是否可以调试NDK代码。默认为 true。
• minifyEnabled: 是否启用混淆。默认为 false，生产版本应该设置为 true。
• proguardFiles: 指定要使用的 ProGuard 规则文件的位置（文件名或路径）。它是混淆过程的一部分，可用于缩小 APK 文件的大小并更好地保护应用程序代码。
• signingConfig: 指定签名配置以对 APK 进行签名。可以使用内置的 debug 配置或自定义的 release 配置。
• buildConfigField: 定义在编译时生成的 BuildConfig 类中的自定义构建配置字段
• applicationIdSuffix: 为应用程序的包名称添加后缀以创建不同的变体。
• shrinkResources: 是否自动清理未使用的资源，默认为false。
• zipAlignEnabled: 是否开启zipalign优化，提高APK的运行效率。
• multiDexEnabled：是否启动自动拆分为多个Dex的功能。

3.2 productFlavors

• name: 产品风格的名称。
• applicationId: 为该产品风格定义的应用程序包名称。
• versionCode: 该产品风格的版本号。
• versionName: 该产品风格的版本名称。
• minSdkVersion: 该产品风格支持的最低 API 级别。
• targetSdkVersion: 该产品风格所针对的 API 级别。
• testApplicationId: 用于测试该产品风格的应用程序包名称。
• testInstrumentationRunner: 用于运行该风格的测试的 Runner 类。
• manifestPlaceholders: 在 AndroidManifest 中定义的占位符变量。可以用来替换不同风格之间的字符串和 URL。
• resValue: 在编译时生成的资源值（例如颜色、字符串和布尔值）。
• buildConfigField: 在编译时生成的 BuildConfig 类中的定义字段（例如应用程序的 API 密钥）。
• dimension：指定产品风格所属的维度。

为方便读者进一步理解，写了以下的demo，该demo没有实际含义，只是方便进一步理解，注意buildTypes和productFlavors的配置会有重复配置哦，实际开发中要注意。上述的场景配置我集中写在buildTypes-release和productFlavors-normal这两个配置项下面：

apply plugin: 'com.android.application'

android {
    compileSdkVersion 30
    buildToolsVersion "30.0.3"

    defaultConfig {
        applicationId "com.example.