Android Gradle 简介

Gradle

Android 面试中关于 Gradle 的内容，通常会围绕以下几个核心方面：

Gradle 基础知识

是什么？ 理解 Gradle 是一个构建自动化工具，用于管理项目依赖、编译、打包和测试等任务。
为什么 Android 选择 Gradle？ 了解其灵活性 （基于 Groovy/Kotlin DSL）、可扩展性 （插件化）、性能（增量构建、构建缓存）等优势。
Groovy 与 Kotlin DSL： 了解两者在 Gradle 脚本编写中的区别和优缺点。面试官可能会问你更熟悉哪一种，或者特定场景下哪种更合适。

Gradle 构建脚本

settings.gradle(.kts)： 知道它的作用是管理多模块项目，声明哪些子项目需要被构建。
build.gradle(.kts) (Project-level)： 理解它用于配置整个项目的通用属性，例如 Gradle 插件版本、仓库地址等。
build.gradle(.kts) (Module-level)： 这是重点！面试官会重点考察你对模块级构建脚本的理解：
- plugins { ... }： 如何应用和管理 Gradle 插件 (例如 com.android.application, com.android.library, kotlin-android)。
- android { ... }： 这是 Android 项目的核心配置块，包含：
  - compileSdk, minSdk, targetSdk, versionCode, versionName：理解它们的含义和作用。
  - buildTypes { ... }：如何配置不同的构建类型 (例如 debug, release)，包括混淆 (ProGuard/R8)、签名配置、BuildConfig 字段等。
  - productFlavors { ... }：如何配置不同的产品渠道或版本，实现代码和资源的多样化。
  - dependencies { ... }：如何声明和管理项目依赖 (例如 implementation, api, testImplementation, androidTestImplementation)，理解不同依赖配置的区别。
  - defaultConfig { ... }：默认配置。
  - sourceSets { ... }：如何配置不同的源码和资源目录。
gradle.properties： 了解如何在这里定义项目范围的常量和配置，例如 JVM 参数、插件版本等。
local.properties： 通常用于存放本地环境相关的配置，例如 SDK 路径，一般不提交到版本控制。

Gradle 任务 (Tasks)

理解 Gradle 的核心是任务。构建过程就是一系列任务的执行。
知道如何查看项目中的所有任务 (例如 ./gradlew tasks)。
知道如何执行特定的任务 (例如 ./gradlew assembleDebug)。
了解一些常用任务 ：assemble, build, clean, install, test, lint 等。
可能会问到如何自定义任务 ，或者任务之间的依赖关系。

依赖管理

不同类型的依赖： 本地依赖 (JARs, AARs)、远程依赖 (Maven Central, Google's Maven repository, JCenter - 虽然已弃用但可能还会提及)。
依赖冲突： 理解什么是依赖冲突，以及如何通过 Gradle 的机制 (例如 exclude, force) 来解决。
传递性依赖： 了解一个库可能依赖其他库，以及 Gradle 如何处理这些传递性依赖。
BOM (Bill of Materials)： 了解 BOM 的作用，以及如何简化多模块项目中库版本的管理。

构建优化与提速

Gradle Daemon： 了解它的作用是后台运行，避免每次构建都重新初始化 Gradle 环境，从而加快构建速度。
构建缓存 (Build Cache)： 理解本地构建缓存和远程构建缓存如何通过复用之前任务的输出来加速构建。
并行构建 (Parallel Execution)： 知道如何配置 Gradle 以并行执行独立的任务。
增量构建 (Incremental Build)： 理解 Gradle 如何只重新构建发生变化的部分。
配置按需 (Configuration on Demand)： 了解这个特性如何只配置参与当前构建任务的项目，从而在大型多模块项目中提升配置阶段的速度。
分析构建性能： 了解如何使用 --scan 或 Gradle Profiler 来分析构建瓶颈。

多模块项目

理解在 Android 中为什么要使用多模块架构 (例如解耦、复用、加快构建速度等)。
知道如何在 settings.gradle(.kts) 中声明模块。
理解不同模块类型 (例如 Application 模块, Library 模块, Feature 模块)。
模块间的依赖关系如何配置。

自定义 Gradle 插件

对于高级职位，可能会问到是否编写过自定义 Gradle 插件，或者如何编写。
理解插件的作用和生命周期。

常见问题与排错

面试官可能会描述一个常见的 Gradle 构建错误，问你如何分析和解决。
例如：依赖下载失败、版本冲突、签名问题、资源找不到等。

总结来说，面试官希望了解你是否具备以下能力：

理解 Gradle 的核心概念和工作原理。
熟练阅读和编写 Gradle 构建脚本。
能够有效地管理项目依赖。
知道如何优化和提升构建速度。
具备解决常见 Gradle 构建问题的能力。

准备面试时，除了理论知识，最好能结合实际项目经验来回答问题，展示你解决实际问题的能力。熟悉 Android Studio 中的 Gradle 相关操作界面也会有所帮助。

BOM 的作用 - 如何简化多模块项目中库版本的管理

什么是 BOM (Bill of Materials)？

你可以将 BOM 理解为一个**"推荐依赖版本清单"或者"版本协调中心"**。

想象一下，你有一个大型项目，里面用到了很多来自同一个技术栈或同一个系列的不同库（例如 Firebase 系列、Spring Boot 系列、OkHttp 系列等）。这些库之间通常会有兼容性要求，即特定版本的库 A 可能需要与特定版本的库 B 协同工作才能保证稳定性和正确性。

BOM 就是这样一个特殊类型的依赖，它本身不包含任何代码，而是声明了一组相关库的推荐版本 。当你引入一个 BOM 后，你就可以在你的项目中声明这些库的依赖，而无需显式指定它们的版本号。Gradle 会自动从 BOM 中查找并使用推荐的版本。

核心作用：

集中管理版本： 将一组相关库的版本号集中在一个地方进行管理。
保证兼容性： BOM 的发布者通常会确保其声明的库版本之间是相互兼容的。
简化依赖声明： 在子模块中引入库时，无需重复指定版本号。

BOM 如何简化多模块项目中库版本的管理？

在 Android 的多模块项目中，BOM 的优势尤为明显，因为不同模块可能会共享许多相同的依赖。

没有 BOM 的情况（痛点）：

假设你的项目有多个模块（app, feature_A, feature_B, core_library），并且它们都用到了 OkHttp 的几个组件：okhttp, logging-interceptor。

版本不一致风险：
- 你可能在 app 模块的 build.gradle 中写：
  
  Gradle
  arduino 复制代码
```
implementation 'com.squareup.okhttp3:okhttp:4.9.1'
implementation 'com.squareup.okhttp3:logging-interceptor:4.9.1'
```
- 在 feature_A 模块的 build.gradle 中，你可能不小心写了：
  
  Gradle
  arduino 复制代码
```
implementation 'com.squareup.okhttp3:okhttp:4.9.0' // 版本不一致！
implementation 'com.squareup.okhttp3:logging-interceptor:4.9.0'
```
- 这种不一致很容易导致难以排查的运行时错误或编译冲突。
升级困难：
- 当 OkHttp 发布新版本（例如 4.10.0）时，你需要手动去每一个 使用了这些库的模块的 build.gradle 文件中修改版本号。这非常繁琐且容易出错，尤其是在模块众多的情况下。
难以保证兼容性：
- 如果你只升级了 okhttp 而忘记升级 logging-interceptor，可能会因为版本不匹配导致问题。

使用 BOM 的情况（优势）：

现在，假设 OkHttp 提供了一个 BOM：com.squareup.okhttp3:okhttp-bom:4.9.3。

在根项目的 build.gradle(.kts) (或者一个统一管理依赖的 dependencies.gradle 文件) 中引入 BOM：

在 dependencies 代码块中，使用 platform (对于 Java/Kotlin 平台) 或 enforcedPlatform (如果需要强制使用 BOM 中的版本，覆盖传递依赖中的版本) 来引入 BOM。

Gradle

java 复制代码

// Groovy DSL (build.gradle)
dependencies {
    // 引入 OkHttp BOM
    implementation platform('com.squareup.okhttp3:okhttp-bom:4.9.3')

    // 现在可以不指定版本号引入 OkHttp 的其他库
    implementation 'com.squareup.okhttp3:okhttp'
    implementation 'com.squareup.okhttp3:logging-interceptor'

    // ... 其他依赖
}

Kotlin

scss 复制代码

// Kotlin DSL (build.gradle.kts)
dependencies {
    // 引入 OkHttp BOM
    implementation(platform("com.squareup.okhttp3:okhttp-bom:4.9.3"))

    // 现在可以不指定版本号引入 OkHttp 的其他库
    implementation("com.squareup.okhttp3:okhttp")
    implementation("com.squareup.okhttp3:logging-interceptor")

    // ... 其他依赖
}

注意: 通常更推荐的做法是在根 build.gradle(.kts) 文件中仅声明 BOM 本身，然后在各个子模块中声明具体的库依赖（不带版本号）。这样结构更清晰。

更推荐的方式：

根 build.gradle(.kts):

Gradle

java 复制代码

// Groovy DSL
dependencies {
    implementation platform('com.squareup.okhttp3:okhttp-bom:4.9.3')
    // 或者在 allprojects 或 subprojects 中统一配置 platform
}

Kotlin

less 复制代码

// Kotlin DSL
dependencies {
    implementation(platform("com.squareup.okhttp3:okhttp-bom:4.9.3"))
}

子模块 app/build.gradle(.kts), feature_A/build.gradle(.kts) 等:

Gradle

arduino 复制代码

// Groovy DSL
dependencies {
    implementation 'com.squareup.okhttp3:okhttp' // 版本由 BOM 控制
    implementation 'com.squareup.okhttp3:logging-interceptor' // 版本由 BOM 控制
    // ... 其他模块特有的依赖
}

Kotlin

scss 复制代码

// Kotlin DSL
dependencies {
    implementation("com.squareup.okhttp3:okhttp") // 版本由 BOM 控制
    implementation("com.squareup.okhttp3:logging-interceptor") // 版本由 BOM 控制
    // ... 其他模块特有的依赖
}

带来的好处：
- 版本统一： 所有模块中声明的 com.squareup.okhttp3:okhttp 和 com.squareup.okhttp3:logging-interceptor (以及 BOM 中定义的其他 OkHttp 相关库) 都会自动使用 BOM 中指定的版本 (在这个例子中是 4.9.3 对应的版本)。你无需在每个子模块中重复写版本号，从根本上避免了版本不一致的问题。
- 升级便捷： 当你想升级 OkHttp 系列库时，你只需要在根项目的 build.gradle(.kts) 中修改 BOM 的版本号 。例如，将 platform('com.squareup.okhttp3:okhttp-bom:4.9.3') 修改为 platform('com.squareup.okhttp3:okhttp-bom:4.10.0')。所有依赖该 BOM 的库版本都会自动更新，大大简化了升级过程。
- 保证兼容性： BOM 的发布者（例如 Square 对于 OkHttp BOM）会确保 BOM 中列出的所有库版本是相互测试过并且兼容的。这降低了因版本不匹配引入问题的风险。
- 更清晰的依赖声明： 子模块的 build.gradle 文件看起来更干净，因为它只关注需要哪些库，而不必操心具体的版本号（除非你想覆盖 BOM 中的版本，但不推荐）。

platform vs enforcedPlatform：

platform(...): 这是推荐的用法。它会导入 BOM 中的版本信息，但如果项目中的其他传递依赖引入了更高版本的同一个库，Gradle 默认会选择更高版本（依赖调解策略）。
enforcedPlatform(...): 这种方式会强制使用 BOM 中定义的版本，即使其他传递依赖引入了更高版本，也会被 BOM 的版本覆盖。当你希望严格控制某一组库的版本，确保它们完全符合 BOM 的规定时，可以使用它。

总结一下 BOM 在多模块项目中的简化作用：

单一版本控制点： 只需在一个地方（通常是根项目）更新 BOM 的版本，所有相关库的版本就会在整个项目中同步更新。
消除版本冲突： 通过统一管理，减少了不同模块间因手动指定不同版本而导致的冲突。
提升可维护性： 依赖管理更加清晰和简单，尤其对于大型复杂项目。
依赖于官方推荐： 使用官方发布的 BOM 可以确保你使用的库组合是经过测试和推荐的，减少了兼容性问题。

因此，在多模块 Android 项目中，对于那些提供 BOM 的库集合（如 Firebase、OkHttp、Kotlin Coroutines、Compose 等），强烈建议使用 BOM 来管理它们的版本。这是一种现代且高效的依赖管理方式。

Gradle如何自定义任务，或者任务之间的依赖关系

Gradle 如何自定义任务

Gradle 中的一切行为都围绕着任务 (Task) 进行。你可以创建全新的自定义任务来执行任何你想要的操作，比如复制文件、执行脚本、打包特定资源、生成代码等等。

有几种主要的方式来定义一个自定义任务：

1. 使用 task 关键字 (简单任务 - Groovy DSL)

这是最基本的方式，可以直接在 build.gradle 文件中定义。

Groovy

arduino 复制代码

// build.gradle (Groovy DSL)

task mySimpleTask { // 任务名 mySimpleTask
    // 配置阶段的代码 (Task Configuration)
    group = "My Custom Tasks" // 给任务分组，方便在 ./gradlew tasks 中查看
    description = "This is a simple custom task."

    // 执行阶段的代码 (Task Action)
    doLast {
        println 'Executing mySimpleTask!'
        // 在这里执行任务的具体操作
        // 例如：println "Current project: ${project.name}"
    }

    doFirst {
        println 'Preparing to execute mySimpleTask...'
    }
}

2. 使用 tasks.register (推荐方式 - Groovy & Kotlin DSL)

这种方式更推荐，因为它利用了 Gradle 的配置避免 (Configuration Avoidance) API。这意味着任务的配置代码只会在任务实际需要执行时才会被执行，从而提升构建性能，尤其是在大型项目中。

Groovy DSL (build.gradle)

Groovy

dart 复制代码

tasks.register('myRegisteredTask') {
    group = "My Custom Tasks"
    description = "A task registered using tasks.register."

    doLast {
        println "Executing myRegisteredTask!"
        // 实际操作
        def newFile = new File("$buildDir/myOutput.txt")
        newFile.text = "Hello from myRegisteredTask on ${new Date()}"
        println "Created file: ${newFile.absolutePath}"
    }
}

Kotlin DSL (build.gradle.kts)

Kotlin

kotlin 复制代码

// build.gradle.kts (Kotlin DSL)

tasks.register("myRegisteredTaskInKotlin") {
    group = "My Custom Tasks"
    description = "A task registered using tasks.register in Kotlin DSL."

    doLast { // 任务执行时最后运行的动作
        println("Executing myRegisteredTaskInKotlin!")
        // 实际操作
        val newFile = File("$buildDir/myOutputFromKotlin.txt")
        newFile.writeText("Hello from myRegisteredTaskInKotlin on ${java.util.Date()}")
        println("Created file: ${newFile.absolutePath}")
    }

    doFirst { // 任务执行时最先运行的动作
        println("Getting ready for myRegisteredTaskInKotlin...")
    }
}

3. 继承现有任务类型 (Task Types)

Gradle 提供了很多内置的任务类型，例如 Copy, Delete, Exec, JavaCompile, Zip 等。你可以创建基于这些类型的任务，并配置它们的特定属性。

Groovy DSL (build.gradle)

Groovy

javascript 复制代码

tasks.register('copyMyDocs', Copy) { // 类型是 Copy
    group = "My Custom Tasks"
    description = "Copies documentation files."

    from 'src/main/docs' // 源目录
    into "$buildDir/docs"  // 目标目录

    include '**/*.md'    // 只拷贝 markdown 文件
    exclude '**/draft*.md' // 排除草稿文件

    // 可以在 doLast 中添加额外的操作
    doLast {
        println "Documentation copied to $buildDir/docs"
    }
}

tasks.register('cleanMyDocs', Delete) { // 类型是 Delete
    group = "My Custom Tasks"
    description = "Deletes copied documentation."
    delete "$buildDir/docs"
}

Kotlin DSL (build.gradle.kts)

Kotlin

sql 复制代码

import org.gradle.api.tasks.Copy
import org.gradle.api.tasks.Delete

tasks.register<Copy>("copyMyDocsInKotlin") {
    group = "My Custom Tasks"
    description = "Copies documentation files using Kotlin DSL."

    from("src/main/docs")
    into("$buildDir/docs")

    include("**/*.md")
    exclude("**/draft*.md")

    doLast {
        println("Documentation copied to $buildDir/docs (Kotlin)")
    }
}

tasks.register<Delete>("cleanMyDocsInKotlin") {
    group = "My Custom Tasks"
    description = "Deletes copied documentation using Kotlin DSL."
    delete("$buildDir/docs")
}

4. 创建独立的任务类 (更复杂和可复用的任务)

对于复杂的逻辑或者需要在多个项目中复用的任务，最佳实践是创建一个单独的 .gradle 文件或者在 buildSrc 目录下（或者作为一个独立的 Gradle 插件）定义一个继承自 org.gradle.api.DefaultTask 的类。

Groovy (buildSrc/src/main/groovy/com/example/MyCustomTask.groovy)

Groovy

scala 复制代码

package com.example

import org.gradle.api.DefaultTask
import org.gradle.api.tasks.Input
import org.gradle.api.tasks.TaskAction
import org.gradle.api.tasks.options.Option

class MyCustomTask extends DefaultTask {

    @Input // 标记为输入属性，影响任务的最新状态检查
    String message = "Default message"

    @Option(option = "msg", description = "Sets the message to be printed.") // 允许通过命令行传递参数
    void setMessage(String message) {
        this.message = message
    }

    @TaskAction // 标记任务执行的方法
    void Greet() {
        println "Message from MyCustomTask: ${message}"
        println "Executing from custom task class in project: ${project.name}"
    }
}

然后在 build.gradle 中使用它：

Groovy

javascript 复制代码

// build.gradle
// 如果 MyCustomTask.groovy 在 buildSrc 中，Gradle 会自动编译并使其可用
// 如果是单独的 .gradle 文件，可能需要 apply from: 'path/to/taskfile.gradle'

tasks.register('greet', com.example.MyCustomTask) {
    group = "My Custom Tasks"
    description = "A task defined by a custom class."
    message = "Hello from build script!" // 配置任务属性
}

Kotlin (buildSrc/src/main/kotlin/com/example/MyCustomTask.kt)

Kotlin

kotlin 复制代码

package com.example

import org.gradle.api.DefaultTask
import org.gradle.api.provider.Property
import org.gradle.api.tasks.Input
import org.gradle.api.tasks.TaskAction
import org.gradle.api.tasks.options.Option
import javax.inject.Inject // 对于 Gradle 7.x+ 使用 @Inject 构造函数注入服务

abstract class MyCustomTask @Inject constructor() : DefaultTask() { // 必须是 abstract

    @get:Input // 标记为输入属性
    abstract val message: Property<String> // 使用 Property API

    @Option(option = "msg", description = "Sets the message to be printed.")
    fun setMessage(message: String) {
        this.message.set(message)
    }

    init { // 构造函数或 init 块中设置默认值
        message.convention("Default message from Kotlin Task")
        group = "My Custom Tasks"
        description = "A task defined by a custom Kotlin class."
    }

    @TaskAction
    fun greet() {
        println("Message from MyCustomTask (Kotlin): ${message.get()}")
        println("Executing from custom task class in project: ${project.name}")
    }
}

然后在 build.gradle.kts 中使用：

Kotlin

kotlin 复制代码

// build.gradle.kts
import com.example.MyCustomTask

tasks.register<MyCustomTask>("greetKotlin") {
    // message.set("Hello from build script (Kotlin)!") // 通过 setter 配置
    // 或者直接配置属性
    this.message.set("Hello directly to property (Kotlin)!")
}

任务动作 (Task Actions): doFirst 和 doLast

doFirst { ... }: 添加一个在任务主要动作执行之前运行的闭包/lambda。可以添加多个，它们会按照添加的顺序执行。
doLast { ... }: 添加一个在任务主要动作执行之后运行的闭包/lambda。可以添加多个，它们会按照添加的顺序执行。
对于继承自某些内置任务类型（如 Copy）或自定义任务类中的 @TaskAction 方法，这些是任务的主要动作。

定义任务之间的依赖关系

Gradle 允许你精确控制任务的执行顺序和依赖。

1. dependsOn (直接依赖)

这是最常用的方式，表示一个任务的执行依赖于一个或多个其他任务的完成。被依赖的任务会先执行。

Groovy DSL (build.gradle)

Groovy

arduino 复制代码

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

task build {
    // build 任务依赖于 clean 任务
    dependsOn clean
    doLast {
        println 'Building the project...'
    }
}

task taskA { doLast { println 'Executing Task A' } }
task taskB { doLast { println 'Executing Task B' } }
task taskC {
    // taskC 依赖于 taskA 和 taskB
    dependsOn taskA, taskB
    doLast { println 'Executing Task C' }
}

当执行 ./gradlew build 时，clean 任务会先执行，然后才是 build 任务。当执行 ./gradlew taskC 时，taskA 和 taskB (顺序不保证) 会先执行，然后是 taskC。

Kotlin DSL (build.gradle.kts)

Kotlin

kotlin 复制代码

val clean by tasks.registering(Delete::class) {
    delete(rootProject.buildDir)
}

val build by tasks.registering {
    // build 任务依赖于 clean 任务
    dependsOn(clean) // 或者 dependsOn("clean")
    doLast {
        println("Building the project...")
    }
}

val taskA by tasks.registering { doLast { println("Executing Task A (Kotlin)") } }
val taskB by tasks.registering { doLast { println("Executing Task B (Kotlin)") } }
val taskC by tasks.registering {
    // taskC 依赖于 taskA 和 taskB
    dependsOn(taskA, taskB)
    doLast { println("Executing Task C (Kotlin)") }
}

2. mustRunAfter 和 shouldRunAfter (顺序约束，非严格依赖)

这些用于指定任务执行的相对顺序，但并不意味着被依赖的任务一定会执行。它们只在两个任务都计划执行时才生效。

mustRunAfter : 如果任务 A mustRunAfter 任务 B，并且 A 和 B 都在执行计划中，那么 B 必须在 A 之前完成。如果 B 不在执行计划中，A 仍然可以执行。如果违反了这个约束（例如，通过 dependsOn 导致 A 必须在 B 之前），构建会失败。
shouldRunAfter : 与 mustRunAfter 类似，但更宽松。如果任务 A shouldRunAfter 任务 B，Gradle 会尽力让 B 在 A 之前执行（如果两者都执行）。但如果由于其他约束无法满足，Gradle 不会报错，只会尝试。

Groovy DSL

Groovy

arduino 复制代码

task taskX { doLast { println 'Task X' } }
task taskY {
    mustRunAfter taskX // 如果 taskX 和 taskY 都执行，taskX 必须先于 taskY
    doLast { println 'Task Y' }
}
task taskZ {
    shouldRunAfter taskX // 如果 taskX 和 taskZ 都执行，Gradle 会尝试让 taskX 先于 taskZ
    doLast { println 'Task Z' }
}

Kotlin DSL

Kotlin

scss 复制代码

val taskX by tasks.registering { doLast { println("Task X (Kotlin)") } }
val taskY by tasks.registering {
    mustRunAfter(taskX)
    doLast { println("Task Y (Kotlin)") }
}
val taskZ by tasks.registering {
    shouldRunAfter(taskX)
    doLast { println("Task Z (Kotlin)") }
}

如果你执行 ./gradlew taskY taskX，你会看到 X 先于 Y 执行。如果你只执行 ./gradlew taskY，X 不会自动执行，因为 mustRunAfter 不会触发依赖。

3. finalizedBy (终结者任务)

一个任务可以被声明为由另一个任务"终结"。这意味着，无论第一个任务成功还是失败，只要它执行了，那么"终结者"任务总会在它之后被执行。

Groovy DSL

Groovy

arduino 复制代码

task mainTask {
    doLast {
        println "Running main task..."
        // throw new RuntimeException("Simulating failure") // 可以测试失败情况
    }
}

task cleanupTask {
    doLast {
        println "Running cleanup task, regardless of mainTask's outcome."
    }
}

mainTask.finalizedBy cleanupTask // cleanupTask 会在 mainTask 执行后执行

Kotlin DSL

Kotlin

kotlin 复制代码

val mainTask by tasks.registering {
    doLast {
        println("Running main task (Kotlin)...")
        // if (true) throw RuntimeException("Simulating failure in Kotlin")
    }
}

val cleanupTask by tasks.registering {
    doLast {
        println("Running cleanup task (Kotlin), regardless of mainTask's outcome.")
    }
}

mainTask { // 配置已注册的任务
    finalizedBy(cleanupTask)
}

如果你执行 ./gradlew mainTask，即使 mainTask 失败，cleanupTask 也会尝试执行。

4. 通过任务输入/输出隐式依赖

Gradle 非常智能，它可以根据任务的输入和输出自动推断任务之间的依赖关系，从而实现增量构建和并行执行。

例如，如果任务 B 的输入是任务 A 的输出，Gradle 会自动确保任务 A 在任务 B 之前执行。这是通过配置任务的 inputs 和 outputs 属性来实现的。

Groovy

kotlin 复制代码

// Groovy DSL
tasks.register('generateContent') {
    outputs.file("$buildDir/generated.txt") // 声明输出
    doLast {
        file("$buildDir/generated.txt").text = "Content from producer"
    }
}

tasks.register('consumeContent') {
    inputs.file("$buildDir/generated.txt") // 声明输入，隐式依赖于生成此文件的任务
    doLast {
        def content = file("$buildDir/generated.txt").text
        println "Consumer read: $content"
    }
}

在这种情况下，执行 ./gradlew consumeContent 会自动先执行 generateContent。

总结：

自定义任务： 可以通过 task 关键字（简单）、tasks.register (推荐，支持配置避免)、继承现有任务类型或创建独立任务类来实现。
任务依赖：
- dependsOn: 强制依赖，被依赖任务必须先执行。
- mustRunAfter / shouldRunAfter: 顺序约束，不强制执行被依赖任务，仅在两者都执行时调整顺序。
- finalizedBy: 确保一个任务在另一个任务执行完毕后（无论成功或失败）运行。
- 输入/输出：Gradle 可以通过文件依赖自动推断任务顺序。

理解并熟练运用这些机制，可以让你创建出强大、高效且易于维护的 Gradle 构建脚本。

Sources

定义了task后如何加入主工程里

Show thinking

将定义好的 Gradle 任务"加入"主工程，通常意味着你希望这个任务在构建过程中的特定时机被执行，或者作为其他主要任务的一部分运行。以下是几种常见的方法：

1. 让其他任务依赖你的自定义任务 (dependsOn)

这是最直接的方式。你可以让主工程中一些标准的生命周期任务（如 build, assemble, check）或者其他你关心的任务依赖于你的自定义任务。这样，当执行这些标准任务时，你的自定义任务会先被执行。

场景: 你有一个自定义任务 generateVersionInfo，需要在每次构建应用包之前生成版本信息文件。

Groovy DSL (build.gradle)

Groovy

dart 复制代码

task generateVersionInfo {
    doLast {
        println "Generating version information..."
        // 实际生成版本信息的代码
        def versionFile = new File("$buildDir/generated/version.txt")
        versionFile.parentFile.mkdirs()
        versionFile.text = "Version: 1.0.0, Build: ${new Date()}"
    }
}

// 让 'assemble' 任务依赖于 'generateVersionInfo'
// 对于 Android 项目，通常是 assemble<VariantName>，例如 assembleDebug
// 如果是纯 Java/Kotlin 项目，可能是 classes 或 jar 任务
// 为了通用性，可以让 'build' 任务依赖它，因为 'build' 通常会执行 'assemble' 和 'check'
tasks.named('build') { // 或者 tasks.getByPath(':app:assembleDebug') 对于 Android
    dependsOn generateVersionInfo
}

// 或者，如果你想在更早的阶段，比如编译Java代码之前
// tasks.named('compileJava') { // 对于 Android 可能是 compile<VariantName>JavaWithJavac
//     dependsOn generateVersionInfo
// }

Kotlin DSL (build.gradle.kts)

Kotlin

scss 复制代码

val generateVersionInfo by tasks.registering {
    doLast {
        println("Generating version information (Kotlin)...")
        val versionFile = project.layout.buildDirectory.file("generated/version.txt").get().asFile
        versionFile.parentFile.mkdirs()
        versionFile.writeText("Version: 1.0.0, Build: ${java.util.Date()} (Kotlin)")
    }
}

// 让 'build' 任务依赖于 'generateVersionInfo'
tasks.named("build") { // 或者 tasks.getByPath(":app:assembleDebug") 对于 Android
    dependsOn(generateVersionInfo)
}

// tasks.named("compileJava") { // compile<VariantName>JavaWithJavac
//     dependsOn(generateVersionInfo)
// }

注意: 在 Android 项目中，你通常会希望任务在特定构建变体 (Build Variant) 的构建过程中执行。例如，让 assembleDebug 任务依赖你的自定义任务：

Groovy

javascript 复制代码

// Groovy - Android
project.afterEvaluate { // 确保 Android 插件的任务已经创建
    tasks.named('assembleDebug') {
        dependsOn generateVersionInfo
    }
    tasks.named('assembleRelease') {
        dependsOn generateVersionInfo
    }
}

Kotlin

javascript 复制代码

// Kotlin - Android
project.afterEvaluate { // 确保 Android 插件的任务已经创建
    tasks.named("assembleDebug") {
        dependsOn(generateVersionInfo)
    }
    tasks.named("assembleRelease") {
        dependsOn(generateVersionInfo)
    }
}

或者更细致地挂接到 Android 任务图中的某个点，比如 preBuild 或特定变体的 preBuild 任务：

Groovy

javascript 复制代码

tasks.named('preBuild') { // 通常在所有变体构建前执行
    dependsOn generateVersionInfo
}
// 或者
// tasks.named('preDebugBuild') { // 仅在 Debug 变体构建前
//     dependsOn generateVersionInfo
// }

2. 让你的自定义任务依赖其他任务 (mustRunAfter, shouldRunAfter)

这种情况较少用于"加入主工程"，更多是用来调整你自定义任务与其他任务的执行顺序（如果它们都会被执行）。dependsOn 更侧重于"这个任务执行前，必须先完成那个"。

3. 使用 finalizedBy

如果你的任务是某个主要任务执行完毕后（无论成功或失败）必须执行的清理或报告任务。

场景: 在 assemble 任务完成后，执行一个自定义的 reportApkSize 任务。

Groovy DSL (build.gradle)

Groovy

javascript 复制代码

task reportApkSize {
    doLast {
        println "Reporting APK size..."
        // 获取 APK 文件并报告大小
    }
}

tasks.named('assemble') { // 或者 assembleDebug, assembleRelease
    finalizedBy reportApkSize
}

Kotlin DSL (build.gradle.kts)

Kotlin

scss 复制代码

val reportApkSize by tasks.registering {
    doLast {
        println("Reporting APK size (Kotlin)...")
    }
}

tasks.named("assemble") { // 或者 assembleDebug, assembleRelease
    finalizedBy(reportApkSize)
}

4. 直接调用自定义任务

定义好的任务本身就已经"在"主工程里了。你可以通过 Gradle Wrapper 直接从命令行执行它：

Bash

bash 复制代码

./gradlew yourCustomTaskName

这种方式下，任务不会自动成为标准构建流程的一部分，除非你手动调用它或通过 CI/CD 脚本调用。

5. Android 项目特有的挂载点

Android Gradle 插件提供了一些特定的"锚点任务 (anchor tasks)"或扩展点，允许你更容易地将自定义逻辑注入到构建流程中。

android.applicationVariants.all { variant -> ... } (旧版 AGP) 或 androidComponents.onVariants { variant -> ... } (新版 AGP - 推荐) : 你可以遍历所有构建变体，并为每个变体的特定任务（如 preBuild, mergeResources, packageApplication) 添加依赖或操作。

使用 androidComponents API (AGP 7.0+ 推荐)

Groovy DSL (build.gradle)

Groovy

kotlin 复制代码

task myCustomAndroidTask {
    doLast {
        println "Running myCustomAndroidTask for ${project.name}"
    }
}

androidComponents {
    onVariants(selector().all(), { variant ->
        // 在打包之前运行
        def packageTaskName = "package${variant.name.capitalize()}"
        tasks.named(packageTaskName).configure {
            dependsOn myCustomAndroidTask
        }

        // 或者注册一个新任务并让某个 Android 任务依赖它
        def variantSpecificTask = tasks.register("myVariantSpecificTaskFor${variant.name.capitalize()}", MyCustomTaskType) {
            // 配置这个任务
            inputFile.set(layout.projectDirectory.file("some_input.txt"))
            outputFile.set(layout.buildDirectory.file("outputs/${variant.name}/output.txt"))
        }
        // 让 preBuild 依赖这个新注册的特定于变体的任务
        tasks.named("pre${variant.name.capitalize()}Build").configure {
            dependsOn variantSpecificTask
        }
    })
}

Kotlin DSL (build.gradle.kts)

Kotlin

less 复制代码

abstract class MyCustomTaskType : DefaultTask() { // 示例自定义任务类型
    @get:InputFile
    abstract val inputFile: RegularFileProperty
    @get:OutputFile
    abstract val outputFile: RegularFileProperty
    @TaskAction
    fun taskAction() {
        println("Executing MyCustomTaskType for variant, input: ${inputFile.get().asFile.name}")
        outputFile.get().asFile.writeText("Processed by ${name} for ${inputFile.get().asFile.name}")
    }
}

val myCustomAndroidTask by tasks.registering {
    doLast {
        println("Running myCustomAndroidTask for ${project.name} (Kotlin)")
    }
}

androidComponents {
    onVariants(selector().all()) { variant ->
        // 在打包之前运行
        val packageTaskName = "package${variant.name.replaceFirstChar { it.uppercase() }}"
        tasks.named(packageTaskName).configure {
            dependsOn(myCustomAndroidTask)
        }

        // 或者注册一个新任务并让某个 Android 任务依赖它
        val variantSpecificTask = tasks.register<MyCustomTaskType>("myVariantSpecificTaskFor${variant.name.replaceFirstChar { it.uppercase() }}") {
            inputFile.set(project.layout.projectDirectory.file("some_input.txt"))
            outputFile.set(project.layout.buildDirectory.file("outputs/${variant.name}/output.txt"))
        }
        tasks.named("pre${variant.name.replaceFirstChar { it.uppercase() }}Build").configure {
            dependsOn(variantSpecificTask)
        }
    }
}

选择哪种方式？

如果你的任务是通用的，并且应该在每次构建或特定阶段（如打包、检查）之前运行，使用 dependsOn 挂载到标准的 Gradle 生命周期任务或 Android 的主要变体任务上（如 assembleDebug, preBuild）。
如果你的任务是某个主要任务的收尾工作，使用 finalizedBy。
如果你的任务是独立的工具性质，不需要自动集成到标准构建流程，直接通过命令行调用即可。
对于 Android 项目，如果需要根据不同的构建变体执行或配置任务，优先考虑使用 androidComponents API。

确保理解 Gradle 的配置阶段 (Configuration phase) 和执行阶段 (Execution phase)。依赖关系通常在配置阶段确定。如果你需要基于某些条件动态添加依赖，可能需要使用 project.afterEvaluate { ... } (尽管应尽量避免，因为它会降低配置效率并可能导致顺序问题，androidComponents API 是更好的选择)。

Android Gradle中主工程中标准的生命周期是什么

理解 Android Gradle 中主工程（通常是 application 模块）的构建生命周期对于管理和自定义构建过程至关重要

虽然 Gradle 本身有一些核心的生命周期概念，但在 Android 项目中，这些概念与 Android Gradle 插件（AGP）定义的任务紧密结合，形成了一套更具体的构建流程。

可以从两个层面来看：

1. 通用 Gradle 生命周期任务 (Standard Gradle Lifecycle Tasks)

这些是 Gradle 内置的，并且在 Android 项目中依然有意义，尽管它们通常会触发一系列 Android 特定的任务。

clean:
- 作用 : 清理项目的构建产物。通常会删除 build 目录。
- 在 Android 中的体现 : 执行 ./gradlew clean 会删除所有模块的 build 目录，包括编译的类文件、打包的 APK/AAB、生成的资源等。
assemble:
- 作用: 构建项目的所有输出产物，但不运行测试。
- 在 Android 中的体现 : 对于主工程（Application 模块），执行 ./gradlew assemble 通常会构建所有构建变体（Build Variants）的 APK 或 AAB 文件。例如，它会触发 assembleDebug 和 assembleRelease (如果都配置了)。
  - assemble<VariantName> (例如 assembleDebug, assembleRelease): 这是更常用的，用于构建特定变体的输出。它会执行编译代码、处理资源、DEX 化、打包等一系列步骤。
check:
- 作用: 执行所有的验证任务，通常包括运行单元测试和 instrumentation 测试（如果配置了）。
- 在 Android 中的体现 : 执行 ./gradlew check 会运行 lint 检查、单元测试 (testDebugUnitTest, testReleaseUnitTest 等) 以及连接设备/模拟器的 instrumentation 测试 (connectedDebugAndroidTest 等，如果连接了设备并且任务被触发)。
build:
- 作用 : 执行 assemble 和 check 两者的任务。也就是说，它会构建项目并运行所有检查和测试。
- 在 Android 中的体现 : 执行 ./gradlew build 会构建所有变体的 APK/AAB，并运行相关的 Lint 检查和测试。这是一个非常全面的构建命令。
projects: 列出项目中的所有子项目 (模块)。
tasks: 列出当前项目中所有可执行的任务。
help: 显示 Gradle 帮助信息。

2. Android Gradle 插件 (AGP) 定义的关键构建流程和任务

AGP 在通用 Gradle 生命周期之上，为构建 Android 应用定义了更细致的任务和流程。当你执行像 assembleDebug 这样的任务时，背后会有一长串相互依赖的任务被执行。以下是一些关键阶段和任务（以构建一个 APK 为例，顺序大致如此，但具体任务名可能包含构建变体）：

初始化 (Initialization Phase) :
- Gradle 解析 settings.gradle(.kts) 文件，确定哪些项目参与构建。
配置 (Configuration Phase) :
- Gradle 解析所有项目的 build.gradle(.kts) 文件。
- AGP 根据你的配置（如 compileSdk, minSdk, buildTypes, productFlavors, 依赖等）创建和配置大量的任务。
- 例如，preBuild, pre<VariantName>Build (如 preDebugBuild) 任务在此时被配置，它们通常在实际编译前执行一些准备工作。
执行 (Execution Phase) - 当你运行一个具体任务如 assembleDebug 时：
1. 资源处理 (Resource Processing) :
  - generate<VariantName>ResValues: 生成 resValue 定义的资源。
  - generate<VariantName>Resources: 执行其他资源生成任务。
  - merge<VariantName>Resources: 合并所有来源（主代码、库、构建变体）的资源文件。处理覆盖规则，生成 R.java (或 R.jar for libraries, and bytecode for R class for AGP 7.0+ with non-transitive R classes) 的前置步骤。
  - process<VariantName>Resources: 处理并编译资源，例如将 XML 转换为二进制格式，优化图片等。
2. 编译 Java/Kotlin 代码 (Compilation) :
  - compile<VariantName>Kotlin (如果使用 Kotlin): 编译 Kotlin 源代码为 Java 字节码。
  - compile<VariantName>JavaWithJavac: 编译 Java 源代码（以及 Kotlin 编译后的字节码）为 .class 文件。
3. DEX 化 (Dexing) :
  - dexBuilder<VariantName> 或 mergeDex<VariantName>: 将 .class 文件（以及库的 .class 文件）转换为 Android Runtime (ART) 或 Dalvik 虚拟机可执行的 DEX (.dex) 文件。对于 minSdkVersion 21+，可能会使用 D8 进行 DEX 化，并可能进行脱糖 (desugaring) 以支持较新 Java 语言特性。
4. 代码缩减和混淆 (Shrinking, Obfuscation, Optimization - 如果启用) :
  - 通常使用 R8 (替代 ProGuard)。任务可能包括 minify<VariantName>WithR8。
  - 这个步骤会在 DEX 化之前或作为 DEX 化的一部分进行，移除未使用的代码和资源，混淆代码，优化字节码。
5. 合并 DEX 文件 (Merging Dex files) :
  - mergeExtDex<VariantName> 和 mergeLibDex<VariantName> (如果需要，例如 multidex 场景)。
  - 将所有 DEX 文件合并。
6. 打包 APK/AAB (Packaging) :
  - package<VariantName> (例如 packageDebug): 将编译后的代码 (DEX 文件)、处理过的资源、assets、Android Manifest 等打包成一个 APK 文件。
  - 对于 App Bundle，则是 bundle<VariantName> (例如 bundleDebug)。
7. 签名 (Signing) :
  - sign<VariantName>Apk (或者作为 package<VariantName> 的一部分): 使用签名配置对 APK进行签名。Debug 构建通常使用自动生成的 debug keystore，Release 构建需要你配置的发布密钥。
8. 对齐 (Zipalign - 通常在签名后，但对于 v2+ 签名方案，顺序可能不同) :
  - zipalign<VariantName>: 优化 APK 文件，使其在运行时更有效地被 Android 系统读取。
9. 最终产物通常是 app/build/outputs/apk/<variantName>/app-<variantName>.apk 或 app/build/outputs/bundle/<variantName>/app-<variantName>.aab。

其他重要的 Android 相关任务:

install<VariantName> (例如 installDebug): 构建并安装特定变体的 APK 到连接的设备或模拟器。
uninstall<VariantName> (例如 uninstallDebug): 从设备卸载特定变体的应用。
lint: 运行代码静态分析，检查潜在的 bug、性能问题、可用性问题等。
- lint<VariantName> (例如 lintDebug): 针对特定变体运行 Lint。
test<VariantName>UnitTest (例如 testDebugUnitTest): 运行本地 JVM 单元测试。
connected<VariantName>AndroidTest (例如 connectedDebugAndroidTest): 在连接的设备或模拟器上运行 Instrumentation 测试。
deviceCheck : (旧称 createDebugCoverageReport 等) 通常用于运行需要在设备上执行的更广泛的检查。

总结来说，Android Gradle 的主工程生命周期是：

清理 (可选): clean
构建:
- 执行 assemble<VariantName> 会触发资源处理、编译、DEX 化、打包、签名等一系列任务。
- 执行 assemble 会对所有变体执行上述过程。
检查 (可选):
- lint<VariantName>
- test<VariantName>UnitTest
- connected<VariantName>AndroidTest
- check 会执行所有这些检查。
完整构建 (可选): build (相当于 assemble + check)

理解这些任务和它们大致的顺序，可以帮助你：

知道在构建的哪个阶段可以插入自定义任务。
更好地调试构建问题。
优化构建时间。

你可以通过运行 ./gradlew tasks --all (对于特定项目，如 :app:tasks --all) 来查看项目中所有可用的任务及其依赖关系，从而更深入地了解构建流程。

Gradle 插件自定义指南

自定义 Gradle 插件主要有三种方式：

在 build.gradle 文件中直接编写插件： 这种方式最简单，适用于插件逻辑比较简单且仅用于当前构建文件的情况。
在 buildSrc 项目中编写插件： 这是 Gradle 推荐的组织构建逻辑的方式。buildSrc 是一个特殊的项目，它里面的代码会自动被编译并加入到主构建的 classpath 中。这种方式适合插件逻辑相对复杂，但仍仅用于当前项目的情况。
创建独立的插件项目： 这是最灵活也是最复杂的方式，适用于需要将插件发布并分享给多个项目使用的情况。

接下来，我将详细介绍后两种更常用的方式。

在 `buildSrc` 项目中编写插件

buildSrc 是一个位于项目根目录下的特殊目录。Gradle 会在执行任何其他构建任务之前，自动编译和测试这个目录中的代码，并将其添加到构建脚本的 classpath 中。

步骤：

创建 buildSrc 目录： 在你的项目根目录下创建 buildSrc 文件夹。
创建 build.gradle 文件 (可选但推荐)： 在 buildSrc 目录下创建一个 build.gradle 文件，用于声明 buildSrc 项目本身的依赖。例如，你可能需要 Gradle API：

Groovy
scss 复制代码
```
// buildSrc/build.gradle
repositories {
    mavenCentral()
}
dependencies {
    implementation gradleApi() // 声明对 Gradle API 的依赖
    // implementation localGroovy() // 如果使用 Groovy
}
```
创建插件源代码目录： 在 buildSrc/src/main 目录下，根据你选择的语言创建相应的目录结构：
- Groovy: buildSrc/src/main/groovy
- Java: buildSrc/src/main/java
- Kotlin: buildSrc/src/main/kotlin

编写插件代码： 例如，我们创建一个简单的 Groovy 插件 GreetingPlugin.groovy：

Groovy

typescript 复制代码

// buildSrc/src/main/groovy/com/example/GreetingPlugin.groovy
package com.example

import org.gradle.api.Plugin
import org.gradle.api.Project

class GreetingPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.task('hello') {
            doLast {
                println "Hello from the GreetingPlugin!"
            }
        }
    }
}

应用插件： 在你项目根目录的 build.gradle 文件中应用该插件：

Groovy
arduino 复制代码
```
// project-root/build.gradle
plugins {
    id 'java' // 举例，可以是任何其他插件
    id 'com.example.GreetingPlugin' // 应用自定义插件
}
```
或者使用旧的 apply 方式 (不推荐)：

Groovy
arduino 复制代码
```
// project-root/build.gradle
apply plugin: com.example.GreetingPlugin
```
注意： 对于 buildSrc 中的插件，你不需要在 settings.gradle 中包含 buildSrc，也不需要在主构建的 buildscript 闭包中添加 buildSrc 的依赖，Gradle 会自动处理。
运行任务： 现在你可以在命令行中运行你在插件中定义的任务了：

Bash
bash 复制代码
```
./gradlew hello
```

创建独立的插件项目

如果你希望将插件发布并在多个项目中复用，或者插件逻辑非常复杂，那么创建一个独立的插件项目是更好的选择。

步骤：

创建新的 Gradle 项目： 你可以使用 Gradle init 命令或者 IDE 来创建一个新的 Gradle 项目。

配置 build.gradle 文件： 在插件项目的 build.gradle 文件中，你需要：

应用 java-gradle-plugin (推荐) 或 groovy-gradle-plugin (如果使用 Groovy 且不使用 Java Gradle Plugin Development Suite 的特性)。java-gradle-plugin 插件会自动应用 Java 插件并添加 gradleApi() 依赖。
配置 gradlePlugin 闭包，声明插件的 ID 和实现类。

例如，使用 java-gradle-plugin 和 Groovy：

Groovy

csharp 复制代码

// plugin-project/build.gradle
plugins {
    id 'groovy' // 或者 'java' 或 'org.jetbrains.kotlin.jvm'
    id 'java-gradle-plugin'
}

repositories {
    mavenCentral()
}

// 如果使用 Groovy，确保 Groovy 依赖存在 (java-gradle-plugin 不会自动添加)
dependencies {
    implementation localGroovy()
}

gradlePlugin {
    plugins {
        greetingPlugin { // 这是插件的配置名称，可以任意取
            id = 'com.example.greeting' // 插件的唯一 ID
            implementationClass = 'com.example.standalone.GreetingPlugin' // 插件实现类的全限定名
        }
    }
}

编写插件代码： 在 src/main/groovy (或 java/kotlin) 目录下创建插件实现类：

Groovy

typescript 复制代码

// plugin-project/src/main/groovy/com/example/standalone/GreetingPlugin.groovy
package com.example.standalone

import org.gradle.api.Plugin
import org.gradle.api.Project

class GreetingPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.task('standaloneHello') {
            doLast {
                println "Hello from the Standalone GreetingPlugin!"
            }
        }
    }
}

发布插件 (可选)：

发布到本地 Maven 仓库 (mavenLocal())： 在插件项目的 build.gradle 中添加 maven-publish 插件并配置：

Groovy

javascript 复制代码

plugins {
    // ... 其他插件
    id 'maven-publish'
}

publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java // 如果是纯 Java/Groovy 插件
            // 对于 Gradle 插件，java-gradle-plugin 插件会自动处理发布相关的元数据
        }
    }
    repositories {
        mavenLocal()
    }
}

然后运行 ./gradlew publishToMavenLocal。

发布到远程仓库： 配置相应的仓库地址和凭证。

在其他项目中使用插件：

如果发布到了本地 Maven 仓库： 在要使用该插件的项目的 settings.gradle 文件中配置 pluginManagement：

Groovy

scss 复制代码

// consumer-project/settings.gradle
pluginManagement {
    repositories {
        mavenLocal()
        gradlePluginPortal() // 确保 Gradle 插件门户也在其中
        mavenCentral()
    }
}

然后在该项目的 build.gradle 文件中应用插件：

Groovy

arduino 复制代码

// consumer-project/build.gradle
plugins {
    id 'com.example.greeting' version '1.0.0' // 替换为你的插件版本
}

如果插件项目是多模块构建的一部分： 在 settings.gradle 中使用 includeBuild：

Groovy

arduino 复制代码

// consumer-project/settings.gradle
pluginManagement {
    // ... repositories
}
includeBuild '../plugin-project' // 假设插件项目在上一级目录的 plugin-project 文件夹

然后在 build.gradle 中应用插件 (通常不需要版本号)：

Groovy

bash 复制代码

// consumer-project/build.gradle
plugins {
    id 'com.example.greeting'
}

插件的更多功能

1. 扩展 (Extensions)

插件可以定义扩展，允许用户在构建脚本中配置插件的行为。

在插件中定义扩展对象 (POJO/POGO)：

Groovy

java 复制代码

// buildSrc/src/main/groovy/com/example/GreetingPluginExtension.groovy (或独立插件项目)
package com.example

abstract class GreetingPluginExtension {
    String greeter = "Plugin User" // 默认值
    String message = "Hello"

    // 对于 Kotlin 或需要 Gradle 注入服务的更高级场景，可以使用 @javax.inject.Inject
    // import org.gradle.api.provider.Property
    // abstract Property<String> getGreeter()
    // abstract Property<String> getMessage()
    // GreetingPluginExtension() { // 构造函数中设置默认值
    //     getGreeter().convention("Plugin User")
    //     getMessage().convention("Hello")
    // }
}

在插件 apply 方法中注册扩展：

Groovy

typescript 复制代码

// buildSrc/src/main/groovy/com/example/GreetingPlugin.groovy (或独立插件项目)
package com.example

import org.gradle.api.Plugin
import org.gradle.api.Project

class GreetingPlugin implements Plugin<Project> {
    void apply(Project project) {
        // 注册扩展，名称为 "greeting"
        def extension = project.extensions.create('greeting', GreetingPluginExtension)

        project.task('hello') {
            doLast {
                println "${extension.message} from ${extension.greeter} (via GreetingPlugin)!"
            }
        }
    }
}

在 build.gradle 中配置扩展：

Groovy

arduino 复制代码

// project-root/build.gradle
plugins {
    id 'com.example.GreetingPlugin' // 或独立插件的 ID
}

greeting { // "greeting" 是注册扩展时使用的名称
    greeter = "Awesome Developer"
    message = "Custom Hi"
}

2. 约定 (Conventions)

约定是插件为项目设置的默认值或行为，用户可以覆盖它们。这通常通过配置任务的属性或项目的属性来实现。

3. 依赖管理

插件可以为项目添加默认的依赖。

Groovy

arduino 复制代码

// 在插件的 apply 方法中
project.dependencies {
    implementation 'com.google.guava:guava:32.1.3-jre'
}

4. 与其他插件交互

插件可以检查其他插件是否被应用，并根据此来配置自身行为，或者配置其他插件的任务。

Groovy

javascript 复制代码

// 在插件的 apply 方法中
project.plugins.withId('java') { // 当 java 插件被应用时
    // 配置 java 插件相关的任务或属性
    project.tasks.named('compileJava') {
        // ...
    }
}

// 或者
project.afterEvaluate { // 在项目配置完成后
    if (project.plugins.hasPlugin('application')) {
        // ...
    }
}

最佳实践

使用 java-gradle-plugin： 对于独立插件项目，它简化了很多配置。
惰性配置 (Lazy Configuration)： 使用 Provider API (Property, Provider) 来定义任务输入输出和扩展属性，避免在配置阶段就实例化或计算值，提高构建性能。
增量构建： 正确声明任务的输入和输出，使 Gradle 能够跳过未更改的任务。
可测试性： 编写单元测试和集成测试 (使用 Gradle TestKit) 来验证插件的行为。
清晰的文档： 如果插件要被他人使用，提供清晰的文档说明如何配置和使用。
命名空间： 为插件 ID 和扩展名使用唯一的命名空间，避免冲突。

选择哪种方式取决于你的具体需求。对于简单的、项目内部的逻辑，buildSrc 通常是最佳选择。对于需要共享或更复杂的插件，独立项目更为合适。

Android 面试级别详解

Android 面试的 "Grade" 或级别，通常指的是公司内部对候选人能力和经验的评估体系。这个体系会直接关联到职位名称、薪资范围、以及工作职责和期望。虽然不同公司的具体称谓和层级划分可能有所差异，但总体上遵循一定的规律。

以下是一些常见的 Android 面试级别和相关概念：

通用级别划分 (由低到高):

初级 Android 工程师 (Junior Android Developer / Associate Android Engineer):
- 经验要求: 通常是应届毕业生或拥有 0-2 年相关经验。
- 面试考察重点:
  - 扎实的 Java 或 Kotlin 基础知识。
  - 对 Android SDK 核心组件 (Activity, Service, BroadcastReceiver, ContentProvider) 的理解和基本使用。
  - 熟悉 Android Studio 开发环境和调试工具。
  - 能够实现简单的 UI 界面和处理用户交互。
  - 对基本的布局、控件、生命周期管理有了解。
  - 学习能力和解决问题的潜力。
- 工作职责: 通常在资深工程师的指导下完成具体模块的开发、bug 修复和单元测试。
中级 Android 工程师 (Mid-level Android Developer / Android Engineer):
- 经验要求: 通常拥有 2-5 年相关经验。
- 面试考察重点:
  - 更深入的 Android SDK 知识，包括更复杂的组件使用、自定义 View、性能优化、内存管理等。
  - 熟悉常用的设计模式 (如 MVP, MVVM, MVI) 并能在项目中应用。
  - 掌握网络编程 (如 Retrofit, OkHttp)、数据存储 (SQLite, Room, DataStore) 等。
  - 了解多线程编程、异步处理。
  - 能够独立负责模块或小型项目的设计与开发。
  - 具备一定的代码审查和调试复杂问题的能力。
  - 对 Jetpack 组件库有一定程度的掌握。
- 工作职责: 独立完成功能模块的开发，参与部分架构设计，解决开发中的技术难题，指导初级工程师。
高级 Android 工程师 (Senior Android Developer):
- 经验要求: 通常拥有 5 年以上相关经验。
- 面试考察重点:
  - 深厚的 Android 技术功底，对 Android 系统底层原理有一定理解。
  - 精通应用架构设计，能够根据业务需求选择和设计合适的架构。
  - 在性能优化、稳定性保障、安全性等方面有丰富经验。
  - 熟悉模块化、组件化开发。
  - 能够主导复杂项目或关键技术模块的攻坚。
  - 具备良好的技术选型和方案设计能力。
  - 能够指导和培养团队成员。
  - 对新技术和行业趋势有敏锐的洞察力。
  - 可能会涉及系统设计 (System Design) 方面的考察。
- 工作职责: 负责复杂项目的架构设计和核心模块开发，解决关键技术问题，主导技术难题攻关，指导团队成员，参与制定技术规范和流程。
资深/专家级 Android 工程师 (Staff/Principal Android Engineer / Tech Lead):
- 经验要求: 通常拥有 8 年以上甚至更丰富的经验，在特定领域有深厚积累。
- 面试考察重点:
  - 在某个或多个 Android 技术领域达到专家水平 (如性能优化、架构、UI 框架、音视频、安全等)。
  - 能够对公司级的技术方向和战略产生影响。
  - 领导跨团队的大型项目或技术攻关。
  - 解决极具挑战性的技术问题。
  - 在业界有一定影响力者更佳。
  - 强大的系统设计能力和抽象能力。
  - 卓越的沟通、协作和领导能力。
- 工作职责: 定义团队或部门的技术愿景和路线图，解决公司层面最复杂的技术挑战，推动技术创新，指导和培养高级工程师，代表公司参与行业技术交流。

大型科技公司 (如 FAANG/BAT) 的级别体系:

这些公司通常有更细致的内部级别体系，例如：

Google: L3 (Entry-Level), L4 (Software Engineer), L5 (Senior Software Engineer), L6 (Staff Software Engineer), L7 (Senior Staff Software Engineer) 等。
Meta (Facebook): E3, E4, E5, E6, E7 等。

这些级别会对应到上述通用级别，但划分更精细，晋升标准也更明确。面试时，面试官会根据候选人的表现将其对应到相应的内部级别。

面试评价标准:

面试官通常会从以下几个方面综合评估候选人：

技术知识和技能 (Role-Related Knowledge & Skills): 对 Android 基础、进阶知识、框架、工具等的掌握程度。
编码能力 (Coding): 代码的正确性、健壮性、可读性、效率等。通常会有算法题和实际场景的编码题。
解决问题的能力 (Problem Solving / General Cognitive Ability): 分析问题、定位问题、提出解决方案的能力。
系统设计能力 (System Design): (对于中高级及以上职位) 设计复杂系统或模块的能力，考虑可扩展性、可维护性、性能等。
项目经验和影响力 (Experience and Past Projects): 过去项目的复杂度、个人在其中的贡献和遇到的挑战。
沟通能力和团队协作 (Communication & Teamwork): 清晰表达思路，有效与面试官沟通，以及过往团队协作的经验。
文化契合度 (Cultural Fit / Googleyness 等): 是否符合公司的价值观和团队文化。
领导力 (Leadership): (对于高级及以上职位) 带领团队、指导他人的能力。

总结:

Android 面试的 Grade 是一个综合评估的结果，它不仅取决于你答对了多少问题，更重要的是展现出来的技术深度、广度、解决问题的能力以及与不同级别岗位相匹配的经验和潜力。在准备面试时，建议根据目标公司的级别要求，有针对性地复习和准备。了解不同级别的期望，能帮助你更好地展示自己。

Android Gradle 简介

Gradle

Gradle 基础知识

Gradle 构建脚本

Gradle 任务 (Tasks)

依赖管理

构建优化与提速

多模块项目

自定义 Gradle 插件

常见问题与排错

BOM 的作用 - 如何简化多模块项目中库版本的管理

什么是 BOM (Bill of Materials)？

BOM 如何简化多模块项目中库版本的管理？

Gradle如何自定义任务，或者任务之间的依赖关系

Gradle 如何自定义任务

定义任务之间的依赖关系

Android Gradle中主工程中标准的生命周期是什么

Gradle 插件自定义指南

在 buildSrc 项目中编写插件

创建独立的插件项目

插件的更多功能

1. 扩展 (Extensions)

2. 约定 (Conventions)

3. 依赖管理

4. 与其他插件交互

最佳实践

Android 面试级别详解

在 `buildSrc` 项目中编写插件