Electron 中渲染器和主进程的区别 [英] Distinction between the renderer and main processes in Electron

问题描述

我最初认为 Electron 中的渲染器进程在类似 chrome 的环境中被沙盒化，这意味着你所能做的就是弄乱 DOM.但是，我最近了解到您可以访问文件系统、运行子进程并获取它们的输出，并导入您想要的任何其他节点模块.

I originally thought that the renderer process in Electron was sandboxed in a chrome-like environment, meaning all you can do is mess with the DOM. However, I recently learned that you can access the filesystem, run child processes and get their output, and import any other node modules you want.

如果是这样的话，主进程和渲染进程的区别到底是什么?不是硬分离吗?什么样的代码进入主进程，什么样的代码进入渲染进程?

If this is the case, what exactly is the distinction between the main process and the renderer process? Is it not a hard separation? What kind of code goes in the main process and what kind of code goes in the renderer process?

如果有人对 Electron 应用架构有很好的深入阅读/演示，我也很想看看；可能有助于消除一些困惑

If anyone has a good in-depth reading/presentation on Electron app architecture I would love to look at that too; might help clear up some of the confusion

推荐答案

main/renderer 进程的区别实际上并不是 Electron 的概念——它继承自 Chromium(这里是 关于 Chromium 架构及其背后的推理的文章).这是 Chrome 出于性能和稳定性原因而使用的架构.每个 webContents 实例都在它自己的进程中运行(渲染器"进程).主进程(只能是其中一个)管理 webContents 实例等.

The main/renderer process distinction isn't actually an Electron concept per se -- it's inherited from Chromium (here's an article on Chromium's architecture and the reasoning behind it). This is the architecture that Chrome uses for performance and stability reasons. Each webContents instance runs in it's own process (a "renderer" process). The main process (there can only be one of these) manages webContents instances, among other things.

有一个 在这里很好地讨论关于两者之间的差异.

There's a good discussion here on the differences between the two.

某些 API 仅在一个进程或另一个进程中可用，这可以帮助您了解逻辑在哪里.例如，通知(使用 HTML5 接口，但作为原生通知实现)只能从渲染器进程创建.Menu 类 只能在 main 中调用过程.通读 Electron 模块的 API 文档，看看哪里有什么.你可以使用 IPC, remote 模块，或 electron-remote 在两个进程之间进行协调(您使用哪一个取决于您的用例).

Some APIs are only available in one process or the other, which can help you get a sense of what logic goes where. For example, Notifications (uses the HTML5 interface but are implemented as native notifications) can only be created from a renderer process. The Menu class can only be called from within the main process. Read through the Electron modules' API docs and see what goes where. You can use IPC, remote module, or electron-remote to coordinate between the two processes (which one you use depends on your use case).

我会说这是一个硬"分离.它们都是独立的进程，因此不共享任何资源或状态.对于我认为的大多数 JS 开发人员来说，这是一种范式转变(至少对我来说是这样).例如，如果我有一个有状态的模块，我在主进程中设置了一些状态，然后我在渲染器中需要该模块，那么该状态将不存在.它们是该模块的两个完全不同的实例.像这样共享状态可能最好在主进程中，然后使用上述方法之一在渲染器进程之间共享该状态.

I would say it is a "hard" separation. They're all separate processes and thus don't share any resources or state. This is a paradigm shift for most JS devs I think (at least it was for me). For example if I had a stateful module that I set some state in in the main process, and then I required that module in the renderer, that state won't be there. They're two entirely different instances of that module. Sharing state like that would probably be best in the main process and then either use one of the methods described above to share that state between renderer processes.

这里是 现实生活中的应用程序 和 一些示例应用.

Shawn Rakowski 说得很好(在下面的评论中):将处理平台基础架构代码(即创建窗口、注册全局快捷方式等)的代码放在主进程和应用程序特定代码中可能是一个很好的规则(你的应用实际在做什么)在渲染器进程中."

Shawn Rakowski said it well (in comments below): "It may be a good rule to put code dealing with the platform infrastructure code (i.e. creating windows, registering global shortcuts, etc) in the Main process and application specific code (what your app is actually doing) in the Renderer processes."

[我的应用的功能是什么]解析一些文件，然后将信息呈现到屏幕上

[My app's functionality is it] parses some files and then renders the info to the screen

在 Electron 中有很多方法可以解决这个问题，因为在渲染器进程中可以使用 fs 模块(以及所有 node.js 模块).

There's lots of approaches you can take to this in Electron because the fs module (and all node.js modules) are available to you in the renderer process.

如果您只处理一个浏览器窗口实例而不进行 CPU 密集型解析，我会说在该渲染器进程实例中运行所有与 fs 相关的代码.这是最简单的方法.

If you're only dealing with one browser window instance and not doing CPU intensive parsing, I would say run all the fs related code in that renderer process instance. That's the simplest way.

如果您在这些文件上执行 CPU 密集型工作，您不想锁定 UI，这意味着您无法执行处理浏览器窗口渲染器，也无法在 main (这将锁定你所有的渲染器！).所以我会研究类似 electron-remote 或创建一个运行繁重的不可见浏览器窗口实例起重.

If you're doing CPU intensive work on these files, you don't want to lock up the UI, which means you can't do your processing browser window renderer, and you can't do it in the main (this will lock up all your renderers!). So I would look into something like electron-remote or create an invisible browser window instance that runs the heavy lifting.

这篇关于主要和渲染器进程的文章 更深入地讨论了这些主题(披露:我写的).

This article about the main and renderer processes talks about these topics more in-depth (disclosure: I wrote that).

这篇关于Electron 中渲染器和主进程的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！