RexCode logo

為什麼 macOS 原生 App 比 Electron 更適合做檔案工具

macOS 原生 App(如 Tauri + Rust)比 Electron App 在啟動速度、記憶體佔用、電池效率、檔案 I/O 四個維度上有系統性優勢——這在處理大量檔案時的感受尤其明顯,因為這類工作本身就已經是 I/O 密集型操作。

本文不是在說 Electron 不好。它讓 VS Code、Slack、Figma 都能在三個平台上用同一份程式碼運作,這是了不起的成就。問題在於:檔案工具(folder compare、hex viewer、全文搜尋)有特定的效能訴求,Electron 的架構在這幾點上天生吃虧。


先看結論:Electron vs Native(Tauri + Rust)對照表

維度 Electron Tauri + Rust(如 Lode) 對檔案工具的影響
渲染引擎 捆綁完整 Chromium 系統 WebView(macOS=WKWebView) 原生共用 OS 已載入的引擎
後端語言 Node.js(V8) Rust(原生機器碼) Rust 對 CPU 密集的解析、比對快得多
冷啟動 2–5 秒 < 1 秒 即開即用,工具型 App 體驗關鍵
記憶體起點 150–300 MB ~100 MB(實測 idle ≈ 106 MB) 多工具並開時差距放大到 GB 級
安裝體積 80–150 MB+ 3–10 MB 下載快、佔硬碟少
電池(MacBook) 基準 +20–40% 耗電 接近系統原生 行動工作續航差異明顯
並行模型 單執行緒 event loop 真多執行緒 + async I/O 大目錄掃描時 UI 不卡
跨平台一致性 ✅ 三平台幾乎一致 ⚠️ 需各平台測試 WebView 差異 Electron 在此勝出
npm/外掛生態 ✅ 非常成熟 ⚠️ 成長中 Electron 在此勝出
原生 UI 元件 同樣靠 Web 渲染 同樣靠 Web 渲染(後端才是 Rust) 平手

下面逐項拆解每個維度背後的原因。


啟動速度

Electron 每次啟動都要載入一個完整的 Chromium 引擎(約 80–120 MB)和 Node.js runtime。即使 App 本身只有幾 MB,使用者等到可以操作通常要 2–5 秒。對「臨時想比個資料夾」「快速 hex 看一下檔頭」這種用完即關的工具,每次都等好幾秒是很傷體驗的——因為檔案工具的使用模式本來就是高頻、短時。

Tauri + Rust 的二進位檔只有幾 MB,使用系統 WebView(macOS 的 WKWebView)而不是捆綁 Chromium。WKWebView 的引擎在系統開機後就常駐記憶體、被 Safari 與其他 App 共用,App 啟動時不必再從零載入。Lode 冷啟動不到 1 秒,在 M1 Mac 上幾乎是即開即用。


記憶體佔用

典型 Electron App 的記憶體起點是 150–300 MB,這是 Chromium 的底線成本——它會為主行程、渲染行程、GPU 行程各開一份。

Lode 使用系統 WebView,idle 記憶體實測約 100 MB(M1 Max,主程序 + WebView,2026-06 量測)。在同時開著多個工具的開發環境中,這個差距會放大——每個 App 相對 Electron 省下 50–200 MB,8 個 App 累積起來就接近 1 GB。對檔案工具來說還有一個隱藏成本:比對大目錄時要在記憶體裡持有兩棵檔案樹,Electron 的 baseline 已經吃掉一大塊,留給實際工作的空間就更少。

Rex 的實際觀察:在 Mac Studio M1(32GB RAM)上,開著 Lode + Xcode + Docker + Chrome 沒什麼壓力;如果把 Lode 換成同功能的 Electron 版本,記憶體壓力明顯增加。32GB 夠多,但在 8GB / 16GB MacBook 上,記憶體就是真實的瓶頸——swap 一旦開始,整台機器的反應都會被拖慢。


電池效率

Chromium 的渲染引擎對 GPU 的使用方式並未針對 macOS 最佳化。Electron App 在 MacBook 上的耗電通常比同功能的原生 App 高出 20–40%(Mozilla 2020 的瀏覽器架構研究提供了引擎成本的類似量級,雖非針對 Electron)。原因包含背景輪詢、計時器喚醒、以及多行程架構讓 CPU 較難進入深層睡眠。

Tauri + Rust 後端使用 Rust 的非同步 runtime(Tokio),CPU 閒置時真的閒置,不做多餘的輪詢。WKWebView 是 macOS 原生優化的 WebView,GPU 路徑與 Safari 相同,能吃到 Apple 對自家瀏覽引擎的省電調校。對一整天帶著 MacBook 跑的工程師,這是續航上看得到的差別。


檔案 I/O:Rust 的本質優勢

這是最關鍵的一點。資料夾比對、全文搜尋、Hex 解析,這三種操作都是 I/O 密集 + CPU 密集的組合。

具體差異:Lode 用 ripgrep(Rust 寫的全文搜尋工具)當搜尋引擎,ripgrep 在各種 benchmark 中都顯著快於 JavaScript 實現的搜尋——它結合了有限狀態自動機的正則引擎、記憶體映射檔案、以及多核心平行走訪目錄。對「在十萬個檔案裡找一個字串」這種需求,引擎層級的差異會直接反映在等待時間上。


安裝體積與散佈

容易被忽略但對工具型 App 很實際:Electron App 因為內嵌整個 Chromium,安裝檔通常 80–150 MB 起跳,更新時往往要重新下載一大包。Tauri App 的安裝檔常在 3–10 MB 之間,下載快、佔硬碟少、自動更新的增量也小。對「想推薦給同事裝來用」的小工具,下載門檻低本身就是優勢。

安全面也值得一提:Electron 內嵌的 Chromium 版本必須由 App 開發者自己跟進安全更新,一旦落後就把已知漏洞帶進使用者機器;Tauri 走系統 WebView,安全性更新跟著 macOS 系統更新走,攻擊面相對小。


那 Tauri 的限制是什麼?

公平評比也要說缺點:


何時該選 Electron

不要因為這篇就一律排斥 Electron。如果你的 App 核心不是 I/O 密集、團隊只有前端背景、而且跨平台像素級一致比啟動速度更重要——例如即時通訊、文件協作、設計工具——Electron 仍然是非常理性的選擇,開發速度的優勢往往蓋過效能上的代價。Slack、Notion、Figma 走 Electron/Web 路線都站得住腳。

關鍵在於 App 的瓶頸在哪。當瓶頸是網路與協作,Electron 的弱項(記憶體、啟動)不痛;當瓶頸是本機檔案的讀取與運算,原生路線的優勢就會被使用者天天感受到。


結論

如果你在開發一個 檔案工具——比對、搜尋、hex 檢視、diff——Rust + Tauri 的組合在效能和資源效率上有明確優勢,而且代價(跨平台一致性的額外測試)對 macOS-first 工具來說幾乎可以忽略。

Electron 的優勢在於開發速度和跨平台一致性,對於工具本身不是 I/O 密集型的 App(Slack、Notion 等)完全合理。選型沒有絕對答案,只有「你的 App 瓶頸在哪」這個問題的答案。

🔨
本文介紹的工具:Lode

原生 macOS 工作台,整合 Folder Diff、File Diff、Binary Diff、全文搜尋,一個 App 搞定。