[英]Which one is better way in terms of performance to use IPC listener in electron?
I have a lot of IPC listeners ( more than 30 ) on my electron application, but I wonder which one is better in terms of performance.我的 electron 应用程序上有很多 IPC 侦听器(超过 30 个),但我想知道哪个在性能方面更好。
The first solution (Implement IPC listener as many as it needed):第一个解决方案(根据需要实施 IPC 侦听器):
ipcMain.on('appLanguageChange', (event, data) => {
//do something with data
})
ipcMain.on('current-patient-ask', (event, data) => {
//do something with data
})
ipcMain.on('patient-set', (event, data) => {
//do something with data
})
//Still need many listeners below..
The second solution (Using Switch and only implementing one IPC listener):第二种解决方案(使用 Switch 且仅实现一个 IPC 侦听器):
ipcMain.on('data-flow', (event, topic, data) => {
switch (topic) {
case "appLanguageChange":
//do something with data
case "current-patient-ask":
//do something with data
case "patient-set":
//do something with data
break;
//Still need many cases below..
})
Currently, I am using the second solution, is it a good approach?目前,我正在使用第二种解决方案,这是一个好的方法吗? Because I am aware that some people could get a warning that too many IPC listeners have already implemented.
因为我知道有些人可能会收到一个警告,即已经实施了太多的 IPC 侦听器。 How many maximum IPC listeners could be implemented if there is a limitation?
如果有限制,最多可以实现多少个 IPC 侦听器? It would be better if someone could explain the pros and cons of the two methods.
如果有人能解释一下这两种方法的优缺点就更好了。 Thanks in advance.
提前致谢。
As Electron uses Node.js underneath and Electron's IPC is based on Node events, any limits would be imposed by Node and not Electron (unless otherwise defined by electron, which I don't believe it is).由于 Electron 在下面使用 Node.js 并且 Electron 的 IPC 基于 Node 事件,因此任何限制都将由 Node 而不是 Electron 施加(除非 electron 另有定义,我不相信它是)。
As per the latest Node.js Event documentation, once you have more than 10 listeners per event a warning will be emitted.根据最新的 Node.js 事件文档,一旦每个事件的侦听器超过 10 个,就会发出警告。 The thing to note here is "more than 10 listeners per event ".
这里要注意的是“每个事件超过 10 个听众”。
See this Node link for more information: events.defaultMaxListeners
有关详细信息,请参阅此节点链接: events.defaultMaxListeners
As each ipcMain.on('channelName', () => {... })
is a listener for, in this example, an event named channelName
, you would need more than quantity 10 of the ipcMain.on('eventName', () => {... })
methods in your code before a warning is throw.由于每个
ipcMain.on('channelName', () => {... })
都是一个侦听器,在此示例中,一个名为channelName
的事件,您需要超过 10 个ipcMain.on('eventName', () => {... })
在抛出警告之前代码中的方法。
As all your ipcMain
methods seem to be for different event names, there is no operational benefit between either of your solutions.由于您的所有
ipcMain
方法似乎都用于不同的事件名称,因此您的两种解决方案之间都没有操作优势。
That said, your first solution would be the preferred solution, allowing you to place your individual ipcMain
calls into their "associated files".也就是说,您的第一个解决方案将是首选解决方案,允许您将个人
ipcMain
调用放入它们的“关联文件”中。 EG: appLangaugeChange
events would be coded within your language
scripts whilst your any patient
events would be coded within your patient
scripts. EG:
appLangaugeChange
事件将在您的language
脚本中编码,而您的任何patient
事件将在您的patient
脚本中编码。 This will keep your code seperated, logical, expandable and simple to debug.这将使您的代码保持分离、逻辑、可扩展且易于调试。
Additionally, as your project grows, a particular section of code can listen for an event emitted by an unrelated section of code, if needed.此外,随着项目的增长,如果需要,特定的代码部分可以侦听由不相关的代码部分发出的事件。 EG: Submitting some new information on a form may update more than one panel in your main window, or update multiple child-windows, all at the same time.
EG:在表单上提交一些新信息可能会同时更新主 window 中的多个面板,或者同时更新多个子窗口。
On the discussion of "performance", if your events were firing every couple of milliseconds then one would want to look at micro-optimisation.关于“性能”的讨论,如果您的事件每隔几毫秒触发一次,那么人们就会想看看微优化。 But based on the event names, this is not the case, so any solution would work.
但根据事件名称,情况并非如此,因此任何解决方案都可行。 If anything, it would probably be more based on your preferred coding style.
如果有的话,它可能更多地基于您喜欢的编码风格。
As a closing note, consider the ipcMain
method and its associated Electron methods only as an extension of Node events.作为结束语,将
ipcMain
方法及其关联的 Electron 方法仅视为 Node 事件的扩展。 They are not special or magical, but only a simple observer design pattern.它们并不特殊或神奇,而只是一个简单的观察者设计模式。 This way, you will write better, more modular code.
这样,您将编写出更好、更模块化的代码。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.