Electron 内部: 将 Node 用作库
这是解释 Electron 内部原理的系列文章中的第二篇。如果您还没有阅读关于事件循环集成的第一篇文章，请查看。
大多数人使用 Node 进行服务器端应用程序开发，但由于 Node 丰富的 API 集合和蓬勃发展的社区，它也非常适合作为嵌入式库使用。本文解释了 Node 如何在 Electron 中用作库。
构建系统
Node 和 Electron 都使用 GYP 作为它们的构建系统。如果您想在您的应用程序中嵌入 Node，您也必须使用它作为您的构建系统。
GYP 新手？在您继续阅读本文之前，请阅读本指南。
Node 的标志
Node 源代码目录中的 node.gyp 文件描述了 Node 的构建方式，以及许多 GYP 变量，用于控制 Node 的哪些部分被启用以及是否打开某些配置。
要更改构建标志，您需要在项目的 .gypi 文件中设置变量。Node 中的 configure 脚本可以为您生成一些常见配置，例如，运行 ./configure --shared 将生成一个包含指示 Node 构建为共享库的变量的 config.gypi 文件。
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 链接时，有两种选择：您可以将其构建为静态库并包含在最终的可执行文件中，或者将其构建为共享库并与最终的可执行文件一起发布。
在 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 插入到网页中。其详细信息将在未来的文章中解释。