本文由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 跨平台框架正式支持鴻蒙；
····
本篇基於當前各大活躍的跨端框架的現狀，對比當前它們的情況和未來的可能，幫助你在選擇框架時更好理解它們的特點和差異。
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開發指南》）
9、本文小結
最後，我們簡單做個總結：
什麼，你居然看完了？事實上我寫完都懶得查錯別字了，因為真的太長了。
10、參考資料
[1] 快速瞭解新一代跨平台桌面技術——Electron
[2] Electron初體驗(快速開始、跨進程通信、打包、踩坑等)
[3] vivo的Electron技術棧選型、全方位實踐總結
[4] 蘑菇街基於Electron開發IM客户端的技術實踐
[5] 融雲基於Electron的IM跨平台SDK改造實踐總結
[6] 網易雲信基於Electron的IM消息全文檢索技術實踐
[7] 得物基於Electron開發客服IM桌面端的技術實踐
[8] 新QQ桌面版為何選擇Electron作為跨端框架
[9] 全面解密新QQ桌面版的Electron內存優化實踐
[10] 快速對比跨平台框架Electron、Flutter、Tauri、React Native等
[11] 環信基於Electron打包WebIM桌面端的技術實踐
[12] 萬字長文詳解QQ Linux端實時音視頻背後的跨平台實踐
[13] 從理論到實踐，詳細對比Electron和Tauri的優劣
（本文已同步發佈於：http://www.52im.net/thread-4843-1-1.html）
