Kuikly 是腾讯大前端 Oteam 在 2025 年 4 月开源的跨端开发框架，基于 Kotlin Multiplatform（KMP）构建，目标是用一套 Kotlin 代码覆盖 Android、iOS、鸿蒙、Web（H5）、微信小程序，macOS（Alpha）六端。

它目前在 QQ、QQ 音乐、QQ 浏览器、腾讯新闻、搜狗输入法、应用宝等 20+ 腾讯系产品深度使用，覆盖 1000+ 页面、5 亿+ DAU。

技术底座：为什么是"KMP + 原生渲染"

跨端框架的渲染路线大致分三派——自绘引擎（Flutter）、JS 桥接原生（RN）、原生渲染（Kuikly / 鸿蒙 ArkUI 思路）。Kuikly 选了第三条，核心思路是：

• Kotlin 写业务与 UI 描述​ → 通过 KMP 编译成各平台原生产物（Android .aar、iOS .framework、鸿蒙 .so、Web .js）

• 布局和高阶组件放 Kotlin 跨平台层，原生层只做"原子组件的轻量映射"，这样既能复用原生渲染管线，又能保证多端组件行为一致

• 没有 JS Bridge、没有自绘引擎、没有 WebView 嵌套，所以性能接近原生、包体积也小

架构上自底向上分四层：编译层（@Page注解 + KSP）→ 核心层（跨平台抽象）→ 渲染层（core-render-android/ios/ohos/web）→ 应用层。

官方给出的体量数据：

指标	Kuikly	对比参照
Android 最小 SDK	~300 KB（AOT）	Flutter 空包 ~10 MB
iOS 最小 SDK	~1.2 MB	Flutter 较大
鸿蒙渲染	ArkUI 原生控件	Flutter 仍靠社区 fork

核心特性：四个关键词

1. 一码多端，鸿蒙是差异点

五端（Android / iOS / 鸿蒙 / H5 / 小程序）共用 commonMain里的 Kotlin 代码，平台差异用 expect/actual兜底。鸿蒙端已正式发布（非 Beta），在腾讯内部 QQ、QQ 音乐等的鸿蒙版都接了 Kuikly——这一点 Flutter（社区 fork）和 RN（需额外适配）目前都没做到同等完整度。

2. 双 DSL 策略

• 自研 DSL：API 风格接近 CSS Flexbox，前端背景也容易上手

• Compose DSL（Beta，2026 年推进正式 Release）：复用 Jetpack Compose 的组件/布局/动画 API，只把渲染层从 Skia 换成 Kuikly 原生渲染

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

3. 页面级动态化

依托腾讯 Shiply，支持页面维度热更新，且性能几乎无损。这对国内运营活动、A/B 测试、紧急修复是刚需——Flutter 官方没有通用热更新，RN 的 CodePush 又受 Google Play 政策约束。

4. 原生工具链闭环

用 Android Studio / VS Code + Kotlin + Bugly（质量监控）+ Shiply（发布止损），从脚手架到监控一条龙。

横向对比：Kuikly vs Flutter vs RN vs 纯 KMP

维度	Kuikly	Flutter	React Native	纯 KMP
语言	Kotlin	Dart	JS/TS	Kotlin
渲染	原生控件映射	自绘 Skia/Impeller	JS 桥接原生	各端原生 UI
UI 是否跨端	✅ 一套 Kotlin	✅ 一套 Dart	✅ 一套 JS	❌ 各端分开写
包体积	~300KB / ~1.2MB	~10MB 起	中等	接近原生
鸿蒙支持	✅ 正式	❌ 社区 fork	需适配	❌
热更新	✅ 页面级	受限	✅ CodePush	❌
社区生态	⭐⭐（2025.4 才开源）	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐

和 Flutter 的本质差异：Flutter 用自绘换"像素级一致"，代价是引擎体积和 Dart 学习成本；Kuikly 用原生渲染换"原生感 + 小包"，代价是高度自定义 UI（粒子、3D）不如自绘灵活。

和 RN 的本质差异：RN 是 JS 世界的人，前端团队迁移顺；Kuikly 是 Kotlin 世界的人，Android 团队迁移顺。RN 胜在生态和热更新成熟度，Kuikly 胜在鸿蒙 + 原生性能 + 无桥接损耗。

和纯 KMP 的关系：KMP 只解决"逻辑跨端"，UI 还得各端各写；Kuikly 是在 KMP 之上补了 UI 跨端这一层。所以两者不是替代，是"纯 KMP 团队要不要再加 Kuikly"的递进关系。

适用边界：什么时候该选，什么时候别选

适合选 Kuikly 的场景：

• 团队是 Android / Kotlin 背景，不想引入 Dart 或 JS

• 必须覆盖鸿蒙（这是它目前最强的差异点）

• 动态化是业务硬需求（运营活动、热修复）

• 存量 Native App 想渐进式接入跨端页面（Add-to-App）

要谨慎的场景：

• 复杂动效（粒子、3D）→ 仍首选 Flutter

• 前端团队主导、需要丰富 npm 生态 → RN 更顺手

• 国际化 / 英文文档依赖强 → Kuikly 目前中文社区为主，外部踩坑资料较少

• 小程序端仍在 Beta，性能还有优化空间

---

2026 年值得关注的方向

腾讯在 2026 Roadmap 里把 "AI 友好"​ 写进了核心战略：MCP Server + Rules + Skills 让 AI 编程工具理解 Kuikly、Figma 转代码、React/Vue/Flutter 存量代码智能转码，QQ 音乐的 React → Kuikly 转码已在生产跑通。这条路线如果兑现，跨端框架的下一轮竞争维度可能从"谁渲染快"变成"谁对 AI Coding 更友好"。