一件悄悄发生的"版图扩张"

先说个数字：四。

Android、iOS、桌面 —— 这是 Kotlin Multiplatform 这几年稳定覆盖的主力阵地（Web / Wasm 也在推进中）。写一套共享逻辑，加一套 Compose UI，几个平台一起跑。

而昨天，这个名单要加上第四个成员了：鸿蒙。

而且这次不是"理论上能跑"，是正式版本发布——组件进了 Maven 仓，Android Studio 插件市场上能搜到工具链插件，文档在 AtomGit 上。

最让我意外的是发布方那句话：

已经在其他平台使用 CMP 的开发团队，界面业务代码可直接复用同一套 Compose 写法，不必为鸿蒙完全重新写一套 ArkUI。

不用重写 ArkUI。 这五个字对做跨端的人来说，分量挺重的。

先把事实说清楚

这次发布的是 KMP&CMP 鸿蒙首版本，2026 年 9 月 15 日发布。

几个关键信息：

  • 谁做的：CPF-KMP-CMP SIG 社区伙伴共建（注意，是社区 SIG，不是 JetBrains 官方，后面我会细说这个区别）
  • 基于什么：源社区 KMP 2.2.21 / CMP 1.9.2
  • 目标：把"逻辑跨端共享、UI 原生渲染"这套开发范式带到鸿蒙上
  • 获取方式：组件已发布至 Maven 仓；工具链插件 KMP OHOS Support 在 Android Studio 插件市场搜索安装

官方对适用人群的定位也很清楚：

对已经使用 KMP/CMP 做跨端业务的团队，该版本有助于降低迁到鸿蒙的改造成本。鸿蒙开发团队也可借助这套能力，做 Kotlin 与 ArkTS 混合开发，拓展技术选型。

翻译一下就是：KMP 团队想上鸿蒙，现在成本低了；鸿蒙团队想用 Kotlin，现在有路子了。

顺便说个背景——这事其实铺垫了三个月。今年 6 月社区版就开了 Beta，8 月 InfoQ 还报道过一版实测数据（渲染内存降 95%、GC 卡顿率降 90%）。现在算是正式落地。

亮点一：Compose 直接跑鸿蒙，不用重写 UI

这是我觉得最有价值的一条。

在鸿蒙上开发，官方路线是 ArkTS + ArkUI。对已经在做 KMP/CMP 的团队来说，这意味着鸿蒙端要单独维护一套 UI——业务逻辑能共享，但界面得重写一遍。

这次发布把这条路铺平了：

CPF-KMP-CMP 在鸿蒙侧提供了 compose.ui、compose.foundation、compose.material、compose.material3 的平台实现，可延续熟悉的声明式 UI 习惯开发鸿蒙端界面。

compose.material3 都在。 也就是说，你写惯了的那套 Compose 代码，在鸿蒙上是能认的。

对一个已经在 Android/iOS 上跑 CMP 的项目来说，这意味着鸿蒙端的接入成本，从"重写一套 UI"降到"加一个 target"。

差别有多大？做过跨端的人应该懂。

亮点二：Kotlin ↔ ArkTS 双向互操作

第二条对存量项目很关键。

现实情况是：很多鸿蒙项目已经用 ArkTS 写了一堆东西（系统能力、业务模块），不可能整体推翻重写成 Kotlin。

这次的解法是 akinterop：

共享逻辑可继续写 Kotlin，系统侧或存量模块仍用 ArkTS 时，用 akinterop 做双向互操作：注解 / 装饰器声明意图，工具链生成桥接，少写 C 胶水。基础类型、容器与异常可跨侧传递，存量工程可渐进接入，不必为互通推倒重来。

“渐进接入，不必推倒重来” —— 这句话是给存量项目的定心丸。

注解声明意图、工具链生成桥接——比手写 C 胶水的体验好太多，写过 JNI 的人都懂那种痛。

亮点三：统一渲染（这条是技术核心）

这条比较硬核，但我觉得是整件事里最有技术含量的一环。

先说问题：传统的跨平台 UI 方案，通常要自建一套渲染管线。

自建有什么坏处？报道里说得很直接：

传统跨平台 UI 方案常自建渲染管线，这容易带来额外初始化与合成开销，也容易出现启动慢、动画和系统表现不一致等问题。

自渲染意味着你的 UI 不走系统那条路——启动要多一步初始化，动画节奏跟系统对不齐，看起来就"不像原生"。

这次的方案是反过来的：

CPF-KMP-CMP 将 Compose 绘制能力对接鸿蒙 Render Service / RenderNode 系统渲染能力，由鸿蒙系统统一完成合成与刷新调度（统一渲染需 API 19 及以上）。

把绘制能力交给鸿蒙系统自己去合成，收益是连锁的：

  • 更快首帧：少了自渲染的初始化等待，启动和跳转更利落
  • 精细化局部刷新：状态变了才更新，还支持局部录制——只重绘变化的区域
  • 原生组件友好混排：Compose 页面能和 ArkUI、C-API 混排，地图、视频这类原生能力更容易嵌进来
  • 对齐系统动画：帧节奏走系统的 DisplaySync，动画体验跟鸿蒙原生应用一致

最后一条尤其重要。跨平台应用"一眼假"的原因，往往不是布局不对，而是动画的节奏感不对——帧率调度跟系统不在一个节拍上。

⚠️ 注意一个限制：统一渲染需要 API 19 及以上。老设备上会退化。

性能账：省了 20% 编译时间，降了 30% 堆内存

这次给了几个挺具体的数字，不像很多"性能优化"的模糊说法：

编译侧（并行编译）：

将 LLVM IR 切分后多线程跑局部优化再合并，缩短大规模工程的编译等待；典型场景下约可节省 20%+ 耗时。

内存侧（CommonGC）：

采用并发标记—复制回收算法，降低内存碎片、减少 GC 停顿时间，典型场景下 KN 堆占用约可下降 30%。

另外还有两个工程化的优化很实用：

  • 模块化拆分：单一 KMP 工程可配置成多个 .so，配合分布式编译进一步缩短构建
  • Debug 增量编译：macOS / Linux 上支持基于静态库缓存的增量编译——只重编改动的部分，不必每次全量重链

（做 KMP 的人看到"全量重链"四个字应该会有点应激反应）

还有个细节我挺喜欢——后台不空转：

统一渲染路径支持按需申请 VSync 信号，当页面没有内容变化时，主动抑制刷新绘制；同时支持 LTPO 硬件特性，应用退到后台之后自动停止无效绘制循环……该行为为框架默认行为，不需要业务额外编写代码。

默认行为，不需要业务写代码。这种"框架替你操心"的设计，比让你手动去 onPause 里关动画友好多了。

上手：三步跑起来

流程比我想象的简单：

(1) DevEco Studio：用 6.0.0+ 下载 HarmonyOS SDK API 17+，打开工程里的 harmonyApp 配好调试签名。 (2) Android Studio：日常写 KMP&CMP 代码。 (3) Android Studio：选设备和 harmonyApp 点 Run（推包时保持 DevEco 运行）。

注意第 3 步那个括号——推包时要保持 DevEco Studio 开着。这类"两个 IDE 配合"的细节最容易踩坑，官方提前说了。

文档在 AtomGit（搜 CPF-KMP-CMP/docs），想深入看的可以去翻。

为什么鸿蒙这块拼图特别重要

说句实在话：对国内的 KMP 开发者，鸿蒙这块拼图可能比 Web/Wasm 重要得多。

原因很现实——在国内做移动端，鸿蒙已经不太是"要不要考虑"的问题了，而是"什么时候必须做"的问题。 尤其在政企、金融、车机、IoT 这些领域，推进速度比很多人预期的快。

而过去 KMP 团队面对鸿蒙的选择挺尴尬的：

  • 共享逻辑能复用，但 UI 得重写（ArkUI）→ 相当于鸿蒙端要额外养一个人
  • 或者干脆放弃 KMP，鸿蒙端单独起个工程 → 共享逻辑的优势全丢了

这次发布的意义就在这儿：它把"鸿蒙端 UI 也要重写"这个成本项，从等式里拿掉了一大半。

对一个小团队来说，这可能就是从"做不起"到"做得起"的差别。

说点冷静的：这事该怎么看

热点归热点，我得把几个边界说清楚，免得你判断失误。

第一，这是社区 SIG 项目，不是 JetBrains 官方。

发布方是 CPF-KMP-CMP SIG，不是 JetBrains 也不是华为官方发布。这不代表它不好——恰恰相反，这种"生态底座"通常就是靠社区 SIG 一点点啃出来的——但你心里的预期要摆正：

  • 长期维护性取决于社区活跃度，不像官方 API 那样有明确承诺
  • 遇到问题，答案在社区（Issue/Discussion），不在官方文档里

第二，API 19+ 才能用统一渲染。

如果目标设备里有大量低版本鸿蒙，那这项最大的性能红利你吃不到，得评估一下自己的设备分布。

第三，但它解决的是个真问题。

跨平台上鸿蒙，过去的选项基本是两个：

  • 要么鸿蒙端单独写 ArkUI，维护两套 UI
  • 要么放弃鸿蒙，等官方支持

现在多了第三条：共享逻辑照写，Compose UI 复用，ArkTS 存量用 akinterop 桥接。

对一个已经投了 KMP 的团队来说，这个第三条路的性价比，是很难忽视的。

放回这几天的脉络里看

有意思的是，这事跟咱们前两天聊的两个话题，正好串成了一条线。

Jake Wharton 那篇里，他说得很清楚：

会 Kotlin 已经不是职业优势了……但掌握 Kotlin Multiplatform 这类相对进阶的能力，仍然可能构成差异化优势。

Shopify 那篇的结论是：AI 把"重复实现"变便宜之后，“共享 UI 派"受冲击最大，而"共享逻辑 + 原生 UI"这条路更抗打。

然后是今天：KMP 的版图，又扩了一块——而且是块很大的版图。

三件事指向同一个方向：跨平台的价值，正在从"省人力"转向"架构治理 + 生态覆盖”。

一个平台一个平台地啃下来，本来就是 KMP 这条路线的核心叙事。鸿蒙这块拼图补上，对国内开发者尤其是——它可能是很多人第一次真正有理由认真看 KMP。

最后留个问题给大家：

如果鸿蒙能用 Compose 写 UI，你会为它单独维护一套 ArkUI，还是直接把 KMP 项目扩到鸿蒙？

还有——你手上的项目，鸿蒙是"必须做"还是"再看看"？

评论区聊聊，我挺想知道大家的真实处境。

参考资料：