使用 Gradle 配置 Android 工程
文章目录
0. 前言
自从将 Android 开发工具从 eclipse 迁移到 AndroidStudio 中之后，Android 工程构建越来越方便。见过很多项目中各式各样的 Gradle 配置语法，懵懵懂懂。遂花费近两周时间将官方文档通读一遍并整理出常用 Gradle 配置 Demo，以此博客作为说明。
1. 准备工作
一个最新版本的 AndroidStudio 毋庸置疑。下载地址：请戳。此处使用 3.5 版本。
Gradle 版本 5.4.1 ，无须单独下载，在工程中配置好即可。
2. 基本概念
2.1. Module
软件工程中，通常采用模块化开发的策略，将一个项目划分成若*分，多人协作开发中，每人完成一部分，最终完成整个项目。因此 AndroidStudio 也采用模块化管理的方式编译 Android 工程 。各个模块之间的依赖关系类似于树形结构，主 Module 作为根节点，其余多个库 Module 都直接或简介的被主 Module 引用。
2.2. Project
基于前面的描述，Project 即 AndroidStudio 打开的一个目录，其中包含 N+1 个 Module ，通过 Gradle 构建多个 Module 并最终合并成一个 apk 文件。
其实，在一个 Project 目录中，可以有多个主 Module ，每个主 Module 可以依赖相同的库 Module 并负责生成一个 apk 文件。通常不建议这么使用，因为这样会破坏 Module 之间的树形依赖关系，不利于后期维护。推荐将复用频率较高的库 Module 封装成 aar 文件，通过直接依赖或远程依赖的方式用于不同的主 Module 之中。
2.3. buildType & productFlavor
通过直译的方式 ，可以理解成 构建类型 和 产品特性 。构建类型中，默认包含 debug 和 release 两种类型。一些基本的差异如 ：debug 包允许调试，release 包不允许调试。产品特性可以根据实际需要自行定义，如：收费和免费版本，汉语、英语及日语。不同的特性之间通过维度的概念区分。
最终如上图所示，生成 2x3x2 共 12 种不同的 apk 文件。
3. 工程结构
精简后的 AndroidStudio 工程结构如下：
├── app
│ ├── build.gradle
│ ├── proguard-project.txt
│ └── src
│ └── main
│ ├── AndroidManifest.xml
│ ├── java
│ │ └── com
│ │ └── flueky
│ │ └── demo
│ │ └── MainActivity.java
│ └── res
│ ├── layout
│ │ └── activity_main.xml
│ └── values
│ ├── strings.xml
│ └── styles.xml
├── build.gradle
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── settings.gradle
- 文件夹 app 作为一个 Module ，必须有 build.gradle 文件，src 文件夹包含全部源文件：Java 文件、资源文件、清单文件等。
- 文件 build.gradle 不同于 app/build.gradle , 它用于整个工程的配置，而 app/build.gradle 只作用于 app Module 的配置。
- gradle 包含使用的 gradle 插件版本 。若未指定 ，AndroidStudio 会自动生成最新的 gradle 插件目录。
- gradlew、gradlew.bat 分别是 Mac/Linux 和 Windows 的脚本文件。关联于 gradle 插件版本，不可单独删除。
- settings.gradle 包含整个工程的所有 Module 的声明。
settings.gradle 示例：
// 主Module
include ':app'
// 库Module
include ':library'
// 添加外部库
include 'other-lib'
project(':other-lib').projectDir = new File(rootDir, "../other-sample/library")
4. 配置 Project
4.1. 构建脚本
buildscript {
repositories {
// 仓库地址
google()
jcenter()
mavenCentral()
}
// 工程的依赖配置
dependencies {
// 必须包含的 gradle 版本的构建工具。
classpath 'com.android.tools.build:gradle:3.4.1'
}
}
4.2. 全工程配置
// 全部工程配置，作用于每个 Module
allprojects {
repositories {
// 仓库地址
google()
jcenter()
mavenCentral()
// 依赖仓库，添加用于查找依赖项的目录，可以多个。
flatDir {
// jar、aar 存放的目录
dirs 'libs'
}
}
}
4.3. 扩展变量
// 扩展变量，用于统一管理每个 Module 的有关配置
ext {
// 应用 id
applicationId = "com.flueky.demo"
// 统一控制各个 Module 使用的 SDK 版本
compileSdkVersion = 29
buildToolsVersion = "29.0.0"
minSdkVersion = 19
targetSdkVersion = 29
// 定义 Module 的版本号
app = [
versionCode: 1,
versionName: '1.0.0'
]
}
4.4. 加载配置文件
// 加载其他的 gradle 配置文件，可选
apply from: "config.gradle"
5. 配置 Module
5.1. 加载插件
// 声明 Module 是主 Module，生成 apk 文件
apply plugin: 'com.android.application'
// 声明 Module 是库 Module，生成 aar 文件
apply plugin: 'com.android.library'
// 声明 Module 是 Java 库，生成 jar 文件
apply plugin: 'java-library'
还有很多 Plugin 可以用，如： java web maven-publish 等。
另一种写法，一个 Module 中使用多个插件，如：
plugins {
id 'java'
id 'war'
id 'maven-publish'
}
5.2. 使用SDK
android {
// 定义编译的 sdk 版本，只有使用最新版本的sdk，才能在代码中只用最新的 api 方法
compileSdkVersion rootProject.ext.compileSdkVersion
// 定义构建工具的版本
buildToolsVersion rootProject.ext.buildToolsVersion
}
rootProject.ext 是在 Project 的 build.gradle 文件中声明。
5.3. 默认配置
android{
defaultConfig {
// 应用 id
applicationId rootProject.ext.applicationId
// 最小 sdk 版本，低于此 Android 版本的手机不能安装
minSdkVersion rootProject.ext.minSdkVersion
// 目标 sdk 版本，低于此 Android 版本的手机完美兼容，高于此 Android 版本的手机，部分特性不能使用
// 升级 target 需要针对高版本做兼容。
targetSdkVersion rootProject.ext.targetSdkVersion
// 应用版本号，覆盖安装时，升级版本依据
versionCode rootProject.ext.app.versionCode
// 版本名称，
versionName rootProject.ext.app.versionName
// 指定需要编译 abi 版本的 so
ndk{
abiFilters 'armeabi-v7a'
}
// 设置编译的资源
resConfigs "zh-rCN"
// 多 dex 支持 ，minSdkVersion >= 20 使用
multiDexEnabled true
}
}
5.4. 签名配置
签名文件，至少配置一个。如未使用，debug 包，会使用 user home/.android/debug.keystore 的签名文件。 release 包默认不签名。
// 可以将签名文件信息配置在 keystore.properties 文件中
def ksPropFile = rootProject.file("keystore.properties")
def ksProp = new Properties()
// 加载签名配置文件
ksProp.load(new FileInputStream(ksPropFile))
android{
signingConfigs {
// 生产签名，读取配置文件
release {
keyAlias ksProp['keyAlias']
keyPassword ksProp['keyPassword']
storeFile file(ksProp['storeFile'])
storePassword ksProp['storePassword']
}
// 测试签名，静态配置
debug {
keyAlias 'flueky'
keyPassword 'android'
storeFile file('../demo.keystore')
storePassword 'android'
}
}
}
使用配置的好处是，将生产签名文件信息保存在配置文件中，不添加到版本控制工具中，可以有效防范签名文件信息泄露，被他人使用。
针对签名文件的校验，会有专门的防篡改技术，防止应用被反编译 apk 后二次打包。如签名文件泄露，会构成很大威胁。
5.5. 构建类型
android{
buildTypes {
// 测试版本
debug {
// 允许 Java 代码调试（默认允许）
debuggable true
// 允许 JNI 代码调试（默认允许）
jniDebuggable true
// 签名 信息
signingConfig signingConfigs.debug
// 版本名称后缀
versionNameSuffix = '-beta'
// 应用 Id 后缀
applicationIdSuffix '.debug'
}
// 发行版本
release {
// 禁止 Java 代码调试（默认禁止）
debuggable false
// 禁止 JNI 代码调试 （默认禁止）
jniDebuggable false
signingConfig signingConfigs.release
// build/intermediates/proguard-files 目录下存在三个混淆配置文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
// 允许代码压缩、混淆、优化,默认情况下会使用 R8 压缩
minifyEnabled true
// 允许资源压缩，包括清理无用资源。在生成 apk 时，如需保留被删除的图片使用，keep.xml 声明 。
shrinkResources true
// 配置需要放在主 dex 中的类
// multiDexKeepFile file('multidex-config.txt')
// 或者使用下面的配置，语法同 proguard file
// multiDexKeepProguard file('multidex-config.pro')
}
// 内部使用版本
inner {
// 使用 debug 的配置
initWith debug
applicationIdSuffix '.inner'
}
}
}
AndroidStudio 默认支持 debug 和 release 两种类型。并有一些默认的配置。常用配置见上。
5.6. 产品特性
android{
// 定义两种纬度
flavorDimensions 'stage', 'api'
productFlavors {
// 开发阶段
dev {
dimension 'stage'
}
// 生产阶段
pro {
dimension 'stage'
}
minApi21 {
dimension 'api'
minSdkVersion 21
}
minApi23 {
dimension 'api'
minSdkVersion 23
}
minApi26 {
dimension 'api'
minSdkVersion 26
}
}
}
产品特性和构建类型，不仅仅是在构建的时候修改些配置，还可以在 src 目录下，定义同名的文件夹，存放 java 、res 、assets 和 AndroidManifest.xml 等。用于实现不同的业务逻辑，资源图片等。
5.7. 过滤变体
产品特性和构建类型可以通过组合的方式生成多个 apk 文件。但在实际中可能不需要部分组合方式。忽略后，可加速编译过程。
如，内部使用不需要生产阶段的 apk 文件，配置如下：
android{
// 设置不需要生成 apk 的类型和特性
variantFilter { variant ->
// 将多个 flavor 组合转成字符串数组
def names = variant.flavors*.name
// 获取到 buildType 名称
def type = variant.buildType.name
// 忽略部分不需要生成的 apk
if (names.contains('pro') && type.equals("inner")) {
setIgnore(true)
}
}
}
5.8. 细分APK
android{
splits {
// 注意和 nkd.abiFilters 的冲突
abi {
enable true
// 包含所有版本so 的apk 文件。此配置仅用于 abi 。
// density 中默认会生成包含所有资源的 apk
universalApk true
// 去除 x86 和 x86_64
exclude 'x86', 'x86_64'
}
// 注意和 resConfigs 的冲突
density {
enable true
reset()
include "xhdpi"
// compatibleScreens 'small', 'normal', 'large', 'xlarge'
}
}
}
universalApk 只用在 abi 的配置中。true 表示按照默认的方式将全部 so 打包 。density 中，此值必须为 true。
使用 abi 和 density 要注意同 ndk.abiFilters 和 resConfigs 使用的冲突。
5.9. 添加依赖
依赖第三方库，在新版本 Gradle 中，常用的有 implementation 和 api 。
它们区别是：
- A 中 implementation B , B 中 implementation C 。 B 可以使用 C 的类和方法，A 可以使用 B 的类和方法。
- A 中 implementation B , B 中 api C 。 B 可以使用 C 的类和方法，A 可以使用 B 的类和方法。A 还可以使用 C 的类和方法。
这样的好处是，如果只修改了 Module C , 情况 1 只会重新编译 B 和 C ，情况 2 会重新编译 A B C 。 因此在实际应用中，避免大量使用 api 的方式。
下面列举了对 jar 文件、 aar 文件和 maven 库文件的依赖方式。
dependencies {
// 依赖同级的 libs 目录，只包含jar
implementation fileTree(include: '*.jar', dir: 'libs')
// 依赖同级的 libs 目录，包含 jar 和 aar，还可以选择不包含指定文件
implementation fileTree(dir: 'libs', include: ['*.aar', '*.jar'], exclude: [])
// debug 类型的依赖
debugImplementation fileTree(include: '*.jar', dir: 'src/debug/libs')
// release 类型的依赖
releaseImplementation fileTree(include: '*.jar', dir: 'src/release/libs')
// 同理 devImplementation minApi21Implementation innerImplementation
// 如果 需要组合使用，如 devMinApi21DebugImplementation，见 configurations
// 依赖本地 module
implementation project(':library')
implementation project(':other-lib')
// 等同于带 path 参数
// implementation project(path: ':library')
// 依赖远程库，不建议在版本号中使用 + 通配符,括号可以省略
implementation 'com.android.support:appcompat-v7:28.0.0'
implementation('com.android.support:support-v4:28.0.0') {
// 一个远程库可能包含多个第三方库，可以排除指定库
exclude group: 'com.android.support', module: 'collections'
}
// 等同于复杂形势
// implementation group: 'com.android.support', name: 'support-v4', version: '28.0.0'
implementation 'com.google.dagger:dagger:2.24'
annotationProcessor 'com.google.dagger:dagger-compiler:2.24'
// 5.0 之前多 dex 支持，minSdkVersion < 20 必须使用。
implementation 'androidx.multidex:multidex:2.0.1'
}
注意到上面的配置中存在 debugImplementation 和 releaseImplementation 。这是对不同构建类型单独指定的依赖方式。
产品特性也可以使用上面的配置，但是需要先声明，方式如下：
configurations {
// 添加多个依赖项配置
devMinApi21DebugImplementation {}
devMinApi21Api {}
devDebugCompileOnly {}
minApi21DebugRuntimeOnly {}
}
篇幅有限 ，以上介绍均是常用配置。更多配置请见源码。
- 修改生成的 apk 文件目录。
- 修改生成的 apk 文件名称。
- 动态修改版本号。
- 替换 build 缓存目录。
- AndroidManifest.xml 注入变量。
关于 AndroidManifest.xml 合并冲突，有机会在后面的文章中讲。
6. 常见问题
6.1. 问题1
主 Module 有 inner 的构建类型，库 Module 中、没有 ，构建 app 时会报错。
可在库 Module 中添加 inner 的构建类型，或者在主 Module 的 inner 类型中，添加下面的配置。
// inner 匹配失败 ， debug 匹配成功， release 忽略
matchingFallbacks = ['inner', 'debug', 'release']
如需匹配 release 时，将 release 放在 debug 前，或者直接删除 debug 。
6.2. 问题2
主 Module 有的产品特性，库 Module 中没有，构建 app 时会报错。
错误原因同 问题 1 。如，库 Module 中存在其他类似的产品特性，可使用匹配的方式 ，如下：
android{
productFlavor{
minApi21 {
minSdkVersion 21
// 库 module 没有 minApi21 ，匹配较高版本
// 同时需要在 AndroidManifest.xml 中使用 overrideLibrary
matchingFallbacks = ['minApi23']
}
minApi26 {
minSdkVersion 26
// 库 module 没有 minApi26 ，匹配较低版本，可兼容
matchingFallbacks = ['minApi23']
}
}
}
如，库 Module 中没有定义任何产品特性，可以直接在 defauleConfig 中，忽略对维度的依赖 。
android{
defauleConfig{
// 库 module 没有开发进度的维度，因此忽略
missingDimensionStrategy 'dev', 'pro'
}
}
6.3. 问题3
主 Module 的 minSdk 小于 库 Module 的 minSdk。
使用 overrideLibrary ，指定复写库 Module 的 packageName 。
<manifest xmlns:tools="http://schemas.android.com/tools">
<!-- minSdkVersion 存在冲突的解决方案-->
<uses-sdk tools:overrideLibrary="com.flueky.library" />
</manifest>
源码地址。
觉得有用？那打赏一个呗。去打赏
上一篇： 做抖音短视频的十大误区，你掉坑了吗？
下一篇： JS实现堆排序