我有一个React/Electron应用程序，它分为两个(可选地还有更多(进程——一个前端、一个后端，可能还有许多"检查器"窗口。它们都通过Redux使用Redux电子存储进行连接，该存储使用IPC保持所有实例的同步，主进程是"主"节点，渲染器被发送不同的操作。后端处理大量图像和XML，可能有数百个，并将它们发送到Redux进行存储，导致整个过程挂起。前端需要缩略图，其他两个窗口都需要解析的XML数据。
最初，我将每个项目作为自己的Redux操作发送，例如，导致大约200个操作冻结了它。我还尝试过交错发送，每2秒左右发送一个，这很好，直到性能在中途开始下降。然后，我将其更改为一个批处理过程，对一组文件的每种处理类型(缩略图或解析XML(都有一个操作，这会产生48MB和37MB或类似的2个有效载荷，这更好，但仍然会将所有内容冻结好几秒钟。
我在主进程中放了一个小的间隔计数器，看看它是主进程还是渲染器挂起，似乎主进程正在冻结，大概是在它接收和重新发送这些大消息的时候(当然，这不是一个非常简单的确定因果关系的方法(。所以我真的不知道如何重组以停止冻结主要流程。我们有两个想法：
-
将缩略图和XML数据抽象到Redux的另一个部分，该部分不会由IPC同步，而是在后端有一个小型的本地websocket服务器，该服务器可以直接与请求数据的进程通信，该进程将数据放在自己的Redux中，而不会同步。这可能可以通过WebWorkers完成？这应该避免向主进程发送大的有效负载，并且web工作人员应该避免冻结渲染器。
-
合作伙伴的想法是拥有一个本地数据库，该数据库可能会被读取/写入，而其他窗口则需要以某种方式得到通知，并可能将其存储在组件状态而不是Redux中。我不太喜欢这样，因为引入了更多的I/O操作，需要维护这个文件，以及一些额外的补丁来通知需要它的组件，写入已经完成，然后去读取相同的数据。
IPC目前都是异步完成的，尽管它仍然会阻塞。
这一切都给人的印象是，冻结渲染器的大型消息是唯一的问题，而不是Redux用它做事情，这可能也是真的，但像解决方案1中那样将其从同步中删除将涵盖这两个问题。
如果有人对如何更好地构建这一体系有任何想法，我将不胜感激。
如果只要求在渲染器之间共享这些操作，并且所有渲染器都有相同的来源，则可以尝试使用BroadcastChannel作为IPC的替代方案。
此外，您还可以尝试在渲染器过程中处理数据，并将更新发送到其他渲染器，而不涉及马宁过程。