Electron 内部:消息循环集成
这是解释 Electron 内部原理的系列文章的第一篇。 本文介绍如何在 Electron 中将 Node 的事件循环与 Chromium 集成。
已经有很多尝试使用 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 的成熟,现在可以采用另一种方法。
后端 fd 的概念已引入 libuv,它是一个文件描述符(或句柄),libuv 轮询该描述符以获取其事件循环。 因此,通过轮询后端 fd,可以在 libuv 中有新事件时收到通知。
因此,在 Electron 中,我创建了一个单独的线程来轮询后端 fd,并且由于我使用的是系统调用进行轮询而不是 libuv API,因此它是线程安全的。 并且每当 libuv 的事件循环中有一个新事件时,都会将消息发布到 Chromium 的消息循环,然后将在主线程中处理 libuv 的事件。
这样,我避免了修补 Chromium 和 Node,并且在主进程和渲染器进程中使用了相同的代码。
代码
您可以在 electron/atom/common/
下的 node_bindings
文件中找到消息循环集成的实现。 它可以很容易地重复用于想要集成 Node 的项目。
更新:实现已移至 electron/shell/common/node_bindings.cc
。