Spectron 将于2022年2月1日被弃用。

从2022年2月开始，Spectron 将被 Electron 团队正式弃用。

为什么要弃用 Spectron？​

尽管 Spectron 针对每个新版本的 Electron 都发布了新版本，但该项目一年多以来维护和改进很少，目前没有全职维护者。随着 remote 模块从 Electron 核心移出并成为 Electron 14 中的外部模块，Spectron 将需要进行重大重写才能继续可靠运行。

在审查了 Spectron 持续维护的几个可用选项后，Electron 团队决定在 2022 年弃用 Spectron。

弃用时间线​

以下是我们计划的弃用时间表

• 2021年11月 - 2022年1月：Electron 团队将继续接受来自社区的拉取请求。
• 2022年1月：将发布最终版本的公告，警告 Spectron 的弃用。
• 2022年2月1日：Spectron 的仓库将被标记为“存档”。 不再接受拉取请求。

2022 年 2 月 1 日之后，Electron 将无限期地保留 Spectron 仓库，以欢迎他人分叉或使用现有代码用于其项目。我们希望这将有助于为任何仍依赖 Spectron 的项目提供更长的过渡期。

Spectron 的替代方案​

如果您目前在项目中使用 Spectron 并希望迁移到替代测试解决方案，您可以在此处阅读我们的自动化测试指南。

我们目前有几个其他推荐的 Spectron 替代品，包括 Playwright 和 WebDriverIO。 每个选项的官方教程都可以在我们的自动化测试文档中找到。

下一步计划​

Electron 团队感谢您使用 Spectron 和 Electron。我们理解你们中的许多人依赖 Spectron 来测试您的应用程序，我们希望使这一过渡对您来说尽可能轻松。 感谢您选择 Electron！

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 起，我们将支持版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月的 Electron 19。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持更改是我们新的发布周期更改的一部分。请参阅我们的博客文章以获取完整详细信息。

下一步计划​

短期内，您可以期望团队继续专注于跟上 Electron 主要组成部分（包括 Chromium、Node 和 V8）的开发。虽然我们很谨慎，不会承诺发布日期，但我们的计划是大约每 2 个月发布一次包含这些组件新版本的 Electron 新主要版本。

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

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

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

来自 GIPHY

12 月份保持不变的事项​

1. 零日漏洞和其他与重大安全相关的版本将根据需要发布。安全事件应通过 SECURITY.md 报告。
2. 行为准则的报告和管理工作将继续进行。

12 月份会有所不同的事项​

1. 12 月份不会发布新的 Beta 或 Stable 版本。12 月的最后两周不会发布 Nightly 版本。
2. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
3. 任何代码仓库的 Issue Tracker 都不会有更新。
4. 维护者不会在 Discord 上提供调试帮助。
5. 社交媒体内容将暂停更新。

为什么要这样做？​

总之，尽管维护者对该项目感到满意并积极参与，但全世界都很疲惫。12 月对大多数公司来说是比较平静的月份，所以我们希望让维护者有机会休养生息。我们鼓励其他项目考虑类似的措施。

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

移除/弃用的变更​

没有 API 被移除或弃用。

支持的版本​

从 Electron 15 开始，我们将支持版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月的 Electron 19。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持更改是我们新的发布周期更改的一部分。请参阅我们的博客文章以获取完整详细信息。

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

下一步计划​

短期内，您可以期望团队继续专注于跟上 Electron 主要组成部分（包括 Chromium、Node 和 V8）的开发。虽然我们很谨慎，不会承诺发布日期，但我们的计划是大约每季度发布一次包含这些组件新版本的 Electron 新主要版本。

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

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

Electron 14.0.0 已发布！它包含了 Chromium 93 和 V8 9.3 的升级。我们添加了几项 API 更新、bug 修复和通用改进。请继续阅读以获取更多详情！

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

重要变更​

Electron 发布节奏变更​

从 2021 年 9 月的 Electron 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。您可以在此处阅读完整详细信息。Electron 15 将于 2021 年 9 月 1 日开始 beta 测试，稳定版将于 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
• 添加了 process.contextId，用于 @electron/remote。 #28007
• 添加了实验性的 cookie 加密支持，该支持通过Electron Fuse 提供。#29492

请参阅 14.0.0 版本说明 以获取新功能和更改的完整列表。

破坏性变更​

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

已移除：app.allowRendererProcessReuse​

app.allowRendererProcessReuse 属性已被移除，这是我们为了更紧密地与 Chromium 的进程模型保持一致，以提高安全性、性能和可维护性而采取的计划的一部分。

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

已移除：BrowserWindow 亲和性​

在创建新的 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 模块的直接替代品。有关迁移说明和参考，请参阅模块的自述文件。

API 更改​

• 添加了 BrowserWindow.isFocusable() 方法，用于确定窗口是否可聚焦。 #28642
• 添加了 WebFrameMain.visibilityState 实例属性。 #28706
• 向通过 setWindowOpenHandler 注册的窗口打开处理程序传递的详细信息对象添加了 disposition、referrer 和 postBody。#28518
• 添加了 process.contextId，用于 @electron/remote。 #28007
• 添加了实验性的 cookie 加密支持，该支持通过Electron Fuse 提供。#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 tick 中附加命令行开关来从 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 源代码的 fork 构建的。Electron 不与 Chrome 共享任何 DLL。WebView2 二进制文件与 Edge（截至 Edge 90 的稳定版）进行硬链接，因此它们共享磁盘和部分工作集。有关更多信息，请参阅Evergreen 分发模式。

Electron 应用程序始终捆绑和分发其开发时使用的确切 Electron 版本。WebView2 在分发方面有两个选项。您可以捆绑应用程序开发时使用的确切 WebView2 库，或者使用系统中可能已存在的共享运行时版本。WebView2 为每种方法提供了工具，包括在共享运行时丢失时引导安装程序。WebView2 从 Windows 11 开始内置。

捆绑框架的应用程序负责更新这些框架，包括次要安全版本。对于使用共享 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-native-addon。WebView2 应用程序不假定您应用程序其余部分是用什么语言或框架编写的。您的 JavaScript 代码必须通过应用程序宿主进程代理任何操作系统访问。

Electron 致力于保持与 Web API 的兼容性，包括从Fugu Project 开发的 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 构建的应用程序的脚手架，供有兴趣的人调查潜在的性能差异。

在渲染网页内容之外，存在一些差异，来自 Electron、WebView2、Edge 和其他团队的人员都表示有兴趣就包括 PWA 在内的详细比较进行合作。

进程间通信 (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 使用结构化克隆算法。利用此 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 周增加一个新的扩展稳定版选项，其中包含所有更新的安全修复。

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

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

我们第一个使用Chromium长期支持版本（Extended Stable）的发布将是2021年9月21日的Electron 15。

我们知道发布周期调整将影响其他下游应用程序，因此我们希望尽快告知我们的开发者社区。请继续阅读以了解有关我们2021年发布计划的更多详细信息。

Electron 15：临时 Alpha 版本​

鉴于我们最初的 Electron 15 发布目标是非扩展稳定版（Chromium 的扩展稳定版基于其偶数版本），我们需要更改我们最初的目标发布日期。但是，Electron 应用程序必须使用最新的 2 个 Chromium 主要版本才能被 Microsoft Store 接受，这使得等待两个 Chromium 版本变得不可行。

有了这两个要求，我们的团队面临着时间上的困境。将 Electron 15 移至包含 Chromium M94 将允许应用程序开发人员使用 Chromium 的第一个扩展稳定版；但是，这也将 Beta 到稳定版的周期缩短到仅 3 周。

为了帮助完成此次切换，Electron 将提供一个临时性的 Alpha 版本，仅用于 Electron 15 发布。此 Alpha 版本将为开发人员提供更多时间来测试和规划 Electron 15 的发布，其稳定版本将比我们当前的 nightly 版本更稳定。

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

2021年发布计划​

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

添加 alpha 通道将 Electron 15 发布前的开发时间从3周延长到9周——更接近我们新的8周周期，同时仍满足Windows商店的提交要求。

为了进一步帮助应用程序开发人员，在 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，用于获取会话特定数据在磁盘上的路径。 #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，用于获取会话特定数据在磁盘上的路径。28866
• 增加了通过上下文桥传递 DOM 元素的支持。 #26776
• 为沙盒化的渲染器添加了 process.uptime()。 #26684
• 在作为 context-menu 事件一部分发出的参数中，添加了缺失的字段。#26788
• 增加了对注册 Manifest V3 扩展 Service Worker 的支持。
• 为 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.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 安装它，或从我们的发布网站下载。请继续阅读有关此版本的详细信息，并请分享您的任何反馈！

重要变更​

技术栈变更​

• Chromium 89
  • Chrome 88 新增功能
  • Chrome 89 新增功能
• Node.js 14.16
  • Node 14.16.0 博客文章
  • Node 14.0.0 博客文章
• 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 路线图。
• x86 上的 Chrome 需要 SSE3：Chromium 已移除对不满足 SSE3（Streaming SIMD Extensions 3）最低支持的老式 x86 CPU的支持。此支持已在 Electron 12 中移除。

有关这些及未来更改的更多信息，请参阅计划中的重大更改页面。

API 更改​

• 添加了 webFrameMain API：webFrameMain 模块可用于查找现有WebContents 实例中的帧。这是现有 webFrame 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 处理程序中的详细信息对象中添加了 frame 和 webContents 属性。 #27334
  • 添加了 webContents.forcefullyCrashRenderer()，用于强制终止渲染器进程，以协助恢复挂起的渲染器。 #25580
  • 为渲染器创建的子窗口添加了 setWindowOpenHandler API，并弃用了 new-window 事件。 #24517
• webFrame API 更改
  • 向渲染器添加了拼写检查 API。 #25060

移除/弃用的变更​

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

• 已弃用 remote 模块。它已被@electron/remote 取代。#25293
• 移除了已弃用的 crashReporter API。 #26709
• 从打包应用程序的默认“帮助”菜单中移除了指向 Electron 网站的链接。 #25831

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

Electron 9.x.y 已根据项目的支持策略达到支持期末。鼓励开发人员和应用程序升级到更新版本的 Electron。

下一步计划​

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

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

Electron 11.0.0 已发布！它包含了 Chromium 87、V8 8.7 和 Node.js 12.18.3 的升级。我们增加了对 Apple 芯片的支持，以及通用改进。详情请阅读下文！

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.6 博客文章
  • V8 8.7 博客文章

重点特性​

• Apple M1 支持：11 月 10 日，Apple 发布了其新款 M1 芯片，该芯片将包含在其即将推出的硬件中。从 Electron 11 开始，Electron 将为 Intel Mac（x64）和 Apple 即将推出的 M1 硬件（arm64）分别发布 Electron 版本。您可以在此处了解更多关于如何让您的 Electron 应用程序在 Apple M1 硬件上运行的信息。 #24545
• 向 crashReport 参数添加了 V8 崩溃消息和位置信息。#24771
• 提高了通过上下文桥发送大型对象时的性能。#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() 以强制终止渲染进程，从而帮助恢复挂起的渲染进程。#25756

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

Electron 8.x.y 已根据项目的支持策略达到支持期末。鼓励开发人员和应用程序升级到更新版本的 Electron。

下一步计划​

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

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

继续努力弃用 remote 模块​

我们在 Electron 9 中开始致力于移除 remote 模块。我们计划在 Electron 14 中移除 remote 模块本身。

阅读并关注 此问题 以获取完整的弃用计划和详细信息。

要求本地 Node 模块具有上下文感知能力或使用 N-API 的最后一步（在 Electron 12 中）​

从 Electron 6 开始，我们一直在为要求渲染器进程中加载的本地 Node 模块是 N-API 或上下文感知奠定基础。强制执行此更改可以提高安全性、加快性能并减少维护工作量。此计划的最后一步是在 Electron 12 中移除禁用渲染进程重用的能力。

阅读并关注 此问题 以获取完整详细信息，包括拟议的时间表。