@electron 包将需要 Node.js 22 LTS。 在我们的博客上阅读更多信息。
Electron 项目将在 2021 年 12 月暂停一个月，然后在 2022 年 1 月恢复全速运转。
简而言之，虽然维护人员对项目感到满意并积极参与，但世界已经疲惫不堪。十二月是大多数公司的淡季，因此我们希望让我们的维护人员有机会充电。我们鼓励其他项目考虑类似的措施。
不用担心。我们能够采取这一步，是因为项目状况良好。每个人都期待着 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 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。您可以在 此处阅读完整详情。
此外，Electron 将把支持的版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月。 请参阅我们的版本控制文档，了解有关 Electron 版本控制的更多详细信息。
94
16.5.0
9.4
nativeWindowOpen: true 不再是实验性的，现在是默认设置。safeStorage 字符串加密 API。 #30430WebContents 添加了 'frame-created' 事件，该事件在页面中创建框架时发出。 #30801BrowserWindow 的 will-resize 事件添加了调整大小 edge 信息。 #29199有关新功能和更改的完整列表，请参阅 15.0.0 发行说明。
以下是 Electron 15 中引入的重大变更。有关这些变更和未来变更的更多信息，请访问 计划的重大变更 页面。
在 Electron 15 之前，默认情况下 window.open 被填充为使用 BrowserWindowProxy。这意味着 window.open('about:blank') 不能用于同步打开可脚本化的子窗口，以及其他不兼容性。 nativeWindowOpen: true 不再是实验性的，现在是默认设置。
有关更多详细信息，请参阅 Electron 中 window.open 的文档。
WebContents 添加了 'frame-created' 事件，该事件在页面中创建框架时发出。 #30801safeStorage 字符串加密 API。 #30430dialog.showMessageBox 添加了 signal 选项。 #26102app.asar 文件上强制执行代码签名。需要最新的 asar 模块（v3.1.0 或更高版本）。 #30900NODE_OPTIONS 和 --inspect 调试参数。 #30420MenuItem.userAccelerator 属性，以读取用户分配的 macOS 加速器覆盖。 #26682app.runningUnderARM64Translation 属性，以检测在 Apple Silicon 上在 Rosetta 下运行时，或在 Windows for ARM 上在 WOW 下运行时。 #29168imageAnimationPolicy web 首选项，以控制图像的动画方式。 #29095没有 API 被删除或弃用。
从 Electron 15 开始，我们将把支持的版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月的 Electron 19。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持更改是我们新的节奏更改的一部分。有关完整详细信息，请参阅 我们的博客文章。
鼓励开发人员和应用程序升级到较新版本的 Electron。
| E15 (21 年 9 月) | E16 (21 年 11 月) | E17 (22 年 2 月) | E18 (22 年 3 月) | E19 (22 年 5 月) |
|---|---|---|---|---|
| 15.x.y | 16.x.y | 17.x.y | 18.x.y | 19.x.y |
| 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y |
| 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y |
| 12.x.y | 13.x.y | 14.x.y | 15.x.y | -- |
在短期内，您可以期望团队继续专注于跟上构成 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 安装它，或者从我们的 发布网站 下载它。继续阅读以了解有关此版本的详细信息，并请分享您的任何反馈！
从 2021 年 9 月的 Electron 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。您可以在 此处阅读完整详情。 Electron 15 将于 2021 年 9 月 1 日开始 beta 测试，稳定版本将于 2021 年 9 月 21 日发布。您可以在 此处找到 Electron 的公共时间表。此外，Electron 将把支持的版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月。有关 Electron 版本控制的更多详细信息，请参阅 我们的版本控制文档。
93
14.17.0
9.3
nativeWindowOpen 现在默认为 true。 (请参阅文档)session.storagePath API，以获取会话特定数据的磁盘路径。 #28665process.contextId，供 @electron/remote 使用。 #28007有关新功能和更改的完整列表，请参阅 14.0.0 发行说明。
以下是 Electron 14 中引入的重大变更。有关这些变更和未来变更的更多信息，请访问 计划的重大变更 页面。
app.allowRendererProcessReuseapp.allowRendererProcessReuse 属性已被删除，这是我们计划更紧密地与 Chromium 的进程模型保持一致，以提高安全性、性能和可维护性的一部分。
有关更多详细信息，请参阅 #18397。
构造新的 BrowserWindow 时的 affinity 选项已被删除，这是我们计划更紧密地与 Chromium 的进程模型保持一致，以提高安全性、性能和可维护性的一部分。
有关更多详细信息，请参阅 #18397。
window.open()可选参数 frameName 不再设置窗口的标题。此行为现在遵循 本机文档 中描述的 windowName 参数规范。
如果您使用此参数来设置窗口的标题，则可以改为使用 win.setTitle(title) 方法。
worldSafeExecuteJavaScriptworldSafeExecuteJavaScript 已被删除，没有替代方案。请确保您的代码在此属性启用时可以正常工作。自 Electron 12 以来，它已默认启用。
如果您使用 webFrame.executeJavaScript 或 webFrame.executeJavaScriptInIsolatedWorld，您将受到此更改的影响。您需要确保这些方法返回的值受 Context Bridge API 支持，因为这些方法使用相同的值传递语义。
nativeWindowOpen 默认为 true在 Electron 14 之前，默认情况下 window.open 被填充为使用 BrowserWindowProxy。这意味着 window.open('about:blank') 不能用于同步打开可脚本化的子窗口，以及其他不兼容性。 nativeWindowOpen 不再是实验性的，现在是默认设置。
有关更多详细信息，请参阅 Electron 中的 window.open 的文档。
在 Electron 14 之前，使用 window.open 打开的窗口将从其父窗口继承 BrowserWindow 构造选项，例如 transparent 和 resizable。从 Electron 14 开始，此行为已被删除，窗口将不再从其父窗口继承任何 BrowserWindow 构造选项。
相反，使用 setWindowOpenHandler 显式设置新窗口的选项
webContents.setWindowOpenHandler((details) => {
return {
action: 'allow',
overrideBrowserWindowOptions: {
// ...
},
};
});
additionalFeaturesWebContents 的 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 模块remote 模块在 Electron 12 中已弃用，现在已从 Electron 本身中删除，并提取到一个单独的软件包 @electron/remote 中。 @electron/remote 模块桥接从主进程到渲染器进程的 JavaScript 对象。这使您可以访问仅限主进程的对象，就像它们在渲染器进程中可用一样。这是 remote 模块的直接替代品。有关迁移说明和参考，请参阅 模块的 readme。
BrowserWindow.isFocusable() 方法，以确定窗口是否可聚焦。 #28642WebFrameMain.visibilityState 实例属性。 #28706setWindowOpenHandler 注册的窗口打开处理程序传递的详细信息对象添加了 disposition、referrer 和 postBody。 #28518process.contextId，供 @electron/remote 使用。 #28007webRequest 监听器详细信息添加了缺少的 resourceType 转换：font、ping、cspReport、media、webSocket。 #30050session.storagePath API，以获取会话特定数据的磁盘路径。 #28665--log-file=.../path/to/file.log 将 Chromium 日志记录定向到文件的支持。此外，现在可以通过在第一个 JS tick 期间附加命令行开关来从 JavaScript 启用日志记录。 #29963ContextBridgeMutability 功能，该功能允许上下文桥对象被改变。 #27348以下 API 已被删除或现在已弃用
remote 模块已被删除。 #25734new-window 和 did-create-window WebContents 事件中删除了已弃用的 additionalFeatures 属性。 #28548app.allowRendererProcessReuse 和 BrowserWindow affinity 选项。 #26874uploadToServer 为 false 时，crashReporter.start 的 submitURL 选项不再是必需的参数。 #28105根据项目的 支持策略，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 的稳定通道），因此它们共享磁盘和一些工作集。有关更多信息，请参阅 常青分发模式。
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 上不可用。
快速摘要
| Electron | WebView2 | |
|---|---|---|
| 构建依赖项 | Chromium | Edge |
| GitHub 上提供的源代码 | 是 | 否 |
| 共享 Edge/Chrome DLL | 否 | 是（截至 Edge 90） |
| 应用程序之间的共享运行时 | 否 | 可选 |
| 应用程序 API | 是 | 否 |
| Node.js | 是 | 否 |
| 沙盒 | 可选 | 始终 |
| 需要应用程序框架 | 否 | 是 |
| 支持的平台 | Mac、Win、Linux | Win（计划支持 Mac/Linux） |
| 应用程序之间的进程共享 | 从不 | 可选 |
| 框架更新由以下项管理 | 应用程序 | WebView2 |
当涉及到渲染您的 Web 内容时，我们预计 Electron、WebView2 和任何其他基于 Chromium 的渲染器之间的性能差异很小。我们为那些有兴趣调查潜在性能差异的人创建了 使用 Electron、C++ + WebView2 和 C# + WebView2 构建的应用程序的脚手架。
在渲染 Web 内容之外，存在一些差异，来自 Electron、WebView2、Edge 和其他方面的人员表示有兴趣进行详细的比较，包括 PWA。
我们想立即强调一个差异，因为我们认为这通常是 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 当前的发布节奏。
Chromium 计划从 2021 年 9 月 21 日的 Chrome 94 版本开始，每 4 周 发布一个新的里程碑版本。 此发布节奏还增加了一个新的每 8 周的扩展稳定版选项，其中将包含所有更新的安全修复程序。
Microsoft Store 将要求基于 Chromium 的应用版本不得低于最新的 2 个主要版本。 例如，如果 Chromium 最新发布的主要版本是 85，则任何基于 Chromium 的浏览器都必须至少使用 Chromium 83 或更高版本。 此规则包括 Electron 应用。
从 2021 年 9 月开始，Electron 将每 8 周发布一个新的主要稳定版本，以匹配 Chromium 的 8 周扩展稳定版发布周期。
我们首个采用 Chromium 扩展稳定版的版本将是 Electron 15，发布日期为 2021 年 9 月 21 日。
考虑到发布节奏的更改会影响其他下游应用程序，我们希望尽快通知我们的开发者社区。 请继续阅读以了解有关我们 2021 年发布计划的更多详细信息。
鉴于我们最初的 Electron 15 发布目标是非扩展稳定版（Chromium 的扩展稳定版基于其偶数版本），我们需要更改我们最初的目标发布日期。 然而，Electron 应用必须使用最新的 2 个 Chromium 主要版本才能被 Microsoft Store 接受，这使得等待两个 Chromium 版本变得不可行。
考虑到这两个要求，我们的团队面临着时间困境。 将 Electron 15 迁移到包含 Chromium M94 将使应用程序开发者能够使用 Chromium 的第一个扩展稳定版； 但是，这也将把 Beta 到 Stable 的周期缩短到只有 3 周。
为了帮助完成此切换，Electron 将为 Electron 15 版本提供一个临时的 Alpha 构建版本。 此 Alpha 构建版本将为开发者提供更多时间来测试和规划 Electron 15 的发布，其构建版本比我们当前的 Nightly 版本更稳定。
Alpha 频道构建版本将于 2021 年 7 月 20 日发布 Electron 15。 它将于 2021 年 9 月 1 日过渡到 Beta 版本，并计划于 2021 年 9 月 21 日发布稳定版本。 后续的 Electron 版本将不再有 Alpha 版本。
以下是我们当前的 2021 年发布时间表
| Electron | Chrome | Alpha 版本 | Beta 版本 | 稳定版本 | 稳定周期（周） |
|---|---|---|---|---|---|
| E13 | M91 | - | 2021-03-05 | 2021-05-25 | 12 |
| E14 | M93 | - | 2021-05-26 | 2021-08-31 | 14 |
| E15 | M94 | 2021-07-20 | 2021-09-01 | 2021-09-21 | 9 (包括 Alpha) |
| E16 | M96 | - | 2021-09-22 | 2021-11-16 | 8 |
| E17 | M98 | - | 2021-11-17 | 2022-02-01 | 11 |
添加 Alpha 频道将 Electron 15 发布前的开发时间从 3 周延长到 9 周 - 更接近我们新的 8 周周期，同时仍然满足 Windows Store 提交的要求。
为了进一步帮助应用程序开发者，在 2021 年剩余时间到 2022 年 5 月期间，我们还将把支持的版本策略从最新的 3 个版本扩展到最新的 4 个 Electron 版本。 这意味着即使您无法立即更改升级计划，旧版本的 Electron 仍将收到安全更新和修复程序。
我们在这个发布周期更改计划之前很久就发布这篇文章是有原因的。 我们知道更快的发布周期将对 Electron 应用程序产生实际影响 - 其中一些应用程序可能已经觉得我们的主要版本发布节奏过于激进。
我们已尝试在下面解决常见的疑虑
为了在 Electron 中交付最新版本的 Chromium，我们的时间表需要与他们保持一致。 有关 Chromium 发布周期的更多信息，请访问此处。
此外，当前的 12 周发布周期对于 Microsoft Store 新的提交要求来说是不可持续的。 即使是最新稳定版 Electron 上的应用程序也会经历大约两周的时间，在此期间，他们的应用程序可能会因新的安全要求而被拒绝。
每个新的 Chromium 版本都包含新功能、错误修复/安全修复和 V8 改进。 我们希望您作为应用程序开发者能够及时获得这些更改，因此我们的稳定版本发布日期将继续与 Chromium 的每个其他稳定版本发布日期保持一致。 作为应用程序开发者，您将比以前更快地访问新的 Chromium 和 V8 功能及修复程序。
更频繁发布的一个优势是发布版本更小。 我们理解升级 Electron 的主要版本可能很困难。 我们希望较小的版本每次发布引入的 Chromium 和 Node 更改以及重大更改都会更少。
目前没有计划支持永久的 Alpha 版本。 此 Alpha 版本仅适用于 Electron 15，作为帮助开发者在缩短的发布周期内更轻松升级的一种方式。
在 2022 年 5 月 Electron 19 发布之前，我们将把支持的版本策略从最新的三个版本扩展到最新的四个 Electron 版本。 在 Electron 19 发布后，我们将恢复支持最新的三个主要版本，以及 Beta 和 Nightly 版本。
| E13 (2021 年 5 月) | E14 (2021 年 8 月) | E15 (21 年 9 月) | E16 (21 年 11 月) | E17 (22 年 2 月) | E18 (22 年 3 月) | E19 (22 年 5 月) |
|---|---|---|---|---|---|---|
| 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y | 19.x.y |
| 12.x.y | 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y |
| 11.x.y | 12.x.y | 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y |
| -- | -- | 12.x.y | 13.x.y | 14.x.y | 15.x.y | -- |
📨 如果您有任何问题或疑虑，请发送邮件至 info@electronjs.org 或 加入我们的 Discord。 我们知道这是一个会影响许多应用程序和开发者的更改，您的反馈对我们非常重要。 我们希望听到您的声音！
Electron 13.0.0 已发布！ 它包括 Chromium 91 和 V8 9.1 的升级。 我们添加了一些 API 更新、错误修复和常规改进。 请阅读下文了解更多详情！
Electron 团队很高兴地宣布 Electron 13.0.0 的发布！ 您可以通过 npm 使用 npm install electron@latest 安装它，或从我们的发布网站下载它。 继续阅读以了解有关此版本的详细信息，并请分享您的任何反馈！
91
14.16.0
9.1
process.contextIsolated 属性，指示当前渲染器上下文是否启用了 contextIsolation。 #28252session.storagePath API 以获取会话特定数据的磁盘路径。 #28866WebContents 的 new-window 事件。 它已被 webContents.setWindowOpenHandler() 替代@electron/remote 使用的 process.contextId。 #28251请参阅 13.0.0 发行说明，了解新功能和更改的完整列表。
window.open() 参数 frameName 不再设置为窗口标题。 #27481session.setPermissionCheckHandler(handler) 以允许 handler 的第一个参数 webContents 为 null。 #19903有关这些更改和未来更改的更多信息，请访问 计划的重大更改 页面。
BrowserWindow 添加了 roundedCorners 选项。 #27572session.storagePath API 以获取会话特定数据的磁盘路径。28866process.uptime()。 #26684context-menu 事件一部分发出的参数添加了缺少的字段。#26788以下 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.shouldUseDarkColorsnativeTheme.shouldUseInvertedColorSchemenativeTheme.shouldUseHighContrastColors根据项目的支持策略，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 安装它，或从我们的发布网站下载它。 继续阅读以了解有关此版本的详细信息，并请分享您的任何反馈！
89
14.16
8.9
exposeInMainWorld 方法现在可以公开非对象 API。 #26834webFrameMain API，用于从主进程访问 WebContents 实例的子框架。 #25464contextIsolation 和 worldSafeExecuteJavaScript 的默认值现在为 true。 #27949 #27502请参阅 12.0.0 发行说明，了解新功能和更改的完整列表。
remote 模块。 它已被 @electron/remote 替代。 #25293remote 模块，我们编写了一个迁移到 @electron/remote 的指南，请点击此处。contextIsolation 的默认值更改为 true。 #27949worldSafeExecuteJavaScript 的默认值更改为 true。 #27502crashReporter.start({ compress }) 的默认值从 false 更改为 true。 #25288有关这些更改和未来更改的更多信息，请访问 计划的重大更改 页面。
webFrameMain API：webFrameMain 模块可用于查找现有 WebContents 实例中的框架。 这是现有 webFrame API 的主进程等效项。 有关此新 API 的更多信息，请访问 此处，以及我们的 文档。app API 更改
BrowserWindow API 更改
contextBridge API 更改
exposeInMainWorld 方法公开非对象 API。 #26834display API 更改
Display 对象添加了 displayFrequency 属性，以允许获取有关 Windows 刷新率的信息。 #26472extensions API 更改
chrome.management API 的支持。 #25098MenuItem API 更改
net API 更改
powerMonitor API 更改
session API 更改
ses.loadExtension() API 添加了 allowFileAccess 选项。 #27702session.setPermissionRequestHandler 添加了 display-capture API。 #27696session.setSSLConfig 添加了 disabledCipherSuites 选项。 #25818session 添加了 extension-loaded、extension-unloaded 和 extension-ready 事件。 #25385session.setSSLConfig() 以允许配置 SSL。 #25461session.setProxy() 中添加了显式指定 direct、auto_detect 或 system 模式的支持。 #24937shell API 更改
shell.trashItem() API，取代了同步的 shell.moveItemToTrash()。 #25114webContents API 更改
webFrame API 更改
以下 API 已被删除或现在已弃用
remote 模块。 它已被 @electron/remote 替代。 #25293crashReporter API。 #26709根据项目的支持策略，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 芯片的支持以及常规改进。 请阅读下文了解更多详情！
Electron 团队很高兴地宣布 Electron 11.0.0 的发布！ 您可以通过 npm 使用 npm install electron@latest 安装它，或从我们的发布网站下载它。 此版本包含大量升级、修复和对 Apple M1 硬件的新支持。
我们迫不及待想看看您使用它们构建什么！ 继续阅读以了解有关此版本的详细信息，并请分享您的任何反馈！
87.0.4280.47
12.18.3
8.7
请参阅 11.0.0 发行说明，了解新功能和更改的完整列表。
BrowserView.{fromId, fromWebContents, getAllViews} 和 BrowserView 的 id 属性。 #23578有关这些更改和未来更改的更多信息，请访问 计划的重大更改 页面。
app.getApplicationInfoForProtocol() API，该 API 返回有关处理特定协议的应用程序的详细信息。 #24112app.createThumbnailFromPath() API，该 API 返回给定文件路径和最大缩略图大小的文件预览图像。 #24802webContents.forcefullyCrashRenderer() 以强制终止渲染器进程，以帮助恢复挂起的渲染器。 #25756根据项目的支持策略，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 以获取完整的弃用计划和详细信息。
从 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 开始，我们将为 Intel Mac 和 Apple Silicon Mac 发布单独的 Electron 版本。在此更改之前，我们已经发布了两个工件，darwin-x64 和 mas-x64，后者用于 Mac App Store 兼容性用途。现在我们又发布了另外两个工件，darwin-arm64 和 mas-arm64，它们是上述工件的 Apple Silicon 等效版本。
您需要发布两个版本的应用程序：一个用于 x64（Intel Mac），另一个用于 arm64（Apple Silicon）。好消息是 electron-packager、electron-rebuild 和 electron-forge 已经支持以 arm64 架构为目标。只要您运行的是这些软件包的最新版本，一旦您将目标架构更新为 arm64，您的应用程序就应该可以完美运行。
未来，我们将发布一个软件包，允许您将 arm64 和 x64 应用程序“合并”为单个通用二进制文件，但值得注意的是，此二进制文件将非常庞大，可能不是交付给用户的理想选择。
更新：此软件包现已在 @electron/universal 提供。您可以使用它将两个打包好的 x64 和 arm64 应用程序合并为单个二进制文件。
由于您要以新的架构为目标，因此您需要更新几个依赖项，这可能会导致构建问题。下面列出了某些依赖项的最低版本供您参考。
| 依赖项 | 版本要求 |
|---|---|
| Xcode | >=12.2.0 |
node-gyp | >=7.1.0 |
electron-rebuild | >=1.12.0 |
electron-packager | >=15.1.0 |
由于这些依赖项的版本要求，您可能需要修复/更新某些原生模块。需要注意的一点是，Xcode 升级将引入新版本的 macOS SDK，这可能会导致您的原生模块构建失败。
目前，Apple Silicon 应用程序只能在 Apple Silicon 硬件上运行，而在撰写此博文时，Apple Silicon 硬件尚未在商业上发售。如果您有 开发者过渡套件，则可以在该套件上测试您的应用程序。否则，您将不得不等待量产 Apple Silicon 硬件发布后才能测试您的应用程序是否可以正常工作。
Rosetta 2 是 Apple 最新迭代的 Rosetta 技术，该技术允许您在其新的 arm64 Apple Silicon 硬件上运行 x64 Intel 应用程序。尽管我们认为 x64 Electron 应用程序可以在 Rosetta 2 下运行，但仍有一些重要事项需要注意（以及您应该发布原生 arm64 二进制文件的原因）。
加入我们，参与社区联谊和为期一个月的开源庆祝活动。
Electron 的 外联工作组 很高兴宣布启动我们的官方社区 Discord 服务器！
在早期作为 Atom 文本编辑器 的骨干时，关于 Electron 框架的社区讨论发生在 Atom 的 Slack 工作区中的单个频道中。随着时间的推移，这两个项目日益解耦，Atom 工作区与 Electron 项目的相关性降低，维护者在 Slack 频道中的参与度也以同样的方式下降。
到目前为止，我们仍然将更广泛的社区重定向到 Atom Slack 工作区，即使我们收到了许多关于人们难以收到邀请的报告，并且我们很少有核心维护者经常访问该频道。
我们正在建立这个闪亮的新服务器，使其成为社区的中心讨论枢纽，您可以在其中获取有关 Electron 的所有最新消息。
到目前为止，服务器的成员由一些共同努力建立它的维护者组成，但我们非常高兴与大家聊天！来这里寻求帮助，了解 Electron 的最新版本，或者只是与其他开发人员一起闲逛。我们为您准备了一个方便的 邀请链接，它将让您访问服务器！
作为一个大型且长期运行的开源项目，如果没有社区的贡献，Electron 不会取得如此大的成功，这些贡献包括代码提交、错误报告、文档更改等等。这就是为什么我们相信参与 Hacktoberfest 的重要性，以便引导更广泛的、各种技能水平的开发者社区加入该项目。
今年，我们没有更广泛的项目供大家参与，但我们想专注于为 Electron JavaScript 生态系统做出贡献的机会。
请关注我们各个仓库中标注为 hacktoberfest 的 issue，包括主要的 electron/electron 仓库、electron/electronjs.org 网站、electron/fiddle 和 electron-userland/electron-forge！
附注：如果您感觉特别有冒险精神，我们还有积压的标有 help wanted 标签的 issue，如果您正在寻找更具挑战性的任务。
此外，我们的 Discord 服务器盛大开幕恰逢年度最大的开源软件庆祝活动，这也绝非巧合。查看 #hacktoberfest 频道，询问有关您的 Hacktoberfest PR 的帮助。如果您错过了，这是邀请链接！