/ 今日科技快讯 /
近日，极越CEO夏一平发布内部信承认，公司目前正遇到困难，需要立即调整。他提出了合并职能重复的部门与岗位、削减短期内无法提升财务表现的项目等一系列举措。据多位极越员工处透露，公司员工11月份的工资已经到账，但是11月、12月的社保需要自行缴纳。目前公司所有业务陷入停滞，内部大群全员禁言。极越计划留下极少数员工维持业务。其余员工有两种方案可以选择，一是离职，等到明年2月底拿N+1补偿；二是选择留下来，但12月开始薪资无法发放，职员将处于“自费上班”的状况。
/ 作者简介 /
明天周六啦，提前祝大家周末愉快！
本篇文章来自 XDMrWu 的投稿，文章主要分享了自己开发的一个 KMP 插桩框架，相信会对大家有所帮助！同时也感谢作者贡献的精彩文章。
XDMrWu 的博客 地址：
https://juejin.cn/user/395479914649933/posts
/ 背景 /
Kotlin Multiplatform近年来逐渐崭露头角，已成为备受关注的跨平台开发方案。它支持代码在 Android、iOS、Web、Destop 等多个平台之间复用，能够大幅提升开发效率与需求的多端一致性。并且随着鸿蒙 Next 的发布，越来越多公司开始着手适配 KMP 以满足未来移动端跨平台开发的需求，由此可见 KMP的发展潜力不可小觑。
然而，在将 KMP 应用到实际项目中时发现缺少一个关键能力——「代码插桩」。这一能力对于修改第三方库、面向切片编程（AOP）以及构建业务框架等场景至关重要。在 Android 平台上，我们可以基于 Transform 实现自定义的字节码转换，并且社区也提供了丰富的 AOP 框架（如 Lancet （https://github.com/eleme/lancet ））。但目前还没有一款基于 KMP 的类 Transform 能力与对应的 AOP 框架，因此本文将探索 KMP 平台上类 Transform 能力，并基于该能力开发一款适用于 KMP 的 AOP 框架——EzHook。
本文仅关注 Kotlin/Native、Kotlin/JS两个平台的插桩能力，Android 平台继续使用 Transform
本文重在探讨方案的实现思路，包含较多 Kotlin 编译器源码与流程分析、调试思路等，如果只想了解框架如何使用那么只需关注「如何使用 EzHook」、「如何实现自定义 Transform」两节即可
本文基于 Kotlin 2.0.21 版本分析
/ 使用EzHook /
Github地址： https://github.com/XDMrWu/EzHook
依赖配置
顶层组件： 对于 Kolint/Native 和 Kotlin/JS 来说都会有一个处于上层的组件用于产出对应的 so 或 js 产物，这个组件我们称为顶层组件
EzHook 包含 Gradle 插件、运行时 Library 两部分，Gradle 插件提供了编译期信息采集与 IR 转换的能力，需要在顶层组件引入
// 根目录 build.gradle.kts "io.github.xdmrwu:ez-hook-gradle-plugin:0.0.2" )// 顶层组件 "io.github.xdmrwu.ez-hook-gradle-plugin" )
Library则提供了必要的注解与运行时能力，在使用到 EzHook 的模块依赖即可
kotlin {"io.github.xdmrwu:ez-hook-library:0.0.2" )
为了使 EzHook 生效还需要关闭 Kotlin/Native 的缓存机制
// gradle.properties native .cacheKind=none
使用方式
EzHook是一个类似 Lancet 的 AOP 框架，可以将任意方法在编译期替换为指定方法，只需要提供一个 Hook 方法并添加 @EzHook 注解指定目标方法即可
@HiddenFromObjC @EzHook("kotlin.time.Duration.toInt" ) fun toInt (unit: DurationUnit ) Int {"Hook to int" )return 10086
上述代码则会将Duration类的 toInt 方法替换为当前的 toInt 方法，需要注意的是
@EzHook注解提供的是目标方法的fqName，也支持顶层方法
Hook 方法的方法名可以随意写，但是参数数量、类型与返回值类型需要与目标方法保持一致
Hook 方法必须是顶层方法
如果目标平台包括 iOS，需要添加@HiddenFromObjC注解
框架也支持在 Hook 方法中调用目标方法，并修改参数。具体做法为
创建一个与参数同名同类型的变量来覆盖原始参数
通过 callOrigin 来调用目标方法
@HiddenFromObjC @EzHook("kotlin.time.Duration.toInt" ) fun toInt (unit: DurationUnit ) Int {val unit = DurationUnit.HOURSreturn callOrigin<Int >()
由于 JS 模块循环依赖时容易出现运行时崩溃，框架支持将 Hook 方法内联到目标方法模块中，以此避免生成的 JS 代码存在模块间的循环依赖。只需要在 @EzHook注解中配置参数 inline=true 即可 @EzHook("kotlin.time.Duration.toInt" , true) fun toInt (unit: DurationUnit ) Int {val unit = DurationUnit.HOURSreturn callOrigin<Int >()需要注意的是Hook 方法不能依赖当前模块其他方法或变量，否则还是会出现循环依赖的问题，在实际应用中可以参考下面两条原则 如何判断是否需要 inline：当目标平台包括 Kotlin/JS，且 Hook 方法所在模块位于目标方法所在模块上层 如何判断 Hook 方法是否可以 inline：Hook 方法所引用的类、方法、变量所在的模块均可以被目标模块依赖 Transform为 EzHook 框架提供了 IR 转换的底座，但是由于 KCP 模块无法引入外部依赖的限制，当前无法提供一个独立的Transform 产物用于接入，只能通过拷贝代码到自己的 GradlePlugin、KCP模块中实现，下面将介绍如何基于这种方式使用 Transform 基座。 1. 拷贝 KotlinJsIrLinkConfig.kt 到你的 Gradle Plugin 模块中，请注意保持包名一致，并且在 classpath 中将该 Gradle Plugin 放在最前面 2. 拷贝 hook 目录下的代码到你的 KCP 模块中 注册 IrLoweringHookExtension 在你的CompilerPluginRegistrar中通过调用IrLoweringHookExtension.registerExtension完成 Hook 并注册自定义的 IrLoweringHookExtension，IrLoweringHookExtension定义如下 interface IrLoweringHookExtension fun traverse (context: CommonBackendContext , module: IrModuleFragment ) fun transform (context: CommonBackendContext , module: IrModuleFragment ) Transform 对项目中的 IR 会进行两轮处理，分别对应 traverse 和 transform 两个方法，建议在 traverse 中采集代码信息，在 transform 中实现具体的 IR 转换逻辑 KCP（Kotlin Compiler Plugin）是 Kotlin 提供的一种功能强大的扩展机制，用于在编译阶段对代码进行分析、变换或生成。通过 KCP开发者可以深度定制编译器行为，实现如 AOP（面向切面编程）、代码插桩、静态检查等高级功能。KCP 的核心特点是它直接作用于 Kotlin 编译器的中间表示（IR），具有高度的灵活性和跨平台支持（包括 JVM、JS 和 Native）。 本文不会介绍如何实现 KCP，推荐先阅读 Writing Your Second Kotlin Compiler Plugin （https://bnorm.medium.com/writing-your-second-kotlin-compiler-plugin-part-1-project-setup-7b05c7d93f6c ）。 为了实现类 Android 的 Transform 底座，我们需要实现统一处理应用所有模块 IR 数据的能力。虽然 Kotlin 允许我们自定义编译器插件（KCP）进行 IR 处理，但 KCP 只能处理单一模块的 IR，无法直接访问或修改应用程序中所有依赖模块的 IR 信息。因此仅依赖 KCP 实现全局统一的 IR 处理是不可行的，我们需要探索其他解决思路。 Kotlin/Native 和 Kotlin/JS 发布的库产物以 klib 形式存在，而 klib 文件存储了该模块编译后的 Kotlin IR 数据。因此可以合理猜测，当编译顶层模块生成平台可执行产物（如 so 文件或 js 文件）时，编译器会收集整个项目中所有依赖模块的 IR 数据，并在这一阶段将其整合、优化，最终统一编译成目标平台的产物。 如果我们可以在这个阶段注入我们自定义的 IR 转换逻辑，就可以实现全局 IR 的处理能力。下面将分别分析Kotlin /Native 和 Kotlin/ JS 的编译流程，尝试找到这一阶段并实现逻辑注入。 Kotlin/Native 编译主要会触发 KotlinNativeCompile 和 KotlinNativeLink 两个 Gradle Task，前者负责将当前模块编译为 Library 产物（也就是包含Kotlin IR 的 klib），后者负责将当前项目编译为平台可执行产物。 KMP 的编译逻辑并不与 Gradle 耦合，Gradle Task 只是负责整合编译参数、通过 KotlinToolRunner 执行编译命令触发编译，相关代码如下所示 @CacheableTask abstract class KotlinNativeCompile @TaskAction fun compile () val buildMetrics = metrics.get ()// 构建编译参数 val arguments = createCompilerArguments()val buildArguments = buildMetrics.measure(GradleBuildTime.OUT_OF_WORKER_TASK_ACTION) {val output = outputFile.get ()// 触发编译命令 // KotlinNativeCompilerRunner.run 最终会触发到 KotlinToolRunner#runInProcess abstract class KotlinToolRunner private fun runInProcess (args: List <String >, metricsReporter: BuildMetricsReporter <GradleBuildTime , GradleBuildPerformanceMetric> = DoNothingBuildMetricsReporter) // 编译转换参数，在参数前增加 konanc val transformedArgs = transformArgs(args)// 获取 ClassLoader 加载 cli class val isolatedClassLoader = getIsolatedClassLoader()// ... try {val mainClass = isolatedClassLoader.loadClass(mainClass)val entryPoint = mainClass.methods"Couldn't find daemon entry point '$daemonEntryPoint '" )// 通过 cli 执行 konanc 命令完成编译 null , transformedArgs.toTypedArray())catch (t: InvocationTargetException) {throw t.targetException可以看到 KotlinNativeCompile 整合编译参数后通过 cli 触发了 konanc 命令进行编译，完整的命令如下所示 konancenable -assertionslocal -plugin-repository/io/github/xdmrwu/ez-hook-compiler-plugin/0.0.2/ez-hook-compiler-plugin-0.0.2.jar-produce： 产物类型，当前指定编译为 Library -Xplugin： 如果当前模块配置了自定义的 KCP 插件，那么会通过改参数传递KCP 插件的 jar 包路径 最终 konanc 会触发编译器代码进行编译，入口在 K2Native中，这里首先会解析前面传递的-Xplugin参数，将 KCP 插件通过 ClassLoader 加载到内存中并完成注册 class K2Native : CLICompiler <K2NativeCompilerArguments >override fun doExecute (@NotNull arguments: K2NativeCompilerArguments ,@NotNull configuration: CompilerConfiguration ,@NotNull rootDisposable: Disposable ,@Nullable paths: KotlinPaths ?) // ... // 加载 KCP 插件并完成注册 val pluginLoadResult =if (pluginLoadResult != ExitCode.OK) return pluginLoadResult// .. try {// 执行编译逻辑 catch (e: Throwable) {// ... throw ereturn ExitCode.OK最终的代码编译逻辑在DynamicCompilerDriver中实现，该类负责 Kotlin/Native 所有类型产物的编译，KotlinNativeCompile 传递的是 library 类型产物，最终编译产物为 klib，具体逻辑如下所示 internal class DynamicCompilerDriver private val performanceManager: CommonCompilerPerformanceManager?) : CompilerDriver() {override fun run (config: KonanConfig , environment: KotlinCoreEnvironment ) if (!config.compileFromBitcode.isNullOrEmpty()) produceBinaryFromBitcode(engine, config, config.compileFromBitcode!!)else when (config.produce) {// 编译为 library "Bitcode output kind is obsolete." )private fun produceKlib (engine: PhaseEngine <PhaseContext >, config: KonanConfig , environment: KotlinCoreEnvironment ) val serializerOutput = if (environment.configuration.getBoolean(CommonConfigurationKeys.USE_FIR))// 编译为 KotlinIR else // 写入 klib 综上，KotlinNativeCompile 整体流程流程如下图所示 KotlinNativeLink整体流程与 KotlinNativeCompile 类似，最终也是通过 CLI 触发 konanc 编译，但是编译参数有所不同，具体参数如下所示 konancenable -assertions这段参数是用于编译 macos 上的可执行文件，核心参数如下 -produce： 指定产物类型为 program，配合--target 可以确定平台 与 KotlinNativeCompile 相比少了-Xplugin 参数，这也可以解释为什么 KCP 只能处理单一模块的 IR。 在编译器侧的逻辑和前面 KotlinNativeCompile 的逻辑一样，区别在于最后调用了produceBinary 生成可执行文件。 /** private fun produceBinary (engine: PhaseEngine <PhaseContext >, config: KonanConfig , environment: KotlinCoreEnvironment ) // ... val backendContext = createBackendContext(config, frontendOutput, psiToIrOutput)// 执行后端编译逻辑，生成 binary 产物 // TopLevelPhases.kt internal fun runBackend (backendContext: Context , irModule: IrModuleFragment ) // ... fun createGenerationStateAndRunLowerings (fragment: BackendJobFragment ) // ... try {val module = fragment.irModule// ... // 对当前模块以及所有依赖模块执行 lower return generationStatecatch (t: Throwable) {throw tval fragments = backendEngine.splitIntoFragments(irModule)val threadsCount = context.config.threadsCountif (threadsCount == 1 ) {else {// ... internal fun PhaseEnginelowerModuleWithDependencies (module: IrModuleFragment ) // ... // 获取所有依赖的 IrModule val allModulesToLower = listOf(module) + dependenciesToCompile.reversed()// 执行所有 lower phase 从源码可以看出 在lowerModuleWithDependencies中会整合当前模块和所有依赖模块的 IR，并进行 lower 处理。然而 Kotlin 编译器为了提升编译效率，会在首次编译时将三方依赖编译为目标平台的binary并缓存，下次编译直接使用缓存参与目标平台产物的编译， 具体实现如下： class KonanDriver val project: Project,val environment: KotlinCoreEnvironment,val configuration: CompilerConfiguration,val compilationSpawner: CompilationSpawnerfun run () val cacheBuilder = CacheBuilder(konanConfig, compilationSpawner)if (cacheBuilder.needToBuild()) {// 为三方依赖库构建缓存 // TODO: Just set freshly built caches. // 执行编译 cacheBuilder.build 会并发执行所有三方库的缓存构建，触发类型为CompilerOutputKind.STATIC_CACHE，从该类的定义可以看出在 macos 平台上缓存产物为 .a 文件 enum class CompilerOutputKind override fun suffix (target: KonanTarget ?) ".${target!!.family.staticSuffix} " override fun prefix (target: KonanTarget ?) enum class Family val exeSuffix: String,val dynamicPrefix: String,val dynamicSuffix: String,val staticPrefix: String,val staticSuffix: String"kexe" , "lib" , "dylib" , "lib" , "a" ),"kexe" , "lib" , "dylib" , "lib" , "a" ),"kexe" , "lib" , "dylib" , "lib" , "a" ),"kexe" , "lib" , "dylib" , "lib" , "a" ),"kexe" , "lib" , "so" , "lib" , "a" ),"exe" , "" , "dll" , "lib" , "a" ),"kexe" , "lib" , "so" , "lib" , "a" );综上，KotlinNativeLink 整体流程流程如下图所示 从上面的编译流程分析可以看出 KotlinNativeLink 阶段就是负责将当前项目依赖模块统一处理、编译成可执行产物，也确实在这个阶段对所有 IR 进行了统一的处理(Lower)。但是由于缓存机制的存在，这个阶段只会处理当前项目所有源码模块，而三方依赖模块会直接使用处理后的缓存，这样看来我们仍然无法统一处理整个项目所有的 IR。然而经过一番源码研究后发现这个缓存机制是可配置的，我们可以通过指定 gradle 参数来关闭这个缓存机制 // gradle.properties native .cacheKind=none关闭之后在KotlinNativeLink阶段会统一处理所有三方库与项目源码的 IR，我们只需要想办法在这个阶段注入我们自定义的 IR 处理逻辑即可达成目标。上面提到最终会调用lowerModuleWithDependencies方法执行 lower，我们来看一下这块代码 internal fun PhaseEnginelowerModuleWithDependencies (module: IrModuleFragment ) // ... // 获取所有依赖的 IrModule val allModulesToLower = listOf(module) + dependenciesToCompile.reversed()// 执行所有 lower phase // NativeLoweringPhases.kt internal val validateIrBeforeLowering = createSimpleNamedCompilerPhase("ValidateIrBeforeLowering" ,"Validate IR before lowering" , 最终会使用NativeLoweringPhases.kt中定义的各个 LoweringPhase 对 IR 进行处理，由于该文件中定义的所有 LoweringPhase 都是顶层属性，那么我们很容易想到利用 java 反射来 Hook 这些LoweringPhase注入自定义的 IR 处理逻辑。以第一个validateIrBeforeLowering为例，它是通createSimpleNamedCompilerPhase创建的对象，具体 IR 处理逻辑在 op 参数中，createSimpleNamedCompilerPhase实现如下 fun createSimpleNamedCompilerPhase (String ,String ,Set <Action <Input , Context>> = emptySet() > = emptySet(),> = emptySet(), = object : SimpleNamedCompilerPhase(fun (actionState: ActionState , data : Pair <Input , Output>, context: Context ) data .second, context)override fun outputIfNotEnabled (phaseConfig: PhaseConfigurationService , phaserState: PhaserState <Input >, context: Context , input: Input ) override fun phaseBody (context: Context , input: Input ) 本质上创建了一个匿名内部类，该类会捕获外部的 op 参数，在生成的字节码中会有一个参数与之对应$op，我们只需要通过反射替换该属性即可完成自定义逻辑注入，具体实现如下 private fun hookValidateIrBeforeLowering (allModules: MutableList <IrModuleFragment >, transformer: (CommonBackendContext , IrModuleFragment ) -> Unit ) val clazz = Class.forName("org.jetbrains.kotlin.backend.konan.driver.phases.NativeLoweringPhasesKt" )// 获取 validateIrBeforeLowering val lower = clazz.declaredFields.firstOrNull { it.name == "validateIrBeforeLowering" } ?.apply {true get (null )// 替换 $op 属性 "$op " ).apply {true set (lower, { context: LoggingContext, module: IrModuleFragment ->val innerContext = context.javaClass.getDeclaredField("context" ).apply {true get (context) as CommonBackendContext// 在这插入自定义逻辑 // ... // 调用原始逻辑 as CommonBackendContext).lower(module)在 Transform 的设计中会有 traverse 和 transform 两个阶段，前者用于信息采集，后者实现 IR 转换，所以我们可以 Hook Lower 阶段前两个LoweringPhase，分别实现这两个阶段，具体代码见NativeIrLoweringExtension.kt （https://github.com/XDMrWu/EzHook/blob/main/compiler_plugin/src/main/kotlin/com/wulinpeng/ezhook/compiler/hook/NativeIrLoweringExtension.kt ） 在实现 Hook 逻辑后，我们还需要选择合适的时机来执行这个 Hook 方法。通过前面的分析，我们知道 KotlinNativeCompile 阶段会调用自定义的编译器插件。同时，KotlinNativeCompile 和 KotlinNativeLink 这两个任务默认在同一进程中运行，并复用相同的 ClassLoader。因此，在自定义编译器插件中执行 Hook 方法是可以对后续的 KotlinNativeLink 任务产生影响，具体代码见EzHookCompilerRegister.kt （https://github.com/XDMrWu/EzHook/blob/main/compiler_plugin/src/main/kotlin/com/wulinpeng/ezhook/compiler/EzHookCompilerRegister.kt ） Kotlin / JS 与 Kotlin/Native 整体流程比较像，在 Gradle 层面也有Kotlin2JsCompile和KotlinJsIrLink两个 Task，Kotlin2JsCompile负责将模块编译为 klib，KotlinJsIrLink 负责将所有 IR 编译为 JS 代码。 在分析过程中发现 JS 的编译器后端无端断点调试，排查后发现编译 JS 默认会启动新的进程执行编译，为了能够正常断点调试可以在 gradle.properties 中添加配置开启当前进程编译 kotlin.compiler.execution.strategy=in -process与 Kotlin/Native 类似，Kotlin2JsCompile负责整合编译参数、通过 GradleKotlinCompilerRunner 执行编译命令触发编译，相关代码如下所示 @CacheableTask abstract class Kotlin2JsCompile override fun callCompilerAsync (K2JSCompilerArguments ,InputChanges ,TaskOutputsBackup ?, // 处理参数 // 触发编译 -Xir-onlysource -mapsource -map-embed-sourceslocal -plugin-repository/io/github/xdmrwu/ez-hook-compiler-plugin/0.0.2/ez-hook-compiler-plugin-0.0.2.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-scripting-compiler-impl-embeddable/2.0.21/84c79a332f515fd6dd3ea2ab50c227c4a5756c37/kotlin-scripting-compiler-impl-embeddable-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-scripting-jvm/2.0.21/939d8b644308f8d97c60317df76ee40299475831/kotlin-scripting-jvm-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-scripting-common/2.0.21/2aeb50e2df2ef94f6b90b7ab2c56d5e18d3687c1/kotlin-scripting-common-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/2.0.21/618b539767b4899b4660a83006e052b63f1db551/kotlin-stdlib-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-gradle-plugin-api/2.0.21/2fe6828d39788b439f1a44576c4fd2d98862e77b/kotlin-gradle-plugin-api-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-gradle-plugin-annotations/2.0.21/585ea547101485df5165acbffc51b760b0bf2728/kotlin-gradle-plugin-annotations-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-native-utils/2.0.21/ccdbc49a5d23f7ab782fbdff20c9426cf074f2d7/kotlin-native-utils-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-tooling-core/2.0.21/952179e9b7f114e78274ca73cea6df8fce3c8b3b/kotlin-tooling-core-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/2.0.21/c9b044380ad41f89aa89aa896c2d32a8c0b2129d/kotlin-script-runtime-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-util-klib/2.0.21/cc042c4a50a1ee46695a8f2f928c196223bdd7dc/kotlin-util-klib-2.0.21.jar,/Users/wulinpeng/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-util-io/2.0.21/4467ad395771e3d12ca864fd9949e1404920f558/kotlin-util-io-2.0.21.jar-Xir-module-name： 当前编译模块名称 -Xir-produce-klib-dir： 编译 klib -Xplugin： 如果当前模块配置了自定义的 KCP 插件，那么会通过改参数传递KCP 插件的 jar 包路径 最终会触发编译器代码进行编译，入口在 K2JsIrCompiler中，这里首先会解析前面传递的-Xplugin参数，将 KCP 插件通过 ClassLoader 加载到内存中并完成注册 class K2JsIrCompiler : CLICompiler <K2JSCompilerArguments >override fun doExecute (K2JSCompilerArguments ,CompilerConfiguration ,Disposable ,KotlinPaths ? // ... // 加载插件 val pluginLoadResult = loadPlugins(paths, arguments, configuration)if (pluginLoadResult != OK) return pluginLoadResult// ... try {// 执行代码编译 val ir2JsTransformer = Ir2JsTransformer(arguments, module, phaseConfig, messageCollector, mainCallArguments)val outputs = ir2JsTransformer.compileAndTransformIrNew()// ... catch (e: CompilationException) {// ... return INTERNAL_ERRORreturn OK综上，Kotlin2JsCompile 整体流程流程如下图所示 KotlinJsIrLink 和 Kotlin2JsCompile 流程相似，区别在于编译参数，具体参数如下 -Xcache-directory=/Users/wulinpeng/Desktop/kcp_project/EzHook/demo/build/klib/cache/js/developmentLibrarysource -mapsource -map-embed-sources-Xir-produce-js： 编译成 JS 产物 和 KotlinNativeLink 类似，在这个阶段不会带上 KCP 插件。最终的编译逻辑在JsIrCompilerWithIC 中实现 class JsIrCompilerWithIC override fun compile (allModules: Collection <IrModuleFragment >, dirtyFiles: Collection <IrFile >) // ... // 执行 lower as WholeWorldStageController)val transformer = IrModuleToJsTransformer(context, shouldReferMainFunction = mainArguments != null )return transformer.makeIrFragmentsGenerators(dirtyFiles, allModules)与 Kotlin/Native 类似，我们只需要 Hook 对应的 LoweringPhase 即可，代码见JsIrLoweringExtension.kt 上面介绍过在 Kotlin /Native 下是在 KCP 的执行入口来触发 Hook 逻辑，Compile 与 Link 两个 Task 在一个进程且复用 ClassLoader 是改方案可行的重要前提。然而在 Kotlin/ JS 中，尽管我们设置 in-progress 保证了 Compile 和 Link在一个进程中，但是 GradleKotlinCompilerWork在不同 Task 之间没有复用 ClassLoader ，导致该方案无效。 class GradleKotlinCompilerWork private fun compileInProcessImpl (messageCollector: MessageCollector ) val stream = ByteArrayOutputStream()val out = PrintStream(stream)// todo: cache classloader? val classLoader = URLClassLoader(config.compilerFullClasspath.map { it.toURI().toURL() } .toTypedArray())val servicesClass = Class.forName(Services::class .java .canonicalName , true , classLoader) val emptyServices = servicesClass.getField("EMPTY" ).get (servicesClass)val compiler = Class.forName(config.compilerClassName, true , classLoader)// ... 那么是否可以将 KotlinJsIrLink 的编译参数中应用 KCP 插件来实现呢？首先从源码入手看一下为什么KotlinJsIrLink没有应用 KCP，将 KCP 插件路径赋值到编译参数中的逻辑在AbstractKotlinCompileConfig中 internal abstract class AbstractKotlinCompileConfig <TASK : AbstractKotlinCompile>> constructor (compilationInfo: KotlinCompilationInfo) : this (// ,,, // ... internal .configurations.pluginConfiguration// ... 而KotlinJsIrLinkConfig继承该类后主动清空了 pluginClassplugin，因此 KotlinJsIrLink 不会应用 KCP internal open class KotlinJsIrLinkConfig private val binary: JsIrBinary,(KotlinCompilationInfo(binary.compilation)) {private val compilationget () = binary.compilationinit {// Link tasks are not affected by compiler plugin, so set to empty // ... 如果你具备 Gradle Hook 相关经验，可能已经想到一种方法：通过调整 classpath 顺序来覆盖 KGP 的实现类。在这里，我们可以覆盖 KotlinJsIrLinkConfig 类的实现。具体步骤是将 KotlinJsIrLinkConfig 的代码拷贝到自定义的 Gradle Plugin 中，并确保该插件在 classpath 中优先加载，从而取代原始的 KotlinJsIrLinkConfig 实现。以下是具体的实现方式： internal open class KotlinJsIrLinkConfig private val binary: JsIrBinary,(KotlinCompilationInfo(binary.compilation)) {private val compilationget () = binary.compilationinit {// 注释掉这一行，应用 KCP 到 KotlinJsIrLink // task.pluginClasspath.setFrom(objectFactory.fileCollection()) // ... 然而默认情况下 Kotlin/JS 是走 daemon 模式的，改模式下 Compile 与 Link 共用一个 daemon 进程并复用 ClassLoader。由于上面为 KotlinJsIrLink 任务应用了 KCP 会导致相关的类被 Hook 两次(加载 KCP 没有复用 ClassLoader)，进而导致运行时异常，因此需要在对应的 Hook 逻辑中判断原始 Lower 是否已经被 Hook，具体逻辑见JsIrLoweringExtension.kt（https://github.com/XDMrWu/EzHook/blob/main/compiler_plugin/src/main/kotlin/com/wulinpeng/ezhook/compiler/hook/JsIrLoweringExtension.kt ） 框架核心需要实现的功能是替换目标方法的实现，并且在 Hook 方法中能够调用原始方法并修改参数， 实现逻辑如下 class EzHookIrTransformer val collectInfos: List, val pluginContext: CommonBackendContext): IrElementTransformerVoidWithContext() {companion object {private const val LAST_PARAM_NAME = "ez_hook_origin" private const val NEW_FUNCTION_SUFFIX = "_ez_hook" override fun visitFunctionNew (function: IrFunction ) // ... val newFunction = function.copyFunctionToParent("${function.name.asString()} $NEW_FUNCTION_SUFFIX " )fun IrFunction.copyFunctionToParent (newName: String , newParent: IrDeclarationParent = parent) return deepCopyWithSymbols(newParent).apply {as IrDeclarationContainer).addChild(this ) 2. 将目标方法实现替换为调用 Hook 方法，并传递当前对象 class EzHookIrTransformer val collectInfos: List, val pluginContext: CommonBackendContext): IrElementTransformerVoidWithContext() {companion object {private const val LAST_PARAM_NAME = "ez_hook_origin" private const val NEW_FUNCTION_SUFFIX = "_ez_hook" override fun visitFunctionNew (function: IrFunction ) // ... val result = createTmpVariable(// put dispatch receiver as the last param if exist if (function.isClassMember()) {"returnValue" , class EzHookIrTransformer val collectInfos: List, val pluginContext: CommonBackendContext): IrElementTransformerVoidWithContext() {companion object {private const val LAST_PARAM_NAME = "ez_hook_origin" private const val NEW_FUNCTION_SUFFIX = "_ez_hook" override fun visitFunctionNew (function: IrFunction ) // ... if (function.isClassMember()) { 4. 找到 Hook 方法中的 callOrigin 调用，替换为目标对象的 copy 方法调用 class EzHookIrTransformer val collectInfos: List, val pluginContext: CommonBackendContext): IrElementTransformerVoidWithContext() {companion object {private const val LAST_PARAM_NAME = "ez_hook_origin" private const val NEW_FUNCTION_SUFFIX = "_ez_hook" override fun visitFunctionNew (function: IrFunction ) // ... null )class EzHookCallOriginTransformer val hookFunction: IrFunction, val targetFunction: IrFunction, val context: CommonBackendContext): IrElementTransformerVoidWithContext() {companion object {private const val CALL_ORIGIN = "com.wulinpeng.ezhook.runtime.callOrigin" /** private val overrideParams = mutableListOf()override fun visitVariable (declaration: IrVariable ) val name = declaration.name.asString()val type = declaration.type.getClass()!!.kotlinFqName!!.asString()if (hookFunction.valueParameters.any {return super .visitVariable(declaration)override fun visitCall (expression: IrCall ) if (expression.symbol.owner.fqNameWhenAvailable?.asString() == CALL_ORIGIN) {return irCall(targetFunction.symbol).apply {// for class member function, make the last param as dispatch receiver if (targetFunction.isClassMember()) {val lastParam = hookFunction.valueParameters.last()for (i in 0 until targetFunction.valueParameters.size) {val valueParam = targetFunction.valueParameters[i]// override param val irVariable = overrideParams.find { it.name.asString() == valueParam.name.asString() }else {return super .visitCall(expression) 在 iOS Target 上运行时会出现编译问题，具体信息如下 error: Invalid record (Producer: 'LLVM11.1.0' Reader: 'LLVM 11.1.0' )1 error generated.129 )85 )35 )44 )72 )87 )0 (ObjectFiles.kt:22 )3 .phaseBody(PhaseBuilders.kt:91 )3 .phaseBody(PhaseBuilders.kt:79 )226 )113 )120 )default (Machinery.kt:111 )295 )12 $runAfterLowerings(TopLevelPhases.kt:127 )139 )83 )2 $lambda$1 $lambda$0 (DynamicCompilerDriver.kt:43 )1 .phaseBody(Machinery.kt:79 )1 .phaseBody(Machinery.kt:73 )226 )113 )86 )37 )135 )157 )65 )34 )这是由于在编译期为 Hook 方法添加了参数，导致 Hook 方法签名变更，最终与生成的头文件签名不一致造成编译失败。Compose Compiler 也有类似的问题，它们在编译期会为 @Composable 方法添加额外的参数，解决方案就是为这些方法加上@HiddenFromObjC注解，保证这些方法不会导出，下面是 Compose Compiler 的实现 /**@Composable types and class AddHiddenFromObjCLowering override fun visitFunction (declaration: IrFunction ) val f = super .visitFunction(declaration) as IrFunction// 非 public 的方法不会被导出，不需要添加 @HiddenFromObjC if (f.isLocal || f.isSyntheticFun() ||return f// 为 @Composable 方法添加 @HiddenFromObjC 注解 if (f.hasComposableAnnotation() || f.needsComposableRemapping()) {true return f由于我们 Hook 的时机比较靠后，使用这种方式加上@HiddenFromObjC 注解也无法解决该问题，所以就需要使用方主动在 Hook 方法上增加@HiddenFromObjC注解来规避这个问题。 Cannot read properties of undefined (reading 'a') 通过执行jsNodeDevelopmentRun运行 js 代码时会出现崩溃，堆栈如下 /Users/wulinpeng/Desktop/kcp_project/EzHook/build/js/packages/EzHook-demo/kotlin/EzHook-demo-v2.js:15 'a' )19 :40 5 :5 (/Users/wulinpeng/Desktop/kcp_project/EzHook/build/js/packages/EzHook-demo/kotlin/EzHook-demo-v2.js:15 :2 )internal /modules/cjs/loader:1455 :14 )internal /modules/cjs/loader:1534 :10 )internal /modules/cjs/loader:1265 :32 )internal /modules/cjs/loader:1081 :12 )internal /modules/cjs/loader:1290 :19 )internal /modules/helpers:188 :18 )5 :29 这是由于在编译期我们为目标方法添加了对 Hook 方法的依赖(引用)，导致模块间存在循环依赖。而在 JS 中模块循环依赖时非常容易出现初始化错误，比如这里 undefined 就是因为 demo 模块和 demo-v2 模块循环依赖导致 demo 模块未完成初始化。 针对这种情况需要将 Hook 方法内联到目标模块中，以此来避免生成 JS 代码出现循环依赖的问题。
