Electron中渲染器和主要进程之间的区别

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

如果是这种情况，那么主进程和渲染器进程之间的区别是什么？分离不是很难吗？什么样的代码进入主进程，什么样的代码进入渲染器进程

---

如果有人对Electron应用程序架构有很好的深入阅读/介绍，我也很想看看；可能有助于消除一些混淆

主/渲染器过程的区别实际上并不是一个电子概念本身——它是从Chromium继承而来的（以下是关于Chromium的体系结构及其背后的推理）。这是Chrome出于性能和稳定性的考虑而使用的架构。每个WebContent实例都在自己的进程（一个“渲染器”进程）中运行。主进程（其中只能有一个）管理WebContent实例以及其他内容

关于这两者之间的区别有很多不同之处

有些API只在一个进程或另一个进程中可用，这可以帮助您了解逻辑的走向。例如，通知（使用HTML5接口，但实现为本机通知）只能从渲染器进程创建。只能从主进程内调用。通读Electron模块的API文档，看看会发生什么。您可以使用、模块或在这两个过程之间进行协调（使用哪一个取决于您的用例）

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

以下是和的列表

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

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

在Electron中有很多方法可以实现这一点，因为

fs

模块（以及所有node.js模块）在渲染器过程中都是可用的

如果您只处理一个浏览器窗口实例，而不进行CPU密集型解析，我会说运行该渲染器进程实例中所有与

fs

相关的代码。这是最简单的方法

如果您在这些文件上执行CPU密集型工作，则不希望锁定UI，这意味着您无法处理浏览器窗口渲染器，也无法在主窗口中执行（这将锁定所有渲染器！）。所以我会研究一些类似的东西，或者创建一个运行繁重工作的不可见浏览器窗口实例

---

这篇关于这些话题的讨论更深入（披露：我写的）

好吧，看来我可以坚持一个过程90%。但问题是，我的大部分代码应该在主进程还是渲染器进程中？值得注意的是，如果需要，可以在渲染器进程中关闭节点集成，这将赋予主进程新的含义：-）。文档还指出，由于存在潜在泄漏，处理BrowserWindows本身的创建和修改对渲染器进程不利。将处理平台基础架构代码（即创建窗口、注册全局快捷方式等）的代码放在主进程中，将特定于应用程序的代码（应用程序实际执行的操作）放在渲染器进程中，这可能是一个好规则。当然，也有例外，但是如果你想要一个一般的规则，它可能是一个很好的遵循。除非您想要一个沙盒更多的窗口，否则您通常会让节点集成处于打开状态。。。e、 g.从web加载不受信任的内容。@c关于阻止UI，我在主进程和渲染器进程中放置了一个无限while循环，两次都阻止了UI。我以为主进程根本不处理渲染，只是管理windows？@YvesSchelpe这是真的，我的回答错了，我会很快更新它，使其正确。不幸的是，主代码中的阻塞代码将阻塞所有渲染器。然而，对于大多数用例，JS的运行速度足够快，它不会真正阻塞（或者用户不会注意到）。有关更多详细信息，请参阅我的更新答案。。。