我有一个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可以做到这一点吗？这应该避免向主进程发送大量有效负载，并且网络工作者应避免冻结渲染器。
合作伙伴的想法是要拥有一个本地数据库，该数据库可能被读取/写入，并且需要以某种方式通知其他窗口，并可能将其存储在组件状态而不是Redux中。我不喜欢这样做，因为引入了更多的I / O操作，需要维护该文件以及一些附加的补丁程序来通知需要该文件的组件，编写完成，然后再读取相同的数据。 >
尽管IPC仍处于阻止状态，但IPC目前全部异步完成。
这全都是这样的印象，冻结渲染器的大消息是唯一的问题，而不是Redux用它来做事，这也可能是正确的，但是如解决方案1所述将其从同步中删除将涵盖这两个方面。
如果有人对如何更好地组织这一点有任何想法，我将不胜感激。
我有一个React / Electron应用程序，该应用程序分为2个（可能还有更多）进程-前端，后端和可能有许多“检查器”窗口。它们都通过redux使用redux-electron -...
如果仅在渲染器之间共享这些动作，并且所有渲染器具有相同的来源，则可以尝试使用BroadcastChannel作为IPC的替代方法。