当前位置: 首页 > article >正文

腾讯 ovCompose 开源,Kuikly 鸿蒙和 Compose DSL 开源,腾讯的“双”鸿蒙方案发布

近日,腾讯的 ovCompose 和 Kuikly 都发布了全新开源更新,其中 Kuikly 在之前我们聊过,本次 Kuikly 主要是正式开源鸿蒙支持部分和 Compose DSL 的相关支持,而 ovCompose 是腾讯视频团队基于 Compose Multiplatform 生态推出的跨平台开发框架,ovCompose 主要是为了弥补官方 CMP 不支持鸿蒙平台的遗憾和解决 iOS 平台混排受限的问题

那可能有人要问了,这两者有什么关系?

首先它们都是属于腾讯大前端领域 Oteam ,并且 ovCompose 和 Kuikly 都依赖于 KuiklyBase ,可以说 KuiklyBase 是腾讯视频和 Oteam 共建的 KMP 基础支持

KuiklyBase 之前我们就聊过,它服务是独立于 Kuikly UI 之外,为 Kuikly 提供基础设施支持,比如为 iOS、Android 和鸿蒙三大移动平台提供了统一的底层基建能力:

而这部分支持对于鸿蒙平台也非常重要,特别是在鸿蒙平台编译支持上,而在新开源的 ovCompose 上,KuiklyBase 也是共享使用,所以不严谨考虑,可以简单认为,大家都是基于 KuiklyBase 的 KMP 支持,而在上层渲染:

  • KuiklyUI 使用原生 OEM 渲染,但是有自己的「薄原生层」利用原子组件实现 UI 统一,并且 KuiklyUI 侧重于静态化+动态化双运行模式(Kotlin/JS),后续还能可以支持 H5 和小程序,有 Compose DSL ,但是不是真正的 Compose
  • ovCompose 采用官方标准 CMP API ,Skia 自绘,支持 Android 、iOS 和鸿蒙三端,只考虑 Kotlin Native 方,是对于标准 CMP 的横向拓展

所以,在 KMP 角度可以认为它们是同源的,特别是基于 Kotlin Native 的鸿蒙实现上,KuiklyBase 方案基本通用,例如,KuiklyBase 在编译时,在将 Kotlin IR 转 LLVM IR 时会先采用苹果的 LLVM 11,在 LLVM IR 生成可执行文件时使用鸿蒙的 LLVM 12,这样既可以满足诉求,Kotlin本身也无需进行架构调整:

当然,这也造成了你要编译鸿蒙平台,只能使用 mac 电脑。

所以,如果你有 Web 和小程序需求,那么你还是选 KuiklyUI 更合适,特别如果你还需要动态化。

但是如果你只考虑移动端三端,那么 ovCompose 或者更适合你,因为它基于 Compose Multiplatform ,横向扩展了鸿蒙平台,而纵向则是优化了 iOS 平台的混合开发,对于喜欢 CMP 的人来说可能会更容易接受,并且性能理论上会更好一点。

例如 ovCompose 在 iOS 上设计了基于 iOS 的 PictureRecorder 局部更新架构,优化的核心思路是通过增量 hash 来减少 hash 的计算量,并希望对应优化,后续可以反向 PR 合并到 Jetbrains:

而在鸿蒙平台,KuiklyUI 毫无意外也是通过 C API 实现指令的映射,毕竟直接走 ArkUI 实现的 OEM 性能实在堪忧,基本上类似 RN 的实现都会选择直接对接底层 C API,例如 Taro on Harmony C-API 版本 。

而对于 ovCompose ,因为是自绘方案,所以在混合开发里,则是采用 XComponent 的 Texture 模式,将内容绘制到 FBO ,由FBO 参与原有的 ArkUI 的绘制节奏来保证完全的同步:

最后,Kuikly 也支持了 Compose DSL,不过是基于 Kuikly 核心架构与通用渲染层之上,扩充对标准Compose DSL 的支持,就是写法 Compose 了,组件命令和 API 也和 Compose 相近,例如 Kuikly Compose 就支持 Compose 的布局系统,包括所有布局组件和布局修饰符:

@Page("helloWorld")
internal class HelloWorldPage : ComposeContainer() {override fun willInit() {super.willInit()setContent {// 编写Compose代码}}
}LazyRow(modifier: Modifier = Modifier,state: LazyListState = rememberLazyListState(),contentPadding: PaddingValues = PaddingValues(0.dp),reverseLayout: Boolean = false,horizontalArrangement: Arrangement.Horizontal = Arrangement.Start,verticalAlignment: Alignment.Vertical = Alignment.Top,content: LazyListScope.() -> Unit
)

Kuikly 的 Compose DSL 的目标是支持所有标准的 Compose API,但是实际还有部分 API 的参数暂时未完全支持

所以,可以看出来作为 KMP 核心支持和鸿蒙编译链的 KuiklyBase 是公用的,而在上层 UI 上,如果你更考虑动态化和小程序,那么 KuiklyUI 可能更适合你,如果你更注重 Compose 对齐和自渲染性能,那么 ovCompose 则是首选。

那么,ovCompose 或者 Kuikly 会是你 CMP 适配鸿蒙的选择吗?

参考链接

  • https://mp.weixin.qq.com/s/GTkzHTvWIdDmxtlRVpNgfw

  • https://mp.weixin.qq.com/s/KsEqVO_Zh73xSlUWOrvZrQ

  • https://github.com/Tencent-TDS/ovCompose-sample/blob/main/README-zh_CN.md

http://www.lryc.cn/news/2398609.html

相关文章:

  • PYTHON调用讯飞C/C++动态库实现离线语音合成并且实时播放
  • 黑马Java面试笔记之 消息中间件篇(RabbitMQ)
  • Vue中安装插件的方式
  • 如何提高工作效率
  • Redisson学习专栏(五):源码阅读及Redisson的Netty通信层设计
  • Spring AI 项目实战(一):Spring AI 核心模块入门
  • 字节跳动开源图标库:2000+图标一键换肤的魔法
  • 结合 AI 生成 mermaid、plantuml 等图表
  • 行列式详解:从定义到应用
  • R语言使用随机过采样(Random Oversampling)平衡数据集
  • HertzBeat的安装和使用教程
  • 【Kotlin】高阶函数Lambda内联函数
  • 从0开始学vue:vue3和vue2的关系
  • MySQL关系型数据库学习
  • 嵌入式硬件篇---龙芯2k1000串口
  • 4-C#的不同窗口传值
  • 谷歌地图苹果版v6.138.2 - 前端工具导航
  • NSSCTF [LitCTF 2025]test_your_nc
  • 第十九章 正则表达式
  • browser-use Agent 日志链路分析
  • Qwen3高效微调
  • Gitee Wiki:重塑关键领域软件研发的知识管理范式
  • redis的哨兵模式和Redis cluster
  • MySQL计算精度计算加减乘除取模方式和方法总计
  • 农业机器人的开发
  • Swift 解锁 LeetCode 热门难题:不改数组也能找出重复数字?
  • 2025年微信小程序开发:趋势、最佳实践与AI整合
  • 【深度学习】15. Segment Anything Model (SAM) :基于提示的分割新时代
  • Java从入门到精通 - 常用API(一)
  • SQL 筛选出在表1但不在表2中的数据