性能

开发者经常询问优化 Electron 应用程序性能的策略。软件工程师、用户和框架开发者对“性能”的含义并不总是有统一的定义。本文档概述了 Electron 维护者们最喜欢的一些方法，这些方法旨在减少内存、CPU 和磁盘资源的使用量，同时确保您的应用程序响应用户输入并尽可能快地完成操作。此外，我们希望所有性能策略都能保持高标准的应用程序安全性。

关于如何使用 JavaScript 构建高性能网站的经验和信息通常也适用于 Electron 应用程序。在一定程度上，讨论如何构建高性能 Node.js 应用程序的资源也适用，但请注意，“性能”对于 Node.js 后端和在客户端运行的应用程序来说，含义是不同的。

此列表旨在为您提供便利——并且，就像我们的安全清单一样——并非详尽无遗。即使遵循下面概述的所有步骤，也可能构建出一个缓慢的 Electron 应用程序。Electron 是一个强大的开发平台，它使您，即开发者，能够或多或少地做任何您想做的事情。所有这些自由意味着性能在很大程度上是您的责任。

衡量、衡量、再衡量

下面的列表包含了一些相当直接且易于实现的步骤。然而，要构建您的应用程序最优化版本，您需要超越这些步骤。相反，您必须通过仔细的性能分析和测量，密切检查应用程序中运行的所有代码。瓶颈在哪里？当用户点击按钮时，哪些操作占用了大部分时间？当应用程序空闲时，哪些对象占用了最多的内存？

我们一次又一次地看到，构建高性能 Electron 应用程序最成功的策略是分析运行中的代码，找出其中资源消耗最大的部分，并对其进行优化。反复重复这个看似费力的过程将极大地提高您应用程序的性能。与 Visual Studio Code 或 Slack 等主要应用程序合作的经验表明，这种做法是迄今为止提高性能最可靠的策略。

要了解如何分析您的应用程序代码，请熟悉 Chrome 开发者工具。如需一次查看多个进程的进阶分析，请考虑使用 Chrome Tracing 工具。

推荐阅读

• 分析运行时性能
• 演讲：“Visual Studio Code - 第一个一秒”

清单：性能建议

如果您尝试这些步骤，您的应用程序很可能会更精简、更快，并且通常对资源的需求更少。

1. 随意包含模块
2. 过早加载和运行代码
3. 阻塞主进程
4. 阻塞渲染器进程
5. 不必要的 polyfill
6. 不必要的或阻塞的网络请求
7. 打包您的代码
8. 当您不需要默认菜单时，调用 Menu.setApplicationMenu(null)

1. 随意包含模块

在向您的应用程序添加 Node.js 模块之前，请检查该模块。该模块包含多少个依赖项？它在简单的 require() 语句中被调用时需要什么样的资源？您可能会发现，在 NPM 包注册表中下载量最多或在 GitHub 上星标最多的模块，实际上并不是最精简或最小的可用模块。

为什么？

这一建议背后的原因最好通过一个实际例子来说明。在 Electron 的早期，可靠的网络连接检测是一个问题，导致许多应用程序使用一个暴露了简单 isOnline() 方法的模块。

该模块通过尝试连接到一些知名端点来检测您的网络连接。对于这些端点的列表，它依赖于另一个模块，该模块也包含一个知名端口列表。这个依赖项本身又依赖于一个包含端口信息的模块，该模块以一个超过 100,000 行内容的 JSON 文件的形式存在。每当该模块被加载（通常在 require('module') 语句中）时，它都会加载所有依赖项，并最终读取和解析这个 JSON 文件。解析数万行 JSON 是一个非常耗时的操作。在慢速机器上，这可能需要整整几秒钟的时间。

在许多服务器环境中，启动时间几乎无关紧要。一个需要所有端口信息的 Node.js 服务器，如果在服务器启动时将所有必需信息加载到内存中以更快地服务请求，那么它实际上可能“更具性能”。本例中讨论的模块并非“坏”模块。然而，Electron 应用程序不应加载、解析和存储它实际不需要的信息到内存中。

简而言之，一个主要为运行 Linux 的 Node.js 服务器编写的看似优秀的模块，可能对您的应用程序性能来说是个坏消息。在这个特定的例子中，正确的解决方案是根本不使用任何模块，而是使用 Chromium 后续版本中包含的连接性检查功能。

如何做？

在考虑一个模块时，我们建议您检查

1. 包含的依赖项大小
2. 加载它（require()）所需的资源
3. 执行您感兴趣的操作所需的资源

为加载模块生成 CPU 分析文件和堆内存分析文件可以通过命令行上的一个简单命令完成。在下面的示例中，我们正在查看流行的 request 模块。

node --cpu-prof --heap-prof -e "require('request')"

执行此命令会在您执行命令的目录中生成一个 .cpuprofile 文件和一个 .heapprofile 文件。这两个文件都可以使用 Chrome 开发者工具进行分析，分别在 Performance 和 Memory 选项卡中查看。

在这个例子中，在作者的机器上，我们看到加载 request 花费了近半秒，而 node-fetch 占用的内存显著减少，并且耗时不到 50 毫秒。

2. 过早加载和运行代码

如果您有耗时的设置操作，请考虑推迟它们。检查应用程序启动后立即执行的所有工作。与其立即启动所有操作，不如考虑按照更贴近用户旅程的顺序错开执行。

在传统的 Node.js 开发中，我们习惯于将所有 require() 语句放在顶部。如果您目前正使用相同策略编写 Electron 应用程序，并且正在使用您不需要立即使用的大型模块，请应用相同的策略，将加载推迟到更合适的时机。

为什么？

加载模块是一项出乎意料地昂贵操作，尤其是在 Windows 上。当您的应用程序启动时，它不应该让用户等待当前不必要的操作。

这可能看起来很明显，但许多应用程序在启动后往往会立即执行大量工作——比如检查更新、下载后续流程中使用的内容或执行繁重的磁盘 I/O 操作。

以 Visual Studio Code 为例。当您打开一个文件时，它会立即显示文件内容给您，不进行任何代码高亮，优先确保您可以与文本进行交互。完成这项工作后，它才会进行代码高亮。

如何做？

我们来考虑一个例子，假设您的应用程序正在解析虚构的 .foo 格式文件。为此，它依赖于同样虚构的 foo-parser 模块。在传统的 Node.js 开发中，您可能会编写急切加载依赖项的代码

parser.js

const fs = require('node:fs')
const fooParser = require('foo-parser')

class Parser {
  constructor () {
    this.files = fs.readdirSync('.')
  }

  getParsedFiles () {
    return fooParser.parse(this.files)
  }
}

const parser = new Parser()

module.exports = { parser }

在上述示例中，我们正在执行大量在文件加载后立即运行的工作。我们是否需要立即获取已解析的文件？我们是否可以在 getParsedFiles() 实际被调用时稍后执行这项工作？

parser.js

// "fs" is likely already being loaded, so the `require()` call is cheap
const fs = require('node:fs')

class Parser {
  async getFiles () {
    // Touch the disk as soon as `getFiles` is called, not sooner.
    // Also, ensure that we're not blocking other operations by using
    // the asynchronous version.
    this.files = this.files || await fs.promises.readdir('.')

    return this.files
  }

  async getParsedFiles () {
    // Our fictitious foo-parser is a big and expensive module to load, so
    // defer that work until we actually need to parse files.
    // Since `require()` comes with a module cache, the `require()` call
    // will only be expensive once - subsequent calls of `getParsedFiles()`
    // will be faster.
    const fooParser = require('foo-parser')
    const files = await this.getFiles()

    return fooParser.parse(files)
  }
}

// This operation is now a lot cheaper than in our previous example
const parser = new Parser()

module.exports = { parser }

简而言之，应“即时”分配资源，而不是在应用程序启动时全部分配。

3. 阻塞主进程

Electron 的主进程（有时称为“浏览器进程”）是特殊的：它是应用程序所有其他进程的父进程，也是操作系统与之交互的主要进程。它处理窗口、交互以及应用程序内部各个组件之间的通信。它也承载着 UI 线程。

在任何情况下，都不应使用长时间运行的操作来阻塞此进程和 UI 线程。阻塞 UI 线程意味着您的整个应用程序将冻结，直到主进程准备好继续处理。

为什么？

主进程及其 UI 线程本质上是应用程序内部主要操作的控制中心。当操作系统告诉您的应用程序鼠标点击事件时，它会先经过主进程，然后才到达您的窗口。如果您的窗口正在渲染流畅的动画，它需要与 GPU 进程进行通信——这同样会再次经过主进程。

Electron 和 Chromium 都非常小心地将繁重的磁盘 I/O 和 CPU 密集型操作放到新的线程中，以避免阻塞 UI 线程。您也应该这样做。

如何做？

Electron 强大的多进程架构随时可以帮助您处理长时间运行的任务，但其中也包含一些性能陷阱。

1. 对于长时间运行的 CPU 密集型任务，请利用 工作线程 (worker threads)，考虑将它们移至 BrowserWindow，或（作为最后手段）生成一个专用进程。

2. 尽可能避免使用同步 IPC 和 @electron/remote 模块。尽管存在合法的用例，但太容易在不知不觉中阻塞 UI 线程。

3. 避免在主进程中使用阻塞 I/O 操作。简而言之，只要核心 Node.js 模块（如 fs 或 child_process）提供同步或异步版本时，您都应该首选异步和非阻塞版本。

4. 阻塞渲染器进程

由于 Electron 随附了最新版本的 Chrome，您可以利用 Web 平台提供的最新最佳功能来推迟或卸载繁重操作，从而使您的应用程序保持流畅和响应。

为什么？

您的应用程序可能在渲染器进程中有大量 JavaScript 代码需要运行。关键在于尽可能快地执行操作，同时不占用保持滚动流畅、响应用户输入或实现 60fps 动画所需的资源。

如果用户抱怨您的应用程序有时“卡顿”，那么协调渲染器代码中的操作流程会特别有用。

如何做？

一般来说，所有关于为现代浏览器构建高性能 Web 应用程序的建议也适用于 Electron 的渲染器。您目前可以利用的两个主要工具是 requestIdleCallback() 用于小型操作，以及 Web Workers 用于长时间运行的操作。

requestIdleCallback() 允许开发者将一个函数排队，一旦进程进入空闲期就立即执行。它使您能够在不影响用户体验的情况下执行低优先级或后台工作。有关如何使用它的更多信息，请查看其在 MDN 上的文档。

Web Workers 是在单独线程上运行代码的强大工具。有一些注意事项需要考虑——请查阅 Electron 的多线程文档和Web Workers 的 MDN 文档。对于任何需要长时间大量 CPU 运算的操作，它们都是理想的解决方案。

5. 不必要的 polyfill

Electron 的一大优势在于您确切知道哪个引擎将解析您的 JavaScript、HTML 和 CSS。如果您正在重新利用为通用 Web 编写的代码，请确保不要对 Electron 中已包含的功能进行 polyfill。

为什么？

在为当今互联网构建 Web 应用程序时，最旧的环境决定了您可以使用和不能使用哪些功能。尽管 Electron 支持表现良好的 CSS 滤镜和动画，但较旧的浏览器可能不支持。在您可以使用 WebGL 的地方，您的开发者可能为了支持旧手机而选择了更耗资源的解决方案。

至于 JavaScript，您可能已经包含了像 jQuery 这样的工具库用于 DOM 选择器，或者像 regenerator-runtime 这样的 polyfill 来支持 async/await。

基于 JavaScript 的 polyfill 很少会比 Electron 中等效的原生功能更快。不要通过发布您自己的标准 Web 平台功能版本来减慢您的 Electron 应用程序。

如何做？

假设当前版本的 Electron 中的 polyfill 是不必要的。如果您有疑问，请访问 caniuse.com 并检查您的 Electron 版本中使用的 Chromium 版本是否支持您需要的功能。

此外，仔细检查您使用的库。它们真的必要吗？例如，jQuery 如此成功，以至于它的许多功能现在已成为标准 JavaScript 可用功能集的一部分。

如果您正在使用像 TypeScript 这样的转译器/编译器，请检查其配置，并确保您正在 targeting Electron 支持的最新 ECMAScript 版本。

6. 不必要的或阻塞的网络请求

如果很少变化的资源可以轻松地与您的应用程序打包在一起，请避免从互联网上获取它们。

为什么？

许多 Electron 用户从一个完全基于 Web 的应用程序开始，然后将其转换为桌面应用程序。作为 Web 开发者，我们习惯于从各种内容分发网络加载资源。现在您正在发布一个成熟的桌面应用程序，请尽可能尝试“剪断脐带”，避免让用户等待那些永不改变且可以轻松包含在您的应用程序中的资源。

一个典型的例子是 Google Fonts。许多开发者利用 Google 庞大的免费字体库，它附带内容分发网络。其理念很简单：包含几行 CSS，Google 就会处理其余部分。

在构建 Electron 应用程序时，如果您下载字体并将其包含在应用程序的包中，您的用户将获得更好的体验。

如何做？

在理想情况下，您的应用程序根本不需要网络即可运行。要实现这一点，您必须了解您的应用程序正在下载哪些资源——以及这些资源有多大。

为此，请打开开发者工具。导航到 Network 选项卡并勾选 Disable cache 选项。然后，重新加载您的渲染器。除非您的应用程序禁止此类重新加载，否则通常在开发者工具处于焦点状态时，按下 Cmd + R 或 Ctrl + R 即可触发重新加载。

现在，工具将详细记录所有网络请求。首先，统计所有正在下载的资源，重点关注较大的文件。其中是否有不会改变的图片、字体或媒体文件，并且可以包含在您的打包中？如果有，请将其包含在内。

下一步，启用 Network Throttling（网络限速）。找到当前显示 Online 的下拉菜单，并选择一个较慢的速度，例如 Fast 3G。重新加载您的渲染器，看看您的应用程序是否有不必要的等待资源。在许多情况下，应用程序会等待网络请求完成，尽管它实际上并不需要所涉及的资源。

一个提示是，从互联网加载您可能想要更改而无需发布应用程序更新的资源，这是一种强大的策略。为了更高级地控制资源的加载方式，请考虑投入使用 Service Workers。

7. 打包您的代码

正如在“过早加载和运行代码”中已经指出的，调用 require() 是一项昂贵的操作。如果可能的话，将您的应用程序代码打包成一个单独的文件。

为什么？

现代 JavaScript 开发通常涉及许多文件和模块。虽然这对于使用 Electron 开发来说完全没问题，但我们强烈建议您将所有代码打包到一个单独的文件中，以确保调用 require() 所产生的开销只在应用程序加载时支付一次。

如何做？

市面上有许多 JavaScript 打包工具，我们深知不应通过推荐某个工具而惹恼社区。然而，我们确实建议您使用能够处理 Electron 独特环境的打包工具，该环境需要同时处理 Node.js 和浏览器环境。

在撰写本文时，流行的选择包括 Webpack、Parcel 和 rollup.js。

8. 当您不需要默认菜单时，调用 Menu.setApplicationMenu(null)

Electron 在启动时会设置一个包含一些标准条目的默认菜单。但您的应用程序可能需要更改它，并且这样做将有益于启动性能。

为什么？

如果您构建自己的菜单或使用没有原生菜单的无边框窗口，您应该尽早告诉 Electron 不要设置默认菜单。

如何做？

在 app.on("ready") 之前调用 Menu.setApplicationMenu(null)。这将阻止 Electron 设置默认菜单。另请参阅 https://github.com/electron/electron/issues/35512 以获取相关讨论。