腾讯 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 的布局系统,包括所有布局组件和布局修饰符:

kotlin 复制代码
@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 适配鸿蒙的选择吗?

参考链接

相关推荐
鬼手点金5 小时前
模型即 Agent:当模型本身成为产品
开发语言·前端·人工智能·python·机器学习
kiracrimson5 小时前
npm 入门:包管理器、依赖与 npx
前端·npm·node.js
ShineWinsu5 小时前
对于JavaScript:初识JavaScript以及输入输出
java·开发语言·前端·javascript·css·面试·html
鲤鱼_5995 小时前
教培机构一体化运营管理系统操作手册
前端
a5986525 小时前
Docker多开云手机,六边云独立端口隔离访问实战
android·运维·docker·容器·智能手机·云手机
鶴哥只手遮天5 小时前
React 19.3.1 源码深度剖析-第 3 章 Fiber 架构与双缓冲
前端·react.js·开源
鶴哥只手遮天5 小时前
React 19.3.1 源码深度剖析-第 9 章(下)lazy、retry、hydration 与实战
前端·react.js·开源
鶴哥只手遮天5 小时前
React 19.3.1 源码深度剖析-第 6 章 React DOM 渲染器与 Commit 阶段(把 Fiber 副作用落到真实 DOM)(上)
前端·react.js·开源
鶴哥只手遮天5 小时前
React 19.3.1 源码深度剖析-第 6 章 React DOM 渲染器与 Commit 阶段(把 Fiber 副作用落到真实 DOM)(下)
前端·react.js·开源