Open tyn1998 opened 2 years ago
查看代码时的想到的问题:
https://github.com/opensumi/core/blob/main/packages/core-common/src/mocks/electron/ipcRenderer.ts
@Yantze 老师,请问这个MockedElectronIpcRenderer是做什么用的?只是为了测试用吗?
马克一下:
https://github.com/opensumi/core/pull/1560 中,在core-browser/src/bootstrap/app.ts的构造函数中向window
全局变量插上HOOK。
如果是electron app的形式,那么会先启动electron的main thread,main thread再启动browser window,所以这里有个时间先后关系,要留心一下。
Devtron的做法是在loadExtension的时候(应该是比较初始的时间点),就对ipcRenderer的方法做个代理,这样后面用到ipcRenderer的各个方法时,被改造过的方法都会把消息给捕捉了。
browserNodeIntegrated
是集成方控制的一个配置项,如ide-connection设置为true,但是core中的electron是设置为false的。
若browserNodeIntegrated
为true
,那么opensumi-devtools可以像Devtron那样,直接require('electron').ipcRenderer
和require('electron').ipcMain
来改造,是完全外挂式的。但是,若browserNodeIntegrated
为false
,那么opensumi-devtools中无法访问模块,只能采用捕获ws messages那样的方法,即需要opensumi/core进行配合。
我个人更倾向于侵入式的方式,@Yantze老师怎么看?
初步调查
假设我是一个opensumi/core的集成方,如果要做electron应用,那么一定会使用到@opensumi/ide-core-electron-main模块。于是,如果ipc捕获功能需要opensumi/core配合的话,我就应该着眼于修改ide-core-electron-main模块。
ide-electron项目是一个示范项目,指导集成方如何基于opensumi/core打造electron应用。
opensumi/core的tools/electron类似于ide-electron,但是更加简单一点。
@Yantze老师,请问我的上面3个理解对吗?