為何 Monosnap 變得如此緩慢 — 以及解決方案
它以前不’會花這麼久的時間。啟動曾只需一秒。編輯器曾能即時開啟。以下是’改變了什麼，為何這種趨勢不會’逆轉，以及真正再次感覺快速的輕量級替代方案。
Electron 的負擔，日益加劇
Monosnap 並不’是作為 Electron 應用程式開始的。在其早期，許多截圖和編輯程式碼都是原生的。隨著時間的推移，UI 元件在 Chromium 渲染器之上進行了重建 — 這使得它們更容易迭代，但也增加了巨大的、永久性的啟動成本。
Electron 不會’隨著時間的推移而變得更輕量。每年 Chromium 都會增加功能，發布更多程式碼、更高的記憶體基準，以及更複雜的初始化。一個在 2019 年可接受的 60 MB 應用程式，現在啟動時至少需要 180 MB，並且還會繼續增長。這’是在考慮我們在 記憶體洩漏頁面.
當您按下 Ctrl+Alt+5, Monosnap 需要預熱 Chromium 渲染器來繪製擷取疊加層。在應用程式冷啟動時，這會’會花費數百毫秒。對於一個已經佔用數百 MB 記憶體的暖啟應用程式來說，它’會更長。在工作日的第五個小時，疊加層繪製速度會慢到使用者可以察覺到差異。
註釋編輯器是罪魁禍首
截圖後的編輯器視窗幾乎完全是一個 Chromium webview。當您放置箭頭或繪製矩形時，該工具會透過 Electron’的 IPC 邊界將事件傳送到原生程序，然後再傳回。在一個全新的程序上，這個往返過程很快，但一旦程序負載過重，就會明顯變慢。
對於需要大量註釋的使用者 — 錯誤報告、教學、文件 — 這會累積起來。註釋十分鐘感覺就像二十分鐘。
Maxisnap：沒有 Electron，沒有負擔
Maxisnap’的編輯器是一個原生的 PyQt6 視窗。註釋畫布使用 QPainter 直接在 QPixmap上。沒有 webview，工具邏輯和渲染表面之間沒有 IPC 邊界。當您放置箭頭時，它會在下一個繪製週期中出現。沒有往返延遲。’沒有 webview，工具邏輯和渲染表面之間沒有 IPC 邊界。當您放置箭頭時，它會在下一個繪製週期中出現。沒有往返延遲。
在典型機器上，從系統匣冷啟動到準備好截圖大約需要一秒。從截圖到編輯器開啟不到 200 毫秒。這些數字在第 1 小時、第 4 小時、第 8 小時和第 72 小時都保持不變。應用程式不會’隨著時間推移而效能下降，因為沒有’任何東西會累積。
找回您的速度
- 1下載安裝程式。 下載頁面，63 MB，免費。
- 2退出 Monosnap 從系統匣，這樣兩個應用程式就不會’爭奪 hotkey。
- 3安裝。 預設值即可。無需重新啟動。
- 4按下 Ctrl+Alt+5。 請注意，編輯器會在您’放開按鍵之前開啟。
效能問題
我可以在不切換的情況下加速 Monosnap 嗎？
輕微地。在一天結束時關閉應用程式，而不是讓它持續運行。取消勾選「最小化啟動」。禁用任何您不使用的雲端同步功能。’這些都無法解決結構性開銷，但會有些許幫助。
Maxisnap 是’擷取品質一樣嗎？
完全相同。PNG 輸出為全解析度、無損。也支援可配置品質的 JPEG。’除非您透過裁切工具自行添加，否則不會進行縮小取樣或調整大小。
Maxisnap 支援捲動擷取嗎？
尚未支援。如果捲動擷取對您的工作流程至關重要， ShareX 或 Snagit 更適合您。對於帶有註釋的標準區域 / 全螢幕 / 視窗擷取，Maxisnap 更快、更輕巧。