騰訊開源 ovCompose 跨平臺框架：實現一次跨三端（Android/iOS/鴻蒙）

在這里插入圖片描述

在移動應用開發領域，跨平臺技術一直是開發者們追求的目標，它能夠幫助企業降低開發成本、提高開發效率，同時保證應用在不同平臺上的一致性體驗。2025 年 6 月 3 日，騰訊視頻團隊迎來了一個重要的里程碑 —— 正式發布 ovCompose 跨平臺框架，這一框架的最大亮點在于全面支持純血鴻蒙系統，為開發者們帶來了全新的跨端開發體驗。

1. 背景：跨平臺需求的升級與挑戰

隨著純血鴻蒙系統的推出，單純的 UI 跨端已經難以滿足復雜業務的需求，企業迫切需要構建能夠同時在 Android、iOS 和鴻蒙平臺上運行的全跨端應用，以最大程度地降低開發成本、提升人效。與此同時，對于非小程序類的常規應用來說，開發者們更希望在保持原生優良性能的同時，使用行業通用的 UI 開發語言，以降低學習成本。

Kotlin 與 Compose 作為 Google 官方推薦的 Android 開發語言與 UI 框架，深受開發者們的喜愛。Kotlin Multiplatform（KMP）更是具備高性能、與原生交互靈活等優點，因此騰訊視頻團隊選擇了 Compose Multiplatform 作為全跨端應用的基礎。

然而，這套方案也存在一些問題，如不支持純血鴻蒙、iOS 平臺混排能力受限、GC 性能表現一般等。面對這些挑戰，騰訊視頻團隊經過不懈努力，成功解決了這些問題，并決定將解決方案開源，與全行業一同推動 Compose 跨端生態的成熟。

2. 框架的核心特性與優勢

2.1 KuiklyBase 高性能：原生方案帶來極致體驗

KuiklyBase 是騰訊為 Kotlin Multiplatform 開發提供的一整套跨平臺基礎能力組件。它選擇了 Native 方案而非 JS 方案，這是因為 Kotlin-Native（KN）相比 JS 具有更快的執行速度。ovCompose 底層依托 KuiklyBase ，通過一系列的性能優化，KN+Compose 的性能表現令人矚目。
在這里插入圖片描述

在 “小球碰撞” Demo 測試中，以 30FPS 為最低極限，優化后小球數量從 600 提升到 1500（Android 可達 1600 球），繪制性能提升了 150%。這些優化成果不僅提升了應用的流暢度，也為更復雜的業務場景提供了堅實的性能基礎。

2.2 鴻蒙三明治架構：完美解決視圖混排難題

鴻蒙平臺采用了 Skia 的渲染方案，能夠 100% 支持 Compose 語法和渲染能力。通過三明治鏤空結構，很好地解決了與原生組件的混排問題。原生 UI 可以靈活地展示在 Compose 上層或下層，滿足了絕大部分的業務需求。
在這里插入圖片描述

更值得一提的是，該架構還支持粘貼按鈕等安全組件的混排，使得 Compose 無需申請權限也能使用系統能力，這在提升開發效率的同時，也增強了應用的安全性。

2.3 三端高一致性：邏輯與 UI 的完美統一

在邏輯運行方面，由于鴻蒙平臺采用了 Kotlin-Native 方案，解決了 Kotlin-JS 使用 TaskPool 時無法約束跨線程訪問的問題，保持了高度的三端一致性。
在這里插入圖片描述

在 UI 繪制方面，iOS、鴻蒙平臺均采用 Skia 渲染，Android 底層也使用 Skia 渲染，應用層暴露了 Paragraph/Canvas 的繪制接口。基于 Skia 封裝后的 Skiko 可以完美還原 Android 繪制效果，實現了三端 UI 的高度一致。這意味著開發者們可以在三個平臺上 100% 使用 Compose 的控件與繪制能力，大大降低了開發和維護成本。

2.4 iOS 多模態渲染：解放混排能力

針對 iOS 端大量存量業務模塊高度依賴 Compose 與原生 UI 混合編排能力的需求，騰訊視頻團隊提出了指令映射的自研實現方案。這種方案在畫布層進行映射實現，雖然開發難度較高，但可以充分利用 UIKit 豐富的渲染能力，對 Compose 的繪制效果實現較高的還原度。

該方案成功在騰訊視頻 iOS 端核心業務場景落地，業務團隊甚至可以根據實際應用場景在基于 UIKit 實現的自研指令映射方案或官方的 Skia 渲染方案之間自由切換，并且可以在 Runtime 期共存。在文本渲染方面，通過 Skia 將文本渲染成圖片，利用 CALayer 進行展示的方案，保持了高度的一致性。
在這里插入圖片描述

2.5 Kotlin Native 內存優化：GC 與堆 Dump 的雙重突破

GC 優化：在 APP 滑動等高幀率場景，短暫抑制 GC 保障流暢；低影響場景高頻 GC 降低 PSS。分析 CMS 算法發現兩次 STW 暫停，利用 GC 掛起能力，在 Vsync 時掛起、idle 時恢復，并調整 munmap 流程，將第二次 STW 時間壓縮至 1ms 內。
KN 堆 Dump 優化：KN 堆轉儲會暫停線程致界面凍結。鴻蒙端借助 Linux 內核 fork 特性，以 “父子進程異步轉儲” 實現零延遲；iOS 端重新設計流程，緩存數據異步寫入，使 450MB 轉儲耗時從 2.8 秒降至 410 毫秒，滿足線上使用需求。

2.6 KuiklyBase 組件生態：豐富組件助力高效開發

KuiklyBase 提供了豐富的組件生態，涵蓋了開發過程中的各個方面：

Kotlin Native 堆棧還原組件：提供 Kotlin 異常堆棧還原，方便定位問題。
Kotlin Native/ArkTS 互調用組件：支持 ArkTS 與 Kotlin Native 跨語言訪問，提供基礎類型、閉包、ArrayBuffer 等類型互轉，統一的生命周期管理，支持跨線程同步調用和跨 Runtime 的服務發現。
資源管理組件：構建了一套跨平臺原生資源管理解決方案，支持 Android、iOS 及 HarmonyOS 三大移動端平臺，實現了多平臺資源統一管理與編譯期強校驗。
原子操作組件：提供輕量級的原子類型，支持原子讀寫、CAS 等操作，實現線程安全的并發編程。
協程組件：簡化異步和并發編程，支持協程構建器、調度器、掛起函數等能力。
序列化組件：支持高效、類型安全的對象序列化與反序列化，兼容多種復雜類型。
IO、網絡等三方工具庫：為開發者提供了全面的工具支持，屏蔽了平臺差異，提高了開發效率。

3. 實現原理：技術細節的深度探索

3.1 KN 鴻蒙平臺適配：創新方案解決架構難題

Kotlin 1.9 使用的 LLVM 11，Kotlin 2.1 升級到 LLVM 16，但鴻蒙平臺能夠支持的版本在 LLVM 12~15。騰訊視頻團隊提出了一種創新的 KuiklyBase 方案：在第一步 Kotlin IR 轉 LLVM IR 時采用蘋果的 LLVM 11，在 LLVM IR 生成可執行文件時使用鴻蒙的 LLVM 12。這種方案既滿足了需求，又無需對 Kotlin 本身進行架構調整，解決了常規方案中需要依賴不同 Kotlin 版本的問題。
在這里插入圖片描述

3.2 KN 性能優化：多維度提升運行效率

內聯優化：對比 Kotlin IR 與 LLVM IR 文件，發現鴻蒙平臺 LLVM IR 內聯不足，添加 always inline 后性能顯著提升。后查明 Kotlin 與 C++ 代碼生成 LLVM 函數時 cpu feature 不一致影響內聯，經屬性配置修復問題。
ThreadLocal 優化：分析 Benchmark 中鴻蒙耗時超 iOS 的案例，發現其默認用軟件模擬 thread_local 致 Kotlin-Native 內存分配性能差。通過編譯時強制使用硬件 thread_local，性能提升 30%。
協程性能優化：Compose Multiplatform 協程調度依賴異常處理模型，運行損耗大，且鴻蒙 libhilog.so 捕獲異常加劇延遲。通過緩存或舍棄關鍵位置異常，解決非法捕獲，實現長列表滑動 120Hz 穩定。
調試性能優化：針對 Kotlin Native 調試耗時過長問題，在 KDS 與 LLDB 上采用流程合并、緩存等優化手段，提升通信與處理效率，性能提升數倍至數十倍，接近 Native 水平。

3.3 鴻蒙繪制不同步問題解決：Texture 模式實現完美同步

在鴻蒙系統中，Compose 列表與 ArkUI 元素混排滾動時，由于兩種組件屬于獨立的繪制層，存在不同步的問題，導致 UI 銜接處出現空白區域。騰訊視頻團隊采用 XComponent 的 Texture 模式，將內容繪制到 FBO 中，由 FBO 參與原有的 ArkUI 的繪制節奏，保證了完全的同步，解決了這一難題。
在這里插入圖片描述

3.4 iOS 多模態渲染：PictureRecorder 局部更新架構提升效率

針對 iOS 集中渲染架構的特點，設計了基于 iOS 的 PictureRecorder 局部更新架構。通過對繪制命令進行差量處理，只更新變化的部分，提升了繪制效率。進一步升級后，采用增量 hash 來減少 hash 計算量，并將原先由 OC 對象代表的指令改為簡單的 C 結構體，去掉 OC 閉包，大幅提升了渲染效率。以騰訊視頻的視頻播放頁面為例，首次渲染耗時降低 13%，再次渲染耗時降低 56%。

3.5 與 KuiklyUI 的差異：兩種方案滿足不同需求

騰訊大前端 Oteam 同時進行了兩種方案的探索：

原生渲染方案 KuiklyUI：側重于靜態化 + 動態化雙運行模式，采用輕量原生渲染保持原生 UI 體驗并具備高度一致性，基于原生組件映射的方式支持 Compose API，還支持 H5 和小程序（6 月底推出）。
自渲染方案 ovCompose：專注于全面對齊 Compose Multiplatform 標準 API，采用自渲染方式實現鴻蒙平臺的適配，確保三端高度一致性，針對 iOS 上較多的存量業務，提出多模態渲染方案解決低端 iPhone 內存緊張、混排原生視圖、手勢等問題。

4. 開源說明：攜手業界共建生態

此次開源共包含 5 個倉庫，涵蓋了 ovCompose 和 KuiklyBase：

ovCompose-sample：展示 ovCompose 與 KuiklyBase 的功能。
ovCompose-multiplatform-core：基于 JetBrains 的 compose-multiplatorm-core 定制，實現鴻蒙端適配及 iOS 多模態渲染能力。
KuiklyBase-kotlin：基于 JetBrains 的 kotlin-multiplatform 定制，適配鴻蒙平臺并進行了部分優化。
KuiklyBase-components：封裝常用的跨端組件，涵蓋資源管理、跨語言通信、網絡請求和圖片加載四大模塊。
KuiklyBase-platform：基于官方組件適配鴻蒙平臺，并對部分功能進行性能優化，提升開發效率，現已覆蓋 10 個基礎組件。