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

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

为什么要弃用 Spectron？​

虽然 Spectron 一直为每个新版本的 Electron 发布新版本，但该项目一年多来几乎没有维护和改进，目前没有全职维护人员。随着远程模块从 Electron 核心移出并进入 Electron 14 中的外部模块，Spectron 将需要进行重大重写才能继续可靠地工作。

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

弃用时间线​

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

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

在 2022 年 2 月 1 日之后，Electron 将继续无限期地保留 Spectron repo，以便其他人可以随意 fork 或使用现有代码用于他们的项目。我们希望这将有助于为可能仍然依赖 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 添加数据参数以在实例之间共享数据。#30891
• 将 securityOrigin 传递给媒体权限请求处理程序。#31357
• 添加 commandLine.removeSwitch。#30933

请参阅 16.0.0 发布说明，获取新特性和更改的完整列表。

重大更改​

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

构建原生模块​

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

行为已更改：crashReporter 实现已切换到 Linux 上的 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 或稳定版本。12 月最后两周没有 Nightly 版本。
2. 除少数例外，没有拉取请求审查或合并。
3. 任何存储库上都没有问题跟踪器更新。
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' 事件，该事件在页面中创建框架时发出。#30801
• 为BrowserWindow的will-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 保险丝，用于在您的应用程序加载的 app.asar 文件上强制执行代码签名。需要最新的 asar 模块（v3.1.0 或更高版本）。#30900
• 添加了保险丝以禁用打包应用程序中的 NODE_OPTIONS 和 --inspect 调试参数。#30420
• 添加了新的 MenuItem.userAccelerator 属性，以读取用户分配的 macOS 加速器覆盖。#26682
• 添加了新的 app.runningUnderARM64Translation 属性，以检测在 Apple Silicon 上通过 Rosetta 运行或在 Windows for ARM 上通过 WOW 运行的情况。#29168
• 添加了新的 imageAnimationPolicy web 偏好设置，以控制图像的动画方式。#29095
• 添加了通过上下文桥发送 Blob 的支持。#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 更新、错误修复和常规改进。请阅读下文了解更多详情！

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

值得注意的更改​

Electron 发布节奏变更​

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

有关新功能和更改的完整列表，请参阅14.0.0 发行说明。

重大更改​

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

已删除：app.allowRendererProcessReuse​

作为我们更紧密地与 Chromium 的进程模型保持一致以确保安全性、性能和可维护性的计划的一部分，已删除 app.allowRendererProcessReuse 属性。

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

已删除：浏览器窗口关联性​

作为我们更紧密地与 Chromium 的进程模型保持一致以确保安全性、性能和可维护性的计划的一部分，已删除构造新 BrowserWindow 时的 affinity 选项。

有关更多详细信息，请参阅#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 替换。）窗口功能中的裸键现在将在 options 对象中显示为值为 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
• 将 disposition、referrer 和 postBody 添加到传递给使用 setWindowOpenHandler 注册的窗口打开处理程序的详细信息对象。#28518
• 添加了 process.contextId，供 @electron/remote 使用。#28007
• 在 Electron 保险丝 后面添加了实验性的 cookie 加密支持。#29492
• 为 webRequest 侦听器详细信息添加了缺少的 resourceType 转换：font、ping、cspReport、media、webSocket。#30050
• 添加了新的 session.storagePath API 来获取会话特定数据的磁盘路径。#28665
• 添加了对 macOS 上的 Windows 控制覆盖的支持。#29986
• 添加了通过 --log-file=.../path/to/file.log 将 Chromium 日志记录定向到文件的支持。此外，现在可以通过在第一个 JS tick 期间附加命令行开关来从 JavaScript 启用日志记录。#29963
• 添加了对 node crypto 中 des-ede3 密码的支持。#27897
• 添加了一个 ContextBridgeMutability 功能，允许修改上下文桥对象。#27348

已删除/已弃用的更改​

以下 API 已被删除或现在已弃用

• 在 Electron 12 中弃用后，已删除 remote 模块。#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 的稳定通道），因此它们共享磁盘和一些工作集。有关更多信息，请参阅 Evergreen 分发模式。

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

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

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 项目 开发的 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 和其他团队的成员都表示有兴趣进行包括 PWA 在内的详细比较。

进程间通信 (IPC)​

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

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

即使 Electron 和 WebView2 具有相似的进程模型，但底层 IPC 也有所不同。在 JavaScript 和 C++ 或 C# 之间进行通信需要 marshalling，最常见的是 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 计划 每 4 周 发布一个新的里程碑，从 2021 年 9 月 21 日的 Chrome 94 开始。 此发布节奏还增加了每 8 周一个新的 Extended Stable 选项，其中将包含所有更新的安全修复程序。

2. Microsoft Store 将 要求基于 Chromium 的应用程序不超过 2 个主要版本。例如，如果最新发布的主要 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 发布目标是一个非扩展稳定版本（Chromium 的扩展稳定版本基于其偶数版本），我们需要更改最初的目标发布日期。然而，一个 Electron 应用必须使用最新的 2 个 Chromium 主要版本才能被 Microsoft Store 接受，这使得等待两个 Chromium 版本变得不可行。

有了这两个要求，我们的团队面临一个时间上的困境。将 Electron 15 移至包含 Chromium M94 将允许应用程序开发者使用第一个扩展稳定版本的 Chromium；然而，这也会将 beta 到 stable 的周期缩短到只有 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 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 来获取会话特定数据在磁盘上的路径。#28866
• 弃用了 WebContents 的 new-window 事件。它被 webContents.setWindowOpenHandler() 替换。
• 添加了 process.contextId，供 @electron/remote 使用。#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 扩展服务工作者的支持。
• 向 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 版本。 暂定的 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 也删除了 Flash 支持。有关更多详细信息，请参见Chromium 的 Flash 路线图。
• 在 x86 上需要 SSE3 才能支持 Chrome：Chromium 已经删除了对不符合 SSE3（流式 SIMD 扩展 3）最低要求的旧 x86 CPU 的支持。Electron 12 也删除了此支持。

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

API 更改​

• 添加了 webFrameMain API：可以使用 webFrameMain 模块在现有的 WebContents 实例中查找框架。这是现有 webFrame API 的主进程等效项。有关此新 API 的更多信息，请参见此处，以及我们的文档。
• app API 更改
  • 将非本地化的 serviceName 添加到 'child-process-gone' / app.getAppMetrics()。#25975
  • 添加了新的 app.runningUnderRosettaTranslation 属性，以检测何时在 Apple 芯片上运行 Rosetta。#26444
  • 将 exitCode 添加到 render-process-gone 详细信息（app & webContents）。#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 更改
  • 将 displayFrequency 属性添加到 Display 对象，以允许获取有关 Windows 上刷新率的信息。#26472
• extensions API 更改
  • 添加了对某些 chrome.management API 的支持。#25098
• MenuItem API 更改
  • 添加了显示 macOS 共享菜单的支持。#25629
• net API 更改
  • 为 net.request() 添加了一个新的 credentials 选项。#25284
  • 添加了 net.online，用于检测当前是否存在 Internet 连接。#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
  • 将 frame 和 webContents 属性添加到 webRequest 处理程序中的详细信息对象。#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 的新主要版本，其中包含这些组件的新版本。暂定的 13.0.0 时间表 绘制了 Electron 13.0 开发生命周期中的关键日期。 此外，请参阅我们的版本控制文档，以获取有关 Electron 版本控制的更多详细信息。

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

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.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 的新主要版本，其中包含这些组件的新版本。暂定的 12.0.0 时间表 绘制了 Electron 12.0 开发生命周期中的关键日期。 此外，请参阅我们的版本控制文档，以获取有关 Electron 版本控制的更多详细信息。

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

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

我们开始了在 Electron 9 中移除 remote 模块的工作。 我们计划在 Electron 14 中移除 remote 模块本身。

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

在 Electron 12 中要求本机 Node 模块必须是上下文感知或 N-API 的最后一步​

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

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