Electron 自带浏览器运行时是内存大头

更新于 2026-07-31

**用 Electron 做桌面壳时，「内存占用高」不是页面本身的成本，而是先付了一套完整浏览器运行时的基础成本：Chromium 内核、V8、DOM/CSS 渲染树，以及 Renderer / GPU / Network 多个隔离进程（通常还带 Node.js runtime）。** 即使窗口里只有一个列表，也是先付这套运行时，而不是「列表本身」的内存。

对比：SwiftUI 复用 macOS 已加载的系统 UI 框架；WKWebView 复用系统 WebKit，通常比自带 Chromium 更轻，同时仍能复用 Web UI —— 代价是与 Chrome 渲染细节可能略有差异，JS 与本地数据仍需 bridge。

壳的三种选择

方案复用代价
SwiftUI 原生系统 UI 框架要重写一套 UI
WKWebView 壳系统 WebKit + Web UIbridge、渲染细节差异
Electron自带 Chromium + Web UI常驻浏览器运行时内存

不要凭印象否决壳方案

把长期驻留内存设成硬验收指标，做最小原型实测 SwiftUI 与 WKWebView 两条路径再决策。前提是先回答「这个 App 是不是全天常驻」——常驻型（持续承接剪藏、订阅、同步）才必须严格控制内存。

多标签切换不必照抄 Chrome 的多网页模型：可以让一个 WKWebView 始终常驻，前端只切换当前标签对应的页面，后台标签只保存轻量状态；切换时不重启 WebView、不重新下载 JS、不访问网络。

延迟不要口头保证，先写成硬验收（如 P95 标签切换 <100ms 且不显示 loading），达不到再考虑保留最近使用页面的渲染状态，不提前引入 Chrome 式（Frozen / Discarded）淘汰机制。

相关