6 篇帖子已标记 “Electron 内部原理”

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

两个团队都有明确的目标，即让 Web 技术在桌面上达到最佳状态，并且正在讨论共享的综合比较。

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 更新管理。

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 上不可用。

快速摘要

性能讨论​

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

在 Web 内容渲染之外，存在一些差异，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 有许多差异，但不应期望它们在渲染 Web 内容方面的性能有太大差异。最终，应用程序的架构和 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)

在上面的行中，.SetMethod 在 mate::ObjectTemplateBuilder 上调用。可以在 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 的最小浏览器。提供浏览器界面的核心模块称为 Content Module。

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

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

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

将 Chromium 构建为单个共享库​

作为 Content Module 的用户，Electron 在大多数情况下不需要修改 Chromium 的代码，因此改进 Electron 构建的显而易见的方法是将 Chromium 构建为共享库，然后在 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 来测试弱引用，它向传递的对象添加弱引用，并在对象被垃圾回收时调用回调

// 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 中是不可能的。使用普通 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 集和蓬勃发展的社区，它也非常适合作为嵌入式库。这篇文章解释了 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.dll 的名称不需要更改。

支持原生模块​

原生模块 的工作原理是为 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 的成熟，那时可以采取另一种方法。

后端 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。