1、前言

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

本文介绍的重点：

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

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

2、Gradle配置简介

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

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

2.1、配置的优先级

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

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

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

Command-line flags：命令行标志，如–stacktrace，这些优先于属性和环境变量；
System properties：系统属性，如systemProp.http.proxyHost=somehost.org存储在gradle.properties文件中；
Gradle properties：Gradle属性，如org.gradle.caching=true，通常存储在项目根目录或GRADLE_USER_HOME环境变量中的gradle.properties文件中；
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 falseid 'com.android.library' version '7.3.0' apply falseid '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 32defaultConfig {applicationId "com.yechaoa.gradlex"minSdk 23targetSdk 32versionCode 1versionName "1.0"testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"}buildTypes {release {minifyEnabled falseproguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'}}compileOptions {sourceCompatibility JavaVersion.VERSION_1_8targetCompatibility 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 30defaultConfig {applicationId "com.yechaoa.app"minSdkVersion 19targetSdkVersion 30versionCode 1versionName "1.0"testInstrumentationRunner 'androidx.test.runner.AndroidJUnitRunner'}buildTypes {release {minifyEnabled falseproguardFiles 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.releaseshrinkResources trueminifyEnabled trueproguardFiles 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 truev2SigningEnabled 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 32defaultConfig {applicationId "com.yechaoa.gradlex"minSdk 23targetSdk 32versionCode 1versionName "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{}的提示：

提炼几个信息：

BaseAppModuleExtension
com.android.build.gradle.internal.dsl
Closure
org.gradle.api.Project

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

然后点进去：

@HasInternalProtocol
public interface Project extends Comparable<Project>, ExtensionAware, PluginAware {.../*** <p>Configures the dependencies for this project.** <p>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.** <h3>Examples:</h3>* 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: DefaultConfigget() = publicExtensionImpl.defaultConfig as DefaultConfigoverride val productFlavors: NamedDomainObjectContainer<ProductFlavor>get() = publicExtensionImpl.productFlavors as NamedDomainObjectContainer<ProductFlavor>override val sourceSets: NamedDomainObjectContainer<AndroidSourceSet>get() = publicExtensionImpl.sourceSetsoverride val composeOptions: ComposeOptions = publicExtensionImpl.composeOptionsoverride val bundle: BundleOptions = publicExtensionImpl.bundle as BundleOptionsoverride val flavorDimensionList: MutableList<String>get() = flavorDimensionsoverride val buildToolsRevision: Revisionget() = 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@Overrideprotected ExtensionData<...> createExtension(...) {// ...if (getProjectServices().getProjectOptions().get(BooleanOption.USE_NEW_DSL_INTERFACES)) {// noinspection unchecked,rawtypes: Hacks to make the parameterized types make senseClass<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配置都是通过插件的方式引入的。

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

通过依赖’com.android.application’插件，有了android{}这个配置DSL；
一个项目对应一个Project对象，Project对象里面包含dependencies函数；
android{}这个配置DSL点进去就是Project对象里面dependencies这个函数，二者都接收一个闭包；
然后通过DependencyHandler这个类，执行android(Closure configuration)这个闭包并委托给dependencies(Closure configureClosure)，也就是Project对象；
最后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

【Gradle-2】一文搞懂Gradle配置相关推荐

一文搞懂AWS EC2, IGW, RT, NAT, SG 基础篇下
B站实操视频更新跟着拉面学习AWS--EC2, IGW, RT, NAT, SG 简介长文多图预警,看结论可以直接拖到"总结"部分本文承接上一篇文章介绍以下 AWS 基础概念 ...
一文搞懂 Traefik2.1 的使用
原文链接:一文搞懂 Traefik2.1 的使用一文搞懂 Traefik2.1 的使用核心概念安装 ACME 中间件灰度发布流量复制 TCP 简单 TCP 服务带 TLS 证书的 TCP ...
一文搞懂UART通信协议
目录 1.UART简介 2.UART特性 3.UART协议帧 3.1.起始位 3.2.数据位 3.3.奇偶校验位 3.4.停止位 4.UART通信步骤 1.UART简介 UART(Universal ...
一文搞懂什么是 PostCSS
一文搞懂什么是 PostCSS 在 Web 应用开发中,CSS 代码的编写是重要的一部分.CSS 规范从最初的 CSS1 到现在的 CSS3,再到 CSS 规范的下一步版本,规范本身一直在不断的发展演 ...
网络知识扫盲，一文搞懂 DNS
在找工作面试的过程中,面试官非常喜欢考察基础知识,除了数据结构与算法之外,网络知识也是一个非常重要的考察对象. 而网络知识,通常是很抽象,不容易理解的,有很多同学就在这里裁了跟头.为了更好地通过面试, ...
【显卡】一文搞懂显卡
[显卡]一文搞懂显卡文章目录 [显卡]一文搞懂显卡 1. 前言介绍 1.1 CPU和显卡的区别 1.1.1 作用不同 1.1.2 结构不同 1.1.3 应用场景不同 1.2 三个著名的显卡公司 2. ...
一文搞懂MySQL数据库分库分表
如果数据量过大,大家一般会分库分表.分库需要注意的内容比较少,但分表需要注意的内容就多了. 工作这几年没遇过数据量特别大的业务,那些过亿的数据,因为索引设置合理,单表性能没有影响,所以实战中一直没用过 ...
一文搞懂什么VR，什么是6Dof，欧拉角，四元数转视图矩阵
目录一.什么是VR 二.什么是3Dof,6Dof, 9Dof 三.欧拉角(姿态角) 四.Android手机的欧拉角与坐标系五.安卓坐标系转换欧拉角六.根据姿态四元数求视图矩阵一文搞懂什么VR, ...
一文搞懂Elasticsearch索引的mapping与setting
目录 Elasticsearch索引结构 Mapping Setting Elasticsearch索引结构一个Elasticsearch索引的主要结构如下: {"test_index&q ...

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

1、前言

2、Gradle配置简介

2.1、配置的优先级

2.2、项目初始配置

3、Gradle配置

3.1、gradle-wrapper

3.2、build.gradle（Project）

3.2.1、7.0之后

3.2.1、7.0之前

buildscript

ext

repositories

dependencies

allprojects

task clean(type: Delete)

3.3、build.gradle（Module）

3.2.1、7.0之后

3.3.1、7.0之前

plugins/apply plugin

namespace

com.android.application

android{}

compileSdkVersion/compileSdk

buildToolsVersion

defaultConfig{}

applicationId

minSdkVersion/minSdk

targetSdkVersion/targetSdk

versionCode

versionName

multiDexEnabled

ndk{}

sourceSets

buildTypes

signingConfigs

productFlavors

buildConfigField

Build Variants

buildFeatures

dexOptions{}

compileOptions

kotlinOptions

composeOptions

lintOptions

dependencies{}

implementation和api的区别

3.4、settings.gradle

pluginManagement

dependencyResolutionManagement

rootProject.name

include

3.5、gradle.properties

Gradle本身配置

版本管理

3.6、local.properties

本地配置

环境管理

4、Gradle配置怎么来的

5、总结

6、Github

7、参考文档

【Gradle-2】一文搞懂Gradle配置相关推荐

最新文章

热门文章