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

通过 GIPHY

12 月份保持不变的内容​

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

12 月份的不同之处​

1. 2024 年的最后一个稳定分支版本，包括 Electron 31、32 和 33，将在 12 月 1 日那一周发布。12 月份不会有其他计划的发布。
2. 12 月份最后两周没有 Nightly 和 Alpha 版本。
3. 除少数例外，不进行拉取请求审查或合并。
4. 任何存储库上都没有问题跟踪器更新。
5. 维护人员不提供 Discord 调试帮助。
6. 没有社交媒体内容更新。

2025 年见！

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

通过 GIPHY

12 月份保持不变的内容​

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

12 月份的不同之处​

1. Electron 28.0.0 将于 12 月 5 日发布。Electron 28 之后，12 月份不会有新的稳定版本发布。
2. 12 月份最后两周没有 Nightly 和 Alpha 版本。
3. 除少数例外，不进行拉取请求审查或合并。
4. 任何存储库上都没有问题跟踪器更新。
5. 维护人员不提供 Discord 调试帮助。
6. 没有社交媒体内容更新。

展望未来​

这是我们第三年运行安静期实验，到目前为止，我们在平衡一个月的休息和之后维持我们的正常发布节奏方面取得了很大的成功。因此，我们已决定将其作为我们发布日历的常规部分。我们仍然会在每个日历年的最后一个稳定版本中放入提醒。

2024 年见！

第一次提交到 electron/electron 存储库是在 2013 年 3 月 13 日¹。

10 年和 1192 位独特贡献者的 27,147 次提交之后，Electron 已成为当今构建桌面应用程序最流行的框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路所学到的东西的绝佳机会。

如果没有每个人都投入时间和精力为项目做出贡献，我们今天就不会在这里。虽然源代码提交始终是最可见的贡献，但我们也必须承认报告错误、维护 userland 模块、提供文档和翻译以及参与 Electron 网络空间社区的人们所做的努力。作为维护者，每一项贡献对我们来说都是非常宝贵的。

在我们继续进行博客文章的其余部分之前：谢谢。❤️

我们是如何走到这里的？​

Atom Shell 是作为 GitHub Atom 编辑器的支柱构建的，该编辑器于 2014 年 4 月发布公开测试版。它从头开始构建，作为当时可用的基于 Web 的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代方案。它有一个杀手级功能：嵌入 Node.js 和 Chromium，为 Web 技术提供强大的桌面运行时。

在一年之内，Atom Shell 在功能和受欢迎程度上开始出现巨大的增长。大型公司、初创公司和个人开发人员都开始使用它构建应用程序（一些早期采用者包括 Slack、GitKraken 和 WebTorrent），并且该项目被恰如其分地重命名为 Electron。

从那时起，Electron 开始一路狂奔，从未停止。以下是我们的每周下载量随时间变化的视图，由 npmtrends.com 提供

Electron v1 于 2016 年发布，承诺提高 API 稳定性和更好的文档和工具。Electron v2 于 2018 年发布，并引入了语义版本控制，使 Electron 开发人员可以更轻松地跟踪发布周期。

到 Electron v6 时，我们转向了常规的 12 周主要版本发布节奏，以匹配 Chromium 的节奏。对于该项目来说，这一决定是一种心态的转变，将“拥有最新的 Chromium 版本”从一个锦上添花的东西变成了一个优先事项。这减少了升级之间的技术债务，使我们能够更轻松地保持 Electron 的更新和安全。

从那时起，我们一直是一台运转良好的机器，在每个 Chromium 稳定版发布的同一天发布一个新的 Electron 版本。当 Chromium 在 2021 年将他们的发布计划加速到 4 周时，我们能够耸耸肩，并将我们的发布节奏相应地提高到 8 周。

我们现在使用的是 Electron v23（并且还在不断增加），并且仍然致力于构建用于构建跨平台桌面应用程序的最佳运行时。即使近年来 JavaScript 开发人员工具蓬勃发展，Electron 仍然是桌面应用程序框架领域中稳定、经过实战考验的中流砥柱。Electron 应用程序如今随处可见：您可以使用 Visual Studio Code 进行编程、使用 Figma 进行设计、使用 Slack 进行通信以及使用 Notion 进行笔记（以及许多其他用例）。我们对这一成就感到无比自豪，并感谢所有使之成为可能的人。

我们一路学到了什么？​

达到十年大关的道路漫长而曲折。以下是一些帮助我们运行可持续的大型开源项目的关键因素。

使用治理模型扩展分布式决策​

我们需要克服的一个挑战是在 Electron 首次爆发流行之后，如何处理项目的长期方向。我们如何处理一个由分布在不同公司、国家和时区的几十名工程师组成的团队？

在早期，Electron 的维护者团队依靠非正式协调，这对于较小的项目来说既快速又轻量，但无法扩展到更广泛的协作。在 2019 年，我们转向了一种治理模型，其中不同的工作组拥有正式的职责范围。这对于简化流程并将部分项目所有权分配给特定的维护者至关重要。如今，每个工作组 (WG) 负责什么？

• 发布 Electron 版本（发布 WG）
• 升级 Chromium 和 Node.js（升级 WG）
• 监督公共 API 设计（API WG）
• 保持 Electron 安全（安全 WG）
• 运行网站、文档和工具（生态系统 WG）
• 社区和企业推广（推广 WG）
• 社区审核（社区和安全 WG）
• 维护我们的构建基础设施、维护者工具和云服务（基础设施 WG）

大约在我们转向治理模型的同时，我们还将 Electron 的所有权从 GitHub 转移到 OpenJS 基金会。虽然最初的核心团队今天仍然在 Microsoft 工作，但他们只是构成 Electron 治理的更大的协作者群体的一部分。²

虽然这种模式并不完美，但它在全球大流行病和持续的宏观经济逆风中非常适合我们。展望未来，我们计划修改治理章程，以指导我们度过 Electron 的第二个十年。

社区​

开源的社区部分很难，尤其是当您的推广团队是一群穿着写着“社区经理”的风衣的工程师时。也就是说，作为一个大型开源项目意味着我们有很多用户，并且利用他们的能量为 Electron 构建一个 userland 生态系统对于维持项目健康至关重要。

我们一直在做什么来发展我们的社区影响力？

构建虚拟社区​

• 2020 年，我们启动了我们的社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定建立一个更非正式的消息平台，以便维护者和 Electron 开发人员之间进行讨论，并提供一般的调试帮助。
• 2021 年，在 @BlackHole1 的帮助下，我们建立了 Electron China 用户组。该小组在 Electron 在中国蓬勃发展的科技界的用户增长中发挥了重要作用，为他们提供了一个协作开展想法和讨论 Electron 的空间，而不是在我们以英语为母语的空间中。我们还要感谢 cnpm 在其用于 npm 的中文镜像中支持 Electron 的 nightly 版本的辛勤工作。

参与高知名度的开源计划​

• 自 2019 年以来，我们每年都在庆祝 Hacktoberfest。Hacktoberfest 是 DigitalOcean 组织的年度开源庆祝活动，每年我们都会得到数十名热情的贡献者，他们希望在开源软件上留下自己的印记。
• 2020 年，我们参与了 Google Season of Docs 的初始迭代，我们与 @bandantonio 合作，重新设计了 Electron 的新用户教程流程。
• 2022 年，我们第一次指导 Google 编程之夏学生。 @aryanshridhar 做了一些很棒的工作来重构 Electron Fiddle 的核心版本加载逻辑，并将其捆绑器迁移到 webpack。

自动化所有的事情！​

如今，Electron 治理部门拥有大约 30 名活跃的维护人员。我们中只有不到一半是全职贡献者，这意味着有很多工作要做。我们保持一切顺利运行的秘诀是什么？我们的座右铭是电脑很便宜，而人的时间很昂贵。以典型的工程师方式，我们开发了一套自动化支持工具，以使我们的生活更轻松。

Not Goma​

Electron 的核心代码库是一个庞大的 C++ 代码，并且构建时间一直是限制我们发布错误修复和新功能的速度的一个因素。2020 年，我们部署了 Not Goma，这是 Google Goma 分布式编译器服务的自定义 Electron 特定的后端。Not Goma 处理来自授权用户计算机的编译请求，并将该过程分发到后端数百个内核中。它还会缓存编译结果，以便编译相同文件的其他人只需要下载预编译的结果。

自推出 Not Goma 以来，维护者的编译时间已从数小时缩短到数分钟。稳定的互联网连接成为贡献者编译 Electron 的最低要求！

持续因子身份验证​

持续因子身份验证 (CFA) 是围绕 npm 的双重身份验证 (2FA) 系统的自动化层，我们将其与 semantic-release 结合使用，以管理我们的各种 @electron/ npm 包的安全和自动化发布。

虽然 semantic-release 已经自动化了 npm 包发布过程，但它需要关闭双重身份验证或传入一个秘密令牌来绕过此限制。

我们构建了 CFA 来为 npm 2FA 提供基于时间的一次性密码 (TOTP) 给任意 CI 作业，从而使我们能够在保持双重身份验证的额外安全性的同时利用 semantic-release 的自动化。

我们将 CFA 与 Slack 集成前端一起使用，使维护者可以从他们拥有 Slack 的任何设备验证包发布，只要他们手头有 TOTP 生成器即可。

Sheriff​

Sheriff 是我们编写的开源工具，用于自动化管理 GitHub、Slack 和 Google Workspace 中的权限。

Sheriff 的关键价值主张是权限管理应该是一个透明的过程。它使用一个 YAML 配置文件，该文件指定了所有上述服务的权限。借助 Sheriff，获得存储库上的协作者身份或创建新的邮件列表就像获得批准并合并 PR 一样容易。

Sheriff 还有一个审核日志，该日志会发布到 Slack，以警告管理员 Electron 组织中任何地方发生的可疑活动。

...以及我们所有的 GitHub 机器人​

GitHub 是一个具有丰富的 API 可扩展性和名为 Probot 的第一方机器人应用程序框架的平台。为了帮助我们专注于工作中更具创造力的部分，我们构建了一套较小的机器人来帮助我们完成繁琐的工作。以下是一些示例

• Sudowoodo 从头到尾自动化 Electron 发布流程，从启动构建到将发布资源上传到 GitHub 和 npm。
• Trop 通过尝试基于 GitHub PR 标签将补丁 cherry-pick 到之前的发布分支，从而自动化 Electron 的反向移植过程。
• Roller 自动化 Electron 的 Chromium 和 Node.js 依赖项的滚动升级。
• Cation 是我们 electron/electron PR 的状态检查机器人。

总而言之，我们的小型机器人家族极大地提高了开发人员的生产力！

下一步是什么？​

在我们作为项目的第二个十年开始之际，您可能会问：Electron 的下一步是什么？

我们将与 Chromium 的发布节奏保持同步，每 8 周发布新的 Electron 主要版本，使该框架与 Web 平台和 Node.js 的最新和最棒的版本保持同步，同时为企业级应用程序保持稳定性和安全性。

我们通常会在即将推出的计划变得具体时宣布相关新闻。如果您想及时了解未来的发布、功能和常规项目更新，您可以阅读我们的博客并关注我们的社交媒体个人资料（Twitter 和 Mastodon）！

Electron 将于 Electron 23 中停止支持 Windows 7、Windows 8 和 Windows 8.1。

根据 Chromium 的弃用策略，Electron 将于 Electron 23 中停止支持 Windows 7、Windows 8 和 Windows 8.1。这与 Microsoft 终止对 Windows 7 ESU 和 Windows 8.1 扩展版 的支持（2023 年 1 月 10 日）相符。

Electron 22 将是最后一个支持低于 10 的 Windows 版本的 Electron 主要版本。Electron 23 及更高版本将不支持 Windows 7/8/8.1。旧版本的 Electron 将继续在 Windows 7 上运行，并且我们将继续发布 Electron 22.x 系列的补丁，直到 2023 年 5 月 30 日，届时 Electron 将终止对 22.x 的支持（根据我们的 支持时间表）。

为什么要弃用？​

Electron 遵循计划的 Chromium 弃用策略，该策略将在 Chromium 109 中弃用支持（在此处阅读有关 Chromium 时间表的更多信息）。Electron 23 将包含 Chromium 110，该版本将不支持旧版本的 Windows。

因此，包含 Chromium 108 的 Electron 22 将是最后一个受支持的版本。

弃用时间表​

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

• 2022 年 12 月：Electron 团队将进入节假日静默期
• 2023 年 1 月：所有受支持的发布分支都接受与 Windows 7 和 8 相关的问题。
• 2023 年 2 月 7 日：发布 Electron 23。
• 2023 年 2 月 8 日 - 2023 年 5 月 29 日：Electron 将继续接受 Electron 23 之前版本的受支持行的修复。
• 2023 年 5 月 30 日：Electron 22 达到其支持周期的结束。

这对开发人员意味着什么

• Electron 团队将接受与 Windows 7/8/8.1 相关的稳定支持线的 issue 和修复，直到每行达到其支持周期的结束。
  • 这专门适用于 Electron 22、Electron 21 和 Electron 20。
• 与 Windows 7/8/8.1 相关的新 issue 将被接受用于低于 Electron 23 的 Electron 版本。
  • 任何较新的版本都不会接受新的 issue。
• 一旦 Electron 22 达到其支持周期的结束，所有与 Windows 7/8/8.1 相关的现有 issue 将被关闭。

下一步是什么​

如果您有任何问题或疑虑，请随时通过 info@electronjs.org 与我们联系。您还可以在我们的官方 Electron Discord 中找到社区支持。

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

通过 GIPHY

12 月份保持不变的内容​

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

12 月份的不同之处​

1. 12 月没有新的稳定版发布。12 月的最后两周没有 Nightly 和 Alpha 版本发布。
2. 除少数例外，不进行拉取请求审查或合并。
3. 任何存储库上都没有问题跟踪器更新。
4. 维护人员不提供 Discord 调试帮助。
5. 没有社交媒体内容更新。

为什么会发生这种情况？​

由于 2021 年 12 月静默月的成功，我们希望将其带回 2022 年。12 月仍然是大多数公司的静默月，因此我们希望让我们的维护人员有机会充电。每个人都期待着 2023 年，我们期待着美好的事情发生！我们鼓励其他项目考虑类似的措施。

上个月，Electron 的维护团队在加拿大温哥华举行会议，讨论了 2023 年及以后该项目的方向。在会议室的四天里，核心维护人员和受邀的合作者讨论了新的计划、维护痛点和整体项目健康状况。

展望未来，该团队仍将致力于发布定期和快速的 Chromium 升级、修复错误以及使 Electron 对每个人都更加安全和高效。我们还在进行一些令人兴奋的项目，我们很乐意与社区分享！

变革性的新 API​

Electron 项目中需要达成共识的主要 API 提案会经历一个征求意见 (RFC) 过程，该过程由我们的 API 工作组的成员审查。

今年，我们推进了两项重大提案，这些提案有可能为 Electron 应用程序解锁新的功能维度。这些提案具有高度实验性，但这里可以先睹为快！

新的本机插件增强功能（C API）​

该提案概述了一个新的 Electron C API 层，它将允许应用程序开发人员编写自己的本机 Node 插件，这些插件与 Electron 的内部资源接口，类似于 Node 自己的 Node-API。有关拟议的新 API 的更多信息可以在这里找到。

示例：使用 Chromium 资源增强应用程序​

许多 Electron 应用程序都维护自己的分支，以直接与 Chromium 内部组件进行交互，否则这些组件使用 vanilla（未修改的）Electron 将无法访问。通过在 C API 层中公开这些资源，此代码可以作为与 Electron 并排的本机模块存在，从而可能减少应用程序开发人员的维护负担。

公开 Chromium 的 UI 层（Views API）​

在底层，Chrome 用户界面 (UI) 的非网站部分（例如工具栏、选项卡或按钮）是使用名为 Views 的框架构建的。Views API 提案将此框架的部分内容作为 Electron 中的 JavaScript 类引入，最终目标是允许开发人员创建非 Web UI 元素到他们的 Electron 应用程序。这将防止应用程序必须拼凑 Web 内容。

使这组新 API 成为可能的基础工作目前正在进行中。以下是您在不久的将来可以期待的一些首批内容。

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

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

尽管此更改没有为应用程序开发人员提供许多新功能，但它是一个大型重构，消除了底层的大量代码，简化了 Chromium 升级并降低了主要版本之间出现新错误的风险。

如果您是 Electron 开发人员，在您的应用程序中使用 BrowserViews：请不要担心，我们没有忘记您！我们计划将现有的 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 及更高版本将启用 V8 内存笼子，这对某些本机模块有影响。

在 Electron 21 中，我们将启用 Electron 中的 V8 沙盒指针，继 Chrome 的 决定在 Chrome 103 中也这样做。这对本机模块有一些影响。此外，我们之前启用了一项相关技术，即 Electron 14 中的 指针压缩。我们当时没有对此过多讨论，但指针压缩对最大 V8 堆大小有影响。

启用后，这两种技术对安全性、性能和内存使用都有显着好处。但是，启用它们也有一些缺点。

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

启用指针压缩的主要缺点是 V8 堆限制为最大 4GB。这方面的确切细节有点复杂——例如，ArrayBuffer 与 V8 堆的其余部分分开计算，但有它们自己的限制。

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

1. 它使 Electron 更接近 Chromium。Electron 在 V8 配置等复杂的内部细节上与 Chromium 的差异越小，我们意外引入错误或安全漏洞的可能性就越小。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 的内存。

常见问题解答​

我如何知道我的应用程序是否受到此更改的影响？​

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

如果您在应用程序中未使用任何本机 Node 模块，那么您是安全的——无法从纯 JS 触发此崩溃。此更改仅影响本机 Node 模块，这些模块在 V8 堆之外分配内存（例如，使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存。这是一个相当罕见的用例，但某些模块确实使用此技术，并且需要重构此类模块才能与 Electron 20+ 兼容。

我如何衡量我的应用程序使用多少 V8 堆内存，以了解我是否接近 4GB 限制？​

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

什么是 V8 内存笼子？​

一些文档将其称为“V8 沙盒”，但该术语很容易与 Chromium 中发生的 其他类型的沙盒 混淆，因此我将坚持使用术语“内存笼子”。

有一种相当常见的 V8 漏洞利用方法，如下所示

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

V8 内存笼子是一种旨在从根本上防止此类攻击的技术。实现此目的的方法是不在 V8 堆中存储任何指针。相反，对 V8 堆中其他内存的所有引用都存储为距某个保留区域开头的偏移量。然后，即使攻击者设法破坏了 ArrayBuffer 的基本地址，例如通过利用 V8 中的类型混淆错误，他们能做的最糟糕的事情就是读取和写入笼子内的内存，他们可能无论如何都可以这样做。有关 V8 内存笼子如何工作的更多信息可供阅读，因此我不会在此处进一步详细介绍——最好的阅读起点可能是来自 Chromium 团队的 高级设计文档。

我想重构 Node 本机模块以支持 Electron 21+。我该怎么做？​

有两种方法可以重构本机模块以与 V8 内存笼子兼容。第一种是将外部创建的缓冲区复制到 V8 内存笼子中，然后再将它们传递给 JavaScript。这通常是一个简单的重构，但当缓冲区很大时，它可能会很慢。另一种方法是使用 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 并可能导致释放后使用错误。

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 项目将在 2021 年 12 月暂停一个月，然后在 2022 年 1 月恢复全速运行。

通过 GIPHY

12 月份保持不变的内容​

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

12 月份的不同之处​

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

为什么会发生这种情况？​

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

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

不。我们能够采取这一步，因为该项目状况良好。每个人都期待 2022 年，我们期待美好的事情发生！

从 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 版本目标是非 Extended Stable 版本（Chromium 的 Extended Stable 版本基于其偶数版本），我们需要更改我们最初的目标发布日期。但是，Electron 应用程序必须使用最新的 2 个主要版本的 Chromium 才能被 Microsoft Store 接受，这使得等待两个 Chromium 版本变得站不住脚。

有了这两个要求，我们的团队面临着一个时间困境。将 Electron 15 包含 Chromium M94 将允许应用程序开发人员使用 Chromium 的第一个 Extended Stable 版本；但是，它也会将 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。我们知道这是一个会影响许多应用程序和开发人员的变更，您的反馈对我们非常重要。我们想听到您的声音！