鸿蒙与KMP融合：跨平台业务逻辑共享架构实战指南

1. 为什么这个时间点，我要认真聊鸿蒙和KMP的融合

我打开热搜词榜单的时候，一眼就看到了几个非常有意思的组合：“harmonyos”“kmp开发app”“跨平台音乐管理系统v2.0源码”“voracious跨平台视频播放器 复读机”，还有一个诡异的“kmp算法”。这几条热搜词放在一起，基本上就是国内移动端开发者当前最真实的困惑：鸿蒙（HarmonyOS）生态起来了，要不要接入；KMP（Kotlin Multiplatform）作为跨平台方案值不值得跟；如果两个都想做，它们到底怎么共存。

我这两年正好在同时折腾两条技术线：一边是公司内部鸿蒙应用的落地，一边是个人项目用 KMP 做 Android/iOS 的双端共享。两条线刚开始是平行的，但做着做着就发现，它们迟早要汇合。原因很简单：没有哪家公司愿意同一个业务逻辑在 Android、iOS、鸿蒙三套代码里各写一遍，也没有哪个团队养得起三套纯原生的维护成本。所以“鸿蒙 + KMP”不是两个孤立的技术选型，而是未来两三年移动端架构绕不开的交汇点。

如果你想直接搜“kmp开发app”，大概率搜到的是字符串匹配算法，而不是跨平台框架。这本身就说明，很多人在刚刚接触这个领域时，是被同一个缩写带偏过的。我在这篇里会从底层原理、现有可落地的对接方式、真实架构案例到踩坑排查，完整讲一遍。适合三类人看：正在评估鸿蒙适配路线的技术负责人、已经在用或准备用 KMP 的双端开发者、以及对跨平台方案有点懵但想系统搞清楚的移动端新人。

2. 先搞清楚 KMP 的边界：它到底能跨什么、不能跨什么

2.1 KMP 不是 UI 跨平台框架，这是最大的前提

很多人第一次听到 Kotlin Multiplatform，会天然把它和 Flutter、React Native 归成一类——以为是一套 UI 写三端。这是最大的误解。KMP 骨子里不是 UI 跨平台方案，它是业务逻辑跨平台方案。你共享的是网络请求、数据仓库、领域模型、状态管理、工具函数，而不是界面控件。

如果你开了 Compose Multiplatform，那确实可以把 UI 层也用 Compose 统一，定制能力不如原生渲染，做不到像素级还原，而且它没有针对鸿蒙做适配。KMP 本身也一样，截至我写这篇内容时，Kotlin 官方的目标平台列表里没有鸿蒙这一项。所以纯粹指望“KMP 一套代码直接跑鸿蒙”，目前没有官方通道。后面的融合方案，都得在这个现实前提下来谈。

2.2 真正适合放进 KMP 共享模块的代码

我在自己的音乐类项目里把代码拆成三层：展示层、业务层、数据层。最终进入共享模块的是业务层和数据层里与平台无关的那部分代码。具体来说，下面这些非常适合共享：

• 领域模型和数据模型类（Track、Playlist、User、Order 这类纯数据结构）
• 网络协议的请求和响应 DTO，以及对应的序列化逻辑
• 业务校验规则，比如播放倍速的范围判断、缓存过期策略、订阅到期的计算
• 本地偏好的读写封装（利用 multiplatform-settings 这类库）
• 日志埋点的事件定义和参数拼装
• 通用的时间、金额、单位换算工具函数

反过来说，UI 组件、平台推送、指纹识别、蓝牙连接、需要在特定系统上调用硬件能力的模块，都不适合放进共享层。哪怕强塞进去，你最后也得为每个平台写一把 actual 实现，折腾的成本比直接各写各的还高。

2.3 三端现状：Android、iOS、鸿蒙的成熟度差距

我可以给你一张我评估过很多次的对照表，方便你快速判断当前生态：