跳到主内容

Electron 内部：消息循环集成

·阅读 4 分钟
zcbenz
zcbenz

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

曾有很多尝试使用 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。