2025年跨平台開發框架大戰開打！React Native和Flutter誰更勝一籌？
# 分析：2025年初探討 React Native 與 Flutter 的比較
一堆人吵來吵去，總覺得關於跨平台移動開發框架的選擇，很難真正有個定論。其實到現在，很多決策者和工程師還是在兩個陣營之間猶豫不決——React Native 或 Flutter？下文主要是試著把這兩種方案攤開來聊聊，大約會從它們的底層結構、執行效能、日常好用程度、整體資源圈子，還有開發速度之類的層面切入。當然啦，如果有人在找 KMP、Phonegap、ionic 或直接寫原生的經驗分享，這段就暫時略過。
照片那邊先跳過。回到主題。
**React Native**
要說 React Native，其實後面推手是 Meta（以前叫 Facebook），但名字變了，大概也沒幾個人真的注意細節啦。有趣的是，它讓你可以直接用 JavaScript 和 React 這些東西來做手機 app。不像傳統那種完全 native 開發，一份程式碼大致就能同時跑在蘋果和安卓上。雖然這種「一次搞定」的想法，不是只有 React Native 才有——Flutter 好像也是差不多思路。
如果問工程圈裡誰用的人最多，也許 React Native 算挺熱門那掛。有不少網路社群在討論，各種第三方函式庫感覺加起來應該也有七十多包吧？（其實可能比這多）對於那些已經有現成原生 app 的團隊，好像也看到有人慢慢把部分功能混進 React Native，一點一滴地嘗試導入，而不用一次砍掉重練。這種循序漸進的方式，有些公司蠻喜歡；但也不是每個場合都適合就是了。
Meta 支持底下，React Native 發展算久了，所以大大小小工具、生態系都已經成型，大家遇到問題往往很快能找到資料或範例解法。但偶爾還是會碰到老問題——新舊版本兼容、有些函式庫突然沒維護等等情形。不過整體而言，只要不是追求極致性能或特殊 UI 動畫需求，大部份開發者好像用起來都說可接受啦。
畢竟現在技術更新很快，據說將近一半剛入行的新手，也會優先考慮從像 React Native 這樣門檻較低的平台開始學起。有時候大家選擇，除了技術本身，多半還受限於團隊技能組成、市場人才供給狀況，那些層面其實也是某種不得不考慮的小細節……
一堆人吵來吵去，總覺得關於跨平台移動開發框架的選擇，很難真正有個定論。其實到現在，很多決策者和工程師還是在兩個陣營之間猶豫不決——React Native 或 Flutter？下文主要是試著把這兩種方案攤開來聊聊，大約會從它們的底層結構、執行效能、日常好用程度、整體資源圈子，還有開發速度之類的層面切入。當然啦，如果有人在找 KMP、Phonegap、ionic 或直接寫原生的經驗分享，這段就暫時略過。
照片那邊先跳過。回到主題。
**React Native**
要說 React Native，其實後面推手是 Meta（以前叫 Facebook），但名字變了，大概也沒幾個人真的注意細節啦。有趣的是，它讓你可以直接用 JavaScript 和 React 這些東西來做手機 app。不像傳統那種完全 native 開發，一份程式碼大致就能同時跑在蘋果和安卓上。雖然這種「一次搞定」的想法，不是只有 React Native 才有——Flutter 好像也是差不多思路。
如果問工程圈裡誰用的人最多，也許 React Native 算挺熱門那掛。有不少網路社群在討論，各種第三方函式庫感覺加起來應該也有七十多包吧？（其實可能比這多）對於那些已經有現成原生 app 的團隊，好像也看到有人慢慢把部分功能混進 React Native，一點一滴地嘗試導入，而不用一次砍掉重練。這種循序漸進的方式，有些公司蠻喜歡；但也不是每個場合都適合就是了。
Meta 支持底下，React Native 發展算久了，所以大大小小工具、生態系都已經成型，大家遇到問題往往很快能找到資料或範例解法。但偶爾還是會碰到老問題——新舊版本兼容、有些函式庫突然沒維護等等情形。不過整體而言，只要不是追求極致性能或特殊 UI 動畫需求，大部份開發者好像用起來都說可接受啦。
畢竟現在技術更新很快，據說將近一半剛入行的新手，也會優先考慮從像 React Native 這樣門檻較低的平台開始學起。有時候大家選擇，除了技術本身，多半還受限於團隊技能組成、市場人才供給狀況，那些層面其實也是某種不得不考慮的小細節……
原文出處: https://www.kantti.net/tw/column/2252/analysis-react-flutter-competition
React Native的五大優勢讓你不得不愛，但為什麼開發者又愛又恨？
有些企業好像偏好用 React，主要是他們本來網站就都跑這個技術。可是實際上，如果 App 裡頭要處理那些很吃效能的動畫，或是算得特別複雜的東西，用 JavaScript 跟原生模組溝通時會多一道橋接層，傳資料速度可能沒那麼快。大致上，只要不是做那種花俏又密集切換畫面的應用，平常倒也還行，不過偶爾還是有人反映在特殊情境下明顯感受到慢一點。
找開發人員這件事嘛，畢竟 JavaScript 到現在已經變成一種到處都在用的語言，要找到懂這套的人據說不難，也讓不少公司覺得省了時間和預算。只是，有時候如果真的想把畫面細節調到和原生完全一樣，好像還免不了要動手寫點 Android 或 iOS 的原生程式碼。而且不同手機系統，在某些元件表現上會有小地方不太一樣，有人說看久了才分辨得出。
說到支援和社群，其實參與的人數已經累積蠻多了，不過跟那些專門針對單一系統開發或是 Google 出的 Flutter 比起來，資源豐富度總覺得還有進步空間。有關未來走向，目前 Meta 還是在維護，但速度似乎比 Flutter 慢一些——當然，也可能哪天會加快吧。
對於效能問題再提一下，如果 App 內容單純，大部分時候體驗不差，可是一旦牽涉大量動畫或者資料運算，就容易遇到瓶頸，所以有些團隊乾脆直接考慮其他方案。
Flutter 這邊，是 Google 推出的公開原始碼 UI 工具包，他主打就是從同一份程式一次搞定 iOS 和 Android，大致減少重複開發帶來的不便跟耗時。
找開發人員這件事嘛，畢竟 JavaScript 到現在已經變成一種到處都在用的語言，要找到懂這套的人據說不難，也讓不少公司覺得省了時間和預算。只是，有時候如果真的想把畫面細節調到和原生完全一樣，好像還免不了要動手寫點 Android 或 iOS 的原生程式碼。而且不同手機系統，在某些元件表現上會有小地方不太一樣，有人說看久了才分辨得出。
說到支援和社群，其實參與的人數已經累積蠻多了，不過跟那些專門針對單一系統開發或是 Google 出的 Flutter 比起來，資源豐富度總覺得還有進步空間。有關未來走向，目前 Meta 還是在維護，但速度似乎比 Flutter 慢一些——當然，也可能哪天會加快吧。
對於效能問題再提一下，如果 App 內容單純，大部分時候體驗不差，可是一旦牽涉大量動畫或者資料運算，就容易遇到瓶頸，所以有些團隊乾脆直接考慮其他方案。
Flutter 這邊，是 Google 推出的公開原始碼 UI 工具包，他主打就是從同一份程式一次搞定 iOS 和 Android，大致減少重複開發帶來的不便跟耗時。
JavaScript橋接器是React Native的致命傷？效能瓶頸全解析
有時候說到 Flutter，大家大概會先想到它那種接近原生的效能。畢竟這個框架不是繞過什麼橋樑，而是直接把程式編譯成裝置能跑的格式，所以速度上常有人覺得跟原生差不多——雖然實際體感，可能還是要看你怎麼寫和跑在哪裡。有些人注意到 Flutter 裡頭那些元件（Widget）很豐富，想怎麼調整都可以，畫面呈現起來風格也容易統一。不像某些其他做法還得依賴平台自己的 UI 元素，它直接透過 Skia 這個圖形引擎自己畫出界面——好像這樣一來動畫就流暢了不少，尤其如果你的 APP 滿重視動畫或大量圖片顯示之類。
有篇文章在 Medium 上討論過這事，其實也不是所有人都全然認為沒問題。Flutter 雖然不靠 JavaScript 橋樑（比如 React Native 就會卡在那），但久了還是會冒出一些別種型態的小瓶頸。最常被提起的大概就是 Widget 重建，有時候頁面複雜、列表又長又多變化，只要哪個地方不小心讓 Widget 被頻繁重建，就容易發現效能慢下來。當然官方強調他們框架設計得滿聰明，大致上只重建那些真的改變的部分，可是如果開發者沒有特別注意細節，也不是沒機會遇到卡頓。
話說回來，不同情境下 Flutter 的表現浮動算大嗎？有的人測試結果比較接近原生 App，也有人碰上狀況搞得不是很順手。就像市面上一堆東西，看似規格齊全、功能多，但實際體驗總有點落差——大概也只能說遇到效能議題時，有時候是因為用法上的小細節影響比較大吧。
有篇文章在 Medium 上討論過這事，其實也不是所有人都全然認為沒問題。Flutter 雖然不靠 JavaScript 橋樑（比如 React Native 就會卡在那），但久了還是會冒出一些別種型態的小瓶頸。最常被提起的大概就是 Widget 重建，有時候頁面複雜、列表又長又多變化，只要哪個地方不小心讓 Widget 被頻繁重建，就容易發現效能慢下來。當然官方強調他們框架設計得滿聰明，大致上只重建那些真的改變的部分，可是如果開發者沒有特別注意細節，也不是沒機會遇到卡頓。
話說回來，不同情境下 Flutter 的表現浮動算大嗎？有的人測試結果比較接近原生 App，也有人碰上狀況搞得不是很順手。就像市面上一堆東西，看似規格齊全、功能多，但實際體驗總有點落差——大概也只能說遇到效能議題時，有時候是因為用法上的小細節影響比較大吧。
Flutter憑什麼敢說自己接近原生效能？Skia引擎背後的黑科技
有時候，一個小元件其實沒變，卻還是會一直重繪，這樣一來處理效能就可能被白白浪費掉。這種情況，有些人說大概跟依賴關係太雜、或者上層元件一變動，下層就全跟著動作，多少有點關聯。也聽過有人說那種樹狀結構特別深的畫面，稍微哪裡改一下，好像下面好幾層都要重新整理一次。然後狀態管理如果沒顧好，也常常會讓那些本來不用管事的小部件莫名跑去重建。
其實解決方法也不是什麼新鮮事，大致離不開檢查每個小零件到底該不該對父級變化敏感，再把那棵樹修修剪剪，不然就是用比較精確的狀態管理工具去控管。做得好的話，用戶操作起來通常滑順多了——但當然，也不是說一定全部都能靠這些搞定，只是有不少人在類似場景下覺得蠻有效果的。
說到開發效率，有些團隊認為Flutter因為支援即時熱重載，加上一堆現成組件，所以開起案子來速度挺快，減少反覆等候的時間，好像成本也壓低一些。有的人提過它內建的視覺元件種類算多，可以拿來拼湊出滿客製化又一致性的介面設計，但是不是每次都適合用、效果如何，其實還是要看專案需求或設計師怎麼調整才比較準。
至於體驗方面，不少人注意到Flutter那套預設外觀可以維持各平台間的某種統一，不過想走自己風格也不算難——自訂程度大致夠用，就是偶爾得花點心思細修。不過這些看法，有的是業界傳聞、有的是部分案例分享，具體情境可能還得斟酌。
其實解決方法也不是什麼新鮮事，大致離不開檢查每個小零件到底該不該對父級變化敏感，再把那棵樹修修剪剪，不然就是用比較精確的狀態管理工具去控管。做得好的話，用戶操作起來通常滑順多了——但當然，也不是說一定全部都能靠這些搞定，只是有不少人在類似場景下覺得蠻有效果的。
說到開發效率，有些團隊認為Flutter因為支援即時熱重載，加上一堆現成組件，所以開起案子來速度挺快，減少反覆等候的時間，好像成本也壓低一些。有的人提過它內建的視覺元件種類算多，可以拿來拼湊出滿客製化又一致性的介面設計，但是不是每次都適合用、效果如何，其實還是要看專案需求或設計師怎麼調整才比較準。
至於體驗方面，不少人注意到Flutter那套預設外觀可以維持各平台間的某種統一，不過想走自己風格也不算難——自訂程度大致夠用，就是偶爾得花點心思細修。不過這些看法，有的是業界傳聞、有的是部分案例分享，具體情境可能還得斟酌。
小心踩雷！Flutter開發者最常忽略的Widget重建效能陷阱
Flutter 這個框架，最近社群人數明顯增多，說是一下子就冒出不少討論串也不誇張。各種外掛、工具包，大致上每天都能看到新東西被提出來，雖然還沒像原生開發那些平台那麼齊全，不過工程師們其實挺努力在補齊差距。有時候找第三方函式庫會覺得好像還差點什麼，但這個情況慢慢有改善的跡象。
Google 持續推動 Flutter 的研發，好像讓大家覺得它未來有些保障。畢竟，有大公司支持的技術，通常不太容易突然消失。至於生態圈成熟度——嗯，目前算是在逐步追趕吧，有時候遇到功能需求還是得自己動手寫，不過看起來情勢朝著更完善前進。
說到 Flutter 怎麼跟原生模組溝通，其實背後運作方式有一點巧妙。它主要靠一種叫做 Platform Channels 的橋接機制，把 Dart 程式和原生程式（不管是 Android 還是 iOS）串聯起來。有些人會形容這種模式像是在兩邊間搭座橋，資料就這樣傳過去再回來。不過偶爾也有人反應說，如果遇到複雜互動需求，可能要額外花時間調整。不過，大部分日常開發裡，大致夠用。
Google 持續推動 Flutter 的研發，好像讓大家覺得它未來有些保障。畢竟，有大公司支持的技術，通常不太容易突然消失。至於生態圈成熟度——嗯，目前算是在逐步追趕吧，有時候遇到功能需求還是得自己動手寫，不過看起來情勢朝著更完善前進。
說到 Flutter 怎麼跟原生模組溝通，其實背後運作方式有一點巧妙。它主要靠一種叫做 Platform Channels 的橋接機制，把 Dart 程式和原生程式（不管是 Android 還是 iOS）串聯起來。有些人會形容這種模式像是在兩邊間搭座橋，資料就這樣傳過去再回來。不過偶爾也有人反應說，如果遇到複雜互動需求，可能要額外花時間調整。不過，大部分日常開發裡，大致夠用。
Platform Channels如何讓Flutter與原生模組無縫溝通？
Flutter如果要跟原生那邊互動，大家有時候會聽說「Platform Channels」這個詞，意思大概就是它們之間傳訊息的方式，有人覺得像是搭了一座橋。實際上怎麼做呢？方法倒是不只一種，不過常見的是MethodChannel，好像蠻多人用這個來溝通——你可以把它想成在兩端都取了一個名字，然後雙方都知道這條線路。
Dart這邊（也就是Flutter寫的地方）會註冊一個處理器，看起來就像負責收發訊息。而Android（不論Java還Kotlin）或iOS（Swift、Objective-C也行）那邊，也會認同同樣那組名稱，所以對得上。然後等到Flutter想叫原生去做點事，或者拿些資料，就透過這種管道發消息出去——內容裡面大致包含「你要幫我執行哪個方法」還有一些參數之類的。
當然啦，有時候細節可能因專案需求微調，也不是每一次都完全相同。有的人覺得好像挺靈活，不少場景下都看得到有人在用。至於雙向溝通，如果仔細研究一下，會發現其實不算太困難，只是初學者剛接觸時可能有點混亂。不小心說遠了，大致上就是靠類似這樣的設計，讓Flutter和手機本身那些功能能夠彼此對話。
Dart這邊（也就是Flutter寫的地方）會註冊一個處理器，看起來就像負責收發訊息。而Android（不論Java還Kotlin）或iOS（Swift、Objective-C也行）那邊，也會認同同樣那組名稱，所以對得上。然後等到Flutter想叫原生去做點事，或者拿些資料，就透過這種管道發消息出去——內容裡面大致包含「你要幫我執行哪個方法」還有一些參數之類的。
當然啦，有時候細節可能因專案需求微調，也不是每一次都完全相同。有的人覺得好像挺靈活，不少場景下都看得到有人在用。至於雙向溝通，如果仔細研究一下，會發現其實不算太困難，只是初學者剛接觸時可能有點混亂。不小心說遠了，大致上就是靠類似這樣的設計，讓Flutter和手機本身那些功能能夠彼此對話。
拆解React Native的JavaScript橋接器運作原理
在某些情境下，Flutter跟原生端之間的訊息來來回回，好像有點像書信往返。比方說，Flutter發出一個請求，原生端收到後稍微處理一下，再透過同一條線路把結果傳回去。有時候Flutter那邊就會接到這個回應，看狀況再決定怎麼處理。
其實這整套平台通道的做法，不單只是單向傳遞。大致上，它允許訊息雙向流動，有時候Flutter主動聯絡原生，也可能反過來。開發者似乎可以利用這種方式連結上不少裝置功能，包括那些比較偏底層的感測器、系統設定，甚至外部套件，只要寫得夠細心，好像沒什麼明顯障礙。不過型別安全部分聽說還是要靠自己多留意，如果有用pigeon之類的工具輔助，大致能減少出錯機率。
說穿了，用這種通道，其實就是讓跨平台開發的人多了點彈性。雖然語言不盡相同，但整合起來仍然有機會讓App變得更豐富或順暢。有些人覺得這樣混搭兩邊的好處挺明顯，可是不排除偶爾會遇到小問題。至於具體落地效果如何，大概還是要看需求和開發經驗吧。
其實這整套平台通道的做法，不單只是單向傳遞。大致上，它允許訊息雙向流動，有時候Flutter主動聯絡原生，也可能反過來。開發者似乎可以利用這種方式連結上不少裝置功能，包括那些比較偏底層的感測器、系統設定，甚至外部套件，只要寫得夠細心，好像沒什麼明顯障礙。不過型別安全部分聽說還是要靠自己多留意，如果有用pigeon之類的工具輔助，大致能減少出錯機率。
說穿了，用這種通道，其實就是讓跨平台開發的人多了點彈性。雖然語言不盡相同，但整合起來仍然有機會讓App變得更豐富或順暢。有些人覺得這樣混搭兩邊的好處挺明顯，可是不排除偶爾會遇到小問題。至於具體落地效果如何，大概還是要看需求和開發經驗吧。
UI一致性之爭：用原生元件還是自建Widget庫更吃香？
React Native 裡頭，有個叫 JavaScript 橋樑的東西，經常被拿來當作溝通 JS 跟原生模組的中間人。說起來有點像兩邊講不同語言，非得靠這個橋樑幫忙翻譯一下。某些時候，比如說你想要用手機裡內建的什麼感應器、發送網路請求或者插入一塊原生介面，差不多都會透過 JS 先呼叫一段函式，那東西最後其實會包成訊息傳過去給原生那端。有的人形容那流程大概就像資料被打包、送出去，再由對方拆開後處理。
至於原生模組要回傳資訊，也不是沒可能。有時候它們也會找機會丟點事件或數據給 JS 這邊，只是細節上偶爾讓人搞不太清楚到底是哪裡先動手。不過整體看起來，大致就是彼此互相「喊話」然後交換需要的內容。
實際順序誰先誰後，其實不一定每次都照本宣科。反正只要最終能讓 React Native 元件跟底層系統搭上線，大致上流程就八九不離十了。好像有聽說過有人覺得這樣設計有點複雜，不過換個角度，有這層橋樑至少還算靈活。如果真的哪天遇到卡住，多半也是在序列化或解碼步驟繞了些彎路吧？
至於原生模組要回傳資訊，也不是沒可能。有時候它們也會找機會丟點事件或數據給 JS 這邊，只是細節上偶爾讓人搞不太清楚到底是哪裡先動手。不過整體看起來，大致就是彼此互相「喊話」然後交換需要的內容。
實際順序誰先誰後，其實不一定每次都照本宣科。反正只要最終能讓 React Native 元件跟底層系統搭上線，大致上流程就八九不離十了。好像有聽說過有人覺得這樣設計有點複雜，不過換個角度，有這層橋樑至少還算靈活。如果真的哪天遇到卡住，多半也是在序列化或解碼步驟繞了些彎路吧？
Google vs Meta：從後台看兩大框架的未來發展潛力
好像在 React Native 裡頭，資料和事件會被整理成一種適合傳送的格式，然後從原生那邊丟到 JavaScript 端。這過程有點像是把東西打包寄快遞，到了對面再拆封還原。通常 JavaScript 收到後就會處理這些內容，好像又要再轉換一下格式，最後才會讓畫面上的元件狀態跟著更新。
其實這個所謂「橋接」的東西，大多時候不是馬上回應的——它大致上是分開進行，以免哪邊卡住影響整體運作。有的人可能經歷過，就是頻繁互動或者複雜操作時，好像流暢度會下降一些，據說主要就是橋樑傳輸有些負擔吧。
說起來，把 JavaScript 跟原生系統連在一起，其實靠的就是這條通道。有了它，好像不少人覺得可以用 JavaScript 寫出貼近原生體驗的 App，不過畢竟每次都得將資料轉來轉去、處理來回，有時候效能表現也不盡相同。有人提過，如果是資料量很大的情境或需要即時反應，那麼橋接機制可能不是最佳選擇，但小規模需求下倒也還算順手。
總之，用這方式開發，看似彈性滿高，只是細節中偶爾藏著幾個眉角，也許要視專案情況斟酌調整。
其實這個所謂「橋接」的東西，大多時候不是馬上回應的——它大致上是分開進行，以免哪邊卡住影響整體運作。有的人可能經歷過，就是頻繁互動或者複雜操作時，好像流暢度會下降一些，據說主要就是橋樑傳輸有些負擔吧。
說起來，把 JavaScript 跟原生系統連在一起，其實靠的就是這條通道。有了它，好像不少人覺得可以用 JavaScript 寫出貼近原生體驗的 App，不過畢竟每次都得將資料轉來轉去、處理來回，有時候效能表現也不盡相同。有人提過，如果是資料量很大的情境或需要即時反應，那麼橋接機制可能不是最佳選擇，但小規模需求下倒也還算順手。
總之，用這方式開發，看似彈性滿高，只是細節中偶爾藏著幾個眉角，也許要視專案情況斟酌調整。
2025年專案選型終極建議：什麼情況下你該放棄React Native選擇Flutter？
結論這東西，怎麼說呢？Flutter跟React Native各有擅長的地方。有人發現，如果要做跨平台開發，像是二〇二五年左右，Flutter好像會比較適合——尤其那種介面講究精緻、又要速度表現不錯的應用程式。有時候大家也在意預算，想壓低一點，不過品質又不能太糟，那麼Flutter這套工具感覺還滿能幫忙。而且它可以跑在手機、網頁，甚至可能未來還有其他裝置，彈性算大。
但換個角度，有些團隊本來就已經對JavaScript或React有點熟悉了，而且如果專案內容沒那麼複雜，其實選React Native也不是不行。畢竟每個團隊情況都不同嘛。
嗯……這樣聊下來，好像也沒有哪一方一定優於另一方，只是依照需求和條件去做選擇而已。大概差不多就是這樣。如果你看到這裡還有興趣，也許可以再追蹤一下，有新東西再一起討論吧。
但換個角度，有些團隊本來就已經對JavaScript或React有點熟悉了，而且如果專案內容沒那麼複雜，其實選React Native也不是不行。畢竟每個團隊情況都不同嘛。
嗯……這樣聊下來，好像也沒有哪一方一定優於另一方，只是依照需求和條件去做選擇而已。大概差不多就是這樣。如果你看到這裡還有興趣，也許可以再追蹤一下，有新東西再一起討論吧。
