今天，在騰訊的 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