Gradle系列——依赖管理与插件机制

今天，我们要聚焦构建过程中的两大关键 “角色”： 依赖管理 和 插件机制。

如果说 Gradle 生命周期和 Task 执行图是构建流程的 “骨架”，那么 依赖管理 就是构建的 “物料保障”，它负责引入和管理项目所需的各种外部库和资源，确保构建 “巧妇有米”。而 插件机制 则是 Gradle 的 “扩展引擎”，它赋予 Gradle 无限的扩展能力，让我们可以根据项目需求定制各种构建功能，真正实现 “量身定制”。

理解依赖管理和插件机制，就像掌握了构建的 “粮仓” 和 “动力源泉”，能让你更有效地管理项目依赖，灵活扩展构建功能，从而构建出更健壮、更高效的 Android 应用。

依赖管理 (Dependency Management) 深度解析：构建的 “物料保障”

在 Android 开发中，我们几乎不可能从零开始构建一切。我们通常会依赖各种第三方库 (例如 Retrofit, RxJava, Glide 等) 来加速开发，提高效率。 Gradle 的依赖管理系统 就是负责管理这些外部依赖的 “物料管理员”。

依赖解析 (Dependency Resolution) 过程：Gradle 如何找到你的 “物料”

当我们声明一个依赖 (例如 implementation 'androidx.appcompat:appcompat:1.6.1') 时，Gradle 并不会 “魔法” 般地直接拿到这个库。它需要经历一个 依赖解析 (Dependency Resolution) 的过程，才能找到并下载我们需要的 “物料”。这个过程大致可以分为以下几个步骤：

依赖解析步骤：

构建依赖图 (Dependency Graph Construction): 在 配置阶段，Gradle 会根据 dependencies {} 代码块中的声明，构建一个 依赖图 (Dependency Graph)。这个图描述了项目模块之间的依赖关系，以及模块对外部库的依赖关系。 Gradle 会分析所有模块的 build.gradle 文件，将依赖信息收集起来，形成一个完整的依赖关系网络。

依赖查找 (Dependency Lookup): 对于每个声明的外部依赖，Gradle 会根据配置的 仓库 (Repositories) 列表，依次查找该依赖。仓库列表在 settings.gradle (或模块级别的 build.gradle，但不推荐) 的 dependencyResolutionManagement { repositories { ... } } 代码块中配置。常用的仓库包括：

google(): Google Maven 仓库，包含了 Android SDK 相关的库，以及一些 Google 官方库。

mavenCentral(): Maven 中央仓库，是最大的 Maven 仓库，包含了大量的 Java 和 Android 开源库。

gradlePluginPortal(): Gradle 插件仓库，专门用于查找 Gradle 插件。

maven { url '仓库地址' }: 自定义 Maven 仓库，可以指向公司内部的 Maven 私服，或者其他的第三方 Maven 仓库。

flatDir { dirs 'libs' }: 本地仓库，指向项目 libs 目录，用于存放本地的 JAR 或 AAR 文件。

Gradle 会按照仓库列表的顺序，逐个仓库查找依赖库。一旦在某个仓库找到，就会停止查找，并进入下一步。

依赖下载 (Dependency Download): 在 执行阶段 (当需要用到这些依赖的任务执行时)，Gradle 会从找到依赖的仓库下载依赖库文件 (通常是 JAR 或 AAR 文件) 到本地缓存。 Gradle 有一套高效的缓存机制，已经下载过的依赖库会被缓存起来，下次构建时如果版本没有变化，则会直接使用缓存，避免重复下载，加快构建速度。

依赖传递 (Transitive Dependencies): 依赖库本身也可能依赖其他的库。Gradle 会自动处理 传递依赖 (Transitive Dependencies)，即下载依赖库所依赖的库。例如，如果你依赖了 Retrofit，Retrofit 又依赖了 OkHttp 和 Converter-Gson，那么 Gradle 会自动下载 OkHttp 和 Converter-Gson。这大大简化了依赖管理，我们只需要声明直接依赖，Gradle 会帮我们处理所有的间接依赖。

代码示例:

settings.gradle.kts - 配置依赖仓库：

小结:

理解 Gradle 依赖解析过程，有助于你排查依赖相关的问题，例如依赖找不到、下载失败等。

合理配置 repositories {} 代码块，确保 Gradle 能找到你需要的依赖库。 推荐在 settings.gradle 中统一配置仓库，并使用 repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) 强制模块级别不定义仓库，保持仓库配置的统一性。

Gradle 的依赖缓存机制非常高效，可以显著加快构建速度。但有时候缓存也可能导致问题，例如依赖版本更新后，Gradle 可能仍然使用旧的缓存版本。这时可以尝试清理 Gradle 缓存 (gradlew --refresh-dependencies 或删除 ~/.gradle/caches 目录) 来解决。

依赖冲突 (Dependency Conflicts) 的产生与解决：当 “物料” 版本不一致时

在复杂的 Android 项目中，尤其是多模块项目，很容易遇到 依赖冲突 (Dependency Conflicts) 的问题。依赖冲突通常发生在以下场景：

直接依赖和传递依赖版本不一致: 你直接依赖了一个库 A 的 1.0 版本，而另一个你依赖的库 B 的传递依赖也包含了库 A，但可能是 1.1 版本。Gradle 需要决定使用哪个版本。

多个传递依赖版本不一致: 多个你直接依赖的库，都传递依赖了同一个库 C，但版本不一致。

💡

Gradle 默认的依赖冲突解决策略是 “最近版本优先 (Newest version wins)”。也就是说，Gradle 会选择所有冲突版本中版本号最高的版本。大多数情况下，这个策略都能解决问题。

示例：

假设你的项目依赖了库 A 和库 B，它们都传递依赖了库 C，但是版本不同：

你的项目 -> 库 A -> 库 C (版本 1.0)

你的项目 -> 库 B -> 库 C (版本 1.2)

Gradle 会默认选择库 C 的 1.2 版本。

但是，“最近版本优先” 策略并非万能，有时候可能会导致运行时问题，例如：

API 不兼容: 高版本库 C 的 API 可能与低版本库 C 的 API 不兼容，导致编译或运行时错误。

功能缺失或行为改变: 高版本库 C 可能移除了某些功能，或者改变了某些行为，导致应用功能异常。

高级依赖冲突策略：

当 “最近版本优先” 策略无法解决依赖冲突时，我们需要使用更高级的依赖冲突解决策略：

强制版本 (Force versions): 使用 resolutionStrategy.force(...) 强制 Gradle 使用指定的依赖版本。这会覆盖 Gradle 默认的 “最近版本优先” 策略，强制使用你指定的版本。

使用场景: 当你明确知道某个依赖的特定版本是稳定且兼容的，而 Gradle 默认选择的版本可能存在问题时，可以使用强制版本。

但要谨慎使用，过度使用强制版本可能会隐藏潜在的依赖问题。

组件选择规则 (Component Selection Rules): 使用 resolutionStrategy.componentSelection { ... } 定义组件选择规则，可以更精细地控制 Gradle 如何选择依赖版本。例如，你可以指定只接受 release 版本的库，拒绝 beta 或 alpha 版本。

使用场景: 当你需要根据更复杂的条件 (例如版本号、发布状态、模块信息等) 来选择依赖版本时，可以使用组件选择规则。

组件替换规则 (Component Substitution Rules): 使用 resolutionStrategy.componentSubstitution { ... } 定义组件替换规则，可以将一个依赖替换为另一个依赖。例如，你可以将一个远程仓库依赖替换为本地的模块依赖，方便本地开发和调试。

使用场景: 当你需要将一个依赖替换为另一个依赖时，可以使用组件替换规则。例如，在本地开发环境下，将远程依赖替换为本地模块，方便调试和修改。

Dependency Constraints (依赖约束): Gradle 5.3+ 引入的 依赖约束 (Dependency Constraints) 机制，提供了一种更细粒度、更可靠的方式来管理依赖版本。你可以在 dependencyConstraints {} 代码块中声明依赖约束，强制指定某个依赖的版本范围或特定版本。依赖约束比强制版本更灵活，可以定义更复杂的版本规则。

使用场景: 当你需要对依赖版本进行更严格的控制，例如强制使用特定版本，或者指定版本范围时，可以使用依赖约束。

推荐使用依赖约束来管理关键依赖的版本，提高依赖管理的可靠性。

小结:

依赖冲突是复杂项目中常见的问题，理解依赖冲突的产生原因和解决策略非常重要。

优先使用 Gradle 默认的 “最近版本优先” 策略。 大多数情况下，这个策略都能解决问题。

当 “最近版本优先” 策略无法解决问题时，再考虑使用高级的依赖冲突解决策略，例如强制版本、组件选择规则、组件替换规则、依赖约束。

谨慎使用强制版本，过度使用可能会隐藏潜在的依赖问题。 推荐使用依赖约束来管理关键依赖的版本，提高依赖管理的可靠性。

使用 Gradle Build Scan 可以方便地分析依赖树，定位依赖冲突，并查看 Gradle 选择的依赖版本。 Build Scan 是解决依赖问题的利器。

依赖优化的最佳实践：让你的 “物料仓库” 更高效

合理的依赖管理不仅能保证构建的正确性，还能提升构建效率，减小 APK 大小，甚至影响应用的性能。下面是一些依赖优化的最佳实践：

最佳实践——减少不必要的依赖，精简依赖树:

仔细检查依赖声明，移除项目中没有实际使用的依赖库。可以使用工具 (例如 ProGuard/R8 的依赖分析功能，或者一些第三方依赖分析工具) 来分析项目依赖，找出未使用的依赖。

精简依赖树可以减小 APK 大小，加快构建速度，并减少潜在的依赖冲突。

最佳实践——统一依赖版本管理，避免版本冲突:

在多模块项目中，尽量统一各个模块使用的依赖版本。可以使用 Gradle 的 版本目录 (Version Catalogs) (Gradle 7.0+ 引入的新特性) 来集中管理依赖版本，提高依赖管理的可维护性和一致性。 统一依赖版本可以减少依赖冲突，简化依赖管理，并提高构建的可维护性。

示例 (libs.versions.toml - 版本目录配置文件):

在 build.gradle.kts 中使用版本目录:

最佳实践——使用 Dependency Constraints 管理依赖版本，提高依赖管理的可靠性:

对于关键依赖，使用依赖约束 (Dependency Constraints) 强制指定版本或版本范围，避免意外的版本升级或降级导致的问题。 使用依赖约束可以提高依赖管理的可靠性和稳定性。

最佳实践——利用 Dependency Substitution (依赖替换) 进行本地开发和调试:

在本地开发环境下，可以使用组件替换规则 (Component Substitution Rules) 将远程依赖替换为本地模块，方便本地修改和调试依赖库的代码。

Dependency Substitution 可以提高本地开发效率，方便调试依赖问题。

最佳实践——优化依赖下载速度:

如果项目依赖很多，或者网络环境较差，可以考虑优化依赖下载速度：

使用国内 Maven 镜像: 例如阿里云 Maven 镜像，可以加速 Maven 中央仓库的下载速度。

配置 Gradle Enterprise Build Cache (远程 Build Cache): 如果团队内部使用了 Gradle Enterprise，可以使用远程 Build Cache 来缓存依赖库，实现团队成员之间共享依赖缓存，避免重复下载。

配置 CDN 缓存加速: 一些 CDN 服务提供 Maven 仓库加速功能，可以利用 CDN 缓存加速依赖下载。

小结:

合理的依赖管理是构建优化的重要组成部分。

精简依赖树、统一依赖版本、使用依赖约束、优化依赖下载速度，都是提升依赖管理效率和构建性能的有效方法。

Gradle 版本目录 (Version Catalogs) 是管理依赖版本的利器，推荐在大型项目中使用。

Gradle Build Scan 是分析依赖问题和优化依赖管理的强大工具，强烈推荐使用。

插件机制 (Plugin Mechanisms) 深度解析：构建能力的 “扩展引擎”

Gradle 的强大之处不仅在于其优秀的依赖管理系统，还在于其 插件机制 (Plugin Mechanisms)。插件就像 Gradle 的 “扩展引擎”，它可以为 Gradle 添加各种新的功能和特性，让 Gradle 可以胜任各种复杂的构建任务。Android Gradle Plugin (AGP) 就是一个典型的例子，它为 Gradle 注入了 Android 特性构建的能力。

Gradle 插件的类型与机制：Gradle 如何 “变身”

Gradle 插件本质上是一些 代码模块，它们可以扩展 Gradle 的功能，定制构建流程。 Gradle 插件主要分为两种类型：

两种插件类型：

二进制插件 (Binary Plugins): 用 Java 或 Kotlin 等 JVM 语言编写的插件，编译成 JAR 文件发布。 Android Gradle Plugin (AGP) 就是一个二进制插件。 二进制插件功能强大，性能高，但开发和发布相对复杂。

脚本插件 (Script Plugins): 用 Groovy 或 Kotlin DSL 编写的插件，以 .gradle 或 .gradle.kts 脚本文件形式存在。脚本插件开发简单，易于使用，但功能和性能相对有限。 你可以在项目内部创建和使用脚本插件，用于封装一些通用的构建逻辑。

两种插件应用方式：

Gradle 插件的应用方式主要有两种：

使用 plugins {} 代码块 (推荐): 在 build.gradle 或 settings.gradle 文件中使用 plugins {} 代码块声明和应用插件。这是 Gradle 官方推荐的插件应用方式，简洁、类型安全 (Kotlin DSL)。

使用 apply plugin: '插件 ID' (旧语法，不推荐): 在 build.gradle 文件中使用 apply plugin: '插件 ID' 语句应用插件。这是 Gradle 早期版本的插件应用方式，语法相对繁琐，类型不安全 (Kotlin DSL)。不推荐在新项目中使用这种方式。

插件来源：

Gradle 插件的来源主要有以下几种：

Gradle 插件门户 (Gradle Plugin Portal): Gradle 官方提供的插件仓库，包含了大量的开源 Gradle 插件。可以通过插件的 ID 在 plugins {} 代码块中直接引用 Gradle 插件门户中的插件。

Maven 仓库: 一些插件也发布在 Maven 仓库中。需要先在 settings.gradle 的 pluginManagement { repositories { ... } } 代码块中配置插件仓库，然后在 plugins {} 代码块中引用 Maven 仓库中的插件。

本地文件: 可以将脚本插件 (.gradle 或 .gradle.kts 文件) 放在项目本地，然后使用 apply from: '脚本插件文件路径' 语句应用本地脚本插件。

小结:

Gradle 插件是扩展 Gradle 构建能力的关键机制。理解插件的类型和应用方式，可以帮助你更好地利用 Gradle 插件，定制构建流程。

推荐使用 plugins {} 代码块应用插件，这是 Gradle 官方推荐的方式，简洁且类型安全 (Kotlin DSL)。

Gradle 插件主要来源于 Gradle 插件门户、Maven 仓库和本地文件。你需要根据插件的来源配置插件仓库或指定插件文件路径。

Android Gradle Plugin (AGP) 是 Android 构建的核心插件，它为 Gradle 注入了 Android 特性构建的能力。 后续我们会更深入地探讨 AGP。

插件对构建流程的影响：Gradle 如何 “百变”

Gradle 插件之所以强大，是因为它可以 深度定制和扩展 Gradle 构建流程的各个方面。插件主要通过以下方式影响构建流程：

插件原理之扩展 Project 对象（Extensions）

插件可以为 Project 对象添加新的 扩展 (Extensions)，这些扩展就像是 Project 对象的新属性，用于配置插件的行为。例如，Android Gradle Plugin (AGP) 就为 Project 对象添加了 android {} 扩展，用于配置 Android 构建相关的参数 (例如 compileSdk, buildTypes, dependencies 等)。

代码示例 (Module-level build.gradle.kts - 使用 android {} 扩展配置 Android 构建):

插件原理之添加Task，扩展任务

插件可以向 Project 对象添加新的 Task，扩展构建任务。例如，Android Gradle Plugin (AGP) 就添加了 compileDebugKotlin, assembleRelease, installDebug, testDebugUnitTest 等大量的 Task，用于执行 Android 构建的各个环节 (例如编译代码、打包 APK、运行测试等)。

场景示例: 当应用了 com.android.application 插件后，就可以在 Android Studio 的 Gradle 面板中看到大量的 Android 构建相关的 Task，例如 assembleDebug, assembleRelease, installDebug, uninstallAll, connectedAndroidTest, testDebugUnitTest 等。这些 Task 都是由 Android Gradle Plugin 插件添加的。

插件原理之添加约定 (Conventions)：定制构建行为

插件可以为 Gradle 构建添加新的 约定 (Conventions)，定制构建行为。例如，Android Gradle Plugin (AGP) 就约定了 Android 项目的默认目录结构 (src/main/java, src/main/res 等)，默认的构建产物目录 (build/outputs) 等。这些约定简化了 Android 构建的配置，让开发者可以更专注于业务逻辑，而不是构建细节。

小结：

总结来说，Gradle 插件就像是 Gradle 的 “百变魔盒”，它可以：

为 Gradle 添加新的配置选项 (通过扩展 Project 对象)

为 Gradle 添加新的构建任务 (通过添加 Task)

为 Gradle 定制构建行为 (通过添加约定)

正是插件机制，让 Gradle 变得如此强大和灵活，可以适应各种不同的构建需求。

自定义 Gradle 插件开发入门：打造你的专属 “构建工具” (非常简化)

如果想要更深入地定制 Gradle 构建流程，或者封装一些通用的构建逻辑，开发自定义 Gradle 插件 是一个非常强大的选择。虽然自定义插件开发相对高级，但入门其实并不难。这里我们做一个非常简单的入门介绍，让你对自定义插件开发有一个初步的了解。

自定义插件类型

自定义 Gradle 插件的类型 (再次强调):

二进制插件 (Binary Plugins): 用 Java 或 Kotlin 等 JVM 语言编写，功能强大，性能高，但开发和发布相对复杂。

脚本插件 (Script Plugins): 用 Groovy 或 Kotlin DSL 编写，开发简单，易于使用，但功能和性能相对有限。 对于简单的自定义插件，脚本插件通常就足够了。

这里我们以开发一个简单的 Groovy 脚本插件为例，演示如何创建一个自定义 Task，并将其添加到 Gradle 构建中。

步骤 1：创建脚本插件文件 (`my-script-plugin.gradle`)

在项目根目录创建一个名为 my-script-plugin.gradle 的文件，写入以下 Groovy 代码：

代码解释:

project.extensions.create("greeting", GreetingPluginExtension): 向 Project 对象添加一个名为 greeting 的扩展，类型为 GreetingPluginExtension。这样我们就可以在 build.gradle 中通过 greeting {} 代码块配置这个扩展。

tasks.register("hello") { ... }: 注册一个名为 hello 的 Task，并设置 Task 的分组和描述。

doLast { ... }: 定义 Task 的执行逻辑，这里只是简单地打印 project.greeting.greetingMessage 属性的值。

class GreetingPluginExtension { ... }: 定义扩展类 GreetingPluginExtension，包含一个 greetingMessage 属性，用于配置 greeting 消息。

步骤 2：在 `build.gradle` 中应用脚本插件并配置扩展

在 Module-level app/build.gradle 文件中应用脚本插件，并配置 greeting 扩展：