TL;DR — Electron은 실제 메모리 비용이 있습니다. 의미 있는 녹화 또는 내보내기 페널티를 강제로 부과할 필요는 없습니다.
저희 M4 Mac 미니에서, 네이티브 ScreenCaptureKit 녹화기와 Electron에서 호스팅된 동일한 네이티브 녹화기는 57.70 fps와 57.53 fps로 4K 동영상을 생성했습니다. 4K 편집 셰이더는 직접 Metal에서는 p95 기준으로 프레임당 1.62ms, Electron의 WebGL-to-Metal 경로에서는 1.90ms가 소요되었습니다. 제어된 1080p H.264 내보내기는 네이티브 VideoToolbox를 통해 실시간 대비 7.54배, Electron의 WebCodecs 경로를 통해 7.46배 속도로 실행되었습니다.
간격은 0이 아니었습니다. 단지 기존 논의가 주장하는 위치에는 없었다는 것입니다.
Electron의 명백한 손실은 메모리였다: Chromium 렌더러를 추가하기 전, 직접 네이티브 녹화 호스트는 45 MB, 서명된 Electron/Node 호스트는 94 MB였다. 패키지된 Tight Studio 세션은 이 테스트에서 약 744–749 MB로 안정화되었다. 이는 솔직하게 이름을 붙일 가치가 있는 타협이다. 이것이 캡처된 프레임이 반드시 웹 페이지를 거쳐야 하거나 내보내기가 소프트웨어 인코딩으로 돌아가야 한다는 증거는 아니다.
우리는 Tight Studio를 Electron으로 개발했기 때문에 이 질문에 관심이 있습니다. 그래서 우리는 벤치마크를 통제 가능하고 반복 가능하게 만들었으며, 이 게시물에는 Electron이 더 나쁘게 보이도록 만드는 결과와 더 좋게 보이도록 만드는 결과를 모두 포함했습니다.
“네이티브 vs Electron”은 잘못된 추상화 수준입니다.
데스크탑 앱은 하나의 실행 엔진이 아니다.
Electron은 Chromium 렌더러, Node.js 메인 프로세스, 다중 프로세스 애플리케이션 셸을 제공합니다. 또한 네이티브 모듈을 지원합니다. Electron 자체 문서에서는 앱이 플랫폼 API와 성능에 중요한 작업을 위해 네이티브 코드를 사용할 수 있다고 명확히 명시하고 있습니다.
이는 Electron 화면 녹화 프로그램이 최소한 두 가지 매우 다른 방식으로 구축될 수 있음을 의미합니다.
- 프레임을 JavaScript와 브라우저 표면을 통해 캡처, 합성, 복사 및 인코딩합니다.
- 제품 UI 및 오케스트레이션에는 Electron을 사용하고 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에서 스크린 프레임은 ScreenCaptureKit을 사용하는 Swift 모듈에 의해 캡처되고 AVAssetWriter로 기록됩니다. 녹화는 DOM, React 또는 Chromium 캔버스를 거치지 않습니다. 편집과 내보내기 과정에서는 GPU 합성 및 하드웨어 코덱 API가 무거운 작업을 수행하며, JavaScript는 파이프라인을 조율합니다.
애플은 ScreenCaptureKit을 프레임 및 오디오 캡처를 위한 고성능 API으로 설명합니다. Electron은 앱이 이를 호출하는 것을 막지 않습니다. 네이티브 모듈은 동일한 프레임워크를 호출하고 수신할 수 있습니다 CMSampleBuffer 객체들을 동일한 시스템 인코더로 전달합니다.
우리가 벤치마킹한 것
우리는 두 완제품을 비교하는 것을 피했습니다. 한 앱은 자막, 커서 움직임, 카메라 컷아웃 및 다섯 개의 오버레이를 렌더링할 수 있는 반면 다른 앱은 원본 녹화를 다시 멀렉스할 수 있습니다. 더 빠른 결과는 Swift나 Electron에 대해 거의 아무 것도 알려주지 않을 것입니다.
대신, 우리는 작업 부하를 일정하게 유지했습니다:
- 기계: Apple M4 Mac 미니, 10코어 CPU, 10코어 GPU, 16 GB 메모리, macOS 26.5.2.
- 녹화: 완전히 동일한 패키지 네이티브 캡처 엔진은 직접 Swift CLI에서 한 번 실행되고 Tight Studio의 서명된 Electron/Node 실행 파일에서 한 번 실행됩니다. 둘 다 60fps 타겟에서 동일한 애니메이션 3840×2160 디스플레이를 기록했습니다.
- 편집: 같은 절차적 배경, 둥근 카드, 그리드, 그림자, 그리고 3840×2160에서 애니메이션 커서 셰이더. 네이티브는 Metal을 사용했고, Electron은 ANGLE의 Metal 렌더러를 통해 WebGL 2를 사용했습니다. 모든 프레임에는 동기화 경계가 있어 숨겨진 캔버스가 작업을 사라지게 할 수 없었습니다.
- 내보내기: 1920×1080, 30 fps, H.264, 12 Mbps 목표에서 300 프레임. 네이티브는 Metal과 VideoToolbox를 사용했습니다. Electron은 WebGL과 하드웨어 가속을 요청한 WebCodecs를 사용했습니다.
- 실행 횟수: 경로당 세 개. 표는 중앙값을 보고합니다.
배터리 결과는 포함되지 않았습니다. 이는 Mac 미니였으며, 신뢰할 수 있는 배터리 주장에는 더 길고 통제된 MacBook 테스트가 필요합니다.
결과
| 단계 | 직접 네이티브 | Electron/하이브리드 | Electron 차이 |
|---|---|---|---|
| 4K 출력 속도 기록 | 57.70 fps | 57.53 fps | -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 fps | 593.77 fps | -13.22% |
| 4K 편집 셰이더 p95 프레임 시간 | 1.62 ms | 1.90 ms | +0.28 ms |
| 1080p 내보내기 처리량 | 226.10 fps | 223.78 fps | -1.02% |
| 1080p 내보내기 속도 | 7.54x 실시간 | 7.46x 실시간 | -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 역전은 일반적인 실행 간 변동(noise)일 뿐이며, Electron이 ScreenCaptureKit를 somehow 가속화한다는 증거가 아닙니다.
공개할 가치가 있는 테스트 관련 문제점이 있습니다. macOS은 서명된 애플리케이션 ID에 화면 녹화 권한을 부여합니다. 저희 개발 Electron 바이너리는 해당 권한이 없었기 때문에, Electron 녹화 실행은 Electron의 Node 호환 모드에서 Tight Studio의 서명된 실행 파일을 사용했습니다. 이는 네이티브 브리지를 격리하지만, Chromium 렌더러는 생략합니다. 94개의 MB 호스트를 전체 Electron 앱으로 조용히 표시하는 대신, 패키지된 셸을 별도로 측정했습니다.
편집: 번역된 Metal은 여전히 Metal입니다
JavaScript는 Apple의 Metal API를 직접 노출하지 않습니다. 이 사실은 때때로 훨씬 더 광범위한 주장으로 확대되기도 하는데, 이는 Electron이 Metal 지원 GPU 렌더링을 사용할 수 없다는 것입니다.
macOS에서 ANGLE은 Chromium이 WebGL 아래에서 사용할 수 있는 OpenGL ES용 Metal 백엔드를 제공합니다. 저희 Electron 벤치마크에서 해당 렌더러를 확인했습니다. ANGLE Metal Renderer: Apple M4.
Direct Metal이 더 빠릅니다. 중간 네이티브 실행에서는 초당 684 프레임이 렌더링되었고, Electron은 594 프레임이 렌더링되어 13%의 처리량 차이가 있습니다. P95 프레임 시간은 1.62ms에서 1.90ms로 증가했습니다.
이는 측정 가능한 오버헤드입니다. 또한 60fps에서 프레임 예산이 16.67ms일 때 0.28ms입니다.
물론 실제 편집자는 하나 이상의 셰이더를 수행합니다. 동영상을 디코딩하고, 텍스처를 업로드하거나 가져오고, 텍스트를 렌더링하고, 애니메이션 상태를 계산하고, 입력에 응답합니다. 부주의하게 구현하면 복사, 할당, 동기식 IPC 또는 React 작업으로 남은 예산이 소진될 수 있습니다. 그러나 브라우저 합성기는 자동으로 소프트웨어 렌더러가 아니며 Mac의 WebGL은 GPU이 우회되었다는 증거가 아닙니다.
WebGL이나 WebGPU 경로만으로 충분하지 않을 때, Electron은 여전히 네이티브 Metal 모듈을 허용합니다. 아키텍처는 서브시스템별로 이 탈출 경로를 선택할 수 있습니다.
내보내기: 하드웨어 인코더는 어떤 버튼으로 시작되었는지 신경 쓰지 않습니다.
VideoToolbox는 Apple의 하드웨어 인코더 및 디코더에 대한 저수준 인터페이스입니다. Chromium에는 macOS VideoToolbox 인코더 백엔드가 있으며, WebCodecs는 애플리케이션에 하드웨어 가속 선호를 노출합니다.
저희 네이티브 실행에서는 VideoToolbox가 하드웨어 인코딩을 확인했습니다. Electron 실행에서는 WebCodecs를 통해 하드웨어를 요청했습니다. WebCodecs는 선택된 인코더 이름을 노출하지 않기 때문에, Electron 선택에 대한 API 수준의 증거를 주장할 수 없습니다. 성능과 출력은 하드웨어 경로와 일치합니다: 네이티브는 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초 길이였으며, 약 30fps, 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 경계를 넘어가나요?
- 편집기가 목표 해상도에서 60fps를 유지할 수 있나요?
- 출력 1초당 내보내기 시간은 얼마인가요?
- 같은 작업에서 CPU, 메모리, 프레임 드롭, 전력, 열 성능 결과는 무엇인가요?
“네이티브”와 “Electron”은 유용한 구현 세부사항입니다. 이는 약한 벤치마크 결과입니다.
결론
완전히 네이티브인 앱은 가능한 최저 수준의 셸 오버헤드를 가지며 플랫폼 API에 가장 직접적으로 접근할 수 있다. 두 팀이 동일하게 최적화되고 기능이 동일한 파이프라인을 구축한다면 네이티브는 여전히 이점을 유지한다—특히 메모리와 GPU 제어의 마지막 단계에서.
그러나 Electron 앱이 미디어 엔진을 DOM 노드와 JavaScript 루프로 구축할 필요는 없습니다. ScreenCaptureKit을 통해 캡처하고, Metal 기반 GPU API에서 합성하며, 하드웨어 미디어 엔진으로 인코딩하고, 성능이 중요한 작업을 네이티브 모듈이나 워커로 이동할 수 있습니다.
우리 측정에서 0.29%의 녹화 프레임율 격차, 13%의 합성 4K 셰이더 처리량 격차, 1%의 제어된 내보내기 격차를 발견했습니다. 또한 큰 메모리 격차도 확인했습니다. 이것이 트레이드오프의 솔직한 모습입니다.
프레임워크는 기본값을 설정합니다. 파이프라인은 성능을 설정합니다.
출처 및 재현
- 애플: ScreenCaptureKit
- 애플: 동영상툴박스
- electron: 네이티브 코드와 electron
- electron: 프로세스 모델
- Electron: 왜 Electron을 사용하며, 실제 앱 예제
- ANGLE: Metal 백엔드 지원
- 크로미움: macOS videotoolbox 인코더
- W3C: WebCodecs 하드웨어 가속
벤치마크 하니스, 원시 실행 테이블, 권한 주의 사항 및 해석 제한이 독립적인 공개 릴리스를 위해 준비되고 있습니다. 패키지를 독립적으로 복제하고 실행할 수 있을 때 저장소 링크를 여기 추가할 것입니다. 추가적인 Apple 실리콘 기계와 제어된 MacBook 전력 테스트가 이러한 결과를 확대할 수 있지만, 위의 주장에는 포함되지 않습니다.