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

腾讯 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.xdnf.cn/news/10707.html

相关文章:

  • 云原生时代 Kafka 深度实践:05性能调优与场景实战
  • Vue3中Axios的使用-附完整代码
  • sqlite3 命令行工具详细介绍
  • 虚拟现实教育终端技术方案——基于EFISH-SCB-RK3588的全场景国产化替代
  • DNS (Domain Name System) 域名系统 将域名解析为 IP 地址
  • OCC笔记:TopoDS_Edge上是否一定存在Geom_Curve
  • 【Vmware】虚拟机安装、镜像安装、Nat网络模式、本地VM8、ssh链接保姆篇(图文教程)
  • J. Adv. Res. | DAP-seq助力解析大麦HvbZIP87基因让小麦抗病又高产的新机制
  • 吃透 Golang 基础:数据结构之 Map
  • UGUI Text/TextMeshPro字体组件
  • 从一堆数字里长出一棵树:中序 + 后序构建二叉树的递归密码
  • chromedriver 下载失败
  • 阿里云百炼全解析:一站式大模型开发平台的架构与行业实践
  • 智启未来:AI重构制造业供应链的五大革命性突破
  • 鸿蒙仓颉语言开发实战教程:购物车页面
  • AI Agent开发第78课-大模型结合Flink构建政务类长公文、长文件、OA应用Agent
  • 网络安全-等级保护(等保) 3-3-1 GB/T 36627-2018 附录A (资料性附录) 测评后活动、附 录 B (资料性附录)渗透测试的有关概念说明
  • WPF技术体系与现代化样式
  • 如何选择最高效的沟通方式?
  • 每日八股文6.3
  • 谷歌地图苹果版v6.138.2 - 前端工具导航
  • 极智项目 | 基于PyQT+Whisper实现的语音识别软件设计
  • HttpServletResponse 对象用来做什么?
  • T/CCSA 663-2025《医疗科研云平台技术要求》标准解读与深度分析
  • 黑马Java面试笔记之 微服务篇(业务)
  • 6.3 day 35
  • 榕壹云健身预约系统:多门店管理的数字化解决方案(ThinkPHP+MySQL+UniApp实现)
  • 前端面试高频问题通关指南—通用性问题
  • 相机Camera日志分析之二十三:高通相机Camx 基于预览1帧的process_capture_request二级日志分析详解
  • rate-limit 为 java 设计的渐进式限流开源工具