通用 agent 写 ArkTS 会翻车，原因就三个洞。它不认识 ArkTS 的装饰器和构建命令；它手里没有一份能查的官方文档，只能凭印象编 API；就算代码写对了，它也不知道怎么把包构建出来、装进设备、送到应用市场。

洞可以一个个堵。华为和社区把堵洞的东西做成了可以外挂的工具，从零装到能用是八步。这篇按顺序走一遍，每一步给命令，也给该看到的输出。最后拿 DeepSeek Harness 把三样接进一个真 agent，看它到底认不认。

要装的是四件东西

DevEco Studio 或者它的命令行工具是地基，构建、设备、签名这些真活都在它身上。@deveco/deveco-cli 是工具集，命令名 devecocli，负责把能力装进别的 agent。

两个 MCP 分工不一样。远程的开发者知识 MCP 管查文档，本地的 deveco-mcp 管 .ets 和 C、C++ 的语法检查。最后一件是 agc-cli，社区写的上架命令行，把 AGC 后台的操作搬回终端。

另外先备一个华为开发者账号，装地基和生成签名都要用。

第一步：装地基

去开发者联盟的下载中心（developer.huawei.com/consumer/cn/download/），登录后选 macOS 版。Apple Silicon 的机器要的是 macOS ARM 那一档。

装完记一下路径，默认是 /Applications/DevEco-Studio.app。这一步不能跳，devecocli 后面所有的真活都要它。

不想装整个 IDE 的话，另一条路是同一页面上的命令行工具。体积小得多，但官方专门提了一句：

Set DEVECO_CLI_CLT_PATH to the Command Line Tools root when DevEco Studio is not installed; CLT is not discovered automatically from PATH or default installation directories.

它不会自己从 PATH 或者默认目录里被发现，必须手写环境变量指过去：

# 装了 IDE
export DEVECO_CLI_STUDIO_PATH=/Applications/DevEco-Studio.app
# 只装命令行工具
export DEVECO_CLI_CLT_PATH=$HOME/command-line-tools

写进 ~/.zshrc 才会一直生效。Studio 首次启动会引导下载 HarmonyOS SDK，这一步要联网，也慢，别在没网的地方干等。

第二步：装 devecocli 工具集

两个 npm 包一起装：

npm install -g @deveco/deveco-cli @deveco/deveco-code

装出来两个命令。deveco 是 Agent 本体，基于 OpenCode 定制；devecocli 是工具集。两个包 255 个依赖、267 MB。

装完先验一下，别急着往下走：

devecocli --help
devecocli device list

第二条会列出连着的设备。如果它报 DevEco Studio 找不到，问题不在这一条命令上，回头查第一步那个环境变量。

第三步：把技能包装进你的 agent

这是「任意 agent」那一半的答案，一条命令：

devecocli init --skill --agent dsh,cursor,codex

不给 –agent 就是装到所有能识别的宿主。想装到指定目录用 –path，要覆盖已有配置加 -f。

装进去的东西长这样：

node_modules/@deveco/deveco-cli-common/SKILL.md

24,690 字节，开头的触发条件写得很直白：

Use ‘devecocli’ for HarmonyOS apps (scaffold, build, run, debug, devices, emulators, logs, docs, UI inspection, 鸿蒙开发文档, skills). Use it if workspace has build-profile.json5 or oh-package.json5, or user mentions HarmonyOS, 鸿蒙, DevEco, ArkTS, ArkUI …

agent 读到它之后，碰到鸿蒙工程或者提到鸿蒙，就会自己想到用 devecocli。同一个包还带着一份离线文档语料，docs.zip 有 40.5 MB，解开是 31,477 个文件，另加 15.2 MB 的检索索引。devecocli docs search 查的就是它，不联网也能用。

支持的宿主是官方给的名单：atomcode、codebuddy、claude-code、codex、cursor、dsh、deveco、opencode、pi、qoder、trae-cn，十一个。名单外的宿主也有条土路，技能包说到底就是一个 Markdown 文件加一份文档语料，把它放进那个宿主的 skill 目录就是同一回事。

想批量装或者查已经装了什么，走 skills 子命令：

devecocli skills list
devecocli skills add --all

第四步：装本地那个语法检查 MCP

devecocli init --mcp

它配的是 deveco-mcp，一个 stdio MCP，只暴露一个 check 工具，专门给 .ets、C、C++ 做语法检查。接进 agent 之后，它每改完一轮代码先自查一遍，不用等整包构建才报错。官方在说明书里还叮嘱了一句，一轮编辑跑一次就行，不要每次编辑都跑。

官方另有一句限定：所有支持的宿主都能配全局和项目级 MCP，只有 qoder 不支持项目级。

这个服务能手动起，调试的时候用得上：

devecocli serve mcp

它认几个环境变量，PROJECT_PATH、DEVECO_PATH，还有调 Node 内存上限的 NODE_MAX_OLD_SPACE_SIZE。

第五步：接官方知识 MCP

这一件最通用，任何支持 MCP 的客户端都是往配置里塞一段：

{
  "mcpServers": {
    "harmonyos_developer_knowledge": {
      "url": "https://connect-api.cloud.huawei.com/api/developerknowledge/mcp",
      "type": "http"
    }
  }
}

DevEco Code 自己带 MCP 管理命令，一行就够：

deveco mcp add harmonyos_developer_knowledge \
  --url https://connect-api.cloud.huawei.com/api/developerknowledge/mcp

跑完它会自己报状态：

●  ✓ harmonyos_developer_knowledge connected

它只有两个工具。searchDocuments 按关键词搜，返回匹配的文本块和文档标识；getDocumentsById 拿标识换全文，一次最多十篇。成本要有数：搜一次三千字符左右，拉一篇全文三万五千字符，别让它一次拉十篇。官方说这份语料跟官网准实时同步，延迟不超过 30 分钟，这是这条路跟「让模型凭记忆答题」最要紧的差别。

以 DeepSeek Harness 为例：三件东西怎么落到一个真 agent 上

前面几步讲的是做什么，这一节拿 dsh 走一遍落到哪。它正好在官方那份宿主名单里，所以三件东西都能自动接。

技能包一条命令，落到 dsh 自己的技能目录：

devecocli init --skill --agent dsh
ls ~/.dsh/skills

目录结构跟它已有的技能一模一样，一个目录一份 SKILL.md，文件开头就两行 frontmatter，写 name 和 description。这台机器的 ~/.dsh/skills 里原本已经躺着七个 memorix- 开头的技能，deveco-cli 进来之后跟它们并列。

MCP 要写进 dsh 的配置文件 cordis.patch.yml。它的配置是一层层的 profile patch，MCP 走它自己的 mcp-client 插件，一个服务一条记录。知识 MCP 写进去是这样：

- insert:
    - id: mcp-harmonyos-knowledge
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: harmonyos_developer_knowledge
        transport: streamable-http
        url: https://connect-api.cloud.huawei.com/api/developerknowledge/mcp

本地那个语法检查 MCP 只换 transport 和启动命令：

    - id: mcp-deveco-syntax
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: deveco
        transport: stdio
        command: devecocli
        args: [serve, mcp]

它只认两种 transport，stdio 是本地起的进程，streamable-http 是服务端。几个默认值值得知道：单次工具调用超时 60 秒，服务端下发的指令上限 32,768 字节，连接断了会自己重连，最多连试十次。

改完不用重启去猜，dsh 有 dump 命令，能把合成后的配置整个打出来：

dsh --profile <你的 profile> --patch ./hw-mcp.yml --dump-config

配置合成进 profile 树之后，工具名就真的出现在它的工具表里了，我拿一个隔离的 DSH_HOME 跑过一遍：

mcp__harmonyos_developer_knowledge__searchDocuments
mcp__harmonyos_developer_knowledge__getDocumentsById

命名规则是 mcp 加两个下划线加服务名加工具名，所以同一个 agent 里挂好几个 MCP 也不会撞名。到这一步，你在 dsh 里问一句鸿蒙的接口怎么写，它会先去查官方文档，而不是凭印象编。

第六步：登录与签名

要真机跑，这一步绕不过去。

devecocli auth login

它会开浏览器走华为开发者账号的 OAuth。登录状态用 devecocli auth status 看，加入的团队账号用 devecocli auth team list 列。然后生成签名：

devecocli signature generate --product default

顺序官方给得很清楚，auth login、signature generate、build、run，一步都不能少。漏了哪步都有对应的报错：没登录会说 Not logged in. Run devecocli auth login first，令牌过期说 Invalid AccessToken. Sign in and try again，签名换了说 error:install sign info inconsistent，这时候 run 加 –uninstall，或者签名重新生成时加 –force。

第七步：装 agc-cli

上架走 AGC，以前只能在浏览器里一页页点。这个开源命令行把接口整理成一张可检索的注册表，实测 159 个接口、13 个家族，每条都带方法、路径、必填参数，还有一条指回华为官方文档的 sourceUrl。

Homebrew 那条路要先信任它的 tap：

brew tap createitv/tap
brew trust createitv/tap
brew install agc-cli

或者直接下官方 Release 的预编译二进制，有 darwin_arm64 的包，核完哈希再用：

shasum -a 256 agc-cli_0.2.0_darwin_arm64.tar.gz
./agc version

凭据有三种配法，走一种就行：

agc auth login --client-id <id> --client-key <key>
agc auth login --api-client-file client.json
agc auth login --service-account-file sa.json

agc auth check 看当前生效的是哪一套，agc auth list 列已存的所有档，agc auth token 给当前这档签一个临时令牌。

它默认只预演，真发之前你会先看到请求长什么样：

agc publishing app-info-query --invoke --query appId=123456789
{"data":{"method":"GET","url":"https://connect-api.cloud.huawei.com/api/publish/v2/app-info?appId=123456789&lang=zh-CN","dryRun":true}}

确认没问题，再显式加 –dry-run=false 才真发。每个接口的返回里还带一段 affordances，写着下一步能跑哪条命令。agent 不用背命令树，顺着返回往下走就行。

第八步：跑一遍，看它自己验货

装完这些，从工程到设备是一条直链：

devecocli build
devecocli emulator list
devecocli emulator start "Phone"
devecocli run

模拟器第一次用要先接受协议，交互式是 devecocli emulator license，要 TTY，脚本里用 devecocli emulator license accept。镜像下载失败别连着重试，官方说得很直白，这条交给用户手动跑。

跑完看工程里多出来的两个目录。.verify 放校验产物，docs/screenshots 放截图，后面这个是自动跑出来的：

docs/screenshots
  01-home.png                          首页
  03-quick-entry.png                   快捷记账
  05-stats-mpchart.png                 统计图表
  06-stats-retry.png                   统计失败后重试
  08-trip-edit.png                     行程编辑
  09-home-empty.png                    空态
  10-real-device-home.png              真机
  11-real-device-trip-detail-finish.png
  12-light-home.png                    浅色
  15-dark-home.png                     深色
  19-dark-to-system-fixed.png

编号从 01 排到 19。里面有两张真机截图，说明它把包装进设备真跑过；浅色、深色各一套，说明主题切换也在它的流程里；还有空态和统计失败后的重试态，说明它不满足于走顺路，会把边角的状态一个个摆出来。这些都不是手截的。

这一步的意义在闭环。以前 agent 写完代码交给你，好不好看得你自己去看；现在它能自己看到结果，截图落成文件，下一轮改什么就有依据。这也是我更愿意把 devecocli 归到「工具」而不是「客户端」的原因：它不是替你写代码的那只手，它是让 agent 能自己验货的那只眼。

每步一条验证命令

装完别靠感觉，一条条过：

devecocli --help                  # 工具集在
devecocli device list             # 找得到设备
devecocli docs search ArkTS       # 离线文档在
devecocli skills list             # 技能包装上了
deveco mcp list                   # 知识 MCP 连上了
devecocli auth status             # 登录状态
agc auth check                    # AGC 凭据配好了
agc endpoints                     # 注册表读得到

哪条不对，问题就在它对应的那一步，不用到处翻。

一点判断

四件东西里我会先装哪件？先装地基，因为它卡着后面全部。但如果你只想花二十分钟试水，那就先接远程的知识 MCP，一个 URL、不用设备、不用账号，堵的又是最致命的那个洞。

顺序别倒过来。技能包和本地 MCP 都挂在 devecocli 上，devecocli 的真活又挂在 DevEco Studio 上，地基不牢，后面每一步都会撞同一句话。

你现在让自己常用的 agent 写鸿蒙代码吗？它最常在哪一步翻车？评论区聊聊。

前段时间我写过一篇鸿蒙 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 发布说明。

先说个数字：四。

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 项目扩到鸿蒙？

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

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

参考资料：

• KMP&CMP 鸿蒙首版本正式发布（快科技/驱动之家，2026-09-15）
• 文档集合：AtomGit 搜索 CPF-KMP-CMP/docs