我原本以为Electron中的渲染器进程是在类似chrome的环境中进行沙盒化,这意味着你所能做的就是搞乱DOM了.但是,我最近了解到您可以访问文件系统,运行子进程并获取其输出,并导入所需的任何其他节点模块.
如果是这种情况,主进程和渲染器进程之间的区别究竟是什么？这不是一个艰难的分离？主进程中有哪些代码以及渲染器进程中的代码类型？
如果有人对Electron app架构进行了深入的阅读/演示,我也很乐意看到它; 可能有助于消除一些混乱
ccn*_*kes 38
主要/渲染器过程的区别实际上并不是电子概念本身 - 它继承自Chromium(这里是关于Chromium架构的文章及其背后的推理).这是Chrome出于性能和稳定性原因而使用的架构.每个webContents实例都在它自己的进程中运行("渲染器"进程).主进程(只能有其中一个)管理webContents实例等.
这里有一个很好的讨论,两者之间的差异.
有些API只能在一个进程或另一个进程中使用,这可以帮助您了解逻辑在哪里.例如,通知(使用HTML5界面但实现为本机通知)只能从渲染器进程创建.该菜单类只能从主进程中调用.仔细阅读Electron模块的API文档,了解其中的内容.您可以使用IPC,远程模块或电子遥控器来协调两个进程(您使用的进程取决于您的用例).
我会说这是一个"硬"分离.它们都是独立的流程,因此不共享任何资源或状态.对于我认为的大多数JS开发者来说,这是一种范式转变(至少对我而言).例如,如果我有一个有状态模块,我在主进程中设置了一些状态,然后我在渲染器中需要该模块,那个状态将不存在.它们是该模块的两个完全不同的实例.像这样的共享状态在主进程中可能是最好的,然后使用上述方法之一在渲染器进程之间共享该状态.
Shawn Rakowski说得很好(在下面的评论中):"在主流程和特定于应用程序的代码中放置代码处理平台基础架构代码(即创建窗口,注册全局快捷方式等)可能是一个很好的规则(你的应用程序是什么)实际上是在渲染过程中."
[我的应用程序的功能是它]解析一些文件,然后将信息呈现到屏幕上
您可以在Electron中使用许多方法,因为fs在渲染器过程中可以使用模块(以及所有node.js模块).
如果您只处理一个浏览器窗口实例而不进行CPU密集型解析,我会说fs在该呈现器流程实例中运行所有相关代码.这是最简单的方法.
如果您正在对这些文件进行CPU密集型工作,则不希望锁定UI,这意味着您无法处理浏览器窗口渲染器,并且您无法在主处理中执行此操作(这将锁定你所有的渲染器!).所以我会研究类似电子遥控器的东西,或创建一个运行繁重的隐形浏览器窗口实例.
这篇关于主要和渲染器过程的文章更深入地讨论了这些主题(披露:我写的那篇).
| 归档时间： |
|
| 查看次数： |
6505 次 |
| 最近记录： |