Electron以慢著称，腾讯文档却能实现内存优化60%？

腾讯云开发者

于 2025-05-21 08:45:49 发布

阅读量924

点赞数 15

CC 4.0 BY-SA版权

文章标签： electron javascript 前端 ecmascript 前端框架

本文链接：https://blog.youkuaiyun.com/QcloudCommunity/article/details/148336349

👉目录

1 背景介绍

2 优化方案

3 实施过程

4 优化效果

5 总结

6 后续计划

腾讯文档桌面端新版本已对外发布，该版本中优化了内存占用，Windows 版本内存占用下降了约60%，改善了用户体感，本文对桌面端的部分工作做一个总结。

关注腾讯云开发者，一手技术干货提前解锁👇

鹅厂程序员面对面直播继续，每周将邀请鹅厂明星技术大咖深入讲解技术话题，更有精美周边等你来拿，记得提前预约直播～👇

🏃揭秘腾讯云爆款产品！抢跑618，开发者直播间限定福利，爆款低至1元起，手慢无！

01

背景介绍

腾讯文档桌面端采用的是 Electron 技术方案，文档管理与编辑核心功能由 Web 实现，各品类提供文档的编辑页面，每打开一篇文档就会增加一个渲染进程，占用几百 MB 的内存，再加上基础公共的进程，内存占用数量偏高，外部用户和内部同事都有希望减少内存占用的相关反馈。

虽然主流设备的内存配置一直在增长，但是当用户在任务管理器中看到我们的应用占用了大几百 M 甚至几个 G 的内存，还是给我们了很大的压力。与 Native 编辑技术方案的产品对比后，就让我们的产品在内存占用方面更显劣势。我们有迫切的需求改善这个状况。

02

优化方案

2.1 难点与挑战

通常的内存优化方案，代码瘦身，资源复用，按需加载，优化程序数据结构，解决内存泄漏，这些都是有效的方法，我们的同学们也在逐步进行中，但是这些方案都需要长时间的开发投入，逐步优化我们的内存占用，而且目前部分优化成果暂时还未完全落地到我们 C 端的产品环境中，远水不能解近渴，我们需要更快见效的方案。

我们考虑了一些方案：

容器合并：用户打开同一品类的多份文档时，只使用一个容器，多份文档共享同一个容器，用户切换文档时只切换页面中的文档数据。这样如果是同一个品类，多打开一份文档只新增数据及维护状态的内存消耗。 Slide 团队做了一个原型进行快速验证，验证结果切换文档数据时会有一个明显的重新渲染等待时间，后面可以继续考虑缓存渲染结果等方案进行优化，大量的组件需要配合支持，同时也有很多状态需要维护，开发成本较高，效果暂不明确，暂时没有继续推进。
渲染进程的单进程模式，Electron 使用的是 Chromium 多进程模式，这也是现在浏览器的主流方式，单进程模式可以节省内存，在浏览器上通过--single-process 的启动项进行了尝试，发现运行不稳定，Electron 默认也不支持单进程模式，于是这个方案暂时没有继续向下推进，后续对 Chromium 内核有了进一步了解后，再来验证该方向。

03

实施过程

3.1 第一阶段：墓碑机制

用户通常的使用习惯，打开腾讯文档桌面端后，即使暂不使用，关闭窗口后，默认会最小化到托盘，不会退出应用程序。

该操作方式下，我们的文档所有的页面还是处于打开状态，会继续占用内存，也会占用小部分 CPU。我们效仿 iOS 的墓碑系统（Tombstone System）的设计来对已打开的文档进行内存管理以达到内存峰值的控制。其主要原理为区分文档的前/后台状态，然后进行必要的进程清理（杀后台）。

主要策略：

触发条件：文档切换到后台（Tab 未选中）超过30分钟且当前打开的Tab占用内存总数超过系统内存的1/4，

则：依次杀掉文档切换到后台超过30分钟，且时间最长的渲染进程，一直到内存占用降低到1/4之下。

用户再次切换到该 Tab 时自动重新加载该文档（类似 Chrome 省内存模式下的表现）。

回收暂不使用的文档 Tab，我们最担心的是降低的用户体验，再次选中Tab时会有一个加载的过程，所以设置了较高的触发门槛。

我们在3.9.0版本中该策略上线后，持续关注用户体验情况，未收到相关负面反馈。

3.2 第二阶段：内存清理与页面冻结

内存清理

我们调研发现，Windows 平台 EmptyWorkingSet 的 API 可以实现清空工作集，将进程的使用的内存页标记为可移除，如果内存紧张有其他进程需要使用时，再将该内存页移动到页面文件中，当前进程需要使用时，如果内存页还在内存中，即可直接再次启用，如果已经被移动到页面文件，即自动从页面文件中加载回来。通过验证发现，该方法可显著降低进程的内存占用（以任务管理器统计为准），普通用户正常使用过程中几乎感受不到对性能的影响，而且该方法在 Windows 7 平台下也支持。但是通过 EmptyWorkingSet 清理内存后，随着渲染进程持续的运行，标记为可移除的内存页面会重新加载回来，任务管理器统计的内存使用量又会很快上涨回来。

页面冻结

我们在 Chrome 中找到了 SetPageFrozen 方法，可以将当前不可见的页面设置为冻结状态。冻结状态的页面渲染进程会暂停为该页面分配 CPU 资源，原本页面中定时器回调函数、DOM 操作、复杂的 JavaScript 计算等任务都将停止执行，从而使得 CPU 可以将更多的资源分配给其他活跃的页面或系统进程，提升活跃页面的运行效率。

实施

在 Windows 平台下使用 EmptyWorkingSet API 需要至少拥有目标进程的 PROCESS_QUERY_LIMITED_INFORMATION 以及 PROCESS_SET_QUOTA 权限，通常情况下在当前进程中操作另一个进程时，只拥有 PROCESS_QUERY_LIMITED_INFORMATION 权限，而无法获取到 PROCESS_SET_QUOTA 权限，除非当前进程拥有管理员权限，或者操作的是当前进程。腾讯文档桌面端通常运行在普通权限下，不可能向用户申请调管理员权限，于是只能在当前进程中调用。

我们开发了 node 的 addon，将该 addon 注入到渲染进程，验证了执行效果，但要往渲染进程注入 addon 需要打开渲染进程的 node 集成，这样会影响在线文档的安全性，正式版本不能这样做。

页面冻结方法 SetPageFrozen 是在 Chromium 中提供的内部方法，Electron没有进行封装。

于是我们重新修改编译了 Electron 的源码，封装了 SetPageFrozen 方法，在渲染进程和浏览器进程中都增加内存清理的方法，让 Electron 应用开发者可以调用渲染进程的内存清理的方法，以及设置页面的冻结状态。

基于以上两个方法，我们实现了内存清理与页面冻结，从单个文档 Tab 上查看效果如下：

演示文档的 PID 是24716，文档切换到后台，大约 10s 左右，内存占用即会明显下降。

对整个桌面端主要策略如下：

文档切换到后台（Tab 未选中）3s 后即 SetPageFrozen，使页面冻结，浏览器会暂停大部分活动，进行页面的垃圾回收，再延时 5s 后进行 EmptyWorkingSet。每1分钟进行一次检查，如果渲染进程占用内存超过50m，则再进行一次内存清理。

文档切换到前台后，恢复页面为非冻结，并停止内存清理操作。

另外对于主进程、preload 进程，report 进程，列表页渲染进程，会进行内存清理，但不会冻结相应进程。