我正在编写一个 Electron 应用程序,一些构建回测试人员开始注意到两个 electro.exe 进程一直消耗大量 CPU 时间。一个固定 CPU 核心,另一个使用大约 85% 的核心。
我确信情况并非总是如此,因为几个月前的构建并没有这样做。但我不知道如何调试哪些代码更改可能引入了此问题,因为代码库在那段时间发生了巨大的发展。
process.getIOCounters() 报告每隔几分钟就会发生几 GB 的 IO。应用程序没有死锁,一切仍然正常,只是消耗了 CPU 的资源。即使应用程序处于后台且没有任何用户输入,它也会在应用程序打开时发生。我只有 Windows 10 x64 系统,我已将其部署为 Electron 1.7.9 和 1.7.5。
根据行为,我确信此 IO 是渲染线程和主线程之间的进程间通信,但我没有手动执行任何 IPC。我认为这个问题是由我们引入的某些模块不正确地驻留在渲染线程中引起的。
我的问题是,如何调试 Electron 渲染/主线程 IPC 管道?是否可以挂钩知道千兆字节流量的内容是什么?
基于过去几天尝试调试这个问题,我自己回答了这个问题:
我的问题是,如何调试 Electron 渲染/主线程 IPC 管道?
不,电子似乎是一个好主意,将所有客户端和平台代码编写在同一个地方。但是有很多问题,而且库会突然出现奇怪的错误,解决这些错误的成本很高,因为它们超出了主流用例。这当然与我不是电子专家有很大关系,但在现实世界中,有最后期限和时间表,我不能总是像我希望的那样跟上进度。
我已经将我的架构更新为尝试过的真正的服务/GUI 模型。我将维护对客户端代码的完整浏览器支持,以及当检测到电子时带有某些功能挂钩的电子模式。
这使我能够快速识别特定于浏览器、版本或平台框架的问题。它还允许我使用我想要的 NodeJS 版本来提供服务,这在我的案例中也是一个问题。
不过我仍然喜欢 Electron,只是在使用它时会更加小心。如果我确实发现了出现此问题的具体原因,我会回来查看并报告这些详细信息。
更新
所以这个问题并不像我想象的那样与 Electron 直接相关,IPC 不在渲染器和主线程之间,并且是一个转移注意力的问题。这实际上是一个 chrome 关键帧动画问题,导致 60 FPS 重绘率,仍然不确定为什么这会导致 GB 的 IPC,但无论如何。请参阅https://github.com/Microsoft/vscode/issues/22900
我通过将此应用程序移植回本机浏览器(使用 Nodejs 服务)发现了这一点。然后我在 Chrome、Edge 和 Firefox 中运行。只有 chrome 有这种行为。
| 归档时间: |
|
| 查看次数: |
8706 次 |
| 最近记录: |