前言
上篇文章《總聽(tīng)說(shuō)AGP，它到底做了什么？》和大家分析了 AGP(Android Gradle Plugin) 做了哪些事，了解到 AGP 就是為打包這個(gè)過(guò)程服務(wù)的。
那么，本篇文章就和大家聊一聊其中的 Transform，解決一下為什么在 AGP 3.x.x 的版本可以通過(guò)反射獲取的 transformClassesWithDexBuilderForXXX Task 在 4.0.0 的版本就不靈了？
源碼走起！
一、Transform的流程
讀本篇文章以前，相信同學(xué)們已經(jīng)具備 Transform 的使用基礎(chǔ)。
相信很多人都看過(guò)這張圖：
正如上圖中展示的，我么可以看到：
- 在一個(gè)項(xiàng)目中，我們可能既會(huì)有自定義的
Transform，也會(huì)有系統(tǒng)的Transform - 在處理過(guò)程中，每一個(gè) Transform 的接受流都是接收到上一個(gè) Transform 的輸出流，原始的文件流會(huì)經(jīng)過(guò)很多 Transform 的處理
二、Transform源碼分析
既然我們已經(jīng)了解了整體的流程，再來(lái)看一下其中的細(xì)節(jié)吧。
第一步 Transform的起點(diǎn)
我們都知道，使用 Transform 的目的，是為了修改其中的字節(jié)碼，那么，這些 Class 文件是哪里來(lái)的呢？
直接打開(kāi) AGP 的源碼，直接跳到創(chuàng)建編譯 Task 的時(shí)候，這個(gè)方法發(fā)生在 AGP 創(chuàng)建跟 Variant 相關(guān)的 Task 的時(shí)候，在 AbstractAppTaskManager 里：
private void createCompileTask(@NonNull VariantPropertiesImpl variantProperties) {
ApkCreationConfig apkCreationConfig = (ApkCreationConfig) variantProperties;
// 執(zhí)行javac
TaskProvider<? extends JavaCompile> javacTask = createJavacTask(variantProperties);
// 添加Class輸入流
addJavacClassesStream(variantProperties);
setJavaCompilerTask(javacTask, variantProperties);
// 執(zhí)行transform和dex相關(guān)的任務(wù)
createPostCompilationTasks(apkCreationConfig);
}
雖然只有幾個(gè)方法，但是每個(gè)方法的作用還挺大，先看 javac。
第二步 執(zhí)行javac
大家對(duì) javac 的命令肯定很熟悉，它可以將 .java 文件轉(zhuǎn)化成 .class 文件。這個(gè)方法確實(shí)也是這樣：
public TaskProvider<? extends JavaCompile> createJavacTask(
@NonNull ComponentPropertiesImpl componentProperties) {
// Java預(yù)編譯任務(wù)，看了一下，主要是處理Java注解
taskFactory.register(new JavaPreCompileTask.CreationAction(componentProperties));
// Java編譯任務(wù)
final TaskProvider<? extends JavaCompile> javacTask =
taskFactory.register(new JavaCompileCreationAction(componentProperties));
postJavacCreation(componentProperties);
return javacTask;
}
它的方法注釋：
Creates the task for creating *.class files using javac. These tasks are created regardless of whether Jack is used or not, but assemble will not depend on them if it is. They are always used when running unit tests.
很明顯，就是為了創(chuàng)建 .class 文件。
這一步中，最重要的一步就是注冊(cè)了一個(gè)名叫 JavaCompile 的任務(wù)，也就是將 Java 文件和 Java 注解轉(zhuǎn)變成 .class 的 Task。
JavaCompile 的 Task 的代碼比較繞，直接跟大家說(shuō)結(jié)果了，最終是調(diào)用 JDK 下面的 JavaCompiler 類，動(dòng)態(tài)將 .java 轉(zhuǎn)化成 .class 文件。
當(dāng)然，不僅僅只有 .class 文件，還有其他的諸如 .kt 和 .jar 等，都需要特定的 Task，才能轉(zhuǎn)化成我們需要的輸入源。
第三步 建立原始的輸入流
回到第一步，進(jìn)入 addJavacClassesStream 方法：
protected void addJavacClassesStream(@NonNull ComponentPropertiesImpl componentProperties) {
// create separate streams for the output of JAVAC and for the pre/post javac
// bytecode hooks
TransformManager transformManager = componentProperties.getTransformManager();
boolean needsJavaResStreams =
componentProperties.getVariantScope().getNeedsJavaResStreams();
transformManager.addStream(
OriginalStream.builder(project, "javac-output")
// Need both classes and resources because some annotation
// processors generate resources
.addContentTypes(
needsJavaResStreams
? TransformManager.CONTENT_JARS
: ImmutableSet.of(DefaultContentType.CLASSES))
.addScope(Scope.PROJECT)
.setFileCollection(project.getLayout().files(javaOutputs))
.build());
BaseVariantData variantData = componentProperties.getVariantData();
transformManager.addStream(
OriginalStream.builder(project, "pre-javac-generated-bytecode")
.addContentTypes(
needsJavaResStreams
? TransformManager.CONTENT_JARS
: ImmutableSet.of(DefaultContentType.CLASSES))
.addScope(Scope.PROJECT)
.setFileCollection(variantData.getAllPreJavacGeneratedBytecode())
.build());
transformManager.addStream(
OriginalStream.builder(project, "post-javac-generated-bytecode")
.addContentTypes(
needsJavaResStreams
? TransformManager.CONTENT_JARS
: ImmutableSet.of(DefaultContentType.CLASSES))
.addScope(Scope.PROJECT)
.setFileCollection(variantData.getAllPostJavacGeneratedBytecode())
.build());
}
這個(gè) transformManager 就是處理 Transform 的，它在建立第一個(gè) Transform 的原始數(shù)據(jù)流。
細(xì)心的同學(xué)可能發(fā)現(xiàn)了，第一個(gè)數(shù)據(jù)流的 contentType 至少也是 DefaultContentType.CLASSES，scope 是 Scope.PROJECT，自定義過(guò) Transform 的同學(xué)肯定知道，這樣設(shè)置我們自定義的 Transform 能夠接收到原始數(shù)據(jù)流。
第四步 創(chuàng)建編譯后的任務(wù)
回到第一步中的 createPostCompilationTasks 方法，它用來(lái)創(chuàng)建編譯后的任務(wù)：
public void createPostCompilationTasks(@NonNull ApkCreationConfig creationConfig) {
//...
TransformManager transformManager = componentProperties.getTransformManager();
// ...
// java8脫糖
maybeCreateDesugarTask(
componentProperties,
componentProperties.getMinSdkVersion(),
transformManager,
isTestCoverageEnabled);
BaseExtension extension = componentProperties.getGlobalScope().getExtension();
// Merge Java Resources.
createMergeJavaResTask(componentProperties);
// ----- External Transforms -----
// apply all the external transforms.
List<Transform> customTransforms = extension.getTransforms();
List<List<Object>> customTransformsDependencies = extension.getTransformsDependencies();
boolean registeredExternalTransform = false;
for (int i = 0, count = customTransforms.size(); i < count; i++) {
Transform transform = customTransforms.get(i);
List<Object> deps = customTransformsDependencies.get(i);
registeredExternalTransform |=
transformManager
.addTransform(
taskFactory,
componentProperties,
transform,
null,
task -> {
if (!deps.isEmpty()) {
task.dependsOn(deps);
}
},
taskProvider -> {
// if the task is a no-op then we make assemble task depend on it.
if (transform.getScopes().isEmpty()) {
TaskFactoryUtils.dependsOn(
componentProperties
.getTaskContainer()
.getAssembleTask(),
taskProvider);
}
})
.isPresent();
}
// Add a task to create merged runtime classes if this is a dynamic-feature,
// or a base module consuming feature jars. Merged runtime classes are needed if code
// minification is enabled in a project with features or dynamic-features.
if (componentProperties.getVariantType().isDynamicFeature()
|| variantScope.consumesFeatureJars()) {
taskFactory.register(new MergeClassesTask.CreationAction(componentProperties));
}
// ----- Minify next -----
// 混淆
// ----- Multi-Dex支持...
// 創(chuàng)建 dex
createDexTasks(
creationConfig, componentProperties, dexingType, registeredExternalTransform);
// ... 資源壓縮等
}
在進(jìn)行 Transform 之前，它還會(huì)進(jìn)行一些 java8 的脫糖以及合并 java 資源的 Task，這些都是會(huì)被添加到原始的數(shù)據(jù)流中。
第五步 為T(mén)ransfrom創(chuàng)建Task
首先，我們得明白，每一種 Transform 其實(shí)有兩種類型：
- 消費(fèi)型：需要將數(shù)據(jù)源輸出給下一個(gè) Transform
- 引用型：只需要讀取，不需要輸出
接下來(lái)就到了我們關(guān)心的處理 Transform 的邏輯了。
從上面的方法我們可以看出，系統(tǒng)會(huì)為我們找到所有已經(jīng)在 BaseExtension 注冊(cè)的 Transform 并遍歷，使用 transformManager 通過(guò) addTransform 做處理:
public <T extends Transform> Optional<TaskProvider<TransformTask>> addTransform(
@NonNull TaskFactory taskFactory,
@NonNull ComponentPropertiesImpl componentProperties,
@NonNull T transform,
@Nullable PreConfigAction preConfigAction,
@Nullable TaskConfigAction<TransformTask> configAction,
@Nullable TaskProviderCallback<TransformTask> providerCallback) {
//... 省略
List<TransformStream> inputStreams = Lists.newArrayList();
String taskName = componentProperties.computeTaskName(getTaskNamePrefix(transform));
// get referenced-only streams
List<TransformStream> referencedStreams = grabReferencedStreams(transform);
// find input streams, and compute output streams for the transform.
IntermediateStream outputStream =
findTransformStreams(
transform,
componentProperties,
inputStreams,
taskName,
componentProperties.getGlobalScope().getBuildDir());
// ... 檢測(cè)工作
transforms.add(transform);
TaskConfigAction<TransformTask> wrappedConfigAction =
t -> {
t.getEnableGradleWorkers()
.set(
componentProperties
.getGlobalScope()
.getProjectOptions()
.get(BooleanOption.ENABLE_GRADLE_WORKERS));
if (configAction != null) {
configAction.configure(t);
}
};
// create the task...
return Optional.of(
taskFactory.register(
new TransformTask.CreationAction<>(
componentProperties.getName(),
taskName,
transform,
inputStreams,
referencedStreams,
outputStream,
recorder),
preConfigAction,
wrappedConfigAction,
providerCallback));
}
這里呢，先定義了一個(gè) taskName，規(guī)則是：
transform${inputType}With${transformName}For${BuildType}
關(guān)于 taskName 規(guī)則先放這兒，后面我們會(huì)用到！
上面代碼中的 referencedStreams 用來(lái)處理引用型的 Transform，所以我們著重看 outputStream，outputStream 是通過(guò)方法 findTransformStreams 方法生成的，關(guān)于數(shù)據(jù)流向的問(wèn)題這個(gè)方法里面講的特別明白：
private final List<TransformStream> streams = Lists.newArrayList();
private IntermediateStream findTransformStreams(
@NonNull Transform transform,
@NonNull ComponentPropertiesImpl componentProperties,
@NonNull List<TransformStream> inputStreams,
@NonNull String taskName,
@NonNull File buildDir) {
//...
// 消費(fèi)數(shù)據(jù)流，inputStreams添加需要消費(fèi)的數(shù)據(jù)流
// 1. inputStreams會(huì)消費(fèi)掉streams可以消費(fèi)的數(shù)據(jù)流
consumeStreams(requestedScopes, requestedTypes, inputStreams);
Set<ContentType> outputTypes = transform.getOutputTypes();
File outRootFolder =
FileUtils.join(
buildDir,
StringHelper.toStrings(
AndroidProject.FD_INTERMEDIATES,
FD_TRANSFORMS,
transform.getName(),
componentProperties.getVariantDslInfo().getDirectorySegments()));
// 創(chuàng)建輸出流
IntermediateStream outputStream =
IntermediateStream.builder(
project,
transform.getName() + "-" + componentProperties.getName(),
taskName)
.addContentTypes(outputTypes)
.addScopes(requestedScopes)
.setRootLocation(outRootFolder)
.build();
// 2. 為下一個(gè)Transform添加生成的數(shù)據(jù)流
streams.add(outputStream);
return outputStream;
}
流程如圖：
意思就是每一個(gè) Transform 都要走一遍圖中的流程，對(duì)于大部分 Transform 來(lái)說(shuō)，每一個(gè)的輸入源就是上一個(gè)Transform 的輸出源。
所以對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，如果我們定義 Transform 卻不將生成的文件添加到輸出目錄，這就會(huì)導(dǎo)致后面的 Transform 找不到輸入源，編譯器就只能報(bào)錯(cuò)了。
這個(gè)錯(cuò)誤我最近才犯過(guò)。
回到這一步的開(kāi)始，taskFactory 最終為我們注冊(cè)了一個(gè) TransformTask。
第六步 TransformTask做了什么
進(jìn)入 TransformTask 這個(gè)類，里面有一個(gè)方法 transform 添加了 @TaskAction 注解，所以，一旦該 Task 執(zhí)行了，這個(gè)方法就會(huì)被調(diào)用。
@TaskAction
void transform(final IncrementalTaskInputs incrementalTaskInputs)
throws IOException, TransformException, InterruptedException {
// 設(shè)置增量編譯
isIncremental.setValue(transform.isIncremental() && incrementalTaskInputs.isIncremental());
// ...
recorder.record(
ExecutionType.TASK_TRANSFORM_PREPARATION,
preExecutionInfo,
getProjectPath().get(),
getVariantName(),
new Recorder.Block<Void>() {
@Override
public Void call() throws Exception {
// ... 針對(duì)增量編譯對(duì)文件處理
return null;
}
});
GradleTransformExecution executionInfo =
preExecutionInfo.toBuilder().setIsIncremental(isIncremental.getValue()).build();
recorder.record(
ExecutionType.TASK_TRANSFORM,
executionInfo,
getProjectPath().get(),
getVariantName(),
new Recorder.Block<Void>() {
@Override
public Void call() throws Exception {
// ...
transform.transform(
new TransformInvocationBuilder(context)
.addInputs(consumedInputs.getValue())
.addReferencedInputs(referencedInputs.getValue())
.addSecondaryInputs(changedSecondaryInputs.getValue())
.addOutputProvider(
outputStream != null
? outputStream.asOutput()
: null)
.setIncrementalMode(isIncremental.getValue())
.build());
if (outputStream != null) {
outputStream.save();
}
return null;
}
});
}
recorder 不用管，它只是一個(gè)執(zhí)行器，最終會(huì)執(zhí)行 Block 中的代碼。
如果是增量編譯的 Task，它會(huì)處理文件，告訴我們哪些文件變化了。
之后，就執(zhí)行 Transform 的 transform 方法，整個(gè) Transform 就結(jié)束了。
第七步 DexBuild
回到第四步，AGP 會(huì)我們先后注冊(cè)了混淆和多 Dex 支持的 Task，之后就到了創(chuàng)建 Dex 的 Task：
private void createDexTasks(
@NonNull ApkCreationConfig apkCreationConfig,
@NonNull ComponentPropertiesImpl componentProperties,
@NonNull DexingType dexingType,
boolean registeredExternalTransform) {
// ...
taskFactory.register(
new DexArchiveBuilderTask.CreationAction(
dexOptions,
enableDexingArtifactTransform,
componentProperties));
//...
}
DexArchiveBuilderTask 就是名為 dexBuilder 的任務(wù)，它的注釋：
Task that converts CLASS files to dex archives
它就是創(chuàng)建 dex 文件的 Task。
如果想要對(duì) Dex 有進(jìn)一步的了解，可以閱讀：
到了這一步，我們的源碼分析就結(jié)束了。
三、解決問(wèn)題
之前我一直說(shuō) AGP 3.x.x 的時(shí)候可以 hook 到 transformClassesWithDexBuilderForXXX 的 task，到了 AGP 4.x.x 就不行了。
仔細(xì)看一下我上面提到 taskName 命名規(guī)則，就會(huì)發(fā)現(xiàn)，在 3.x.x 之前，transformClassesWithDexBuilderForXXX 其實(shí)是一個(gè) Transform，我記得對(duì)應(yīng)的類 DexTransform，它會(huì)幫助 AGP 生成 .dex 文件。
而在 4.1.1 的代碼中，這個(gè)任務(wù)交給了 DexArchiveBuilderTask，已經(jīng)不是一個(gè) Transform 了。
所以啊，經(jīng)?？吹桨沧块_(kāi)發(fā)者罵罵咧咧的說(shuō)：臥槽，AGP版本升級(jí)了，我的這個(gè)方法不能用了！
因此，得出結(jié)論，在 AGP 上，最好還是不要去 hook 源碼，建議使用官方推薦的接口去處理。
總結(jié)
本篇文章的內(nèi)容其實(shí)是對(duì)上面 Transform 流程的驗(yàn)證，相信大家已經(jīng)對(duì) Transform 流程有了整體的把握！
如有什么爭(zhēng)議的內(nèi)容，歡迎評(píng)論區(qū)留言，如果覺(jué)得本文不錯(cuò)，「點(diǎn)贊」是對(duì)本文最大的肯定！
文章引用：
