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. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
4. 任何代码仓库的 Issue Tracker 都不会有更新。
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. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
4. 任何代码仓库的 Issue Tracker 都不会有更新。
5. 维护者不会在 Discord 上提供调试帮助。
6. 社交媒体内容将暂停更新。

未来计划​

我们今年已经是第三年实施静默期实验了，到目前为止，我们在平衡一个月的休息时间与之后维持正常发布节奏方面取得了很大的成功。因此，我们决定将此作为我们未来发布日历的常规部分。我们仍将在每年的最后一个稳定版本发布时提醒大家。

2024 年再见！

electron/electron 仓库的首次提交是在 2013 年 3 月 13 日¹。

十年后的今天，Electron 已经成为最受欢迎的桌面应用程序构建框架之一，贡献者也从 1192 位独立贡献者增加了 27,147 个提交。这个里程碑是一个绝佳的机会来庆祝和反思我们迄今为止的旅程，并分享我们在过程中学到的经验。

没有所有投入时间和精力为该项目做出贡献的人，我们今天就不会在这里。尽管源代码提交总是最显而易见的贡献，但我们也必须承认那些报告错误、维护用户模块、提供文档和翻译以及参与到网络空间中的 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 版本（Releases WG）
• 升级 Chromium 和 Node.js（Upgrades WG）
• 监督公共 API 设计（API WG）
• 维护 Electron 的安全（Security WG）
• 运营网站、文档和工具（Ecosystem WG）
• 社区和企业推广（Outreach WG）
• 社区管理（Community & Safety WG）
• 维护我们的构建基础设施、维护者工具和云服务（Infrastructure WG）

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

虽然这个模式并非完美，但它在全球疫情和持续的宏观经济逆风中很好地支持了我们。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。

社区​

开源的社区部分很难，尤其是在您的外展团队是一打穿着写着“社区经理”的雨衣的工程师时。也就是说，作为一个大型开源项目，我们有很多用户，利用他们的能量为 Electron 构建用户生态系统是维持项目健康的关键部分。

我们为发展我们的社区做了些什么？

建立虚拟社区​

• 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 Summer of Code 学生。 @aryanshridhar 完成了出色的工作，重构了 Electron Fiddle 的核心版本加载逻辑，并将其打包器迁移到了 webpack。

自动化一切！​

如今，Electron 治理团队约有 30 名活跃的维护者。其中全职贡献者不到一半，这意味着有很多工作需要分配。我们保持一切顺利运行的诀窍是什么？我们的座右铭是计算机便宜，而人力时间昂贵。本着工程师的典型作风，我们开发了一套自动支持工具来让我们的生活更轻松。

Not Goma​

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

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

持续因子认证 (Continuous Factor Authentication)​

Continuous Factor Authentication (CFA) 是 npm 双因素身份验证 (2FA) 系统之上的一层自动化，我们将其与 semantic-release 结合使用，以管理我们各种 @electron/ npm 包的安全和自动化发布。

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

我们构建了 CFA，以便为任意的 CI 作业提供基于时间的一次性密码 (TOTP) 用于 npm 2FA，这使我们能够利用 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 标签将补丁挑选到以前的发布分支，来自动化 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 将在 Electron 23 中停止对 Windows 7、Windows 8 和 Windows 8.1 的支持。这与 Microsoft 对 Windows 7 ESU 和 Windows 8.1 扩展支持 的支持终止日期（2023 年 1 月 10 日）相符。

Electron 22 将是最后一个支持 Windows 10 以下版本的 Electron 主要版本。Windows 7/8/8.1 将不再受 Electron 23 及更高主要版本的支持。旧版 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 的版本，将接受与 Windows 7/8/8.1 相关的新问题。
  • 任何更新的发布产品线将不再接受新问题。
• 一旦 Electron 22 达到其支持周期终点，所有与 Windows 7/8/8.1 相关的现有问题都将被关闭。

下一步​

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

Electron 项目将在 2022 年 12 月暂停，并于 2023 年 1 月恢复全速运行。

来自 GIPHY

12 月份保持不变的事项​

1. 零日漏洞和其他与重大安全相关的版本将根据需要发布。安全事件应通过 SECURITY.md 报告。
2. 行为准则的报告和管理工作将继续进行。

12 月份会有所不同的事项​

1. 12 月份不发布稳定版本。12 月最后两周不发布 Nightly 和 Alpha 版本。
2. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
3. 任何代码仓库的 Issue Tracker 都不会有更新。
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 内部交互，而这些内部资源在纯粹（未经修改）的 Electron 中是无法访问的。通过在 C API 层公开这些资源，这些代码可以作为原生模块与 Electron 一起存在，从而可能减轻应用程序开发者的维护负担。

公开 Chromium 的 UI 层（Views API）​

在底层，Chrome 用户界面（UI）的非网站部分（例如工具栏、标签页或按钮）是用一个名为 Views 的框架构建的。Views API 提案将此框架的一部分作为 JavaScript 类引入 Electron，最终目标是允许开发者在其 Electron 应用程序中创建非 Web UI 元素。这将避免应用程序不得不 hack Web 内容。

使这套新 API 成熟的基础工作正在进行中。以下是我们可以在不久的将来看到的一些首批成果。

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

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

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

如果您是 Electron 应用开发者，并且正在使用 BrowserViews：请放心，我们没有忘记您！我们计划将现有的 BrowserView 类变成 WebContentsView 的一个包装器，为您向较新的 API 过渡提供缓冲。

参见：electron/electron#35658

示例：使用 ScrollView 对 Web 内容进行滚动​

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

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

如何参与​

您是对这两个 API 提案感兴趣的 Electron 应用开发者吗？虽然我们还没有准备好接收额外的 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 中，我们将启用 V8 沙盒指针，遵循 Chrome 在 Chrome 103 中启用相同功能的决定。这对原生模块有一些影响。此外，我们之前启用了一项相关技术，即 指针压缩，在 Electron 14 中。当时我们没怎么谈论它，但指针压缩对 V8 的最大堆大小有影响。

这两种技术在启用后，在安全性、性能和内存使用方面都有显著的好处。然而，启用它们也有一些缺点。

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

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

Electron Upgrades 工作组 (WG) 认为指针压缩和 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 模块，您是安全的——纯 JavaScript 无法触发此崩溃。此更改仅影响那些分配 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 内存隔离区兼容。第一种是复制外部创建的缓冲区到 V8 内存隔离区，然后再传递给 JavaScript。这通常是一个简单的重构，但当缓冲区很大时可能会变慢。另一种方法是使用 V8 的内存分配器来分配您打算最终传递给 JavaScript 的内存。这有点复杂，但可以避免复制，从而提高大型缓冲区的性能。

为了使这一点更具体，这里有一个使用外部 ArrayBuffer 的 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 或 Stable 版本。12 月的最后两周不会发布 Nightly 版本。
2. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
3. 任何代码仓库的 Issue Tracker 都不会有更新。
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 的应用程序的发布版本不得早于最新两个主要版本。例如，如果最新的 Chromium 主要版本是 85，那么任何基于 Chromium 的浏览器都必须是 Chromium 版本 83 或更高版本。此规则包括 Electron 应用程序。

从2021年9月开始，Electron将每8周发布一个新的主要稳定版本，以匹配Chromium的8周长期支持（Extended Stable）版本。

我们第一个使用Chromium长期支持版本（Extended Stable）的发布将是2021年9月21日的Electron 15。

我们知道发布周期调整将影响其他下游应用程序，因此我们希望尽快告知我们的开发者社区。请继续阅读以了解有关我们2021年发布计划的更多详细信息。

Electron 15：临时 Alpha 版本​

鉴于我们最初的 Electron 15 版本针对的是非扩展稳定版本（Chromium 的扩展稳定版本基于其偶数版本），我们需要更改我们最初的发布日期。但是，Electron 应用程序必须使用最新的两个 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商店的提交要求。

为了进一步帮助应用程序开发者，在 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。我们知道这是一个将影响许多应用程序和开发者的更改，您的反馈对我们非常重要。我们希望听到您的声音！