在移动应用开发领域，跨平台技术一直是开发者们追求的目标，它能够帮助企业降低开发成本、提高开发效率，同时保证应用在不同平台上的一致性体验。2025 年 6 月 3 日，腾讯视频团队迎来了一个重要的里程碑 —— 正式发布 ovCompose 跨平台框架，这一框架的最大亮点在于全面支持纯血鸿蒙系统，为开发者们带来了全新的跨端开发体验。

1. 背景：跨平台需求的升级与挑战

随着纯血鸿蒙系统的推出，单纯的 UI 跨端已经难以满足复杂业务的需求，企业迫切需要构建能够同时在 Android、iOS 和鸿蒙平台上运行的全跨端应用，以最大程度地降低开发成本、提升人效。与此同时，对于非小程序类的常规应用来说，开发者们更希望在保持原生优良性能的同时，使用行业通用的 UI 开发语言，以降低学习成本。

Kotlin 与 Compose 作为 Google 官方推荐的 Android 开发语言与 UI 框架，深受开发者们的喜爱。Kotlin Multiplatform（KMP）更是具备高性能、与原生交互灵活等优点，因此腾讯视频团队选择了 Compose Multiplatform 作为全跨端应用的基础。

然而，这套方案也存在一些问题，如不支持纯血鸿蒙、iOS 平台混排能力受限、GC 性能表现一般等。面对这些挑战，腾讯视频团队经过不懈努力，成功解决了这些问题，并决定将解决方案开源，与全行业一同推动 Compose 跨端生态的成熟。

2. 框架的核心特性与优势

2.1 KuiklyBase 高性能：原生方案带来极致体验

KuiklyBase 是腾讯为 Kotlin Multiplatform 开发提供的一整套跨平台基础能力组件。它选择了 Native 方案而非 JS 方案，这是因为 Kotlin-Native（KN）相比 JS 具有更快的执行速度。ovCompose 底层依托 KuiklyBase ，通过一系列的性能优化，KN+Compose 的性能表现令人瞩目。

在 “小球碰撞” Demo 测试中，以 30FPS 为最低极限，优化后小球数量从 600 提升到 1500（Android 可达 1600 球），绘制性能提升了 150%。这些优化成果不仅提升了应用的流畅度，也为更复杂的业务场景提供了坚实的性能基础。

2.2 鸿蒙三明治架构：完美解决视图混排难题

鸿蒙平台采用了 Skia 的渲染方案，能够 100% 支持 Compose 语法和渲染能力。通过三明治镂空结构，很好地解决了与原生组件的混排问题。原生 UI 可以灵活地展示在 Compose 上层或下层，满足了绝大部分的业务需求。

更值得一提的是，该架构还支持粘贴按钮等安全组件的混排，使得 Compose 无需申请权限也能使用系统能力，这在提升开发效率的同时，也增强了应用的安全性。

2.3 三端高一致性：逻辑与 UI 的完美统一

在逻辑运行方面，由于鸿蒙平台采用了 Kotlin-Native 方案，解决了 Kotlin-JS 使用 TaskPool 时无法约束跨线程访问的问题，保持了高度的三端一致性。

在 UI 绘制方面，iOS、鸿蒙平台均采用 Skia 渲染，Android 底层也使用 Skia 渲染，应用层暴露了 Paragraph/Canvas 的绘制接口。基于 Skia 封装后的 Skiko 可以完美还原 Android 绘制效果，实现了三端 UI 的高度一致。这意味着开发者们可以在三个平台上 100% 使用 Compose 的控件与绘制能力，大大降低了开发和维护成本。

2.4 iOS 多模态渲染：解放混排能力

针对 iOS 端大量存量业务模块高度依赖 Compose 与原生 UI 混合编排能力的需求，腾讯视频团队提出了指令映射的自研实现方案。这种方案在画布层进行映射实现，虽然开发难度较高，但可以充分利用 UIKit 丰富的渲染能力，对 Compose 的绘制效果实现较高的还原度。

该方案成功在腾讯视频 iOS 端核心业务场景落地，业务团队甚至可以根据实际应用场景在基于 UIKit 实现的自研指令映射方案或官方的 Skia 渲染方案之间自由切换，并且可以在 Runtime 期共存。在文本渲染方面，通过 Skia 将文本渲染成图片，利用 CALayer 进行展示的方案，保持了高度的一致性。

2.5 Kotlin Native 内存优化：GC 与堆 Dump 的双重突破

• GC 优化：在 APP 滑动等高帧率场景，短暂抑制 GC 保障流畅；低影响场景高频 GC 降低 PSS。分析 CMS 算法发现两次 STW 暂停，利用 GC 挂起能力，在 Vsync 时挂起、idle 时恢复，并调整 munmap 流程，将第二次 STW 时间压缩至 1ms 内。

• KN 堆 Dump 优化：KN 堆转储会暂停线程致界面冻结。鸿蒙端借助 Linux 内核 fork 特性，以 “父子进程异步转储” 实现零延迟；iOS 端重新设计流程，缓存数据异步写入，使 450MB 转储耗时从 2.8 秒降至 410 毫秒，满足线上使用需求。

2.6 KuiklyBase 组件生态：丰富组件助力高效开发

KuiklyBase 提供了丰富的组件生态，涵盖了开发过程中的各个方面：

• Kotlin Native 堆栈还原组件：提供 Kotlin 异常堆栈还原，方便定位问题。
• Kotlin Native/ArkTS 互调用组件：支持 ArkTS 与 Kotlin Native 跨语言访问，提供基础类型、闭包、ArrayBuffer 等类型互转，统一的生命周期管理，支持跨线程同步调用和跨 Runtime 的服务发现。
• 资源管理组件：构建了一套跨平台原生资源管理解决方案，支持 Android、iOS 及 HarmonyOS 三大移动端平台，实现了多平台资源统一管理与编译期强校验。
• 原子操作组件：提供轻量级的原子类型，支持原子读写、CAS 等操作，实现线程安全的并发编程。
• 协程组件：简化异步和并发编程，支持协程构建器、调度器、挂起函数等能力。
• 序列化组件：支持高效、类型安全的对象序列化与反序列化，兼容多种复杂类型。
• IO、网络等三方工具库：为开发者提供了全面的工具支持，屏蔽了平台差异，提高了开发效率。

3. 实现原理：技术细节的深度探索

3.1 KN 鸿蒙平台适配：创新方案解决架构难题

Kotlin 1.9 使用的 LLVM 11，Kotlin 2.1 升级到 LLVM 16，但鸿蒙平台能够支持的版本在 LLVM 12~15。腾讯视频团队提出了一种创新的 KuiklyBase 方案：在第一步 Kotlin IR 转 LLVM IR 时采用苹果的 LLVM 11，在 LLVM IR 生成可执行文件时使用鸿蒙的 LLVM 12。这种方案既满足了需求，又无需对 Kotlin 本身进行架构调整，解决了常规方案中需要依赖不同 Kotlin 版本的问题。

3.2 KN 性能优化：多维度提升运行效率

• 内联优化：对比 Kotlin IR 与 LLVM IR 文件，发现鸿蒙平台 LLVM IR 内联不足，添加 always inline 后性能显著提升。后查明 Kotlin 与 C++ 代码生成 LLVM 函数时 cpu feature 不一致影响内联，经属性配置修复问题。

• ThreadLocal 优化：分析 Benchmark 中鸿蒙耗时超 iOS 的案例，发现其默认用软件模拟 thread_local 致 Kotlin-Native 内存分配性能差。通过编译时强制使用硬件 thread_local，性能提升 30%。

• 协程性能优化：Compose Multiplatform 协程调度依赖异常处理模型，运行损耗大，且鸿蒙 libhilog.so 捕获异常加剧延迟。通过缓存或舍弃关键位置异常，解决非法捕获，实现长列表滑动 120Hz 稳定。

• 调试性能优化：针对 Kotlin Native 调试耗时过长问题，在 KDS 与 LLDB 上采用流程合并、缓存等优化手段，提升通信与处理效率，性能提升数倍至数十倍，接近 Native 水平。

3.3 鸿蒙绘制不同步问题解决：Texture 模式实现完美同步

在鸿蒙系统中，Compose 列表与 ArkUI 元素混排滚动时，由于两种组件属于独立的绘制层，存在不同步的问题，导致 UI 衔接处出现空白区域。腾讯视频团队采用 XComponent 的 Texture 模式，将内容绘制到 FBO 中，由 FBO 参与原有的 ArkUI 的绘制节奏，保证了完全的同步，解决了这一难题。

3.4 iOS 多模态渲染：PictureRecorder 局部更新架构提升效率

针对 iOS 集中渲染架构的特点，设计了基于 iOS 的 PictureRecorder 局部更新架构。通过对绘制命令进行差量处理，只更新变化的部分，提升了绘制效率。进一步升级后，采用增量 hash 来减少 hash 计算量，并将原先由 OC 对象代表的指令改为简单的 C 结构体，去掉 OC 闭包，大幅提升了渲染效率。以腾讯视频的视频播放页面为例，首次渲染耗时降低 13%，再次渲染耗时降低 56%。

3.5 与 KuiklyUI 的差异：两种方案满足不同需求

腾讯大前端 Oteam 同时进行了两种方案的探索：

• 原生渲染方案 KuiklyUI：侧重于静态化 + 动态化双运行模式，采用轻量原生渲染保持原生 UI 体验并具备高度一致性，基于原生组件映射的方式支持 Compose API，还支持 H5 和小程序（6 月底推出）。

• 自渲染方案 ovCompose：专注于全面对齐 Compose Multiplatform 标准 API，采用自渲染方式实现鸿蒙平台的适配，确保三端高度一致性，针对 iOS 上较多的存量业务，提出多模态渲染方案解决低端 iPhone 内存紧张、混排原生视图、手势等问题。

4. 开源说明：携手业界共建生态

此次开源共包含 5 个仓库，涵盖了 ovCompose 和 KuiklyBase：

• ovCompose-sample：展示 ovCompose 与 KuiklyBase 的功能。
• ovCompose-multiplatform-core：基于 JetBrains 的 compose-multiplatorm-core 定制，实现鸿蒙端适配及 iOS 多模态渲染能力。
• KuiklyBase-kotlin：基于 JetBrains 的 kotlin-multiplatform 定制，适配鸿蒙平台并进行了部分优化。
• KuiklyBase-components：封装常用的跨端组件，涵盖资源管理、跨语言通信、网络请求和图片加载四大模块。
• KuiklyBase-platform：基于官方组件适配鸿蒙平台，并对部分功能进行性能优化，提升开发效率，现已覆盖 10 个基础组件。

仓库 group 地址：https://github.com/Tencent-TDS

5. 未来计划：持续优化推动技术进步

尽管 KMM 生态已经取得了长足的发展，Kotlin-Native 的执行性能在很多方面超越了 Kotlin-JVM，但 Compose Multiplatform 跨平台技术还没有达到成熟的状态（特别是 GC）。ovCompose & KuiklyBase 将持续优化，重点关注以下方向：

• GC 在业务场景的表现：进一步优化 GC 性能，减少对应用流畅度的影响。
• Kotlin-Native 组件化：提升组件化水平，提高开发效率和代码复用率。
• Kotlin-Native 的开发体验优化：简化开发流程，提升开发者体验。
• UIKit 渲染模式进一步对齐 Skia 的渲染：确保 iOS 平台上的渲染效果与其他平台更加一致。