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 已成为当今构建桌面应用程序最流行的框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路走来所学到的东西的绝佳机会。

如果没有每个人投入时间和精力来为项目做出贡献，我们今天就不会在这里。尽管源代码提交始终是最可见的贡献，但我们还必须承认那些报告错误、维护用户区模块、提供文档和翻译以及参与整个网络空间 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 版本 (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 基金会。尽管最初的核心团队今天仍在 Microsoft 工作，但他们只是构成 Electron 治理的更大协作者群体的一部分。²

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

社区​

开源的社区部分很难，尤其当您的外展团队是由十几位穿着写着“社区经理”风衣的工程师组成时。也就是说，作为一个大型开源项目，意味着我们有很多用户，利用他们的力量为 Electron 构建用户领域生态系统是维持项目健康的关键部分。

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

构建虚拟社区​

• 2020 年，我们推出了我们的社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定拥有一个更非正式的消息平台，以便维护者和 Electron 开发人员之间进行讨论，并提供一般的调试帮助。
• 2021 年，在 @BlackHole1 的帮助下，我们成立了 Electron 中国 用户组。该小组对于 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 的最低要求！

持续因素身份验证​

持续因素身份验证 (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 上运行，我们将继续为 22.x 系列的 Electron 发布补丁，直到 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 相关的现有问题都将关闭。

下一步是什么？​

如果您有任何问题或疑虑，请随时发送电子邮件至 [email protected]。您还可以在我们的官方 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 应用程序维护自己的 fork，以便直接与 Chromium 内部组件交互，否则这些组件将无法通过 vanilla（未修改）的 Electron 访问。通过在 C API 层中公开这些资源，此代码可以作为原生模块与 Electron 一起存在，从而可能减轻应用程序开发人员的维护负担。

公开 Chromium 的 UI 层（Views API）​

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

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

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

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

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

如果您是在应用程序中使用 BrowserView 的 Electron 开发人员：别担心，我们没有忘记您！我们计划将现有的 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 中，我们将启用 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

这里重要的是 主机名 发生了变化，并且 /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 周一次的新扩展稳定版选项，其中将包含所有更新的安全修复程序。

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 版到稳定版的周期缩短到只有 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 是否会延长支持的版本数量？​

在 2022 年 5 月 Electron 19 发布之前，我们将把支持的版本策略从最新的三个版本延长到最新的四个 Electron 版本。在 Electron 19 发布之后，我们将恢复到支持最新的三个主要版本，以及 beta 和 nightly 版本。

问题？​

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