Electron Internals: Using Node as a Library
This is the second post in an ongoing series explaining the internals of Electron. Check out the first post about event loop integration if you haven't already.
Most people use Node for server-side applications, but because of Node's rich API set and thriving community, it is also a great fit for an embedded library. This post explains how Node is used as a library in Electron.
构建系统
节点和 Electron 都使用 GYP 作为他们的构建系统。 If you want to embed Node inside your app, you have to use it as your build system too.
New to GYP? 新建 GYP? Read this guide before you continue further in this post.
Node's flags
个节点。 yp 节点源代码目录中的文件描述节点 是如何构建的， 加上许多 GYP 变量来控制 节点的哪些部分已启用以及是否打开某些配置。
To change the build flags, you need to set the variables in the .gypi file of your project. The configure script in Node can generate some common configurations for you, for example running ./configure --shared will generate a config.gypi with variables instructing Node to be built as a shared library.
Electron does not use the configure script since it has its own build scripts. 节点配置在 common.gypi 文件 中定义了 Electron的根源代码目录。
Link Node with Electron
In Electron, Node is being linked as a shared library by setting the GYP variable node_shared to true, so Node's build type will be changed from executable to shared_library, and the source code containing the Node's main entry point will not be compiled.
Since Electron uses the V8 library shipped with Chromium, the V8 library included in Node's source code is not used. This is done by setting both node_use_v8_platform and node_use_bundled_v8 to false.
Shared library or static library
When linking with Node, there are two options: you can either build Node as a static library and include it in the final executable, or you can build it as a shared library and ship it alongside the final executable.
In Electron, Node was built as a static library for a long time. This made the build simple, enabled the best compiler optimizations, and allowed Electron to be distributed without an extra node.dll file.
然而，Chrome切换到使用 BoringSSL 后改变了这种情况。 BoringSSL is a fork of OpenSSL that removes several unused APIs and changes many existing interfaces. 因为节点仍在使用 OpenSSL，编译器会产生无数的 链接错误，如果它们是相互冲突的符号连接在一起的话。 Because Node still uses OpenSSL, the compiler would generate numerous linking errors due to conflicting symbols if they were linked together.
Electron 无法在节点中使用 BoringSSL 或在 Chromium 中使用 OpenSSL 所以唯一的 选项是切换到构建节点作为共享库， 和 隐藏每个组件中的 BoringSSL 和 OpenSSL 符号
This change brought Electron some positive side effects. Before this change, you could not rename the executable file of Electron on Windows if you used native modules because the name of the executable was hard coded in the import library. After Node was built as a shared library, this limitation was gone because all native modules were linked to node.dll, whose name didn't need to be changed.
Supporting native modules
节点工作中的原生模块 ，定义节点加载的条目函数。 然后从节点中搜索V8和libuv 的符号。 This is a bit troublesome for embedders because by default the symbols of V8 and libuv are hidden when building Node as a library and native modules will fail to load because they cannot find the symbols.
So in order to make native modules work, the V8 and libuv symbols were exposed in Electron. For V8 this is done by forcing all symbols in Chromium's configuration file to be exposed. For libuv, it is achieved by setting the BUILDING_UV_SHARED=1 definition.
Starting Node in your app
After all the work of building and linking with Node, the final step is to run Node in your app.
Node doesn't provide many public APIs for embedding itself into other apps. 通常您只能调用 节点：start 和 节点：:Init 开始 新的节点实例。 However, if you are building a complex app based on Node, you have to use APIs like node::CreateEnvironment to precisely control every step.
In Electron, Node is started in two modes: the standalone mode that runs in the main process, which is similar to official Node binaries, and the embedded mode which inserts Node APIs into web pages. The details of this will be explained in a future post.