performance - 大型邮件的 Electron IPC替代品

Question

我有一个React/Electron应用程序，该应用程序分为2个(可能还有更多)进程-前端，后端和可能有许多“检查器”窗口。它们都使用redux-electron-store通过Redux进行连接，后者使用IPC使所有实例保持同步，主要过程是“主”节点，渲染器被发送diff操作。后端处理大量图像和XML(可能数百个)，并将它们发送到Redux进行存储，从而使整个过程挂起。前端需要缩略图，而其他两个窗口都需要解析的XML数据。

最初，我将每个项目作为其自己的Redux操作发送，例如导致200个操作冻结。我还尝试过交错这些，每2秒左右发送一次，这很好，直到性能开始逐渐下降。然后，我将其更改为批处理，对于一组文件，每种处理类型(缩略图或XML解析)将执行1个操作，这导致2个有效载荷分别为48MB和37MB或类似，虽然更好，但仍然冻结了所有内容好几秒钟。

我在主进程中放置了一个小间隔计数器，以查看它是主进程还是渲染器挂起，并且似乎主进程处于冻结状态，大概是在摄取并重新发送这些大消息的时候(自然这不是一种非常安全的方法因果关系)。因此，我不太确定如何重组事物以停止冻结主要过程。我们有两个想法:

将缩略图和XML数据抽象到Redux的不同部分，该部分不会被IPC同步，而是在后端有一个小型本地Websocket服务器，可以直接与请求数据的进程进行通信，并将其放入它自己的Redux，并且不同步它。使用WebWorkers可以做到这一点吗？这应该避免向主进程发送大量有效负载，并且网络 worker 应避免冻结渲染器。

一个合作伙伴的想法是拥有一个大概可以读写的本地数据库，并且需要以某种方式通知其他窗口，并可能将其存储在组件状态而不是Redux中。我不喜欢这样做，因为引入了更多的I/O操作，需要维护该文件以及一些附加的补丁程序来通知需要该文件的组件，编写完成，然后再读取相同的数据。

尽管IPC仍然处于阻塞状态，但它目前已全部异步完成。

所有这些都是在印象中，冻结渲染器的大消息是唯一的问题，而不是Redux用它来做事，这也可能是正确的，但是如解决方案1中那样将其从同步中删除将涵盖这两个方面。

如果有人对如何更好地组织这一点有任何想法，我将不胜感激。

Answer 1

如果仅在渲染器之间共享这些 Action 是必需的，并且所有渲染器具有相同的来源，则可以尝试使用BroadcastChannel作为IPC的替代方法。

您也可以尝试在渲染器进程中处理数据，并将更新发送到其他渲染器，而完全不涉及manin进程。