TL;DR — Electron hat einen echten Speicherbedarf. Es muss keine nennenswerte Aufnahme- oder Exportstrafe auferlegen.
Auf unserem M4 Mac Mini erzeugten ein nativer ScreenCaptureKit-Rekorder und derselbe native Rekorder, der von Electron gehostet wird, 4K Video mit 57,70 und 57,53 fps. Ein 4K Bearbeitungsshader benötigte 1,62 ms pro Bild bei p95 in direktem Metal und 1,90 ms über den WebGL-zu-Metal-Pfad von Electron. Ein kontrollierter 1080p H.264 Export lief mit 7,54x Echtzeit über native VideoToolbox und 7,46x über den WebCodecs-Pfad von Electron.
Die Lücke war nicht null. Sie war nur nicht dort, wo das konventionelle Argument sie verortet.
Der klare Nachteil von Electron war der Speicher: 45 MB für den direkten nativen Aufnahme-Host gegenüber 94 MB für den signierten Electron/Node-Host, bevor ein Chromium-Renderer hinzugefügt wurde. Eine verpackte Tight Studio Sitzung stabilisierte sich in diesem Test bei etwa 744–749 MB. Das ist ein Kompromiss, den man ehrlich benennen sollte. Es ist kein Beweis dafür, dass aufgenommene Frames über eine Webseite laufen müssen oder dass der Export auf Softwarekodierung zurückfallen muss.
Wir bauen Tight Studio mit Electron, daher haben wir ein Interesse an dieser Frage. Deshalb haben wir das Benchmark kontrolliert und wiederholbar gemacht, und deshalb enthält dieser Beitrag die Ergebnisse, die Electron schlechter dastehen lassen, sowie die, die es gut dastehen lassen.
„Native vs Electron“ ist die falsche Abstraktionsebene.
Eine Desktop-App ist keine einzelne Ausführungs-Engine.
Electron liefert einen Chromium-Renderer, einen Node.js-Hauptprozess und eine Multiprozess-Anwendungsschale. Es unterstützt auch native Module. Die eigene Dokumentation von Electron macht deutlich, dass eine App nativen Code für Plattform-APIs und leistungsrelevante Aufgaben verwenden kann.
Das bedeutet, dass ein Electron-Bildschirmrekorder auf mindestens zwei sehr unterschiedliche Arten gebaut werden kann:
- Rahmen durch JavaScript und Browser-Oberflächen aufnehmen, zusammensetzen, kopieren und kodieren.
- Verwenden Sie Electron für das Produkt UI und die Orchestrierung, während ScreenCaptureKit, AVFoundation, Metal, VideoToolbox oder eine andere native Medien-Engine den Hot Path übernimmt.
Diese Apps teilen ein Framework-Label. Sie teilen keine Performance-Architektur.
Electron treibt bereits anspruchsvolle Desktop-Apps an
Diese Architektur ist nicht ungewöhnlich. Die aktuellen macOS-Distributionen von Codex und Claude verwenden Electron. Auf der für diesen Artikel verwendeten Maschine deklariert Codex 26.825.41651 ElectronAsarIntegrity für sein app.asar Paket, während Claude 1.26832.0 beide ausliefert Electron Framework.framework Und app.asar.
Die eigene Dokumentation von Electron nennt ebenfalls Visual Studio Code, Figma, Docker Desktop, Loom, Canva, Notion, 1Password, Slack, Discord und Signal unter den Produkten, die mit dem Framework erstellt wurden. Sie decken Codebearbeitung und Debugging, kollaborative Grafik, Containerverwaltung, Bildschirmaufnahme, Kennwortverwaltung, Messaging, Sprach- und Videoanrufe sowie AI-Workflows ab.
Diese Liste ist kein Leistungsbenchmark und beweist nicht, dass jede Electron-App effizient ist. Sie zeigt den architektonischen Punkt: Die Wahl von Electron für eine Desktop-Shell erfordert nicht, dass die Shell jede teure Operation ausführt. Native Module, GPU Prozesse, lokale Dienste und entfernte Systeme können die spezialisierte Arbeit übernehmen.
Sie können die macOS-Bundle-Überprüfung ohne spezielle Werkzeuge reproduzieren. Wählen Sie im Finder Paketinhalte anzeigen, dann überprüfe Contents/Info.plist, Contents/Resources/app.asar, Und Contents/Frameworks/.
Tight Studio verwendet das zweite Modell. Bei macOS werden Bildschirmbilder von einem Swift-Modul mithilfe von ScreenCaptureKit erfasst und mit AVAssetWriter geschrieben. Die Aufnahme läuft nicht über DOM, React oder eine Chromium-Arbeitsfläche. Während der Bearbeitung und des Exports erledigen GPU Compositing- und Hardware-Codec-APIs die aufwendige Arbeit; JavaScript koordiniert die Pipeline.
Apple beschreibt ScreenCaptureKit als sein Hochleistungs-API für Frame- und Audioaufnahme. Electron verhindert nicht, dass eine App es aufruft. Ein natives Modul kann dasselbe Framework aufrufen, die gleichen Ergebnisse erhalten CMSampleBuffer Objekte, und übergeben Sie sie an denselben System-Encoder.
Was wir benchmarkt haben
Wir haben vermieden, zwei fertige Produkte zu vergleichen. Eine App könnte Untertitel, Cursorbewegungen, einen Kameraausschnitt und fünf Overlays rendern, während eine andere die Originalaufnahme nur erneut multiplexiert. Das schnellere Ergebnis würde uns fast nichts über Swift oder Electron sagen.
Stattdessen hielten wir die Arbeitslast konstant:
- Maschine: Apple M4 Mac mini, 10-Kern-CPU, 10-Kern-GPU, 16 GB Speicher, macOS 26.5.2.
- Aufnahme: die exakt gleiche verpackte native Capture-Engine, die einmal von ihrem direkten Swift CLI und einmal von der signierten ausführbaren Electron/Node-Datei von Tight Studio ausgeführt wird. Beide zeichneten die gleiche animierte 3840×2160-Anzeige mit einem 60-fps-Ziel auf.
- Bearbeitung: denselben prozeduralen Hintergrund, abgerundete Karte, Raster, Schatten und animierten Cursor-Shader bei 3840×2160. Native verwendete Metal; Electron nutzte WebGL 2 über ANGLE’s Metal-Renderer. Jeder Frame hatte eine Synchronisationsgrenze, sodass eine versteckte Arbeitsfläche die Arbeit nicht verschwinden lassen konnte.
- Exportieren: 300 Frames bei 1920×1080, 30 fps, H.264, und einem Ziel von 12 Mbps. Nativ wurde Metal plus VideoToolbox verwendet. Electron nutzte WebGL plus WebCodecs mit angeforderter Hardwarebeschleunigung.
- Durchläufe: drei pro Pfad. Die Tabelle gibt Mediane an.
Kein Batterie-Ergebnis enthalten. Dies war ein Mac-Mini, und eine glaubwürdige Batteriebestätigung benötigt einen längeren, kontrollierten MacBook-Test.
Ergebnisse
| Phase | Direkt nativ | Electron/hybrid | Electron-Unterschied |
|---|---|---|---|
| 4K Aufnahme-Ausgaberate | 57,70 fps | 57,53 fps | -0.29% |
| Aufnahmehost CPU | 7.06% | 6.98% | -0,09 Punkte |
| Aufnahme OS-Service CPU | 31.34% | 32.76% | +1,42 Punkte |
| Maximaler Speicher des Aufnahmehosts | 45.36 MB | 94.39 MB | +49.03 MB |
| 4K Shader-Durchsatz bearbeiten | 684,23 fps | 593,77 fps | -13.22% |
| 4K Shader-Bearbeitungszeit p95 Frame | 1,62 ms | 1,90 ms | +0,28 ms |
| 1080p Exportdurchsatz | 226,10 fps | 223,78 fps | -1.02% |
| 1080p Exportgeschwindigkeit | 7,54x Echtzeit | 7,46x Echtzeit | -1.02% |
Dies sind kurze, kontrollierte Tests auf einer Maschine. Sie zeigen, was mit diesen Architekturen möglich ist; sie sind kein Versprechen, dass jede Electron-App so effizient sein wird.
Aufnahme: Electron muss keinen Frame berühren
Das Aufnahmeergebnis ist fast unentschieden, weil beide Wege dort gleich sind, wo es zählt.
ScreenCaptureKit erzeugt die Frames. AVAssetWriter und der System-Codec-Stack kodieren sie. Die Electron-Seite fordert den nativen Rekorder auf, zu starten, zu stoppen, anzuhalten und fortzufahren. Es empfängt keine 4K Pixelpuffer über einen IPC-Kanal und kodiert sie nicht in JavaScript.
Über die drei Durchläufe hinweg lieferte die native Version eine mittlere Bildrate von 57,70 fps und der Electron-Host 57,53 fps – ein Unterschied von 0,29 %. Die mittlere Rekorder-CPU betrug 7,06 % für die native Version und 6,98 % für den Electron-Host. Die macOS-Aufnahmeservices lagen im Durchschnitt bei 31,34 % bzw. 32,76 %.
Das Ergebnis der Bildrate ist das Wichtige. Die winzige CPU-Umkehrung ist gewöhnliches Lauf-zu-Lauf-Rauschen, kein Beweis dafür, dass Electron irgendwie ScreenCaptureKit beschleunigt.
Es gibt eine Testunsicherheit, die es wert ist, offengelegt zu werden. macOS gewährt Screen Recording-Berechtigung an eine signierte Anwendungsidentität. Unser entwickeltes Electron-Binary hatte diese Berechtigung nicht, daher verwendete der Electron-Aufnahmevorgang das signierte Executable von Tight Studio im Node-kompatiblen Modus von Electron. Das isoliert die native Brücke, lässt jedoch einen Chromium-Renderer weg. Wir haben die gepackte Shell separat gemessen, anstatt stillschweigend den 94 MB Host als vollständige Electron-App darzustellen.
Bearbeitung: Übersetztes Metal ist immer noch Metal
JavaScript gibt Apple’s Metal API nicht direkt frei. Diese Tatsache wird manchmal zu einer viel weiter gefassten Behauptung gedehnt: dass Electron kein Metal-gestütztes GPU Rendering verwenden kann.
Auf macOS stellt ANGLE ein Metal-Backend für OpenGL ES bereit, das Chromium unter WebGL verwenden kann. Unser Electron-Benchmark identifizierte seinen Renderer als ANGLE Metal Renderer: Apple M4.
Direct Metal war schneller. Der mittlere native Lauf rendert 684 Bilder pro Sekunde; Electron rendert 594, eine Durchsatzlücke von 13 %. Die P95-Bildzeit stieg von 1,62 auf 1,90 ms.
Das ist messbarer Overhead. Es sind auch 0,28 ms bei einem Frame-Budget von 16,67 ms bei 60 fps.
Reale Editoren bearbeiten natürlich mehr als einen Shader. Sie dekodieren Video, laden Texturen hoch oder importieren sie, rendern Text, berechnen den Animationszustand und reagieren auf Eingaben. Eine nachlässige Implementierung kann das verbleibende Budget durch Kopien, Zuweisungen, synchrone IPC oder React-Arbeiten aufbrauchen. Aber der Browser-Kompositor ist nicht automatisch ein Software-Renderer, und WebGL auf einem Mac ist kein Beweis dafür, dass der GPU umgangen wurde.
Wenn ein WebGL- oder WebGPU-Pfad nicht ausreicht, erlaubt Electron immer noch ein natives Metal-Modul. Die Architektur kann ihren Notausgang pro Teilsystem wählen.
Exportieren: Der Hardware-Encoder interessiert sich nicht dafür, welcher Knopf ihn gestartet hat
VideoToolbox ist Apples Low-Level-Schnittstelle zu Hardware-Encodern und -Decodern. Chromium verfügt über ein macOS VideoToolbox-Encoder-Backend, und WebCodecs bietet Anwendungen eine Präferenz für Hardwarebeschleunigung.
In unserem nativen Lauf bestätigte VideoToolbox die Hardware-Codierung. Der Electron-Lauf forderte Hardware über WebCodecs an. WebCodecs gibt den ausgewählten Encoder-Namen nicht preis, daher können wir keinen API-level Beweis für die Electron-Auswahl beanspruchen. Seine Leistung und Ausgabe stimmen mit dem Hardware-Pfad überein: nativ wurden 300 Frames in median 1,327 Sekunden codiert; Electron benötigte 1,341 Sekunden. Die Ausgaben unterschieden sich in der Größe um weniger als 1%.
Das ergibt 7,54x gegenüber 7,46x Echtzeit – eine Lücke von 1%.
Das bedeutet nicht, dass jeder Electron-Exporter schnell ist. Der Export verlangsamt sich, wenn eine App:
- liest für jeden Frame Pixel aus dem GPU zurück;
- kopiert volle Frames durch JavaScript oder IPC;
- kodiert in Software;
- serialisiert Dekodierungs-, Render-, Audio- und Kodierungsphasen unnötigerweise;
- behält die gesamte Ausgabe im Speicher, anstatt sie zu streamen;
- nutzt den UI-Thread als Render-Worker.
Das sind Entscheidungen für die Pipeline, keine Anforderungen, die von Electron auferlegt werden.
Ein echter Tight Studio-Export
Mikrobenchmarks zeigen, wo Overhead entsteht. Ein Produkttest sagt uns, ob die gesamte Pipeline nützlich ist.
Wir haben auch das bestehende Fünf-Clip-Export-Regressionstool von Tight Studio dreimal ausgeführt. Die 112-Sekunden-Timeline testet die Decodierung pro Clip, GPU-Rendering, Audio, Kodierung, Verkettung und Multiplexing bei 1440×1080. Die Exportzeiten betrugen 81,54, 80,94 und 81,28 Sekunden. Der Median lag bei 81,28 Sekunden, also 1,38-fache Echtzeit.
Die erzeugte Datei war 112,36 Sekunden lang, etwa 30 fps, mit H.264 Video und AAC Audio. Dieses Fixture ist kein universeller Export-Geschwindigkeitstest—die Quellmedien und Effekte spielen eine Rolle—aber es handelt sich um eine End-to-End-Electron-Anwendung, die in einem wiederholbaren Repository-Test schneller exportiert als die Wiedergabe.
Der Teil, bei dem Electron wirklich verliert: Speicher
Electron integriert eine multiprozessorfähige Browserlaufzeit. Das kostet Speicher.
Der direkte native Aufnahme-Host erreichte 45 MB RSS. Der signierte Electron/Node-Host erreichte 94 MB. Unser minimaler Electron-Bearbeitungs-Prozessbaum lag bei etwa 360 MB, und der Export-Prozessbaum bei etwa 394 MB. Eine verpackte Tight Studio-Sitzung mit einem frischen Profil lag in diesem speziellen App-Zustand bei etwa 744–749 MB.
Diese letzte Zahl ist kein Gesetz von Electron, und es ist kein Vergleich mit einer nativen App. Sie ist eine Erinnerung daran, keine minimale Testumgebung als Marketing-Tarnung zu verwenden.
Speicher kann auf eingeschränkten Maschinen wichtig sein. Er kann Druck erzeugen, Swap erhöhen und indirekt Energie kosten. Aber zugewiesener RAM ist nicht dasselbe Maß wie aufgezeichnetes CPU, verworfene Frames, GPU Frame-Zeit oder Encoder-Durchsatz. Eines als Ersatz für alle anderen zu behandeln, führt zu schlechten ingenieurtechnischen Schlussfolgerungen.
Das praktische Ziel ist nicht „keinen Chromium-Speicher verwenden“. Es besteht darin, die Browser-Laufzeit von Hot-Paths für Rohbilder fernzuhalten, Medienobjekte sofort zu schließen, Puffer zu begrenzen, Ausgabe zu streamen und inaktiven Arbeiten inaktiv zu halten.
Eine bessere Möglichkeit, einen Bildschirmrekorder zu bewerten
Fragen Sie, was jedes Teilsystem tatsächlich tut:
- Welche API nimmt den Bildschirm auf?
- Wo werden Frames zusammengesetzt?
- Ist das GPU-Backend hardwarebeschleunigt?
- Welche Encoder-Implementierung wird ausgewählt?
- Wie viele Vollbildkopien entstehen?
- Überqueren Pixeldaten IPC oder JavaScript-Grenzen?
- Kann der Editor 60 fps bei der Zielauflösung halten?
- Was ist die Exportzeit pro Sekunde Ausgabe?
- Was sind CPU, Speicher-, Frame-Drop-, Energie- und Wärme-Ergebnisse bei derselben Arbeitslast?
„Native“ und „Electron“ sind nützliche Implementierungsdetails. Sie sind schwache Benchmark-Ergebnisse.
Die Schlussfolgerung
Eine vollständig native App hat den geringstmöglichen Shell-Overhead und den direktesten Zugriff auf Plattform-APIs. Wenn zwei Teams gleich optimierte, funktionsidentische Pipelines erstellen, behält die native App einen Vorteil – insbesondere im Speicher und bei den letzten Zuwächsen der GPU-Kontrolle.
Aber eine Electron-App muss ihre Media-Engine nicht aus DOM Knoten und JavaScript-Schleifen aufbauen. Sie kann über ScreenCaptureKit aufnehmen, auf Metal-unterstützten GPU-APIs zusammensetzen, mit der Hardware-Medien-Engine kodieren und leistungskritische Aufgaben in native Module oder Worker auslagern.
Unsere Messungen zeigten eine Aufnahme-Bildratenlücke von 0,29 %, eine synthetische 4K Shader-Durchsatzlücke von 13 % und eine kontrollierte Exportlücke von 1 %. Wir fanden auch eine große Speicherdifferenz. Das ist die ehrliche Ausprägung des Kompromisses.
Das Framework setzt die Standardwerte. Die Pipeline bestimmt die Leistung.
Quellen und Reproduktion
- Apple: ScreenCaptureKit
- Apple: VideoToolbox
- electron: nativer Code und electron
- electron: Prozessmodell
- Electron: Warum Electron und Produktions-App-Beispiele
- ANGLE: Metal-Backend-Unterstützung
- chromium: macOS-Videotoolbox-Encoder
- W3C: WebCodecs-Hardwarebeschleunigung
Der Benchmark-Harness, die Rohlauf-Tabelle, der Berechtigungs-Hinweis und die Interpretationsgrenzen werden für eine eigenständige öffentliche Veröffentlichung vorbereitet. Wir fügen den Repository-Link hier hinzu, sobald das Paket unabhängig geklont und ausgeführt werden kann. Zusätzliche Apple-Silicon-Geräte und ein kontrollierter MacBook-Leistungstest würden diese Ergebnisse erweitern, sind jedoch in den obigen Angaben nicht enthalten.