在 3月的時候通過 《騰訊 TDF 即將開源 Kuikly 跨端框架，Kotlin 支持全平臺》 我們大致知道了 Kuikly 的基本情況，Kuikly 是一個面向終端技術棧的跨端開發框架，完全基于kotlin語言開發，提供原生的性能和體驗。

按照官方的說法：Kuikly 是基于Kotlin Multiplatform 的 UI 與邏輯全面跨端綜合解決方案，由騰訊大前端領域 Oteam（公司級）推出，目的在于提供一套一碼多端、極致易用、動態靈活的全平臺高性能開發框架。

當然，雖然是全平臺，但是目前暫時只開源了 Android 和 iOS，鴻蒙部分 5 月才開源，而 Web 和 小程序暫定是 Q2：

官方表示 Kuikly 在騰訊內部本身已經支持了小程序 + H5 ，后續會分步驟開放，可能下一期還不會是所有小程序平臺。

那 Kuikly 如何實現跨平臺？目前 Kuikly 主要是在 KMP 的基礎上實現的自研 DSL 來構建 UI ，比如 iOS 平臺的 UI 能力就是 UIkit ，而大家更熟悉的 Compose 支持，目前還處于開發過程中：

SwiftUI 和 Compose 無法直接和 Kuikly 一起使用，但是 Kuikly 可以在 DSL 語法和 UI 組件屬性對齊兩者的寫法，變成一個類 Compose 和 SwiftUI 的 UI 框架，也就是 Compose DSL 大概就是讓 Kuikly 更像 Compose ，而不是直接適配 Compose ？

那么大家可能會有疑問，既然借助了平臺控件的能力，那它和 RN 有什么區別？

首先 Kuikly 是直接從編譯產物的角度實現跨平臺，它的編譯產物與原生一致，和 RN 是在運行時轉換為原生控件不同，Kotlin 是直接編譯為對應平臺的原生代碼，所以在運行時其實就類似原生 code 。

那 Kuikly 又如何保證多端 UI 一致？答案是 Kuikly 實現了自己的一套「薄原生層」。

首先在 Kotlin 層，Kuikly 將虛擬 Dom 方案優化為直調方案，這里 Kotlin View API 直調，避免 JSON 序列化/反序列化損耗，同時只維護一棵樹，更輕量和O(1)同步UI更新：

之后，Kuikly 使用“非常薄”的原生層，該原生層只暴露最基本和無邏輯的 UI 組件（原子組件），也就是 Kuikly 在 UI 上只用了最基本的原生層 UI ，真正的 UI 邏輯主要在共享的 Kotlin 代碼來實現：

通過將 UI 邏輯抽象到共享的 Kotlin 層，減少平臺特定 UI 差異或行為差異的可能性，「薄原生層」充當一致的渲染目標，確保 Kotlin 定義的 UI 元素在所有平臺上都以類似的方式顯示。

也就是說，Kuikly 雖然會依賴原生平臺的控件，但是大部分控件的實現都已經被「提升」到 Kuikly 自己的 Kotlin 共享層，目前 Kuikly 實現了 60% UI 組件的純 Kotlin 組合封裝實現，不需要 Native 提供原子控件 ：

最容易出現不一致的高階組件都通過 Kotlin 實現，比如 List 列表控件，Kuikly 通過對齊 Native 的 List 內部實現原理，然后再用 Kotlin 重寫一次，從而實現真正的高一致性 UI 組件跨平臺實現。

所以基于上面的內容，我們再來看 Kuikly UI 官方提供的結構圖，是不是就清晰了很多：

• Core 模塊提供了統一的 UI 邏輯實現和 API 接口
• Render 模塊負責在 Android、iOS、HarmonyOS、H5 以及各種小程序等多個平臺上實現 UI 的渲染 。

另外在 Kuikly 領域，還有一套名為 KuiklyBase 服務，它是獨立于 Kuikly UI 之外，為 Kuikly 提供基礎設施支持，比如為 iOS、Android 和鴻蒙三大移動平臺提供了統一的底層基建能力：

KuiklyBase 強調在不同平臺之間實現高性能的邏輯共享 ，它更像是 KMP 的進一步定制，KuiklyBase 兼容標準的 Kotlin Multiplatform 組件，允許復用成熟的 KMP 組件，比如有些業務各端都已經有 UI 層的實現，僅僅需要非 UI 的業務邏輯實現跨端，而通過 KuiklyBase 的基礎設施，也可以滿足這種場景的需求。

另外 KuiklyBase 還提供了對 HarmonyOS 平臺的全面支持，包括 KN HarmonyOS 編譯、調試和構建能力。

也就是 Kuikly 在鴻蒙有支持 Kotlin Native 高性能版本。

同時，KuiklyBase 還提供了強大的多線程和協程能力，支持復雜業務邏輯的跨平臺并行處理，以滿足高性能場景的需求。

并且在開發工具鏈方面，KuiklyBase 覆蓋了從腳手架搭建到調試、構建、發布和監控的整個流程，特別是支持和 Bugly 和 Shiply 聯動提供配套能力。

最后，KuiklyBase 還內置了性能優化工具，并針對 HarmonyOS 和 iOS 提供了優化的調試體驗 。

目前使用 KuiklyBase 業務的團隊：騰訊視頻、瀏覽器、新聞、輸入法、理財通····

當然，這里需要注意的是， KuiklyBase 和 KuiklyUI 一起使用，某種情況下會存在場景沖突：

• KuiklyUI 的 iOS 和鴻蒙動態化方案主要利用了 Kotlin/JS 編譯成 js 產物，動態下發到宿主的js引擎去執行
• KuiklyBase 利用 Kotlin/Native 編譯成高性能的二進制產物執行，因此沒有解耦 KuiklyBase 的 KMP 組件，在 iOS 和鴻蒙在動態化場景需要注意兼容

所以，動態化決定了你優先使用哪個支持：

• 無動態化訴求場景: KuiklyBase + KuiklyUI = 完美

• 有動態化訴求場景: KuiklyBase 兼容 js 動態化方案還沒完成，短期方案可利用 KuiklyUI 的 Module 方案來作為替代

上面問題的核心其實是，KuiklyBase 組件因為是 KMP 組件，沒有和平臺做解耦，動態化時產物會運行在 js 環境中，由于 js 單線程，無法直接提供平臺能力等的限制，所以決定了動態化部分不能直接使用多線程和平臺能力。

所以業務在開發過程中需要特別注意在調用平臺 KMP 組件能力的時候，需要通過 Kuikly Module 方式進行解耦調用，避免直接依賴。

Kuikly 作為一個跨端的 UI 框架, 他本身不具備調用平臺 API 的能力, 但是Kuikly提供了一套Module機制，可以通過Module機制將平臺的 API 暴露給 Kuikly 側調用，同時 Kuikly內置了一些通用的 Module , 如果這些 Module 不滿足 業務訴求時, 可以通過擴展原生 API 自定義Module, 將更多的宿主平臺 API 暴露給 Kuikly 側使用。

在 KuiklyUI 內部，模塊頁面分為兩種類型：可動態化類型(內置和動態靈活切換)和純內置類型(只能內置) ：

而可動態化類型部分：

• 不可直接依賴平臺能力
• 不可使用多線程和協程
• 不可依賴內置部分
• 不可依賴使用到了平臺能力或多線程協程等能力的 KMP 組件，如果無法避免需要使用相關能力，就需要前面提到額 Kuikly Module 進行解耦調用

核心就是，動態化的只能是 JS 。

最后，以下是 Kuikly 工程的項目結構說明：

.
├── core                    # 跨平臺模塊，實現各個平臺響應式 UI、布局算法、Bridge 通信等核心能力├── src├── commanMain            # 跨平臺共享代碼、定義跨平臺接口 ├── androidMain           # Android 平臺實現代碼 （aar）├── jvmMain               # 泛 JVM 平臺代碼（不涉及 Android API）（jar）├── iosMain               # iOS 平臺實現代碼（framework）
├── core-render-android    # android 平臺的渲染器模塊
├── core-render-ios        # iOS 平臺的渲染器模塊
├── core-annotations       # 注解模塊，定義業務注解 @Page
├── core-ksp               # 注解處理模塊，生成 Core 入口文件 
├── buildSrc               # 編譯腳本，用于編譯、打包、分包產物相關腳本
├── demo                   # DSL 示例代碼 
├── androidApp             # Android 宿主殼工程
└── iosApp                 # iOS 宿主殼工程

還有需要注意的是，之前的 Kuikly 的插件還不支持 K2 模式，所以如果你的 IDE 是 K2 模式，需要關閉 K2 才能支持插件：

而一天之后，已經是 1.0.3 版本，此時 KuiklyTemplate 插件也支持了最新的 K2 模式：

針對 Mac 用戶還提供 kdoctor CI 支持：

另外，Kuikly 未來也會兼容 Compose DSL ，但是大概率不會是原本的 Compose ，而是類 Compose 的代碼組織方式。

另外，在混合開發領域，在原有 App 集成 Kuikly ，可以把它簡單當作如系統 webview 的概念來使用，但是如果在原生列表中嵌入 Kuikly view，目前會因為 Kuikly 本身的異步機制，導致無法同原生列表其它卡片同時生存layout和view結果，造成顯示上的不同步。

可以看到，Kuikly 總得來說還是一個類 RN 框架，但是它又不像 RN 一樣的運行時 OEM 原生控件，而是在編譯成完成轉化為原生代碼，并且它抽象出了統一的 「薄原生層」，讓大量高階控件在共享的 Kotlin 層完成實現，只讓少量 native 層提供原子組件能力，從而盡可能實現 UI 的多端統一，類似于把原生控件單做 “Canvas" 效果使用。

總的來說，Kuikly 既能實現接近原生的性能體驗和原生的開發體驗，又能提供良好的動態化能力，看起來還是不錯的選擇。

最后，官方表示 Kuikly 對于 Android 的同學家基本沒有學習成本，只要使用過響應式開發的都能上手，而對于 iOS 同學而已，大概就是需要熟悉一下 Kotlin 語法，不過 Kotlin 和 Swift 相近度挺高，所以上手也不會太困難。

目前 Kuikly 已經在 QQ、QQ音樂、QQ瀏覽器、騰訊新聞、搜狗輸入法、應用寶、全民K歌、酷狗音樂、酷我音樂、自選股、ima.copilot、微視等多款產品中使用，那么，你覺得你會愿意嘗試 Kuikly 嗎？

參考鏈接

• https://kuikly.tds.qq.com/
• https://github.com/Tencent-TDS/KuiklyUI/