2024年12月Electron项目将进入暂停状态，然后在2025年1月全速恢复。

via GIPHY

12月保持不变的内容​

1. 必要时将发布零日和其他与安全相关的主版本。 Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

12月变动的内容​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. 12 月的最后两周没有 Nightly 和 Alpha 版本。
3. 除了少数例外，不会合并请求的审核或合并。
4. 任何仓库上都不会有问题跟进更新。
5. 维护人员不会提供 Discord 调试帮助。
6. 社交媒体暂停更新内容。

See you all in 2025!

The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY

12月保持不变的内容​

1. 必要时将发布零日和其他与安全相关的主版本。 Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

12月变动的内容​

1. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable releases in December.
2. 12 月的最后两周没有 Nightly 和 Alpha 版本。
3. 除了少数例外，不会合并请求的审核或合并。
4. 任何仓库上都不会有问题跟进更新。
5. 维护人员不会提供 Discord 调试帮助。
6. 社交媒体暂停更新内容。

Going forward​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

2013年3月13日¹ 首次被提交到 electron/electron 仓库。

经过10年和来自 1192 位贡献者的 27147 次提交之后，Electron 已成为如今构建桌面应用程序最受欢迎的框架之一。 这个里程碑是一个完美的机会，可以庆祝和回顾我们迄今为止的旅程，并分享我们沿途所学到的东西。

如果没有每个人都献出时间和努力为该项目做出贡献，我们今天就不会在这里了。 尽管源代码提交总是最显著的贡献，但我们还必须承认那些报告错误、维护用户空间模块、提供文档和翻译，并参与网络空间中的 Electron 社区的人所做出的努力。 对于我们作为维护者来说，每一份贡献都是无价之宝。

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

我们怎么发展到现在的？​

Atom Shell 是为 GitHub Atom 编辑器 打造的基础框架，该编辑器于 2014 年 4 月公开发布 beta 版。 它是基于当时一些以网页为基础的桌面端框架 (node-webkit and Chromium Embedded Framework) 从头开始构建的替代方案。 它有一个杀手级功能：嵌入 Node.js 和 Chromium，为网页 技术提供一个强大的桌面运行时间。

一年之内，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 版本。 到 2021 年，Chromium 加快了发布速度，每 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 server 的社区。 我们之前在 Atom 的论坛上有一个版块，但决定有一个更非正式的消息传递平台，让维护者和 Electron 开发人员之间有一个讨论的空间，并获得一般的调试帮助。
• 2021 年，我们在 @BlackHole1 的帮助下建立了 Electron China 用户群。 这个群体在中国蓬勃发展的科技界中对 Electron 用户的增长起了重要作用，为他们在我们的英语语言的范畴之外提供了一个创意合作、讨论 Electron 的空间。 我们还要感谢 cnpm 为支持 Electron 在他们的中文镜像中为 npm 所做的工作。

参与高知名度的开源项目​​

• 自 2019 年以来，我们每年都会庆祝 Hacktoberest 。 Hacktoberfest 是由 DigitalOcean 组织的每年一度的开源庆典，每年我们都会有数十名热情的贡献者加入其中，希望在开源软件上留下自己的印记。
• 在 2020 年，我们参加了首次举行的 Google Season of Docs 活动，与 @bandantonio 合作重新设计了 Electron 的新用户教程流程。
• 2022年，我们第一次指导 Google Summer of Code 的学生。 @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

将所有东西自动化！​

今天，Electron 的维护有大约 30 名积极的维护者。 我们中只有不到一半的人是全职贡献者，这意味着还有很多工作需要做。 我们怎么才能让一切顺利进行呢？ 我们的座右铭是计算机便宜，人的时间是昂贵的。 按照典型的工程师风格，我们开发了一套自动化支持工具来使我们的生活更轻松。

Not Goma​​

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

自从启用 Not Goma 以来，维护者的编译时间已经从几个小时缩短到几分钟的级别。 拥有稳定的互联网连接成为贡献者编译 Electron 的最低要求！

Continuous Factor Authentication​

Continuous Factor Authentication (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 标签，在先前的发行分支上尝试挑选补丁，从而自动化 Electron 的回溯过程。
• Roller 可以自动化 Electron 的 Chromium 和 Node.js 依赖项的滚动升级过程。
• Cation 是我们针对 electron/electron PR 的状态检查机器人。

总的来说，我们的这些小机器人为我们的开发者生产力带来了巨大的提升！

下一步是什么？​

在我们进入项目的第二个十年时，您可能会问：Electron 接下来会发生什么？

我们将继续保持同步 Chromium 的发布节奏，每 8 周发布 Electron 新的主要版本，以保持该框架更新到 Web 平台和 Node.js 的最新技术，同时维护企业级程序的稳定性和安全性

通常，我们会在计划即将实现时公布相关消息。 如果你想跟进未来的新版本、功能和项目更新的最新动态，你可以阅读我们的博客，并关注我们的社交媒体账户(Twitter 和 Mastodon)！

Electron 将在 Electron23 中开始结束 Windows 7, Windows 8 和 Windows 8.1 的支持。

In line with Chromium’s deprecation policy, Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23. This matches Microsoft's end of support for Windows 7 ESU and Windows 8.1 extended on January 10th, 2023.

Electron 22 will be the last Electron major version to support Windows versions older than 10. Electron 23 及以后的主要版本将不支持 Windows 7/8/8.1。 Older versions of Electron will continue to function on Windows 7, and we will continue to release patches for Electron the 22.x series until May 30 2023, when Electron will end support for 22.x (according to our support timeline).

为什么要废弃它？​

Electron 遵循计划中的Chromium 弃置策略，它将不支持Chromium 109 (在这里阅读更多关于 Chromium 的时间表)。 Electron 23 将包含 Chromium 110, 它不支持旧版本的Windows。

因此含有Chromium 108的Electron 22将是最后一个支持版本。

弃用时间表​

The following is our planned deprecation timeline:

• 2022 年 12 月：Electron 团队将度过一段假期，此时将不会有大的动向。
• January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
• 2023 年 2 月 7 日: Electron 23 将发布。
• February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
• 2023: Electron 22 迎来其支持周期的终结。

这对开发者意味着什么：

• The Electron team will accept issues and fixes related to Windows 7/8/8.1 for stable supported lines, until each line reaches the end of its support cycle.
  • This specifically applies to Electron 22, Electron 21 and Electron 20.
• New issues related to Windows 7/8/8.1 will be accepted for Electron versions older than Electron 23.
  • New issues will not be accepted for any newer release lines.
• Once Electron 22 has reached the end of its support cycle, all existing issues related to Windows 7/8/8.1 will be closed.

下一步​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. 您也可以在我们官方的 Electron Discord 中找到社区支持。

2022年12月Electron项目将进入暂停状态，然后在2023年1月全速恢复。

通过 GIPHY

12月保持不变的内容​

1. 必要时将发布零日和其他与安全相关的主版本。 安全事件应该通过 SECURITY.md 报告。
2. 行为准则报告和审核将继续。

12月变动的内容​

1. 12 月没有新的稳定版。 12 月的最后两周没有 Nightly 和 Alpha 版本。
2. 除了少数例外，不会合并请求的审核或合并。
3. 任何仓库上都不会有问题跟进更新。
4. 维护人员不会提供 Discord 调试帮助。
5. 社交媒体暂停更新内容。

为什么会发生这种情况？​

With the success of December Quiet Month 2021, we wanted to bring it back for 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 提案将这个框架的一部分作为 Electron 中的 JavaScript 类引入，最终目标是允许开发人员为其 Electron 应用程序创建非 Web UI 元素。 这将避免应用程序不得不将网页内容集中在一起。

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

示例：将窗口模型重置为 WebContentsView​

我们计划的第一次更改是在 Electron 的 API 中显示 Chrome 的 WebContentsView。这将 是我们现有的 BrowsView API 的继承者(尽管该名称是 Electron 指定的代码 与 Chromium 视图无关)。 随着 WebContentsView 暴露，我们将有一个可重用的 View 对象 可以显示网页内容，为使 BrowserWindow 类成为纯粹的 JavaScript 打开了大门。 更多的消除了代码复杂性。

尽管此更改并未为应用程序开发人员提供很多新功能，但它是一个大型重构，消除了许多底层代码，简化了 Chromium 升级并减少主要版本之间出现新错误的风险。

如果您是一个使用 BrowserViews 的 Electron 开发者，请勿担心，我们没有忘记您！ 我们计划将现有的 BrowserView 类变成一个 WebContentsView 的垫片（shim），以便在您过渡到较新的 API 时提供一个缓冲。

见: electron/electron#35658

示例：使用 ScrollView 滚动网页​

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

尽管这个新的 API 实现了一个较小的功能，但该团队的最终目标是建立 一套实用的视图组件，可以作为一个工具包来构建更复杂的非 HTML 接口。

加入我们​

你是 Electron 应用程序的开发者，对这些 API 提案感兴趣吗？ 虽然我们还没有准备好接收更多的 RFC，但请继续关注未来的更多细节!

Electron Forge v6 稳定发布​

自从该框架诞生以来，Electron 的构建工具生态系统在很大程度上是由社区驱动的。 社区驱动的，由许多小型的单用途包组成(例如 electron-installer, 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沙盒指针， Electron中，Chrome 决定在Chrome 103中执行相同的操作。 这对原生模块有一定的影响。 此外，我们曾在 Electron 14 中启用了 指针压缩 相关技术。 我们当时没有对此进行过多地讨论，但指针压缩对V8最大堆大小有影响。

这两种技术一旦启用，将对安全、性能和内存使用大有裨益。 但是，启用它们也有一些缺点。

启用沙盒指针的主要缺点是，不再允许进行指向外部 ("off-heap") 内存 的数组缓冲区的操作。 这意味着在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的内存。

常见问题 (FAQ)​

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

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

如果你没有在应用中使用任何原生 Node 模块，那么你是安全的 - 目前没有办法从纯 JS 触发此崩溃。 此更改仅影响原生 Node 模块，这些模块在 V8 堆之外分配内存（例如，使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存。 这是一个相当罕见的用例，但有些模块确实使用这种技术，并且这些模块需要重构才能与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_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 is changing its primary S3 bucket, you may need to update your build scripts

What is happening?

A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Examples are included below:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib After: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb After: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

Again, the hostname changed and the /atom-shell prefix was changed.

How might this impact you?

Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.

For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.

What about existing data?

Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.

The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.

2021年12月Electron项目将进入暂停状态，然后在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 计划从2021年9月21日的 Chrome 94 开始每4周发布一个新的里程碑。此版本节奏还每8周添加新的"扩展稳定"选项，其中包含所有更新的安全修补程序。

2. 微软应用商店要求 基于Chromium应用的版本号不得低于最新发行版本2个版本号。 例如，如果最新发布的Chromium主版本号为85，任何基于Chromium的应用其所用版本必须为83或更高。 以上规则包含Electron应用。

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

我们的第一个发行版Electron 15将会随Chromium扩展稳定版在2021年9月21日释出。

需要注意的是，版本发行频率的改变会影响下游应用程序的开发，我们想让我们的开发者社区尽快知晓此次改变。 请阅读我们的2021开发计划以获取更多详情。

Electron 15：临时 Alpha 内测版本​

基于我们的Electron15初始版本针对的是Chromium的非扩展稳定版(其扩展稳定版基于偶数版本号)，我们需要改变我们的初始目标发行日期。 然而，一款Electron的app必须使用最近两个版本以内的Chromium以便能被微软商店收录，这项新规定会使得等待两个新版本变得不可持续。

伴随着这两项要求，我们的团队也面临着时间规划上的挑战。 推进Electron 15以包括Chromium的M94版本会使得应用开发者们能快速获取最新的Chromium扩展稳定版；然而这也会使得公测版到稳定版的开发周期缩短到只有3周。

为了有利于此次变动，Electron将会提供一个临时的内测版本，并仅限于Electron 15系列的发行版。 本内测版将给与开发者们更多时间，用这款比每日版更稳定的版本去测试和规划他们的Eletron15。

Electron 15系列内测版本频道将会于2021年7月21日开通。 It will transition to a beta release on September 1st, 2021 with a stable release target of September 21st, 2021. 在那之后的Electron发行版将不再包含内测系列。

2021 发行计划​

以下是我们当前的2021发行计划:

添加 alpha 通道将 Electron 15 发布前的开发时间从 3 周延长到 9 周 - 更接近我们新的 8 周周期，同时仍满足 Windows 应用商店提交的要求。

为了进一步帮助应用程序开发人员， 从2021年的剩余时间到2022年5月，我们还将把我们支持的版本政策从最新的3个版本扩展到最新的4个版本的Electron。 这意味着即使您无法立即更改升级计划，旧版本的Electron仍将收到安全更新和修复程序。

解决疑虑​

在安排此发布周期更改之前，我们发布这篇文章是有原因的。 我们知道，更快的发布周期将对Electron应用程序产生真正的影响 - 其中一些应用程序可能已经认为我们的主要发布节奏过于频繁。

我们试图解决以下常见问题：

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

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

此外，目前12周的发布节奏将无法满足Microsoft应用商店的新提交要求。 即使是最新稳定版本的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。 我们知道这是一个将影响许多应用程序和开发者的变化，您的反馈对我们非常重要。 我们希望收到您的来信！