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 将生成一个 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 插入到网页中的嵌入模式。这方面的详细信息将在以后的文章中解释。