0 引言
在仿制比如qq音乐的增量编译工具时,demo阶段使用了一些硬编码.比如要增量编译一个改动的java文件,其classpath需要一个android.jar. 比如'Android/Sdk/platforms/android-28/android.jar'.
以及编译结束后需要调用adb命令 push 增量编译产物到手机, 还需要重启app查看运行结果.
- 收敛问题域,本次我们探讨,如何优雅的拿到android.jar, adb命令这些, 替换掉demo阶段的硬编码.
1 先说结论 (鱼)
若当前project已经 "apply plugin: 'com.android.application' " (或apply plugin: 'com.android.library')了, 那么这样拿:
// 注, 以下代码都需要在当前project的afterEvalute之后执行:
// 注2,以下代码不保证执行(因为使用调试的变量监视器获取,可能访问了部分private属性)
// 拿adb:
project.plugins.getPlugin('android').extension.adbExecutable
project.plugins.getPlugin('android').extension.globalScope.sdkComponents.adbExecutableProvider.get()
// 拿android.jar (bootclasspath):
project.plugins.getPlugin('android').extension.globalScope.sdkComponents.sdkLoadStrategy.getAndroidJar()
看下结果示例:
获取adb:
获取android.jar:
其本质原理是
通过project拿到
androidPlugin(com.android.build.gradle.internal.plugins.AppPlugin / LibraryPlugin)
或 androidExtension (com/android/build/gradle/AppExtension / LibraryExtension).
的对象实例.
这二者都持有 com.android.build.gradle.internal.scope.GlobalScope 对象实例.
进一步的, GlobalScope持有 com.android.build.gradle.internal.SdkComponents对象实例,
进一步的, 其内部的 SdkLoadingStrategy,
进一步的, 其组合了 SdkDirectLoadingStrategy 等策略.
进一步的,跟进到 SdkLocationSourceSet, 看到其加载 localProperties, environmentProperties, systemProperties
等配置.
整个链路下来, 基本能感受到 AGP加载配置,解析出 包括但不仅限于 android.jar /adb 等 一系列工具和依赖信息路径的套路.
以后网上或他人提供的类似问题的答案 无论如何绕,除了groovy/kt语法糖加持显得特殊一些, 已经没有秘密了.
1 怎么找到的? (渔)
笔者本次是在复制"QQ音乐Android编译提速之路"
在硬编码验证后,正在工程化. 增量的编译新增改动的代码,需要拿到当前环境的android.jar 而不能是硬编码.
push增量编译产物到手机, 也需要拿当前环境的adb命令,而不是硬编码.
先找到一个切入口: AGP创建的javac task 是如何附加上 android.jar的呢?
调试+阅读源码, 跟进这个好问题.
根据对AGP源码基本结构的了解, AGP创建的task都来源于 com.android.build.gradle.internal.VariantManager
和 com.android.build.gradle.internal.TaskManager
定位到这两个源码,寻找javac关键字,容易找到:
进一步的前往 com.android.build.gradle.tasks.JavaCompileCreationAction 追踪其输入的classpath参数.
在JavaCompileCreationAction,留意到, 真正负责javac的是 org.gradle.api.tasks.compile.JavaCompile 这个.
(ps: AGP的 XXXTask_CreationAction 有一些常规的套路,死磕一两个后就清楚套路了, 无法是gradle的一些provider延迟加载机制,
kotlin的一些语法糖, 支持所谓gradle所谓的dsl的一些注解处理动态字节码工具(可参考见文章:gradle 如何生成 _Decoreted 包装类的 )
阅读了使用 JavaCompile , 发现是在其基类 AbstractCompile 的classpath属性记录当前编译需要依赖的classpath的.
另, 正向阅读代码 也可能发现设置javac classpath的方法:
上述两点,上下夹住的代码就是这里, 设置javac的task JavaCompile 设置 classpath的地方:
(ps: 不熟悉kt的同学 看着可能有点点费劲)
调试, 下断点, 发现这个 scope.bootClasspath 就是android.jar啦(包含但不仅限于, 其他的是什么就是另外一个话题了)
- 如此 我们找到 原来javac 的classpath中的bootclasspath中的android.jar 是来源与AGP的 VariantScope.
继续跟进 VariantScope来源 就能得到开头给出的'鱼'了.
