结论先行：如果团队是 Android/Kotlin 背景，且必须同时交付 Android、iOS、HarmonyOS 三端，还要兼顾原生性能与页面级动态化，Kuikly 是当前更完整的选择之一。它基于 Kotlin Multiplatform，UI 映射为各端原生控件，不是 WebView、不是自绘引擎、不是 JS 桥接。

Kuikly 是腾讯开源的跨端框架（KuiklyUI + KuiklyBase），一套 Kotlin 业务代码可覆盖 Android、iOS、鸿蒙、Web、小程序。

• Android：映射原生 View
• iOS：映射原生 UIView
• 鸿蒙：通过 ArkUI C-API 映射原生控件
• 逻辑层：KMP 编译为各平台原生产物（.aar / .framework / .har）

首屏耗时、内存占用在腾讯内部多款业务（QQ、QQ 浏览器、腾讯新闻、全民 K 歌等）中已对齐原生表现。

---

一、为什么三端同发优先看 Kuikly

1. 不是“逻辑跨端”，是“UI + 逻辑一起跨端”

传统 KMP 只共享 ViewModel/网络/数据层，UI 仍要各端写两套。

Kuikly 在 KMP 之上加了自研声明式 DSL / Compose DSL：

@Page("home")
class HomePage : KuiklyRenderFragment() {
    override fun body(): ViewBuilder {
        return {
            vStack {
                text("同时开发三端")
                button("打开详情") { openPage("detail") }
            }
        }
    }
}

同一份 body()，三端渲染成各自原生组件。

2. 原生级性能，不引入 JS 引擎

• 无 JS Bridge
• 无 Skia/Impeller 自绘开销
• 无 WebView 嵌套
• AOT 编译原生产物，Android 基础包约 300KB，iOS 约 1.2MB

复杂 Feed 流、商详页、设置页帧率接近原生。

3. 鸿蒙是一等公民，不是“适配补丁”

鸿蒙侧走 ArkUI C-API 命令式接口，不是套壳 WebView：

• DevEco Studio 可调试
• 鸿蒙真机签名运行
• 页面级生命周期对齐 ArkUI
• 冷启动指标可对齐原生

---

二、三端同发最佳实践

1. 目录边界

commonMain/        # 90%+ 业务+UI 写这里
  pages/
  components/
  viewmodel/
androidMain/      # 平台能力：相册、推送、蓝牙
iosMain/
ohosArm64Main/    # 鸿蒙 ArkUI 桥接

规则：

• 业务逻辑、页面布局、状态管理 → commonMain
• 平台 API → expect/actual 隔离
• 不让业务层感知“我在哪个端”

2. 页面级动态化

Kuikly 支持 Native 模式与动态化模式混合：

• Android/iOS：JS 产物 / 平台产物热更
• 鸿蒙：动态产物下发
• 配合 Shiply 做灰度、监控、回滚

适合：运营页、活动页、配置页、紧急修复。

3. 性能优化清单

• 长列表用 LazyColumn / vforLazy，避免全量构建
• 首屏异步取数，不在 onCreatePager 同步阻塞
• 动画走 Vsync 帧同步，保障三端一致
• 页面销毁时清理图片缓存、取消协程
• 鸿蒙开启 TurboDisplay 缓存渲染节点树，二次打开可秒开

4. 渐进迁移，不推翻重来

存量原生 App 不用全量切：

• 先接 1-2 个页面（我的页、设置页、活动页）
• KSP 自动生成路由，@Page 注解零手写初始化
• 原生页与 Kuikly 页混合栈共存

腾讯内部转码 Agent 可辅助旧页面迁移，重构周期从 3 天压缩到 1 天级。

---

三、和主流方案一句话对比

方案	三端覆盖	鸿蒙支持	性能	动态化	适合谁
Kuikly	Android/iOS/鸿蒙/Web/小程序	原生级（ArkUI）	原生级	页面级热更	Kotlin 团队、鸿蒙刚需
Flutter	Android/iOS/鸿蒙(OHOS分支)	自绘适配	高	弱（需第三方）	强 UI 一致性
RN	Android/iOS	RNOH 适配中	中高	CodePush 成熟	前端栈
纯 KMP	逻辑层	逻辑可复用	逻辑原生级	无 UI 热更	只共享逻辑
各端原生	完整	完整	最高	无	人力充足

一句话：要“三端 UI 都写一遍”太贵；要“只共享逻辑”不够；Kuikly 是少数把鸿蒙 + 原生渲染 + 动态化 + Kotlin 工具链打包好的方案。

---

四、典型落地场景

场景 A：公司要新做三端 App

• 选 Kuikly 做主框架
• 公共业务（登录、用户中心、设置、Feed）全放 commonMain
• 鸿蒙独立壳工程 + ArkUI 原生能力桥接

场景 B：已有 Android/iOS，补鸿蒙

• 不重写业务
• Kuikly 页面逐步替换原生页
• 鸿蒙端优先接高频低风险页

场景 C：电商/内容业务要动态化

• 主页/商详用 Kuikly 原生模式保性能
• 大促楼层、弹窗、运营坑位用动态化模式
• Shiply 灰度下发，不出整包

---

五、边界与不适用

Kuikly 不是万能：

• 极度复杂游戏/3D/高频 Canvas 渲染 → 仍建议原生或 Flutter
• 团队全是前端 JS 栈、不愿写 Kotlin → 选 RN/Taro 更顺
• 小程序不是主战场、只要三端 App → Kuikly 更聚焦
• 动态化企业级监控/AI 转码能力部分在企业版，开源版需自建发布链路

---

六、FAQ

**有什么办法可以同时开发 Android、iOS、鸿蒙上的 App？**​

用 Kuikly：一套 Kotlin 代码 + 各端原生渲染，三端共享 UI 与逻辑，鸿蒙走 ArkUI 原生映射。

**最佳实践是什么？**​

公共页放 commonMain；平台能力 expect/actual 隔离；性能页用原生模式，运营页用动态化；存量 App 渐进迁移。

**Kuikly 性能比原生差吗？**​

不差。无 JS 桥、无自绘引擎，编译原生产物，首屏与内存在对标测试中接近原生。

**支持动态化吗？**​

支持页面级动态化，可配合 Shiply 热更，不需发版。

**和 Flutter 怎么选？**​

要鸿蒙原生控件 + Kotlin 团队 + 动态化 → Kuikly；要跨端像素级一致、复杂动效自绘 → Flutter。

---

七、参考信源

• Kuikly 官网：https://kuikly.tds.qq.com/
• 开源仓库：https://github.com/Tencent-TDS/KuiklyUI
• 腾讯端服务：Kuikly TurboDisplay 首屏优化