鴻蒙NEXT時代你所不知道的全平臺跨端框架：CMP、Kuikly、Lynx、uni-app x等

Posted on 2025-07-16 10:28 Jack Jiang 閱讀(17) 評論(0) 編輯收藏

本文由GSYTech 戀貓de小郭分享，原題“2025 跨平臺框架更新和發布對比，這是你沒看過的全新版本”，下文有修訂和重新排版。

1、前言

2025 年可以說又是一個跨平臺的元年，其中不妨有鴻蒙Next平臺刺激的原因，也有大廠技術積累“達到瓶頸”的可能，又或者“開猿截流、降本增笑”的趨勢的影響，2025 年上半年確實讓跨平臺框架又成為最活躍的時刻。

例如：

1）Flutter Platform 和 UI 線程合并和Android Impeller 穩定；
2）React Native 優化 Skia 和發布全新 WebGPU 支持；
3）Compose Multiplatform iOS 穩定版發布，客戶端全平臺穩定；
4）騰訊 Kotlin 跨平臺框架 Kuikly 正式開源；
5）字節跨平臺框架 Lynx 正式開源；
6）uni-app x 跨平臺框架正式支持鴻蒙；
····

本篇基于當前各大活躍的跨端框架的現狀，對比當前它們的情況和未來的可能，幫助你在選擇框架時更好理解它們的特點和差異。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4843-1-1.html）

2、系列文章

本文是系列文章中的第 14篇，本系列總目錄如下：

《IM跨平臺技術學習(一)：快速了解新一代跨平臺桌面技術——Electron》

《IM跨平臺技術學習(二)：Electron初體驗(快速開始、跨進程通信、打包、踩坑等)》

《IM跨平臺技術學習(三)：vivo的Electron技術棧選型、全方位實踐總結》

《IM跨平臺技術學習(四)：蘑菇街基于Electron開發IM客戶端的技術實踐》

《IM跨平臺技術學習(五)：融云基于Electron的IM跨平臺SDK改造實踐總結》

《IM跨平臺技術學習(六)：網易云信基于Electron的IM消息全文檢索技術實踐》

《IM跨平臺技術學習(七)：得物基于Electron開發客服IM桌面端的技術實踐》

《IM跨平臺技術學習(八)：新QQ桌面版為何選擇Electron作為跨端框架》

《IM跨平臺技術學習(九)：全面解密新QQ桌面版的Electron內存占用優化》

《IM跨平臺技術學習(十)：快速選型跨平臺框架Electron、Flutter、Tauri、React Native等》

《IM跨平臺技術學習(十一)：環信基于Electron打包WebIM桌面端的技術實踐》

《IM跨平臺技術學習(十二)：萬字長文詳解QQ Linux端實時音視頻背后的跨平臺實踐》

《IM跨平臺技術學習(十三)：從理論到實踐，詳細對比Electron和Tauri的優劣》

《IM跨平臺技術學習(十四)：鴻蒙NEXT時代你所不知道的全平臺跨端框架》（☜ 本文）

3、Flutter

首先 Flutter 大家應該已經很熟悉了，作為在「自繪領域」堅持了這么多年的跨平臺框架，相信也不需要再過多的介紹，因為是「自繪」和「AOT 模式」，讓 Flutter 在「平臺統一性」和「性能」上都有不錯的表現。開發過程過程中的 hotload 的支持程度也很不錯。

而自 2025 以來的一些更新也給 Flutter 帶來了新的可能，比如 Flutter Platform 和 UI 線程合并，簡單來說就是以前 Dart main Thread 和 Platform UI Thread 是分別跑在獨立線程，它們的就交互和數據都需要經過 Channel 。

而合并之后：Dart main 和 Platform UI 在 Engine 啟動完成后會合并到一個線程，此時 Dart 和平臺原生語言就支持通過同步的方式去進行調用，也為 Dart 和 Kotlin/Java，Swift/OC 直接同步互操作在 Framework 提供了進一步基礎支持。

當然也帶來一些新的問題，具體可見線程合并的相關文章。

另外在當下：其實 Flutter 的核心競爭力是 Impeller，因為跨平臺框架不是系統“親兒子”，又是自繪方案，那么在性能優化上，特別 iOS 平臺，就不得不提到著色器預熱或者提前編譯。

傳統 Skia 需要把「繪制命令」編譯成可在 GPU 執行代碼的過程，一般叫做著色器編譯， Skia 需要「動態編譯」著色器，但是 Skia 的著色器「生成/編譯」與「幀工作」是按順序處理，如果這時候著色器編譯速度不夠快，就可能會出現掉幀（Jank）的情況，這個我們也常叫做「著色器卡頓」。

而 Impeller 正是這個背景的產物，簡單說，App 所需的所有著色器都在 Flutter 引擎構建時進行離線編譯，而不是在應用運行時編譯。

這其實才是目前是 Flutter 的核心競爭力，不同于 Skia 需要考慮多場景和平臺通用性，需要支持各種靈活的額著色器場景，Impeller 專注于 Flutter ，所以它可以提供更好的專注支持和問題修復。

當然 Skia 也是 Google 項目，對于著色器場景也有 Graphite 后端在推進支持，它也在內部也是基于 Impeller 為原型去做的改進，所以未來 Skia 也可以支持部分場景的提前編譯。

而在鴻蒙平臺：華為針對 Flutter 在鴻蒙的適配，在華為官方過去的分享里，也支持了《Flutter引擎Impeller鴻蒙化》。

甚至，Flutter 在類游戲場景支持也挺不錯，如果配合 rive 的狀態機和自適應，甚至可以開發出很多出乎意料的效果，而官方也有 Flutter 的游戲 SDK 或者 Flame 第三方游戲包支持（如下圖所示）。

最后，那么 Flutter 的局限性是什么呢？其實也挺多的，例如：

1）文字排版能力不如原生；
2）PC平臺推進交給了 Canonical 團隊負責，雖然有多窗口雛形，但是推進慢；
3）不支持官方熱更新，shorebird 國內穩定性一般；
4）內存占用基本最高；
5）Web 只支持 wasm 路線；
6）鴻蒙版本落后主版本太多；
7）不支持小程序，雖然有第三方實現，但是力度不大；
8）····。

所以，Flutter 適合你的場景嗎？

4、React Native

如果你很久沒了解過 RN ，那么 2025 年的 RN 會超乎你的想象，可以說 Skia 和 WebGPU 給了它更多的可能。

RN 的核心之一就是對齊 Web 開發體驗，其中最重要的就是 0.76 之后 New Architecture 成了默認框架，例如 Fabric, TurboModules, JSI 等能力解決了各種歷史遺留的性能瓶頸。

比如：

1）JSI 讓 RN 可以切換 JS 引擎，比如 Chakra、v8、Hermes，同時允許 JS 和 Native 線程之間的同步相互執行；
2）全新的 Fabric 取代了原本的 UI Manager，支持 React 的并發渲染能力，特別是現在的新架構支持 React 18 及更高版本中提供的并發渲染功能，對齊 React 最新版本，比如 Suspense & Transitions；
3）Hermes JS 引擎預編譯的優化字節碼，優化 GC 實現等
4）TurboModules 按需加載插件
5）····

另外現在新版 RN 也支持熱重載，同時可以更快對齊新 React 特性，例如 React 19 的 Actions、改進的異步處理等。

而另一個支持就是 RN 在 Skia 和 WebGPU 的探索和支持，使用 Skia 和 WebGPU 不是說 RN 想要變成自繪，而是在比如「動畫」和「圖像處理」等場景增加了強力補充。

還有是 React Native 開始引入 WebGPU 支持，其效果將確保與 Web 端的 WebGPU API 完全一致，允許開發者直接復制代碼示例的同時，實現與 Web Canvas API 對稱的 RN Canvas API。

最后，WebGPU 的引入還可以讓 React Native 開發者能夠利用 ThreeJS 生態，直接引入已有的 3D 庫，這讓 React Native 的能力進一步對齊了 Web。

最后，RN 也是有華為推進的鴻蒙適配，會采用 XComponent 對接到 ArkUI 的后端接口進行渲染，詳細可見《鴻蒙版 React Native 正式開源》。

而在 PC 領域 RN 也有一定支持，比如微軟提供的 windows 和 macOS 支持，社區提供的 web 和 Linux 支持，只是占有并不高，一般忽略。

而在小程序領域，有京東的 Taro 這樣的大廠開源支持，整體在平臺兼容上還算不錯。

當然，RN 最大的優勢還在于成熟的 code-push 熱更新支持。

那么使用 RN 有什么局限性呢？

最直觀的肯定是平臺 UI 的一致性和樣式約束，這個是 OEM 框架的場景局限，而對于其他的，目前存在：

1）第三方庫在新舊框架支持上的風險

2）RN 版本升級風險，這個相信大家深有體會

3）平臺 API 兼容復雜度較高

4）0.77 之后才支持 Google Play 的 16 KB 要求

5）可用性集中在 Android 和 iOS ，鴻蒙適配和維度成本更高

6）小程序能力支持和客戶端存在一定割裂

7）····

事實上， RN 是 Cordova 之后我接觸的第一個真正意義上的跨平臺框架，從我知道它到現在應該有十年了，那么你會因為它的新架構和 WebGPU 能力而選擇 RN 么？

5、Compose Multiplatform

Compose Multiplatform（CMP）近期的熱度應該來自 Compose Multiplatform iOS 穩定版發布，作為第二個使用 Skia 的自繪框架，除了 Web 還在推進之外， CMP 基本完成了它的跨平臺穩定之路。

Compose Multiplatform（CMP）是 UI，Kotlin Multiplatform (KMP) 是語言基礎。

CMP 使用 Skia 繪制 UI ，甚至在 Android 上它和傳統 View 體系的 UI 也不在一個渲染樹，并且 CMP 通過 Skiko (Skia for Kotlin) 這套 Kotlin 綁定庫，進而抹平了不同架構（Kotlin Native，Kotlin JVM ，Kotlin JS，Kotlin wasm）調用 skia 的差異。

所以 CMP 的優勢也來自于此，它可以通過 skia 做到不同平臺的 UI 一致性，并且在 Android 依賴于系統 skia ，所以它的 apk 體積也相對較小，而在 PC 平臺得益于 JVM 的成熟度，CMP 目前也做到了一定的可用程度。

其中和 Android JVM 模式不同的是，Kotlin 在 iOS 平臺使用的是 Kotlin/Native，Kotlin/Native 是 KMP 在 iOS 支持的關鍵能力，它負責將 Kotlin 代碼直接編譯為目標平臺的機器碼或 LLVM 中間表示 (IR)，最終為 iOS 生成一個標準 .framework，這也是為什么 Compose iOS 能實現接近原生的性能。

實現鴻蒙支持目前主流方式也是 Kotlin/Native ，不得不說 Kotlin 最強大的核心價值不是它的語法糖，而是它的編譯器，當然也有使用 Kotlin/JS 適配鴻蒙的方案。

所以 CMP 最大的優勢其實是 Kotlin，Kotlin 的編譯器很強大，支持各種編譯過程和產物，可以讓 KMP 能夠靈活適配到各種平臺，并且 Kotlin 語法的優勢也讓使用它的開發者忠誠度很高。

不過遺憾的是，目前 CMP 鴻蒙平臺的適配上都不是 Jetbrains 提供的方案，華為暫時也沒有 CMP 的適配計劃，目前已知的 CMP/KMP 適配基本是大廠自己倒騰的方案，有基于 KN 的 llvm 方案，也有基于 Kotlin/JS 的低成本方案，只是大家的路線也各不相同。在小程序領域同樣如此。

另外現在 CMP 開發模式下的 hot reload 已經可以使用，不過暫時只支持 desktop，原理大概是只支持 jvm 模式。

而在社區上，klibs.io 的發布也補全了 Compose Multiplatform 在跨平臺最后一步。

這也是 Compose iOS 能正式發布的另外一個原因：

那么聊到這里，CMP 面臨的局限性也很明顯：

1）鴻蒙適配成本略高，沒有官方支持，低成本可能會選擇 Kotlin/JS，為了性能的高成本可能會考慮 KN，但是 KN 在 iOS 和鴻蒙的 llvm 版本同步適配也是一個需要衡量的成本；
2）小程序領域需要第三方支持；
3）iOS 平臺可能面臨的著色器等問題暫無方案，也許未來等待 Skia 的 Graphite 后端；
4）在 Android JVM 模式和 iOS 的 KN 模式下，第三方包適配的難度略高；
5）hotload 暫時只支持 PC；
6）桌面內存占用問題；
7）沒有官方熱更新條件；
8）kjs、kn、kjvm、jwasm 之間的第三方包兼容問題；
9）····

相信 2025 年開始，CMP 會是 Android 原生開發者在跨平臺的首選之一，畢竟 Kotlin 生態不需要額外學習 Dart 或者 JS 體系，那么你會選擇 CMP 嗎？

6、Kuikly

Kuikly 其實也算是 KMP 體系的跨平臺框架，只是騰訊在做它的時候還沒 CMP ，所以一開始 Kuikly 是通過 KMM 進行實現，而后在 UI 層通過自己的方案完成跨平臺。

這其實就是 Kuikly 和 CMP 最大的不同，底層都是 KMP 方案，但是在繪制上 Kuikly 采用的是類 RN 的方式，目前 Kuikly 主要是在 KMP 的基礎上實現的自研 DSL 來構建 UI ，比如 iOS 平臺的 UI 能力就是 UIkit，而大家更熟悉的 Compose 支持，

目前還處于開發過程中：

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

那么，Kuikly 和 RN 之間又什么區別?

1）Kuikly 支持 Kotlin/JS 和 Kotlin/Native 兩種模式，也就是它可以支持性能很高的 Native 模式；
2）Kuikly 實現了自己的一套「薄原生層」，Kuikly 使用“非常薄”的原生層，該原生層只暴露最基本和無邏輯的 UI 組件（原子組件），也就是 Kuikly 在 UI 上只用了最基本的原生層 UI ，真正的 UI 邏輯主要在共享的 Kotlin 代碼來實現：

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

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

另外 Kuikly 表示后續會支持全平臺小程序，這也是優勢之一。

最后，Kuikly 還在動態化熱更新場景，可以和自己騰訊的熱更新管理平臺無縫集成，這也是優勢之一。

那么 Kuikly 存在什么局限性？

首先就是動態化場景只支持 Kotlin/JS，而可動態化類型部分：

1）不可直接依賴平臺能力；
2）不可使用多線程和協程；
3）不可依賴內置部分。

其他的還有：

1）UI 不是 CMP ，使用的是類 RN 方式，所謂需要稍微額外理解成本；
2）不支持 PC 平臺；
3）基于原生 OEM，雖然有原子控件，但是還是存在部分不一致情況；
4）在原有 App 集成 Kuikly ，只能把它簡單當作如系統 webview 的概念來使用。

另外，騰訊還有另外一個基于 CMP 切適配鴻蒙的跨平臺框架，只是何時開源還尚不明確。

那么，你會為了小程序和鴻蒙NEXT而選擇 Kuikly 嗎？

7、Lynx

如果說 Kuikly 是一個面向客戶端的全平臺框架，那么 Lynx 就是一個完全面向 Web 前端的跨平臺全家桶。

目前 Lynx 開源的首個支持框架就是基于 React 的 ReactLynx，當然官方也表示Lynx 并不局限于 React，所以不排除后續還有 VueLynx 等其他框架支持，而 Lynx 作為核心引擎支持，其實并不綁定任何特定前端框架，只是當前你能用的暫時只有 ReactLynx。

而在實現上，源代碼中的標簽，會在運行時被 Lynx 引擎解析，翻譯成用于渲染的 Element，嵌套的 Element 會組成的一棵樹，從而構建出UI界面。

所以從這里看，初步開源的 Lynx 是一個類 RN 框架，不過從官方的介紹“選擇在移動和桌面端達到像素級一致的自渲染” ，可以看出來宣傳中可以切換到自渲染，雖然暫時還沒看到。

而對于 Lynx 主要的技術特點在于：

1）「雙線程架構」，思路類似 react-native-reanimated ，JavaScript 代碼會在「主線程」和「后臺線程」兩個線程上同時運行，并且兩個線程使用了不同的 JavaScript 引擎作為其運行時：

2）另外特點就是 PrimJS，一個基于 QuickJS 深度定制和優化的 JavaScript 引擎，主要有模板解釋器（利用棧緩存和寄存器優化）、與 Lynx 對象模型高效集成的對象模型（減少數據通信開銷）、垃圾回收機制（非 QuickJS 的引用計數 RC，以提升性能和內存分析能力）、完整實現了 Chrome DevTools Protocol (CDP) 以支持 Chrome 調試器等；

3）“Embedder API” 支持直接與原生 API 交互，提供多平臺支持。

所以從 Lynx 的宏觀目標來看，它即支持類 RN 實現，又有自繪計劃，同時除了 React 模式，后期還適配 Vue、Svelte 等框架，可以說是完全針對 Web 開發而存在的跨平臺架構。

另外支持平臺也足夠，Android、iOS、鴻蒙、Web、PC、小程序都在支持列表里。

最后，Lynx 對“即時首幀渲染 (IFR)”和“絲滑流暢”交互體驗有先天優勢，開發雙線程模型及主線程腳本 (MTS) 讓 Lynx 的啟動和第一幀渲染速度還挺不錯。

比如：

1）Lynx 主線程負責處理直接處理屏幕像素渲染的任務，包括：執行主線程腳本、處理布局和渲染圖形等等，比如負責渲染初始界面和應用后續的 UI 更新，讓用戶能盡快看到第一屏內容；
2）Lynx 的后臺線程會運行完整的 React 運行時，處理的任務不直接影響屏幕像素的顯示，包括在后臺運行的腳本和任務(生命周期和其他副作用)，它們與主線程分開運行，這樣可以讓主線程專注于處理用戶交互和渲染，從而提升整體性能。

而在多平臺上，Lynx 是自主開發的渲染后端支持 Windows、tvOS、MacOS 和 HarmonyOS ，但是不確實是否支持 Linux。

那 Lynx 有什么局限性？

首先：肯定是它非常年輕，雖然它的餅很大，但是對應社區、生態系統、第三方庫等都還需要時間成長。

所以官方也建議 Lynx 最初可能更適合作為模塊嵌入到現有的原生應用中，用于構建特定視圖或功能，而非從零開始構建一個完整的獨立應用。

其次：就是對 Web 前端開發友好，對客戶端而言學習成本較高，并且按照目前的開源情況，除了 Android、iOS 和 Web 的類 RN 實現外，其他平臺的支持和自繪能力尚不明確：

最后：Lynx 的開發環境最好選 macOS，關于 Windows 和 Linux 平臺目前工具鏈兼容性還需要打磨。

總結下來，Lynx 應該會是前端開發的菜，那你覺得 Lynx 是你的選擇么？

8、uni-app x

說到 uni-app 大家第一印象肯定還是小程序，而雖然 uni-app 也可以打包客戶端 app，甚至有基于 weex 的 nvue 支持，但是其效果只能說是“一言難盡”，而這里要聊的 uni-app x ，其實就是 DCloud 在跨平臺這兩年的新嘗試。

具體來說：就是 uni-app 不再是運行在 jscore 的跨平臺框架，它是“基于 Web 技術棧開發，運行時編譯為原生代碼”的模式，相信這種模式大家應該也不陌生了，簡單說就是js（uts）代碼在打包時會直接編譯成原生代碼。

甚至極端一點說：uni-app x 可以不需要單獨寫插件去調用平臺 API，你可以直接在 uts 代碼里引用平臺原生 API ，因為你的代碼本質上也是會被編譯成原生代碼，所以 uts ≈ native code ，只是使用時需要配置上對應的條件編譯(如 APP-ANDROID、APP-IOS)支持。

import Context from"android.content.Context";
import BatteryManager from"android.os.BatteryManager";

import { GetBatteryInfo, GetBatteryInfoOptions, GetBatteryInfoSuccess, GetBatteryInfoResult, GetBatteryInfoSync } from'../interface.uts'
import IntentFilter from'android.content.IntentFilter';
import Intent from'android.content.Intent';

import { GetBatteryInfoFailImpl } from'../unierror';

/**
* 獲取電量
*/
exportconst getBatteryInfo : GetBatteryInfo = function (options : GetBatteryInfoOptions) {
const context = UTSAndroid.getAppContext();
if (context != null) {
    const manager = context.getSystemService(
      Context.BATTERY_SERVICE
    ) as BatteryManager;
    const level = manager.getIntProperty(
      BatteryManager.BATTERY_PROPERTY_CAPACITY
    );

    let ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
    let batteryStatus = context.registerReceiver(null, ifilter);
    let status = batteryStatus?.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
    let isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || status == BatteryManager.BATTERY_STATUS_FULL;

    const res : GetBatteryInfoSuccess = {
      errMsg: 'getBatteryInfo:ok',
      level,
      isCharging: isCharging
    }
    options.success?.(res)
    options.complete?.(res)
  } else {
    let res = new GetBatteryInfoFailImpl(1001);
    options.fail?.(res)
    options.complete?.(res)
  }
}

比如上方代碼：通過 import BatteryManager from "android.os.BatteryManager"可以直接導入使用 Android 的 BatteryManager對象。

可以看到，在 uni-app x 你是可以“代碼混寫”的，所以與傳統的 uni-app 不同，uni-app 依賴于定制 TypeScript 的 uts 和 uvue 編譯器。

具體是：

1）uts 和 ts 有相同的語法規范，并支持絕大部分 ES6 API ，在編譯時會把內置的如Array、Date、JSON、Map、Math、String等內置對象轉為 Kotlin、Swift、ArkTS 的對象等，所以也不需要有 uts 之類的虛擬機，另外 uts 編譯器在處理特定平臺時，還會調用相應平臺的原生編譯器，例如 Kotlin 編譯器和 Swift 編譯器。

2）uvue 編譯器基于 Vite 構建，并對它進行了擴展，大部分特性（如條件編譯）和配置項（如環境變量）與 uni-app 的 Vue3 編譯器保持一致，并且支持 less、sass、ccss 等 CSS 預處理器，例如 uvue 的核心會將開發者使用 Vue 語法和 CSS 編寫的頁面，編譯并渲染為 ArkUI。

而在 UI 上，目前除了編譯為 ArkUI 之外，Android 和 iOS 其實都是編譯成原生體系，目前看在 Android 應該是編譯為傳統 View 體系而不是 Compose ，而在 iOS 應該也是 UIKit ，按照官方的說法，就是性能和原生相當。

所以從這點看，uni-app x 是一個類 RN 的編譯時框架，所以，它的局限性問題也很明顯，因為它的優勢在于編譯器轉譯得到原生性能，但是它的劣勢也是在于轉譯。

具體是：

1）不同平臺翻譯成本較高，并不支持完整的語言，閹割是必須的，API 必然需要為了轉譯器而做刪減，翻譯后的細節對齊于優化會是最大的挑戰；
2）iOS 平臺還有一些騷操作，保留了可選 js 老模式和新 swift 模式，核心是因為插件生態，官方表示 js 模式可以大幅降低插件生態的建設難度，插件作者只需要特殊適配 Android 版本，在iOS和Web端仍使用 ts/js 庫，可以快速把 uni-app/web 的生態遷移到 uni-app x；
3）生態支持割裂，uni-app 和 uni-app x 插件并不通用；
4）不支持 PC；
5）HBuilderX IDE；
6）·····

那么，你覺得 uni-app x 會是你跨平臺選擇之一么？（詳見《uni-app x的鴻蒙NEXT開發指南》）