今天，在腾讯的 Shiply 平台看 Flutter 动态化自研框架 Conch 时，在侧边栏看到了有「跨端开发框架」的介绍，点开发现有两个产品：

• Hippy：面向前端技术栈的跨端开发框架，Web原生开发体验，支持 React 和 Vue 开发框架。
• Kuikly：面向终端技术栈的跨端开发框架，完全基于kotlin语言开发，原生的性能和体验。

关于 Hippy 在之前就大概了解过，属于 Web 开发体验的开源的跨端开发框架，但是 Kuikly 又是什么？

通过查找，在 openhippy 的官网可以看到，原来 Kuikly 是基于 Kotlin KMM(Kotlin Multiplatform Mobile) 技术实现的客户端友好跨端方案，可以使用 Kotlin 原生开发语言创建 Android 、iOS、、H5、小程序和 PC 应用，属于 TDF （Tencent Device-oriented Framework）的全新跨平台方案。

而从目前已有的产品介绍看，Kuikly 是采用类 Compose 和 SwiftUI 的声明式+响应式的开发模式，框架输出的产物有：

• Android 产物为 AAR/Dex
• iOS 产物为 .framework/JS

运行时会映射到系统原生控件渲染，跟系统原生控件体验完全一致，最重要的是，Android 平台实现了基于dex 动态下发支持，iOS平台基于 JS 动态下发，也就是完全支持热更新，动态话能力可以依托腾讯自家的 Shiply 。

看起来为了实现动态，在 iOS 平台使用的是 Kotlin/JS 。

同时，App 极度的轻量化，使用 Kuikly 的安装包增量仅 300K，运行时额外的内存占用几乎为零，从这点看大小和内存基本不会是 Kuikly 的门槛。

在查阅资料后才发现，2023 年的时候，「腾讯技术工程」团队就在知乎分享过 Kuikly 的实现，Kuikly（Kotlin UI Kit，发音同 quickly），项目就是使用 Kotlin 开发了自己的一套声明式 UI 框架，同时映射到系统原生控件做渲染，最终用 KMM（Kotlin Multiplatform Mobile）实现跨端。

而对于 Kuikly ，它从业务代码、UI 框架、布局层以及渲染层全部使用 Kotlin 语言（iOS 渲染层是 OC），其中Android 端通过 KMM 编译成 SO 文件，而，iOS 端可以编译成 JS，不过那也是两年前的情况。

可以看到当时腾讯几乎是用了自己的 UI 框架实现而非直接使用了 Compose MultiPlatform，不知道现在是否还是如此？

而从现在看来，依托 KMP 项目的成熟，目前 Kuikly 很大可能已经支持可 Kotlin Native？ 并且从预告看，已经支持了鸿蒙平台，那么大概率不是 Kotlin/JS 就是 Kotlin Native 。

如果是为了动态化，可能还是 Kotlin/JS 的概率大一些？

如下图所示，是过去 Kuikly 过去在知乎发过的代码编写情况，看起来基本上有着浓浓的 Compose 的熟悉味道：

这时候可能路过的 iOS 表示：为什么大厂弄跨平台甚至直至鸿蒙都是 Kotlin 不是 Swift ？

而 Kuikly 表示，其核心的设计思路是让 native 的渲染层尽量的薄，所以他们把布局和复杂 UI 控件封装都放在了跨端的 Kotlin 侧，native 层只有对原生基础控件的简单映射，这样也能尽量减少因为两端代码不一致导致的功能和体验不一致问题。

这是两年前 Kuikly 提供的数据对比，基本和原始开发保持一致：

另外，通过代码量对比，腾讯技术工程团队表示：同一个页面使用 Kotlin 和 OC 开发两端的代码量，是使用 Kuikly 跨端开发的代码量的 3 倍，同时腾讯还发布了 Kuikly 与类 RN 和 Flutter 的对比：

那么 2025 年的今天，Kuikly 是否还是使用全自研发的 UI 框层？还是已经接入 Compose MultiPlatform ? 从渲染实现上考虑，看起来还是映射的可能性更大？毕竟还有考虑动态化支持，具体还是要等项目正式开源后才知道了。

• 文档可见：https://shiply.tds.qq.com/docs/doc?id=4012359584

• Kuikly 入口可见：https://openhippy.com/

• 2023 原文可见：https://zhuanlan.zhihu.com/p/622485633