📚 课程目录第4章插件机制

插件机制：核心插件与社区插件、apply与plugins、自定义插件入门

说起Gradle的插件机制，我接触得还挺早的。刚开始用Gradle那会儿，说实话，我对插件这玩意儿挺怵的。总觉得「插件」是个黑盒，不知道它到底干了什么。后来做项目做多了，踩的坑多了，才慢慢体会到——插件就是Gradle的灵魂。

说白了，Gradle本身就像一个操作系统内核，只提供最基础的构建能力。你想要打包APK、做代码混淆、跑单元测试？嗯，这些能力都得靠插件来实现。你想想看，如果没有插件，你每次都得自己写Task去编译Java、拷贝资源、签名APK……那不得累死？

核心插件 vs 社区插件

插件分两大类：核心插件和社区插件。

核心插件是Gradle官方内置的，开箱即用。比如java、groovy、maven-publish这些。你不需要额外引入什么依赖，直接写id 'java'就能用。

社区插件是由第三方开发者或组织发布的。比如Android应用开发用的com.android.application，Spring Boot项目用的org.springframework.boot，这些都需要从Gradle插件门户或者自定义仓库里下载。

我个人习惯：能用核心插件解决的问题，绝不引入社区插件。比如只是做Java库的发布，用maven-publish就足够了，没必要为了漂亮去引入某个第三方发布的插件——少一个依赖，少一次风险。

这里有一个比较实用的表格，我整理了一下常见的插件分类：

类型	插件ID	来源	适用场景
核心	`java`	内置	Java项目编译、测试、打包
核心	`maven-publish`	内置	发布Artifacts到Maven仓库
社区	`com.android.application`	Android Gradle Plugin	构建Android应用APK
社区	`org.springframework.boot`	Spring Gradle Plugin	Spring Boot项目打包与依赖管理
社区	`com.google.protobuf`	Protobuf Gradle Plugin	编译Protobuf定义文件

apply 与 plugins：两种声明方式

这里有个细节，很多人刚开始会搞混——apply和plugins到底有什么区别？

简单来说，plugins块是Gradle 2.1之后推荐的方式，它是一种声明式写法。我建议你以后都用这种方式：

plugins {
    id 'java'
    id 'com.android.application' version '8.1.0'
}

而apply是传统写法，更灵活，但你需要手动管理依赖：

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:8.1.0'
    }
}

apply plugin: 'com.android.application'

我在项目里就踩过这个坑。有一次我接手一个老项目，看到它用了apply plugin的方式。我想加一个新插件，顺手就写到了plugins块里。结果呢？两个插件的解析顺序出问题了，编译报错搞了我一下午。

千万不要在同一个build.gradle里混用plugins块和apply方式声明同一个插件，不然解析顺序和依赖管理会乱掉。要么全用plugins，要么全用apply。

为什么会这样？因为plugins块会在构建生命周期的早期阶段自动解析插件，而apply是在配置阶段手动调用。两者混用，顺序没法保证。

自定义插件开发入门

好了，聊完怎么用插件，再说说怎么写插件。我刚开始写自定义插件的时候，以为是什么高大上的事情。后来发现，其实就是写一个实现了Plugin<Project>接口的类，然后在apply()方法里定义你要做的事。

最简单的自定义插件，长这样：

class HelloPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.task('hello') {
            doLast {
                println 'Hello from my first plugin!'
            }
        }
    }
}

然后你可以在build.gradle里这样应用它：

apply plugin: HelloPlugin

嗯，这里要注意。我们通常不会把插件类写在build.gradle里，而是放在buildSrc目录下，或者做成独立的工程发布到仓库里。

我给大家画了一张图，方便理解插件开发的核心流程：

开发自定义插件的关键步骤，我总结成这几步：

创建插件类：实现org.gradle.api.Plugin<Project>接口
定义扩展（可选）：用project.extensions.create()让用户可以传参数
注册Task：在apply()里调用project.task()或project.tasks.register()
发布插件：用maven-publish插件发布到仓库
应用插件：在项目里通过plugins块或apply引用

  我建议大家刚开始写自定义插件的时候，从buildSrc开始。把插件类放到项目根目录的buildSrc/src/main/java（或groovy）下，Gradle会自动编译并把它加入构建脚本的classpath。无需发布，即时生效，调试起来特别方便。

举个例子，假设你想写一个插件，用来统一打印项目的所有依赖：

// buildSrc/src/main/java/com/example/DepsPlugin.java
public class DepsPlugin implements Plugin<Project> {
    @Override
    public void apply(Project project) {
        project.getTasks().register("printDeps", task -> {
            task.doLast(t -> {
                project.getConfigurations().forEach(config -> {
                    System.out.println("Config: " + config.getName());
                    config.getDependencies().forEach(dep -> {
                        System.out.println("  - " + dep.getGroup() + ":" + dep.getName() + ":" + dep.getVersion());
                    });
                });
            });
        });
    }
}

然后在build.gradle里：

plugins {
    id 'com.example.deps-plugin'
}

或者如果你懒得注册插件ID，直接：

apply plugin: com.example.DepsPlugin

运行gradle printDeps，所有配置下的依赖就列出来了。这就是自定义插件的魅力——把重复的、复杂的工作封装起来，一行代码就能复用。

我曾经在一个多模块项目里写过一个自定义插件，用来统一管理所有模块的公共配置。比如统一Java版本、统一编码格式、自动添加静态分析工具。这样每个子模块的build.gradle就干净多了，只保留和自身业务相关的配置。

说白了，插件机制就是Gradle留给你的「后门」。官方给的插件不够用？你自己写一个。写好了，还能分享给团队，甚至发布到社区让全世界的人用。这个能力掌握好了，你对Gradle的掌控力会提升一个档次。