从 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 相关的 issue。
• 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 的 Electron 版本。
  • 对于任何更新的发行分支，将不再接受新的 issue。
• 一旦 Electron 22 达到其支持周期的结束，所有与 Windows 7/8/8.1 相关的现有 issue 将被关闭。

后续步骤​

如果您有任何疑问或疑虑，请随时发送邮件至 [email protected]。您也可以在我们的官方 Electron Discord 中找到社区支持。

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

via GIPHY

12 月份哪些内容保持不变​

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

12 月份哪些内容有所不同​

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

为什么会这样？​

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

我们很高兴地宣布 Electron Forge v6.0.0 现已可用！此版本标志着自 2018 年以来 Forge 的第一个主要版本，并将该项目从 electron-userland 移至 Github 上的主 electron 组织。

继续阅读以了解新功能以及您的应用如何采用 Electron Forge！

什么是 Electron Forge？​

Electron Forge 是一个用于打包和分发 Electron 应用程序的工具。它将 Electron 的构建工具生态系统统一到一个可扩展的接口中，以便任何人都可以轻松上手创建 Electron 应用。

主要特性包括：

• 📦 应用程序打包和代码签名
• 🚚 可自定义的 Windows、macOS 和 Linux 安装程序（DMG、deb、MSI、PKG、AppX 等）
• ☁️ 用于云提供商的自动化发布流程（GitHub、S3、Bitbucket 等）
• ⚡️ 易于使用的 webpack 和 TypeScript 模板
• ⚙️ 原生 Node.js 模块支持
• 🔌 可扩展的 JavaScript 插件 API

v6 中的新功能？​

完全重写​

从 v1 到 v5，Electron Forge 基于现已停止维护的 electron-compile 项目。Forge 6 是该项目的完整重写，采用新的模块化架构，可以扩展以满足任何 Electron 应用程序的需求。

在过去几年中，Forge v6.0.0-beta 已实现了与 v5 的功能 parity，代码 churn 也大大减少，使该工具可以进行普遍采用。

官方支持​

历史上，Electron 维护者对构建工具一直持中立态度，将此任务留给各种社区包。然而，随着 Electron 作为项目的成熟，新 Electron 开发人员越来越难以理解他们需要哪些工具来构建和分发他们的应用程序。

为了帮助指导 Electron 开发人员进行分发流程，**我们已决定将 Forge 作为 Electron 的官方开箱即用的构建管道**。

在过去的一年中，我们一直在将 Forge 逐步集成到官方 Electron 文档中，并且最近已将 Forge 从其旧的 electron-userland/electron-forge 存储库迁移到 electron/forge 存储库。现在，我们终于准备好向公众发布 Electron Forge 了！

入门​

初始化新的 Forge 项目​

可以使用 create-electron-app CLI 脚本搭建新的 Electron Forge 项目。

yarn create electron-app my-app --template=webpack
cd my-app
yarn start

npm init electron-app@latest my-app -- --template=webpack
cd my-app
npm start

该脚本将在 my-app 文件夹中创建一个 Electron 项目，该项目具有完整的 JavaScript 打包和预配置的构建管道。

有关更多信息，请参阅 Forge 文档中的 入门指南。

导入现有项目​

Electron Forge CLI 还包含一个用于导入现有 Electron 项目的命令。

cd my-app
yarn add --dev @electron-forge/cli
yarn electron-forge import

cd my-app
npm install --save-dev @electron-forge/cli
npm exec --package=@electron-forge/cli -c "electron-forge import"

当您使用 import 命令时，Electron Forge 将添加一些核心依赖项并创建一个新的 forge.config.js 配置文件。如果您有任何现有的构建工具（例如 Electron Packager、Electron Builder 或 Forge 5），它将尝试迁移尽可能多的设置。您可能需要手动迁移一些现有的配置。

可以在 Forge 的 导入文档中找到手动迁移的详细信息。如果您需要帮助，请访问 我们的 Discord 服务器！

为什么切换到 Forge？​

如果您已经拥有用于打包和发布 Electron 应用程序的工具，采用 Electron Forge 的好处仍然可能大于最初的切换成本。

我们认为使用 Forge 有两个主要好处：

1. **Forge 会在 Electron 支持后立即获得新的应用程序构建功能。**在这种情况下，您无需自行连接新的工具支持，也不需要等到其他软件包最终实现该支持后再进行升级。有关最新示例，请参阅 macOS 通用二进制文件和 ASAR 完整性检查。

2. **Forge 的多包架构使其易于理解和扩展。**由于 Forge 由许多具有明确职责的较小包组成，因此更容易跟踪代码流程。此外，Forge 的可扩展 API 设计意味着您可以编写自己的额外构建逻辑，使其与提供的配置选项分开，以满足高级用例。有关编写自定义 Forge 插件、生成器和发布者的更多详细信息，请参阅文档的 扩展 Electron Forge部分。

重大更改​

Forge 6 已经在 beta 阶段运行了很长时间，其发布节奏也逐渐放缓。但是，我们在 2022 年下半年加速了开发，并在最近几个版本中推动了一些最终的重大更改，以便在 v6.0.0 稳定版本发布之前完成。

如果您是 Electron Forge 6 beta 用户，请参阅 v6.0.0 GitHub 发行说明，以了解最近 beta 版（>=6.0.0-beta.65）中进行的重大更改列表。

可以在存储库的 CHANGELOG.md中找到完整的更改和提交列表。

提交您的反馈！​

告诉我们您的需求！Electron Forge 团队始终致力于构建更符合用户需求的项目。

您可以通过提交功能请求、发布 问题或只是告知我们您的反馈来帮助我们改进 Electron Forge！您也可以加入 官方 Electron Discord 服务器，其中有一个专门用于 Electron Forge 讨论的频道。

如果您想对 https://forge.electron.js.cn 上的 Forge 文档提供任何反馈，我们有一个与 electron-forge/electron-forge-docs 存储库同步的 GitBook 实例。

上个月，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 元素。这将防止应用程序不得不将 Web 内容拼凑在一起。

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

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

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

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

如果您是 Electron 开发人员，并在您的应用程序中使用 BrowserView：不用担心，我们还没有忘记您！我们计划将现有的 BrowserView 类设为 WebContentsView 的垫片，以便在您过渡到较新的 API 时提供缓冲。

参见：electron/electron#35658

示例：使用ScrollView实现可滚动的 Web 内容​

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

虽然此新 API 满足了单个较小的功能，但该团队最终的目标是构建一组实用程序 View 组件，这些组件可用作构建更复杂的非 HTML 界面工具包。

参与进来​

您是 Electron 应用程序开发人员，对这些 API 建议中的任何一个感兴趣吗？虽然我们还没有准备好接收其他 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.0.0 已发布！它包括对 Chromium 106、V8 10.6 和 Node.js 16.16.0 的升级。阅读以下内容以获取更多详细信息！

Electron 团队很高兴地宣布 Electron 21.0.0 发布！您可以通过 npm install electron@latest 使用 npm 安装它，或从我们的 发布网站 下载它。继续阅读以了解有关此版本的详细信息。

如果您有任何反馈，请在 Twitter 上与我们分享，或加入我们的社区 Discord！错误和功能请求可以在 Electron 的 问题跟踪器 中报告。

重要更改​

堆栈更改​

• Chromium 106
  • Chrome 106 中的新增功能
  • Chrome 105 中的新增功能
  • DevTools 106 中的新增功能
  • DevTools 105 中的新增功能
• Node.js 16.16.0
  • Node 16.16.0 博客文章
• V8 10.6

新功能​

• 添加了webFrameMain.origin。 #35534
• 添加了新的WebContents.ipc 和WebFrameMain.ipc API。 #35231
• 添加了对类似面板行为的支持。窗口可以浮动在全屏应用程序之上。 #34388
• 添加了对 macOS 应用程序来自 APNs 的推送通知的支持。 #33574

重大更改和 API 更改​

以下是 Electron 21 中引入的重大更改。

启用 V8 内存沙箱​

Electron 21 启用了 V8 沙箱指针，遵循 Chrome 的 在 Chrome 103 中做出相同决定的决定。这对原生模块有一些影响。此功能具有性能和安全优势，但也对原生模块施加了一些新的限制，例如，使用指向外部（“堆外”）内存的 ArrayBuffer。请参阅 此博客文章 以获取更多信息。 #34724

重构 webContents.printToPDF​

重构了webContents.printToPDF 以与 Chromium 的无头实现保持一致。有关更多信息，请参阅 #33654。

有关这些更改和未来更改的更多信息，可以在 计划中的重大更改 页面上找到。

18.x.y 版本支持结束​

根据项目的 支持策略，Electron 18.x.y 已达到支持结束。鼓励开发人员和应用程序升级到 Electron 的较新版本。

接下来是什么​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。

您可以在此处找到 Electron 的公开时间表。

有关未来更改的更多信息，可以在 计划中的重大更改 页面上找到。

Electron 20.0.0 已发布！它包括对 Chromium 104、V8 10.4 和 Node.js 16.15.0 的升级。阅读以下内容以获取更多详细信息！

Electron 团队很高兴地宣布 Electron 20.0.0 发布！您可以通过 npm install electron@latest 使用 npm 安装它，或从我们的 发布网站 下载它。继续阅读以了解有关此版本的详细信息，并请分享您可能有的任何反馈！

重要更改​

新功能​

• 在 Windows 上添加了沉浸式深色模式。 #34549
• 添加了对类似面板行为的支持。窗口可以浮动在全屏应用程序之上。 #34665
• 更新了 Windows 控件叠加按钮，使其在 Windows 11 上的外观和感觉更原生。 #34888
• 除非指定了nodeIntegration: true 或sandbox: false，否则渲染器现在默认情况下会被沙盒化。 #35125
• 在使用 nan 构建原生模块时添加了安全措施。 #35160

堆栈更改​

• Chromium 104
  • Chrome 104 中的新增功能
  • Chrome 103 中的新增功能
  • DevTools 中的新增功能
• Node.js 16.15.0
  • Node 16.15.0 博客文章
• V8 10.4

重大更改和 API 更改​

以下是 Electron 20 中引入的重大更改。有关这些更改和未来更改的更多信息，可以在 计划中的重大更改 页面上找到。

默认值已更改：没有nodeIntegration: true 的渲染器默认情况下会被沙盒化​

以前，指定了预加载脚本的渲染器默认为未沙盒化。这意味着默认情况下，预加载脚本可以访问 Node.js。在 Electron 20 中，此默认值已更改。从 Electron 20 开始，渲染器将默认情况下被沙盒化，除非指定了nodeIntegration: true 或sandbox: false。

如果您的预加载脚本不依赖于 Node，则无需执行任何操作。如果您的预加载脚本依赖于 Node，则要么重构它们以从渲染器中删除 Node 用法，要么为相关的渲染器显式指定sandbox: false。

已修复：nan 原生模块中的自发崩溃​

在 Electron 20 中，我们更改了与原生模块相关的两个项目

1. V8 标头现在默认使用c++17。此标志已添加到 electron-rebuild 中。
2. 我们修复了一个问题，该问题会导致依赖于 nan 的原生模块中出现缺少包含文件导致的自发崩溃。

为了获得最大的稳定性，我们建议在重建原生模块（特别是依赖于 nan 的模块）时使用 node-gyp >=8.4.0 和 electron-rebuild >=3.2.9。有关更多信息，请参阅 electron #35160 和 node-gyp #2497。

已移除：Linux 上的.skipTaskbar​

在 X11 上，skipTaskbar 会向 X11 窗口管理器发送_NET_WM_STATE_SKIP_TASKBAR 消息。Wayland 没有直接的等效项，并且已知的解决方法具有不可接受的权衡（例如，GNOME 中的 Window.is_skip_taskbar 需要不安全模式），因此 Electron 无法在 Linux 上支持此功能。

17.x.y 版本的支持结束​

根据项目的支持策略，Electron 17.x.y 已达到支持结束日期。鼓励开发人员和应用程序升级到更新版本的 Electron。

接下来是什么​

在短期内，您可以预期团队将继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每 2 个月发布具有这些组件新版本的新 Electron 主要版本。

您可以在此处找到 Electron 的公开时间表。

有关未来更改的更多信息，可以在 计划中的重大更改 页面上找到。

Electron 21 及更高版本将启用 V8 内存沙箱，这对某些原生模块有影响。

在 Electron 21 中，我们将启用 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 将允许使用 WebAssembly 在 Web 和 Electron 中构建的应用程序使用超过 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 19.0.0 已发布！它包含对 Chromium 102、V8 10.2 和 Node.js 16.14.2 的升级。阅读以下内容以了解更多详细信息！

Electron 团队很高兴地宣布 Electron 19.0.0 发布！您可以通过 npm install electron@latest 使用 npm 安装它，或从我们的发布网站下载它。继续阅读以了解有关此版本的详细信息，并请分享您的任何反馈！

重要更改​

Electron 发布节奏变更​

该项目正在恢复其早期支持最新三个主要版本的策略。请参阅我们的版本控制文档，以获取有关 Electron 版本控制和支持的更多详细信息。之前曾短暂支持四个主要版本，以帮助用户适应从 Electron 15 开始的新发布节奏。您可以在此处阅读完整详细信息。

堆栈更改​

• Chromium 102
  • Chrome 102 中的新增功能
  • Chrome 101 中的新增功能
• Node.js 16.14.2
  • Node 16.14.2 博客文章
• V8 10.2

重大更改和 API 更改​

以下是 Electron 19 中引入的重大更改。有关这些更改和未来更改的更多信息，可以在计划中的重大更改页面上找到。

Linux 上不支持：.skipTaskbar​

BrowserWindow 构造函数选项skipTaskbar在 Linux 上不再受支持。在#33226中更改。

已删除 WebPreferences.preloadURL​

已从 WebPreferences 中删除半文档化的preloadURL属性。#33228。应改用WebPreferences.preload。

15.x.y 和 16.x.y 的支持结束​

Electron 14.x.y 和 15.x.y 均已达到支持结束。这使Electron 恢复到其现有策略，即支持最新的三个主要版本。鼓励开发人员和应用程序升级到更新版本的 Electron。

接下来是什么​

在短期内，您可以预期团队将继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每 2 个月发布具有这些组件新版本的新 Electron 主要版本。

您可以在此处找到 Electron 的公开时间表。

有关未来更改的更多信息，可以在 计划中的重大更改 页面上找到。

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-zcbenzS3 存储桶不会被主动删除。但是，我们无法保证该存储桶将保留多长时间。我们强烈建议尽快更新以目标新的存储桶。

Electron 18.0.0 已发布！它包含对 Chromium 100、V8 10.0 和 Node.js 16.13.2 的升级。阅读以下内容以了解更多详细信息！

Electron 团队很高兴地宣布 Electron 18.0.0 发布！您可以通过 npm install electron@latest 使用 npm 安装它，或从我们的发布网站下载它。继续阅读以了解有关此版本的详细信息，并请分享您的任何反馈！

重要更改​

Electron 发布节奏变更​

从 Electron 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。您可以在此处阅读完整详细信息。

此外，Electron 已将支持的版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月。请参阅我们的版本控制文档，以获取有关 Electron 中版本控制的更多详细信息。2022 年 5 月之后，我们将恢复支持最新的三个版本。

堆栈更改​

• Chromium 100
  • Chrome 100 中的新增功能
• Node.js 16.13.2
  • Node 16.13.2 博客文章
• V8 10.0

突出显示的功能​

• 添加了ses.setCodeCachePath() API 用于设置代码缓存目录。#33286
• 删除了基于旧BrowserWindowProxy的window.open实现。这也从webPreferences中删除了nativeWindowOpen选项。#29405
• 向WebContents添加了“focus”和“blur”事件。#25873
• 在 macOS 上添加了替换菜单角色：showSubstitutions、toggleSmartQuotes、toggleSmartDashes、toggleTextReplacement。#32024
• 向app.requestSingleInstanceLock()流程添加了first-instance-ack事件，允许用户从第一个实例无缝地将数据传输到第二个实例。#31460
• 在setBackgroundColor中添加了对更多颜色格式的支持。#33364

请参阅18.0.0 发行说明，以获取新功能和更改的完整列表。

重大更改和 API 更改​

以下是 Electron 18 中引入的重大更改。有关这些更改和未来更改的更多信息，可以在计划中的重大更改页面上找到。

已删除：nativeWindowOpen​

在 Electron 15 之前，window.open默认情况下使用BrowserWindowProxy进行模拟。这意味着window.open('about:blank')无法用于打开可同步脚本化的子窗口，以及其他不兼容性。从 Electron 15 开始，nativeWindowOpen已默认启用。

请参阅Electron 中 window.open 的文档以获取更多详细信息。在#29405中删除。

14.x.y 的支持结束​

根据项目的支持策略，Electron 14.x.y 已达到支持结束。鼓励开发人员和应用程序升级到更新版本的 Electron。

从 Electron 15 开始，我们将支持的版本从最新的三个版本更改为最新的四个版本，直到 Electron 19 发布的 2022 年 5 月。Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持更改是我们新的节奏更改的一部分。请参阅我们的博客文章以获取完整详细信息。

接下来是什么​

在短期内，您可以预期团队将继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每 2 个月发布具有这些组件新版本的新 Electron 主要版本。

您可以在此处找到 Electron 的公开时间表。

有关未来更改的更多信息，可以在 计划中的重大更改 页面上找到。