上个月，Electron 的维护者团队在加拿大温哥华会面，讨论项目 2023 年及未来的发展方向。 在会议室里，核心维护者和受邀协作者用了四天时间讨论了新的计划、维护痛点以及整体项目健康状况。

展望未来，团队仍将全力致力于定期快速地升级 Chromium、修复错误，并使 Electron 对所有人来说更安全、性能更好。 我们还有一些令人兴奋的项目正在进行中，很高兴能与社区分享！

变革性的新 API​

Electron 项目中需要达成共识的主要 API 提案，会经过征求意见稿 (RFC) 流程，由我们的 API 工作组成员进行评审。

今年，我们推进了两项主要提案，它们有望为 Electron 应用开启全新的功能维度。 这些提案仍处于高度实验阶段，但这里可以先睹为快！

新的原生插件增强功能 (C API)​

该提案概述了 Electron C API 的新层，这将允许应用开发者编写自己的原生 Node 插件，这些插件可以与 Electron 的内部资源交互，类似于 Node 自己的 Node-API。 关于提议的新 API 的更多信息可在此处找到。

示例：利用 Chromium 资源为应用加速​

许多 Electron 应用会维护自己的分支 (fork) 以直接与 Chromium 内部机制交互，否则这些内部机制在使用原版 (未修改的) Electron 时是无法访问的。 通过在 C API 层暴露这些资源，这些代码可以作为原生模块与 Electron 并存，从而可能减轻应用开发者的维护负担。

暴露 Chromium 的 UI 层 (Views API)​

在内部，Chrome 用户界面 (UI) 中非网站部分，如工具栏、标签页或按钮，都是使用一个名为 Views 的框架构建的。 Views API 提案将该框架的部分内容以 JavaScript 类形式引入到 Electron 中，最终目标是允许开发者在其 Electron 应用中创建非 Web UI 元素。 这将避免应用不得不拼凑 Web 内容的情况。

使这套新 API 成为可能的基础工作目前正在进行中。 以下是您在不久的将来可以期待的一些初步进展。

示例：使用 WebContentsView 重构窗口模型​

我们计划的第一个变更是将 Chrome 的 WebContentsView 暴露给 Electron 的 API 层面，它将是我们现有 BrowserView API（尽管名称如此，但它是 Electron 特定的代码，与 Chromium Views 无关）的继任者。 暴露 WebContentsView 后，我们将拥有一个可重用的 View 对象，它可以显示 Web 内容，从而为将 BrowserWindow 类纯粹 JavaScript 化并消除更多代码复杂性打开了大门。

尽管此项变更不会为应用开发者提供很多新功能，但它是一项大型重构，消除了底层大量代码，简化了 Chromium 升级，并降低了主要版本之间出现新错误的风险。

如果您是使用 BrowserViews 的 Electron 应用开发者：请不要担心，我们没有忘记您！ 我们计划将现有的 BrowserView 类作为 WebContentsView 的 shim，以便在您过渡到新 API 时提供缓冲。

参阅：electron/electron#35658

示例：使用 ScrollView 实现可滚动 Web 内容​

我们的朋友 Stack 一直在推动一项将 Chromium ScrollView 组件暴露给 Electron API 的倡议。 有了这个新 API，任何子 View 组件都可以实现水平或垂直滚动。

尽管这个新 API 只实现了一个较小的功能，但团队的最终目标是构建一套实用的 View 组件，这些组件可以作为工具包来构建更复杂的非 HTML 界面。

参与其中​

您是 Electron 应用开发者，对这些 API 提案感兴趣吗？ 尽管我们尚未准备好接收额外的 RFC，但请持续关注未来的更多细节！

Electron Forge v6 稳定版发布​

自框架诞生以来，Electron 的构建工具生态系统主要由社区驱动，由许多小型单一用途的包组成（例如 electron-winstaller、electron-packager、electron-notarize、electron-osx-sign）。 尽管这些工具运行良好，但对于用户来说，将一个可用的构建流水线拼接起来是令人望而生畏的。

为了帮助 Electron 开发者构建更友好的体验，我们构建了 Electron Forge，这是一个一体化解决方案，将所有现有工具整合到一个界面中。 尽管 Forge 自 2017 年以来一直在开发，但该项目在过去几年一直处于休眠状态。 然而，鉴于社区对 Electron 构建工具现状的反馈，我们一直在努力发布 Forge 的下一代稳定主要版本。

Electron Forge 6 提供了第一流的 TypeScript 和 Webpack 支持，以及一个可扩展的 API，允许开发者创建自己的插件和安装程序。

敬请期待：即将发布公告​

如果您对使用 Forge 构建项目，或使用 Forge 可扩展的第三方 API 构建模板或插件感兴趣，请在本月晚些时候关注我们关于 Forge v6 稳定版的官方公告！

下一步是什么？​

除上述内容外，团队一直在考虑一系列探索性项目，以改善 Electron 为应用开发者和最终用户带来的体验。 更新工具、API 评审流程和增强的文档是我们正在试验的其他事项。 我们希望在不久的将来能分享更多消息！

Electron 21.0.0 已发布！ 它包括对 Chromium 106、V8 10.6 和 Node.js 16.16.0 的升级。 阅读下文了解更多详情！

Electron 团队很高兴宣布 Electron 21.0.0 发布！ 您可以通过 npm 使用 npm install electron@latest 安装，或从我们的发布网站下载。 继续阅读了解此版本的详情。

如果您有任何反馈，请在 Twitter 上与我们分享，或加入我们的社区 Discord！ 错误和功能请求可以在 Electron 的问题跟踪器中报告。

重要变更​

技术栈变更​

• Chromium 106
  • Chrome 106 新特性
  • Chrome 105 新特性
  • DevTools 106 新特性
  • DevTools 105 新特性
• Node.js 16.16.0
  • Node 16.16.0 博客文章
• V8 10.6

新特性​

• 添加了 webFrameMain.origin。 #35534
• 添加了新的 WebContents.ipc 和 WebFrameMain.ipc API。 #35231
• 添加了面板状行为支持。 窗口可以浮动在全屏应用上方。 #34388
• 添加了对 macOS 应用通过 APNs 接收推送通知的支持。 #33574

重大变更和 API 变更​

以下是 Electron 21 中引入的重大变更。

启用 V8 内存笼​

Electron 21 启用了 V8 沙箱指针，这是继 Chrome 在 Chrome 103 中做出相同决定之后的操作。 这对原生模块有一些影响。 此功能具有性能和安全优势，但也对原生模块施加了一些新的限制，例如使用指向外部（“堆外”）内存的 ArrayBuffers。 请参阅此博客文章了解更多信息。 #34724

重构了 webContents.printToPDF​

重构了 webContents.printToPDF 以与 Chromium 的无头实现对齐。 参阅#33654了解更多信息。

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

停止支持 18.x.y​

根据项目的支持政策，Electron 18.x.y 已停止支持。 鼓励开发者和应用升级到更新的 Electron 版本。

下一步​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

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

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

Electron 20.0.0 已发布！ 它包括对 Chromium 104、V8 10.4 和 Node.js 16.15.0 的升级。 阅读下文了解更多详情！

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

重要变更​

新特性​

• 在 Windows 上添加了沉浸式深色模式。 #34549
• 添加了面板状行为支持。 窗口可以浮动在全屏应用上方。 #34665
• 更新了 Windows Control Overlay 按钮，使其在 Windows 11 上看起来和感觉更原生。 #34888
• 渲染器现在默认处于沙箱环境中，除非指定了 nodeIntegration: true 或 sandbox: false。 #35125
• 使用 nan 构建原生模块时添加了安全防护措施。 #35160

技术栈变更​

• Chromium 104
  • Chrome 104 新特性
  • Chrome 103 新特性
  • DevTools 新特性
• Node.js 16.15.0
  • Node 16.15.0 博客文章
• V8 10.4

重大变更和 API 变更​

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

默认变更：未指定 nodeIntegration: true 的渲染器默认处于沙箱环境​

以前，指定了预加载脚本的渲染器默认是不处于沙箱环境的。 这意味着默认情况下，预加载脚本可以访问 Node.js。 在 Electron 20 中，此默认设置已更改。 从 Electron 20 开始，渲染器将默认处于沙箱环境中，除非指定了 nodeIntegration: true 或 sandbox: false。

如果您的预加载脚本不依赖于 Node，则无需采取任何操作。 如果您的预加载脚本确实依赖于 Node，请重构它们以从渲染器中移除 Node 用法，或为相关渲染器明确指定 sandbox: false。

修复：nan 原生模块中随机崩溃的问题​

在 Electron 20 中，我们更改了与原生模块相关的两项内容

1. V8 头文件现在默认使用 c++17。 此标志已添加到 electron-rebuild 中。
2. 我们修复了一个问题，即缺少 include 会导致依赖 nan 的原生模块随机崩溃。

为了最大程度的稳定性，我们建议在重新构建原生模块时使用 node-gyp >=8.4.0 和 electron-rebuild >=3.2.9，特别是依赖 nan 的模块。 参阅 electron #35160 和 node-gyp #2497 了解更多信息。

移除：Linux 上的 .skipTaskbar​

在 X11 上，skipTaskbar 会向 X11 窗口管理器发送 _NET_WM_STATE_SKIP_TASKBAR 消息。 Wayland 没有直接等效的功能，且已知的变通方法存在不可接受的权衡（例如，GNOME 中的 Window.is_skip_taskbar 需要不安全模式），因此 Electron 无法在 Linux 上支持此功能。

停止支持 17.x.y​

根据项目的支持政策，Electron 17.x.y 已停止支持。 鼓励开发者和应用升级到更新的 Electron 版本。

下一步​

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

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

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

Electron 21 及更高版本将启用 V8 内存笼，这对一些原生模块会产生影响。

在 Electron 21 中，我们将启用 Electron 中的 V8 沙箱指针，这是继 Chrome 在 Chrome 103 中做出相同决定之后的操作。 这对原生模块有一些影响。 此外，我们先前在 Electron 14 中启用了相关技术指针压缩。 我们当时没有对此进行太多讨论，但指针压缩对 V8 堆的最大大小有影响。

启用这些技术后，对安全性、性能和内存使用都大有裨益。 然而，启用它们也有一些缺点。

启用沙箱指针的主要缺点是不再允许指向外部（“堆外”）内存的 ArrayBuffers。 这意味着依赖 V8 中此功能的原生模块需要进行重构，才能在 Electron 20 及更高版本中继续工作。

启用指针压缩的主要缺点是 V8 堆的最大大小被限制为 4GB。 其具体细节有点复杂——例如，ArrayBuffers 与 V8 堆的其他部分分开计数，但有它们自己的限制。

Electron 升级工作组认为指针压缩和 V8 内存笼的好处大于缺点。 主要有以下三个原因

1. 它使 Electron 更接近 Chromium。 Electron 与 Chromium 在 V8 配置等复杂内部细节方面的差异越小，我们意外引入错误或安全漏洞的可能性就越小。 Chromium 的安全团队非常强大，我们希望确保能够利用他们的工作。 此外，如果某个错误仅影响 Chromium 未使用的配置，那么修复它不太可能是 Chromium 团队的首要任务。
2. 它性能更好。 指针压缩可将 V8 堆大小减少高达 40%，并将 CPU 和 GC 性能提高 5%–10%。 对于绝大多数不会触及 4GB 堆大小限制且不使用需要外部缓冲区的原生模块的 Electron 应用来说，这些都是显著的性能提升。
3. 它更安全。 一些 Electron 应用会运行不受信任的 JavaScript（希望遵循我们的安全建议！），对于这些应用，启用 V8 内存笼可以保护它们免受一大部分恶性 V8 漏洞的影响。

最后，对于确实需要更大堆的应用，也有一些变通方法。 例如，可以将一个禁用了指针压缩的 Node.js 副本包含在您的应用中，并将内存密集型工作移动到子进程中。 尽管有些复杂，但如果您决定针对特定用例做出不同的权衡，也可以构建一个禁用了指针压缩的 Electron 自定义版本。 最后，在不远的将来，wasm64 将允许使用 WebAssembly 构建的应用（无论是在 Web 上还是在 Electron 中）使用远超 4GB 的内存。

常见问题​

我怎么知道我的应用是否受到此变更的影响？​

在 Electron 20+ 中，尝试使用 ArrayBuffer 包装外部内存将在运行时导致崩溃。

如果您的应用中不使用任何原生 Node 模块，那么您是安全的——无法通过纯 JS 触发此崩溃。 此变更仅影响那些在 V8 堆外分配内存（例如使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存的原生 Node 模块。 这是一种相对罕见的用例，但有些模块确实使用了这种技术，这些模块需要进行重构才能与 Electron 20+ 兼容。

如何测量我的应用正在使用的 V8 堆内存量，以了解是否接近 4GB 限制？​

在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，它将返回 V8 堆以字节为单位的使用量。 在主进程中，您可以使用 process.memoryUsage().heapUsed，两者是可比的。

什么是 V8 内存笼？​

有些文档将其称为“V8 沙盒”，但这个术语很容易与 Chromium 中发生的其他类型的沙盒混淆，因此我将沿用术语“内存笼”（memory cage）。

有一种相当常见的 V8 漏洞攻击方式大致如下：

1. 在 V8 的 JIT 引擎中找到一个 bug。JIT 引擎分析代码，以便能够省略慢速的运行时类型检查并生成快速的机器代码。有时逻辑错误意味着它的分析出错，并省略了一个它实际需要的类型检查——比如，它认为 x 是一个字符串，但实际上它是一个对象。
2. 利用这种混乱来覆盖 V8 堆中的某些内存位，例如，ArrayBuffer 起始位置的指针。
3. 现在你有一个 ArrayBuffer，它指向你想要的任何位置，因此你可以读写进程中的任何内存，甚至包括 V8 通常无法访问的内存。

V8 内存笼是一种旨在从根本上防止此类攻击的技术。实现这一点的方式是不在 V8 堆中存储任何指针。相反，V8 堆内对其他内存的所有引用都存储为相对于某个保留区域起始位置的偏移量。然后，即使攻击者设法破坏 ArrayBuffer 的基地址，例如通过利用 V8 中的类型混淆错误，他们最坏也只能读写笼内的内存，而这很可能他们本来就已经可以做到。关于 V8 内存笼如何工作的更多内容可以阅读，这里我就不再深入介绍了——最好的入门资料可能是 Chromium 团队的高级设计文档。

我想重构一个 Node 原生模块以支持 Electron 21+。我该怎么做？​

有两种方法可以重构原生模块使其与 V8 内存笼兼容。第一种是在将外部创建的缓冲区传递给 JavaScript 之前，将其复制到 V8 内存笼中。这通常是一种简单的重构，但当缓冲区较大时可能会很慢。另一种方法是使用 V8 的内存分配器来分配你打算最终传递给 JavaScript 的内存。这稍微复杂一些，但可以避免复制，这意味着对于大型缓冲区有更好的性能。

为了更具体，这里有一个使用外部数组缓冲区的 N-API 模块示例

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

当启用内存笼时，这将会崩溃，因为数据是在笼外分配的。通过重构改为将数据复制到笼中，我们得到

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

这将把数据复制到 V8 内存笼内新分配的内存区域。此外，N-API 也可以提供一个指向新复制数据的指针，以防你事后需要修改或引用它。

重构以使用 V8 的内存分配器稍微复杂一些，因为它需要修改 create_external_resource 函数，使其使用 V8 分配的内存，而不是使用 malloc。这的可行性高低取决于你是否能控制 create_external_resource 的定义。其思路是首先使用 V8 创建缓冲区，例如使用 napi_create_buffer，然后将资源初始化到 V8 分配的内存中。重要的是要为资源的生命周期保留 Buffer 对象的 napi_ref，否则 V8 可能会对 Buffer 进行垃圾回收，并可能导致 use-after-free 错误。

Electron 19.0.0 已发布！它包括 Chromium 102、V8 10.2 和 Node.js 16.14.2 的升级。请阅读下方了解更多详情！

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

重要变更​

Electron 发布节奏变更​

项目正在恢复到之前支持最新三个主要版本的策略。请参阅我们的版本控制文档，了解有关 Electron 版本控制和支持的更多详细信息。为了帮助用户适应从 Electron 15 开始的新发布节奏，该策略曾临时改为支持最新四个主要版本。你可以在这里阅读完整详情。

技术栈变更​

• Chromium 102
  • Chrome 102 中的新功能
  • Chrome 101 中的新功能
• Node.js 16.14.2
  • Node 16.14.2 博客文章
• V8 10.2

重大变更和 API 变更​

以下是 Electron 19 中引入的破坏性变更。更多关于这些以及未来变更的信息可以在计划的破坏性变更页面上找到。

Linux 上不支持：.skipTaskbar​

BrowserWindow 构造函数的选项 skipTaskbar 在 Linux 上不再受支持。在#33226中更改

移除 WebPreferences.preloadURL​

WebPreferences 中半文档化的 preloadURL 属性已被移除。#33228。应改用 WebPreferences.preload。

结束支持 15.x.y 和 16.x.y​

Electron 14.x.y 和 15.x.y 都已达到支持结束。这使 Electron 回归其现有政策，即支持最新的三个主要版本。鼓励开发者和应用升级到更新的 Electron 版本。

下一步​

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

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

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

Electron 正在更改其主要的 S3 存储桶，您可能需要更新您的构建脚本

发生了什么？

大量的 Electron 构建产物上传到一个名为 gh-contractor-zcbenz 的 S3 存储桶。作为自 2020 年就开始的持续基础设施/所有权迁移的一部分，我们将把所有使用 gh-contractor-zcbenz 的内容从其旧的 S3 位置迁移到托管在 https://artifacts.electronjs.org 的新存储系统。我们大部分资产使用的路径前缀也略有变化。示例包括下方：

之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib 之后： https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

此处重要的变化是主机名更改了，并且 /atom-shell 前缀更改了。另一个例子，这次是关于调试符号：

之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb 之后： https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

同样，主机名更改了，并且 /atom-shell 前缀更改了。

这可能对您有何影响？

任何使用标准构建工具（如 electron-rebuild、electron-packager 或 @electron/get）的人都不需要做任何事情。这应该是大多数用户。

对于任何直接引用 S3 存储桶的人，您必须更新您的引用，使其指向新的主机名并更新路径。

现有数据怎么办？

gh-contractor-zcbenz 存储桶上的大多数数据已被克隆到新的存储系统中。这意味着所有调试符号和所有头文件都已被复制。如果您依赖该存储桶中尚未复制的某些数据，请在 electron/electron 中提出问题并告知我们。

当前的 gh-contractor-zcbenz S3 存储桶不会被主动删除。但是，我们无法保证该存储桶会保留多久。我们强烈建议您尽快更新以指向新的存储桶。

Electron 18.0.0 已发布！它包括 Chromium 100、V8 10.0 和 Node.js 16.13.2 的升级。请阅读下方了解更多详情！

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

重要变更​

Electron 发布节奏变更​

从 Electron 15 开始，Electron 将每 8 周发布一个主要稳定版本。你可以在这里阅读完整详情。

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

技术栈变更​

• Chromium 100
  • Chrome 100 中的新功能
• Node.js 16.13.2
  • Node 16.13.2 博客文章
• V8 10.0

亮点功能​

• 添加了 ses.setCodeCachePath() API，用于设置代码缓存目录。#33286
• 移除了基于旧 BrowserWindowProxy 的 window.open 实现。这也移除了 webPreferences 中的 nativeWindowOpen 选项。#29405
• 向 WebContents 添加了 'focus' 和 'blur' 事件。#25873
• 在 macOS 上添加了替代菜单角色：showSubstitutions、toggleSmartQuotes、toggleSmartDashes、toggleTextReplacement。#32024
• 向 app.requestSingleInstanceLock() 流程添加了 first-instance-ack 事件，允许用户无缝地从第一个实例向第二个实例传输数据。#31460
• 在 setBackgroundColor 中添加了对更多颜色格式的支持。#33364

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

重大变更和 API 变更​

以下是 Electron 18 中引入的破坏性变更。更多关于这些以及未来变更的信息可以在计划的破坏性变更页面上找到。

已移除：nativeWindowOpen​

在 Electron 15 之前，window.open 默认被 shim 以使用 BrowserWindowProxy。这意味着 window.open('about:blank') 无法用于打开可同步脚本化的子窗口，以及存在其他不兼容问题。自 Electron 15 起，nativeWindowOpen 已默认启用。

更多详情请参阅 Electron 中window.open 的文档。在#29405中移除

结束支持 14.x.y​

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

从 Electron 15 开始，我们将支持版本从最新三个版本更改为最新四个版本，直到 2022 年 5 月，涵盖到 Electron 19。Electron 19 之后，我们将恢复到支持最新三个版本。本次版本支持更改是我们新节奏变更的一部分。请在此处查看我们的博客文章以获取完整详情。

下一步​

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

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

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

Electron 团队很高兴宣布，今年我们将首次参加 Google Summer of Code！

什么是 Google Summer of Code？​

Google Summer of Code (GSoC) 是一个年度指导项目，将开源软件项目与潜在贡献者连接起来。之前仅对学生开放，现在任何 18 岁及以上的人都可以注册参加 GSoC。

要了解更多信息，请访问Summer of Code 主页。

如何报名？​

您是否有兴趣与 Electron 合作？如果您是新的或初级开源贡献者，我们欢迎您申请！

要被选为 Google Summer of Code 的 Electron 贡献者，您需要提交一份申请。申请将于2022年4月4日开放，并于2022年4月19日截止。您可以在此处关注 Google: Summer of Code 申请指南的更新。

想申请吗？首先，查看我们准备的五份项目思路草稿。所有列出的思路目前都开放提案。我们也欢迎接受不在拟议项目列表中的新思路。

您的申请应包括

• 您的提案，这是一份详细描述您计划在夏天完成什么的书面文档。
• 您作为开发者的背景。如果您有简历，请附上副本；如果没有，请告诉我们您过去的经历，重点强调相关的技术经验。

此处是关于如何提交 Electron 申请的详细指南。

您还可以阅读官方的 GSoC 学生/贡献者指南，以获取准备提案的重要技巧。

如果您想讨论项目提案或有疑问，欢迎加入我们的 #gsoc-general Discord 频道！

参考资料​

• Electron 提案指南
• Electron GitHub
• 项目思路文档
• Google Summer of Code 学生/贡献者指南

Electron 17.0.0 已发布！它包括 Chromium 98、V8 9.8 和 Node.js 16.13.0 的升级。请阅读下方了解更多详情！

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

重要变更​

Electron 发布节奏变更​

从 Electron 15 开始，Electron 将每 8 周发布一个主要稳定版本。你可以在这里阅读完整详情。

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

技术栈变更​

• Chromium 98
  • Chrome 98 中的新功能
• Node.js 16.13.0
  • Node 16.13.0 博客文章
• V8 9.8

亮点功能​

• 添加了 webContents.getMediaSourceId()，可与 getUserMedia 一起使用以获取 WebContents 的流。#31204
• 弃用 webContents.getPrinters() 并引入 webContents.getPrintersAsync()。#31023
• desktopCapturer.getSources 现在仅在主进程中可用。#30720

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

破坏性变更​

以下是 Electron 17 中引入的破坏性变更。更多关于这些以及未来变更的信息可以在计划的破坏性变更页面上找到。

渲染器中的 desktopCapturer.getSources​

desktopCapturer.getSources API 现在仅在主进程中可用。此项更改旨在提高 Electron 应用的默认安全性。

API 变更​

Electron 17 中没有 API 变更。

已移除/已弃用变更​

• 已移除在渲染器中使用 desktopCapturer.getSources API 的功能。有关如何在应用中替换此 API 的详细信息，请参阅此处。

结束支持 13.x.y​

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

从 Electron 15 开始，我们将支持版本从最新三个版本更改为最新四个版本，直到 2022 年 5 月，涵盖到 Electron 19。Electron 19 之后，我们将恢复到支持最新三个版本。本次版本支持更改是我们新节奏变更的一部分。请在此处查看我们的博客文章以获取完整详情。

下一步​

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

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

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

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

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

为何弃用 Spectron？​

尽管 Spectron 为每个新版本的 Electron 持续发布新版本，但该项目一年多以来维护和改进甚少，并且目前没有全职维护者。随着 remote 模块在 Electron 14 中移出 Electron 核心并成为外部模块，Spectron 将需要进行重大重写才能继续稳定工作。

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

弃用时间表​

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

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

在 2022 年 2 月 1 日之后，Electron 将继续无限期地保留 Spectron 仓库，以便其他人可以随意 fork 或使用现有代码进行他们的项目。我们希望这将有助于为任何可能仍依赖 Spectron 的项目提供更长的过渡期。

Spectron 的替代方案​

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

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

下一步​

我们 Electron 团队感谢您使用 Spectron 和 Electron。我们理解许多人依赖 Spectron 来测试您的应用，我们希望使此过渡尽可能顺利。感谢您选择 Electron！