Electron 不是你螢幕錄影工具的瓶頸

TL;DR —— Electron 確實有實際的記憶體成本，但它不必施加顯著的錄製或匯出懲罰。

在我們的 M4 Mac mini 上，本機 ScreenCaptureKit 錄影工具和同樣由 Electron 託管的本機錄影工具產生的 4K 影片影格率分別為 57.70 和 57.53 fps。一個 4K 編輯著色器在直接 Metal 中每影格 p95 花費 1.62 ms，而透過 Electron 的 WebGL-to-Metal 路徑花費 1.90 ms。受控的 1080p H.264 匯出在本機 VideoToolbox 下以 7.54 倍即時速度執行，透過 Electron 的 WebCodecs 路徑為 7.46 倍。

差距不是零。它只是沒有出現在傳統論點所放的位置。

Electron 明顯的損失是記憶體：直接本機錄製主機為 45 MB，而簽名的 Electron/Node 主機在新增 Chromium 渲染器之前為 94 MB。在此測試中，打包的 Tight Studio 會話穩定在大約 744–749 MB。這是一個值得誠實提及的權衡。這並不證明擷取的影格必須透過網頁傳輸，也不意味著匯出必須依賴軟體編碼。

我們用 Electron 建立 Tight Studio，因此我們對這個問題很感興趣。這就是為什麼我們讓基準測試可控且可重複，並且為什麼這篇文章包含了讓 Electron 看起來更差以及更好的結果。

「原生 vs Electron」 是錯誤的抽象層次。

桌面應用程式不是單一執行引擎。

Electron 提供了一個 Chromium 渲染器、一個 Node.js 主程式以及一個多程式應用程式框架。它也支援本機模組。Electron 自己的檔案明確指出，應用程式可以使用原生程式碼來存取平台 API 和進行效能關鍵的工作。

這意味著 Electron 螢幕錄影可以至少透過兩種非常不同的方式建立：

1. Cap 透過 JavaScript 和瀏覽器介面渲染、合成、複製和編碼影格。
2. 使用 Electron 來處理 UI 產品和編排，而 ScreenCaptureKit、AVFoundation、Metal、VideoToolbox 或其他本機媒體引擎則掌控核心路徑。

這些應用程式分享一個框架標籤。它們不分享效能架構。

Electron 已經為高需求的桌面應用提供動力

這種架構並不罕見。目前 macOS 版本的 Codex 和 Claude 都使用 Electron。在本文使用的機器上，Codex 26.825.41651 宣告 ElectronAsarIntegrity 用於其 app.asar 軟體包，而 Claude 1.26832.0 同時附帶 Electron Framework.framework 和 app.asar.

Electron 自身的檔案還列出了使用該框架建立的產品，包括 Visual Studio Code、Figma、Docker Desktop、Loom、Canva、Notion、1Password、Slack、Discord 和 Signal。這些產品涵蓋了程式碼編輯和除錯、協作圖形、容器管理、螢幕錄影、憑證管理、訊息傳遞、語音和影片，以及 AI 工作流程。

該列表不是效能基準，也不能證明每個 Electron 應用都是高效的。它展示了架構要點：為桌面應用選擇 Electron 並不要求殼層執行每一個昂貴的操作。本機模組、GPU 程式、本機服務以及遠端系統可以承擔專門的工作。

你可以在不使用特殊工具的情況下重現 macOS 捆綁檢查。在 Finder 中，選擇 顯示包內容, 然後檢查 Contents/Info.plist, Contents/Resources/app.asar，和 Contents/Frameworks/.

Tight Studio 使用第二種模型。在 macOS 上，螢幕影格由 Swift 模組使用 ScreenCaptureKit 擷取，並使用 AVAssetWriter 寫出。錄製不會繞過 DOM、React 或 Chromium 畫布。在編輯和匯出過程中，GPU 合成和硬體編解碼 API 執行耗費資源的工作；JavaScript 協調整個流程。

蘋果將 ScreenCaptureKit 描述為其高效能的 API，用於影格和音訊擷取。Electron 並不會阻止應用呼叫它。本機模組可以呼叫相同的框架，並接收相同的 CMSampleBuffer 物件，並將它們交給相同的系統編碼器。

我們的基準測試內容

我們避免比較兩個成品應用程式。一個應用可能渲染字幕、遊標運動、攝影機遮罩和五個疊加層，而另一個則重新封裝原始錄製。較快的結果幾乎無法告訴我們關於 Swift 或 Electron 的任何資訊。

相反，我們保持工作負載不變：

• 機器： Apple M4 Mac mini，10 核 CPU，10 核 GPU，16 GB 記憶體，macOS 26.5.2。
• 錄製： 完全相同的打包本機擷取引擎，一次從其直接的 Swift CLI 執行，一次從 Tight Studio 的簽名 Electron/Node 可執行檔案執行。兩者都錄製了相同的 3840×2160 動畫顯示，目標影格率為 60 fps。
• 編輯： 相同的程式化背景、圓角卡片、網格、陰影和動畫遊標著色器，解析度為 3840×2160。本機使用 Metal；Electron 透過 ANGLE 的 Metal 渲染器使用 WebGL 2。每一影格都有同步邊界，所以隱藏畫布無法使工作消失。
• 匯出： 1920×1080，30 影格/秒，H.264，12 Mbps 目標的 300 影格。Native 使用了 Metal 加 VideoToolbox。Electron 使用了 WebGL 加 WebCodecs，並請求了硬體加速。
• 執行： 每條路徑三個。表格報告中值。

未包含任何電池結果。這是一臺 Mac mini，可信的電池資料需要更長時間的、受控的 MacBook 測試。

結果

階段	直接原生	Electron/混合	Electron 差異
4K 錄製輸出速率	57.70 影格/秒	57.53 影格/秒	-0.29%
錄製主機 CPU	7.06%	6.98%	-0.09 分
錄製 OS-服務 CPU	31.34%	32.76%	+1.42 分
錄製主機峰值記憶體	45.36 MB	94.39 MB	+49.03 MB
4K 編輯著色器吞吐量	684.23 影格/秒	593.77 影格/秒	-13.22%
4K 編輯著色器 p95 影格時間	1.62 毫秒	1.90 毫秒	+0.28 毫秒
1080p 匯出吞吐量	226.10 影格/秒	223.78 影格/秒	-1.02%
1080p 匯出速度	即時 7.54 倍	即時 7.46 倍	-1.02%

這些是在一臺機器上進行的簡短、可控測試。它們確定了這些架構的可能性；但這並不保證每個 Electron 應用都會如此高效。

錄製：Electron 不需要接觸影格

錄製結果幾乎平分秋色，因為在關鍵部分兩個路徑相同。

ScreenCaptureKit 產生影格。AVAssetWriter 和系統編解碼器堆疊對其進行編碼。Electron 端請求本機錄影工具開始、停止、暫停和恢復。它不會透過 IPC 通道接收 4K 像素緩衝，也不會在 JavaScript 中對其進行編碼。

在三次執行中，本機中位數為 57.70 fps，而 Electron 主機為 57.53 fps——差異為 0.29%。中位數錄影工具 CPU 本機為 7.06%，Electron 主機為 6.98%。macOS 擷取服務平均分別為 31.34% 和 32.76%。

影格率結果是重要的。微小的 CPU 反轉屬於普通的執行間雜訊，而不是 Electon 以某種方式加速 ScreenCaptureKit 的證據。

有一個值得披露的測試小問題。macOS 授予已簽名的應用程式身份螢幕錄影權限。我們的開發版 Electron 二進位檔案沒有該權限，因此 Electron 錄製執行使用了 Tight Studio 的已簽名可執行檔案在 Electron 的 Node 相容模式下執行。這隔離了本機橋接，但省略了 Chromium 渲染器。我們單獨測量了打包的外殼，而不是悄悄地將 MB 主機呈現為完整的 Electron 應用。

編輯：翻譯後的 Metal 仍然是 Metal

JavaScript 並不直接暴露 Apple 的 Metal API。這個事實有時會被擴充功能成一個更廣泛的說法：Electron 無法使用基於 Metal 的 GPU 渲染。

在 macOS 上，ANGLE 為 OpenGL ES 提供了 Metal 後端，這也是 Chromium 在 WebGL 下可以使用的。我們的 Electron 基準測試將其渲染器識別為 ANGLE Metal Renderer: Apple M4.

直接使用 Metal 更快。中位數的原生執行渲染了每秒 684 影格；Electron 渲染了 594 影格，吞吐量差距為 13%。P95 影格時間從 1.62 增加到 1.90 毫秒。

這是可測量的開銷。在 60 fps 的每影格預算 16.67 毫秒中，它也是 0.28 毫秒。

真實的編輯者當然不只做一個著色器。他們解碼影片，上傳或匯入紋理，渲染文字，計算動畫狀態，並回應輸入。粗心的實現可能會因複製、分配、同步 IPC 或 React 工作而耗盡剩餘預算。但瀏覽器合成器並不自動就是軟體渲染器，而且 Mac 上的 WebGL 並不能證明 GPU 已被繞過。

當 WebGL 或 WebGPU 路徑不足時，Electron 仍然允許使用原生 Metal 模組。架構可以根據子系統選擇其逃生出口。

匯出：硬體編碼器不在乎是哪個按鈕啟動的

VideoToolbox 是蘋果的硬體編碼器和解碼器的底層介面。Chromium 擁有 macOS VideoToolbox 編碼器後端，而 WebCodecs 向應用程式公開硬體加速偏好設定。

在我們本機執行中，VideoToolbox 確認了硬體編碼。Electron 執行透過 WebCodecs 請求了硬體。WebCodecs 不提供所選擇的編碼器名稱，因此我們無法聲稱有 API 級別的 Electron 選擇證明。其效能和輸出與硬體路徑一致：本機編碼 300 影格的中位數時間為 1.327 秒；Electron 花費了 1.341 秒。輸出大小差異不到 1%。

這相當於 7.54 倍對 7.46 倍即時——差距為 1%。

這並不意味著每個 Electron 匯出器都很快。當應用程式出現以下情況時，匯出速度會變慢：

• 會從 GPU 的每一影格讀取像素；
• 透過 JavaScript 或 IPC 複製完整影格；
• 在軟體中編碼；
• 不必要地序列化了解碼、渲染、音訊和編碼階段；
• 將整個輸出儲存在記憶體中，而不是以流方式處理；
• 使用 UI 執行緒作為渲染工作執行緒。

這些是管線選擇，而不是 Electron 強加的要求。

一個真實的 Tight Studio 匯出

微基準測試顯示開銷出現的位置。產品測試告訴我們整個管道是否有用。

我們還執行了 Tight Studio 已有的五段剪輯匯出迴歸測試裝置三次。112 秒的時間軸涵蓋了每段剪輯的解碼、GPU 渲染、音訊處理、編碼、拼接和 1440×1080 的封裝。匯出時間分別為 81.54、80.94 和 81.28 秒。中位數為 81.28 秒，即 1.38 倍即時。

產生的檔案長度為 112.36 秒，約 30 影格每秒，包含 H.264 影片和 AAC 音訊。這個測試裝置並不是通用的匯出速度評分——源媒體和效果會影響結果——但它是一個端到端的 Electron 應用程式，在可重複的儲存庫測試中匯出的速度比播放更快。

Electron 真正會損失的部分：記憶體

Electron 嵌入了一個多程式的瀏覽器執行時。這會佔用記憶體。

直接的本機錄製主機峰值為 45 MB RSS。簽名的 Electron/Node 主機峰值為 94 MB。我們的最小 Electron 編輯程式樹大約為 360 MB，匯出程式樹大約為 394 MB。帶有新配置檔案的打包 Tight Studio 會話在此特定應用狀態下穩定在 744–749 MB 左右。

最後一個數字不是 Electron 的法則，也不是本機應用的比較。它只是提醒不要將最小化測試殼作為行銷偽裝。

記憶體對於受限裝置可能很重要。它可能產生壓力，增加交換分割槽使用，並間接增加能耗。但分配的 RAM 並不等同於記錄 CPU、丟影格、GPU 影格時間或編碼器吞吐量。將其中一個作為所有其他指標的代理會得出錯誤的工程結論。

實際目標不是「不要使用任何 Chromium 記憶體」。目標是讓瀏覽器執行時遠離原始影格熱路徑，及時關閉媒體物件，限制緩衝區，流式輸出，並保持空閒工作處於空閒狀態。

評估螢幕錄影工具的更好方法

詢問每個子系統實際的功能：

• 哪個 API 捕捉螢幕？
• 影格是在哪裡合成的？
• GPU 的後臺硬體是否有加速？
• 選擇了哪種編碼器實現？
• 會產生多少完整影格副本？
• 像素資料是否跨越了 IPC 或 JavaScript 邊界？
• 編輯器在目標解析度下可以保持 60 fps 嗎？
• 每秒輸出的匯出時間是多少？
• 在相同的工作負載下，CPU 的記憶體、丟影格、功耗和熱量結果如何？

「原生」和「Electron」是有用的實現細節。它們是薄弱的基準結果。

結論

完全原生的應用程式具有最低的外殼開銷，並且能夠最直接地存取平台 API。如果兩個團隊建立了同樣最佳化、功能相同的管道，原生仍然保持優勢——尤其是在記憶體和 GPU 控制的最後增量上。

但是，不需要 Electron 應用程式就可以使用 DOM 節點和 JavaScript 迴圈建立其媒體引擎。它可以透過 ScreenCaptureKit 進行擷取，在支援 Metal 的 GPU API 上進行合成，用硬體媒體引擎編碼，並將效能關鍵任務移到本機模組或工作執行緒中。

我們的測量發現錄製影格率差距為 0.29%，合成 4K 著色器吞吐差距為 13%，受控匯出差距為 1%。我們還發現了較大的記憶體差距。這就是折衷的真實形態。

框架設定預設值。管道設定效能。

來源和復現

• 蘋果：ScreenCaptureKit
• 蘋果：VideoToolbox
• electron：原生程式碼和 electron
• electron：程式模型
• Electron：為什麼選擇 Electron 以及生產應用範例
• ANGLE：Metal 後端支援
• Chromium：macOS VideoToolbox 編碼器
• W3C：WebCodecs 硬體加速

基準測試工具、原始執行表格、權限警告和解釋限制正在準備獨立公開發布。等軟體包可以獨立複製和執行時，我們將在這裡新增儲存庫連結。額外的 Apple 矽芯機器和受控的 MacBook 功率測試將擴充功能這些結果，但它們未包括在以上宣告中。