谈到Gradle开发，相信很多人第一反应就是开发Gadle Plugin。这倒也没错，plugin是Gradle提供出来，通过apply(Closure closure)方法就可以轻松注入到编译过程中来。
当然，你可以说就开发一个Task类，然后在gradle脚本中引入这个Task，这也是可行的，只不过看起来就似乎没有那么优雅以及显得封装性不是那么完整。
PluginAware
谈起plugin那不可避免就要提到org.gradle.api.plugins.PluginAware，为什么这样说呢？因为，它的含义是可以apply plugin的所在，换句话说只有实现了PluginAware的对象才可以apply plugin。
从上图可以得知，gradle中有两个子接口继承PluginAware，分别是org.gradle.api.Project和org.gradle.api.initialization.Settings，当然这两个接口也有分别实现的默认类，是对这两个接口的具体实现，暂不延伸去讲了。
因此可知，有两种类型插件，分别是：
Project[build.gradle]
class ProjectPlugin implements Plugin<Project>{
void apply(Project target){
...
}
}
Settings[settings.gradle]
class SettingsPlugin implements Plugin<Settings>{
void apply(Settings target){
...
}
}
由此可以根据不同的需求(例如settings才能添加顶级工程的classpath依赖)开发不同类型的Plugin。
PluginManager
对，从字面意思来看-插件管理器。无论是Project还是Settings，都是通过org.gradle.api.plugins.PluginManager来对Plugin来进行具体操作的，其中最核心的方法如下。
void apply(String pluginId);
AppliedPlugin findPlugin(String id);
boolean hasPlugin(String id);
void withPlugin(String id, Action<? super AppliedPlugin> action);
很简单但是也最常用，apply是应用插件，findPlugin和hasPlugin分别是查找插件获得插件信息以及判断插件是否被应用，而withPlugin是表示某个插件被应用的时候执行相应的Action回调，其中方法中参数无论是id还是pluginId都是指插件的id。
Plugin
Structure
Plugin通常是作为Library进行开发，工程结构如下：
-
Gradle Plugin需要在resources--METAINF--gradle-plugins目录下面定义一个plugin_id.properties文件，文件里面内容就是具体的Plugin实现类的全路径。为什么要这样做呢，其实这是借鉴了Java的SPI(Service Provider Interface)机制，使得整个Plugin的加载更加优雅和解耦。 - 另外，当插件用
groovy和kotlin进行混合编码的时候，需要注意的是groovy和kotlin的源码是由各自的编译task进行编译的，因此在相互引用的时候会出现编译找不到类，所以需要在对应的CompileXXTask中的classPath添加编译后的类路径，由于kotlin是在groovy之前编译的，所以CompileGroovyTask可以添加kotlin的类路径，反之则不行，这意味着只能groovy引用kotlin的代码。 - 最后
Plugin开发常规有两种方式，分别是通过在工程里面定义buildSrc module或者常规的module来进行开发。
至于具体的开发细节，这里就不再细讲了，因为就是在
void apply(Project target){
//todo something
...
}
中开发自己的编译逻辑，具体API可以自行查阅官方文档。
Module
这里单独说一下Plugin开发的Module，绝大多数介绍基本就是说可以用buildSrc或者独立module的方式进行开发，但是两者有什么优缺点，如何进行选择，都没有给出相应的解释，因此在这里做一个简单的总结。
这两种方式具体表现是在：
-
buildSrc module是在整个Project进行configuration前会对这个module进行编译并且把编译后的jar自动加入到Project的classpath中，直接就可以进行调试。 - 独立
module的方式相对会麻烦一点，每次需要通过uploadArchives将jar发布到本地，然后手动在顶级工程的build.gradle将jar依赖添加到classpath中。
那么，既然第二种调试方式会更加繁琐，是不是第一种方式最好了。其实也不尽然，这两种方式有着各自的优缺点。
- 第一种方式因为它是在
Project进行configuration前就会进行单独的编译，那么就意味着它是一个独立的module，不能去依赖工程里面其他的module，它在单独进行编译的时候其他的module是找不到的，也就意味着它是拿不到Project里面所有的gradle编译信息的。 - 第二种作为独立的
module进行开发的方式，则可以跟正常的module开发一样引用工程里面的其他module。
所以，这两种方式各有取舍，需要按照自己的需求来进行选择。
Extension
Plugin开发肯定也会需要用到外界的数据，那怎么得到所要的数据呢？前面提到org.gradle.api.Plugin接口的void apply(T target)方法，对应的泛型对象在gradle中分别是Project和 Settings，那么可以通过Property进行数据的传递。那还有没有更加优雅的方式呢？没错，那就是Extension。
ExtensionContainer
通过Project的getExtensions方法获得ExtensionContainer对象，然后通过create方法来创建并且添加对应的Extension。
<T> T create(String name, Class<T> type, Object... constructionArguments);
方法对应的参数分别是extension的名称、用来装载的class以及构造对应实例的时候所需要传入的参数。
另外ExtensionContainer还有findByType、getByType等方法，可以自行查阅org.gradle.api.plugins.ExtensionContainer。
那么，标准的extension创建的方法如下：
- 定义一个类似于Bean的
Extension的装载类
class SampleExtension{
String id = ""
}
- 插件中创建对应的
Extension
void apply(Project target){
target.extensions.create("sample", Sample)
}
- 在对应
apply Plugin的build.gradle中传值
sample{
id = "smapleExtension_test"
}
- 插件中读取
extension
project.afterEvaluate{
SampleExtension sampleExtension = project.sample
//打印出来就是传值smapleExtension_test
println "sampleExtension.id-----${sampleExtension.id}"
}
有几个关键点需要注意下：
-
afterEvaluate，也就是project完成整个配置评估后，才会把配置的值装载到对应的extension类中，因此这个时候才能拿到对的值。 - 在
build.gradle进行extension传值，闭包名称必须和create方法中传入的name保持一致。 - 获取对应的
extension对象，直接通过project.sample也就是闭包名称即可。
另外，我们也可以通过相同的方式在自己的插件中去获取别的插件对应的extension。例如：
project.android.registerTransform("...")
这是Plugin Transform开发中必须要用到的，就是通过project.android拿到对应的extension类，这里就是com.android.build.gradle.BaseExtension对象，然后调用其public void registerTransform(@NonNull Transform transform, Object... dependencies)方法。
Andoird Extension
在Android开发中，用到最多就是Gradle提供出来的三个插件:
-
com.android.build.gradle.AppPlugin，对应app module中的apply plugin: 'com.android.application'。 -
com.android.build.gradle.LibraryPlugin，对应aar module中的apply plugin: 'com.android.library'。 -
org.gradle.api.plugins.JavaPlugin，对应java module中的apply plugin: 'java'。
当然，如果用到了kotlin，那么还需要用到对应的kotlin plugin。
这里，着重说一下AppPlugin以及LibraryPlugin这两个插件，这两个插件对应的extension分别是com.android.build.gradle.AppExtension以及com.android.build.gradle.LibraryExtension，继承于com.android.build.gradle.TestedExtension。
TestedExtension是用于android的test module，继承于所有android插件的基础extension也就是com.android.build.gradle.BaseExtension。
里面包含的主要方法有：
public void compileSdkVersion(int apiLevel)
public void buildToolsVersion(String version)
public void defaultConfig(Action<DefaultConfig> action)
public void buildTypes(Action<? super NamedDomainObjectContainer<BuildType>> action)
public void compileOptions(Action<CompileOptions> action)
...
public void sourceSets(Action<NamedDomainObjectContainer<AndroidSourceSet>> action)
是不是感觉很熟悉，再来看下常见的build.gradle中的配置：
android {
compileSdkVersion "${compile_sdk_version}" as Integer
buildToolsVersion "${build_tools_version}"
defaultConfig {
minSdkVersion "${min_sdk_version}" as Integer
targetSdkVersion "${target_sdk_version}" as Integer
versionCode Integer.valueOf(System.env.BUILD_NUMBER ?: "1")
versionName "${version}"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
sourceSets {
main {
java {
include '**/*.java'
include '**/*.kt'
}
}
}
}
应该发现了android闭包里面所有的配置选项对应的就是上述extension中的方法，compileSdkVersion、buildToolsVersion、defaultConfig、compileOptions以及sourceSets都是一一对应的。
另外defaultConfig闭包配置选项对应的是com.android.build.gradle.internal.dsl.DefaultConfig类属性，compileOptions闭包配置对应的就是com.android.build.gradle.internal.CompileOptions，其他以此类推。
由此得知，android{}闭包里面有什么配置选项，直接查看对应的AppExtension和LibraryExtension中的方法和属性就好了，其他插件也是如此。
尾结
至此，Plugin的开发介绍就到此为止了，在这章介绍了Plugin的由来、开发module差异以及最重要的Extension。好了，下章来了解下Gradle中另外一个重要的部分publishing。
