哈嘍，我是老劉

2024年全球移動應用下載量突破2570億次，但開發者面對的現實是：平台越來越多、成本翻倍、體驗難統一。iOS/Android/鴻蒙/桌面端/Web/小程序，各有一套開發與設計規範，原生很難在多設備上做到一致。

跨平台是機會，卻更是選擇題：Flutter講性能、React Native講生態、uni-app講覆蓋、KMP講原生。

如何做好這道選擇題，把有限的資源發揮出最大的效率？

老劉每個月為大家畫出最新的跨平台技術選型地圖，幫你快速做決策。

本月很多跨平台框架都有更新，另外新框架Valdi加入戰場，為跨平台開發帶來了新的可能性。

一、2025年跨平台技術趨勢

第一個變化：性能差距在縮小

現在Flutter的自渲染引擎已經能達到60fps的流暢度。

uni-app x的UTS編譯技術，直接把代碼轉成原生Kotlin和Swift。

跨平台方案與原生的性能差距已經小到用户感知不到的程度。

第二個變化：大廠開始重注跨平台

2024年5月，微軟正式停止Xamarin支持，全力推.NET MAUI。

同一時間，Google官方開始支持Kotlin Multiplatform。

第三個變化：AI加持下的開發效率暴增

現在用Claude Code、Cursor等工具寫Flutter代碼，效率比以前高了3倍。

特別是UI界面，直接傳入設計圖就能生成可用的代碼。

跨平台開發的學習門檻大幅降低。

最新技術動態

React Native 新架構全面啓用

React Native 0.82 里程碑版本

React Native 0.82 - A New Era: https://reactnative.dev/blog

• 2025年10月8日發佈，完全基於新架構運行
• 0.82.1 已在10月推送
• 0.83 作為下一小版本尚未在11月正式 GA

Kotlin Multiplatform 生態成熟加速

Compose Multiplatform 1.9.3 發佈

• Compose Multiplatform 1.9.3 於11月6日發佈

  帶來對最新 AGP 的兼容建議、引入實驗性的 MaterialExpressiveTheme 、並將 Material3 與 Gradle 插件版本解耦

.NET MAUI 企業級發展

.NET 10 預覽與 MAUI 增強

.NET Multi-platform App UI：https://dotnet.microsoft.com/en-us/apps/maui

• .NET 10 已在 .NET Conf 2025（11月11–13日）正式發佈併成為 LTS（支持到 2028-11-10）
• Uno Platform 6.3 帶來 .NET 10（RC）支持、VS 2026 兼容，以及 WebAssembly 端通過 WebWorkers 的圖像解碼性能提升；官方宣佈與微軟 .NET 團隊深度協作推進 MAUI/.NET for Android
  Uno 博客與資訊： platform.uno/blog/uno-platform-6-3

Flutter 平台更新

Flutter 3.38 技術更新: https://docs.flutter.dev/release/whats-new

• 3.38 於11月發佈，支持 Apple 強制的 UIScene 生命週期，需要進行代碼遷移
• 文檔站點遷移到 Jaspr（Dart Web 框架），開發者文檔與工具集成改進
• Widget Previewer 在 VS Code/IntelliJ 進一步集成，提升預覽與調試效率

• 平台支持同步 iOS 26、Xcode 26、macOS 26，穩定性與兼容性提升

  • Dart 3.6 點速記語法（Dot shorthands）默認開啓，減少樣板代碼（如 .start）
  • Web 開發增強：web_dev_config.yaml 支持配置開發服務器與代理，熱重載可多瀏覽器連接
  • OverlayPortal 新能力：子 Widget 可渲染到任意 Overlay，適合彈窗、氣泡、提示等複雜浮層
  • Windows 桌面增強：PlatformDispatcher.displays 可獲取顯示器分辨率、刷新率、DPR、物理尺寸等
  • 修復 Android 端 Activity 銷燬內存泄漏（issue #173770），影響自 3.29.0 引入的缺陷

升級提示（3.38）

• Android：默認 NDK 升級到 r28，滿足 Google Play 16 KB 頁面大小兼容要求
• iOS：嚴格按 UIScene 生命週期遷移，參考官方遷移指南
• 版本選擇策略：觀察期 2–3 個月，穩定後再提升為主力版本

uni-app x 11月進展

uni-app x 4.84/4.85 更新日誌: https://uniapp.dcloud.io/release

• 新增 API uni.createWorker 支持 Worker 線程，提升計算與渲染併發能力（4.84）
• App(iOS/Android) 新增 image 支持 SVG、live-player/live-pusher 實時音視頻、廣告視頻等能力
• HarmonyOS 增強：themeChange 主題切換、登錄/分享、屏幕亮度 API、邏輯層 JSVM 遷移至子線程
• 多平台穩定性修復：list-view 拖動加載崩潰、編譯器 async 嵌套報錯、web-view/scroll-view 等問題修復（4.85）

新的跨平台框架 Valdi 加入戰場

• 4.3章節會詳細介紹 Valdi 框架的設計與實現

接下來老劉按照跨平台技術框架的三種路線，分別介紹一下目前主流的跨平台技術。

二、自渲染類框架

什麼是自渲染？

簡單來説，就是框架自己畫界面，不用系統提供的組件。

就像遊戲引擎一樣，每個像素都是自己控制的。

這樣做有什麼好處？

第一，界面完全一致

在iPhone上看到的按鈕，和在Android上看到的按鈕，一模一樣。

同樣的UI代碼，在不同平台上運行，不會因為轉嫁到系統的UI組件而導致展示效果或者邏輯不一致。

第二，性能媲美原生

因為跳過了系統的UI層，直接操作GPU繪製。

本質上和原生系統框架採用相同的架構，因此性能上也不會有太大的區別。

第三，沒有兼容性bug

其它兩種方案不管是中間層還是轉義，最終都會去調用系統原生的組件。

這個過程中因為不同系統的組件功能差異和實現方案不同就會導致一些兼容性問題。

其中比較複雜的問題可能需要開發者自己去原生代碼的層面去定位和解決。

而自渲染的框架，因為跳過了系統的UI層，所以不會有這個問題。

2.1 Flutter

Flutter現在有多火？

2024年Stack Overflow調查顯示，Flutter是最受歡迎的跨平台框架。

全球有超過500萬開發者在使用。

連阿里巴巴、騰訊、字節跳動都在使用Flutter。

為什麼這麼多大廠選擇Flutter？

原因一：性能真的強

自從切換了Impeller引擎，Flutter真的是和原生應用性能一致。

原因二：開發效率高

熱重載功能讓你改代碼後，1秒鐘就能看到效果。

不用重新編譯，不用重新安裝。

同時，Dart語言本身的在編碼複雜性和功能性方面平衡做的非常好，日常開發的效率很高。

原因三：生態成熟

pub.dev上有超過4萬個插件包。

基本上你能想到的功能，都有現成的插件。

地圖、支付、推送、數據庫...應有盡有。

原因四：對單元測試的良好支持

Flutter是目前為止客户端開發領域中對單元測試支持最好的框架。

這一點比原生開發都要好，是Flutter獨有的優勢。

如果你的團隊使用TDD或者敏捷流程，Flutter可能是最優選擇。

原因五：AI的積極跟進

Flutter在AI時代的表現讓人刮目相看。

Google官方推出了Flutter AI Toolkit，直接集成了Gemini API。

開發者可以用幾行代碼就實現AI聊天、圖像識別、語音轉文字等功能。

而且Flutter對AI模型的本地部署支持也很好。

TensorFlow Lite、ONNX Runtime都有官方插件。

你可以把AI模型直接打包到應用裏，不依賴網絡也能跑AI功能。

這在隱私要求高的場景下特別有用。

最近還有個新玩意兒——Dart MCP Server。

簡單説，就是讓AI助手能直接理解和操作你的Dart/Flutter項目。

你可以讓AI直接幫你寫Flutter代碼、讀取運行中的組件樹、調試問題、優化性能。

總之，可以看到Flutter團隊在對接AI方面的前瞻性和重視度。

Flutter適合什麼項目？

高性能應用：比如音視頻應用

複雜UI應用：比如電商、社交應用

需要快速迭代的項目：比如創業公司的MVP產品

但Flutter也有坑

學習成本高：需要學Dart語言，和JavaScript差別挺大

包體積大：最小的Flutter應用也要10MB+

原生功能調用複雜：需要寫Platform Channel

總結一下

如果你的項目對性能要求高，UI比較複雜，團隊有時間學習新技術。

Flutter是最佳選擇。

特別是如果你們團隊之前沒有移動端開發經驗，Flutter的學習曲線反而比原生開發更平緩。

三、中間層類框架

什麼是中間層框架？

簡單來説，就是在你的代碼和系統原生組件之間，加了一個"翻譯官"。

你用JavaScript寫界面邏輯，框架幫你"翻譯"成原生的Button、TextView。

這種方案有什麼特點？

第一，開發體驗接近Web

如果你的團隊熟悉React、Vue這些Web框架，上手會很快。

基本上就是把Web開發的那套思路搬到移動端。

第二，能調用原生組件

最終渲染的還是系統原生的Button、Input。

所以界面看起來很"原生"，符合各平台的設計規範。

第三，存在性能損耗

因為有個"翻譯"的過程，JavaScript和原生代碼之間要頻繁通信。

就像兩個人通過翻譯官對話，肯定比直接對話慢一些。

但這個損耗在交互不頻繁的界面中，用户是感知不到的。

3.1 React Native

React Native的優勢

原因一：Web開發者的福音

如果你會React，學React Native基本沒有門檻。

同樣的JSX語法，同樣的組件化思想，同樣的狀態管理。

一個熟練的React開發者，一週就能上手React Native。

原因二：生態系統超級豐富

npm上有超過15萬個React Native相關的包。

導航、動畫、圖表、支付...你能想到的功能都有現成的庫。

而且因為和React共享生態，很多Web端的庫稍作修改就能用。

原因三：熱更新能力

這是React Native的殺手鐗功能。

發現bug？不用重新發版，直接推送補丁代碼就能修復。

新功能上線？用户打開App就能看到，不用去應用商店更新。

這對產品迭代速度的提升是巨大的。

原因四：Meta的持續投入

2024年Meta發佈了新架構（New Architecture）。

引入了Fabric渲染器和TurboModules，性能提升了30%。

2025年10月8日，React Native 0.82 正式發佈，新架構全面啓用，舊架構正式退役。

React Native適合什麼項目？

快速迭代的產品：比如社交應用、內容應用

Web技術棧團隊：已經有React開發經驗的團隊

需要熱更新的應用：比如電商、新聞類應用

但React Native也有侷限

性能瓶頸：複雜動畫和大量數據處理時，橋接開銷明顯

原生功能依賴：新的系統API需要等社區或自己封裝

版本升級成本：大版本升級可能需要改很多代碼

3.2 .NET MAUI

.NET MAUI是什麼來頭？

2024年5月，微軟正式停止了Xamarin的支持。

.NET MAUI（Multi-platform App UI）成為微軟官方的跨平台解決方案。

這不是簡單的換個名字，而是架構的全面升級。

MAUI相比Xamarin有什麼改進？

第一，統一的項目結構

以前Xamarin需要為每個平台創建單獨的項目。

MAUI只需要一個項目，就能構建所有平台的應用。

第二，性能大幅提升

新的渲染引擎減少了50%的內存佔用。

啓動速度比Xamarin快了30%。

第三，開發體驗優化

熱重載功能讓你改C#代碼後，立即看到效果。

集成了最新的.NET 8特性，開發效率更高。

.NET MAUI的獨特優勢

企業級支持

微軟提供長期技術支持（LTS）。

對於企業應用來説，這種穩定性保障非常重要。

強大的數據處理能力

C#在處理複雜業務邏輯方面有天然優勢。

特別是金融、ERP這類數據密集型應用。

與微軟生態深度集成

如果你的後端用Azure、數據庫用SQL Server。

MAUI能提供最佳的集成體驗。

.NET MAUI適合什麼項目？

企業級應用：比如CRM、ERP、辦公應用

.NET技術棧團隊：已經有C#開發經驗的團隊

數據密集型應用：比如金融、醫療、教育管理系統

但MAUI也有短板

學習門檻高：需要掌握C#和.NET生態

社區相對較小：第三方庫沒有React Native豐富

移動端特性支持滯後：新的移動端API支持可能會慢一些

中間層框架怎麼選？

如果你的團隊主要是Web開發者

選React Native，學習成本最低，生態最豐富。

如果你的項目是企業級應用

選.NET MAUI，穩定性和長期支持更有保障。

如果你需要頻繁的熱更新

選React Native，這是它的核心優勢。

如果你的應用數據處理邏輯複雜

選.NET MAUI，C#在這方面更有優勢。

總結一下中間層框架的特點

優勢：學習成本低，能複用Web開發經驗，界面原生感強。

劣勢：存在橋接性能損耗，依賴第三方庫封裝原生功能。

適合場景：快速開發、團隊技術棧匹配、對原生感要求高的項目。

四、轉譯類框架

什麼是轉譯？

簡單來説，就是把你寫的高級語言代碼，"翻譯"成目標平台的原生代碼。

比如你用Kotlin寫業務邏輯，框架幫你"翻譯"成iOS的Swift代碼。

或者你用類TypeScript的語法寫界面，框架幫你"翻譯"成Android的Kotlin和iOS的Swift。

這種方案有什麼特點？

第一，性能最接近原生

因為最終運行的就是原生代碼，沒有任何中間層損耗。

就像你直接用Swift寫iOS應用，用Kotlin寫Android應用一樣。

第二，能享受原生生態

轉譯後的代碼可以直接調用平台的所有API。

第三，轉譯效果可能不完美

畢竟是機器"翻譯"的代碼，有時候可能不如手寫的原生代碼優雅。

特別是複雜的業務邏輯，轉譯後的代碼可能需要人工優化。

但這個問題隨着AI技術的發展，正在快速改善。

4.1 Kotlin Multiplatform (KMP)

KMP為什麼突然火了？

2024年是KMP的爆發年。

5月份，Google在I/O大會上宣佈官方支持KMP。

以前KMP只是JetBrains的"個人項目"，現在有了Google的官方背書。

Android開發者可以放心使用，不用擔心被拋棄。

Kotlin-to-Swift 導出功能已公開發布（10月首次發佈），仍處早期階段。

你用Kotlin寫的業務邏輯，可以直接轉成Swift代碼。

iOS開發者拿到的就是純Swift代碼，可以像原生項目一樣調試和優化。

KMP的核心理念

"業務邏輯用KMP共享，UI用Compose Multiplatform統一開發"

這是KMP的最新發展方向，結合了Compose Multiplatform的強大能力。

傳統的KMP是"業務邏輯共享，UI各平台原生"。

但現在有了更好的選擇——Compose Multiplatform。

一套Compose代碼可以運行在Android、iOS、Desktop、Web等所有平台。

業務邏輯用KMP共享，UI用Compose Multiplatform統一開發。

這樣做有什麼好處？

第一，真正的一套代碼多平台

不僅業務邏輯共享，UI也可以共享，開發效率大幅提升。

第二，保持原生性能

Compose Multiplatform在各平台都編譯為原生代碼，性能接近原生應用。

第三，技術棧統一

全部使用Kotlin生態，學習成本更低，團隊協作更高效。

第四，漸進式遷移

你不需要重寫整個應用，可以先從一個模塊開始。

比如先把網絡層用KMP重寫，然後逐步遷移UI到Compose Multiplatform。

KMP + Compose Multiplatform適合什麼項目？

需要快速多平台發佈的項目

一套代碼可以同時發佈到Android、iOS、Desktop、Web等平台。

開發效率比傳統KMP方案大幅提升。

密集調用原生API的項目

比如遊戲、金融交易、實時通信應用。

KMP + Compose Multiplatform能提供真正的原生無縫調用。

Kotlin技術棧的團隊

如果團隊熟悉Kotlin和Jetpack Compose。

這個組合是最自然的選擇，學習成本最低。

已有原生應用的團隊

可以漸進式遷移，先遷移業務邏輯，再遷移UI。

風險可控，收益明顯。

但這個組合也有挑戰

Compose Multiplatform 在 iOS 端已穩定：生態仍在加速建設，注意版本兼容與插件成熟度

學習成本相對較高：需要掌握Kotlin和Compose

生態還在建設中：第三方庫相對較少，但發展很快

4.2 uni-app / uni-app x

uni-app的進化之路

説到uni-app，很多人的印象還停留在"小程序開發工具"。

但2024年，uni-app發生了質的變化。

傳統uni-app：基於Vue.js + JavaScript，更適用於小程序開發

uni-app x：全新架構，使用UTS語言，性能達到原生級別

這不是簡單的版本升級，而是技術路線的根本改變。

uni-app x的技術突破

第一，UTS語言

UTS（UniTypeScript）是DCloud自研的編程語言。

語法類似TypeScript，但編譯後直接生成原生代碼。

Android平台編譯成Kotlin，iOS平台編譯成Swift，鴻蒙平台編譯成ArkTS。

第二，uvue渲染引擎

這是uni-app x的核心技術。

不同於傳統的WebView渲染，uvue直接調用原生渲染引擎。

性能和原生應用完全一致，沒有任何損耗。

第三，無橋接架構

傳統跨平台框架都有個"橋接層"，用來連接JavaScript和原生代碼。

uni-app x直接編譯成原生代碼，完全沒有橋接層。

這意味着沒有跨語言通信損耗，性能達到原生級別。

第四，直接調用原生API

因為編譯後就是原生代碼，可以直接調用平台的所有API。

不需要等插件封裝，新的系統功能立即可用。

uni-app x的獨特優勢

平台支持最全

這是uni-app的傳統優勢。

一套代碼可以發佈到：iOS、Android、Web、各種小程序、快應用、鴻蒙...

總共支持14+個平台，這是其他框架做不到的。

小程序優先的設計理念

如果你的產品需要同時支持App和小程序。

uni-app是唯一的選擇。

其他框架都是"App優先"，小程序支持都是後加的。

國產化支持

對鴻蒙、信創等國產化平台支持最好。

這對國內企業來説非常重要。

學習成本低

如果你會Vue.js，學uni-app基本沒有門檻。

語法、組件、生態都和Vue高度一致。

但uni-app也有侷限

生態相對封閉：主要依賴DCloud的生態

國際化程度低：海外開發者使用較少

技術棧綁定：主要適合Vue技術棧

4.3 Valdi 加入戰場

Valdi 是啥？

Snapchat憋了8年的大招

這個叫Valdi的框架，在Snapchat內部默默服役了整整8年，扛住了8.5億月活的洪荒流量。

開源僅僅7天，GitHub星標就衝破了4.2k，直接霸榜Trending。

為什麼Snapchat要自己造輪子？

2016年，Snapchat用户數爆炸式增長。

React Native剛出，性能和生態都不足以讓大型應用放心。

Flutter還沒發佈（2017年才發佈Beta版）。

純原生開發又意味着iOS/Android兩套代碼，開發效率很難滿足高速增長的需求。

於是Snapchat決定拉起一支小分隊，用TypeScript寫UI，讓編譯器直接吐出原生控件。

內部代號"Valdi"，源自北歐神話的"力量之神"。

8年過去，200+版本，5000+次MR

Valdi 的基本原理

Valdi的核心思路屬於轉義方案的範疇，但是併發代碼級轉義。

具體怎麼做到的？

1. 編譯時轉譯

• TSX代碼 → 原生視圖代碼（OC/Swift + Java/Kotlin）
• 佈局引擎用C++重寫，支持獨立重渲染和視圖回收
• 編譯階段就生成類型安全的綁定，空指針異常直接堵在編譯期

2. 運行時架構

• 無JS Bridge，零跨線程通信開銷
• 業務邏輯可分層：性能關鍵路徑用C++/Swift/Kotlin寫"Polyglot模塊"，框架自動生成TS綁定
• 非關鍵邏輯留在JS端，配合Worker線程做後台任務

3. 熱重載機制

• 文件保存 → 200ms內看到刷新
• 不丟狀態、不重啓App
• VSCode調試鏈完整，斷點直接斷在TS源碼

4. 內存管理

• 自動視圖回收
• 增量渲染

這種技術方案其實是介於轉譯和中間層之間的一種方式。

UI組件樹翻譯成原生組件，組件的生命週期交給C++編寫的引擎管理，業務邏輯部分則保留在TS層。

這樣的好處是在一定程度上避免了轉譯類方案代碼翻譯不到位造成的一些問題。

但是仍然會有中間層方案在高UI交互場景下的性能問題，這部分就需要把處理邏輯放到C++/Swift/Kotlin編寫的"Polyglot模塊"解決。

總的來説，這套架構在Snapchat內部跑了8年，扛住了8.5億月活的洪荒流量。

現在開源出來，就是把踩過的坑都幫你填平了。

Valdi 尚處於生命週期的早起

平台限制

目前僅支持iOS、Android和 macOS

Windows版本要等到2026年Q1。

Web支持也還在路上，預計2026年Q2才會發佈。

生態建設初期

相比React Native和Flutter，Valdi的開源生態和第三方組件庫還在早期階段。

複雜圖表、地圖等高級組件需要自己動手橋接原生SDK。

雖然可以通過"Polyglot模塊"和custom-view嵌入原生控件，但短期還是需要投入額外開發成本。

API穩定性風險

當前版本還是Beta-0.0.1，API可能會微調。

官方建議先在獨立模塊或小業務試水，不要直接all in。

對原生能力的要求

雖然主打"零原生代碼"，但性能關鍵路徑還是需要寫C++/Swift/Kotlin的"Polyglot模塊"。

平台API調用、生命週期管理等也需要一定的原生開發經驗。

CI/CD複雜度

需要搭建成熟的CI構建流程和代碼生成規範。

多端工程和綁定管理相對複雜，對團隊的技術棧要求較高。

總結一句話：Valdi很有潛力，但現在更適合技術探索，不是生產環境的首選。

站在純粹客户端跨平台開發的角度，轉義類方案老劉目前更推薦KMP。

Valdi可以作為一個有潛力的備選，等生態更加成熟後再重新考慮。

轉譯類框架怎麼選？

如果你有現有的原生應用

選KMP，可以漸進式遷移，風險最小。

如果你需要支持小程序

選uni-app，這是它的核心優勢。

如果你對性能要求極高

KMP和uni-app x都可以，看團隊技術棧。

如果你的團隊是Vue技術棧

選uni-app，學習成本最低。

如果你的團隊是Android技術棧

選KMP，Kotlin是你們的強項。

總結一下轉譯類框架的特點

優勢：性能最接近原生，能享受原生生態，沒有運行時損耗。

劣勢：學習成本相對較高，轉譯效果可能需要優化。

適合場景：對性能要求高、需要調用大量原生功能、有原生開發基礎的團隊。

五、技術選型指南

看了這麼多框架，是不是更糾結了？

別慌，老劉給你一個簡單粗暴的選型指南。

5.1 Flutter：大多數App的不二之選

其實對於大多數App來説，Flutter都是當前階段最合適的選擇

為什麼這麼説？

性能足夠強悍

如果在大街上隨機找100個人，把他們手機裏面的非遊戲類App都拿出來，那麼其中99%都是Flutter可以勝任的。

對於性能有極端要求的App來説其實大概率原生開發也不行，需要更深度的優化方式。

比如把數據加解密、視頻編解碼等工作封裝到更底層的so庫中。

而這種優化方案在Flutter項目中也能使用，工作量和原生中差不多。

開發效率夠高

Flutter的熱重載功能，改代碼後1秒內就能看到效果。

這比原生開發快了10倍不止。

而且Flutter的組件庫非常豐富。

Material Design和Cupertino組件開箱即用。

對於更復雜的組件和繪製定製場景，由於Flutter自帶渲染引擎，因此也可以直接在暴露給開發者的canvas上進行更復雜的渲染定製。

TDD開發流程的完美搭檔

Flutter天生支持單元測試、集成測試、UI測試。

測試覆蓋率可以輕鬆達到90%以上。

CI/CD集成也非常簡單，GitHub Actions、GitLab CI都有現成的模板。

如果計劃採用TDD相關的開發流程，Flutter可能是目前唯一的選擇。

AI時代的寵兒

Google全力加持Flutter，AI工具鏈日趨完善。

GPT、Cursor、Claude Code對Flutter的支持都很好。

寫Flutter代碼，AI能幫你完成80%的重複工作。

Flutter適合什麼項目？

• 需要高性能的應用（遊戲、視頻、圖形處理）
• 對UI一致性要求高的應用
• 團隊有充足的學習時間
• 需要長期維護的項目
• 對包體積不是特別敏感的應用

5.2 KMP：潛力股還是畫餅？先別急着上車

Kotlin Multiplatform：Google親兒子的野心與現實

KMP確實很香，但現在上車可能還早了點。

現狀分析：技術很香，但生態還在"襁褓期"

KMP的技術理念非常先進。

但問題是——生態還不夠成熟。

第三方庫支持有限，很多常用功能需要自己封裝。

調試工具也不夠完善，出了問題排查起來比較麻煩。

適用場景：密集調用原生API的項目可以關注

如果你的應用需要大量調用原生API：

• 相機、麥克風、傳感器
• 藍牙、NFC、GPS
• 系統級權限管理

KMP確實有優勢。

因為它可以直接調用原生代碼，沒有性能損耗。

風險提醒：早期採用者需要踩坑的心理準備

選擇KMP，你需要做好這些準備：

• 遇到問題時，Stack Overflow上的答案可能很少
• 第三方庫可能不支持，需要自己寫原生橋接
• 團隊需要同時掌握Kotlin、Swift、Android、iOS開發
• 項目初期開發效率可能不如Flutter

未來展望：如果KMP真正成熟，將是原生開發的強力補充

Google已經把KMP列為官方支持的技術。

JetBrains也在大力投入。

如果生態能在2025年下半年成熟起來，KMP確實值得考慮。

建議：除非你是技術極客，否則再等等

如果你的團隊技術實力很強，喜歡嘗試新技術，可以在小項目上試試KMP。

但如果你需要穩定可靠的解決方案，建議再等一年。

等KMP的生態更成熟一些，再考慮大規模使用。

5.3 App + 小程序：別被"一套代碼走天下"忽悠了

App和小程序一套代碼？這可能是個偽命題！

很多人被"一套代碼，多端運行"的口號忽悠了。

以為App和小程序可以用同一套代碼。

但現實是——這樣做可能得不償失。

思維誤區：把小程序當App的"乞丐版"是大錯特錯

很多人覺得小程序就是App的簡化版。

功能少一點，界面簡單一點，用户體驗差一點。

這種想法完全錯了。

App和小程序應該承擔不同的產品職責。

正確姿勢：App和小程序應該承擔不同的產品職責

App的優勢：

• 性能更好，可以做複雜交互
• 可以離線使用
• 推送通知更及時
• 用户粘性更高

小程序的優勢：

• 獲客成本更低
• 分享傳播更容易
• 用户使用門檻更低
• 可以藉助平台流量

成功案例解析：微信讀書的智慧分工

微信讀書就是一個很好的例子。

App承擔重交互功能：

• 長時間閲讀體驗優化
• 個性化推薦算法
• 離線下載功能
• 複雜的社交互動

小程序專注營銷拉新：

• 好友推薦分享
• 讀書打卡活動
• 限時免費活動
• 新用户引導體驗

這樣分工，App和小程序各司其職，效果比"一套代碼"好得多。

技術選型建議

功能重疊度高的情況：

如果你的App和小程序功能重疊度超過70%，可以考慮uni-app等跨端方案。

比如電商類應用，商品展示、購物車、訂單管理這些功能，App和小程序基本一樣。

功能差異化大的情況：

如果App和小程序的功能差異很大，建議分別選擇最適合的技術棧。

App用Flutter或原生開發，專注用户體驗。

小程序用原生小程序開發，專注營銷轉化。

避坑指南：不要為了技術統一而犧牲用户體驗

很多團隊為了技術棧統一，強行用一套代碼開發App和小程序。

結果App體驗不如原生，小程序功能又太複雜。

兩邊都不討好。

記住：技術是為產品服務的，不是為了技術而技術。

總結一下技術選型的核心原則

1. 大多數情況選Flutter：性能、生態、開發效率都很均衡
2. KMP可以關注但別急着用：等生態成熟一些再説
3. App和小程序要差異化定位：不要被"一套代碼"忽悠
4. 根據團隊技術棧選擇：學習成本也是成本
5. 考慮項目的長期維護：選擇有長期支持的技術

六、總結與建議

寫了這麼多，老劉最後給你一個終極建議。

2025年跨平台開發，記住這三個關鍵詞：務實、聚焦、長期主義。

務實：別追求完美的技術方案

很多團隊陷入"技術潔癖"。

總想找到一個完美的跨平台方案，既要性能好，又要學習成本低，還要生態豐富。

醒醒吧，這樣的方案不存在。

每種技術都有trade-off。

Flutter性能好但包體積大。

React Native生態好但有橋接損耗。

KMP接近原生但生態不成熟。

uni-app平台全但主要適合Vue技術棧。

選擇技術的核心是：在當前約束條件下，哪個方案的收益最大。

不要追求完美，要追求合適。

聚焦：一個團隊最多掌握兩種跨平台技術

很多公司什麼技術都想試。

Flutter也搞，React Native也搞，KMP也要研究。

結果每個都不精通，遇到問題都解決不了。

建議：選定一個主力技術棧，最多再備一個備選方案。

長期主義：技術選型要考慮3年後的維護成本

很多人以為選定技術棧就萬事大吉了。

其實真正決定項目生死的，是你選定技術棧之後做的那些事。

架構設計夠不夠清晰？

模塊劃分是否合理，接口設計是否穩定，這些直接影響後續迭代的難度。

開發流程夠不夠規範？

CI/CD流水線、代碼審查、測試覆蓋率，這些看似繁瑣的流程，3年後會救你的命。

代碼規範夠不夠嚴格？

命名規範、註釋規範、目錄結構，新人能不能快速上手，老代碼能不能看懂。

技術債務管理夠不夠及時？

每次為了趕進度留下的坑，3年後都會變成巨坑。

選定技術棧不是終點，而是起點。

做好這些基礎建設，才是項目能持續健康演進的根本。

否則，再好的技術棧也救不了你。

最後的最後：技術選型沒有標準答案

老劉寫這篇文章，不是為了告訴你"必須選哪個技術"。

而是希望你在選擇時，能有一個清晰的思考框架。

2025年，跨平台開發已經不是"能不能做"的問題，而是"怎麼做得更好"的問題。

選對了技術棧，團隊效率起飛。

選錯了技術棧，就是幾個月的坑。

希望這篇"跨平台開發地圖"能幫你避開那些坑，找到最適合你的路。

如果看到這裏的同學對客户端開發或者Flutter開發感興趣，歡迎聯繫老劉，我們互相學習。

點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。

可以作為Flutter學習的知識地圖。

覆蓋90%開發場景的《Flutter開發手冊》