我正在编写一个Electron应用程序和一些版本，测试人员开始注意到两个electron.exe进程一直在消耗大量的CPU时间。一个使用CPU内核，另一个使用大约85％的内核。
我确信情况并非总是如此，因为几个月前的版本没有做到这一点。但是，由于代码库在那段时间内发生了巨大的变化，我不知道如何调试可能引入的代码更改。
process.getIOCounters（）报告每隔几分钟就会发生几千兆字节的IO。该应用程序没有死锁，一切仍然有效，它只是在咀嚼CPU。它发生在应用程序打开的任何时候，即使它在后台没有任何用户输入。我只有Windows 10 x64系统，我已将其部署为Electron 1.7.9和1.7.5。
根据行为，我确定此IO是呈现主线程和主线程之间的进程间通信，但我不是手动执行任何IPC。我认为这个问题是由我们引入的一些模块造成的，这些模块不正确地驻留在渲染的线程中。
我的问题是，如何调试电子渲染/主线程IPC管道？是否可以了解千兆字节流量的内容是什么？
答案 0 :(得分：1)
根据过去几天尝试调试此问题，我自己回答了这个问题：
不，电子似乎是一个好主意，将所有客户端和平台代码写在同一个地方。但是有很多捕获，并且蓝色库中会有奇怪的错误，因为它们不在主流用例之内。这当然与我不是电子专家有很大关系，但在现实世界中有截止日期和时间表，我无法像我希望的那样加速。我的问题是，如何调试电子渲染/主线程IPC管道？
我已将我的架构更新为经过验证的真正的服务/ GUI模型。我将维护对客户端代码的完全浏览器支持，以及在检测到电子时对某些功能进行挂钩的电子模式。
这使我能够快速识别特定于浏览器，版本或平台框架的问题。它还允许我使用我想要的服务的NodeJS版本，这也是我的问题。
我仍然喜欢Electron，我在使用它时会更加小心。如果我确实发现了我遇到这个问题的具体细节，我会检查并报告这些细节。
<强>更新
所以这个问题并没有像我想象的那样与Electron直接相关，IPC不在渲染器和主线之间，而且是一个红色的鲱鱼。它实际上是一个铬关键帧动画问题导致60 FPS重绘率，仍然不确定为什么这会导致IPC的GB，但无论如何。见https://github.com/Microsoft/vscode/issues/22900
我能够通过将此应用程序移植回本机浏览器（使用nodejs服务）来发现这一点。然后我运行chrome，edge和firefox。只有chrome表现出这种方式。