一文搞懂Electron的四种视图容器和它们之间的IPC通信机制
Electron作为一种基于JS语言搭建的桌面框架,其基础视图容器是包含了Chromium内核的窗口,称为BrowserWindow。对于更复杂的项目,如果需要在窗口内部嵌入第三方业务的页面,则有BrowserView、webView Tag和Iframe三种方案可供选择。
这四类视图容器的实现原理各不相同,和主进程、宿主窗口以及其它兄弟窗口的通信方式也各不相同。官方文档中(截止Electron20版本)的描述较为散乱,本文集中梳理它们各自的特性以及通信方式,并给出推荐的封装模式,以供各位开发者参考。
一、Electron的视图容器层级
1.webContents
Electron的渲染进程是基于Chromium搭建的,下图是Chromium官方文档中关于视图容器的层级划分
其中和Electron关系最紧密的概念是Webcontents,它相当于一个独立的渲染上下文,在Chrome里,每增加一个tab就会创建一个独立的WebContents,它们可以加载各自不同的url,彼此互相独立。
在Electron里,当我们创建一个基础窗口对象,就能够通过它的引用拿到WebContents。
const win = new BrowserWindow({
width: 800,
height: 600,
webPreferences: {
preload: path.join(__dirname, 'preload.js'),
},
})
win.loadFile('index.html')
console.log(win.webContents)
它是一个EventEmitter对象,可以通过它来发送跨进程消息,监听其它进程发来的事件,这是Electron内建ipc通信的基础。
此外,Electron还给每个webcontents对象提供了一个上下文隔离(Isolated Context)的预加载环境,并且在其中执行开发者指定的preload脚本。它会在渲染器加载页面之前运行, 可以同时访问 DOM 接口和 Node.js 环境,并且可以通过 contextBridge 接口将特权接口暴露给渲染器。
因为Electron封装的跨进程通信对象ipcMain和ipcRenderer都是基于nodejs环境的api,而出于安全性考虑,通常需要在生产环境中关闭渲染进程的node权限(设置窗口的nodeIntegration为false),以防恶意脚本破坏操作系统。但这样一来,主进程和渲染进程的通信就会变得麻烦。
Preload脚本给我们提供了一种折中方案。我们可以在隔离上下文里把通信通道建立完毕,然后把有限的接口暴露到渲染上下文,供业务使用。并且在暴露接口时做一些参数检查,过滤的工作,避免非法脚本到达主进程。
所以,尽管官方提供的一些demo会把ipcRenderer直接引入渲染进程,但在生产环境下,我们要尽量避免这样做。包括下文的所有demo代码里,ipcRenderer都应该是经过preload检查过滤后的对象,而非原始的node对象。
// 暴露渲染进程访问的对象,也可以换一个别名
contextBridge.exposeInMainWorld('ipcRenderer', {
send: async (channel: string, ...args: any) => {
// 可以在这里做一些业务上的合法性检查和过滤
ipcRenderer.send(channel, ...args);
},
invoke: async (channel: string, ...args: any) => {
// 可以在这里做一些业务上的合法性检查和过滤
return await ipcRenderer.invoke(channel, ...args);
},
});
2. frame
在webcontets之上还运行着若干frame,我们可以在主进程遍历出一个窗口的所有frame对象,如果某个窗口打开了devtool,或者加载了iframe标签,frame对象都会新增。而每个webcontents都有一个mainFrame,就是窗口直接加载的主体对象。
this.win.webContents.on('did-frame-finish-load',(event, isMainFrame, frameProcessId, frameRoutingId)=>{
// 每个frame加载完毕后都会触发这个事件
console.log("aaaaaa did-frame-finish-load", isMainFrame, frameProcessId, frameRoutingId);
// 遍历窗口所有frame对象,比对routingId,可以找出当前的frame并打印其基础信息
this.win.webContents.mainFrame.frames.forEach(frame => {
if(frame.routingId === frameRoutingId){
const url = new URL(frame.url)
console.log(“当前frame加载的url ", url);
}
})
})
frame 也有一系列的属性和生命周期钩子,但他并不是EventEmitter,无法通过它和其它进程通信。如果需要跨frame交换消息,需要采取迂回的方案,我们将在后文加以说明。
二、基础窗口BrowserWindow
BrowserWindow是Electron里最基本的视口单位,通过主进程创建和调度,一个BrowserWindow等同于一个独立的Chrome进程。
1. BrowserWindow和主进程的通信
主进程和窗体之间通信几乎是所有业务的刚需,Electron官方提供了基于IpcMain和IpcRenderer的封装,鉴于官方文档已经描述得非常清晰,此处不再罗列代码,只用图总结一下。
从窗口调用主进程分为send和invoke两种模式,前者是单向发送,适用于执行特定操作不关心返回值的场景,后者则会返回一个结果,相当于一来一回,并且是异步的。官方也提供了同步调用接口sendSync,但会造成进程阻塞,实际业务中尽量不要用。
从主进程到窗口,则要借助webcontents的send方法来发送,官方只提供了单向调用的封装,可能是因为主进程是运行在后台的,并没有视图,所以通常情况下不存在由主进程主动发起,并依赖渲染进程返回的场景,但如果实际业务中确实有需求,也可以在send的时候带上唯一标识ID,由渲染进程处理完毕后,携带id发起send,通过两次通信模拟出同样的效果。
2. 两个BrowserWindow之间的通信
由于ipc通信的基础是webcontents,而两个独立的窗口之间无法直接交换渲染上下文的信息,所以需要借助主进程的帮助。如果请求次数少,每次都由主进程转发也问题不大。但如果请求次数多,考虑到多窗口应用的性能问题,最好能够建立窗口对窗口的直接通信。
有两种方式可以实现:
(1) 使用 ipcRenderer.sendTo
该方法支持传入一个webContentsId作为发送目标,发送到特定的渲染上下文,通过它我们可以实现窗口对窗口的直接通信,但首先需要通过主进程来获取另一个窗口的webContentsId。
// A窗口
const targetId = await ipcRenderer.invoke(“GetIWindowBId”) //主进程需要通过ipcMain监听该事件并返回窗口B的id
ipcRenderer.sendTo(targetId,"CrossWindow”,”窗口A发给窗口B”)
// B窗口
ipcRenderer.on("CrossWindow",(event,...params)=>{
console.log("CrossWindow Request from ",event.senderId,...params) // B窗口可以把senderId记录下来,并通过它给A窗口发送消息
ipcRenderer.sendTo(event.senderId,"CrossWindow”,”窗口B发给窗口A”)
})
一旦两个窗口都获悉对方的webContentsId,后续就可以自由地发送消息了(事件名可以任意指定)
(2) 使用MessagePort
MessagePort并不是Electron提供的能力,而是基于MDN的web标准API,这意味着它可以在渲染进程直接创建。同时Electron提供了nodejs侧的实现,所以它也能在主进程创建。
// 在渲染进程
const messageChannel = new MessageChannel();
console.log(messageChannel.port1);
console.log(messageChannel.port2);
// 在主进程
import { MessageChannelMain } from 'electron';
const messageChannel = new MessageChannelMain();
console.log(messageChannel.port1);
console.log(messageChannel.port2);
两侧创建的port对象,在能力上是对称的,由主进程创建的对象,可以通过
win.webContents.postMessage('port', null, [port1])
方法发送给BrowserWindow,在窗口侧需要监听同名事件
ipcRenderer.on('port', e => {})
拿到e.ports[0]对象并保存下来。
主进程只需要把port分发给A和B窗口,两个窗口之后各自持有port1和port2之后,就可以通过他们进行通信了。
细节代码参见官方文档: https://www.electronjs.org/docs/latest/tutorial/message-ports
看起来MessagePort似乎不如sendTo方便,对于简单的窗口通信,一般来说sendTo就足够用了。
但它和ipcRenderer.sendTo的最大区别在于,后者是基于WebContents的,所以只有具备webContents的对象才能使用,但messagePort是web标准,还适用于webWorker或者iframe,这意味着我们可以直接建立A窗口/主进程和B窗口的worker或iframe的通信链路。在特定业务场景下,这是非常方便的能力。在后面介绍iframe的部分,会给出实践。
三、独立视图容器BrowserView
BrowserView也是由主进程创建的独立视图容器,可以内嵌在其它BrowserWindow里,加载另一个url,有点类似于Iframe,但比iframe工作在更底层,拥有独立的webContents。
原理上来说,创建一个BrowserView相当于在Chrome浏览器里增加一个Tab。一个窗口可以内嵌多个BrowserView,创建时可以指定相对宿主窗口的偏移坐标。在需要给业务窗口嵌入第三方子页面的时候,使用BrowserView可以保证子页面的独立性,避免影响到宿主页面的运行。
const win = new BrowserWindow({ width: 800, height: 600 })
const view = new BrowserView()
win.setBrowserView(view)
view.setBounds({ x: 0, y: 0, width: 300, height: 300 }) // 指定view相对于宿主窗口的位置
view.webContents.loadURL('https://electronjs.org') //view也有独立的webContents对象
但BrowserView也有局限性,由于它是主进程创建并“贴”在宿主窗口上的,所以它的渲染环境完全独立,游离在宿主页面的dom树之外,意味着一旦创建,宿主页面的其它元素都无法通过设置z-index的方式透显在它上面。
1. BrowserView和主进程通信
因为BrowserView有独立的webcontents,并且可以挂载proload脚本,所以它在ipc通信层面的地位和BrowserWindow完全一样,我们可以通过同样的方式,直接在主进程和它交换消息,无需经过宿主转发。不同的BrowserView之间也可以通过sendTo来互相通信。
2. BrowserView和宿主页面通信
正因为BrowserView的上下文是完全独立的,所以无法直接和宿主页面互通。当它需要和素主页面交换消息的时候,同样需要使用窗口对窗口的方式,交换webContentsid或者MessagePort。这是它和传统内嵌页面iframe的最大的区别。
四、内嵌DOM标签<Iframe>
Iframe的概念相信每个web开发都很熟悉,它和Electron框架无关,是浏览器dom标准里自带的内嵌标签,也是最为基础的内嵌方案。在Electron里,iframe没有webContents,而是以宿主页面contents下面的一个frame的形式存在。
1. Iframe和宿主页面通信
和宿主页面的通信方式,就是我们熟悉的postMessage,完全的web标准,这里不再赘述。
2. Iframe和主进程通信
因为iframe没有独立的webContents,无法直接和主进程建立连接,那么最容易想到的方式,就是通过宿主页面转发,先使用postMessage把所有请求发到外层,再通过ipcRenderer发到主进程,拿到结果之后再发回给iframe。
这样固然可以,但实现起来还是颇为繁琐,而且每个请求都要二次通信,在请求较多的情况下也会影响性能。
前文提到messageChannel的特性在渲染侧和node侧都有对称的实现,那么我们可以把宿主页面作为“中介”,只进行一次端口交换,后续让主进程和iframe直接经由端口来通信。
// 主进程
this.win.once('ready-to-show', () => {
const { port1, port2 } = new MessageChannelMain()
this.win.webContents.postMessage('sendPort', null, [port1])
port2.start();//注意,这里一定要调用一次start,否则消息会一直pending而不触发回调
// 使用port2给iframe发消息,也可以接收iframe发来的消息
port2.on('message',(event)=>{
console.log("主进程收到iframe发来的消息",event.data);
})
setTimeout(()=>{
port2.postMessage("主进程发给iframe的消息 ");
},5000)
})
// 宿主页面
ipcRenderer.on('sendPort', event => {
const port2 = event.ports[0]
const iframe = document.querySelector("iframe");
// 注意,如果父窗口和iframe跨域了,第二个参数要设成*
iframe.contentWindow.postMessage("sendPortToIframe", '*', [port2]);
})
// iframe内部
let messagePort;
window.addEventListener("message", function (event) {
messagePort = event.ports[0];
// 监听宿主发来的消息,把port存下来,就可以直接和主进程通信了
messagePort.onmessage = function (event) {
console.log('iframe 收到主进程发来的消息',event)
};
// 用 port给主进程发消息
messagePort.postMessage('iframe给主进程发消息');
});
可以看出,连接建立过程中有三个角色参与,但宿主页面只需要转发一次port,后续就可以抽身而出,不必再关心iframe和主进程的通信了。
经过笔者实践,上述代码基于Electron20版本可以正常运行。只不过iframe创建的时机不一定是宿主窗口的ready-to-show,也有可能是后续切特定路由的时候,那么相应的,new messageChannel的时机也要做出调整,整体而言,流程还是有些繁琐。
而且由于iframe没有类似preload的预加载脚本,这些初始化的代码需要侵入到子业务代码里完成,跨业务的开发协作起来也是比较麻烦的。
五、内嵌视图容器 <webview> Tag
通过前文可以看出,BrowserView和iframe各有各的局限,前者独立于宿主的文档流之外,无法跟随宿主页面的排版规则,也没办法覆盖一些全局的弹窗和浮层,使用上受到很大限制。后者没有独立的运行环境,和其它进程建立通信比较麻烦,而且容易影响到宿主页面的运行。
<webview> Tag折中了二者的机制,它和<iframe>Tag一样,可以嵌入宿主页面的文档流里,但却像BrowserView似的拥有独立的WebContents,并且支持挂载私有的proload脚本。
<!DOCTYPE html>
<html lang="">
<body>
<div id="drag-area">webview测试</div>
<webview
id="testWebview"
src="file:///xxxx/embedpage.html?subBusinessType=someBusiness"
style="width: 400px; height: 480px; position: absolute; top: 0; left: 0; z-index: 1000"
preload="file:///xxxx/testpreload.js"
></webview>
</body>
<script>
const webview = document.getElementById('testWebview');
</script>
</html>
我们通过dom query api拿到的webview对象,会被Electron劫持并替换成一个shadow Dom,它是一个HTMLElement,但同时也具备EmittEvent的功能,可以把它当作一个webContents来使用。
注意,Electron里的<webview>tag是基于chrome app的标准开发的,由于后者已经被Chrome抛弃,所以Electron开发者也无法保证后续版本的可用性。
但因为它实在太过方便,在依赖版本可控的情况下,还是值得一试的。如果未来真的废弃了,也可以把它迁移回iframe,作为降级替代方案。
1. <webview>和宿主窗口通信
因为选中的<webview>对象具有send方法,等同于ipcRenderer.send,使用它可以直接从宿主窗口抛送事件到webview内部,在内部需要通过ipcRenderer.on来监听。
// 从宿主到webview
// 宿主侧
webview.send("HostToWebview","hello webview")
// webview侧
ipcRenderer.on("HostToWebview",(event,...params)=>{
console.log("from host:",...params) })
});
反之,在Webview内部,可以通过ipcRenderer.sendToHost发送事件,在宿主页面通过给webview对象增加ipc-message的事件监听器来接收处理
// 从webview到宿主
// webview侧
ipcRenderer.sendToHost("WebviewToHost","hello host")
// 宿主侧
webview.addEventListener("ipc-message", (event) => {
console.log("from webview:", event.channel, event.args);
});
和上面提到的原则一样,webview一侧调用ipcRenderer要限定在proeload里面,避免直接把原生对象暴露到渲染上下文。
2. <webview>和主进程通信
我们知道<webvw>Tag是有独立webConents的,意味着主进程可以直接和它通信,但这里有个特殊之处,它是由宿主窗口在渲染进程里创建的,所以当它创建的时候,主进程并不知道它的存在,需要要由它先发送一个通知。
注意和iframe不同的是,通知的过程可以在webview自己的preload里进行,无需宿主页面转发。
// webview侧(通常是在preload里)
// 发送注册请求,subBusinessType可以是一个标识业务类型的字符串,方便主进程区分,也可以省略。
ipcRenderer.invoke("webviewRegister", subBusinessType)
// 监听主进程发来的事件
ipcRenderer.on(“MainToWebview”,, (event, ...params) => {
console.log("收到住进程的事件”,…params)
})
// 主进程
// 处理注册请求
ipcMain.handle('webviewRegister', (event, subBusinessType:SubBusinessType) => {
// 通过event拿到processId和frameId,作为后续发送事件的标识。
// 注意,之所以需要processId,是因为webview和宿主页面跨域的情况下,二者是运行在不同进程里的,需要通过[processId, frameId]二元对来标识,不可省略。
console.log('webview注册subBussiness类型', subBusinessType, event.processId, event.frameId);
const processId = event.processId;
const frameId = event.frameId; // 拿到sender(webview的webContents对象)并且进行发送。
event.sender.sendToFrame([processId, frameId],“MainToWebview”,“helloWebview”);
})
注意到这其中的神奇之处了么?webview的webContents对象可以直接通过事件event的sender属性获取,无需通过宿主的win对象来获得。
如此一来,<webview>就和窗体解藕了,当我们引入一些第三方子业务的时候,主进程不用关心具体是哪个窗口里嵌入了<webview>标签,只需要关心业务本身,做出对应的处理。iframe方案就无法做到这一点。
<webview>还有一个优势,注册的过程可以在preload脚本里执行,而preload脚本由父业务维护。子业务代码加载之前,我们就可以建立好和主进程之间的通道,并且把子业务需要调用的接口,封装成类似于jsApi的形式,暴露到渲染上下文,而无需入侵子业务的任何代码,还可以考虑不同子业务的公共接口复用,从架构来说比iframe要优雅得多。
整体通讯机制如图所示
六、ipc通信的封装模式实践
上文讲到的通信方式,在实际业务中,还需要进行一定的封装才会更便捷。笔者基于最近参与的新版QQ项目,分享介绍一些窗口和主进程之间的ipc通道封装经验。
这里以采用<webview>Tag嵌入的业务窗口和主进程的通信为例(其他的容器对象原理类似),封装的原则主要有两个:
1. 隔离执行环境
前文也强调过,为了应用的安全性(避免被脚本注入攻击等),我们要禁止业务直接用到原生的ipc对象,为此我们需要把执行环境在封装层面隔离开,避免直接暴露给业务代码。
2. 隔离底层细节
业务侧通常不关心通道建立的细节,只希望能够获取数据,执行命令,我们希望把ipc通信封装得尽可能简单简便,方便业务侧理解和使用。
首先我们需要明确需求,当复数个业务存在的情况下,哪些是通用的,哪些是业务私有的,我们使用基类容纳通用的部分,子类继承基类提供私有的部分。
// 主进程
class baseApiHelper{
public handlers = {
// 假设写日志是一个通用的api
writelog(ctx:IpcWebviewCtx, logType:string, ...info:any){
loggerService.log('[+'+ctx.subBusinessType+’+]’,…info);
},
}}
class SomeBusinessApiHelper extends BaseApiHelper{
public handlers = {
...super.handlers, // 继承自基类的通用api
openFile:async (ctx:IpcWebviewCtx,...params:any)=>{
// 省略具体的实现
return 'mock openFile done';
}
}
}
type IpcWebviewCtx = {
subBusinessType:SubBusinessType,
processId:number,
frameId:number,
}
其中IpcWebviewCtx是我们定义的上下文类型,包括子业务的类型标识,发送方的processId和frameId,方便handler函数针对不同的业务做一些特殊处理。
每个Helper都是一个单例,可以使用一些依赖注入框架来管理,也可以简单地new出来并且导出,总之当成单例使用即可。
接下来我们实现一个通用的注册事件,在app启动之后就执行绑定,后续任何子业务<webview>被创建,都会触发注册流程。
为了方便管理,我们把子业务标识和它的发送方id拼装起来,作为该容器私有的channelName,并为它注册监听函数,取得调用的方法名,添加上下文之后分发给hanlder函数处理。
// 主进程
// 处理全局的webview注册事件
ipcMain.handle('webviewRegisterSubBussiness', (event, subBusinessType:SubBusinessType) => {
console.log('webview注册subBussiness类型', subBusinessType, event.processId, event.frameId);
const processId = event.processId;
const frameId = event.frameId;
const channelName = 'ipc-webview-'+subBusinessType+'-'+frameId;
// 取出对应业务的Helper
const helper:any = ipcWebviewContainer.get(subBusinessType);
// 处理来自特定webview的invoke方法,添加上下文之后分配给对应的helper
ipcMain.handle(channelName, async (event: IpcMainInvokeEvent, eventName: string, ...payload)=>{
if(helper.handlers[eventName]){
return await helper.handlers[eventName]({
subBusinessType,
processId:processId,
frameId:frameId
} as IpcWebviewCtx,
...payload);
}
return Promise.reject("ipc hanlder not found")
})
// 处理来自特定webview的send方法,添加上下文之后分配给对应的helper
ipcMain.on(channelName, (event: IpcMainInvokeEvent, eventName: string, ...payload)=>{
if(helper.handlers[eventName]){
helper.handlers[eventName]({
subBusinessType,
processId:processId,
frameId:frameId
} as IpcWebviewCtx,
...payload);
}else{
console.warn("ipc hanlder not found")
}
})
return Promise.resolve(true)
});
而在渲染进程一侧,preload脚本启动后,我们就发送webviewRegisterSubBussiness事件给主进程,并且把调用器暴露到渲染上下文。业务里直接调用ipcApi.invoke或者ipcApi.send,就能执行到对应的方法
// webview preload
// 从url里取出页面的业务类型(或者任意其他方式)
const subBusinessType = parseQuery(location.search).subBusinessType;
const channelName = 'ipc-webview-'+subBusinessType+'-'+frameId;
let registerIpcPromiseReslover = ()=>{};
const registerIpcPromise = new Promise((resolve) => {
registerIpcPromiseReslover = resolve;
});
ipcRenderer.invoke("webviewRegisterSubBussiness", subBusinessType).then(res=>{
registerIpcPromiseReslover();
});
contextBridge.exposeInMainWorld('ipcApi',{
invoke: async (cmd,...params)=>{
await registerIpcPromise;
console.log("call ipcApi invoke ",cmd)
return await ipcRenderer.invoke(channelName,cmd,...params);
},
send: async (cmd,...params)=>{
await registerIpcPromise;
console.log("call ipcApi send ",cmd)
ipcRenderer.send(channelName,cmd,...params);
},
})
子业务需要调用的时候,直接使用window对象上的ipcApi就可以了
// 子业务
window.ipcApi.send('writelog','info', ‘hello IPC’);
const res = await window.ipcApi.invoke('openFile’, somefileName)
注意,这里创建了一个registerIpcPromise,这是因为注册事件到达主进程是异步的,主进程为业务的私有channel注册处理器也需要一些时间,那么在极端情况下,如果业务代码刚启动就调用了api,有可能主进程还没有完成注册,此时可能会调用失败。为了避免情况,我们用一个promise对象让invoke和send请求等一等,注册完成之后再扭转,保证所有的调用都能够被正确处理。
接下来再处理由主进程抛送的通知。
抛送通知给子业务,触发点一定是在某个主进程模块里,我们提供一个触发器给该模块,让它通过子业务类型拿到对应的触发器,触发事件。
我们把触发器也封装在baseApiHelper里,并且用一个Map来维护,这是为了兼容一个子业务有多个实例的情况(当然实际业务场景下,这种情况应该不会很多,可以酌情简化)
// 主进程
class baseApiHelper{
private emiiterMap = new Map<string,Function>;
public handlers = {
……
}
public addEmtter(key:string,emitFunc:Function){
this.emiiterMap.set(key, emitFunc);
}
public removeEmtter(key:string){
this.emiiterMap.delete(key);
}
public emitEvent(eventName:string, ...params:any){
this.emiiterMap.forEach((emitFunc)=>{
emitFunc(eventName,...params);
})
}
}
在子业务注册的时候,我们收集发送对象sender,放进emiiterMap里(还是上面的demo代码,省略重复部分)
// 主进程
// 处理全局的webview注册事件
ipcMain.handle('webviewRegisterSubBussiness', (event, subBusinessType:SubBusinessType) => {
console.log('webview注册subBussiness类型', subBusinessType, event.processId, event.frameId);
const processId = event.processId;
const frameId = event.frameId;
const channelName = 'ipc-webview-'+subBusinessType+'-'+frameId;
const helper:any = ipcWebviewContainer.get(subBusinessType);
// 处理来自特定webview的invoke方法,添加上下文之后分配给对应的helper
……
// 处理来自特定webview的send方法,添加上下文之后分配给对应的helper
……
// 添加temitter到helper,业务可以通过helper给特定webview发送事件
helper.addEmtter(processId+'-'+frameId, (eventName:string, ...params:any)=>{
event.sender.sendToFrame([processId, frameId],channelName, eventName, ...params);
})
return Promise.resolve(200)
});
而在子业务一侧,去注册对sender事件的监听,并且依次触发业务的监听器就可以了。
// webview preload
const eventCbMap = {}
ipcRenderer.on(channelName, (event, eventName, ...params) => {
eventCbMap[eventName]?.forEach(cb=>{
cb(...params);
})
})
contextBridge.exposeInMainWorld('ipcApi',{
on:(eventName, cb)=>{
console.log("页面注册监听", eventName)
if(!eventCbMap[eventName]){
eventCbMap[eventName] = []
}
eventCbMap[eventName].push(cb);
},
……
}
这样一来,通道就建立好了,需要抛事件的模块里,只要拿到对应helper,就可以触发emitter了,业务也可以通过ipcApi.on来绑定监听器,收到通知。
// 主进程任意业务模块
const someBusinessApiHelper = ipcWebviewContainer.get<SomeBusinessApiHelper>(SubBusinessType.SomeBusiness);
someBusinessApiHelper.emitEvent('helloIPC',`主进程发给webview`);
当然注册过的事件都是需要提供卸载逻辑的,可以在注册函数末尾返回一个disposer对象,用于注销监听器。
主进程的也emitter也需要在<webview>生命周期结束后予以卸载,可以选择在webview的beforeunload事件里给主进程发送一个卸载请求,并清理对应helper上的emitter对象,具体的逻辑这里不再赘述。
这样,对子业务的ipc封装就完成了,只需要约定需要哪些能力,由开发在主进程去实现,子业务在自己的代码里就可以通过ipcApi去调用,而无需关心其中的细节。
最后一点,因为<webview> Tag是可以通过渲染进程的脚本创建的,其中的preload属性又指向一个本地脚本,为了安全性,我们应该拦截'will-attach-webview’事件,检查其中的参数,规定只允许挂载我们自己的脚本,避免第三方脚本恶意篡改。也可以对webview里的一些行为做出限制,比如禁止重定向等等,具体可以参阅Electron官方文档。
七、总结
本文介绍了Electron里的四种视图容器的特点以及各自的ipc通信方式。
其中三种子视图的作用接近,都可以用来内嵌第三方业务,实际使用时,可以根据业务场景,选择最合适的方案。
![](https://jkboy.com/wp-content/uploads/2021/10/Pasted-11.png)