AI 提升效率之後，重新看待 UI 工程

2025 年 12 月 12 日，Zed 工程師 mikayla-maki 關閉了一個 PR。那個 PR 想替 GPUI 加入自訂 shader。回覆很客氣，先謝過貢獻，接著說：「we’re shifting focus to core product work at Zed, and without a Zed use case, I can’t validate this code」，句尾還附了個笑臉。

GPUI 是 Zed 自行開發的 GPU 介面框架，談到 Electron 的替代方案時，經常有人提起它。不到四個月前，Zed 才剛宣布取得紅杉領投的 3200 萬美元，累計募資超過 4200 萬。

九個多月後，2026 年 9 月 26 日，開發者 egoist 建立了一個叫做 MyGo 的儲存庫。39 天後，這個儲存庫有 1,042 次提交，其中 890 次有 Claude 署名。

Claude 出自 Anthropic。Anthropic 自己的桌面應用程式，用的是 Electron。

這三件事放在一起，有點不對勁。我們在兩台電腦上實測了 10 個框架，想看看這個領域走到了哪一步。

Electron 仍被 Claude、Codex 等桌面應用程式採用：Web 生態成熟，一份程式碼能跨平台，模型也熟悉。AI 降低了開發成本，但跨平台相容與維護仍需投入。

GPU 自繪提供了另一條路，但 GPUI 仍優先服務 Zed，跨平台繪圖與元件生態需要長期累積。MyGo 展示了 AI 與現成元件如何加快起步，正式環境的成熟度與長期維護能力仍待驗證。

Flutter、Compose、Slint、egui、iced 等框架各有取捨。我們選了 10 個框架，在相同情境下實測流暢度、CPU、記憶體與設計還原，看看這些路線的實際代價。

我們在 Apple M4 Max 和 ThinkPad T14 Gen6 上，以相同情境測試了 10 個框架。兩端都測 CPU 與記憶體；Windows 另有 PresentMon 的外部影格測量。Mac 的影格回呼定義不一，不用於跨框架比較。硬體與記憶體指標也不同，以下只在各自平台內比較。

動效是一個密集場景：500 張 96×64 邏輯像素的卡片，排成 25 列並相互重疊，每張帶圓角 12、135° 漸層和 blur 16、向下偏移 4 的陰影。所有卡片同時按幀更新位置，繞各自中心做半徑 12、週期 4 秒的圓周運動。每輪持續 30 秒，跑 5 輪取中位數。

主要看大量帶效果的元素持續移動時，框架更新介面、組織繪製和提交渲染的 CPU 成本，以及能否穩定出幀。CPU 是整個應用程式程序樹的占用，不是 GPU 使用率，也沒有拆分各階段耗時；要結合幀間隔看，少出幀也可能讓 CPU 更低。500 是場景中的卡片數，遮擋和視窗裁切意味著並非每幀都完整繪製 500 張。

Windows

列表捲動大家都跟得上。差距出在動效：500 張帶陰影與漸層的卡片，Rust 和 Go 的自繪框架大致維持住了 120Hz，Flutter、Electron、Tauri、Compose 的影格間隔則來到 80 至 160ms。WPF 的 684ms 來自 500 個獨立陰影效果，關掉就回到 8.3ms，不算通病。

文字編輯是另一道門檻。在 5,000 行文件中每秒插入 10 個字元，Flutter、Compose、Slint 都用滿一個核心，Flutter 在 Windows 上還漏掉了三成輸入。

Mac

Mac 上，GPUI、MyGo、egui、iced 的動效 CPU 約為 15%–20%，Flutter 為 237%，Electron 和 Compose 約 100%。文字編輯時，Flutter 和 Compose 仍接近一個核心，Slint 則為 52%，低於它在 Windows 上的 99%。

列表場景中，SwiftUI 約 40 MiB、GPUI 約 340 MiB、egui 約 800 MiB，首先反映的是應用程式程序的記憶體足跡。原生 UI 可以利用系統的程序外渲染服務：Apple 明確說明 AppKit 通常在程序外渲染圖層樹，因此部分繪製與合成工作並不發生在應用程式程序裡。自繪框架也要經過系統合成，但兩條路徑在應用程式與系統之間如何分工，不能只看應用程式程序判斷。M 系列的統一記憶體讓 CPU 和 GPU 共用實體記憶體，並不意味著所有相關成本都會計入應用程式的 phys_footprint。

本次 SwiftUI 列表和動效各 5 輪短時 GPU trace 中，未觀測到應用程式 PID 的 GPU 執行事件，同期 WindowServer 有 GPU 活動；這不代表 SwiftUI 不用 GPU，也不能把整個桌面的活動都算給它。WindowServer 記憶體基線還存在約 205 MiB 的波動，快照未見大額共享物件，也不足以排除系統既有資源的複用。因此，這組數據只能說明 SwiftUI 的應用程式程序占用較低，不能據此斷言完整渲染成本更低，也不能把差額全部歸為系統代付。

這些數字只代表這兩台電腦、這些版本和我們寫的測試程式。方法和完整資料在第 05 節。

編輯器、開發工具、業務應用程式，對文字輸入、動效、記憶體、跨平台交付與元件生態的要求不一樣。大家都有各自的使用情境，選型要看這些取捨能不能接受。

不少框架現在也在做保留、快取與局部更新，減少重複的版面配置與繪製。GPUI 是即時與保留混合的設計。採用哪種模式、哪些工作能重用，和一個影格能畫多快，是不同層面的問題。

動效方面，MyGo、iced、GPUI、Slint、egui 都跟得上，CPU 使用率也低。Slint 記憶體用量最小，egui 記憶體用量偏高，GPUI 的編輯控制項要自己補。MyGo 目前主要是作者自己的應用程式在使用，並沒有經過大規模的正式環境驗證。

Flutter、Electron、Compose 在這次動效壓測中的幀間隔和資源占用也不理想。Tauri 的套件只有 11 MB，執行時記憶體用量和 Electron 差不多。

我們現在覺得，比渲染更重要的是驗證。

寫程式的成本降低了，確認程式碼寫對了還是要花時間。在 Stack Overflow 2025 年開發者調查中，66% 的人遇過 AI 給的方案「almost right, but not quite」，45.2% 說除錯 AI 寫的程式碼更費時間。Sonar 今年 1 月公布的調查則顯示，96% 的開發者不完全相信 AI 產生的程式碼功能正確，只有 48% 表示提交前一定會檢查。Sonar 販售程式碼檢查工具，這個數字要保留一點看法，但和前一份調查相符。

Slint 和 egui 那兩次發布沒有引起太多關注，我們認為卻比渲染上的進展更重要。agent 能注入輸入、擷取畫面，才能改一下、看一眼，再改。以前驗證介面，要有人坐在電腦前逐一點選，現在這件事開始能交給機器。

眼前有三種做法。Web 跨平台手上的資源最多。GPU 自繪不用帶著瀏覽器走，門檻也比以前低了。每個平台各做原生應用是最老的方法，以前只有大公司養得起好幾支團隊，現在的難處是 Breunig 所說三倍的 bug 和支援範圍。如果驗證成本下降、品質提升，為每個平台直接產生原生應用程式，也可能行得通。

我們也在嘗試自己的 GPU UI，差異是把大量 Web 開發的 DX 帶進來：類似 JSX 的元件、類似 CSS 的樣式、flexbox 排版、響應式狀態、像瀏覽器一樣的 DevTools，最後編譯成原生程式碼。它還在早期。

哪種答案會勝出，我們不知道，也可能幾種長期並存。開頭那三件事，直到今天都沒變。那個 PR 還關著，MyGo 還在成長，Claude 的桌面版仍是 Electron。這是個很有意思的時代。

測試於 2026 年 11 月 4 日至 6 日進行。同一份場景在每個框架上各實作一遍，採用官方建議寫法、預設設定和 Release 建置。Compose 的設計頁和共用這套實作的靜止場景在修正模糊後重新測量。

每個框架的每個情境跑 5 輪，每輪 30 秒，依序執行並打亂順序，下表皆為中位數。5 輪間的全距中位數約為 3%，九成在 24% 以內。列表和動效是在統一規格後重測的，因此不同欄位並非在同一時段採集。CPU 以一個邏輯核心為 100%。多行程應用程式計入所有子行程，Mac 的 Tauri 也計入系統為它啟動的 WebKit 行程。Windows 的影格資料只採用能唯一歸屬至一個 swapchain、且沒有遺失紀錄的輪次。

串流和編輯都核對了實際完成量：Windows 上 Flutter 的編輯只完成 68%，其餘都在 99% 以上。

設計還原

背景模糊一項要柔化視窗內指定面板的彩條。Compose 1.12.2 為彩條圖層加上 24 dp 的 Modifier.blur 後，Mac 和 Windows 的原生視窗截圖都出現了柔和的過渡。SwiftUI 的實作同樣先模糊已知的彩條圖層，再疊加半透明白色。兩種寫法的驗證範圍都限於這層已知內容。 Compose Desktop API

GPUI、iced、egui 和 Slint 的受測實作只在彩條上疊了半透明圖層，複測中仍可看到清楚的色帶邊緣。GPUI 的 Blurred 和 iced 的 window::Settings::blur 作用於視窗背後的內容。受測版本的內建繪製介面中未找到局部背景模糊。iced 可用自訂繪製實作局部效果，egui 可透過 PaintCallback 接入渲染後端。 GPUI · iced 視窗設定 · egui 繪製回呼

Slint 的受測組合為 1.18.1 與 FemtoVG，該版本未提供元素的 backdrop-blur 屬性。後續上游已為 Skia 渲染器加入此屬性，本次截圖對應 1.18.1 的 FemtoVG 路徑。 Slint 上游紀錄

設計頁共 11 項。Mac 上 GPUI、egui、iced、Slint、Compose 的 P3 色塊在本次輸出中未還原。Windows 截圖沒有色彩設定檔，P3 不作判定，旗幟 emoji 在各家都顯示成字母。

排版逐漸趨同，分歧最大的是文字。iced 在 macOS 上要求 PingFang 700 時，拉丁字母回退到了 Menlo Bold。

限制：

• 每個平台只有一台電腦，動效結果來自 Intel 內顯，不一定適用於獨立顯示卡。
• Mac 測試時電腦非閒置，影格資料只有應用程式回呼，不做跨框架比較。
• 各家陰影的 blur 定義不同，egui、iced、GPUI 採近似實作；編輯控制項也不等價，GPUI 使用改寫的範例編輯器。
• CPU 和記憶體表只統計應用程式及納入的輔助程序，未按視窗分攤 WindowServer 和驅動成本；系統共享資源的複用收益也未量化，不能用這些表為整機渲染成本排名。
• 未能從輸入法候選字視窗、Mac 無障礙樹與耗電量測得有效結果。