Electron 项目将在 2023 年 12 月暂停一个月，然后在 2024 年 1 月恢复正常运行。

via GIPHY

12 月将保持不变的内容​

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

12 月将有所不同的内容​

1. Electron 28.0.0 将于 12 月 5 日发布。Electron 28 发布后，12 月将不再发布新的稳定版本。
2. 12 月最后两周将不再发布夜间版和 Alpha 版。
3. 除少数例外情况外，将不再审核或合并拉取请求。
4. 任何存储库的错误跟踪器都不会更新。
5. 维护者将不再在 Discord 上提供调试帮助。
6. 社交媒体内容不会更新。

展望未来​

这是我们第三年进行平静期实验，到目前为止，我们在平衡一个月的休息时间与保持正常发布节奏之间取得了很大成功。因此，我们决定将此作为未来发布日历的常规部分。我们将在每年的最后一次稳定版本中添加一个提醒。

2024 年见！

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

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

如果没有所有为项目贡献时间和精力的人，我们今天将不会取得这样的成就。虽然源代码提交始终是最明显的贡献，但我们也必须承认那些报告错误、维护用户端模块、提供文档和翻译以及在整个网络空间参与 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。尽管最初的核心团队今天仍然在微软工作，但他们只是构成 Electron 治理的更大协作群体的一部分。²

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

社区​

开源的社区部分很难，特别是当您的外联团队是一群穿着写着“社区经理”外套的工程师时。也就是说，作为一个大型开源项目，意味着我们拥有大量用户，利用他们的能量来构建 Electron 的用户生态系统是维持项目健康的关键部分。

我们一直在做些什么来发展我们的社区存在？

构建虚拟社区​

• 在 2020 年，我们推出了我们的社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定使用一个更非正式的聊天平台，为维护者和 Electron 开发人员之间的讨论提供一个空间，并提供一般的调试帮助。
• 在 2021 年，我们在 @BlackHole1 的帮助下，建立了 Electron 中国 用户组。该组对于来自中国蓬勃发展的科技行业的 Electron 用户的增长至关重要，为他们在我们的英语空间之外提供了一个空间，让他们可以协作想法并讨论 Electron。我们还要感谢 cnpm 为他们在 npm 的中国镜像中支持 Electron 的每日构建版本所做的工作。

参与高曝光度的开源项目​

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

自动化所有事情！​

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

不是 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 向任意 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 的回退过程。
• 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。这与微软对 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 相关的 issue 和修复，直至每个版本线达到其支持生命周期的结束。
  • 这特别适用于 Electron 22、Electron 21 和 Electron 20。
• 与 Windows 7/8/8.1 相关的全新 issue 将被接受，适用于 Electron 23 之前的版本。
  • 任何更新的发行线都不会接受新的 issue。
• 一旦 Electron 22 达到其支持生命周期的结束，所有与 Windows 7/8/8.1 相关的现有 issue 将被关闭。

下一步​

如果您有任何问题或疑虑，请随时通过 [email protected] 与我们联系。您也可以在我们的官方 Electron Discord 中找到社区支持。

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

via GIPHY

12 月将保持不变的内容​

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

12 月将有所不同的内容​

1. 12 月没有新的稳定版发布。12 月最后两周没有夜间版和 Alpha 版发布。
2. 除少数例外情况外，将不再审核或合并拉取请求。
3. 任何存储库的错误跟踪器都不会更新。
4. 维护者将不再在 Discord 上提供调试帮助。
5. 社交媒体内容不会更新。

为什么会出现这种情况？​

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

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

展望未来，该团队仍将全力致力于发布定期且快速的 Chromium 升级、修复 bug 以及使 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 元素。这将阻止应用程序不得不拼凑 Web 内容。

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

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

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

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

如果您是使用 BrowserViews 在您的应用程序中进行开发的 Electron 开发者：不用担心，我们没有忘记您！我们计划使现有的 BrowserView 类成为 WebContentsView 的 shim，以在您过渡到更新的 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 堆的最大大小。

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

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

启用指针压缩的主要缺点是，V8 堆的大小限制为最大 4GB。关于这一点的具体细节有点复杂——例如，ArrayBuffers 与 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 的内存。

常见问题解答​

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

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

如果您在应用程序中没有使用任何原生 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 内存隔离兼容。第一种是复制外部创建的缓冲区到 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 月恢复正常运行。

via 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 计划从 2021 年 9 月 21 日的 Chrome 94 开始，每 4 周发布一个新的里程碑。这种发布节奏还每 8 周添加一个新的扩展稳定选项，其中将包含所有更新的安全修复程序。

2. Microsoft Store 将要求基于 Chromium 的应用不早于两个主要版本。例如，如果 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 的最新两个主要版本才能被接受到 Microsoft Store，这使得等待两个 Chromium 版本变得不可行。

面对这两个要求，我们的团队面临着时间上的困境。将 Electron 15 移至包含 Chromium M94 将允许应用开发者获得 Chromium 的第一个扩展稳定版本；然而，它也将使 Beta 版到稳定版的周期缩短到只有 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 应用产生实际影响，其中一些应用可能已经发现我们的主要发布节奏过于激进。

我们尝试在下面解决了一些常见的疑虑

❓ 为什么还要做出这种改变？为什么不保持 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 版本。

问题？​

📨 如果您有任何问题或疑虑，请发送邮件至[email protected]，或加入我们的 Discord。我们知道这是一个会影响许多应用和开发者的变化，您的反馈对我们非常重要。我们希望听到您的意见！

今天上午在OpenJS World 上，我们宣布 Electron 已正式从OpenJS 基金会 的孵化计划中毕业，现在是 OpenJS 基金会的影响项目。

Electron 于 2019 年 12 月加入孵化计划，参加了在蒙特利尔举行的最后一次 OpenJS 基金会全球会议。我们很高兴能够作为影响项目在 JavaScript 社区中发挥更大的作用，并继续与 OpenJS 基金会合作。

了解更多信息​

您可以在 OpenJSF 网站 上了解该基金会及其使命和成员。OpenJS 基金会托管了许多开源 JavaScript 项目，包括 jQuery、Node.js 和 webpack。它得到了包括 GoDaddy、Google、IBM、Intel、Joyent 和 Microsoft 在内的 30 家公司和最终用户成员的支持。

Electron 是一个开源框架，用于使用 Web 技术构建跨平台桌面应用程序。要详细了解 Electron 背后的团队以及他们的合作方式，请查看我们的 治理页面。

要开始使用 Electron 本身，请查看我们的 文档。