跳到主要内容

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 中引入了后端 fd 的概念，它是一个文件描述符（或句柄），libuv 为其事件循环进行轮询。因此，通过轮询后端 fd，可以在 libuv 中有新事件时得到通知。

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

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

代码​

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

更新：实现已移动到 electron/shell/common/node_bindings.cc。