内容简介:capt 全称 Class Annotation Processor Tool, 是笔者开源的一个 Android 平台的字节码的注解处理工具,详情请了解大家好,本篇会为大家介绍 capt 是如何紧密与 Android Gradle Plugin 协同工作的。capt 自身是 Gradle 的一个插件,同时与 Android Gradle Plugin 是密切关联的,体现在以下几个方面。Variant 是 Android Gradle Plugin 中一个很重要的概念,每个 Variant 均会对应一组构建
capt 全称 Class Annotation Processor Tool, 是笔者开源的一个 Android 平台的字节码的注解处理工具,详情请了解 https://github.com/CoffeePartner/capt 。
大家好,本篇会为大家介绍 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 点星!
感谢大家的阅读,欢迎关注笔者公众号。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。