Chuyển đến bài viết
← Quay lại kỹ thuật

Electron không phải là cổ chai của ứng dụng quay màn hình của bạn

Minh họa bìa cho Electron không phải là nút thắt cổ chai của ứng dụng chụp màn hình của bạn

TL;DR — Electron có chi phí bộ nhớ thực sự. Nó không phải chịu hình phạt đáng kể nào về ghi lại hoặc xuất video.

Trên máy M4 Mac mini của chúng tôi, một ứng dụng quay video ScreenCaptureKit gốc và cùng một ứng dụng quay video gốc được chạy từ Electron đã tạo ra video 4K với tốc độ 57,70 và 57,53 fps. Một shader chỉnh sửa 4K mất 1,62 ms cho mỗi khung tại p95 khi sử dụng Metal trực tiếp và 1,90 ms thông qua đường dẫn WebGL-to-Metal của Electron. Một xuất 1080p H.264 kiểm soát đã chạy với tốc độ 7,54x thời gian thực qua VideoToolbox gốc và 7,46x qua đường dẫn WebCodecs của Electron.

Khoảng cách không bằng không. Nó chỉ không nằm ở vị trí mà lập luận thông thường đặt ra.

Mất mát rõ ràng của Electron là bộ nhớ: 45 MB cho máy chủ ghi video gốc trực tiếp so với 94 MB cho máy chủ Electron/Node được ký, trước khi thêm trình hiển thị Chromium. Một phiên Tight Studio đóng gói ổn định ở khoảng 744–749 MB trong thử nghiệm này. Đó là một sự đánh đổi đáng để thừa nhận trung thực. Nó không phải là bằng chứng rằng các khung hình đã ghi phải đi qua trang web hoặc rằng việc xuất phải dựa vào mã hóa bằng phần mềm.

Chúng tôi xây dựng Tight Studio với Electron, vì vậy chúng tôi quan tâm đến câu hỏi này. Đó là lý do tại sao chúng tôi thực hiện benchmark có kiểm soát và có thể lặp lại, và tại sao bài viết này bao gồm cả kết quả khiến Electron trông tệ hơn cũng như những kết quả khiến nó trông tốt hơn.

Sơ đồ cho thấy Electron xử lý điều khiển sản phẩm trong khi quay gốc, GPU hỗ trợ bởi Metal hiển thị, và các codec phần cứng xử lý các đường dẫn phương tiện

“Native so với Electron” là mức trừu tượng sai

Một ứng dụng trên máy tính để bàn không phải là một động cơ thực thi duy nhất.

Electron cung cấp một trình hiển thị Chromium, một tiến trình chính Node.js, và một bộ vỏ ứng dụng đa tiến trình. Nó cũng hỗ trợ các module gốc. Tài liệu của Electron rõ ràng rằng một ứng dụng có thể sử dụng mã gốc cho các API nền tảng và công việc quan trọng về hiệu suất.

Điều đó có nghĩa là một ứng dụng chụp màn hình Electron có thể được xây dựng ít nhất theo hai cách rất khác nhau:

  1. Ghi lại, kết hợp, sao chép và mã hóa khung hình thông qua JavaScript và bề mặt trình duyệt.
  2. Sử dụng Electron cho sản phẩm UI và điều phối trong khi ScreenCaptureKit, AVFoundation, Metal, VideoToolbox, hoặc một công cụ truyền thông gốc khác đảm nhận đường hầm nóng.

Những ứng dụng đó chia sẻ nhãn thuộc khuôn khổ. Chúng không chia sẻ kiến trúc hiệu năng.

Electron đã hỗ trợ các ứng dụng desktop đòi hỏi cao

Kiến trúc này không hiếm. Các phân phối hiện tại macOS của Codex và Claude sử dụng Electron. Trên máy được sử dụng cho bài viết này, Codex 26.825.41651 khai báo ElectronAsarIntegrity cho nó app.asar gói, trong khi Claude 1.26832.0 cũng phát hành cả hai Electron Framework.frameworkapp.asar.

Tài liệu của Electron cũng liệt kê Visual Studio Code, Figma, Docker Desktop, Loom, Canva, Notion, 1Password, Slack, Discord và Signal trong số các sản phẩm được xây dựng bằng framework này. Chúng bao gồm chỉnh sửa và gỡ lỗi mã, đồ họa hợp tác, quản lý container, quay màn hình, quản lý thông tin đăng nhập, nhắn tin, thoại và video, và các quy trình làm việc AI.

Danh sách đó không phải là một tiêu chuẩn hiệu suất, và nó không chứng minh rằng mọi ứng dụng Electron đều hiệu quả. Nó minh họa điểm kiến trúc: lựa chọn Electron cho một giao diện máy tính để bàn không yêu cầu giao diện thực hiện mọi thao tác tốn kém. Các module gốc, GPU tiến trình, dịch vụ trên thiết bị và hệ thống từ xa có thể đảm nhận công việc chuyên môn.

Bạn có thể kiểm tra gói macOS mà không cần công cụ đặc biệt. Trong Finder, chọn Hiển thị nội dung gói, sau đó kiểm tra Contents/Info.plist, Contents/Resources/app.asar, và Contents/Frameworks/.

Tight Studio sử dụng mô hình thứ hai. Trên macOS, các khung hình màn hình được ghi lại bởi một module Swift sử dụng ScreenCaptureKit và viết bằng AVAssetWriter. Việc ghi video không đi qua DOM, React hay khung chỉnh sửa Chromium. Trong quá trình chỉnh sửa và xuất, GPU kết hợp và các API codec phần cứng thực hiện các công việc nặng; JavaScript điều phối quy trình làm việc.

Apple mô tả ScreenCaptureKit như API hiệu suất cao của nó để ghi lại khung hình và âm thanh. Electron không ngăn một ứng dụng gọi nó. Một module gốc có thể gọi cùng framework, nhận cùng CMSampleBuffer đối tượng, và chuyển chúng cho cùng bộ mã hóa hệ thống.

Những gì chúng tôi đã benchmark

Chúng tôi tránh so sánh hai sản phẩm đã hoàn thiện. Một ứng dụng có thể kết xuất phụ đề, chuyển động con trỏ, cắt camera và năm lớp phủ trong khi ứng dụng khác chỉ ghép lại video gốc. Kết quả nhanh hơn sẽ hầu như không nói lên điều gì về Swift hay Electron.

Thay vào đó, chúng tôi giữ khối lượng công việc không đổi:

  • Máy: Apple M4 Mac mini, 10 lõi CPU, 10 lõi GPU, 16 bộ nhớ GB, macOS 26.5.2.
  • Ghi hình video: cùng một engine ghi hình gốc được đóng gói, chạy một lần từ Swift CLI trực tiếp của nó và một lần từ thực thi Electron/Node đã ký của Tight Studio. Cả hai đều ghi lại cùng một màn hình hoạt hình 3840×2160 với mục tiêu 60 fps.
  • Chỉnh sửa: cùng nền tảng quy trình, thẻ bo tròn, lưới, bóng, và shader con trỏ động ở độ phân giải 3840×2160. Native sử dụng Metal; Electron sử dụng WebGL 2 qua bộ dựng Metal của ANGLE. Mỗi khung hình có ranh giới đồng bộ hóa nên một khung chỉnh sửa ẩn không thể làm công việc biến mất.
  • Xuất: 300 khung hình ở 1920×1080, 30 fps, H.264, và mục tiêu 12 Mbps. Native sử dụng Metal cùng VideoToolbox. Electron sử dụng WebGL cùng WebCodecs với yêu cầu tăng tốc phần cứng.
  • Chạy: ba trên mỗi đường dẫn. Bảng báo cáo giá trị trung vị.

Không có kết quả pin nào được đưa vào. Đây là một Mac mini, và một tuyên bố pin đáng tin cậy cần một bài kiểm tra MacBook lâu hơn và có kiểm soát.

Biểu đồ chuẩn không dựa trên số liệu so sánh quay video trực tiếp gốc và hybrid Electron, chỉnh sửa 4K, và tốc độ xuất H.264

Kết quả

Giai đoạnGốc trực tiếpElectron/hybridSự khác biệt của Electron
4K tỷ lệ xuất bản quay video57,70 khung hình/giây57,53 khung hình/giây-0.29%
Máy chủ ghi video CPU7.06%6.98%-0,09 điểm
Ghi video OS-dịch vụ CPU31.34%32.76%+1,42 điểm
Bộ nhớ đỉnh của máy chủ ghi video45.36 MB94.39 MB+49.03 MB
4K chỉnh sửa thông lượng shader684,23 khung hình/giây593,77 khung hình/giây-13.22%
4K chỉnh sửa thời gian khung shader p951,62 ms1,90 ms+0,28 ms
Thông lượng xuất 1080p226,10 fps223,78 fps-1.02%
Tốc độ xuất 1080p7,54 lần thời gian thực7,46 lần thời gian thực-1.02%

Đây là các thử nghiệm ngắn, được kiểm soát trên một máy. Chúng xác lập những gì có thể với các kiến trúc này; chúng không hứa rằng mọi ứng dụng Electron sẽ hiệu quả như vậy.

Ghi video: Electron không cần chạm vào khung hình

Kết quả quay video gần như hòa vì cả hai đường dẫn đều giống nhau ở những nơi quan trọng.

ScreenCaptureKit tạo ra các khung hình. AVAssetWriter và hệ thống codec mã hóa chúng. Phía Electron yêu cầu ứng dụng quay video gốc để bắt đầu, dừng, tạm dừng và tiếp tục. Nó không nhận các bộ đệm pixel của 4K qua kênh IPC và nó không mã hóa chúng trong JavaScript.

Trong ba lần chạy, bản gốc đạt trung vị 57,70 fps và máy chủ Electron đạt 57,53 fps—khác biệt 0,29%. Trung vị ứng dụng chụp video CPU là 7,06% đối với bản gốc và 6,98% đối với máy chủ Electron. Dịch vụ chụp macOS trung bình lần lượt là 31,34% và 32,76%.

Kết quả tốc độ khung hình là quan trọng. Việc đảo ngược CPU nhỏ là nhiễu bình thường khi chạy nhiều lần, không phải bằng chứng rằng Electron nào đó tăng tốc ScreenCaptureKit.

Có một chi tiết kiểm tra đáng để tiết lộ. macOS cấp quyền chụp màn hình cho một nhận dạng ứng dụng đã được ký. Bản nhị phân Electron phát triển của chúng tôi không có quyền đó, vì vậy lần quay video Electron đã sử dụng tệp thực thi đã ký của Tight Studio trong chế độ tương thích Node của Electron. Điều đó cô lập cầu nối gốc nhưng bỏ qua trình kết xuất Chromium. Chúng tôi đo lường vỏ đóng gói riêng biệt thay vì trình bày lặng lẽ máy chủ 94 MB như một ứng dụng Electron đầy đủ.

Chỉnh sửa: Metal đã dịch vẫn là Metal

JavaScript không trực tiếp cung cấp API Metal của Apple (API). Thực tế này đôi khi được mở rộng thành một tuyên bố rộng hơn: rằng Electron không thể sử dụng kết xuất (GPU) dựa trên Metal.

Trên macOS, ANGLE cung cấp backend Metal cho OpenGL ES, vốn là thứ Chromium có thể sử dụng bên dưới WebGL. Thử nghiệm Electron của chúng tôi đã xác định renderer của nó là ANGLE Metal Renderer: Apple M4.

Direct Metal nhanh hơn. Chạy gốc trung vị xử lý 684 khung hình mỗi giây; Electron xử lý 594, tạo ra khoảng cách thông lượng 13%. Thời gian khung P95 tăng từ 1,62 lên 1,90 ms.

Đó là chi phí tính toán có thể đo lường. Nó cũng là 0,28 ms trong ngân sách khung hình 16,67 ms ở 60 fps.

Tất nhiên, các trình chỉnh sửa thực sự thực hiện nhiều hơn một shader. Chúng giải mã video, tải lên hoặc thêm họa tiết, hiển thị văn bản, tính toán trạng thái hoạt ảnh và phản hồi đầu vào. Việc triển khai bất cẩn có thể đốt cháy ngân sách còn lại bằng các bản sao, phân bổ, IPC đồng bộ hoặc công việc React. Tuy nhiên, trình tổng hợp của trình duyệt không tự động là trình kết xuất phần mềm và WebGL trên Mac không phải là bằng chứng cho thấy GPU đã bị bỏ qua.

Khi một đường dẫn WebGL hoặc WebGPU không đủ, Electron vẫn cho phép một module Metal gốc. Kiến trúc có thể chọn lối thoát riêng theo từng hệ thống con.

Xuất: bộ mã hóa phần cứng không quan tâm nút nào đã khởi động nó

VideoToolbox là giao diện cấp thấp của Apple đối với bộ mã hóa và giải mã phần cứng. Chromium có macOS backend mã hóa VideoToolbox, và WebCodecs cung cấp tùy chọn ưu tiên tăng tốc phần cứng cho các ứng dụng.

Trong lần chạy gốc của chúng tôi, VideoToolbox đã xác nhận mã hóa phần cứng. Lần chạy Electron yêu cầu phần cứng thông qua WebCodecs. WebCodecs không hiển thị tên bộ mã hóa được chọn, vì vậy chúng tôi không thể khẳng định bằng chứng mức API về việc chọn Electron. Hiệu suất và đầu ra của nó phù hợp với đường dẫn phần cứng: bản gốc đã mã hóa 300 khung hình trong trung bình 1,327 giây; Electron mất 1,341 giây. Kích thước đầu ra khác nhau dưới 1%.

Điều đó tương đương với 7,54x so với 7,46x thời gian thực — chênh lệch 1%.

Điều này không có nghĩa là mọi trình xuất Electron đều nhanh. Việc xuất sẽ chậm lại khi một ứng dụng:

  • đọc lại các pixel từ GPU cho mỗi khung hình;
  • sao chép các khung đầy đủ thông qua JavaScript hoặc IPC;
  • mã hóa bằng phần mềm;
  • tuần tự hóa các giai đoạn giải mã, hiển thị, âm thanh và mã hóa một cách không cần thiết;
  • giữ toàn bộ đầu ra trong bộ nhớ thay vì phát trực tiếp;
  • sử dụng luồng UI làm công nhân bản kết xuất.

Đó là những lựa chọn về quy trình làm việc, không phải những yêu cầu do Electron áp đặt.

Một xuất Tight Studio thực sự

Các microbenchmark cho thấy nơi chi phí phụ thêm xuất hiện. Một bài kiểm tra sản phẩm cho chúng ta biết liệu quy trình hoàn chỉnh có hữu ích hay không.

Chúng tôi cũng đã chạy thiết bị kiểm tra một lô xuất năm clip hiện có của Tight Studio ba lần. Dòng thời gian 112 giây này thực hiện giải mã từng clip, kết xuất GPU, âm thanh, mã hóa, nối và ghép ở 1440×1080. Thời gian xuất là 81,54, 80,94 và 81,28 giây. Giá trị trung vị là 81,28 giây, hoặc 1,38 lần thời gian thực.

Tệp tạo ra dài 112,36 giây, khoảng 30 fps, với H.264 video và AAC âm thanh. Bộ thử nghiệm này không phải là một chỉ số tốc độ xuất phổ quát—tài liệu nguồn và hiệu ứng đều quan trọng—nhưng đây là một ứng dụng Electron từ đầu đến cuối xuất nhanh hơn phát lại trong một bài kiểm tra kho lặp lại.

Biểu đồ hiển thị một dự án Tight Studio dài 112 giây xuất ra trong thời gian trung bình 81 giây, hay 1,38 lần thời gian thực

Phần mà Electron thực sự thua: bộ nhớ

Electron nhúng một runtime trình duyệt đa tiến trình. Điều đó tốn bộ nhớ.

Máy chủ ghi hình video gốc trực tiếp đạt đỉnh ở 45 MB RSS. Máy chủ Electron/Node đã ký đạt đỉnh ở 94 MB. Cây quy trình chỉnh sửa Electron tối thiểu của chúng tôi khoảng 360 MB, và cây quy trình xuất khoảng 394 MB. Một phiên Tight Studio đã đóng gói với hồ sơ mới ổn định ở khoảng 744–749 MB trong trạng thái ứng dụng cụ thể này.

Biểu đồ bộ nhớ không dựa trên số liệu so sánh các máy chủ quay video gốc và Electron được ghép nối, với ngữ cảnh cây tiến trình Electron riêng

Con số cuối cùng đó không phải là một định luật của Electron, và nó không phải là so sánh với ứng dụng gốc. Nó là một lời nhắc nhở không sử dụng một môi trường thử nghiệm tối thiểu như một chiêu tiếp thị.

Bộ nhớ có thể quan trọng trên các máy tính hạn chế. Nó có thể tạo áp lực, tăng hoán đổi, và gián tiếp tốn năng lượng. Nhưng RAM được phân bổ không phải là cùng một chỉ số với CPU quay video, khung hình bị bỏ, thời gian khung hình GPU, hoặc thông lượng mã hóa. Xem một cái là đại diện cho tất cả những cái khác sẽ dẫn đến kết luận kỹ thuật sai lầm.

Mục tiêu thực tế không phải là “không dùng bộ nhớ Chromium.” Mà là giữ runtime trình duyệt tránh các đường dẫn khung thô, đóng các đối tượng nội dung đa phương tiện ngay lập tức, giới hạn bộ đệm, phát luồng đầu ra, và giữ công việc nhàn rỗi ở trạng thái nhàn rỗi.

Một cách tốt hơn để đánh giá ứng dụng ghi màn hình

Hỏi xem từng hệ thống phụ thực sự làm gì:

  • Các API nào ghi lại màn hình?
  • Các khung hình được ghép lại ở đâu?
  • Backend của GPU có tăng tốc phần cứng không?
  • Triển khai bộ mã hóa nào được chọn?
  • Có bao nhiêu bản sao toàn khung xảy ra?
  • Dữ liệu pixel có vượt qua IPC hay ranh giới JavaScript không?
  • Trình chỉnh sửa có thể giữ 60 fps ở độ phân giải mục tiêu không?
  • Thời gian xuất trên mỗi giây đầu ra là gì?
  • Các kết quả CPU, bộ nhớ, giảm khung hình, điện năng và nhiệt độ trên cùng một khối lượng công việc là gì?

“Native” và “Electron” là các chi tiết triển khai hữu ích. Chúng là kết quả chuẩn yếu.

Kết luận

Một ứng dụng hoàn toàn gốc có chi phí overhead shell thấp nhất và truy cập trực tiếp nhất tới các API nền tảng. Nếu hai nhóm xây dựng các quy trình làm việc tối ưu hóa, tính năng giống hệt nhau, ứng dụng gốc vẫn giữ ưu thế — đặc biệt về bộ nhớ và trong những gia số cuối cùng của kiểm soát GPU.

Nhưng một ứng dụng Electron không bắt buộc phải xây dựng công cụ đa phương tiện của nó từ DOM nút và vòng lặp JavaScript. Nó có thể ghi lại qua ScreenCaptureKit, kết hợp trên các API GPU hỗ trợ Metal, mã hóa bằng công cụ đa phương tiện phần cứng, và chuyển công việc quan trọng về hiệu suất vào các mô-đun hoặc worker gốc.

Các phép đo của chúng tôi cho thấy khoảng cách 0,29% về tốc độ khung hình quay video, khoảng cách 13% về hiệu suất shader 4K tổng hợp và khoảng cách 1% về xuất kiểm soát. Chúng tôi cũng tìm thấy một khoảng cách bộ nhớ lớn. Đó là hình dạng thực tế của sự đánh đổi.

Framework đặt mặc định. Quy trình công việc đặt hiệu suất.

Nguồn và sự tái tạo

  • Apple: ScreenCaptureKit
  • Apple: VideoToolbox
  • Electron: mã gốc và electron
  • Electron: mô hình tiến trình
  • Electron: Tại sao chọn Electron và ví dụ về ứng dụng sản xuất
  • ANGLE: Hỗ trợ nền tảng Metal
  • Chromium: bộ mã hóa videotoolbox macOS
  • W3C: Tăng tốc phần cứng WebCodecs

Bộ công cụ chuẩn, bảng chạy thô, điều khoản quyền hạn và giới hạn diễn giải đang được chuẩn bị để phát hành công khai độc lập. Chúng tôi sẽ thêm liên kết kho lưu trữ ở đây khi gói có thể được sao chép và chạy độc lập. Thêm các máy Apple silicon khác và một thử nghiệm công suất MacBook kiểm soát được sẽ mở rộng các kết quả này, nhưng chúng không được bao gồm trong các tuyên bố ở trên.

Chia sẻ trên x