6 篇带有“Electron 内部原理”标签的文章

在过去的几周里，我们收到了几个关于新 WebView2 和 Electron 之间区别的问题。

两个团队都表达了让网络技术在桌面上发挥最佳作用的目标，并且正在讨论共享的全面比较。

Electron 和 WebView2 都是快速发展且不断发展的项目。我们整理了 Electron 和 WebView2 之间在目前存在的相似之处和差异的简要快照。

架构概述​

Electron 和 WebView2 都从 Chromium 源代码构建以渲染 Web 内容。严格来说，WebView2 从 Edge 源代码构建，但 Edge 是使用 Chromium 源代码的分支构建的。Electron 不与 Chrome 共享任何 DLL。WebView2 二进制文件硬链接到 Edge（截至 Edge 90 的稳定通道），因此它们共享磁盘和一些工作集。有关更多信息，请参阅 常青分发模式。

Electron 应用程序始终捆绑并分发它们开发的 Electron 的确切版本。WebView2 在分发中有两个选项。您可以捆绑您的应用程序开发的 WebView2 库的确切版本，也可以使用可能已经存在于系统上的共享运行时版本。WebView2 为每种方法提供工具，包括在缺少共享运行时的情况下的引导安装程序。WebView2 从 Windows 11 开始内置。

捆绑其框架的应用程序负责更新这些框架，包括次要安全版本。对于使用共享 WebView2 运行时的应用程序，WebView2 有自己的更新程序，类似于 Chrome 或 Edge，独立于您的应用程序运行。更新应用程序的代码或其任何其他依赖项仍然是开发人员的责任，与 Electron 相同。Electron 和 WebView2 都不是由 Windows Update 管理的。

Electron 和 WebView2 都继承了 Chromium 的多进程架构 - 即，一个主进程与一个或多个渲染器进程通信。这些进程完全独立于系统上运行的其他应用程序。每个 Electron 应用程序都是一个单独的进程树，包含一个根浏览器进程、一些实用程序进程以及零个或多个渲染进程。使用相同 用户数据文件夹 的 WebView2 应用程序（如应用程序套件）共享非渲染器进程。使用不同数据文件夹的 WebView2 应用程序不共享进程。

• ElectronJS 进程模型

  

• 基于 WebView2 的应用程序进程模型

  

在此处阅读有关 WebView2 的进程模型 和 Electron 的进程模型 的更多信息。

Electron 提供用于常见桌面应用程序需求的 API，例如菜单、文件系统访问、通知等。WebView2 是一个旨在集成到应用程序框架（如 WinForms、WPF、WinUI 或 Win32）中的组件。WebView2 不通过 JavaScript 提供 Web 标准之外的操作系统 API。

Node.js 集成到 Electron 中。Electron 应用程序可以使用渲染器和主进程中的任何 Node.js API、模块或 node-native-addon。WebView2 应用程序不假定应用程序的其余部分是用哪种语言或框架编写的。您的 JavaScript 代码必须通过应用程序主机进程代理任何操作系统访问。

Electron 致力于保持与 Web API 的兼容性，包括从 Fugu 项目 开发的 API。我们有一个 Electron 的 Fugu API 兼容性快照。WebView2 维护了一个类似的 与 Edge 的 API 差异列表。

Electron 为 Web 内容提供了一个可配置的安全模型，从完全访问到完全沙箱。WebView2 内容始终处于沙箱模式。Electron 有关于选择您的安全模型的 全面的安全文档。WebView2 也有 安全最佳实践。

Electron 源代码在 GitHub 上维护和提供。应用程序可以修改并构建自己的 Electron 品牌。WebView2 源代码在 GitHub 上不可用。

快速总结

性能讨论​

在渲染您的网页内容时，我们预计 Electron、WebView2 和任何其他基于 Chromium 的渲染器之间的性能差异很小。我们为有兴趣研究潜在性能差异的人创建了使用 Electron、C++ + WebView2 和 C# + WebView2 构建的应用程序的脚手架。

在渲染网页内容之外，还有一些差异会起作用，来自 Electron、WebView2、Edge 和其他方面的人士表示有兴趣进行详细的比较，包括 PWA。

进程间通信 (IPC)​

我们想立即强调一个差异，因为我们认为它通常是 Electron 应用程序中的性能考虑因素。

在 Chromium 中，浏览器进程充当沙盒渲染器和系统其余部分之间的 IPC 代理。虽然 Electron 允许非沙盒渲染进程，但许多应用程序选择启用沙盒以增加安全性。WebView2 始终启用沙盒，因此对于大多数 Electron 和 WebView2 应用程序，IPC 会影响整体性能。

即使 Electron 和 WebView2 具有相似的进程模型，但底层的 IPC 也有所不同。在 JavaScript 和 C++ 或 C# 之间通信需要编组，最常见的是编组为 JSON 字符串。JSON 序列化/解析是一项昂贵的操作，IPC 瓶颈会对性能产生负面影响。从 Edge 93 开始，WV2 将使用 CBOR 处理网络事件。

Electron 通过 MessagePorts API 支持任意两个进程之间的直接 IPC，该 API 利用结构化克隆算法。在进程之间发送对象时，利用此技术的应用程序可以避免支付 JSON 序列化税。

总结​

Electron 和 WebView2 有许多差异，但不要期望它们在渲染网页内容方面的性能有太大差异。最终，应用程序的架构和 JavaScript 库/框架对内存和性能的影响比其他任何因素都大，因为无论它在哪里运行，Chromium 就是 Chromium。

特别感谢 WebView2 团队审阅这篇文章，并确保我们对 WebView2 架构有最新的了解。他们欢迎任何关于该项目的反馈。

Electron 用 C++ 或 Objective-C 编写的功能如何进入 JavaScript，从而可供最终用户使用？

背景​

Electron是一个 JavaScript 平台，其主要目的是降低开发人员构建健壮的桌面应用程序的门槛，而无需担心特定于平台的实现。然而，在其核心，Electron 本身仍然需要用给定的系统语言编写特定于平台的功能。

实际上，Electron 为您处理本机代码，以便您可以专注于单个 JavaScript API。

但这怎么运作呢？Electron 用 C++ 或 Objective-C 编写的功能如何进入 JavaScript，从而可供最终用户使用？

要追溯此路径，让我们从 app 模块开始。

通过打开 lib/ 目录中的 app.ts 文件，您会在顶部附近找到以下代码行

const binding = process.electronBinding('app');

此行直接指向 Electron 用于将其 C++/Objective-C 模块绑定到 JavaScript 以供开发人员使用的机制。此函数由 ElectronBindings 类的头文件和实现文件创建。

process.electronBinding​

这些文件添加了 process.electronBinding 函数，其行为类似于 Node.js 的 process.binding。process.binding 是 Node.js require() 方法的较低级实现，只不过它允许用户 require 本机代码而不是用 JS 编写的其他代码。此自定义的 process.electronBinding 函数赋予了从 Electron 加载本机代码的能力。

当顶层 JavaScript 模块（如 app）需要此本机代码时，如何确定和设置该本机代码的状态？哪些方法暴露给 JavaScript？属性呢？

native_mate​

目前，可以在 native_mate 中找到此问题的答案：它是 Chromium gin 库的一个分支，它使得在 C++ 和 JavaScript 之间编组类型变得更容易。

在 native_mate/native_mate 中，有一个 object_template_builder 的头文件和实现文件。这使得我们能够在本机代码中形成模块，其形状符合 JavaScript 开发人员的预期。

mate::ObjectTemplateBuilder​

如果我们将每个 Electron 模块视为一个 object，那么就更容易理解为什么我们要使用 object_template_builder 来构建它们。此类构建在 V8 公开的类之上，V8 是 Google 的开源高性能 JavaScript 和 WebAssembly 引擎，用 C++ 编写。V8 实现了 JavaScript (ECMAScript) 规范，因此其本机功能实现可以直接与 JavaScript 中的实现相关联。例如，v8::ObjectTemplate 为我们提供了没有专用构造函数和原型的 JavaScript 对象。它使用 Object[.prototype]，在 JavaScript 中等效于 Object.create()。

要查看实际操作，请查看 app 模块的实现文件 atom_api_app.cc。底部是以下代码

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

在上面的代码行中，在 mate::ObjectTemplateBuilder 上调用了 .SetMethod。可以在 ObjectTemplateBuilder 类的任何实例上调用 .SetMethod，以使用以下语法在 JavaScript 中设置 Object 原型上的方法

.SetMethod("method_name", &function_to_bind)

这是 JavaScript 等效的

function App{}
App.prototype.getGPUInfo = function () {
  // implementation here
}

此类还包含用于设置模块属性的函数

.SetProperty("property_name", &getter_function_to_bind)

或

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

这些反过来将是 Object.defineProperty 的 JavaScript 实现

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

和

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

可以创建使用原型和属性形成的 JavaScript 对象，正如开发人员所期望的那样，并且可以更清楚地推理在此较低系统级别实现的功能和属性！

在何处实现任何给定模块方法的决定本身是一个复杂且经常不确定的决定，我们将在以后的文章中介绍。

Electron 基于 Google 的开源 Chromium，该项目不一定是为其他项目设计的。这篇文章介绍了 Chromium 如何作为库构建以供 Electron 使用，以及构建系统多年来的演变。

使用 CEF​

Chromium Embedded Framework (CEF) 是一个将 Chromium 转换为库的项目，并提供基于 Chromium 代码库的稳定 API。Atom 编辑器和 NW.js 的早期版本都使用 CEF。

为了维护稳定的 API，CEF 隐藏了 Chromium 的所有细节，并使用自己的接口封装了 Chromium 的 API。因此，当我们需要访问底层的 Chromium API（例如将 Node.js 集成到网页中）时，CEF 的优势就变成了障碍。

因此，最终，Electron 和 NW.js 都切换为直接使用 Chromium 的 API。

作为 Chromium 的一部分构建​

即使 Chromium 不正式支持外部项目，但其代码库是模块化的，并且很容易基于 Chromium 构建一个最小的浏览器。提供浏览器界面的核心模块称为内容模块。

要使用内容模块开发项目，最简单的方法是将项目作为 Chromium 的一部分构建。这可以通过首先检出 Chromium 的源代码，然后将项目添加到 Chromium 的 DEPS 文件中来完成。

NW.js 和 Electron 的早期版本都使用这种方式进行构建。

缺点是，Chromium 是一个非常大的代码库，需要非常强大的机器才能构建。对于普通笔记本电脑来说，这可能需要 5 个多小时。因此，这极大地影响了可以为项目做出贡献的开发人员数量，并且也使开发速度变慢。

将 Chromium 构建为单个共享库​

作为内容模块的用户，Electron 在大多数情况下不需要修改 Chromium 的代码，因此改进 Electron 构建的显而易见的方法是将 Chromium 构建为共享库，然后在 Electron 中与其链接。这样，开发人员在为 Electron 贡献代码时不再需要构建所有 Chromium。

libchromiumcontent 项目由 @aroben 为此目的创建。它将 Chromium 的内容模块构建为共享库，然后提供 Chromium 的头文件和预构建的二进制文件供下载。可以在此链接中找到 libchromiumcontent 初始版本的代码。

brightray 项目也作为 libchromiumcontent 的一部分而诞生，它在内容模块周围提供了一个薄层。

通过一起使用 libchromiumcontent 和 brightray，开发人员可以快速构建一个浏览器，而无需深入了解构建 Chromium 的细节。并且它消除了构建项目对快速网络和强大机器的要求。

除了 Electron，还有其他基于 Chromium 的项目也以这种方式构建，例如 Breach 浏览器。

过滤导出的符号​

在 Windows 上，一个共享库可以导出的符号数量是有限制的。随着 Chromium 代码库的增长，libchromiumcontent 中导出的符号数量很快就超过了限制。

解决方案是在生成 DLL 文件时过滤掉不需要的符号。它的工作原理是为链接器提供一个 .def 文件，然后使用脚本来判断命名空间下的符号是否应该被导出。

通过这种方法，即使 Chromium 不断添加新的导出符号，libchromiumcontent 仍然可以通过剥离更多符号来生成共享库文件。

组件构建​

在讨论 libchromiumcontent 中采取的后续步骤之前，首先有必要介绍一下 Chromium 中的组件构建概念。

作为一个庞大的项目，Chromium 在构建时的链接步骤非常耗时。通常，当开发人员进行小的更改时，需要 10 分钟才能看到最终输出。为了解决这个问题，Chromium 引入了组件构建，它将 Chromium 中的每个模块构建为独立的共享库，因此最终链接步骤所花费的时间变得不明显。

发布原始二进制文件​

随着 Chromium 的不断增长，Chromium 中导出的符号非常多，即使内容模块和 Webkit 的符号也超过了限制。仅仅通过剥离符号是不可能生成可用的共享库的。

最终，我们不得不发布 Chromium 的原始二进制文件，而不是生成单个共享库。

如前所述，Chromium 中有两种构建模式。由于发布了原始二进制文件，我们必须在 libchromiumcontent 中发布两种不同的二进制文件分发版。一种称为 static_library 构建，其中包括 Chromium 的普通构建生成的每个模块的所有静态库。另一种是 shared_library，其中包括组件构建生成的每个模块的所有共享库。

在 Electron 中，Debug 版本与 libchromiumcontent 的 shared_library 版本链接，因为它下载量小，并且在链接最终可执行文件时花费的时间很少。Electron 的 Release 版本与 libchromiumcontent 的 static_library 版本链接，因此编译器可以生成对调试很重要的完整符号，并且链接器可以进行更好的优化，因为它知道需要哪些目标文件，哪些不需要。

因此，对于正常的开发，开发人员只需要构建 Debug 版本，这不需要良好的网络或强大的机器。虽然 Release 版本需要更好的硬件才能构建，但它可以生成优化更好的二进制文件。

gn 更新​

作为世界上最大的项目之一，大多数普通系统都不适合构建 Chromium，因此 Chromium 团队开发了自己的构建工具。

早期版本的 Chromium 使用 gyp 作为构建系统，但它的缺点是速度慢，并且其配置文件对于复杂的项目来说变得难以理解。经过多年的发展，Chromium 切换到 gn 作为构建系统，它速度更快，并且具有清晰的架构。

gn 的改进之一是引入了 source_set，它表示一组目标文件。在 gyp 中，每个模块都由 static_library 或 shared_library 表示，并且对于 Chromium 的普通构建，每个模块都会生成一个静态库，并将它们链接到最终的可执行文件中。通过使用 gn，每个模块现在只生成一堆目标文件，最终的可执行文件只是将所有目标文件链接在一起，因此不再生成中间静态库文件。

然而，这种改进给 libchromiumcontent 带来了很大的麻烦，因为 libchromiumcontent 实际上需要中间静态库文件。

解决这个问题的第一个尝试是修补 gn 以生成静态库文件，这解决了问题，但远非一个合适的解决方案。

第二次尝试是由 @alespergl 进行的，从目标文件列表中生成自定义静态库。它使用了一个技巧，首先运行一个虚拟构建来收集生成的目标文件列表，然后通过将该列表馈送给 gn 来实际构建静态库。它仅对 Chromium 的源代码进行了最小的更改，并保持了 Electron 的构建架构不变。

总结​

如您所见，与将 Electron 作为 Chromium 的一部分进行构建相比，将 Chromium 构建为一个库需要付出更大的努力并需要持续维护。然而，后者消除了构建 Electron 对强大硬件的要求，从而使更大范围的开发人员能够构建和为 Electron 做出贡献。这个努力完全值得。

作为一种具有垃圾回收功能的语言，JavaScript 使用户无需手动管理资源。但由于 Electron 托管此环境，因此它必须非常小心地避免内存和资源泄漏。

本文介绍了弱引用概念以及它们在 Electron 中如何用于管理资源。

弱引用​

在 JavaScript 中，无论何时将对象分配给变量，都会添加对该对象的引用。只要存在对该对象的引用，它将始终保留在内存中。一旦对该对象的所有引用都消失了，即不再有变量存储该对象，JavaScript 引擎将在下一次垃圾回收时回收内存。

弱引用是对对象的引用，它允许您获取对象，而不会影响它是否会被垃圾回收。当对象被垃圾回收时，您也会收到通知。这样就可以使用 JavaScript 管理资源了。

以 Electron 中的 NativeImage 类为例，每次调用 nativeImage.create() API 时，都会返回一个 NativeImage 实例，并且它在 C++ 中存储图像数据。一旦您完成该实例，并且 JavaScript 引擎 (V8) 垃圾回收了该对象，就会调用 C++ 中的代码来释放内存中的图像数据，因此用户无需手动管理此操作。

另一个例子是窗口消失问题，它直观地展示了当对窗口的所有引用都消失时窗口是如何被垃圾回收的。

在 Electron 中测试弱引用​

由于该语言没有分配弱引用的方法，因此无法在原始 JavaScript 中直接测试弱引用。JavaScript 中与弱引用相关的唯一 API 是 WeakMap，但由于它只创建弱引用键，因此无法知道对象何时被垃圾回收。

在 v0.37.8 之前的 Electron 版本中，可以使用内部 v8Util.setDestructor API 来测试弱引用，该 API 会将弱引用添加到传递的对象，并在对象被垃圾回收时调用回调

// Code below can only run on Electron < v0.37.8.
var v8Util = process.atomBinding('v8_util');

var object = {};
v8Util.setDestructor(object, function () {
  console.log('The object is garbage collected');
});

// Remove all references to the object.
object = undefined;
// Manually starts a GC.
gc();
// Console prints "The object is garbage collected".

请注意，您必须使用 --js-flags="--expose_gc" 命令开关启动 Electron 才能公开内部 gc 函数。

该 API 在更高版本中被删除，因为 V8 实际上不允许在析构函数中运行 JavaScript 代码，并且在更高版本中这样做会导致随机崩溃。

remote 模块中的弱引用​

除了使用 C++ 管理本机资源外，Electron 还需要弱引用来管理 JavaScript 资源。一个例子是 Electron 的 remote 模块，它是一个远程过程调用 (RPC) 模块，允许从渲染器进程中使用主进程中的对象。

remote 模块的一个关键挑战是避免内存泄漏。当用户在渲染器进程中获取远程对象时，remote 模块必须保证该对象在渲染器进程中的引用消失之前一直存在于主进程中。此外，它还必须确保当渲染器进程中不再有对该对象的任何引用时，该对象可以被垃圾回收。

例如，如果没有正确的实现，以下代码将很快导致内存泄漏

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.nativeImage.createEmpty();
}

remote 模块中的资源管理很简单。每当请求一个对象时，都会向主进程发送一条消息，Electron 会将该对象存储在映射中并为其分配一个 ID，然后将该 ID 发送回渲染器进程。在渲染器进程中，remote 模块将接收该 ID 并使用代理对象将其包装起来，当代理对象被垃圾回收时，将向主进程发送消息以释放该对象。

以 remote.require API 为例，简化的实现如下所示

remote.require = function (name) {
  // Tell the main process to return the metadata of the module.
  const meta = ipcRenderer.sendSync('REQUIRE', name);
  // Create a proxy object.
  const object = metaToValue(meta);
  // Tell the main process to free the object when the proxy object is garbage
  // collected.
  v8Util.setDestructor(object, function () {
    ipcRenderer.send('FREE', meta.id);
  });
  return object;
};

在主进程中

const map = {};
const id = 0;

ipcMain.on('REQUIRE', function (event, name) {
  const object = require(name);
  // Add a reference to the object.
  map[++id] = object;
  // Convert the object to metadata.
  event.returnValue = valueToMeta(id, object);
});

ipcMain.on('FREE', function (event, id) {
  delete map[id];
});

具有弱值的映射​

使用之前的简单实现，remote 模块中的每次调用都将从主进程返回一个新的远程对象，并且每个远程对象都表示对主进程中对象的引用。

设计本身没有问题，但问题在于，当多次调用接收同一个对象时，会创建多个代理对象，对于复杂的对象，这会给内存使用和垃圾回收带来巨大的压力。

例如，以下代码：

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.getCurrentWindow();
}

它首先会使用大量内存创建代理对象，然后占用 CPU（中央处理器）进行垃圾回收并发送 IPC 消息。

一个明显的优化是缓存远程对象：当已经存在具有相同 ID 的远程对象时，将返回之前的远程对象，而不是创建新的对象。

这在 JavaScript core 的 API 中是无法实现的。使用普通的 map 来缓存对象会阻止 V8 对对象进行垃圾回收，而 WeakMap 类只能使用对象作为弱键。

为了解决这个问题，添加了一种以弱引用作为值的 map 类型，这非常适合缓存具有 ID 的对象。现在 remote.require 看起来像这样：

const remoteObjectCache = v8Util.createIDWeakMap()

remote.require = function (name) {
  // Tell the main process to return the meta data of the module.
  ...
  if (remoteObjectCache.has(meta.id))
    return remoteObjectCache.get(meta.id)
  // Create a proxy object.
  ...
  remoteObjectCache.set(meta.id, object)
  return object
}

请注意，remoteObjectCache 将对象存储为弱引用，因此当对象被垃圾回收时，无需删除该键。

原生代码​

对于对 Electron 中弱引用的 C++ 代码感兴趣的人，可以在以下文件中找到：

setDestructor API

• object_life_monitor.cc
• object_life_monitor.h

createIDWeakMap API

• key_weak_map.h
• atom_api_key_weak_map.h

这是解释 Electron 内部原理的系列文章的第二篇。如果您还没有阅读过关于事件循环集成的第一篇文章，请查看一下。

大多数人使用 Node 来开发服务器端应用程序，但由于 Node 丰富的 API 集和蓬勃发展的社区，它也非常适合作为嵌入式库。这篇文章解释了如何在 Electron 中将 Node 用作库。

构建系统​

Node 和 Electron 都使用 GYP 作为它们的构建系统。如果想将 Node 嵌入到您的应用程序中，您也必须使用它作为您的构建系统。

GYP 新手？在继续阅读本文之前，请先阅读本指南。

Node 的标志​

Node 源代码目录中的 node.gyp 文件描述了 Node 是如何构建的，以及大量的 GYP 变量，这些变量控制着 Node 的哪些部分被启用以及是否打开某些配置。

要更改构建标志，需要在项目的 .gypi 文件中设置变量。Node 中的 configure 脚本可以为您生成一些常见的配置，例如运行 ./configure --shared 将生成一个 config.gypi，其中包含指示 Node 构建为共享库的变量。

Electron 不使用 configure 脚本，因为它有自己的构建脚本。Node 的配置定义在 Electron 根源代码目录下的 common.gypi 文件中。

将 Node 与 Electron 链接​

在 Electron 中，Node 通过将 GYP 变量 node_shared 设置为 true 来作为共享库进行链接，因此 Node 的构建类型将从 executable 更改为 shared_library，并且包含 Node 的 main 入口点的源代码将不会被编译。

由于 Electron 使用 Chromium 附带的 V8 库，因此不使用 Node 源代码中包含的 V8 库。这是通过将 node_use_v8_platform 和 node_use_bundled_v8 都设置为 false 来完成的。

共享库或静态库​

与 Node 链接时，有两种选择：您可以将 Node 构建为静态库并将其包含在最终的可执行文件中，或者您可以将其构建为共享库并将其与最终的可执行文件一起发布。

在 Electron 中，Node 长期以来一直被构建为静态库。这使得构建简单，启用了最佳的编译器优化，并允许 Electron 在没有额外的 node.dll 文件的情况下进行分发。

然而，在 Chrome 切换到使用 BoringSSL 后，情况发生了变化。BoringSSL 是 OpenSSL 的一个分支，它删除了一些未使用的 API 并更改了许多现有的接口。因为 Node 仍然使用 OpenSSL，如果它们被链接在一起，编译器会由于符号冲突而生成大量的链接错误。

Electron 无法在 Node 中使用 BoringSSL，也无法在 Chromium 中使用 OpenSSL，因此唯一的选择是切换到将 Node 构建为共享库，并隐藏每个组件中的 BoringSSL 和 OpenSSL 符号。

此更改给 Electron 带来了一些积极的副作用。在此更改之前，如果您使用本机模块，则无法在 Windows 上重命名 Electron 的可执行文件，因为可执行文件的名称已硬编码在导入库中。在 Node 构建为共享库之后，此限制消失了，因为所有本机模块都链接到 node.dll，而 node.dll 的名称不需要更改。

支持本机模块​

Node 中的本机模块通过定义一个供 Node 加载的入口函数，然后从 Node 中搜索 V8 和 libuv 的符号来工作。这对于嵌入者来说有点麻烦，因为默认情况下，当 Node 构建为库时，V8 和 libuv 的符号是隐藏的，并且本机模块将无法加载，因为它们找不到符号。

因此，为了使本机模块工作，V8 和 libuv 符号在 Electron 中被公开。对于 V8，这是通过强制在 Chromium 的配置文件中公开所有符号来实现的。对于 libuv，这是通过设置 BUILDING_UV_SHARED=1 定义来实现的。

在您的应用程序中启动 Node​

完成所有构建和与 Node 链接的工作后，最后一步是在您的应用程序中运行 Node。

Node 没有提供太多用于将其自身嵌入到其他应用程序中的公共 API。通常，您可以直接调用node::Start 和 node::Init 来启动一个新的 Node 实例。但是，如果您正在构建一个基于 Node 的复杂应用程序，则必须使用像 node::CreateEnvironment 这样的 API 来精确控制每个步骤。

在 Electron 中，Node 以两种模式启动：在主进程中运行的独立模式（类似于官方 Node 二进制文件）和将 Node API 插入到网页中的嵌入模式。这方面的细节将在以后的文章中解释。

这是解释 Electron 内部原理的系列文章的第一篇。这篇文章介绍了如何在 Electron 中将 Node 的事件循环与 Chromium 集成。

之前有很多尝试使用 Node 进行 GUI 编程，例如用于 GTK+ 绑定的 node-gui 和用于 QT 绑定的 node-qt。但是它们都无法在生产环境中使用，因为 GUI 工具包有自己的消息循环，而 Node 使用 libuv 来实现自己的事件循环，并且主线程一次只能运行一个循环。因此，在 Node 中运行 GUI 消息循环的常用技巧是在一个很小的间隔内使用定时器来泵送消息循环，这使得 GUI 界面的响应速度变慢并占用大量 CPU 资源。

在开发 Electron 的过程中，我们也遇到了同样的问题，尽管是以相反的方式：我们必须将 Node 的事件循环集成到 Chromium 的消息循环中。

主进程和渲染进程​

在我们深入了解消息循环集成的细节之前，我将首先解释 Chromium 的多进程架构。

在 Electron 中，有两种类型的进程：主进程和渲染进程（实际上这非常简化，要获得完整的视图，请参阅多进程架构）。主进程负责诸如创建窗口之类的 GUI 工作，而渲染进程仅处理运行和渲染网页。

Electron 允许使用 JavaScript 来控制主进程和渲染进程，这意味着我们必须将 Node 集成到这两个进程中。

用 libuv 替换 Chromium 的消息循环​

我的第一次尝试是用 libuv 重新实现 Chromium 的消息循环。

对于渲染进程来说很容易，因为它的消息循环只监听文件描述符和定时器，而我只需要用 libuv 实现接口即可。

然而，对于主进程来说，它要困难得多。每个平台都有自己类型的 GUI 消息循环。macOS Chromium 使用 NSRunLoop，而 Linux 使用 glib。我尝试了很多技巧来从本机 GUI 消息循环中提取底层文件描述符，然后将它们提供给 libuv 进行迭代，但我仍然遇到了无法正常工作的极端情况。

因此，我最终添加了一个定时器来以很小的间隔轮询 GUI 消息循环。结果，该进程占用了恒定的 CPU 使用率，并且某些操作有很长的延迟。

在单独的线程中轮询 Node 的事件循环​

随着 libuv 的成熟，现在可以采用另一种方法。

将后端 fd 的概念引入到 libuv 中，它是一个文件描述符（或句柄），libuv 会轮询它来获取其事件循环。因此，通过轮询后端 fd，可以在 libuv 中有新事件时收到通知。

因此，在 Electron 中，我创建了一个单独的线程来轮询后端 fd，并且由于我使用的是系统调用进行轮询而不是 libuv API，因此它是线程安全的。并且每当 libuv 的事件循环中有新事件时，就会将一条消息发布到 Chromium 的消息循环，然后在主线程中处理 libuv 的事件。

通过这种方式，我避免了修补 Chromium 和 Node，并且在主进程和渲染进程中都使用了相同的代码。

代码​

您可以在 electron/atom/common/ 下的 node_bindings 文件中找到消息循环集成的实现。它可以很容易地重用于想要集成 Node 的项目。

更新：实现已移至 electron/shell/common/node_bindings.cc。