每日一问 | apply plugin: 'com.android.application' 背后发生了什么？

apply plugin: 'com.android.application'背后的原理是？

这个问题可能问的地方有两个：

1. 字符串com.android.application所对应的Plugin类在apply时具体做了哪些操作？

2. 这个apply方法是如何通过后面的字符串找到对应的Plugin类的呢？

先来看第二问：

学习过Gradle相关知识的同学会知道，apply plugin: 'com.android.application这句代码其实就是把一个Map（key="plugin"，value="com.android.application"）对象传进ProjectScript的apply(Map options)方法里而已。

然后这个Map对象的value（现在是"com.android.application"这个字符串），会作为PluginId传到DefaultPluginManager的apply方法中，在这里，DefaultPluginManager又会通过DefaultPluginRegistry的lookup方法来初始化一个PluginImplementation对象，这个对象间接携带了前面说到的Map对象的value所对应的Plugin类，接着，这个Plugin类会在DefaultPluginManager的addPlugin方法中通过反射实例化，实例化了之后，最终会调用它的apply方法，并把Project对象传进去（注意！现在这个的apply方法，就是第一问所讲的apply方法，所以要回答第一问，可以从这里开始看起）。

重点来了：DefaultPluginRegistry的lookup方法是怎么知道"com.android.application"对应的是哪个Plugin类呢？

其实是这样的，它会先获取成员变量classLoaderScope所持有的ClassLoader实例，然后通过这个ClassLoader的getResource方法来查找 META-INF/gradle-plugins/ 目录下的 com.android.application.properties 文件！（当然了，如果是apply plugin: 'com.android.library'那就是查找com.android.library.properties文件）

如果有找到的话，会取出里面的配置信息：implementation-class=插件包名.插件类名，玩过自定义Gradle插件的同学应该对这个不陌生，这里所指定的类，就是自己实现的那个Plugin类。

打开gradle路径/caches/modules-2/files-2.1/com.android.tools.build/gradle/gradle版本号/xxxx文件夹下的jar包，并定位到 META-INF/gradle-plugins/目录下会看到很多properties文件，上面说的 com.android.application.properties 也在其中，打开一看，你会发现implementation-class指向的是com.android.build.gradle.AppPlugin，所以com.android.application对应的Plugin类就是这个AppPlugin了，也就是apply plugin: 'com.android.application这行代码，最终会进入到AppPlugin的apply方法中。

如果你现在看上面这段描述看得一头雾水，不要慌，这不是你的问题，是我的问题，明天加上源码分析就很容易明白了。

小结：

build.gradle文件中的apply plugin: 'xxx'，其实就是查找各个jar包中META-INF/gradle-plugins/目录下的xxx.properties文件，找到之后，会取出其implementation-class属性值并通过反射实例化这个属性值所指向的类对象，然后调用其apply方法。

源码分析：

来看看apply plugin: 'com.android.application这句代码被执行时发生了什么。

其实我们在研究像这种找不到源头，还有异步任务满天飞的代码，可以通过Debug来帮助我们快速了解具体执行流程。

不过，如果你直接在AS的Gradle窗口中，随便右键个Task然后选Debug：

你会发现打的断点根本不起作用，那应该怎么做呢？

找到一篇图文并茂的文章，我就不啰嗦了：AS Gradle文件Debug

但是，成功断点之后，新的问题又来了：

当你按下F7进入apply方法时，会发现根本定位不到相关代码，但Debug窗口是正常的：

其实就是AS没有加载Gradle源码的原因（注意这里说的Gradle源码并不是Android Gradle Plugin的源码，而是Gradle本身的源码），像这种情况我们就需要手动去引入了：

Ctrl + Alt + Shift + S打开Project Structure窗口，看一下当前项目使用的Gradle版本是多少（建议新建一个空项目来测试和学习）：

然后，打开你存放Gradle的目录，定位到 wrapper/dists/gradle-你的Gradle版本-all/xxxx/gradle-你的Gradle版本/src/ 目录下，在这里你会看到很多文件夹：

找到core和core-api，并分别把它们里面的org文件夹复制到你的测试项目java目录下。

再次启动Debug：

就能正确定位到对应代码啦~

最后需要做的就是，在build.gradle中添加上Android Gradle Plugin的依赖，因为等下我们还要看它里面的代码：

implementation 'com.android.tools.build:gradle:4.0.1'

版本号需要跟项目中所使用的版本一致。

好，现在开始源码分析：

从apply plugin: 'com.android.application断点进去，会来到ProjectScript的apply方法：

public abstract class ProjectScript extends PluginsAwareScript {

    @Override
    @SuppressWarnings("unchecked")
    public void apply(Map options) {
        getScriptTarget().apply(options);
    }
}

这里的getScriptTarget会返回DefaultProject对象，继承自抽象类AbstractPluginAware。

接着就是它的apply方法啦：

public abstract class AbstractPluginAware implements PluginAwareInternal {

    @Override
    public void apply(Map<String, ?> options) {
        DefaultObjectConfigurationAction action = createObjectConfigurationAction();
        ConfigureUtil.configureByMap(options, action);
        action.execute();
    }
}

可以看到创建了一个DefaultObjectConfigurationAction对象，并调用了它的execute方法：

public class DefaultObjectConfigurationAction implements ObjectConfigurationAction {

    private final Set<Runnable> actions = new LinkedHashSet<Runnable>();

    public void execute() {
        if (targets.isEmpty()) {
            to(defaultTarget);
        }

        for (Runnable action : actions) {
            action.run();
        }
    }
}

来到这里，会遍历一个装着Runnable的Set，并逐个调用run方法。

这些Runnable在哪里实现呢，继续F7：

public class DefaultObjectConfigurationAction implements ObjectConfigurationAction {

    @Override
    public ObjectConfigurationAction plugin(final String pluginId) {
        actions.add(new Runnable() {
            @Override
            public void run() {
                applyType(pluginId);
            }
        });
        return this;
    }

    private void applyType(String pluginId) {
        for (Object target : targets) {
            if (target instanceof PluginAware) {
                ((PluginAware) target).getPluginManager().apply(pluginId);
            } else {
                throw new UnsupportedOperationException(String.format("Cannot apply plugin with id '%s' to '%s' (class: %s) as it does not implement PluginAware", pluginId, target.toString(), target.getClass().getName()));
            }
        }
    }    
}

会发现原来是在plugin方法被调用时实现的匿名对象，里面会调用applyType方法，并将pluginId传了进去（这个pluginId就是字符串"com.android.application"）。

接着会逐个判断target是否PluginAware的实现类，如果是的话，会调用PluginManager的apply方法，并将pluginId传进去。

继续F7会发现getPluginManager方法返回的对象就是DefaultPluginManager：

public class DefaultPluginManager implements PluginManagerInternal {

    private final PluginRegistry pluginRegistry;

    @Override
    public void apply(String pluginId) {
        PluginImplementation<?> plugin = pluginRegistry.lookup(DefaultPluginId.unvalidated(pluginId));
        if (plugin == null) {
            throw new UnknownPluginException("Plugin with id '" + pluginId + "' not found.");
        }
        doApply(plugin);
    }    
}

重点来了，在DefaultPluginManager的apply方法里面，会通过pluginRegistry的lookup方法获取PluginImplementation对象，这个对象储存的相关信息，我们前天也讲过。

调用lookup方法之前，还会先通过DefaultPluginId的unvalidated方法创建一个DefaultPluginId对象：

public class DefaultPluginId implements PluginId {

    private final String value;

    public DefaultPluginId(String value) {
        this.value = value;
    }

    @Override
    public String toString() {
        return value;
    }

    public static PluginId unvalidated(String value) {
        return new DefaultPluginId(value);
    }    
}

这个DefaultPluginId类代码很少，一目了然。

我们接着看lookup方法：

public class DefaultPluginRegistry implements PluginRegistry {
    private final PluginRegistry parent;
    private final ClassLoaderScope classLoaderScope;
    private final LoadingCache<PluginIdLookupCacheKey, Optional<PluginImplementation<?>>> idMappings;

    @Nullable
    @Override
    public PluginImplementation<?> lookup(PluginId pluginId) {
        PluginImplementation lookup;
        if (parent != null) {
            lookup = parent.lookup(pluginId);
            if (lookup != null) {
                return lookup;
            }
        }

        return lookup(pluginId, classLoaderScope.getLocalClassLoader());
    }

    @Nullable
    private PluginImplementation<?> lookup(PluginId pluginId, ClassLoader classLoader) {
        PluginImplementation lookup;
        if (pluginId.getNamespace() == null) {
            PluginId qualified = pluginId.withNamespace(DefaultPluginManager.CORE_PLUGIN_NAMESPACE);
            lookup = uncheckedGet(idMappings, new PluginIdLookupCacheKey(qualified, classLoader)).orNull();
            if (lookup != null) {
                return lookup;
            }
        }

        return uncheckedGet(idMappings, new PluginIdLookupCacheKey(pluginId, classLoader)).orNull();
    }

    private static <K, V> V uncheckedGet(LoadingCache<K, V> cache, K key) {
        try {
            return cache.get(key);
        } catch (ExecutionException | UncheckedExecutionException e) {
            throw UncheckedException.throwAsUncheckedException(e.getCause());
        }
    }    
}

可以看出来这是一个递归方法，如果parent（父插件注册表）不为空的话，会优先通过parent的lookup方法来查找PluginImplementation对象，parent找不到才自己找。

那它是怎么找呢？

看中间的那个lookup方法，无论pluginId.getNamespace()是不是null，都会调用uncheckedGet方法，把idMappings和一个PluginIdLookupCacheKey对象传进去。

这个uncheckedGet方法很简单，只是直接调用传进来的idMappings的get方法。idMappings是LoadingCache的实例，看名字就知道这是一个缓存对象的工具类。在使用它之前，需要告诉它怎么去加载对象，看DefaultPluginRegistry的构造方法：

public class DefaultPluginRegistry implements PluginRegistry {
    private final PluginRegistry parent;
    private final ClassLoaderScope classLoaderScope;
    private final LoadingCache<PluginIdLookupCacheKey, Optional<PluginImplementation<?>>> idMappings;

    private DefaultPluginRegistry(PluginRegistry parent, final PluginInspector pluginInspector, ClassLoaderScope classLoaderScope) {
        this.parent = parent;
        this.pluginInspector = pluginInspector;
        this.classLoaderScope = classLoaderScope;
        this.classMappings = CacheBuilder.newBuilder().build(new PotentialPluginCacheLoader(pluginInspector));
        this.idMappings = CacheBuilder.newBuilder().build(new CacheLoader<PluginIdLookupCacheKey, Optional<PluginImplementation<?>>>() {
            @Override
            public Optional<PluginImplementation<?>> load(@SuppressWarnings("NullableProblems") PluginIdLookupCacheKey key) throws Exception {
                PluginId pluginId = key.getId();
                ClassLoader classLoader = key.getClassLoader();

                PluginDescriptorLocator locator = new ClassloaderBackedPluginDescriptorLocator(classLoader);

                PluginDescriptor pluginDescriptor = locator.findPluginDescriptor(pluginId.toString());
                if (pluginDescriptor == null) {
                    return Optional.absent();
                }

                String implClassName = pluginDescriptor.getImplementationClassName();
                if (!GUtil.isTrue(implClassName)) {
                    throw new InvalidPluginException(String.format("No implementation class specified for plugin '%s' in %s.", pluginId, pluginDescriptor));
                }

                final Class<?> implClass;
                try {
                    implClass = classLoader.loadClass(implClassName);
                } catch (ClassNotFoundException e) {
                    throw new InvalidPluginException(String.format(
                        "Could not find implementation class '%s' for plugin '%s' specified in %s.", implClassName, pluginId,
                        pluginDescriptor), e);
                }

                PotentialPlugin<?> potentialPlugin = pluginInspector.inspect(implClass);
                PluginImplementation<Object> withId = new RegistryAwarePluginImplementation(classLoader, pluginId, potentialPlugin);
                return Cast.uncheckedCast(Optional.of(withId));
            }
        });
    }
}

看到了吧，idMappings是通过CacheBuilder来创建的，在创建时重写了CacheLoader的load方法，我们重点就看这个方法，因为等下idMappings找不到对象时会调用这个方法获取新实例。

它依次从参数key中获取了pluginId和classLoader实例，然后创建了一个ClassloaderBackedPluginDescriptorLocator对象，把classLoader传了进去；接着又调用了它的findPluginDescriptor方法，把pluginId的String传了进去。现在请看回上面的DefaultPluginId源码，它重写了toString，直接return了value，这个value就是 "com.android.application"字符串。

好，现在来看下它的findPluginDescriptor方法：

public class ClassloaderBackedPluginDescriptorLocator implements PluginDescriptorLocator {

    private final ClassLoader classLoader;

    public ClassloaderBackedPluginDescriptorLocator(ClassLoader classLoader) {
        this.classLoader = classLoader;
    }

    @Override
    public PluginDescriptor findPluginDescriptor(String pluginId) {
        URL resource = classLoader.getResource("META-INF/gradle-plugins/" + pluginId + ".properties");
        if (resource == null) {
            return null;
        } else {
            return new PluginDescriptor(resource);
        }
    }

}

！！对吧！就像前天说的那样，是通过ClassLoader来查找META-INF/gradle-plugins/目录下名为pluginId.properties的文件的。

如果从这个ClassLoader中找到了，就会创建一个PluginDescriptor对象并返回。

那现在看回刚刚的load方法，如果返回的PluginDescriptor对象不为空，就会调用getImplementationClassName方法：

public class PluginDescriptor {

    private final URL propertiesFileUrl;

    public PluginDescriptor(URL propertiesFileUrl) {
        this.propertiesFileUrl = propertiesFileUrl;
    }

    public String getImplementationClassName() {
        Properties properties = GUtil.loadProperties(propertiesFileUrl);
        return properties.getProperty("implementation-class");
    }

    public URL getPropertiesFileUrl() {
        return propertiesFileUrl;
    }

    @Override
    public String toString() {
        return propertiesFileUrl.toString();
    }
}

哈哈，就是前天说的那样，它会取出这个配置文件key为implementation-class的value（com.android.application.properties的implementation-class就是com.android.build.gradle.AppPlugin）。

接着看，取出类名之后就是loadClass获取目标插件的Class对象。最后是创建对应的PluginImplementation对象并返回。

好了，现在的lookup方法已经分析完毕，是时候返回到上面的DefaultPluginManager了，在DefaultPluginManager的apply方法中，通过lookup方法获取到PluginImplementation对象后会调用doApply方法：

public class DefaultPluginManager implements PluginManagerInternal {

    private void doApply(final PluginImplementation<?> plugin) {
        PluginId pluginId = plugin.getPluginId();
        final String pluginIdStr = pluginId == null ? null : pluginId.toString();
        final Class<?> pluginClass = plugin.asClass();
        ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
        ......
        Thread.currentThread().setContextClassLoader(pluginClass.getClassLoader());
        if (plugin.getType().equals(PotentialPlugin.Type.UNKNOWN)) {
            throw new InvalidPluginException("'" + pluginClass.getName() + "' is neither a plugin or a rule source and cannot be applied.");
        } else {
            final Runnable adder = addPluginInternal(plugin);
            if (adder != null) {
                userCodeApplicationContext.apply(new Action<UserCodeApplicationId>() {
                    @Override
                    public void execute(UserCodeApplicationId userCodeApplicationId) {
                        buildOperationExecutor.run(new AddPluginBuildOperation(adder, plugin, pluginIdStr, pluginClass, userCodeApplicationId));
                    }
                });
            }
        }
        ......
    }    
}

这里看似是异步任务，我们把目光放在下面的execute方法，即buildOperationExecutor.run那句，在这里打断点后F9。

然后会来到这里：

public class DefaultBuildOperationExecutor implements BuildOperationExecutor, Stoppable, ParallelismConfigurationListener {

    @Override
    public void run(RunnableBuildOperation buildOperation) {
        try {
            execute(buildOperation, runnableBuildOperationWorker, getCurrentBuildOperation());
        } finally {
            maybeStopUnmanagedThreadOperation();
        }
    }
}

在这里也直接进入execute方法：

public class DefaultBuildOperationExecutor implements BuildOperationExecutor, Stoppable, ParallelismConfigurationListener {

    private <O extends BuildOperation> void execute(final O buildOperation, final BuildOperationWorker<O> worker, @Nullable BuildOperationState defaultParent) {
        BuildOperationDescriptor.Builder descriptorBuilder = buildOperation.description();
        execute(descriptorBuilder, defaultParent, new BuildOperationExecution<BuildOperation>() {
            @Override
            public BuildOperation execute(BuildOperationDescriptor descriptor, DefaultBuildOperationContext context, BuildOperationExecutionListener listener) {
                Throwable failure = null;
                try {
                    listener.start();
                    try {
                        worker.execute(buildOperation, context);
                    } catch (Throwable t) {
                        context.thrown(t);
                        failure = t;
                    }
                    listener.stop();
                    if (failure != null) {
                        throw UncheckedException.throwAsUncheckedException(failure, true);
                    }
                    return buildOperation;
                } finally {
                    listener.close();
                }
            }
        });
    }    
}

又是异步，断点worker.execute(buildOperation, context);这一行，F9：

public class DefaultBuildOperationExecutor implements BuildOperationExecutor, Stoppable, ParallelismConfigurationListener {

    private static class RunnableBuildOperationWorker implements BuildOperationWorker<RunnableBuildOperation> {
        @Override
        public String getDisplayName() {
            return "runnable build operation";
        }

        @Override
        public void execute(RunnableBuildOperation buildOperation, BuildOperationContext context) {
            buildOperation.run(context);
        }
    }
}

buildOperation.run(context);，F7：

public class DefaultPluginManager implements PluginManagerInternal {

    private class AddPluginBuildOperation implements RunnableBuildOperation {

        @Override
        public void run(BuildOperationContext context) {
            addPlugin(adder, plugin, pluginId, pluginClass);
            context.setResult(OPERATION_RESULT);
        }
    }

    private void addPlugin(Runnable adder, PluginImplementation<?> plugin, String pluginId, Class<?> pluginClass) {
        boolean imperative = plugin.isImperative();
        if (imperative) {
            Plugin<?> pluginInstance = producePluginInstance(pluginClass);

            if (plugin.isHasRules()) {
                target.applyImperativeRulesHybrid(pluginId, pluginInstance);
            } else {
                target.applyImperative(pluginId, pluginInstance);
            }

            // Important not to add until after it has been applied as there can be
            // plugins.withType() callbacks waiting to build on what the plugin did
            instances.put(pluginClass, pluginInstance);
            pluginContainer.pluginAdded(pluginInstance);
        } else {
            target.applyRules(pluginId, pluginClass);
        }

        adder.run();
    }    
}

到了到了，看addPlugin方法，它会先通过producePluginInstance方法获取Plugin对象实例，来看一下producePluginInstance方法里面发生了什么：

public class DefaultPluginManager implements PluginManagerInternal {

    private Plugin<?> producePluginInstance(Class<?> pluginClass) {
        // This insanity is needed for the case where someone calls pluginContainer.add(new SomePlugin())
        // That is, the plugin container has the instance that we want, but we don't think (we can't know) it has been applied
        Object instance = findInstance(pluginClass, pluginContainer);
        if (instance == null) {
            instance = instantiatePlugin(pluginClass);
        }

        return Cast.uncheckedCast(instance);
    }

    private <T> T findInstance(Class<T> clazz, Iterable<?> instances) {
        for (Object instance : instances) {
            if (instance.getClass().equals(clazz)) {
                return clazz.cast(instance);
            }
        }

        return null;
    }

    private <T> T instantiatePlugin(Class<T> type) {
        try {
            return instantiator.newInstance(type);
        } catch (ObjectInstantiationException e) {
            throw new PluginInstantiationException(String.format("Could not create plugin of type '%s'.", type.getSimpleName()), e.getCause());
        }
    }

}

emmmm，如果findInstance方法找不到现有的实例，就会调用instantiatePlugin方法（参数type其实就是刚刚从com.android.application.properties中取出来的Class对象），在这方法内会通过反射创建type的实例！！！也就是com.android.build.gradle.AppPlugin对象！

好，回到上面的addPlugin方法，在获取到目标Plugin实例之后，会调用它的applyImperative方法，看看：

public class RuleBasedPluginTarget implements PluginTarget {

    @Override
    public void applyImperative(@Nullable String pluginId, Plugin<?> plugin) {
        imperativeTarget.applyImperative(pluginId, plugin);
    }    
}

F7：

public class ImperativeOnlyPluginTarget<T extends PluginAwareInternal> implements PluginTarget {
    @Override
    public void applyImperative(@Nullable String pluginId, Plugin<?> plugin) {
        // TODO validate that the plugin accepts this kind of argument
        Plugin<T> cast = uncheckedCast(plugin);
        cast.apply(target);
    }
}

嘿嘿，看到了吧，在ImperativeOnlyPluginTarget的applyImperative方法里，调用了Plugin的apply方法。

那下一步自然就到了AppPlugin里了：

class AppPlugin: BasePlugin() {
    override fun apply(project: Project) {
        super.apply(project)

        project.apply(INTERNAL_PLUGIN_ID)
    }
}

private val INTERNAL_PLUGIN_ID = mapOf("plugin" to "com.android.internal.application")

它会先调用父类的apply：

open class BasePlugin: Plugin<Project> {
    private lateinit var project: Project

    override fun apply(project: Project) {
        this.project = project

        project.apply(VERSION_CHECK_PLUGIN_ID)
    }
}

internal val VERSION_CHECK_PLUGIN_ID = mapOf("plugin" to "com.android.internal.version-check")

咦，父类在给project赋值之后，也apply了一个插件，这个插件id叫com.android.internal.version-check。

查看com.android.internal.version-check.properties会发现，它指向的是这个类：

class VersionCheckPlugin: Plugin<Project> {

    override fun apply(project: Project) {
        val projectOptions = ProjectOptions(project)
        val logger = project.logger

        val currentVersion = project.gradle.gradleVersion
        if (GRADLE_MIN_VERSION > currentVersion) {
            val file = File("gradle${separator}wrapper${separator}gradle-wrapper.properties")

            val errorMessage = String.format(
                "Minimum supported Gradle version is $GRADLE_MIN_VERSION. Current version is $currentVersion. "
                        + "If using the gradle wrapper, try editing the distributionUrl in ${file.absolutePath} "
                        + "to gradle-$GRADLE_MIN_VERSION-all.zip")

            if (projectOptions.get(BooleanOption.VERSION_CHECK_OVERRIDE_PROPERTY)) {
                logger.warn(errorMessage)
                logger.warn("As ${BooleanOption.VERSION_CHECK_OVERRIDE_PROPERTY.propertyName} is set, continuing anyway.")
            } else {
                throw RuntimeException(errorMessage)
            }
        }
    }
}

跟它的名字一样，它apply方法里面做的事情也是检测一下Gradle版本而已。

好，现在回到刚刚的AppPlugin方法，发现它也apply了一个id为com.android.internal.application的插件，注意这次是com.android.internal.application，比build.gradle中的com.android.application多了个internal。

同样地，找到同名properties文件，会发现上面写着是com.android.build.gradle.internal.plugins.AppPlugin，这次的AppPlugin是用java实现的，它间接继承自com.android.build.gradle.internal.plugins.BasePlugin并且没有重写apply方法，所以当它的apply被调用时，其实是去到了BasePlugin的apply方法：

public abstract class BasePlugin implements Plugin<Project>, ToolingRegistryProvider {

        @Override
    public final void apply(@NonNull Project project) {
        CrashReporting.runAction(
                () -> {
                    basePluginApply(project);
                    pluginSpecificApply(project);
                });
    }
}

不过从这里开始，网上也有很多相关的文章了，我就不啰嗦了，留给同学们自己探索吧。

总结：

apply plugin: 'com.android.application'这句代码会从com.android.application.properties中找到AppPlugin，在AppPlugin的apply方法里会先调用父类的apply，而父类又会加载版本检测的Plugin，最后，在AppPlugin中还会调用到com.android.build.gradle.internal.plugins.BasePlugin的apply方法......

emmmm，看似简单的一行代码，背后所做的工作远超出我们的预料啊。

睡觉

对了，建议大家一边Debug，一边看分析，这样理解更深刻。

根据gradle plugin的原理，每个plguin都是一个Groovy 的Plugin

跟踪了下Android Gradle Plugin 发现最后调用的就是

/** Gradle plugin class for 'application' projects, applied on the base application module */
public class AppPlugin extends AbstractAppPlugin {

}

所以原理就是调用了下AppPlugin 然后根据开发定义的AppExtension，执行特定的gradle任务

Android 项目是基于gradle 编译构建的。

apply plugin: 'com.android.application' 属于gradle脚本的知识。具体可以学习下gradle 简单的知识。

gradle的脚本以.gradle结尾。一个gradle文件，就是一个project，一个project包含多个task。

gradle的开发语言类似java。很容易上手。

apply plugin: 'com.android.application"。 里面封装了很多的task 针对android的。可以通过gradle tasks 查看。

不仅仅android，在java web项目中。也有 apply plugin "java" 等申明。

apply plugin: 'com.android.library”是针对library的插件。具体可以自己定义一个插件试试 很easy的