Electron 16.0.0 已发布！它包含了对 Chromium 96、V8 9.6 和 Node.js 16.9.1 的升级。请阅读下文了解更多详情！

Electron 团队很高兴宣布发布 Electron 16.0.0！您可以通过 npm 使用 npm install electron@latest 进行安装，或从我们的版本发布网站下载。请继续阅读以了解此版本的详情，并请分享您的任何反馈！

值得注意的变化​

Electron 发布节奏变更​

自 Electron 15 起，Electron 将每 8 周发布一个新的稳定主版本。您可以在此处阅读完整详情。

此外，Electron 已将支持版本从最新的三个版本更改为最新的四个版本，直至 2022 年 5 月。有关 Electron 版本控制的更多详细信息，请参阅我们的版本控制文档。2022 年 5 月之后，我们将恢复支持最新的三个版本。

堆栈变更​

• Chromium 96
  • Chrome 96 新功能
• Node.js 16.9.1
  • Node 16.9.1 博客文章
• V8 9.6
  • V8 9.6 博客文章

亮点特性​

• 现在支持 WebHID API。#30213
• 为 app.requestSingleInstanceLock 添加 data 参数，用于在实例之间共享数据。#30891
• 将 securityOrigin 传递给媒体权限请求处理程序。#31357
• 添加 commandLine.removeSwitch。#30933

有关新特性和变更的完整列表，请参阅16.0.0 发布说明。

重大变更​

以下是 Electron 16 中引入的重大变更。有关这些以及未来变更的更多信息，请访问计划中的重大变更页面。

构建原生模块​

如果您的项目使用 node-gyp 构建原生模块，您可能需要根据您的项目设置和 Electron 版本，使用 --force-process-config 调用它。有关此变更的更多信息，请访问#2497。

行为变更：Linux 上 crashReporter 实现已切换到 Crashpad​

Linux 上 crashReporter API 的底层实现已从 Breakpad 更改为 Crashpad，使其与 Windows 和 Mac 对齐。因此，子进程现在会自动受到监控，并且在 Node 子进程中调用 process.crashReporter.start 不再需要（也不建议，因为它将启动第二个 Crashpad 报告程序实例）。

注释在 Linux 上的报告方式也有一些细微变化，包括长值将不再分割到附带 __1、__2 等后缀的注释之间，而是会截断到（新的、更长的）注释值限制处。

API 变更​

Electron 16 中没有 API 变更。

移除/弃用变更​

• 在渲染进程中使用 desktopCapturer.getSources API 已被弃用，并将被移除。此变更提高了 Electron 应用程序的默认安全性。有关如何在您的应用程序中替换此 API 的详细信息，请参阅此处。

停止支持 12.x.y​

根据项目的支持策略，Electron 12.x.y 已达到支持结束。鼓励开发者和应用程序升级到更新的 Electron 版本。

自 Electron 15 起，我们将支持版本从最新的三个版本更改为最新的四个版本，直至 Electron 19（2022 年 5 月）。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持变更作为我们新的发布节奏变更的一部分。请参阅我们的博客文章以获取完整详情。

下一步计划​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。尽管我们谨慎地不对发布日期做出承诺，但我们的计划是大约每 2 个月发布一个新的 Electron 主版本，其中包含这些组件的新版本。

您可以在此处找到 Electron 的公开时间线。

有关未来变更的更多信息，请访问计划中的重大变更页面。

Electron 项目将在 2021 年 12 月暂停，然后在 2022 年 1 月恢复全速运行。

来自 GIPHY

十二月保持不变的内容​

1. 零日漏洞和其他主要安全相关版本将按需发布。应通过 SECURITY.md 报告安全事件。
2. 行为准则报告和审核将继续进行。

十二月将有何不同​

1. 十二月没有新的 Beta 或 Stable 版本发布。十二月的最后两周没有 Nightly 版本发布。
2. 除少数例外，不进行拉取请求审核或合并。
3. 任何仓库上都不进行问题跟踪器更新。
4. 维护者不提供 Discord 调试帮助。
5. 不更新社交媒体内容。

为何如此？​

简而言之，虽然维护者对项目感到高兴并积极参与，但世界是疲惫的。十二月是大多数公司的安静月份，因此我们希望给维护者一个充电的机会。我们鼓励其他项目考虑类似的措施。

我应该担心 Electron 的未来吗？​

不。我们之所以能够采取这一措施，是因为项目状况良好。每个人都期待 2022 年，我们预计会有好事发生！

Electron 15.0.0 已发布！它包含了对 Chromium 94、V8 9.4 和 Node.js 16.5.0 的升级。我们添加了 window.open 的 API 更新、错误修复和常规改进。请阅读下文了解更多详情！

Electron 团队很高兴宣布发布 Electron 15.0.0！您可以通过 npm 使用 npm install electron@latest 进行安装，或从我们的版本发布网站下载。请继续阅读以了解此版本的详情，并请分享您的任何反馈！

值得注意的变化​

Electron 发布节奏变更​

从 Electron 15 开始，Electron 将每 8 周发布一个新的稳定主版本。您可以在此处阅读完整详情。

此外，Electron 将支持版本从最新的三个版本更改为最新的四个版本，直至 2022 年 5 月。参阅我们的版本控制文档，了解 Electron 版本控制的更多详细信息。

堆栈变更​

• Chromium 94
  • Chrome 94 新功能
• Node.js 16.5.0
  • Node 16.5.0 博客文章
• V8 9.4
  • V8 9.4 博客文章

亮点特性​

• nativeWindowOpen: true 不再是实验性功能，现在是默认设置。
• 添加了 safeStorage 字符串加密 API。#30430
• 为 WebContents 添加了 'frame-created' 事件，当页面中创建帧时触发。#30801
• 为 BrowserWindow 的 will-resize 事件添加了 resize edge 信息。#29199

有关新特性和变更的完整列表，请参阅15.0.0 发布说明。

重大变更​

以下是 Electron 15 中引入的重大变更。有关这些以及未来变更的更多信息，请访问计划中的重大变更页面。

默认变更：nativeWindowOpen 默认为 true​

在 Electron 15 之前，window.open 默认被垫片化以使用 BrowserWindowProxy。这意味着 window.open('about:blank') 无法用于打开可同步脚本化的子窗口，此外还有其他不兼容性。nativeWindowOpen: true 不再是实验性功能，现在是默认设置。

有关 Electron 中 window.open 的更多详细信息，请参阅文档。

API 变更​

• 为 WebContents 添加了 'frame-created' 事件，当页面中创建帧时触发。#30801
• 添加了 safeStorage 字符串加密 API。#30430
• 为 dialog.showMessageBox 添加了 signal 选项。#26102
• 添加了一个 Electron Fuse，用于在应用程序加载的 app.asar 文件上强制执行代码签名。需要最新的 asar 模块（v3.1.0 或更高版本）。#30900
• 添加了 fuses 以禁用打包应用中的 NODE_OPTIONS 和 --inspect 调试参数。#30420
• 添加了新的 MenuItem.userAccelerator 属性，用于读取用户分配的 macOS 加速器覆盖。#26682
• 添加了新的 app.runningUnderARM64Translation 属性，用于检测在 Apple Silicon 上的 Rosetta 或 Windows on ARM 上的 WOW 环境下运行时。#29168
• 添加了新的 imageAnimationPolicy web preference，用于控制图像的动画方式。#29095
• 添加了对通过上下文桥发送 Blobs 的支持。#29247

移除/弃用变更​

没有 API 被移除或弃用。

支持的版本​

从 Electron 15 开始，我们将支持版本从最新的三个版本更改为最新的四个版本，直至 Electron 19（2022 年 5 月）。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持变更作为我们新的发布节奏变更的一部分。请参阅我们的博客文章以获取完整详情。

鼓励开发者和应用程序升级到更新的 Electron 版本。

下一步计划​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。尽管我们谨慎地不对发布日期做出承诺，但我们的计划是大约每季度发布一个新的 Electron 主版本，其中包含这些组件的新版本。

您可以在此处找到 Electron 的公开时间线。

有关未来变更的更多信息，请访问计划中的重大变更页面。

Electron 14.0.0 已发布！它包含了对 Chromium 93 和 V8 9.3 的升级。我们添加了多项 API 更新、错误修复和常规改进。请阅读下文了解更多详情！

Electron 团队很高兴宣布发布 Electron 14.0.0！您可以通过 npm 使用 npm install electron@latest 进行安装，或从我们的版本发布网站下载。请继续阅读以了解此版本的详情，并请分享您的任何反馈！

值得注意的变化​

Electron 发布节奏变更​

从 2021 年 9 月 Electron 15 开始，Electron 将每 8 周发布一个新的稳定主版本。您可以在此处阅读完整详情。Electron 15 的 Beta 版本将于 2021 年 9 月 1 日开始，稳定版本将于 2021 年 9 月 21 日发布。您可以在此处找到 Electron 的公开时间线。此外，Electron 将支持版本从最新的三个版本更改为最新的四个版本，直至 2022 年 5 月。请参阅我们的版本控制文档，了解 Electron 版本控制的更多详细信息。

堆栈变更​

• Chromium 93
  • Chrome 93 新功能
  • Chrome 92 新功能
• Node.js 14.17.0
  • Node 14.17.0 博客文章
• V8 9.3
  • V8 9.3 博客文章
  • V8 9.2 博客文章

亮点特性​

• 默认变更：nativeWindowOpen 现在默认为 true。（参见文档）
• 子窗口不再继承其父窗口的 BrowserWindow 构造选项。#28550
• 添加了新的 session.storagePath API，用于获取会话特定数据在磁盘上的路径。#28665
• 添加了由 @electron/remote 使用的 process.contextId。#28007
• 在 Electron Fuse 后面添加了实验性的 cookie 加密支持。#29492

有关新特性和变更的完整列表，请参阅14.0.0 发布说明。

重大变更​

以下是 Electron 14 中引入的重大变更。有关这些以及未来变更的更多信息，请访问计划中的重大变更页面。

已移除：app.allowRendererProcessReuse​

app.allowRendererProcessReuse 属性已被移除，作为我们更紧密地与 Chromium 进程模型对齐（为了安全、性能和可维护性）计划的一部分。

有关更多详细信息，请参见#18397。

已移除：Browser Window Affinity​

在构造新的 BrowserWindow 时，affinity 选项已被移除，作为我们更紧密地与 Chromium 进程模型对齐（为了安全、性能和可维护性）计划的一部分。

有关更多详细信息，请参见#18397。

API 变更：window.open()​

可选参数 frameName 不再设置窗口的标题。此行为现在遵循 原生文档 中描述的 windowName 参数规范。

如果您曾使用此参数设置窗口标题，现在可以使用 win.setTitle(title) 方法代替。

已移除：worldSafeExecuteJavaScript​

worldSafeExecuteJavaScript 已被移除，没有替代方案。请确保您的代码在此属性启用时能够正常工作。自 Electron 12 起，此属性默认已启用。

如果您使用 webFrame.executeJavaScript 或 webFrame.executeJavaScriptInIsolatedWorld，您将受到此变更的影响。由于这些方法使用相同的值传递语义，您需要确保这些方法返回的值受 Context Bridge API 支持。

默认变更：nativeWindowOpen 默认为 true​

在 Electron 14 之前，window.open 默认被垫片化以使用 BrowserWindowProxy。这意味着 window.open('about:blank') 无法用于打开可同步脚本化的子窗口，此外还有其他不兼容性。nativeWindowOpen 不再是实验性功能，现在是默认设置。

有关 Electron 中 window.open 的更多详细信息，请参阅文档。

已移除：BrowserWindowConstructorOptions 继承父窗口设置​

在 Electron 14 之前，通过 window.open 打开的窗口会从其父窗口继承 BrowserWindow 构造选项，例如 transparent 和 resizable。从 Electron 14 开始，此行为已被移除，窗口将不再继承其父窗口的任何 BrowserWindow 构造选项。

改为使用 setWindowOpenHandler 显式设置新窗口的选项

webContents.setWindowOpenHandler((details) => {
  return {
    action: 'allow',
    overrideBrowserWindowOptions: {
      // ...
    },
  };
});

已移除：additionalFeatures​

WebContents 的 new-window 和 did-create-window 事件中已弃用的 additionalFeatures 属性已被移除。由于 new-window 使用位置参数，该参数仍然存在，但将始终为空数组 []。（注意：new-window 事件本身已被弃用，并已替换为 setWindowOpenHandler。）窗口特性中的裸键现在在选项对象中将作为值为 true 的键呈现。

// Removed in Electron 14
// Triggered by window.open('...', '', 'my-key')
webContents.on('did-create-window', (window, details) => {
  if (details.additionalFeatures.includes('my-key')) {
    // ...
  }
});

// Replace with
webContents.on('did-create-window', (window, details) => {
  if (details.options['my-key']) {
    // ...
  }
});

已移除：remote 模块​

在 Electron 12 中被弃用，remote 模块现已从 Electron 本身中移除，并提取到一个单独的包，@electron/remote。@electron/remote 模块将主进程中的 JavaScript 对象桥接到渲染进程。这使您可以像在渲染进程中一样访问仅主进程对象。这是 remote 模块的直接替代品。有关迁移说明和参考，请参阅该模块的 readme。

API 变更​

• 添加了 BrowserWindow.isFocusable() 方法，用于确定窗口是否可聚焦。#28642
• 添加了 WebFrameMain.visibilityState 实例属性。#28706
• 为注册了 setWindowOpenHandler 的窗口打开处理程序传递的详细信息对象中添加了 disposition、referrer 和 postBody。#28518
• 添加了由 @electron/remote 使用的 process.contextId。#28007
• 在 Electron Fuse 后面添加了实验性的 cookie 加密支持。#29492
• 为 webRequest 监听器详细信息添加了缺失的 resourceType 转换：font、ping、cspReport、media、webSocket。#30050
• 添加了新的 session.storagePath API，用于获取会话特定数据在磁盘上的路径。#28665
• 添加了对 macOS 上 Windows Control Overlay 的支持。#29986
• 添加了对使用 --log-file=.../path/to/file.log 将 Chromium 日志记录到文件的支持。此外，现在可以通过在第一个 JS 滴答期间附加命令行开关来从 JavaScript 启用日志记录。#29963
• 在 node crypto 中添加了对 des-ede3 加密算法的支持。#27897
• 添加了 ContextBridgeMutability 功能，允许上下文桥对象可变。#27348

移除/弃用变更​

以下 API 已被移除或现已被弃用

• remote 模块在 Electron 12 中被弃用后，现已移除。#25734
• 子窗口不再继承其父窗口的 BrowserWindow 构造选项。#28550
• 移除了 new-window 和 did-create-window WebContents 事件中已弃用的 additionalFeatures 属性。#28548
• 移除了已弃用的 app.allowRendererProcessReuse 和 BrowserWindow affinity 选项。#26874
• 当 uploadToServer 为 false 时，crashReporter.start 的 submitURL 选项不再是必需参数。#28105

停止支持 11.x.y​

根据项目的支持策略，Electron 11.x.y 已达到支持结束。鼓励开发者和应用程序升级到更新的 Electron 版本。

下一步计划​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。尽管我们谨慎地不对发布日期做出承诺，但我们的计划是大约每季度发布一个新的 Electron 主版本，其中包含这些组件的新版本。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的计划中的重大变更。

在过去几周，我们收到了几个关于新的 WebView2 和 Electron 之间区别的问题。

两个团队都有明确的目标，即让 web 技术在桌面端发挥最佳作用，并且正在讨论进行一次全面的比较。

Electron 和 WebView2 都是快速发展且不断演进的项目。我们整理了一份关于 Electron 和 WebView2 当前相似点和不同点的简要概述。

架构概述​

Electron 和 WebView2 都基于 Chromium 源代码构建，用于渲染 web 内容。严格来说，WebView2 是基于 Edge 源代码构建的，但 Edge 是使用 Chromium 源代码的一个分支构建的。Electron 不与 Chrome 共享任何 DLL。WebView2 二进制文件硬链接到 Edge（截至 Edge 90 的 Stable 通道），因此它们共享磁盘空间和一些工作集。有关更多信息，请参阅常青分发模式。

Electron 应用程序总是打包并分发开发时使用的精确 Electron 版本。WebView2 有两种分发选项。您可以打包应用程序开发时使用的精确 WebView2 库，或者您可以使用系统上可能已有的共享运行时版本。WebView2 为每种方法提供了工具，包括在共享运行时缺失情况下的引导安装程序。从 Windows 11 开始，WebView2 会随系统内置。

捆绑其框架的应用程序负责更新这些框架，包括次要的安全发布。对于使用共享 WebView2 运行时的应用程序，WebView2 有自己的更新程序，类似于 Chrome 或 Edge，它独立于您的应用程序运行。更新应用程序的代码或其任何其他依赖项仍然是开发者的责任，这与 Electron 相同。Electron 和 WebView2 都不由 Windows Update 管理。

Electron 和 WebView2 都继承了 Chromium 的多进程架构——即一个主进程与一个或多个渲染进程通信。这些进程完全独立于系统上运行的其他应用程序。每个 Electron 应用程序都是一个独立的进程树，包含一个根浏览器进程、一些实用进程以及零个或多个渲染进程。使用相同用户数据文件夹的 WebView2 应用程序（就像一组应用程序那样）会共享非渲染进程。使用不同数据文件夹的 WebView2 应用程序不共享进程。

• ElectronJS 进程模型

  

• 基于 WebView2 的应用程序进程模型

  

在此处阅读有关 WebView2 进程模型 和 Electron 进程模型 的更多信息。

Electron 提供适用于常见桌面应用程序需求的 API，例如菜单、文件系统访问、通知等。WebView2 是一个旨在集成到 WinForms、WPF、WinUI 或 Win32 等应用程序框架中的组件。WebView2 不通过 JavaScript 提供 Web 标准之外的操作系统 API。

Node.js 集成在 Electron 中。Electron 应用程序可以在渲染进程和主进程中使用任何 Node.js API、模块或 Node 原生插件。WebView2 应用程序不假定应用程序的其余部分使用何种语言或框架编写。您的 JavaScript 代码必须通过应用程序宿主进程代理任何操作系统访问。

Electron 努力保持与 Web API 的兼容性，包括从 Fugu 项目开发的 API。我们提供了 Electron 的 Fugu API 兼容性快照。WebView2 维护着一份类似的 与 Edge 的 API 差异 列表。

Electron 为 Web 内容提供了可配置的安全模型，从完全访问到完全沙箱。WebView2 内容始终是沙箱化的。Electron 提供了关于选择安全模型的 全面安全文档。WebView2 也有 安全最佳实践。

Electron 源代码在 GitHub 上维护并可用。应用程序可以修改并构建自己的 Electron 版本。WebView2 源代码在 GitHub 上不可用。

快速摘要

性能讨论​

在渲染您的 Web 内容方面，我们预计 Electron、WebView2 和任何其他基于 Chromium 的渲染器之间性能差异很小。对于有兴趣研究潜在性能差异的人，我们创建了使用 Electron、C++ + WebView2 和 C# + WebView2 构建应用程序的脚手架。

在渲染 Web 内容之外，还存在一些差异，Electron、WebView2、Edge 及其他相关人员已表示有兴趣进行详细比较，包括 PWAs。

进程间通信 (IPC)​

我们想立即强调一个差异，因为我们认为这在 Electron 应用程序中通常是性能考虑因素。

在 Chromium 中，浏览器进程充当沙箱化渲染器与系统其余部分之间的 IPC 代理。虽然 Electron 允许非沙箱化的渲染进程，但许多应用程序选择启用沙箱以增强安全性。WebView2 始终启用沙箱，因此对于大多数 Electron 和 WebView2 应用程序而言，IPC 会影响整体性能。

尽管 Electron 和 WebView2 的进程模型相似，但底层 IPC 不同。JavaScript 与 C++ 或 C# 之间的通信需要封送处理，最常见的是封送到 JSON 字符串。JSON 序列化/解析是一个昂贵的操作，IPC 瓶颈会负面影响性能。从 Edge 93 开始，WV2 将对网络事件使用CBOR。

Electron 通过 MessagePorts API 支持任意两个进程之间的直接 IPC，该 API 利用了结构化克隆算法。利用此特性的应用程序可以在进程间发送对象时避免支付 JSON 序列化开销。

总结​

Electron 和 WebView2 有许多不同之处，但在渲染 Web 内容的性能方面预计不会有太大差异。最终，应用程序的架构和 JavaScript 库/框架对内存和性能的影响比其他任何因素都要大，因为无论在哪里运行，Chromium 就是 Chromium。

特别感谢 WebView2 团队审阅此文，并确保我们对 WebView2 架构有最新的了解。他们欢迎对该项目提出任何反馈意见。

从 2021 年 9 月开始，Electron 将每 8 周发布一个主要的稳定版本。

在 2019 年，Electron 改用 12 周的发布周期，以匹配 Chromium 的 6 周发布周期。最近，Chrome 和 Microsoft 都宣布了一些更改，这促使我们重新考虑 Electron 当前的发布节奏。

1. Chromium 计划从 2021 年 9 月 21 日发布的 Chrome 94 开始，每 4 周 发布一个新的里程碑版本。这种发布节奏还会每 8 周增加一个新的 Extended Stable（扩展稳定）选项，其中包含所有最新的安全修复。

2. Microsoft Store 将要求基于 Chromium 的应用程序的版本不低于最新发布的两个主要版本以内。例如，如果 Chromium 最新发布的主要版本是 85，则任何基于 Chromium 的浏览器必须至少是 Chromium 版本 83 或更高版本。此规则包括 Electron 应用程序。

从 2021 年 9 月开始，Electron 将每 8 周发布一个主要的稳定版本，以匹配 Chromium 每 8 周发布的 Extended Stable 版本。

我们第一个包含 Chromium Extended Stable 的版本将是 Electron 15，发布日期为 2021 年 9 月 21 日。

由于知道发布节奏的改变会影响下游应用程序，我们希望尽快通知我们的开发者社区。请继续阅读，了解我们 2021 年发布计划的更多详情。

Electron 15：临时 Alpha 版本​

考虑到我们最初的 Electron 15 版本目标是一个非 Extended Stable 版本（Chromium 的 Extended Stable 版本基于其偶数版本），我们需要更改我们最初的目标发布日期。然而，Electron 应用程序必须使用最新的两个 Chromium 主要版本才能被 Microsoft Store 接受，这使得等待两个 Chromium 版本变得无法接受。

面对这两个要求，我们的团队面临着时间困境。将 Electron 15 调整为包含 Chromium M94 将允许应用程序开发者使用 Chromium 的第一个 Extended Stable 版本；但是，这也会将 Beta 到 Stable 的周期缩短到只有 3 周。

为了帮助完成这一过渡，Electron 将提供一个临时性的 Alpha 构建版本，仅限于 Electron 15 的发布。这个 Alpha 构建版本将为开发者提供更多时间来测试和规划 Electron 15 的发布，其稳定性将高于我们当前的 nightly 版本。

Electron 15 的 Alpha 通道构建版本将于 2021 年 7 月 20 日 发布。它将于 2021 年 9 月 1 日 过渡到 Beta 版本，目标稳定版发布日期为 2021 年 9 月 21 日。后续的 Electron 版本将不再有 Alpha 版本。

2021 年发布计划​

以下是我们的 2021 年当前发布计划

增加 Alpha 通道将 Electron 15 发布前的开发时间从 3 周延长到 9 周，这更接近我们新的 8 周周期，同时仍然满足 Windows Store 提交的要求。

为了进一步帮助应用程序开发者，从 2021 年剩余时间到 2022 年 5 月，我们还将把支持版本政策从最新的 3 个版本扩展到最新的 4 个 Electron 版本。 这意味着即使您无法立即更改升级计划，旧版本的 Electron 仍将获得安全更新和修复。

解决担忧​

我们提早发布此文是有原因的，远早于此发布周期变更计划的安排。我们知道，更快的发布周期将对 Electron 应用程序产生实际影响——其中一些应用程序可能已经觉得我们主要版本的发布节奏很快了。

我们已尝试在下面解决一些常见担忧

❓ 为什么要做这个改变？为什么不保留 12 周的发布节奏？​

为了在 Electron 中提供最新版本的 Chromium，我们的计划需要跟踪他们的计划。有关 Chromium 发布周期的更多信息，请参见此处。

此外，当前的 12 周发布节奏无法满足 Microsoft Store 的新提交要求。即使是使用最新稳定版 Electron 的应用程序，也可能会在新安全要求下经历大约两周的被拒绝期。

每个新的 Chromium 版本都包含新功能、错误修复/安全修复以及 V8 改进。我们希望您作为应用程序开发者能够及时获得这些更改，因此我们的稳定版发布日期将继续与 Chromium 的其他稳定版发布日期相匹配。作为应用程序开发者，您将比以往更快地获得新的 Chromium 和 V8 功能和修复。

❓ 现有的 12 周发布计划已经很快了。团队正在采取哪些措施来简化升级？​

更频繁发布的一个优势是发布版本会更小。我们理解升级 Electron 的主要版本可能很困难。我们希望较小的发布版本每次引入的主要 Chromium 和 Node 更改以及破坏性更改会更少。

❓ 未来 Electron 版本是否会有 Alpha 版本可用？​

目前没有支持永久 Alpha 版本的计划。此 Alpha 版本仅适用于 Electron 15，旨在帮助开发者在缩短的发布周期内更轻松地升级。

❓ Electron 会延长支持的版本数量吗？​

我们将把支持版本政策从最新的三个版本扩展到最新的四个 Electron 版本，直到 2022 年 5 月 Electron 19 发布为止。Electron 19 发布后，我们将恢复支持最新的三个主要版本，以及 Beta 和 nightly 版本。

有疑问？​

📨 如果您有疑问或担忧，请发送邮件至 info@electronjs.org 或加入我们的 Discord。我们知道这是一个会影响许多应用程序和开发者的改变，您的反馈对我们非常重要。我们期待您的来信！

Electron 13.0.0 已发布！它包含对 Chromium 91 和 V8 9.1 的升级。我们还添加了一些 API 更新、错误修复和常规改进。请阅读下文了解更多详情！

Electron 团队激动地宣布 Electron 13.0.0 发布！您可以使用 npm 通过 npm install electron@latest 安装，或从我们的发布网站下载。请继续阅读以了解此版本的详细信息，并欢迎提供您的任何反馈！

值得注意的变化​

堆栈变更​

• Chromium 91
  • Chrome 91 中的新特性
  • Chrome 90 中的新特性
• Node.js 14.16.0
  • Node 14.16.0 博客文章
  • Node 14.0.0 博客文章
• V8 9.1
  • V8 9.1 博客文章
  • V8 9.0 博客文章

亮点特性​

• 添加了 process.contextIsolated 属性，指示当前渲染器上下文是否已启用 contextIsolation。#28252
• 添加了新的 session.storagePath API，用于获取磁盘上存储 session 特定数据的路径。#28866
• WebContents 的 new-window 事件已弃用。它被 webContents.setWindowOpenHandler() 取代。
• 添加了 @electron/remote 使用的 process.contextId。#28251

请参阅13.0.0 版本说明，查看新功能和更改的完整列表。

重大变更​

• window.open() 参数 frameName 不再设置为窗口标题。#27481
• 更改了 session.setPermissionCheckHandler(handler)，允许 handler 的第一个参数 webContents 为 null。#19903

有关这些更改和未来更改的更多信息，请参阅计划中的破坏性更改页面。

API 变更​

• 为 BrowserWindow 添加了 roundedCorners 选项。#27572
• 添加了新的 session.storagePath API，用于获取磁盘上存储 session 特定数据的路径。28866
• 添加了通过上下文桥传递 DOM 元素的支持。#26776
• 为沙箱化渲染器添加了 process.uptime()。#26684
• 为 context-menu 事件作为参数发出的对象添加了缺失的字段。#26788
• 添加了注册 Manifest V3 扩展服务工作者的支持。
• 为 ServiceWorkers 添加了 'registration-completed' 事件。#27562

移除/弃用变更​

以下 API 已被移除或现已被弃用

• WebContents 的 new-window 事件已弃用。它被 webContents.setWindowOpenHandler() 取代。

• 移除了弃用的 shell.moveItemToTrash()。#26723

• 移除了以下弃用的 BrowserWindow 扩展 API

  • BrowserWindow.addExtension(path)
  • BrowserWindow.addDevToolsExtension(path)
  • BrowserWindow.removeExtension(name)
  • BrowserWindow.removeDevToolsExtension(name)
  • BrowserWindow.getExtensions()
  • BrowserWindow.getDevToolsExtensions()

  请改用 session API

  • ses.loadExtension(path)
  • ses.removeExtension(extension_id)
  • ses.getAllExtensions()

• 以下 systemPreferences 方法已弃用

  • systemPreferences.isDarkMode()
  • systemPreferences.isInvertedColorScheme()
  • systemPreferences.isHighContrastColorScheme()

  请改用以下 nativeTheme 属性

  • nativeTheme.shouldUseDarkColors
  • nativeTheme.shouldUseInvertedColorScheme
  • nativeTheme.shouldUseHighContrastColors

10.x.y 版本停止支持​

根据项目的支持政策，Electron 10.x.y 已停止支持。建议开发者和应用程序升级到更新版本的 Electron。

下一步计划​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。虽然我们谨慎地不对发布日期作出承诺，但我们的计划是大约每季度发布一个包含这些新组件的新主要版本 Electron。Electron 14.0 的初步时间表列出了 Electron 14.0 开发生命周期中的关键日期。另外，请参阅我们的版本控制文档，了解有关 Electron 版本控制的更详细信息。

有关即将发布的 Electron 版本中计划的破坏性更改的信息，请参阅我们的计划中的破坏性更改文档。

Electron 12.0.0 已发布！它包含对 Chromium 89、V8 8.9 和 Node.js 14.16 的升级。我们对 remote 模块进行了更改，为 contextIsolation 设置了新的默认值，添加了新的 webFrameMain API，并进行了常规改进。请阅读下文了解更多详情！

Electron 团队激动地宣布 Electron 12.0.0 发布！您可以使用 npm 通过 npm install electron@latest 安装，或从我们的发布网站下载。此版本包含了大量的升级、修复以及对 Apple M1 硬件的新支持。

值得注意的变化​

堆栈变更​

• 我们迫不及待想看到您用它们构建出什么！请继续阅读以了解此版本的详细信息，并欢迎提供您的任何反馈！
  • Chromium 89
  • Chrome 88 中的新特性
• Chrome 89 中的新特性
  • Node 14.16.0 博客文章
  • Node 14.0.0 博客文章
• Node.js 14.16
  • V8 8.9
  • V8 8.8 博客文章

亮点特性​

• V8 8.9 博客文章
• ContextBridge 的 exposeInMainWorld 方法现在可以暴露非对象 API。#26834
• 从 Node 12 升级到 Node 14。#23249
• 添加了新的 webFrameMain API，用于从主进程访问 WebContents 实例的子帧。#25464

contextIsolation 和 worldSafeExecuteJavaScript 的默认值现在为 true。#27949 #27502

重大变更​

• 请参阅12.0.0 版本说明，查看新功能和更改的完整列表。
  • 弃用了 remote 模块。它被 @electron/remote 取代。#25293
• 如果您目前正在使用 remote 模块，我们在此处提供了迁移到 @electron/remote 的指南。
• 将 contextIsolation 的默认值更改为 true。#27949
• 将 worldSafeExecuteJavaScript 的默认值更改为 true。#27502
• 将 crashReporter.start({ compress }) 的默认值从 false 更改为 true。#25288
• 移除 Flash 支持：Chromium 已移除对 Flash 的支持，Electron 12 也随之移除。请参阅Chromium 的 Flash 路线图了解更多详情。

有关这些更改和未来更改的更多信息，请参阅计划中的破坏性更改页面。

API 变更​

• x86 架构的 Chrome 要求支持 SSE3：Chromium 已移除对不满足最低 SSE3 (Streaming SIMD Extensions 3) 支持的旧版 x86 CPU 的支持。Electron 12 中也移除了此支持。
• 添加了 webFrameMain API：webFrameMain 模块可用于查找现有 WebContents 实例中的帧。这是现有 webFrame API 在主进程中的对应 API。可以在此处以及我们的文档中找到有关此新 API 的更多信息。
  • app API 更改
  • 为 'child-process-gone' / app.getAppMetrics() 添加了非本地化的 serviceName。#25975
  • 添加了新的 app.runningUnderRosettaTranslation 属性，用于检测在 Apple silicon 上是否通过 Rosetta 运行。#26444
• 为 render-process-gone 详细信息（app & webContents）添加了 exitCode。#27677
  • BrowserWindow API 更改
  • 添加了 BrowserWindow.isTabletMode() API。#25209
  • 为 BrowserWindow 添加了 resized (Windows/macOS) 和 moved (Windows) 事件。#26216
  • 添加了新的 system-context-menu 事件，允许阻止和覆盖系统上下文菜单。#25795
  • 添加了 win.setTopBrowserView()，以便可以提升 BrowserView 的层级。#27713
• 添加了 webPreferences.preferredSizeMode，允许根据视图文档的最小尺寸调整视图大小。#25874
  • contextBridge API 更改
• 允许 ContextBridge 的 exposeInMainWorld 方法暴露非对象 API。#26834
  • display API 更改
• 为 Display 对象添加了 displayFrequency 属性，用于获取 Windows 上的刷新率信息。#26472
  • extensions API 更改
• 添加了对部分 chrome.management API 的支持。#25098
  • MenuItem API 更改
• 添加了显示 macOS 共享菜单的支持。#25629
  • net API 更改
  • 为 net.request() 添加了新的 credentials 选项。#25284
• 添加了 net.online，用于检测当前是否有互联网连接。#21004
  • powerMonitor API 更改
  • 添加了 powerMonitor.onBatteryPower。#26494
• 在 macOS 上为 powerMonitor 添加了快速用户切换事件。#25321
  • session API 更改
  • 为 ses.loadExtension() API 添加了 allowFileAccess 选项。#27702
  • 为 session.setPermissionRequestHandler 添加了 display-capture API。#27696
  • 为 session.setSSLConfig 添加了 disabledCipherSuites 选项。#25818
  • 为 session 添加了 extension-loaded、extension-unloaded 和 extension-ready 事件。#25385
  • 添加了 session.setSSLConfig()，允许配置 SSL。#25461
  • 添加了在 session.setProxy() 中显式指定 direct、auto_detect 或 system 模式的支持。#24937
  • 添加了 Serial API 支持。#25237
• 添加了用于启用/禁用拼写检查器的 API。#26276
  • shell API 更改
• 添加了新的异步 shell.trashItem() API，取代了同步的 shell.moveItemToTrash()。#25114
  • webContents API 更改
  • 在控制台添加了一个小的控制台提示，以帮助调试渲染器崩溃问题。#25317
  • 为 webRequest 处理程序中的 details 对象添加了 frame 和 webContents 属性。#27334
  • 添加了 webContents.forcefullyCrashRenderer()，用于强制终止渲染器进程，以协助恢复无响应的渲染器。#25580
• 为渲染器创建的子窗口添加了 setWindowOpenHandler API，并弃用了 new-window 事件。#24517
  • webFrame API 更改

移除/弃用变更​

以下 API 已被移除或现已被弃用

• 请参阅12.0.0 版本说明，查看新功能和更改的完整列表。
• 为渲染器添加了拼写检查 API。#25060
• 移除了弃用的 crashReporter API。#26709

从打包应用程序的默认“帮助”菜单中移除了指向 Electron 网站的链接。#25831

9.x.y 版本停止支持​

下一步计划​

根据项目的支持政策，Electron 9.x.y 已停止支持。建议开发者和应用程序升级到更新版本的 Electron。

有关即将发布的 Electron 版本中计划的破坏性更改的信息，请参阅我们的计划中的破坏性更改文档。

2020 年 11 月 17 日 ·

Electron 11.0.0 已发布！它包含对 Chromium 87、V8 8.7 和 Node.js 12.18.3 的升级。我们还添加了对 Apple silicon 的支持，并进行了常规改进。请阅读下文了解更多详情！

Electron 团队激动地宣布 Electron 11.0.0 发布！您可以使用 npm 通过 npm install electron@latest 安装，或从我们的发布网站下载。此版本包含了大量的升级、修复以及对 Apple M1 硬件的新支持。

值得注意的变化​

堆栈变更​

• 我们迫不及待想看到您用它们构建出什么！请继续阅读以了解此版本的详细信息，并欢迎提供您的任何反馈！
  • Chromium 87.0.4280.47
  • Chrome 86 中的新特性
• Chrome 87 中的新特性
  • Node.js 12.18.3
  • Node 12.18.3 博客文章
• Node 12.7.0 博客文章
  • V8 8.7
  • V8 8.7 博客文章

亮点特性​

• 支持 Apple M1：11 月 10 日，Apple 发布了其新款 M1 芯片，该芯片将包含在其即将推出的硬件中。从 Electron 11 开始，Electron 将为英特尔 Mac (x64) 和 Apple 即将推出的 M1 硬件 (arm64) 提供单独的 Electron 版本。您可以在此处了解更多关于如何在 Apple M1 硬件上运行 Electron 应用的信息。 #24545
• 将 V8 崩溃消息和位置信息添加到 crashReport 参数中。 #24771
• 改进了通过 context bridge 发送宽对象的性能。 #24671

有关新特性和更改的完整列表，请参阅11.0.0 发行说明。

重大变更​

• 移除了实验性 API：BrowserView.{fromId, fromWebContents, getAllViews} 和 BrowserView 的 id 属性。 #23578

有关这些更改和未来更改的更多信息，请参阅计划中的破坏性更改页面。

API 变更​

• 新增了 app.getApplicationInfoForProtocol() API，该 API 返回处理特定协议的应用的详细信息。 #24112
• 新增了 app.createThumbnailFromPath() API，该 API 根据文件路径和最大缩略图大小返回文件的预览图像。 #24802
• 新增了 webContents.forcefullyCrashRenderer() API，用于强制终止渲染进程，以帮助恢复无响应的渲染器。 #25756

结束支持 8.x.y​

根据项目的支持策略，Electron 8.x.y 已达到支持结束日期。建议开发者和应用升级到更高版本的 Electron。

下一步计划​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们谨慎不承诺具体的发布日期，但我们的计划是大约每季度发布一个包含这些组件新版本的 Electron 主版本。暂定的 12.0.0 发布时间表列出了 Electron 12.0 开发生命周期中的关键日期。此外，有关 Electron 版本控制的更详细信息，请参阅我们的版本控制文档。

有关即将发布的 Electron 版本中计划的破坏性更改的信息，请参阅我们的计划中的破坏性更改文档。

继续推进 remote 模块的弃用工作​

我们从Electron 9 开始着手移除 remote 模块。我们计划在 Electron 14 中彻底移除 remote 模块。

请阅读并关注此 issue，了解弃用的完整计划和详情。

要求原生 Node 模块必须支持 Context Aware 或 N-API 的最后一步（Electron 12 中）​

从 Electron 6 开始，我们一直在为要求在渲染进程中加载的原生 Node 模块必须支持 N-API 或 Context Aware 奠定基础。强制实施这一更改可以带来更强的安全性、更快的性能和减少的维护工作量。此计划的最后一步是在 Electron 12 中移除禁用渲染进程复用的能力。

请阅读并关注此 issue，了解包括提议的时间表在内的所有详细信息。

随着 Apple Silicon 硬件于今年晚些时候发布，您如何在新的硬件上运行您的 Electron 应用？

随着 Electron 11.0.0-beta.1 的发布，Electron 团队现在正在提供可以在 Apple 计划于今年晚些时候发货的新 Apple Silicon 硬件上运行的 Electron 版本。您可以使用 npm install electron@beta 获取最新的 beta 版本，或直接从我们的发布网站下载。

它是如何工作的？​

从 Electron 11 开始，我们将为英特尔 Mac 和 Apple Silicon Mac 提供单独的 Electron 版本。在此更改之前，我们已经提供两个 Artifact，darwin-x64 和 mas-x64，其中后者用于 Mac App Store 兼容性。现在我们正在提供另外两个 Artifact，darwin-arm64 和 mas-arm64，它们是上述 Artifact 在 Apple Silicon 上的对应版本。

我需要做什么？​

您需要发布两个版本的应用：一个用于 x64（英特尔 Mac），另一个用于 arm64（Apple Silicon）。好消息是 electron-packager、electron-rebuild 和 electron-forge 已经支持针对 arm64 架构。只要您运行的是这些软件包的最新版本，一旦将目标架构更新为 arm64，您的应用就应该能够完美运行。

将来，我们将发布一个软件包，允许您将 arm64 和 x64 应用“合并”成一个通用二进制文件，但值得注意的是，这个二进制文件会非常大，可能不适合分发给用户。

更新：此软件包现已在@electron/universal 上可用。您可以使用它将两个打包好的 x64 和 arm64 应用合并为一个二进制文件。

潜在问题​

原生模块​

由于您正在针对新的架构，您需要更新一些依赖项，这可能会导致构建问题。下文列出了某些依赖项的最低版本要求供您参考。

由于这些依赖项版本要求，您可能需要修复/更新某些原生模块。值得注意的是，Xcode 升级将引入新版本的 macOS SDK，这可能会导致您的原生模块构建失败。

如何测试？​

目前，Apple Silicon 应用只能在 Apple Silicon 硬件上运行，在撰写这篇博客文章时，该硬件尚未商业发布。如果您有 Developer Transition Kit，您可以在上面测试您的应用。否则，您需要等到 Apple Silicon 生产硬件发布后才能测试您的应用是否正常工作。

Rosetta 2 怎么样？​

Rosetta 2 是 Apple Rosetta 技术的最新迭代，它允许您在新 arm64 Apple Silicon 硬件上运行 x64 英特尔应用。虽然我们相信 x64 Electron 应用可以在 Rosetta 2 下运行，但仍有一些重要事项需要注意（以及为何您应该发布原生 arm64 二进制文件的原因）。

• 您的应用性能将显著下降。Electron / V8 使用 JIT 编译 JavaScript，并且由于 Rosetta 的工作方式，您实际上会运行两次 JIT（一次在 V8 中，一次在 Rosetta 中）。
• 您将失去 Apple Silicon 中新技术的优势，例如增加的内存页大小。
• 我们有没有提过性能会显著下降？