Kuikly跨端框架解析

1 Kuikly框架概述

Kuikly是腾讯大前端领域Oteam（公司级）推出的面向客户端技术的跨端开发框架，完全基于Kotlin语言开发，提供原生的性能和体验。作为基于Kotlin Multiplatform (KMP) 的UI与逻辑全面跨端综合解决方案，Kuikly旨在提供一套一码多端、极致易用、动态灵活的全平台高性能开发框架。截至目前，Kuikly已支持Android、iOS、鸿蒙三大移动平台，并支持Web和小程序平台。

1.1 核心特性与优势

Kuikly框架具有以下几个显著特点和优势：

• 一码多端：支持使用单一代码库同时输出Android、iOS、鸿蒙、Web和小程序五端应用。这极大地降低了多平台开发的成本和维护工作量。
• 原生性能体验：得益于KMP跨平台能力，Kuikly将Kotlin代码编译成各个平台原生产物(如Android的.aar和iOS的framework)，从而获得接近原生平台的执行性能。测试数据显示，其页面首屏耗时与原生基本一致，内存占用也相差无几。
• Kotlin语言驱动：完全采用Kotlin作为开发语言，使用原生IDE(Android Studio/VSCode)和性能分析工具，实现了从业务代码到框架代码层的统一技术栈开发闭环。
• 双开发范式：支持自研声明式+响应式DSL，同时也在逐步支持Compose DSL，提供灵活的UI开发选择。
• 动态化支持：支持页面级动态化能力，可按需切换内置和动态化模式，具有页面维度更新、性能高、无hook稳定性高等优势。
• 轻量稳定：框架设计精巧，无复杂外部依赖，安装包体积增量小，稳定性和可维护性高。

Kuikly整体架构

截屏2025-09-15 14.46.20.png

2 Kuikly核心原理剖析

2.1 架构设计理念

Kuikly框架在设计上践行与原生一致的技术栈理念，减少开发者的技术栈跨越。它复用终端的开发语言、工具和生态，拥有接近原生性能和原生渲染，同时采用声明式(类似Compose和SwiftUI)和轻量的设计思路。整个框架架构分为三个核心层次：

• 跨端Core层：包含自研的声明+响应式Kuikly DSL与标准的Compose DSL(建设中)，负责高性能的DSL组件树映射生成Native UI树的核心逻辑，包括2棵树映射方案、精细化的O(1) Diff更新算法、渲染指令生成等逻辑。此层还重新实现了大量的复杂高阶组件(如ListView、ViewPager、Waterfall等)，保证多平台一致性。

• Native渲染层：特点是轻量化，提供统一的平台接口层，包含最小化的原子渲染组件(仅Text、Image、Input、ScrollView等少量组件)。该层还提供API实现模块，供各平台扩展统一API给跨平台层使用。

• KuiklyBase基础设施：提供鸿蒙Kotlin/Native适配以支持鸿蒙高性能运行，以及调试、质量监控、发布、组件生态等配套基础设施。

2.2 渲染机制与薄原生层设计

Kuikly通过自研DSL构建UI，在不同平台上映射到不同的原生UI系统。在iOS平台使用UIKit，在Android平台则可以使用原生View系统或Compose(计划中)。与其他跨端框架不同的是，Kuikly实现了自己的"薄原生层"。

这个薄原生层只暴露最基本和无逻辑的UI组件(原子组件)，真正的UI逻辑主要在共享的Kotlin代码中实现。通过将UI逻辑抽象到共享的Kotlin层，减少平台特定UI差异或行为差异的可能性，薄原生层充当一致的渲染目标，确保Kotlin定义的UI元素在所有平台上都以类似的方式显示。

目前Kuikly实现了60% UI组件的纯Kotlin组合封装实现，不需要Native提供原子控件。仅Text、Image、Input、ScrollView 等少量组件放到Native层。最容易出现不一致的高阶组件都通过Kotlin实现，比如List列表控件，Kuikly通过对齐Native的List内部实现原理，然后再用Kotlin重写一次，从而实现真正的高一致性UI组件跨平台实现。

2.3 性能优化策略

Kuikly以高性能、动态化为框架核心目标，在多个层面实施了性能优化策略：

• 编译期优化：利用KMP将Kotlin代码编译成各个平台的原生产物，消除解释执行或虚拟机运行时的性能开销。
• 渲染优化：采用O(1) Diff算法实现精细化的UI更新，避免不必要的全局重绘。
• 内存管理：引入对象复用机制，对高频创建和释放的组件实施白名单管理的复用池，减少内存分配和垃圾回收的开销。
• 文本渲染专项优化：在鸿蒙平台上，通过利用系统提供的文本绘制接口进行直调绘制，复用布局结果，彻底解决文本重布局问题。

3 多平台Demo实现

参考官方链接：
https://kuikly.tds.qq.com/QuickStart/env-setup.html

4 Kuikly DSL与Compose DSL

Kuikly 框架提供了两种 UI 开发方式：自研的 Kuikly DSL 和兼容 Jetpack Compose 语法的 Compose DSL。它们共享 Kuikly 的核心架构与多端支持，但在实现原理和特性上有所不同。下面这个表格汇总了它们的主要区别，之后我会进一步解释。

4.1.核心共通点

尽管存在差异，但两者都基于 Kotlin Multiplatform (KMP) 技术，并共享 KuiklyBase 提供的基础设施（如调试、构建、监控），都致力于实现 “一码多端” 。

4.2.如何选择？

• 追求极致的原生性能、动态化能力和更稳定的生产环境：Kuikly DSL 是当前更成熟稳妥的选择。
• 项目需要覆盖 Web 或小程序平台：Kuikly DSL 对这些平台的支持已在规划中。
• 团队具备丰富的 Android Jetpack Compose 开发经验，且优先追求开发效率与代码风格统一：可以尝试 Kuikly Compose DSL，但需留意其 Beta 状态。
• 应用高度依赖 Skia 自绘以实现极致自定义 UI 或复杂动画：Kuikly 的两种 DSL 目前均采用原生渲染，可能不是最优先选择。你可以了解腾讯的 ovCompose（基于 Compose Multiplatform 和 Skia 自绘）。

4.3.总结

Kuikly 的两种 DSL 提供了侧重点不同的跨端 UI 解决方案：

• Kuikly DSL 更像是一个“性能优先、多端覆盖” 的务实派，自研道路保证了控制力和优化深度。
• Kuikly Compose DSL 则像一个“体验优先、生态兼容” 的革新派，旨在降低开发者学习成本并拥抱更广泛的 Compose 生态。

选择哪条路径，取决于你的项目优先级和团队技术背景。希望这些分析能帮助你做出更合适的决策。

5 KuiklyUI与KuiklyBase

5.1 功能定位与职责划分

Kuikly框架由两个核心部分组成：KuiklyUI和KuiklyBase。这两个部分各有侧重，共同构成了完整的Kuikly跨端开发生态。

KuiklyUI是框架的UI部分，主要负责：

• 提供声明式UI开发范式，包括自研DSL和Compose DSL两种选择
• 实现跨平台UI渲染，将Kotlin UI代码映射到各平台原生UI组件
• 管理UI生命周期和状态变化
• 处理用户交互和事件响应
• 支持页面级动态化更新

KuiklyBase则是框架的基础设施部分，主要提供：

• 跨平台逻辑共享能力，支持非UI业务的逻辑跨端
• 平台适配层，特别是鸿蒙Kotlin/Native适配
• 调试工具和性能监控设施
• 构建系统和发布工具
• 组件生态和依赖管理

5.2 协作关系与集成方式

KuiklyUI与KuiklyBase之间存在密切的协作关系。KuiklyUI依赖于KuiklyBase提供的底层基础设施和能力，而KuiklyBase则通过KuiklyUI验证和优化其功能设计。

在实际项目中，开发者可以根据需要选择使用完整的Kuikly(包含UI和Base)或仅使用KuiklyBase。对于已经有现有UI层，只需要共享非UI逻辑的场景，可以单独使用KuiklyBase；对于全新项目，则可以使用完整的Kuikly框架。

表：KuiklyUI与KuiklyBase的关系

5.3 实际应用场景

在腾讯内部，KuiklyUI和KuiklyBase已经被广泛应用到多个产品中。例如，腾讯视频、QQ浏览器、腾讯新闻等应用使用KuiklyUI开发全新的跨平台页面；而一些已有的成熟产品则选择使用KuiklyBase来实现业务逻辑的跨端共享，同时保持现有的UI层不变。

这种灵活性使得Kuikly可以适应不同的迁移和改造场景：

• 全新项目：可使用KuiklyUI+KuiklyBase全面跨端开发
• 已有项目，需要共享逻辑：可单独使用KuiklyBase实现非UI逻辑跨端
• 已有项目，需要完整改造：可逐步将UI迁移到KuiklyUI，同时使用KuiklyBase共享业务逻辑

6 Kuikly与ovCompose

6.1 背景与起源

ovCompose(online-video-compose)是腾讯视频团队基于Compose Multiplatform生态推出的跨平台开发框架，旨在弥补JetBrains Compose Multiplatform不支持鸿蒙平台的遗憾与解决iOS平台原生UI混排受限的问题。

虽然ovCompose和Kuikly都是腾讯推出的跨端解决方案，且都基于KMP技术，但它们的设计目标和实现方式有显著差异。两者都依赖于KuiklyBase基础设施，共享底层的KMP支持和鸿蒙编译链。

6.2 技术架构差异

Kuikly和ovCompose在技术架构上有着根本性的区别：

Kuikly采用原生控件渲染方案，通过薄原生层将Kotlin UI代码映射到各平台原生UI组件。它的优点是性能接近原生、内存占用低、与平台UI无缝集成；缺点是需要处理各平台UI差异，实现复杂度高。

ovCompose采用Skia自绘渲染方案，通过Skia图形库在所有平台上一致地绘制UI。它的优点是UI一致性极高、不受平台UI限制；缺点是内存占用较高、与平台UI混排复杂度高。

6.3 适用场景对比

根据不同的技术特点，Kuikly和ovCompose有各自适合的应用场景：

Kuikly更适合以下场景：

• 需要动态化能力的应用，特别是页面级动态更新需求
• 追求最小内存占用和最佳性能的应用
• 需要与平台原生UI深度集成的项目
• 需要支持Web和小程序等多端的项目

ovCompose更适合以下场景：

• 要求极高UI一致性 across all platforms的应用
• 已有Compose代码基础，需要扩展到iOS和鸿蒙的平台
• UI设计较为复杂，需要充分利用Compose强大布局能力的项目
• 不需要支持Web和小程序的纯移动端项目

6.4 性能表现对比

在性能方面，Kuikly和ovCompose各有优势：

• 启动速度：Kuikly因使用原生控件，启动速度略优于ovCompose
• 内存占用：Kuikly的内存占用通常低于ovCompose，特别是在低端设备上
• 渲染一致性：ovCompose的Skia自绘方案在所有平台上提供像素级一致的渲染效果
• 混排能力：Kuikly与平台原生UI混排更简单自然，ovCompose需要通过三明治镂空结构实现混排

6.5 开发体验对比

从开发体验角度来看，两个框架也有所不同：

Kuikly提供两种UI开发范式：自研DSL和Compose DSL。自研DSL针对跨平台优化，学习曲线较平缓；Compose DSL则对已有Compose经验的开发者更友好。

ovCompose完全兼容JetBrains Compose Multiplatform，对于已有Compose经验的开发者可以几乎零学习成本上手，但对于新手需要学习Compose的概念和模式。

7 总结与展望

Kuikly作为腾讯开源的跨端开发框架，凭借其一码多端、原生性能和动态化支持等特性，为多平台应用开发提供了高效的解决方案。通过与KuiklyBase基础设施的配合，Kuikly既可以全面跨端开发新应用，也可以逐步迁移现有项目。

与ovCompose相比，Kuikly更适合需要动态化能力、最小内存占用和原生UI集成的场景，而ovCompose则更适合要求极高UI一致性和已有Compose基础的项目。

随着鸿蒙生态的不断发展壮大，Kuikly的意义不仅在于为开发者提供一个多端开发框架，更在于它降低了鸿蒙应用开发门槛，促进了鸿蒙生态的繁荣。未来，随着Web和小程序平台的支持开源，Kuikly有望成为真正意义上的全平台开发解决方案。

对于技术选型建议，可以根据项目需求选择：

• 需要最大程度复用现有原生代码或需要动态化 → 选择Kuikly
• 要求像素级UI一致性或已有Compose经验 → 选择ovCompose
• 需要支持Web和小程序 → 选择Kuikly
• 纯移动端应用且追求最佳性能 → 根据具体情况选择

无论选择哪种方案，Kuikly和ovCompose都代表了腾讯在跨端开发领域的重要贡献，为开发者提供了更多的技术选择和发展空间。