【Gradle-2】一文搞懂Gradle配置

1、前言

“Gradle的配置太多了，经常版本更新还有变化，而且它还能扩展，记是记不住了，只能用到再搜了，哎，难顶”
真的难顶，但是我想挑战一下…

本文介绍的重点：

1. Gradle配置简介
2. Gradle中的配置有哪些，都是用来干什么的，以及7.0版本之后的变化；
3. Gradle中的配置怎么来的；

前置必读：https://blog.csdn.net/yechaoa/article/details/130174456

2、Gradle配置简介

Gradle的配置主要是用来管理Gradle自己的运行环境和我们的项目，这句话听起来有点抽象，用大白话拆解一下：

1. 第一点其实很好理解，比如Gradle需要java11的运行环境，再比如我们为了加快编译而给Gradle设置更大的运行空间org.gradle.jvmargs=-Xmx2048m等，这类配置往往相对固定的，因为它是跟随项目走的，即使是多团队协作，大家基本也都是用的同一个环境。
2. 第二点，Gradle作为构建工具，主要是帮助我们编译打包apk的，apk是由各种文件组成的，比较多见的是代码文件和资源文件，那其实可以理解为Gradle本质上是在帮我们管理这些散落在各处的文件，比如代码文件有app目录下的源码、module、还有依赖的jar和aar等等，而配置可以决定我们依赖哪些代码，也可以决定哪些代码进入merge，以及打出来的apk产物是release还是debug，但是这类配置往往并不是固定不变的，它是根据开发人员的需求走的，比如提测用debug包，发布用release包，针对厂商适配可能还要再定制一个渠道包，又或者我需要修改一下版本号等等，这些都是通过配置来改的，具有一定的动态可配性。

2.1、配置的优先级

为什么会有优先级的说法呢，是因为Gradle的配置不仅丰富，而且渠道还不是单一的，这种渠道的不单一，也说明了Gradle优秀的扩展性和定制性。

比如我们要运行编译，既可以用Android Studio自带的可视快捷按钮，也可以使用命令行，而这两种编译方式的取配置是不一样的（根据优先级），那自然编译的结果也不一样，所以搞清楚配置的优先级也能帮助我们在不同场景下的使用需求。

优先级分以下4种（由高到低）：

1. Command-line flags：命令行标志，如–stacktrace，这些优先于属性和环境变量；
2. System properties：系统属性，如systemProp.http.proxyHost=somehost.org存储在gradle.properties文件中；
3. Gradle properties：Gradle属性，如org.gradle.caching=true，通常存储在项目根目录或GRADLE_USER_HOME环境变量中的gradle.properties文件中；
4. Environment variables：环境变量，如GRADLE_OPTS，由执行Gradle的环境源；

以上4种，我们较常用的是命令行标志和项目根目录的gradle.properties文件。

2.2、项目初始配置

Android Studio Dolphin | 2021.3.1
Gradle 7.4

看一下新建项目之后的初始配置：

有两个一级目录，分别是app和Gradle Scripts，Gradle Scripts里面除了proguard-rules.pro用于混淆之外，其余的6个文件配置今天都会介绍到。

为了把这些文件的关系看的更直观一点，打印个tree看看：

.
├── README.md
├── app
│   ├── build.gradle
│   ├── ...
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradle.properties
├── local.properties
└── settings.gradle

3、Gradle配置

3.1、gradle-wrapper

.
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat

顾名思义，wrapper是对Gradle的一层封装，封装的意义在于可以使Gradle的版本跟着项目走，这样这个项目就可以很方便的在不同的设备上运行，比如开源项目一般都不会把gradle文件夹设置到gitignore文件里，就是为了保证你clone下来是可以运行的，在团队协作上也是如此。

下面介绍一下上面这几个文件的作用：

• gradle-wrapper.jar：主要是Gradle的运行逻辑，包含下载Gradle；
• gradle-wrapper.properties：gradle-wrapper的配置文件，核心是定义了Gradle版本；
• gradlew：gradle wrapper的简称，linux下的执行脚本
• gradlew.bat：windows下的执行脚本

重点看一下gradle-wrapper.properties：

#Sun Oct 16 15:59:36 CST 2022
distributionBase=GRADLE_USER_HOME
distributionUrl=https\://services.gradle.org/distributions/gradle-7.4-bin.zip
distributionPath=wrapper/dists
zipStorePath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME

• distributionBase：下载的Gradle的压缩包解压后的主目录；
• zipStoreBase：同distributionBase，不过是存放zip压缩包的主目录；
• distributionPath：相对于distributionBase的解压后的Gradle的路径，为wrapper/dists；
• zipStorePath：同distributionPath，不过是存放zip压缩包的；
• distributionUrl：Gradle版本的下载地址；

Gradle版本的下载地址，可以查看Gradle官方的版本发布，或者去Gradle的Github。

这里有几种类型，分别是all、bin、doc：

• doc：顾名思义，用户文档；
• bin：即binary，可运行并不包含多余的东西；
• all：包含所有，除了bin之外还有用户文档、sample等；

所以一般选择bin就可以了。

Gradle、Android Gradle Plugin、Android Studio三者的版本映射关系查看Android官网Gradle版本说明。

AGP > Gradle：

AS > AGP：

3.2、build.gradle（Project）

位于项目的根目录下，用于定义适用于项目中所有模块的依赖项。

3.2.1、7.0之后

Gradle7.0之后，project下的build.gradle文件变动很大，默认只有plugin的引用了，其他原有的配置挪到settings.gradle文件中了。

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    id 'com.android.application' version '7.3.0' apply false
    id 'com.android.library' version '7.3.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.7.10' apply false
}

plugin格式：

id «plugin id» version «plugin version» [apply «false»]   

id和version比较好理解。
apply false表示不将该plugin应用于当前项目，比如在多项目构建中，我只想在某个子项目依赖该plugin就好了，那可以这么写：

plugins {
  id "yechaoa" version "1.0.0" apply false
}

subprojects { subproject ->
    if (subproject.name == "subProject") {
        apply plugin: 'yechaoa'
    }
}

apply plugin在7.0之前的写法：

apply plugin: 'kotlin-android'

// 加上下面

buildscript {
    ...
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.20"
    }
}

除了自带插件和远端插件之外，还可以是我们自定义的脚本插件，比如自定义了一个common.gradle

apply from: 'common.gradle'

这两种方式的区别：

• apply plugin：‘yechaoa’：叫做二进制插件，二进制插件一般都是被打包在一个jar里独立发布的，比如我们自定义的插件，再发布的时候我们也可以为其指定plugin id，这个plugin id最好是一个全限定名称，就像你的包名一样；
• apply from：‘yechaoa.gradle’：叫做应用脚本插件，应用脚本插件，其实就是把这个脚本加载进来，和二进制插件不同的是它使用的是from关键字，后面紧跟一个脚本文件，可以是本地的，也可以是网络存在的，如果是网络上的话要使用HTTP URL。
  • 虽然它不是一个真正的插件，但是不能忽视它的作用，它是脚本文件模块化的基础，我们可以把庞大的脚本文件进行分块、分段整理拆分成一个个共用、职责分明的文件，然后使用apply from来引用它们，比如我们可以把常用的函数放在一个utils.gradle脚本里，供其他脚本文件引用。

后面的文章也会讲到插件的依赖管理。

3.2.1、7.0之前

来看下Gradle7.0之前，project下的build.gradle文件

// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
    ext.kotlin_version = "1.5.0"
    repositories {
        google()
        mavenCentral()
    }
    dependencies {
        classpath "com.android.tools.build:gradle:4.2.1"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
        jcenter() // Warning: this repository is going to shut down soon
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

buildscript

buildscript中的声明是gradle脚本自身需要使用的资源。可以声明的资源包括依赖项、第三方插件、maven仓库地址等。7.0之后改在settings.gradle中配置了（pluginManagement）。
多聊一点，为什么需要buildscript/pluginManagement，因为项目的编译过程，除了项目本身需要的依赖之外，还有就是Gradle自己运行需要的依赖，比如你的插件要去hook Gradle的生命周期，因为运行时机的不同，所以加了一个script，当然buildSrc也可以解决这个问题。

ext

项目全局属性，多用于自定义，比如把关于版本的信息都利用ext放在另一个新建的gradle文件中集中管理，比如version.gradle，然后apply引用即可，这是较为早期的版本管理方式。

repositories

仓库，比如google()、maven()、jcenter()、jitpack等三方托管平台。

dependencies

当然配置了仓库还不够，我们还需要在dependencies{}里面的配置里，把需要配置的依赖用classpath配置上，因为这个dependencies在buildscript{}里面，所以代表的是Gradle需要的插件。
7.0之后把plugin的配置简化了，由apply+classpath简化为只要apply就可以了。

allprojects

allprojects块的repositories用于多项目构建，为所有项目提供共同所需依赖包。而子项目可以配置自己的repositories以获取自己独需的依赖包。

task clean(type: Delete)

运行gradle clean时，执行此处定义的task。
该任务继承自Delete，删除根目录中的build目录。相当于执行Delete.delete(rootProject.buildDir)。其实这个任务的执行就是可以删除生成的Build文件的，跟Android Studio的clean是一个道理。

3.3、build.gradle（Module）

位于每个 project/module/ 目录下，用于为其所在的特定模块配置 build 设置。

3.2.1、7.0之后

其实跟7.0之前差别也不是太大。

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

android {
    namespace 'com.yechaoa.gradlex'
    compileSdk 32

    defaultConfig {
        applicationId "com.yechaoa.gradlex"
        minSdk 23
        targetSdk 32
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    kotlinOptions {
        jvmTarget = '1.8'
    }
}

dependencies {

    implementation 'androidx.core:core-ktx:1.7.0'
    implementation 'androidx.appcompat:appcompat:1.4.1'
    implementation 'com.google.android.material:material:1.5.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.3'
    testImplementation 'junit:junit:4.13.2'
    androidTestImplementation 'androidx.test.ext:junit:1.1.3'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
}

3.3.1、7.0之前

apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'

android {
    compileSdkVersion 30

    defaultConfig {
        applicationId "com.yechaoa.app"
        minSdkVersion 19
        targetSdkVersion 30
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner 'androidx.test.runner.AndroidJUnitRunner'
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

    buildFeatures {
        viewBinding = true
    }

}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
    implementation 'androidx.appcompat:appcompat:1.2.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
    testImplementation 'junit:junit:4.13.2'
    androidTestImplementation 'androidx.test.ext:junit:1.1.2'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'

    implementation "com.google.android.material:material:1.3.0"

    implementation project(':yutils')
    implementation project(':yutilskt')
}

plugins/apply plugin

前文介绍了，参考 # 3.2、build.gradle（Project）

namespace

应用程序的命名空间。主要用于访问应用程序资源。

com.android.application

• App插件id：com.android.application
• Library插件id：com.android.library
• Kotlin插件id：org.jetbrains.kotlin.android

android{}

是Android插件提供的一个扩展类型，可以让我们自定义Gradle Android工程，是Gradle Android工程配置的唯一入口。

compileSdkVersion/compileSdk

编译所依赖的Android SDK的版本，即API Level，可以使用此API级别及更低级别中包含的API功能。
（api等级对应关系）

buildToolsVersion

是构建该Android工程所用构建工具的版本。
后被废弃了，因为7.0之后，假如你的buildToolsVersion是30.0.1，低于AGP7.0.2所要求的的最低版本30.0.2，那就会使用30.0.2的版本，而不是你指定的版本，后续AGP会应用一个对应的默认的版本。

defaultConfig{}

默认配置，它是一个ProductFlavor。ProductFlavor允许我们根据不同的情况同时生成多个不同的apk包。

applicationId

包名，app的唯一标识。其实他跟AndroidManifest里面的package是可以不同的，他们之间并没有直接的关系。

minSdkVersion/minSdk

是支持Android系统的api level，这里是23，也就是说低于Android 6.0版本的机型不能使用这个app。

targetSdkVersion/targetSdk

是标示app基于哪个Android版本开发的，这里是32，也就是适配到Android 12.0。

versionCode

版本号，一般用于版本控制。

versionName

版本名称，公开信息，默认1.0，7.0之前默认是1.0.0，行业规范3位数，但并没有强制。

multiDexEnabled

用于配置该BuildType是否启用自动拆分多个Dex的功能。一般用程序中代码太多，超过了65535个方法的时候。

ndk{}

多平台编译，生成有so包的时候使用，之前用armeabi的比较多，要求做32/64位适配之后开始拆分（提高性能），'armeabi-v7a’表示32位cpu架构, 'arm64-v8a’表示64位, 'x86’是只模拟器或特定rom。
一般使用第三方提供的SDK的时候，可能会附带so库。

sourceSets

源代码集合，是Java插件用来描述和管理源代码及资源的一个抽象概念，是一个Java源代码文件和资源文件的集合，我们可以通过sourceSets更改源集的Java目录或者资源目录等。

buildTypes

构建类型，在Gradle Android工程中，它已经帮我们内置了release构建类型，一般还会加上debug，两种模式主要区别在于，能否在设备上调试以及签名不一样，其他代码和文件资源都是一样的（如果没有做处理的话-log）。

    buildTypes {
        debug {
            buildConfigField("String", "AUTHOR", "\"yechaoa\"")
            minifyEnabled false
        }
        release {
            buildConfigField("String", "AUTHOR", "\"yechaoa\"")
            signingConfig signingConfigs.release
            shrinkResources true
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

• name：build type的名字
• applicationIdSuffix：应用id后缀
• versionNameSuffix：版本名称后缀
• debuggable：是否生成一个debug的apk
• minifyEnabled：是否混淆
• proguardFiles：混淆文件
• signingConfig：签名配置
• manifestPlaceholders：清单占位符
• shrinkResources：是否去除未利用的资源，默认false，表示不去除。
• zipAlignEnable：是否使用zipalign工具压缩。
• multiDexEnabled：是否拆成多个Dex
• multiDexKeepFile：指定文本文件编译进主Dex文件中
• multiDexKeepProguard：指定混淆文件编译进主Dex文件中

signingConfigs

签名配置，一个app只有在签名之后才能被发布、安装、使用，签名是保护app的方式，标记该app的唯一性。

    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile file(keystoreProperties['storeFile'])
            storePassword keystoreProperties['storePassword']
            v1SigningEnabled true
            v2SigningEnabled true
        }
    }

官方建议不直接明文写，而是从文件读取。

productFlavors

多渠道打包配置，可以实现定制化版本的需求。

buildConfigField

他是BuildConfig文件的一个函数，而BuildConfig这个类是Android Gradle构建脚本在编译后生成的。比如版本号、一些标识位什么的。

Build Variants

选择编译的版本。

buildFeatures

开启或关闭构建功能，常见的有viewBinding、dataBinding、compose。

    buildFeatures {
        viewBinding = true
        // dataBinding = true
    }

dexOptions{}

我们知道，Android中的Java/kotlin源代码被编译成class字节码后，在打包成apk的时候被dx命令优化成Android虚拟机可执行的dex文件。
对于这些生成dex文件的过程和处理，Android Gradle插件都帮我们处理好了，Android Gradle插件会调用SDK中的dx命令进行处理。
可以设置编译时所占用的内存（javaMaxHeapSize），从而提升编译速度。
7.0之后已经废弃。

compileOptions

Java编译选项，指定java环境版本。

kotlinOptions

Kotlin编译选项，通常指定jvm环境。

composeOptions

Compose功能的可选设置。比如指定Kotlin Compiler版本，一般用默认。

lintOptions

用于配置lint选项。Example

dependencies{}

我们平时用的最多的大概就这个了，Gradle3.2之后有依赖方式的变更，因为不支持依赖关系细粒度的范围界定。

• compile > implementation/api
• androidTestCompile > androidTestImplementation
• testCompile > testImplementation
• instrumentTest > androidTest

implementation 'androidx.core:core-ktx:1.7.0'

implementation和api的区别

implementation指令依赖是不会传递的，也就是说当前引用的第三方库仅限于本module内使用，其他module需要重新添加依赖才能用，使用api指令的话可以传递。（后面也会细讲依赖）
一图胜千言：

图源：19snow93

3.4、settings.gradle

位于项目的根目录下，用于定义项目级代码库设置。

pluginManagement {
    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "GradleX"
include ':app'

pluginManagement

插件管理，指定插件下载的仓库，及版本。

dependencyResolutionManagement

依赖管理，指定依赖库的仓库地址，及版本。即7.0之前的allprojects。
顺序决定了先从哪个仓库去找依赖库并下载，一般为了编译稳定，会把阿里的镜像地址（或自建私有仓库）放在Google()仓库之前。

rootProject.name

项目名称。

include

用于指定构建应用时应将哪些模块包含在内，即参与构建的模块。
也可用于动态引用，在编译提速时，会module打成aar依赖来节省编译时间，但是为了开发方便，一般会动态选择哪些module使用源码依赖。

3.5、gradle.properties

位于项目的根目录下，用于指定 Gradle 构建工具包本身的设置，也可用于项目版本管理。

Gradle本身配置

比如Gradle 守护程序的最大堆大小、编译缓存、并行编译、是否使用Androidx等等。

# Project-wide Gradle settings.
# IDE (e.g. Android Studio) users:
# Gradle settings configured through the IDE *will override*
# any settings specified in this file.
# For more details on how to configure your build environment visit
# http://www.gradle.org/docs/current/userguide/build_environment.html
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m
# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. More details, visit
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
# org.gradle.parallel=true
# AndroidX package structure to make it clearer which packages are bundled with the
# Android operating system, and which are packaged with your app"s APK
# https://developer.android.com/topic/libraries/support-library/androidx-rn
android.useAndroidX=true
# Automatically convert third-party libraries to use AndroidX
android.enableJetifier=true
# Kotlin code style for this project: "official" or "obsolete":
kotlin.code.style=official

# ---------- 编译相关 start ----------

#并行编译
org.gradle.parallel=true

#构建缓存
org.gradle.caching=true

# ---------- 编译相关 end ----------

版本管理

# ---------- 版本相关 start ----------

yechaoaPluginVersion="1.0.0"

# ---------- 版本相关 end ----------

在版本管理中，可以从gradle.properties文件中读取版本，不仅可以作用于依赖库，也可作用于依赖插件。本质上是key-value形式的参数。

pluginManagement {
  plugins {
        id 'com.yechaoa.gradlex' version "${yechaoaPluginVersion}"
    }
}

3.6、local.properties

位于项目的根目录下，用于指定 Gradle 构建配置本地环境属性，也可用于项目环境管理。

本地配置

## This file must *NOT* be checked into Version Control Systems,
# as it contains information specific to your local configuration.
#
# Location of the SDK. This is only used by Gradle.
# For customization when using a Version Control System, please read the
# header note.
#Mon Feb 08 19:07:41 CST 2021
sdk.dir=/Users/yechao/Library/Android/sdk
ndk.dir=/Users/yechao/Library/Android/ndk

• sdk.dir：SDK 的路径
• ndk.dir：NDK 的路径，已废弃，用SDK目录下的NDK目录。

环境管理

可以用作项目本地调试的一些开关：

isRelease=true
#isDebug=false
#isH5Debug=false

4、Gradle配置怎么来的

前面介绍了这么多的Gradle配置，最常用的就是app > build.gradle了，这个文件里的配置是最多的，也是跟Android开发打交道最多的，那么，这些配置是哪里来的呢？

再来回顾一下app > build.gradle：

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

android {
    namespace 'com.yechaoa.gradlex'
    compileSdk 32

    defaultConfig {
        applicationId "com.yechaoa.gradlex"
        minSdk 23
        targetSdk 32
        versionCode 1
        versionName "1.0"
    }
}

dependencies {
    implementation 'androidx.core:core-ktx:1.7.0'
}

按结构可以分为3部分，plugins、android和dependencies。

在上一篇入门文章中我们讲到，Gradle是一个通用的自动化构建工具，通用也就是说，不仅可以构建Android项目，还可以构建java、kotlin、swift等项目。再结合android{}里面的配置属性，我们可以确定，那这就是Android项目专属的配置DSL了。

既然如此，如果让你来设计Gradle的架构框架你会怎么做？

这种架构通常都是底层通用能力＋上层定制化的经典设计，上层定制化也就是说Android项目有Android的配置DSL，Java项目有Java配置的DSL，不同项目有不同配置。

那么回到问题本身，android{}是怎么来的，创建项目就有，那是跟随开发工具来的？好像也不对啊，Android Studio不仅可以开发Android项目啊，别的也行，而且别的开发工具也能开发Android项目呢。那既然不是跟随开发工具，又要做到定制化，那是怎么来的。

回到build.gradle配置结构的第一部分：

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
}

注意到，这里有一个名为com.android.application的plugin，看名字也是android项目专属无疑了，再去源码里看一下这个plugin是干嘛的。

看Gradle源码有个比较简单的方式，就是直接拉依赖，比如我现在用的Gradle7.4，直接依赖对应版本：

implementation "com.android.tools.build:gradle:7.4"

如果发现还是点不进去源码，再把下载Gradle的类型改了，gradle-7.4-bin.zip > gradle-7.4-all.zip。完事重新sync就可以直接点进源码了。

先看下android{}的提示：

提炼几个信息：

1. BaseAppModuleExtension
2. com.android.build.gradle.internal.dsl
3. Closure
4. org.gradle.api.Project

这几个信息足够验证我们之前的猜想了，android{}是通过插件的方式引入的。

然后点进去：

@HasInternalProtocol
public interface Project extends Comparable<Project>, ExtensionAware, PluginAware {
    ...
    /**
     * 
Configures the dependencies for this project.
     *
     * 
This method executes the given closure against the {@link DependencyHandler} for this project. The {@link
     * DependencyHandler} is passed to the closure as the closure's delegate.
     *
     * 
Examples:
     * See docs for {@link DependencyHandler}
     *
     * @param configureClosure the closure to use to configure the dependencies.
     */
    void dependencies(Closure configureClosure);
    ...
}

是一个dependencies函数，接收一个闭包。

再来看BaseAppModuleExtension 的android：

android(Closure configuration)

也是接收一个闭包，这个闭包其实就是android{}这个配置，配置里面定义的就是我们日常编译运行需要的配置参数，defaultConfig、minSdk、versionCode之类的。

再看下BaseAppModuleExtension源码：

/** The `android` extension for base feature module (application plugin).  */
open class BaseAppModuleExtension(
    dslServices: DslServices,
    bootClasspathConfig: BootClasspathConfig,
    buildOutputs: NamedDomainObjectContainer<BaseVariantOutput>,
    sourceSetManager: SourceSetManager,
    extraModelInfo: ExtraModelInfo,
    private val publicExtensionImpl: ApplicationExtensionImpl
) : AppExtension(
    dslServices,
    bootClasspathConfig,
    buildOutputs,
    sourceSetManager,
    extraModelInfo,
    true
), InternalApplicationExtension by publicExtensionImpl {

    // Overrides to make the parameterized types match, due to BaseExtension being part of
    // the previous public API and not wanting to paramerterize that.
    override val buildTypes: NamedDomainObjectContainer<BuildType>
        get() = publicExtensionImpl.buildTypes as NamedDomainObjectContainer<BuildType>
    override val defaultConfig: DefaultConfig
        get() = publicExtensionImpl.defaultConfig as DefaultConfig
    override val productFlavors: NamedDomainObjectContainer<ProductFlavor>
        get() = publicExtensionImpl.productFlavors as NamedDomainObjectContainer<ProductFlavor>
    override val sourceSets: NamedDomainObjectContainer<AndroidSourceSet>
        get() = publicExtensionImpl.sourceSets

    override val composeOptions: ComposeOptions = publicExtensionImpl.composeOptions

    override val bundle: BundleOptions = publicExtensionImpl.bundle as BundleOptions

    override val flavorDimensionList: MutableList<String>
        get() = flavorDimensions

    override val buildToolsRevision: Revision
        get() = Revision.parseRevision(buildToolsVersion, Revision.Precision.MICRO)

    override val libraryRequests: MutableCollection<LibraryRequest>
        get() = publicExtensionImpl.libraryRequests
}

我们可以看到一些熟悉的配置，比如buildTypes、defaultConfig、sourceSets等等。不过这只是一部分，剩下的配置在父类AppExtension里，就不贴代码了。

然后android{}这个配置标签是怎么创建出来的呢？

/** Gradle plugin class for 'application' projects, applied on the base application module */
public class AppPlugin extends AbstractAppPlugin<...> {

    //...
                    
    @NonNull
    @Override
    protected ExtensionData<...> createExtension(...) {
        // ...

        if (getProjectServices().getProjectOptions().get(BooleanOption.USE_NEW_DSL_INTERFACES)) {
            // noinspection unchecked,rawtypes: Hacks to make the parameterized types make sense
            Class<ApplicationExtension> instanceType = (Class) BaseAppModuleExtension.class;
            BaseAppModuleExtension android =
                    (BaseAppModuleExtension)
                            project.getExtensions()
                                    .create(
                                            new TypeOf<ApplicationExtension>() {},
                                            "android",
                                            instanceType,
                                            dslServices,
                                            bootClasspathConfig,
                                            buildOutputs,
                                            dslContainers.getSourceSetManager(),
                                            extraModelInfo,
                                            applicationExtension);
            project.getExtensions()
                    .add(
                            BaseAppModuleExtension.class,
                            "_internal_legacy_android_extension",
                            android);

            initExtensionFromSettings(applicationExtension);

            return new ExtensionData<>(android, applicationExtension, bootClasspathConfig);
        }

        BaseAppModuleExtension android =
                project.getExtensions()
                        .create(
                                "android",
                                BaseAppModuleExtension.class,
                                dslServices,
                                bootClasspathConfig,
                                buildOutputs,
                                dslContainers.getSourceSetManager(),
                                extraModelInfo,
                                applicationExtension);
        initExtensionFromSettings(android);
        return new ExtensionData<>(android, applicationExtension, bootClasspathConfig);
    }
    //...
}

我把多余代码都删了，简而言之，在AppPlugin里用project.getExtensions().create()方法创建的"android"标签，AppPlugin即id为’com.android.application’的插件，跟自定义Plugin一样配置，后续再展开。

其实所有的DSL配置都是通过插件的方式引入的。

最后我们再来捋一下思路：

1. 通过依赖’com.android.application’插件，有了android{}这个配置DSL；
2. 一个项目对应一个Project对象，Project对象里面包含dependencies函数；
3. android{}这个配置DSL点进去就是Project对象里面dependencies这个函数，二者都接收一个闭包；
4. 然后通过DependencyHandler这个类，执行android(Closure configuration)这个闭包并委托给dependencies(Closure configureClosure)，也就是Project对象；
5. 最后Gradle在执行阶段去解析这个Project对象并拿到android{}里面的配置参数，后面就是执行Task等等；

5、总结

我们先是简单介绍了Gradle的配置，以及配置的优先级和初始配置等概念，然后针对我们常用的配置进行了详细的介绍，以及Gradle7.0版本前后的对比，最后通过源码分析介绍了Android核心配置是怎么来的。

源码部分对新手可能有点不太友好，闭包、DSL、Plugin这些概念可能暂时还不太好理解，不过不用担心，后面会继续讲到，先了解下大致流程就行~

写作不易，点个赞吧！

6、Github

https://github.com/yechaoa/GradleX

7、参考文档

• Build Environment
• 彻底弄明白Gradle相关配置
• Configure your build
• build api dsl
• Gradle入门教程
• Gradle的快速入门学习
• Mastering Gradle
• upgrading_version_6
• apply plugin和plugins两种应用gradle插件的区别
• BaseAppModuleExtension