6 篇标记为“Electron Internals”的文章

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

两个团队都有一个明确的目标，那就是让 Web 技术在桌面上发挥出最佳水平，并且正在讨论进行一次全面的共享比较。

Electron 和 WebView2 都是快速发展和不断演进的项目。我们整理了 Electron 和 WebView2 截至目前的异同点的简要快照。

架构概述​

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

Electron 应用程序总是捆绑并分发其开发时使用的确切版本的 Electron。WebView2 有两种分发选项。您可以捆绑您的应用程序开发时使用的确切 WebView2 库，或者您可以使用系统上可能已存在的共享运行时版本。WebView2 为每种方法都提供了工具，包括一个引导安装程序，以防共享运行时缺失。从 Windows 11 开始，WebView2 随系统一同提供。

捆绑其框架的应用程序负责更新这些框架，包括次要安全版本。对于使用共享 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 原生插件。WebView2 应用程序不假设您的应用程序的其余部分是用哪种语言或框架编写的。您的 JavaScript 代码必须通过应用程序宿主进程代理任何操作系统访问。

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

Electron 具有可配置的网页内容安全模型，从完全访问到完全沙盒。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 是谷歌的开源高性能 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。 .SetMethod 可以在 ObjectTemplateBuilder 类的任何实例上调用，以在 JavaScript 中的对象原型上设置方法，语法如下

.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 项目本身并非专门为其他项目设计。这篇文章将介绍 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 构建一个最小化的浏览器。提供浏览器界面的核心模块称为 Content Module。

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

NW.js 和 Electron 的早期版本都采用了这种构建方式。

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

将 Chromium 构建为单个共享库​

作为 Content Module 的用户，Electron 在大多数情况下不需要修改 Chromium 的代码，因此改进 Electron 构建的一个显而易见的方法是将其构建为共享库，然后 Electron 再与之链接。这样，开发人员在为 Electron 贡献代码时就不再需要构建整个 Chromium。

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

brightray 项目也是作为 libchromiumcontent 的一部分诞生的，它在 Content Module 周围提供了一个精简的封装。

通过结合使用 libchromiumcontent 和 brightray，开发者无需深入了解 Chromium 的构建细节即可快速构建浏览器。并且消除了构建项目对快速网络和强大机器的要求。

除了 Electron 之外，还有其他 Chromium 驱动的项目也采用了这种方式构建，例如 Breach 浏览器。

过滤导出的符号​

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

解决方法是在生成 DLL 文件时过滤掉不需要的符号。它通过 向链接器提供一个 .def 文件，然后使用脚本 判断某个命名空间下的符号是否应该导出 来实现。

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

组件构建​

在介绍 libchromiumcontent 的下一步之前，首先介绍 Chromium 中的组件构建概念非常重要。

作为一个庞大的项目，Chromium 在构建时的链接步骤非常耗时。通常情况下，当开发人员进行一次小的改动时，可能需要 10 分钟才能看到最终输出。为了解决这个问题，Chromium 引入了组件构建，即将 Chromium 中的每个模块构建为独立的共享库，这样最终链接步骤所花费的时间就可以忽略不计了。

分发原始二进制文件​

随着 Chromium 的不断发展，Chromium 中导出的符号越来越多，即使是 Content Module 和 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 核心中的 API 无法实现这一点。使用普通映射表缓存对象会阻止 V8 对其进行垃圾回收，而 WeakMap 类只能使用对象作为弱键。

为了解决这个问题，添加了一种具有弱值作为引用的映射类型，这非常适合缓存带有 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 集和蓬勃发展的社区，它也非常适合作为嵌入式库。本文将介绍 Node 在 Electron 中如何被用作库。

构建系统​

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 中，通过将 GYP 变量 node_shared 设置为 true，Node 被链接为共享库。因此，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 中的工作方式是定义一个入口函数供 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 内部机制系列文章的第一篇。本文将介绍 Node 的事件循环是如何集成到 Electron 的 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 的成熟，可以采用另一种方法。

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

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

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

代码​

您可以在 electron/atom/common/ 目录下的 node_bindings 文件中找到消息循环集成的实现。对于想要集成 Node 的项目，可以轻松复用。electron/atom/common/

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