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

通过 GIPHY

十二月会保持不变的内容​

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

十二月会发生变化的内容​

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

2025 年见！

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

通过 GIPHY

十二月会保持不变的内容​

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

十二月会发生变化的内容​

1. Electron 28.0.0 将于 12 月 5 日发布。在 Electron 28 之后，12 月将不会有新的稳定版本发布。
2. 十二月的最后两周没有 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，我们转向了与 Chromium 匹配的常规 12 周主要版本发布节奏。这个决定是项目心态的转变，将“拥有最新的 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 的核心版本加载逻辑并将其 bundler 迁移到 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 是为了为任意 CI 作业提供用于 npm 2FA 的基于时间的一次性密码 (TOTP)，从而使我们能够利用 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 23 开始，Electron 将结束对 Windows 7、Windows 8 和 Windows 8.1 的支持。

根据 Chromium 的弃用策略，从 Electron 23 开始，Electron 将结束对 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 相关的稳定受支持版本的问题和修复，直到每个版本达到其支持周期的结束。
  • 这专门适用于 Electron 22、Electron 21 和 Electron 20。
• Electron 23 之前的 Electron 版本将接受与 Windows 7/8/8.1 相关的新问题。
  • 任何较新版本都不接受新问题。
• 一旦 Electron 22 达到其支持周期的结束，所有与 Windows 7/8/8.1 相关的现有问题都将被关闭。

下一步是什么​

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

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

通过 GIPHY

十二月会保持不变的内容​

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

十二月会发生变化的内容​

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

为什么会这样？​

由于 2021 年十二月安静月的成功，我们希望在 2022 年再次推出它。十二月仍然是大多数公司的安静月份，因此我们希望给我们的维护者一个充电的机会。每个人都期待着 2023 年，我们预计会有好事发生！我们鼓励其他项目考虑类似的措施。

上个月，Electron 的维护者小组在加拿大温哥华聚会，讨论 2023 年及以后项目的方向。在会议室的四天里，核心维护者和受邀的协作者讨论了新的举措、维护痛点和总体项目健康状况。

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

变革性的新 API​

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

今年，我们推动了两项主要提案，这些提案有可能为 Electron 应用程序解锁新的功能维度。这些提案是高度实验性的，但以下是您可以期待的先睹为快！

新的原生插件增强功能（C API）​

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

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

许多 Electron 应用程序维护自己的分支，以直接与 Chromium 内部组件交互，否则使用 vanilla（未修改）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 的继任者（尽管名称如此，但它是与 Chromium Views 无关的 Electron 特定代码）。通过公开 WebContentsView，我们将拥有一个可重用的 View 对象，该对象可以显示 Web 内容，从而为使 BrowserWindow 类成为纯 JavaScript 并消除更多代码复杂性打开了大门。

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

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

请参阅：electron/electron#35658

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

我们的朋友 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 将允许在 Web 和 Electron 上使用 WebAssembly 构建的应用程序使用明显超过 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 中发生的 其他类型的沙箱 混淆，因此我将坚持使用术语“内存笼”。

有一种相当常见的 V8 漏洞利用，其过程如下

1. 在 V8 的 JIT 引擎中找到一个错误。 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，并可能导致释放后使用错误。

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

这里重要的是 Hostname 更改了，并且 /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

十二月会保持不变的内容​

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

十二月会发生变化的内容​

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 周一次的扩展稳定版选项，其中将包含所有更新的安全修复程序。

2. 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：临时 Alpha 版​

鉴于我们最初的 Electron 15 发布目标是非扩展稳定版（Chromium 的扩展稳定版基于其偶数版本），我们需要更改我们最初的目标发布日期。 但是，Electron 应用程序必须使用 Chromium 的最新 2 个主要版本才能被 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 年发布计划​

以下是我们 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 19 发布之前，我们将把我们的支持版本策略从最新的三个版本扩展到最新的四个 Electron 版本，直到 2022 年 5 月。 在 Electron 19 发布后，我们将恢复为 支持最新的三个主要版本，以及 beta 版和 nightly 版发布。

问题？​

📨 如果您有任何问题或疑虑，请发送邮件至 info@electronjs.org 或 加入我们的 Discord。 我们知道这是一个会影响许多应用程序和开发者的更改，您的反馈对我们非常重要。 我们想听取您的意见！