Monosnap이 왜 이렇게 느려졌을까요 — 그리고 해결책

누적된 Electron 비용

Monosnap은’Electron 앱으로 시작하지 않았습니다. 초기에는 많은 캡처 및 편집 코드가 네이티브였습니다. 시간이 지남에 따라 UI 구성 요소는 Chromium 렌더러 위에 재구축되었고 — 이는 반복 작업을 더 쉽게 만들었지만, 크고 영구적인 시작 비용을 추가했습니다.

Electron은’시간이 지남에 따라 가벼워지지 않습니다. 매년 Chromium은 기능을 추가하고, 더 많은 코드를 배포하며, 더 많은 메모리 기준선과 더 복잡한 초기화를 제공합니다. 2019년에 허용 가능한 60 MB였던 앱은 이제 출시 시 최소 180 MB이며, 거기서부터 계속 증가합니다. 이는’저희가 메모리 누수 페이지에서 다룬 메모리 누수를 고려하기 전입니다..

누르면, Ctrl+Alt+5, Monosnap은 캡처 오버레이를 그리기 위해 Chromium 렌더러를 워밍업해야 합니다. 콜드 앱에서는 그것이’수백 밀리초가 걸립니다. 이미 수백 메가바이트까지 메모리 누수가 발생한 '웜' 앱에서는’더 오래 걸립니다. 근무 시간 5시간째가 되면 오버레이가 너무 느리게 그려져서 사용자들이 차이를 느낄 수 있습니다.

주석 편집기가 가장 큰 문제입니다.

캡처 후 편집기 창은 거의 전적으로 Chromium 웹뷰입니다. 화살표를 놓거나 사각형을 그릴 때, 도구는 Electron을 통해 이벤트를 보냅니다.’의 IPC 경계를 통해 네이티브 프로세스로 보냈다가 다시 가져옵니다. 이 왕복 과정은 새로 시작한 프로세스에서는 빠르지만, 프로세스에 부하가 걸리면 눈에 띄게 지연됩니다.

주석 작업을 많이 하는 사용자에게는 — (버그 보고서, 튜토리얼, 문서 등) — 이러한 지연이 쌓입니다. 10분간의 주석 작업이 20분처럼 느껴집니다.

Maxisnap: Electron 없음, 추가 부담 없음

Maxisnap’의 편집기는 네이티브 PyQt6 창입니다. 주석 캔버스는 QPainter 에 직접 QPixmap을(를) 사용합니다.’웹뷰가 없으며, 도구 로직과 렌더링 표면 사이에 IPC 경계가 없습니다. 화살표를 놓으면 다음 페인트 주기에서 바로 나타납니다. 왕복 과정이 없습니다.

일반적인 컴퓨터에서 트레이에서 캡처 준비까지의 콜드 스타트는 약 1초입니다. 캡처에서 편집기까지는 200ms 미만입니다. 이 수치는 1시간, 4시간, 8시간, 72시간 후에도 동일하게 유지됩니다. 앱은’시간이 지나도 성능이 저하되지 않습니다. 왜냐하면’축적될 것이 없기 때문입니다.