2026 Flutter VS React Native ，同時在 AI 時代 VS Native 開發，你沒見過的版本

本來已經 2026 ，感覺這種 Flutter VS React Native 的場景其實沒什麼太大對比意義，因為兩個框架現在都比較成熟，也都大規模在各種消費級應用裡被使用，但是這時候 Shorebird 提供了另一個角度對比，我們應該在渲染架構、生态系統穩定性、招聘流程、升級難度和運維控制等方面的對比，Shorebird 給出的角度是：

真正的問題不在於「哪個更快」，而在於風險和控制，比如對交付流程的控制力有多大？操作系統變更多久會迫使SDK 發布緊急補丁？第四年的維護情況會是什麼樣的？能否在流量高峰期立即發布關鍵修復程序？對合規性、安全審查和五年總成本產生怎樣的影響？

然後在結合最近的 AI 與 Native 開發場景，突然就覺得有必要聊一聊。

Flutter VS React Native

相信 Flutter 和 RN 的對比大家應該已經看過不少，但今天我們可以通過一些新的角度來對比。

渲染架構的劃分

實際上這也是 Flutter 和 React Native 區分最大的地方，也是大家最熟悉的烂大街對比，React Native 大部分時候依賴原生控件渲染，而 Flutter 則是擁有獨立的完整渲染棧，這不能絕對性的說是誰好誰壞，只能說根據需求各自有各自的優勢。

但是還是有值得一聊的地方，對於 Flutter 目前基本上已經是 Impeller 引擎為主，Skia 已經逐步被完全取代，這樣就意味著 Flutter 會在構建時真正預先編譯著色器，運行時不需要著色器處理意味著動畫卡頓更少。

目前 Impeller 現在已經成為移動平台的默認渲染器，而 Impeller 在 PC 的落地也在推進。

此外，去年底的時候，Avalonia 也宣布投資 Impeller，和 Flutter 團隊合作將他們的 GPU 優先渲染器 Impeller 移植到 .NET 平台，所以從這個角度看，Impeller 無疑算是成功的，也代表了 Flutter 團隊在自繪跨平台這一領域的成就。

而 React Native 的新架構則走了一條不同的道路，現在 JSI（JavaScript 介面）取代了舊的異步橋接，實現了直接的 C++ 通信，這其實比 Flutter 快了一大步，Flutter 在 Framework 的 FFI 和第三方支持上，同步調用支持進度還是慢了不少，另外 Fabric 則通過同步佈局計算來處理渲染，性能差距顯著縮小，不過核心渲染還是映射成原生控件（雖然也有 react-native-skia 第三方包）。

而在渲染對比上，也有一些數據參考：

• Flutter 2026 年的基準測試顯示，與舊版 Skia 渲染器相比，在複雜動畫過程中，卡頓幀減少了 30-50%
• SynergyBoat 基準測試裡，最壞情況下的丟幀對比：Flutter（Impeller）的丟幀率接近 0%，而 React Native 為 15.51%，Swift（原生）為 1.61%

實際上從數據看，兩個的丟幀率其實都還行。

這裡可能就有人不服了，所以就需要額外提一下 SynergyBoat 的這個測試基準 synergyboat/flashcard-ai-app-cross-platform，它對所有平台（Flutter, Android Native, iOS Native, React Native）實現了一套統一邏輯的基準：

• 核心執行邏輯的統一，所有平台（Flutter, Android Native, iOS Native, React Native）都實現了一套完全對等的執行時間記錄器：

• UI 工作負載的標準化，在列表渲染測試中，Flutter 和 React Native 構造了幾乎完全一樣的測試場景，兩者在移動端均設定了 500 px/s 的滾動速度，均使用線性曲線（Linear Curve/Easing）進行自動滾動，消除了人為操作的不確定性

• 深入底層的原生監控，例如記錄底層引擎還模塊的耗時，兩個平台都測量了「首幀渲染時間」

• 為了消除單次測試的偶然性，基準採用了完整的統計分析：

  • 多維度指標：除了平均幀時間，還有 P95 幀時間（反映掉幀的尖峰情況）和 掉幀率（Jank %）
  • 可靠性校驗：通過計算變異係數（CoV）來衡量測試結果的穩定性
  • 環境基準化：在測試開始前記錄內存基準，通過計算 memoryDeltaMB 來衡量純粹由測試操作引起的增量，消除了系統背景負載的影響

• 環境感知與配置對齊

  • 螢幕刷新率對齊：基準會自動檢測平台的螢幕刷新率（如 60Hz 或 120Hz），動態調整 targetFrameTimeMs（如 60Hz 對應 16.6ms），確保在不同硬體上的評價標準是公平的
  • 發佈模式日誌優化：React Native 版本在 Release 模式下通過自定義 emit 函數和 ASCII 淨化處理，確保日誌記錄本身的開銷不會顯著干擾測試結果

而對於對比結果，可以簡單看結論：

• 幀率餘量 ：基準結果裡， Flutter 的平均幀耗時僅為 4.01ms（遠低於 120Hz 的 8.34ms 預算），而 React Native 雖能維持在 8.34ms 左右，接近預算極限
• P95 與掉幀率：通過 P95 耗時和 1.5 倍預算的「Jank（卡頓）」統計，客觀揭示了 RN 在滾動過程中存在 15.51% 的丟幀，而 Flutter 接近 0%
• 啟動性能 (TTFF) ：代碼中均實現了對「首幀渲染時間」進行的精準捕獲，數據顯示 Flutter (16.67ms) VS RN (32.96ms)

另外除了性能差異之外，在外觀一致性上，Flutter 和 React Native 也有很大差異，例如：

• React Native 依賴原生控件，所以會有平台特性的優勢，但是如果你需要不同平台一致性時，就需要單獨處理和適配，就算同平台，比如在之前 iOS 17 改變 TextInput 表情符號的處理時，React Native 應用也會隨之改變，當三星發布 One UI 更新並修改 TextView 內邊距時，Galaxy 設備上的 React Native 應用也會改變行為
• 而 Flutter 在上述例子裡會始終保持一致，也就是沒了一定的平台特性，但是一致性相對有優勢，不過這也是另外一個問題，當需要平台特性時，需要單獨增加適配，比如特性控件的跟進就天然慢於 RN ，更典型是字體庫，Flutter 只會讀取系統路徑下的字體，如果主題字體在系統是通過 hook Typeface 或者 HwTypeface 等注入，那對於 Flutter 而言也是不生效

而 Shorebird 從 UI 層對比的考量結果是：

在 QA 階段，Flutter 的像素級控制可以讓測試在多平台，或者 Android 平台的不同機型上，在 UI 層面減少測試成本。

运营风险

在這方面 React Native 一致保持著優勢，特別微軟的 App Center CodePush 提供了可靠的基礎架構，推送的 JavaScript 更新後，使用者可以夠立即獲得更新，並且它還能與現有的 CI/CD 流水線無縫集成，企業圍繞它構建了關鍵的工作流程。

不過後來微軟關閉了這個服務，微軟在宣布終止服務時給了大家一年的遷移時間，之後就是自行托管開源的 CodePush 伺服器，或者使用 Expo EAS 或自行構建，不過也都進入到了付費模式，例如 Expo 按月活躍用戶數（即下載過至少一次更新的用戶）收費，外加帶寬費用：

每次更新都會下載完整的 JavaScript 包，一個 12MB 的包分發給 50 萬用戶，每年大約會消耗 6TB 的帶寬，如果每月都發布熱修復補丁，那麼每年就會消耗 72TB 的帶寬

截至 2026 年 2 月，Expo 的企業級套餐起價約為每月 1,000 至 2,000 美元，另加使用量費用，一個實際的企業應用場景：

一款金融科技應用，50 萬活躍用戶，每月更新安全補丁，對應 OTA 的基本費用加上超額費用每年就大概 25,000 至 30,000 美元

而 Flutter 目前熱更新能力就相對較弱，對比 Shorebird 提供了一個定製的 Flutter 引擎，和官方分支不衝突，可以無縫切換：

• 按補丁安裝量計費，免費套餐每月包含 5,000 次安裝，超出部分每次安裝收費 0.01 美元
• 同樣情況下（50 萬用戶，每月補丁安裝量），在企業套餐中，每月費用為 400 美元，或每年 4,800 美元
• 如果每月補丁安裝量超過 100 萬次，可以單獨議價

雖然 Shorebird 看起來便宜，但是 Shorebird 對國區支持不穩定（因為 cloudflare），所以這方面也是個優勢不明顯。

當然 Shorebird 從另一個角度也做了對比：

• Shorebird OTA 的補丁簽名採用 Ed25519 加密簽名，補丁使用開發者的私鑰進行簽名，私鑰始終保留在開發者自己那裡
• Expo EAS 提供類似的簽名功能，但由於 EAS 控制著的構建環境，因此需要信任 Expo 的基礎設施來保障密鑰安全

從實際結果上考量，熱更新還是 RN 更優秀，畢竟 Shorebird 方案也並不是完全開源支持自托管的方案。

成本對比

首先，一個標準的 JS/React 項目在安裝時會從 npm 拉取 700 到 1500 個包，每個包都可以通過預安裝腳本在安裝過程中執行代碼，每個包都有自己的依賴項，相信 JS Package 審核和安全問題大家都聽過：

而 Flutter 的 pub.dev 生態系統嵌套規模相對沒那麼深，整體審計難度相對較低，另外 Flutter 用 AOT 編譯將 Dart 編譯成原生 ARM 機器碼，生成的二進制文件逆向成本對比 JS 工程偏高，這算是 Flutter 的相對優勢。

現在 AI 逆向越來越強，不過相對優勢還是有的。

而在混合開發領域，這方面 React Native 確實更有優勢，因為核心渲染都是原生平台，Facebook 開發它的目的就是為了在不完全重寫代碼的情況下，給原生應用添加新功能。

而 Flutter 因為獨立渲染的緣故，add-to-app 的效果和成本都相對較差，雖然經過了幾個版本的優化，但是對比 React Native ，在混合開發領域確實還是遜色不少。

當然，如果說到 SDK 升級成本對比，Flutter 肯定比 RN 低很多，Flutter 的整體項目升級難度和成功率，還是比 RN 高不少的。

對此 Shorebird 也做了一個簡單的總結：

只能說在成本方面，各有優劣。

AI VS Native

而回到現在的 AI 大潮下，原生開發其實在 VS 跨平台開發上，一直有一個說法：

都是 AI 時代了，都 AI 生產了，還用什麼跨平台，不如直接原生生產，性能更好。

比如在 《OpenAI ：你不需要跨平台框架，只需要在 Android 和 iOS 上使用 Codex》 這種 OpenAI 的實踐下，這類觀點更是有了強力的依據。

實際上使用 Native 開發最大的好處就是可以更容易接近平台的性能，當然我一直說，目前能流行的大部分框架，它的性能瓶頸都不在於框架本身，因為大部分時候已經足夠可以了，更多的瓶頸是在於你寫的代碼質量。

原生的性能好更多在於，它給了你更高的容錯率。

而 AI 時代，確實很大程度可以解決代碼質量問題，因為 AI 在「局部範圍內」和「小規模需求」上，代碼質量確實不錯，但是我這裡加了一些限定詞，因為實際上在中大型項目裡，AI 的整體能力還是挺一般的，如果使用者沒有很好的工程管理能力和 AI 規範，大概率會讓代碼在兩三次迭代後留下一坨屎山。

所以，AI 並不是想像中那麼萬能，至少在短期的移動客戶端開發領域上不是，這一點我們剛聊過的 《AI 目前還無法取代客戶端開發，小紅書的論文告訴你數據》 我們就提到過，當前 AI 在生產級的軟體工程力在移動端還存在巨大局限性：

• 成功率極低 ：表現最好配置的成功率僅為 12% ，大多數任務以「實現不完整」告終
• 複雜度陷阱：任務涉及 1-2 個文件時成功率為 18%，但當涉及 7 個以上文件時，成功率驟降至 2% ，顯示出模型在跨文件長程推理方面的短板
• 「防禦性編程」提示詞更有效：研究發現，使用基於「防禦性編程」（原則的簡潔提示詞，比複雜的提示詞能讓成功率提升 7.4%）

所以不同人用 AI ，也可以得到不一樣的效果，那麼回歸到用 AI 生成 Native （Android/iOS）雙端的優勢上，基於前面的情況來說，對於跨平台在「UI 和通用業務代碼上」，其實還是存在新的成本：

• Token 支出，當然這對於企業可能是「微不足道」的成本差異，兩次生成等於雙倍 Token
• 失敗率，基於小紅書的論文數據，因為 AI 代碼能力和客戶端項目的複雜，AI 的產出通過率並不高，所以需要花費更多的時間和 Token 成本在成功率上，因為雙平台代碼輸出下 AI 失敗率疊加
• Review 成本，實際上 AI 時代測試和審核才是最大成本，很多時候 AI 寫代碼之後，工程師都是審核員的角色，而雙端生成就代表了雙端的審核，除非你閉眼 commit ，能跑就行
• 測試成本，在「UI 和通用業務代碼上」上，需要在雙平台上去檢驗成果

可以看到，實際上 AI 能做更多，但是也帶來了更多 ，AI 在目前不是什么閉眼就能搞定的狀態，Native 固然就是有性能和兼容性優勢，但是 AI 其實沒有給他帶來對比跨平台上真正的成本和效率優勢。

相反，對於 Flutter 和 RN ，很多時候以前因為要修改某些原生插件，而自己又不熟悉平台的情況，現在 AI 反而凸顯出了它的優勢：

首先原生插件普遍上下文內容偏短，功能單一，範圍局限，又有對應已有平台代碼參考，比如一個 Android 開發，在只有 Android 插件之後，讓 AI 補全 iOS 實現，反而成功率更高

另外，在目前的測試和 AI 閉環能力上，Flutter 等框架確實比原生體驗更好，比如在 Claude Code 上，就有人把 Flutter 的 Widget Preview 和 Claude Code 結合在一起實現了自動修改和預覽：

另外，在 AI 時代，原生 Android 的 XML 的寫法確實已經不行了，如果你想要更好的原生 AI 體驗，至少你也要用上 Compose ，而官方也是這麼覺得的，所以谷歌也宣布放棄了 XML 的視圖預覽，未來 XML 的功能支持也不會有什麼更新了：

所以，如果從 AI 角度看，其實原生對比跨平台的優勢並沒有凸顯，除非 AI 真的進化到可脫手階段，不然短時間來看，跨平台在 AI 時代的反而相對會更有優勢，當然，這裡最重要的是區分場景：

有的應用的場景就是注重底層硬體交互，或者對文本複雜輸入場景、字體場景有強要求的，那麼實際上肯定選擇原生可以減少更多不必要的麻煩。

最後

最後，我們可以總結下，從 Shorebird 和 SynergyBoat 提供的對比和數據上看，Flutter 確實存在一定優勢，但是也是區分場景，不同場景下優勢可能就成了劣勢，例如熱更新和混合開發，具體還是看你需要什麼。

但是有一點可以看出來的是，Flutter 和 RN 在現階段的性能上已經非常不錯了，特別是 Flutter 的 Impeller 加持下，幀率和動畫穩定性都有很大提升，如果你是在早些年認識的 Flutter 和 RN，那對於他們的印象，也許需要改改了。

而對於 AI ，目前來說並不能完全體現出雙端的優勢，這個目標效果，還有一段路要走。

參考鏈接

shorebird.dev/blog/react-…

www.synergyboat.com/blog/flutte…

devnewsletter.com/p/state-of-…

原文出處：https://juejin.cn/post/7613230154210852910