本文内容主要分为以下两个部分：
帮助各位同学初步了解 Gradle、Wrapper
简要介绍 Android Studio 中与 Gradle 相关的文件，它们之间如何协同配合工作以及相关的参数介绍
PS：本人是刚刚起步学习 Android，如有错误之处，烦请大家指正
话不多说，我们正式开始吧
目录
什么是 Gradle
在创建Android 项目时，一般都需要进到这个页面进行配置，我们重点关注一下下面被红框框住的这一行，这是最初与 gradle 相关的配置，其中的重点词汇就是 build、language、Groovy DSL，我们接下来从这三个词汇入手。
Gradle 既是一种工具，也是一种语言（Language），它负责项目的自动化构建（build）
与 C++、Java等通用编程语言（GPL）不同，Gradle 是一种基于 Groovy（一种用于JVM的敏捷开发语言）的特定领域语言（DSL）
通过 gradle，程序员就不需要进行一些复杂的操作，便可以完成项目的编译。
注（小知识）：
GPL（General Purpose Language）：通用编程语言，是指被设计为各种应用领域服务的编程语言。通常通用编程语言不含有为特定应用领域设计的结构。包括 Objective-C、Java、Python 以及 C 语言等等。
DSL（Domain Specific Language）：特定领域语言，是指通过在表达能力上做的妥协换取在某一领域内的高效能力的语言。
什么是 Warpper
定义：wrapper 是 Android Studio 项目中用于管理 Gradle 版本的工具
Gradle 的工作流程
先简单介绍一下这些文件各自的作用：
gradle-wrapper.jar ：核心执行器，负责下载和运行 Gradle。
gradle-wrapper.properties：配置下载的地址和存储位置。
gradlew / gradlew.bat：启动脚本，根据操作系统选择执行方式。
接下来我们来看一下这些文件是如何协同工作的，这里我们以 Ubuntu系统举例
当开发者运行 ./gradlew build时，流程如下：
解析 gradlew 脚本
- 根据其中的 CLASSPATH 去寻找 gradle-wrapper.jar （Wrapper 的实现文件）
CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
- 根据其中的 CLASSPATH 去寻找 gradle-wrapper.jar （Wrapper 的实现文件）
- 读取 gradle-wrapper.properties
系统会去 gradle-wrapper.properties 中对应 zipStorePath 的文件夹去查找对应的 Gradle 版本，如果没有的话，就根据 distributionUrl 给出的链接去下载对应的版本
运行指定的 Gradle 任务
调用 Gradle ：
gradle-wrapper.jar会启动解压后的 Gradle，执行用户输入的命令（如build、assemble）。构建项目 ：Gradle 读取
build.gradle文件，执行依赖解析、编译、打包等操作。
根据以上的信息，可以得出以下结论：
通过指定固定版本的 Gradle ，保证了所有开发者在构建项目时都使用相同的 Gradle 版本，从而减少构建差异。
但也有一些缺点，即不同的项目配置文件中配置的版本不一致的话，在开发环境中就会下载各种各样的gradle版本，会占用硬盘空间。
gradlew 与 gradlew.bat 的区别
| 场景 | Windows（gradlew.bat） | Linux/macOS（gradlew） |
| 运行构建任务 | gradlew.bat build | ./gradlew build |
| 权限要求 | 无需额外权限（直接运行） | 需赋予可执行权限：chmod +x gradlew |
其余的 Gradle 相关文件
build.gradle（项目级）
位于项目的根目录，用于配置整个项目的全局位置参数
常见参数及意义
// 配置 Gradle 插件本身的依赖和仓库。
buildscript {
ext.kotlin_version = '1.8.0' // 定义全局变量供模块级 build.gradle 使用
// 声明依赖库的下载源（如 Google 官方仓库、Maven 中央仓库）。
repositories {
google() // 使用 Google 的 Maven 仓库
mavenCentral() // 使用 Maven Central 仓库
}
// 声明项目构建所需的工具依赖（如 Android Gradle 插件）（到 repositories 里给出的仓库里去寻找并下载）。
dependencies {
classpath 'com.android.tools.build:gradle:x.x.x' // Android Gradle 插件版本
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" // Kotlin 插件
}
}该文件的作用
统一管理多模块共享的配置（如仓库地址、插件版本）。
通过
ext定义全局变量，避免重复配置。
build.gradle（模块级）
位于模块目录下（如
app、library模块），用于配置该模块的构建细节。
常见参数及意义
plugins {
alias(libs.plugins.android.application) // 应用模块插件
alias(libs.plugins.kotlin.android) // Kotlin 插件
alias(libs.plugins.kotlin.compose)
}
android {
namespace 'com.example.myapplication' // 模块的包名（用于代码引用）
compileSdk 36 // 编译时使用的 Android SDK 版本
defaultConfig {
applicationId "com.example.myapplication" // 应用唯一标识（包名）
minSdk 24 // 最低支持的 Android 版本
targetSdk 36 // 目标 SDK 版本
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_11 // 告诉编译器：主代码要使用Java 11的语法和特性
targetCompatibility JavaVersion.VERSION_11 // 生成的字节码也要兼容JVM 11版本
}
kotlinOptions {
// 要求Kotlin编译器生成的代码也要兼容Java 11，避免出现版本错位导致的运行时错误。
jvmTarget = '11'
}
buildFeatures {
// 开启Jetpack Compose的编译支持，令系统处理@Composable注解生成对应的UI代码。
compose true
}
}
dependencies {
/*
implementation 是通用依赖，主程序的必需品，所有变体都能用。
testImplementation 只在运行本地测试时运行。
androidTestImplementation 专门处理运行在真机/模拟器上的测试依赖。
debugImplementation 只在 debug 包生效。
举个例子：当发布 release 版本时，debugImplementation 里的依赖就像隐身衣一样消失不见，
而 testImplementation 的依赖永远不会出现在APK里。
*/
implementation libs .androidx.core.ktx
implementation libs.androidx.lifecycle.runtime.ktx
implementation libs.androidx.activity.compose
implementation platform(libs.androidx.compose.bom)
implementation libs.androidx.ui
implementation libs.androidx.ui.graphics
implementation libs.androidx.ui.tooling.preview
implementation libs.androidx.material3
testImplementation libs.junit
androidTestImplementation libs.androidx.junit
androidTestImplementation libs.androidx.espresso.core
androidTestImplementation platform(libs.androidx.compose.bom)
androidTestImplementation libs.androidx.ui.test.junit4
debugImplementation libs.androidx.ui.tooling
debugImplementation libs.androidx.ui.test.manifest
}小知识：
plugin 参数
Gradle 并不是专门为 Android 服务，所以 Gradle 它本身是不提供对 Android Stduio 的任何构建功能的。但 Gradle 提供了插件机制，这种插件它提供里大量的任务类型、任务、属性等，而开发者只需要在 build.gradle 中使用
alias(插件名)即可引入该插件包含的所有的功能。Google 为了开发 Android 应用定制了一个插件 Android Plugin DSL。所以这一行指定了该构件文件应用的插件，Android 项目的构建都需要使用 libs.plugins.android.application 这个插件。
代码混淆与混淆规则文件
代码混淆：压缩、优化和混淆代码，减少APK体积并保护代码安全。
混淆规则文件：保持某些类不被混淆，自定义配置规则等。
代码混淆就像给代码加密：把类名 A 变成 a、方法名 doSomething 变成 a()，同时移除未使用的代码。这会让反编译后的代码变成天书，保护源码逻辑。
混淆规则文件就像加密指南：proguard-android-optimize.txt 是 Android 官方预设的安全规则，proguard-rules.pro是你的自定义规则。比如用 -keep class com.example.KeepMe 这行规则，就能让 KeepMe 类保持原样不被混淆。
该文件的主要作用
决定模块的构建规则（如生成 APK/AAR）和功能支持（如 Kotlin、Jetpack Compose）。
项目级与模块级 build.gradle 的区别
| 配置项 | 根目录 build.gradle | 模块级 build.gradle |
| 作用范围 | 全局配置，影响整个项目 | 模块私有配置，仅影响当前模块 |
| 主要参数 | buildscript（仓库、插件依赖） | android（模块构建参数）、dependencies（模块依赖） |
| 插件类型 | 仅声明构建工具插件（如 Gradle） | 应用具体插件（如 application、library） |
| 依赖声明 | 项目工具依赖（如 Gradle 插件） | 模块运行时依赖（如第三方库） |
为什么需要多个 build.gradle 文件
模块化管理 ：每个模块（如 app、library）可以独立配置构建参数（如 SDK 版本、依赖库）。例如，app 模块使用 compileSdk 34，而 library 模块使用 compileSdk 33。
复用与共享配置 ：根目录的 build.gradle 统一声明仓库和插件版本等全局参数，避免多模块重复配置。
依赖隔离 ：不同模块可以依赖不同的库版本，避免冲突。
setting.gradle
// 示例
rootProject.name = "My Application"
include ':app'这里面包含了你的子项目，也就是你项目中的 module，假如刚新建好的项目那么就只包含一个 'app' module。如果你新建了其他 module，它也会包含在这里面。
在构建的初始化阶段，settings.gradle 会提供这次构建项目所要包含的哪些 module。
如果你新建一个 'demo' module 的话，这里就会变成
rootProject.name = "My Application" include ':app'，':demo'好啦，有关 Gradle 就先介绍到这里了，大家有任何疑问欢迎在评论区留言
希望大家生活天天开心，代码越写越好，艾薇巴蒂，我们下期再见啦！
