KMP & CMP 鸿蒙化 v1.1.0 发布：统一渲染、性能与稳定性全面升级

MIGAOTEC

17人浏览 · 2026-10-13 20:28:45

MIGAOTEC · 2026-10-13 20:28:45 发布

KMP & CMP 鸿蒙化 v1.1.0 发布：统一渲染、性能与稳定性全面升级

本文基于 CPF-KMP-CMP/docs 社区的发布说明
KMP-v2.2.21-1.1.0 & CMP-v1.9.2-1.1.0 撰写。

一、背景：KMP/CMP 鸿蒙化是什么

Kotlin Multiplatform（KMP）与 Compose Multiplatform（CMP）让开发者用一套 Kotlin 代码同时覆盖 Android、iOS、桌面等平台。但长期以来，HarmonyOS 一直是缺失的一块——官方 KMP/CMP 工具链没有提供鸿蒙目标。CPF-KMP-CMP 社区（文档仓库见 atomgit.com/CPF-KMP-CMP/docs）的工作，就是把 Kotlin 工具链、Compose 运行时、Skia 渲染层（skiko）逐层适配到 OpenHarmony/HarmonyOS 上，让 CMP 应用可以真正跑在鸿蒙设备上。

本次发布（KMP v2.2.21-1.1.0 / CMP v1.9.2-1.1.0）基于社区 Kotlin 2.2.21 与 Compose Multiplatform 1.9.2 进行适配，是工具链走向成熟的一次重要版本：核心升级集中在统一渲染架构与GC/runtime 稳定性两条主线。

二、发布版本全景

2.1 KMP/CMP 鸿蒙版本信息

名称	版本号	是否发布 Maven 仓
kotlin	2.2.21-1.1.0	已发布
compose-multiplatform	1.9.2-1.1.0	已发布
compose-multiplatform-core	1.9.2-1.1.0	已发布
skiko	0.9.22.2-1.1.0	已发布
akinterop	1.1.0	已发布

2.2 配套开发工具链

名称	版本号	是否发布插件市场
KMP OHOS Support	1.0.0	已发布

2.3 配套 IDE、SDK 与手机 ROM

名称	版本号
DevEco Studio	6.0.0 及以上
HarmonyOS SDK	API17 及以上
Android Studio（Mac）	Hedgehog（2023.1.1 Patch 2）及以上
Android Studio（Windows）	Otter 2 Feature Drop（2025.2.2 Patch 1）及以上
手机 ROM	最低 API17，部分特性依赖更高 API Level

可以看到，整套适配已经形成闭环：从编译器（kotlin）、UI 框架（compose-multiplatform-core）、图形后端（skiko）、互操作层（akinterop），到 IDE 插件（KMP OHOS Support），全部随版本同步发布到 Maven 仓与插件市场，开发者开箱即用。

三、核心特性解读

3.1 统一渲染：从"自渲染孤岛"到"融入图形栈"

统一渲染是本版本最大的亮点，它解决的是 CMP 在鸿蒙上最根本的架构问题——Compose 自己开 Surface 自绘，还是接入系统 ArkUI 渲染管线。

（1）与图形垂直整合，吃满系统优化红利

渲染流程与 HarmonyOS 图形栈垂直整合后，系统级典型优化（D-vSync、增量 OP 优化等）能够直接作用于 CMP 页面：整体负载降低约 3%，单帧渲染性能提升约 10%。这类优化在自渲染方案下是无法享受的，是"融入"而非"旁挂"架构的直接收益。

（2）对接 ArkUI CAPI RenderNode，干掉 70MB 内存开销

此前 CMP 自渲染会额外引入一层多 buffer 的内存负荷，每个实例约 70MB。本版本在 HarmonyOS 侧对接了 ArkUI CAPI 的 RenderNode，页面加载更快，同时彻底消除了这 70MB/实例的额外内存开销。对多实例、长列表、重 Compose 的应用来说，这是实打实的减负。

（3）Fusion 混排（三明治架构）的若干修正

对于"原生控件夹 Compose"的混合渲染场景，本版本做了多项关键修复：

子节点顺序修正为 BACK → Compose → FORE → TOUCHABLE：避免后置 Surface 盖住 Compose 内容——这是混排场景下非常典型的"白屏/内容被遮挡"问题的根治；
新增自动化输入代理：在 Fusion Renderer ArkUI 宿主中支持 uitest uiInput text，为自动化测试（UI 自动化、稳定性回归）补上了输入通路；
弹窗并行录制仅限 Skia 后端开启：避免 Fusion 模式在 FFRT 子线程析构 RenderNode 导致 abort；
Skiko Overlay 双产物 + 零配置链接插件：OHOS 侧上线 api 与 fusion overlay 双产物，零配置链接插件支持 K/N 增量编译；同时在 Overlay/mode=both 下让 Fusion hide 时延迟清理跳过 Skia heavy teardown，避免无 DirectContext 时的 SIGSEGV。

这一组修复的共同主题是：把 Fusion 混排从"能跑"推进到"稳跑"——崩溃、遮挡、测试盲区逐一收口。

3.2 common GC/runtime：一个看似微小的修复

restrace（资源回收追踪）的 heap size 读取被挪到 RunFinalizers 之前，且仅在 restrace 真正启用时才计算。此前若 finalize 回调销毁了 meta-object，之后再读 typeInfoOrMeta_ 会触发偶发 crash。虽然改动只有几行，但它消除的是"低概率、难复现、堆栈指向 runtime 内部"的疑难崩溃——这类问题对上层开发者几乎不可排查，只能靠运行时侧根治。

四、对开发者意味着什么

升级成本可控：所有组件均已发布 Maven 仓，配合 KMP OHOS Support 1.0.0 插件，工程侧基本只需对齐版本号与 IDE/SDK 环境（DevEco Studio 6.0.0+、HarmonyOS SDK API17+）。
性能可感知：渲染负载 -3%、单帧 +10%、内存 -70MB/实例，三项叠加对中大型 Compose 应用的体验提升是可测量的。
稳定性更扎实：Fusion 混排的 SIGSEGV/abort 修复与 runtime 偶发 crash 修复，显著降低了混合开发与长时运行场景的崩溃率。
可测试性补齐：uitest 输入代理让鸿蒙侧的 UI 自动化测试第一次在 Fusion 模式下成为可能。