【发布时间】：2020-07-16 15:45:33
【问题描述】：
我有一个 React/Electron 应用程序分为 2 个（并且可以选择更多）进程 - 一个前端、一个后端，可能还有许多“检查器”窗口。它们都通过 Redux 使用 redux-electron-store 连接，使用 IPC 使所有实例保持同步，主进程是“主”节点，渲染器被发送差异操作。后端处理大量图像和 XML，可能有数百个，并将它们发送到 Redux 进行存储，导致整个事情挂起。前端需要缩略图，其他两个窗口都需要解析的 XML 数据。
最初，我将每个项目作为其自己的 Redux 操作发送，导致例如 200 个操作，这将其冻结。我还尝试错开这些，每 2 秒左右发送一个，这很好，直到性能开始下降。然后我将其更改为批处理，对一组文件的每种处理类型（缩略图或解析 XML）执行 1 个操作，这导致 2 个 48MB 和 37MB 或类似的有效负载，这更好，但仍然冻结了一切好几秒钟。
我在主进程中放了一个小间隔计数器，看看是主进程还是渲染器挂起，似乎主进程在冻结，大概是在它摄取并重新发送这些大消息时（自然这不是一个非常万无一失的此处建立因果关系的方法）。所以我不太确定如何重组事情来停止冻结主进程。我们有两个想法：
将缩略图和 XML 数据抽象到 Redux 的不同部分，它不会被 IPC 同步，而是在后端有一个小型本地 websocket 服务器，可以直接与请求数据的进程通信，它将把它放在它自己的 Redux 中，而不是同步它。这也许可以用 WebWorkers 来完成？这应该可以避免向主进程发送大负载，并且 web worker 应该避免冻结渲染器。
一个合作伙伴的想法是有一个本地数据库，大概可以读取/写入，其他窗口需要以某种方式得到通知，并可能将其存储在组件状态而不是 Redux 中。我不喜欢这个，因为引入了更多的 I/O 操作，需要维护这个文件，以及一些额外的补丁来通知需要它的组件，写入完成，然后去读取相同的数据。
IPC 目前已全部异步完成，但仍会阻塞。
这一切都给人的印象是，冻结渲染器的大消息是唯一的问题，而不是 Redux 处理它，这也可能是正确的，但是在解决方案 1 中将其从同步中移除将涵盖这两个问题.
如果有人对如何更好地构建它有任何想法，我将非常感激。
【问题讨论】：
标签： performance redux websocket electron ipc