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

来自 GIPHY

12 月保持不变的事项​

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

12 月有所不同的事项​

1. 2024 年的最后一次稳定分支发布，包括 Electron 31、32 和 33，将于 12 月第一周进行。12 月不会有额外的计划发布。
2. 12 月最后两周不发布 Nightly 和 Alpha 版本。
3. 除少数例外，不进行 pull request 审核或合并。
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. 除少数例外，不进行 pull request 审核或合并。
4. 所有仓库都不会更新问题跟踪器。
5. 维护者不在 Discord 上提供调试帮助。
6. 不更新社交媒体内容。

展望未来​

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

2024 年见！

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

10 年后，来自 1192 位独立贡献者的 27,147 次提交，Electron 已成为当今构建桌面应用程序最流行的框架之一。这个里程碑是庆祝和回顾我们旅程的绝佳机会，并分享我们一路走来的经验。

没有所有为项目贡献时间和精力的人，就没有今天的我们。虽然源代码提交总是最显眼的贡献，但我们也必须感谢报告 bug、维护用户空间模块、提供文档和翻译以及参与网络空间 Electron 社区的人们。作为维护者，每一次贡献对我们来说都弥足珍贵。

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

我们是如何走到今天的？​

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

在一年内，Atom Shell 的功能和受欢迎程度开始大幅增长。大型公司、初创企业和个人开发者都开始使用它构建应用程序（一些早期采用者包括 Slack、GitKraken 和 WebTorrent），该项目也被恰当地重命名为 Electron。

从那时起，Electron 便开足马力，从未停歇。以下是 courtesy of 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 版本 (发布工作组)
• 升级 Chromium 和 Node.js (升级工作组)
• 监督公共 API 设计 (API 工作组)
• 确保 Electron 安全 (安全工作组)
• 运营网站、文档和工具 (生态系统工作组)
• 社区和企业外展 (外展工作组)
• 社区审核 (社区与安全工作组)
• 维护我们的构建基础设施、维护者工具和云服务 (基础设施工作组)

大约在我们转向治理模式的同时，我们也将 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++ 代码集合，构建时间一直是限制我们发布 bug 修复和新功能速度的因素。2020 年，我们部署了 Not Goma，这是一个针对 Google Goma 分布式编译器服务的自定义 Electron 后端。Not Goma 处理授权用户机器的编译请求，并将进程分布到后端的数百个核心上。它还缓存编译结果，以便编译相同文件的其他人只需下载预编译结果。

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

持续双因素认证​

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

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

我们构建了 CFA，为 npm 2FA 向任意 CI 作业提供基于时间的一次性密码 (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 的 backporting 过程。
• 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 将是支持低于 Windows 10 版本的最后一个 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 之前的版本将接受与 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. 所有仓库都不会更新问题跟踪器。
4. 维护者不在 Discord 上提供调试帮助。
5. 不更新社交媒体内容。

为何会这样？​

鉴于 2021 年十二月静默月 的成功，我们希望在 2022 年再次实施。12 月对大多数公司来说仍然是一个安静的月份，所以我们希望给维护者一个充电的机会。大家都期待着 2023 年，我们也期待着好事情！我们鼓励其他项目考虑类似的措施。

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

展望未来，团队仍将全力致力于定期快速的 Chromium 升级发布、bug 修复以及使 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 的继任者（尽管名称如此，但 BrowserView API 是 Electron 特有的代码，与 Chromium Views 无关）。通过暴露 WebContentsView，我们将拥有一个可复用的 View 对象，能够显示网页内容，为将 BrowserWindow 类纯 JavaScript 化并进一步消除代码复杂性打开了大门。

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

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

参考：electron/electron#35658

示例：带有 ScrollView 的可滚动网页内容​

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

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

参与其中​

您是 Electron 应用开发者并对这些 API 提案感兴趣吗？虽然我们还没有准备好接收额外的 RFCs，但请继续关注未来的更多详情！

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 内存笼 (Memory Cage)，这对某些原生模块有影响。

在 Electron 21 中，我们将跟随 Chrome 在 Chrome 103 中采取相同措施的决定，在 Electron 中启用 V8 沙箱指针 (sandboxed pointers)。这对原生模块有一些影响。此外，我们之前在 Electron 14 中启用了相关的技术，指针压缩 (pointer compression)。当时我们没有太多谈论它，但指针压缩对 V8 堆的最大大小有影响。

这两项技术启用后，对安全性、性能和内存使用有显著益处。然而，启用它们也有一些缺点。

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

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

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

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

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

常见问题解答 (FAQ)​

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

在 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 引擎中找到一个 bug。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 进行垃圾回收，并可能导致 use-after-free 错误。

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 前缀 (prefix) 改变了。另一个例子，这次是针对调试符号：

之前： 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 中提交一个 issue 并告知我们。

当前 的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. 所有仓库都不会更新问题跟踪器。
4. 维护者不在 Discord 上提供调试帮助。
5. 不更新社交媒体内容。

为何会这样？​

简而言之，虽然维护者们对项目感到满意并积极参与，但世界累了。12 月对于大多数公司来说是一个平静的月份，所以我们希望给维护者们一个充电的机会。我们鼓励其他项目考虑采取类似的措施。

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

不用。我们之所以能采取这一步，是因为项目状态良好。每个人都期待着 2022 年，我们预期会发生很多好事！

从 2021 年 9 月开始，Electron 将每 8 周发布一个新的主要稳定版本。

2019 年，Electron 改为 12 周的发布周期，以匹配 Chromium 的 6 周发布周期。最近，Chrome 和 Microsoft 都宣布了变化，这使我们重新考虑 Electron 当前的发布节奏：

1. Chromium 计划从 2021 年 9 月 21 日的 Chrome 94 开始，每 4 周发布一个新的里程碑版本。这种发布节奏还每 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 月 Electron 19 发布，我们还将把支持版本政策从最新的三个版本扩展到最新的四个版本。这意味着即使您无法立即更改您的升级计划，较旧的 Electron 版本仍将收到安全更新和修复。

回应关切​

我们提前很长时间发布这篇文章是有原因的，远早于这次发布周期更改的预定时间。我们知道更快的发布周期将对 Electron 应用产生实际影响——其中一些应用可能已经觉得我们的主要版本发布节奏很激进了。

我们在下方试图回应一些常见关切：

❓ 为什么要做这个改变？为什么不保持 12 周的发布节奏？​

为了在 Electron 中提供最新的 Chromium 版本，我们的计划需要跟踪 Chromium 的计划。关于 Chromium 发布周期的更多信息可以在这里找到。

此外，当前的 12 周发布节奏无法满足 Microsoft Store 新的提交要求。即使是使用 Electron 最新稳定版本的应用，也可能经历大约两周的时间段，期间其应用可能因新的安全要求而被拒绝。

每个新的 Chromium 版本都包含新功能、错误修复/安全修复以及 V8 改进。我们希望您作为应用开发者能及时获得这些更改，因此我们的稳定版发布日期将继续与 Chromium 的每次稳定版发布保持一致。作为应用开发者，您将比以前更快地获得新的 Chromium 和 V8 功能及修复。

❓ 现有的 12 周发布计划已经很快了。团队正在采取哪些措施使升级更容易？​

更频繁发布的一个优势是发布版本更小。我们理解升级 Electron 的主要版本可能很困难。我们希望较小的发布版本每次引入的主要 Chromium 和 Node 更改以及破坏性更改会更少。

❓ 未来的 Electron 版本是否会有 alpha 版本可用？​

目前没有计划支持永久性的 alpha 版本。此 alpha 版本仅用于 Electron 15，作为在缩短的发布周期内帮助开发者更容易升级的一种方式。

❓ Electron 会延长支持的版本数量吗？​

从现在直到 2022 年 5 月 Electron 19 发布，我们将把支持的版本政策从最新的三个版本扩展到最新的四个版本。Electron 19 发布后，我们将恢复支持最新的三个主要版本，以及 beta 和 nightly 版本。

有问题吗？​

📨 如果您有问题或疑虑，请发送邮件至 info@electronjs.org 或加入我们的 Discord。我们知道这是一个会影响许多应用和开发者的变化，您的反馈对我们非常重要。我们期待听到您的声音！