跳到主要内容

Electron 内部：消息循环集成

·3 分钟阅读
zcbenz
zcbenz

这是解释 Electron 内部机制的系列文章中的第一篇。本文介绍了如何在 Electron 中将 Node 的事件循环与 Chromium 集成。

曾有许多尝试使用 Node 进行 GUI 编程，例如 node-gui (用于 GTK+ 绑定)，以及 node-qt (用于 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 用于其事件循环进行轮询的文件描述符 (或句柄)。因此，通过轮询 backend fd，可以在 libuv 中有新事件时收到通知。

所以在 Electron 中，我创建了一个单独的线程来轮询 backend fd，并且由于我使用的是系统调用进行轮询而不是 libuv API，所以它是线程安全的。每当 libuv 的事件循环中有新事件时，就会向 Chromium 的消息循环发布一条消息，然后 libuv 的事件就会在主线程中进行处理。

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

代码​

你可以在 `electron/atom/common/` 下的 `node_bindings` 文件中找到消息循环集成的实现。想要集成 Node 的项目可以轻松复用它。

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