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

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

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

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

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

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

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

而 Impeller 正是這個背景的產(chǎn)物，簡單說，App 所需的所有著色器都在 Flutter 引擎構(gòu)建時進行離線編譯，而不是在應(yīng)用運行時編譯。

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

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

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

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

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

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

所以，F(xiàn)lutter 適合你的場景嗎？

4、React Native

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

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

比如：

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

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

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

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

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

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

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

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

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

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

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

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

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

3）平臺 API 兼容復(fù)雜度較高

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

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

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

7）····

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

5、Compose Multiplatform

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

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

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

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

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

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

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

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

另外現(xiàn)在 CMP 開發(fā)模式下的 hot reload 已經(jīng)可以使用，不過暫時只支持 desktop，原理大概是只支持 jvm 模式。

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

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

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

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

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

6、Kuikly

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

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

目前還處于開發(fā)過程中：

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

那么，Kuikly 和 RN 之間又什么區(qū)別?

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

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

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

另外 Kuikly 表示后續(xù)會支持全平臺小程序，這也是優(yōu)勢之一。

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

那么 Kuikly 存在什么局限性？

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

1）不可直接依賴平臺能力；
2）不可使用多線程和協(xié)程；
3）不可依賴內(nèi)置部分。

其他的還有：

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

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

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

7、Lynx

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

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

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

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

而對于 Lynx 主要的技術(shù)特點在于：

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

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

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

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

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

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

比如：

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

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

那 Lynx 有什么局限性？

首先：肯定是它非常年輕，雖然它的餅很大，但是對應(yīng)社區(qū)、生態(tài)系統(tǒng)、第三方庫等都還需要時間成長。

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

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

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

總結(jié)下來，Lynx 應(yīng)該會是前端開發(fā)的菜，那你覺得 Lynx 是你的選擇么？

8、uni-app x

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

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

甚至極端一點說：uni-app x 可以不需要單獨寫插件去調(diào)用平臺 API，你可以直接在 uts 代碼里引用平臺原生 API ，因為你的代碼本質(zhì)上也是會被編譯成原生代碼，所以 uts ≈ native code ，只是使用時需要配置上對應(yīng)的條件編譯(如 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"可以直接導(dǎo)入使用 Android 的 BatteryManager對象。

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

具體是：

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

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

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

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

具體是：

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

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