capt 与 Android Gradle Plugin

capt 全称 Class Annotation Processor Tool, 是笔者开源的一个 Android 平台的字节码的注解处理工具，详情请了解 github.com/CoffeePartn…。

你们好，本篇会为你们介绍 capt 是如何紧密与 Android Gradle Plugin 协同工做的。capt 自身是 Gradle 的一个插件，同时与 Android Gradle Plugin 是密切关联的,体如今如下几个方面。

Variant 绑定

Variant 是 Android Gradle Plugin 中一个很重要的概念，每一个 Variant 均会对应一组构建产物（APK、AAR 等）。在 capt 中，咱们会对 Android 中每一个 Application / Libray / AndroidTest Variant 建立一个一一对应的 VariantScope 对象。

DomainObjectCollection<? extends BaseVariant> collection = extension instanceof AppExtension ?
        ((AppExtension) extension).getApplicationVariants()
        : ((LibraryExtension) extension).getLibraryVariants();

collection.all(v -> {
    VariantScope variant = factory.create(v);
    dependencies.put(v.getName(), variant);

    TestVariant t;
    if (v instanceof ApplicationVariant) {
        t = ((ApplicationVariant) v).getTestVariant();
    } else {
        t = ((LibraryVariant) v).getTestVariant();
    }

    if (t != null) {
        VariantScope testVariant = factory.create(t, variant);
        dependencies.put(t.getName(), testVariant);
    }
});
复制代码

SourceSet

Android 中每一个 Variant 会依赖一至多个 SourceSet，每建立一个 SourceSet，capt 会自动建立一个与该 SourceSet 同名的 Gradle Configuration，简化的代码以下：

ConfigurationContainer configurations = project.getConfigurations();
extension.getSourceSets().all(androidSourceSet -> {
    if (!androidSourceSet.getName().startsWith(TEST)) { // don't support unit test
        Configuration configuration = configurations.maybeCreate(sourceSetToConfigurationName(androidSourceSet.getName()));
        ...
    }
});
复制代码

这样不管 Android 中建立什么样的 BuildType / ProductFlavor ，capt 均会自动建立对应的 Configuration。可是要注意，这里的 Configuration 是不能够被 resolve 的，只是用来管理依赖。随后咱们会在 VariantScope 中会建立对应 Variant 的 Configuration 并继承依赖的 SourceSet 对应的 Configuration。

VariantScope

而每一个 VariantScope 会最终建立一个 Configuration 并收集和继承这个 Variant 所依赖的全部 SourceSet 对应的 Configuration：

@Override
public VariantScope create(BaseVariant v) {
    ConfigurationContainer configurations = project.getConfigurations();

    // the actual configuration
    Configuration configuration = getByVariant(v.getName());

    ...

    v.getSourceSets().stream()
            .map(SourceProvider::getName)
            .map(VariantManager::sourceSetToConfigurationName)
            .map(configurations::getByName)
            .forEach(configuration::extendsFrom);

    return new VariantScope(v.getName(), configuration, global);
}
复制代码

这样咱们便完成了对 Android Variant 的绑定，这一整套的流程基本和 Android Gradle Plugin 内部的 Configuration 很类似，例如 annotationProcessor，有兴趣的同窗能够看一下 Android Plugin 中 VariantDependencies 这个类。

Transform API

Transform API 从 Android Plugin 1.5 版本开放，他给予开发者们在编译打包时，参与修改字节码的能力。他的工做方式很简单，在打包时会把插件所须要的类以文件的形式传递过来，并由插件生成新的结果交还给他。这样就造成了一个流式的结构，数据流不断的消费、再生产，一层层的传递直到最终结束。

这里我简单介绍一下 Transform 的 API。

ContentType

Android 会将资源以 ContentType 这个接口类来分类，全部的类别有不少种，如 DEX、NATIVE_LIBS、DATA_BINDING、CLASSES 等等，可是对外开放的 API 只有两种：

enum DefaultContentType implements ContentType {
    /** * The content is compiled Java code. This can be in a Jar file or in a folder. If * in a folder, it is expected to in sub-folders matching package names. */
    CLASSES(0x01),

    /** The content is standard Java resources. */
    RESOURCES(0x02);
}
复制代码

这里 capt 仅须要 CLASSES 这一种。

Scope

Scope 是 Android 对资源来源的分类：

enum Scope implements ScopeType {
    /** Only the project content */
    PROJECT(0x01),
    /** Only the sub-projects. */
    SUB_PROJECTS(0x04),
    /** Only the external libraries */
    EXTERNAL_LIBRARIES(0x10),
    /** Code that is being tested by the current variant, including dependencies */
    TESTED_CODE(0x20),
    /** Local or remote dependencies that are provided-only */
    PROVIDED_ONLY(0x40),
}
复制代码

这里 capt 依赖的全部的 Scope，可是要注意的是，只有最上面三种是能够消费的，下面两种只能引用：

@Override
public Set<? super QualifiedContent.Scope> getScopes() {
    return variantManager.isApplication() ? TransformManager.SCOPE_FULL_PROJECT : TransformManager.PROJECT_ONLY;
}

/** * Needs other scopes to compute frame */
@Override
public Set<? super QualifiedContent.Scope> getReferencedScopes() {
    return Sets.difference(ALL, getScopes());
}
复制代码

Library 只容许消费 PROJECT_ONLY，这既是 Android 的限制，也是符合直觉的。咱们对 Library 打 AAR 的时候，只能修改自身的类或者资源。

此外咱们不能消费的类型均会划为引用，以便 ASM 计算栈帧信息。

transform

transform 方法就正式执行消费生产流程了。这里 capt 会调用对应的 VariantScope 的 doTransform 方法，每一个 Variant 的转换流程均独立，工做目录独立，资源独立，对象独立，彻底支持多 Variant 并发执行。这里咱们还有个小优化：

project.afterEvaluate(p -> p.getTasks()
        .withType(TransformTask.class, t -> {
            if (t.getTransform().getName().equals(NAME)) {
                t.dependsOn(getByVariant(t.getVariantName()));

                // register output
                t.getOutputs().dir(getVariantScope(t.getVariantName()).getRoot());
            }
        }));
复制代码

每一个 Variant 对应的 TransformTask 均会对应一个惟一的 capt 工做目录，为了防止在构建后被修改，咱们将其注册到 outputs 中。

总结

以上即是 capt 如何巧妙的利用了 Android Plugin 的 API，达成了咱们的目标。固然，更加核心的执行流程实际上是在 VariantScope.doTransform 中，因为篇幅问题就不展开了，下次再详细的介绍。

若是以为 capt 还不错，欢迎到本篇开头的 GitHub 地址为 capt 点星！ 感谢你们的阅读，欢迎关注笔者公众号。