// 簡報
為何這個決定如此複雜
持份者想要頂級用戶體驗、更快的時間表及可預測的預算——而平台 API 每季都在演變。本指南以同一套企業標準審視 Flutter、React Native 與原生開發（Swift/Kotlin），將炒作與現實分開。沒有萬靈丹，只有攤開來講的取捨。
我們會從原始效能、開發體驗及營運考慮三方面進行基準比較，讓你以具體數據支持自己的建議。可作為路線圖檢討或 RFP 評估前的預讀材料。
效能分析
效能並非單一指標，而是啟動時間、幀率穩定性、記憶體佔用及原生 API 存取的總和。以下是各技術棧在 2025 年的表現。
| 技術棧 | 概要 |
|---|---|
| 原生（Swift/Kotlin） | 直接編譯為平台二進制檔案，零抽象層。是圖形、AR/VR 及硬件加速的黃金標準。開銷極低，並率先支援操作系統層面的最新功能。 |
| Flutter | 編譯為 ARM/x86 機器碼，並透過 Skia 進行渲染。幀率節奏與動畫細膩度足以媲美原生。網頁端的 CanvasKit 以少量 WASM 成本，換取同樣的一致性。 |
| React Native | 配備 Hermes 引擎的新架構降低了橋接延遲，但數據最終仍需在 JavaScript 與原生環境之間傳遞。對大多數 CRUD 應用程式而言表現出色；小眾工作負載或需原生模組才能達到同等水平。 |
對於任務關鍵的渲染管線（遊戲、醫療影像），原生仍然是贏家。Flutter 已為 90% 的使用場景收窄差距，而 React Native 的橋接改進，令其表現比以往更可預測。
開發體驗
上市時間取決於你要維護多少程式碼，以及團隊迭代的速度。Flutter 的單一程式碼庫策略，與 React Native「一次學習，隨處編寫」的理念有著根本分別。
Flutter
- 單一 Dart 程式碼庫可編譯至 iOS、Android、桌面及網頁。
- Hot Reload 與 Hot Restart 將迭代循環縮短至數秒。
- 自繪 widget 樹確保各平台達到像素級一致。
React Native
- 「一次學習，隨處編寫」善用現有 React 技能，但進階功能仍需平台專屬模組。
- Fast Refresh 媲美 Flutter 的 Hot Reload，惟修改原生模組後仍需重新編譯。
- Expo 加 OTA 更新，令小型版本毋須經應用商店審核即可推出。
原生團隊享有第一方工具（Xcode、Android Studio）及新 SDK 的即時支援，但你需要雙倍工程人手，才能讓兩個平台保持同步。
決策矩陣：最終裁決
在督導委員會討論時，可用這個快速篩選工具，將業務驅動因素直接對應到技術選擇。
選擇原生開發，如果：
- 產品上線首日就需要 AR/VR、LiDAR 或硬件機器學習功能。
- 你的工作負載依賴重度運算或底層多線程處理。
- 受監管行業要求平台專屬認證。
選擇 Flutter，如果：
- 設計要求各平台體驗達到像素級一致。
- 你需要企業級效能，同時具備消費級產品的細緻打磨。
- 上市速度與一致的品牌呈現，比小眾原生 API 更重要。
選擇 React Native，如果：
- 你擁有精通 JavaScript/React 的資深網頁團隊。
- OTA 更新（CodePush、Expo）對每週迭代至關重要。
- 第三方插件生態與社群發展速度是首要考慮。
結論：有意識地作出選擇
世上沒有通用的贏家。原生開發帶來最大控制權，Flutter 帶來最高一致性，React Native 帶來最高熟悉度。請按組織能承受的風險及能留住的人才，選擇合適的框架。
成功的 CTO 會及早決定、記錄理據，並投資於工具以減輕缺點。舉棋不定時，先跑兩個 sprint 的技術驗證並進行生產級基準測試，再批出預算。
