6 篇标记为“Electron 内部原理”的博文

在过去几周里，我们收到了许多关于新的 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 为 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 架构有最新的了解。他们欢迎对该项目的任何反馈。

用 C++ 或 Objective-C 编写的 Electron 功能如何进入 JavaScript，以便最终用户可以使用它们？

背景​

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

实际上，Electron 会为你处理原生代码，以便你可以专注于单个 JavaScript API。

然而，它是如何工作的呢？用 C++ 或 Objective-C 编写的 Electron 功能如何进入 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)

在上面一行中，.SetMethod 在 mate::ObjectTemplateBuilder 上被调用。.SetMethod 可以在 ObjectTemplateBuilder 类的任何实例上调用，以以下语法在 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 基于谷歌的开源 Chromium 项目，该项目并非专门设计供其他项目使用。本文介绍了如何将 Chromium 构建为 Electron 使用的库，以及构建系统多年来的演变。

使用 CEF​

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

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

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

作为 Chromium 的一部分构建​

尽管 Chromium 不正式支持外部项目，但其代码库是模块化的，并且很容易基于 Chromium 构建一个最小的浏览器。提供浏览器接口的核心模块称为内容模块 (Content Module)。

要使用内容模块开发项目，最简单的方法是将其作为 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，但由于它只创建弱引用键，因此无法知道对象何时被垃圾回收。

在 Electron v0.37.8 之前的版本中，你可以使用内部的 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 的构建方式，以及许多控制 Node 哪些部分启用以及是否打开某些配置的 GYP 变量。

要更改构建标志，你需要设置项目 .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 中的原生模块通过定义一个供 Node 加载的入口函数，然后从 Node 中搜索 V8 和 libuv 的符号来工作。这对于嵌入者来说有点麻烦，因为默认情况下，当将 Node 作为库构建时，V8 和 libuv 的符号是隐藏的，原生模块将因为找不到符号而无法加载。

因此，为了使原生模块能够工作，Electron 中暴露了 V8 和 libuv 的符号。对于 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 为其事件循环轮询的文件描述符（或句柄）。因此，通过轮询后端文件描述符，可以在 libuv 中有新事件时收到通知。

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

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

代码​

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

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