electron - Electron 中渲染器和主进程的区别

Question

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

如果是这样的话，主进程和渲染进程到底有什么区别呢？难道不是艰难的分离吗？主进程中包含哪些代码，渲染器进程中包含哪些代码？

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

Answer 1

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

有一个good discussion here关于两者之间的差异。

某些 API 仅在一个进程或另一个进程中可用，这可以帮助您了解逻辑在哪里。例如，通知(使用 HTML5 界面，但作为 native 通知实现)只能从渲染器进程创建。 Menu class只能从主进程中调用。通读 Electron 模块的 API 文档，看看哪些内容发生在哪里。您可以使用IPC , remote模块，或electron-remote协调两个进程(您使用哪一个取决于您的用例)。

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

这里是 real life apps 的列表和 some sample apps.

Shawn Rakowski 说得很好(在下面的评论中):“将处理平台基础设施代码(即创建窗口、注册全局快捷方式等)的代码放在主进程和应用程序特定代码中可能是一个很好的规则(您的应用程序在渲染器进程中实际执行的操作。”

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

在 Electron 中您可以采取多种方法来实现此目的，因为 fs 模块(以及所有 Node.js 模块)在渲染器进程中可供您使用。

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

如果您正在对这些文件进行 CPU 密集型工作，您不想锁定 UI，这意味着您无法处理浏览器窗口渲染器，并且无法在主 (这将锁定所有渲染器!)。所以我会研究类似 electron-remote 的东西或者创建一个不可见的浏览器窗口实例来运行繁重的工作。

这篇关于main and renderer processes的文章更深入地讨论这些主题(披露:我写的)。