Kotlin 2.4 来了，鸿蒙开始适配 2.4：KMP 的两条战线

一条分支名，暴露了正在发生的事

前段时间我写过一篇鸿蒙 KMP 的文章，当时查到一个关键信息：社区发布的正式版，是基于 KMP 2.2.21 / CMP 1.9.2 做的鸿蒙适配。

前两天再去翻那个仓库，发现它的分支列表里多了一行字：

develop-2.4 框架 KMP 2.4.21 _ CMP 1.12.0 版本对应的文档集合

而且这个分支21 小时前刚更新过。

另外还有一条：

main-2.2（默认分支） 框架 KMP 2.2.21 _ CMP 1.9.2 版本对应的文档集合

一边是已经发出去的正式版，一边是正在推进的新基线。

KMP 在鸿蒙这条线上，开始跟上游的最新版本对齐了。

而几乎同一时间，上游 JetBrains 刚发布 Kotlin 2.4.20。

两条线，撞在了一个时间点上。

先把上游这条线讲清楚：Kotlin 2.4.20 改了什么

如果你只扫一眼更新日志，可能会觉得"哦，又是个修修补补的版本"——两百多条变更里，大半是 bugfix。

但里面有几个点，对写 KMP 的人来说很实在。

第一，Swift 互操作终于"能打了"。

这次 Swift export 支持把 Kotlin 的 sealed class 直接映射成 Swift 的 enum：

// 不用再写 default 了
let name = switch shape.sealedType() {
case .circle(let t):    "圆"
case .rectangle(let t): "方"
}   // ← 穷尽检查

以前处理这种多态类型，Swift 侧要么写一堆 if let，要么被迫加一个永远走不到的 default 分支——穷尽性检查直接失效。现在编译器能帮你查漏了。

还有跨语言继承：Kotlin 类型可以继承 Swift 的类/协议（含纯 Swift 库），不用再包一层。

这两件事指向同一个方向：KMP 在 iOS 侧一直被人诟病的"互操作摩擦"，正在被一点点磨平。

第二，klib 增量编译进 Beta。

kotlin.incremental.native=true

改一行 Kotlin 代码，不用再等整个 native 模块重编。这个体验改善，做过 Kotlin/Native 的人应该懂。

第三，Kotlin/JS 的测试工具链从 Karma 换成了 Playwright——算是跟上时代。

所以上游这条线的主旋律是：把跨语言的接缝处理得更顺。

再看鸿蒙这条线：它现在走到哪了

要理解鸿蒙这边，得先看它的版本号规则——这是昨天刚发布的正式版公告里写的：

版本号采用「上游基线 + 鸿蒙适配序号」：2.2.21-1.0.0 / 1.9.2-1.0.0 表示基于上游 KMP 2.2.21、CMP 1.9.2 的鸿蒙适配正式版。

这个规则很关键。它说明了一件事：

鸿蒙适配不是另起炉灶，而是在追上游的版本。

所以你会看到 2.2.21-1.0.0 这样的编号——前面的 2.2.21 是它对应的上游 Kotlin 版本，后面的 1.0.0 是鸿蒙适配自己的迭代号。

已经发布并进了 Maven 仓的有：

而 develop-2.4 这条新分支，目标基线就是 KMP 2.4.21 / CMP 1.12.0。

开发节奏公告里也写了：

develop 分支：用于每月开发态代码合入，每月准出后合入 main 分支。

翻译一下：每月推进一版，成熟了才合进正式线。 不是拍脑袋发版，而是有节奏的滚动。

这条线上最近在忙什么

翻了 develop-2.4 的提交记录，最近的动作挺有意思。

最新一条是把 CAPI 用户手册适配到 API 26——把 OHOS CAPI 版本更新到 API26，并且同步更新了「模块、最低 API 与典型依赖库」，还专门加了一节说明**「CAPI 升级至 API 26 后导致的特殊变更」**。

另一条是更新 akinterop 到 1.0.1、sqldelight 到 2.2.1-1.1.0。

这两个方向，恰好对应鸿蒙跨平台落地的两个真实卡点：

• CAPI 跟着鸿蒙系统版本走——系统升级，桥接层就得跟着升，这是"不断档"的问题
• 三方库的适配版本号——生态库能不能跟上，决定了项目敢不敢用

顺带一提：CMP 1.12 上游给的亮点

既然 develop-2.4 这条线要跟到 CMP 1.12.0，那 1.12 上游改了什么，也值得看一眼。

CMP 1.12.0 是 8 月 25 日发布的，最亮的一条在 Desktop 侧：

MCP server was introduced for Compose Hot Reload that enables AI agents to interact with a running Compose application in real time

翻译一下：给 Compose 热重载加了个 MCP server，让 AI agent 能实时和一个正在运行的 Compose 应用交互。

这条挺微妙的——Compose 和 AI 的结合点，正在从"用 AI 写 Compose 代码"，走向"让 AI 直接操作跑着的应用"。

当然它也带了一批破坏性调整，迁移时要留心：

• NativeCanvas、NativePaint 这些 typealias 的弃用级别被提到了 ERROR
• SwingPanel 的 background 参数弃用

从 1.9.2 跳到 1.12.0，不只是版本号变了——迁移成本也是要算进去的。

两件事凑在一起，说明了什么

把这两条线放在一起看，我看到的是一个挺清晰的图景：

KMP 的"一码多端"，正在多条战线上同时推进。

• 上游在打磨跨语言互操作的体验（Swift export、增量编译）
• 鸿蒙这条社区线在追上游版本（2.2 → 2.4）、补系统适配（CAPI → API 26）、扩三方库生态

它们不是同一个团队在做，但走的是同一个方向——让"写一套 Kotlin，跑更多平台"这件事，摩擦更小一点。

对开发者来说，判断标准其实很简单：

当你评估一个新平台时，问的不再是"支持不支持"，而是"上游跟到哪个版本了、库够不够用、性能顶不顶得住"。

从"能不能跑"到"跟得上吗"，这本身就是个阶段性的变化。

但社区的真实声音，比公告更值得听

公告总是漂亮的。我特意去翻了社区讨论区，那才是这条线真正的体温。

最热的一帖，是问"能不能尽快合并到 JetBrains 官方分支"（30 天前发起，7 条回复）。

发起人的原话挺直接的：

我现有的纯 KMP&CMP 应用项目添加鸿蒙平台存在大量库不支持问题，编译过程还出现几个已适配的库存在内部依赖冲突，希望尽快合并上游方便整个 KMP 社区的库开发者新增 ohos 的库版本，CPF 社区对库支持的进度过于慢了。

他具体点了三个库：androidx-datastore、androidx-room3、androidx-sqlite——“这三个基本就是大家普遍使用的持久化方式的基础依赖库了”。

然后是最扎心的部分：

它们都没有 ohos x86 的支持。开发者在 win 平台几乎无法直接开发测试一个正常功能的应用，起码你得一直接一台鸿蒙手机充当测试平台……

他还举了个具体的坑：从某个镜像仓库拉到的 room3 alpha 版本，生成代码会报 androidx.sqlite 缺少实现；而用上游的 room3 3.0.1 就没问题。

官方回复了，态度挺实在：

您好，关于 ohos x86 的支持，已在规划中，感谢您的关注。

其他帖子也各有各的真实：

• “skia 渲染模式下页面帧生产被拖至约 3 秒一帧，疑似 VsyncOnDemand 延迟注销机制异常”——性能问题
• “material3 导致移植已有项目阻塞”——组件库的坑
• “当前 webView 有支持吗？”——能力覆盖
• “大家有项目真实上线吗？有遇到什么坑吗”——底下有人回了四个字：“正在做语音助手 KMP 版本适配”

这几条加起来，才是这条线的真实状态：能跑通、有人在用、但生态和性能还在补课。

为什么"跟上上游"是件慢活

看到社区那句"进度过于慢了"，可能会有人觉得是投入不够。

但这里有个技术现实值得说清楚：鸿蒙适配改的是编译器后端，不是写个插件。

翻 CPF-KMP-CMP 的仓库列表，你会看到这些名字：

kotlin、compose-multiplatform、compose-multiplatform-core、skiko、akinterop、cicd-toolkit……

它们是 Kotlin 编译器、Compose 框架、图形渲染层的鸿蒙分支。

这意味着这份工作至少包括：

• 给 Kotlin/Native 加一个新的编译目标（target）
• 把 Compose 的渲染管线接到鸿蒙的 Render Service
• 让 Skiko 封装的 Skia 图形库能在鸿蒙上跑起来

而每次上游发新版本，这些改动都要重新对齐一遍。

这也是"上游基线 + 适配序号"这个版本号规则真正的含义——它精确描述了这份工作的性质：持续的追踪，而不是一次性的移植。

再看那句"每月开发态代码合入，每月准出后合入 main"，感觉就不一样了：

这不是慢，这是在用一个能持续的速度，做一件很重的事。

我的几点看法

第一，“适配"这件事的本质是"跟上游”，不是"造轮子"。

从版本号规则（上游基线 + 适配序号）就能看出来——鸿蒙这条线的核心工作是把上游的编译器/UI 框架搬到鸿蒙上跑通，而不是自己另搞一套 API。

这意味着它的天花板和上游绑在一起：上游把 Swift 互操作做顺了，那是 iOS 的红利；上游把编译器改进了，鸿蒙这边跟进才能吃到。

第二，社区抱怨的那三条，其实指向同一个问题。

x86 支持、三方库版本、性能——表面看是三件事，本质都是**“生态成熟度”**。

而生态成熟度有个残酷的特点：它不能靠热情解决，只能靠时间和真实项目打磨。 官方回"已在规划中"，是实话，也是实话里透出的无奈。

第三，如果你在评估要不要上这条线，我给个判断框架。

别问"支持鸿蒙吗"——问这三个问题：

1. 上游跟到哪个版本了？（现在是 2.2.21 稳定、2.4.21 开发中）
2. 我依赖的库适配了吗？（尤其是持久化、网络这类基础库——room3、datastore 是公认痛点）
3. 我的开发机是什么？（如果需要 x86 模拟器，现在还得等；Mac M 系列 + 真机的组合比较稳）

三个都过了，再动手；有一个卡住，就先把方案记在备忘录里。

最后

Kotlin 2.4 和鸿蒙 2.4，看起来是两件不相干的事。

但它们其实在回答同一个问题：

一套 Kotlin 代码，能跑多少地方、跑得多好？

上游在把跨语言的接缝磨平，鸿蒙这条线在把版图铺开。

这两件事，都在让那个数字变大。

想问问你：

你手上的 KMP 项目，会因为"鸿蒙适配跟到 2.4 了"而重新考虑吗？

或者你已经踩过这条线的坑了？ 评论区聊聊，我挺想知道真实项目的反馈。

参考资料：CPF-KMP-CMP 社区仓库（AtomGit/GitCode）分支与 Release 公告、社区讨论区公开帖、JetBrains Kotlin 2.4.20 发布说明。