Electron 性能与资源管理：多窗口、多进程与懒加载

Electron 应用被吐槽最多的一点就是「占内存」「吃 CPU」，但很多时候问题不在 Electron 本身，而在于应用的窗口/进程/资源管理方式。
这一篇从工程视角拆开三个问题：多窗口和多进程如何控制、如何避免无谓的常驻开销，以及在加载策略上有哪些常用的懒加载思路。

1. 多窗口 = 多渲染进程：成本是线性上去的

在 Electron 中，每个 BrowserWindow 默认对应一个独立的渲染进程：

  • 每个渲染进程都要占一份：
    • Chromium 渲染堆栈；
    • 前端框架运行时（React/Vue 等）；
    • 应用自己的状态与缓存。

这意味着：

  • 窗口数量和内存/CPU 占用几乎是线性关系；
  • 即便窗口当前不可见，只要进程在，就会占用资源。

工程上的直接启示是：

  • 避免把每一个小功能都做成一个独立窗口，能复用就尽量复用；
  • 对确实需要多窗口的场景，设计清晰的窗口生命周期（何时创建、何时销毁、何时复用）。

可以从几个方面来管理窗口生命周期：

  • 按需创建
    • 首次需要某个功能时再创建对应窗口；
    • 使用时机不高的窗口，尽量不要在应用启动时就全部拉起来。
  • 适时销毁
    • 对完全不再需要的窗口，直接 win.destroy()，释放对应渲染进程；
    • 对只是暂时隐藏的窗口，可以根据场景选择 hide 或销毁重建。
  • 窗口复用
    • 某些场景下可以采用「单例窗口」模式：
      • 如果窗口已经存在，就聚焦并更新内容；
      • 如果不存在，再新建一个。

在主进程中，可以维护一个窗口管理模块：

  • 负责跟踪所有窗口实例及其状态；
  • 提供统一的创建、关闭、聚焦、复用接口，避免在不同地方随意 new 窗口。

渲染进程的主要任务应该是：

  • 处理 UI 渲染；
  • 响应用户交互；
  • 通过受控接口调用本地/远程服务。

一些对 CPU 特别重的任务（如大文件解析、复杂计算、长时间循环）如果直接放在渲染进程中，会导致：

  • UI 卡顿、掉帧；
  • 在多窗口时，单个窗口的重计算还可能拖累整体体验。

更推荐的做法是：

  • 把重计算放到：
    • 后端服务；
    • 主进程或单独的工作进程；
    • 渲染进程里的 Web Worker；
  • 渲染进程只负责展示结果和收集输入。

简单理解为：

  • 渲染进程越「瘦」，Electron 应用在多窗口、多任务下的体验越稳定。

和 Web 应用类似，Electron 应用也需要关注首屏加载时间和感知性能：

  • 首屏/主窗口在用户点击应用图标后多久可见；
  • 次要功能是否可以延后加载，避免一上来把所有代码都打到内存里。

常见的懒加载策略包括：

  • 代码层面
    • 使用前端框架的按需加载（动态 import()、路由级别拆包）；
    • 对大型组件/模块做 lazy loading。
  • 资源层面
    • 图片、图标等非关键资源按需加载；
    • 日志、历史记录等非关键数据在主 UI 稳定后再异步加载。
  • 功能层面
    • 不在应用启动时初始化所有后台任务和监听器；
    • 等用户首次使用某项功能，再初始化相关状态与链接。

在主进程上也类似：

  • 一些与外部系统的长连接、监控任务可以在真正需要时再启动；
  • 不必在 app.ready 之后立刻把所有后台能力都拉起来。

在排查 Electron 性能问题时，可以利用：

  • Chromium DevTools
    • CPU Profiling：查看哪些函数/组件占用最多时间；
    • Performance Timeline：分析渲染帧率、长任务（>50ms）。
  • 内存分析
    • 对比不同窗口数量下的内存占用情况；
    • 在特定操作后观察内存是否持续增长，判断是否存在泄漏。
  • 应用级监控
    • 在关键操作前后埋点，记录操作耗时与资源占用变化；
    • 为异常高占用场景提供重现路径。

调优时，建议先回答几个问题：

  • 是「单窗口场景也持续高占用」，还是「只有打开多窗口后才问题明显」？
  • 是「CPU 打满」还是「内存持续上涨」？
  • 有无特定操作（如打开大文件、切换复杂视图）会稳定复现问题？

这些判断可以帮助更快锁定优化方向：是前端渲染问题、计算问题，还是窗口/进程管理问题。

可以用几条主线来概括这一篇：

  • 多窗口意味着多渲染进程，窗口越多，资源占用越高；应通过「按需创建 + 适时销毁 + 复用单例窗口」来管理生命周期；
  • 渲染进程应尽量保持「瘦」，重任务交给后端服务、主进程/工作进程或 Web Worker；
  • 通过代码/资源/功能三层懒加载策略，把加载压力从启动时刻分散到使用时刻；
  • 利用 DevTools 和监控体系，区分不同类型的性能问题，有针对性地调优。

在这套思路下，Electron 应用的性能体验往往可以从「看上去很笨重」变成「足够顺滑且可控」。