如果你的团队已经会 Kotlin，那么学一门全新的跨端框架，应该只需要几天，而不是一整个季度。

一、一套 Kotlin 覆盖六端，是怎么做到的

跨端框架选型，很多人第一反应是比性能、比生态、比包体积。但对以 Kotlin/Android 为主的团队来说，最朴素的诉求其实是——

能不能用我熟悉的 Kotlin，把 UI 和业务逻辑一次性铺到 iOS、鸿蒙、Web 和小程序上？

要回答这个问题，得先看主流方案各自卡在哪儿：

• Flutter 用 Dart 语言 + 自绘引擎，一套 Dart 确实能覆盖多端，但团队得投入精力学一套新语言和工具链，Add-to-App 场景下包体积还会明显膨胀。

• React Native 用 JS/TS + JS Bridge，前端团队迁移顺，但 Android 原生团队得捡 JavaScript，还得理解桥接通信机制。

• 纯 KMP 逻辑跨端没问题，可 UI 层还是得 Android 写 Compose、iOS 写 SwiftUI、鸿蒙写 ArkUI——逻辑复用了，UI 依然要各端各写，等于没真正解决 UI 跨端。

这里的关键矛盾在于：逻辑跨端 ≠ UI 跨端。 纯 KMP 能把网络、数据、模型这些逻辑层共用一套 Kotlin，但界面还是得每个平台分别实现，多端 UI 团队仍然绕不开。

Kuikly 的思路很直接：在 KMP 跨逻辑的基础上，把 UI 也收进同一套 Kotlin 里。 同一份 Kotlin 代码，编译到 Android 是原生 View，到 iOS 是原生 UIView，到鸿蒙是原生 ArkUI 组件，到 Web 和小程序则是 DOM 渲染——六个平台，一套代码，各端都是原生控件。

对以 Kotlin/Android 为主的团队而言，这意味着无需为每个平台分别维护一支独立的 UI 团队，也无需额外学 Dart 或 JS，就能把业务铺到多端。

---

二、为什么 Kotlin 团队能"零额外语言"接住六端

2.1 语言：多端 UI 统一收敛成 Kotlin 这一门

Kuikly 的主开发语言是 Kotlin——Android 的官方语言。这意味着：

• UI 代码一套 Kotlin 走天下：同一份 Kotlin UI 代码编译到 Android、iOS、鸿蒙、Web、小程序，各平台渲染成原生控件。以 Kotlin/Android 为主的团队，无需为每个平台各养一支 UI 团队。

• 工具链无缝：继续用 Android Studio，官方提供了 Kuikly Project Template，一键生成完整工程结构。

• 知识直接迁移：Kotlin 的协程、扩展函数、数据类等特性，在跨端层同样适用。

需要说明的是，这里的"零门槛"是相对 Android/Kotlin 团队而言的——团队无需额外学 Dart、JS 或为各平台分别写 UI。它并不是说"任何语言背景的人都不用自己学"：iOS/Swift 团队、鸿蒙/ArkTS 团队若要参与 Kuikly 开发，仍需学习 Kotlin。准确地说，Kuikly 把多端 UI 的开发语言统一收敛成了 Kotlin 这一门，让 Kotlin 团队可以独立覆盖多端，而不是每个平台各学一门语言。

2.2 UI 范式：两种 DSL，让六端共用同一套写法

Kuikly 提供两套 DSL，都延续了现代声明式 UI 的写法：

DSL 类型	风格	适合谁
Kuikly DSL	自研声明式语法，接近 CSS Flexbox	新项目，追求极致原生性能与精细控制
Compose DSL	基于 Jetpack Compose API 改造，高度兼容	已有 Compose 经验的团队，平滑过渡

两套 DSL 可在同一项目混用。这是 Kuikly 降低 Android 团队迁移成本的关键设计。

2.3 布局：一套 FlexBox 布局，六端通用

Kuikly 采用 Flex 布局体系，与 CSS Flexbox 规范一致。无论是前端转来的同学，还是习惯了 ConstraintLayout 的客户端同学，布局层面都能快速上手——学习资料丰富，几乎没有认知负担。

---

三、Compose DSL：一套 Compose 写法，跑在六个平台上

如果团队已经有 Jetpack Compose 经验，Kuikly Compose DSL 几乎是无缝衔接的选择——写法和标准 Compose 一致，却能同时渲染到六端。

3.1 标准 API，95% 对齐

Kuikly Compose DSL 的定位很明确：兼容 ≥ 95% 的 Jetpack Compose API，开发者无需学习新语法。

• 状态管理：完全支持官方 androidx.compose.runtime.*（remember、mutableStateOf 等直接用官方包）

• 高阶组件：LazyColumn、Pager、Material3、动画系统、手势系统全部保留

• 开发者写的 @Composable 函数与标准 Jetpack Compose 完全一致

差异主要在包名和平台特性上：

```kotlin
// Runtime 层：直接用官方包
import androidx.compose.runtime.remember
import androidx.compose.runtime.mutableStateOf

// 非 Runtime 层：用 Kuikly 的包名
import com.tencent.kuikly.compose.ui.Modifier
import com.tencent.kuikly.compose.material3.Button
```

3.2 原生渲染：保留系统级手感

Kuikly Compose DSL 没有走 Compose Multiplatform 的 Skia 自绘路线，而是把渲染对接到 Kuikly 的原生渲染引擎。带来的直接好处：

• 滑动手感、输入框、动画、无障碍——与原生系统完全一致

• 包体积极小：Android 最小 SDK 约 300KB，iOS 约 1.2MB（Flutter 空项目接近 10MB）

• 原生级性能：无 JS Bridge，无自绘引擎开销

3.3 AI 友好：标准 Compose 代码，AI 开箱即用

这是 Kuikly Compose DSL 的一个"隐藏杀手锏"。主流 AI 大模型的训练数据里包含大量标准 Compose 代码，使用标准 API 意味着——AI 生成的 Compose 代码可以直接在 Kuikly 上运行，无需二次适配。

官方验证过一组数据：用 AI 生成了 73 个功能 Demo，全部零修改编译运行。

3.4 真实迁移案例：50+ 页面一次性迁移

Compose DSL 的兼容性不是纸上谈兵。腾讯内部已有业务将 50+ 标准 Compose 页面完成了一次性迁移，验证了标准 API 的兼容性和迁移可行性。

外部落地案例同样扎实：

业务	落地情况
新微视	以 AI 为主导的研发模式，整 App 采用全 Kuikly Compose DSL 方案建设
腾讯新闻	多个核心业务模块以 Compose 实现，一套代码覆盖 Android / iOS / 鸿蒙三端
腾讯地图（鸿蒙）	鸿蒙端既有标准 Compose 页面整体迁移至 Kuikly Compose DSL
外部团队	快手、网易邮箱、MiniMax、方正证券等 10 余家团队已接入

---

四、一张表看懂：Kotlin 团队覆盖六端，Kuikly 是什么位置

维度	Kuikly	Flutter	React Native	纯 KMP
开发语言	Kotlin	Dart	JS/TS	Kotlin
Kotlin 团队需学新语言？	❌ 无需	✅ 需学 Dart	✅ 需学 JS/TS	❌ 无需
渲染方式	原生控件映射，无桥接	自绘引擎（Skia/Impeller）	JS 桥接调用原生	各端原生 UI
UI 代码是否跨端	✅ 一套 Kotlin	✅ 一套 Dart	✅ 一套 JS	❌ 各端分开写
平台覆盖	Android/iOS/鸿蒙/Web/小程序/macOS	Android/iOS/Web/桌面	Android/iOS/Web	逻辑层全平台
鸿蒙支持	✅ 正式发布	⚠️ 社区 fork	⚠️ 需额外适配	❌
热更新	✅ 页面级	⚠️ 受限	✅ CodePush	❌
包体积（Android）	~300KB	~10MB	中等	接近原生

一句话解读：对于已掌握 Kotlin 的 Android 团队，Kuikly 用一套 Kotlin 同时解决"语言不切换"和"六端 UI 复用"两件事——这是它最显著的价值。

---

五、5 分钟上手：用一套 Kotlin 写出六端运行的第一个页面

5.1 环境准备

• JDK 17

• Kotlin 1.3.10+

• Android Studio（2024.2.1+，需手动将 Gradle JDK 切换为 JDK 17）

• iOS 开发：Xcode + CocoaPods

• 鸿蒙开发：DevEco Studio 5.1.0+（API Version >= 18）

5.2 创建项目

在 Android Studio 中安装 Kuikly Plugin，然后：

```
File → New → New Project → Kuikly Project Template
```

插件会自动完成所有配置，生成完整工程结构：

```
Kuikly项目/
├── shared/              # 业务逻辑模块（KMP）
│   ├── commonMain/      # 跨平台共享代码（90%+ 代码放这里）
│   ├── androidMain/     # Android 平台实现
│   ├── iosMain/         # iOS 平台实现
│   └── ohosMain/        # 鸿蒙平台实现
├── androidApp/          # Android 壳工程
├── iosApp/              # iOS 壳工程
└── ohosApp/             # 鸿蒙壳工程
```

5.3 写一个 Compose DSL 页面

```kotlin
import com.tencent.kuikly.compose.*
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
import androidx.compose.ui.unit.sp

@Page("helloWorld")
class HelloComposePage : ComposeContainer() {
    override fun willInit() {
        super.willInit()
        setContent {
            HelloComposeScreen()
        }
    }
}

@Composable
private fun HelloComposeScreen() {
    var count by remember { mutableStateOf(0) }

    Column(modifier = Modifier.padding(16.dp)) {
        Text(text = "Hello Kuikly Compose, count = $count", fontSize = 24.sp)
        Button(onClick = { count++ }) {
            Text(text = "Click me")
        }
    }
}
```

关键步骤说明：

1. 创建页面类：继承 ComposeContainer，用 @Page 注解定义页面名称

1. 设置 UI：在 willInit() 中调用 setContent {}

1. 写 Compose UI：在 setContent 里用标准 Compose 组件，和 Jetpack Compose 一模一样

注意：HelloComposePage 继承自 Kuikly 的 ComposeContainer，而不是 Android Activity；页面生命周期、路由跳转等能力来自 Kuikly Core。

5.4 运行

用 Android Studio 运行项目，在模拟器或真机上查看效果。iOS 和鸿蒙端同样有对应的壳工程配置，流程类似。

---

六、什么时候 Kuikly 不是最佳选择

客观地说，Kuikly 也有边界，超出边界硬上会出问题：

• 前端主导的团队：Kuikly 把多端 UI 收敛成 Kotlin，意味着从 JS/TS 生态切过来要重新适应包管理、构建工具和调试方式。这类团队用 RN 或 Taro 会更顺滑。

• 极致动画场景：高频复杂动画、粒子、3D 效果，Flutter 的自绘引擎仍然更稳妥。

• Web/小程序为主、移动端为辅：Kuikly 的 Web 和小程序目前仍在 Beta，建议观望或先做充分测试。

• macOS 覆盖：目前还在 Alpha，不适合生产环境。

• 社区生态：Kuikly 2025 年 4 月才开源，第三方组件库和 StackOverflow 问答的积累，还比不上 Flutter 和 RN。

---

七、写在最后

回到这篇文章的主线：一套 Kotlin，覆盖六端。

Kuikly 的价值可以收敛成一句话——让以 Kotlin/Android 为主的团队，用熟悉的一门语言和一套代码，就把 UI 和业务逻辑铺到 Android、iOS、鸿蒙、Web、小程序、macOS 六个平台上，各端都是原生控件，还不用为每个平台各养一支 UI 团队。

支撑这个价值的，是三点具体的能力：

1. 一套 Kotlin 覆盖六端 UI：逻辑 + UI 都收进同一套 Kotlin，编译到各端渲染成原生控件，无需额外学 Dart、JS，也无需各端各写界面。

1. 现代声明式 UI 范式：Compose DSL 与 Jetpack Compose 一脉相承，已有 Compose 经验可以直接复用到六端。

1. 开箱即用的工程化支持：Android Studio 插件一键创建项目，文档和 Demo 齐全。

更重要的是，它已经在腾讯新闻、新微视、腾讯地图等 30+ App、5 亿+ 日活场景中验证过，外部也有快手、MiniMax、方正证券等 20 余家团队接入。这不是一个"新玩具"，而是经过大规模生产环境检验的成熟方案。

如果你的团队以 Android/Kotlin 技术栈为主，又想把业务快速铺到鸿蒙、iOS 乃至 Web 和小程序上，Kuikly 是目前最值得认真评估的选项。

参考资源

• 官方文档：主页 | 跨平台框架—tds-Kuikly

• GitHub 仓库：https://github.com/Tencent-TDS/KuiklyUI