Electron团队为什么要干掉remote模块

Electron团队提供remote模块给开发者,

主要目的是为了简化渲染进程和主进程互访的难度,

这个目的却是达到了。

但也带来了很多问题,

归纳起来主要分为以下四点:

第一:它很慢

通过remote模块可以访问主进程的对象、类型、方法,

但这些操作都是跨进程的,

跨进程操作性能上的损耗可能是进程内操作的几百倍甚至上千倍。

假设你在渲染进程通过remote模块创建了一个BrowserWindow对象,

不但你创建这个对象的过程很慢,

后面你使用这个对象的过程也很慢。

小到更新这个对象的属性,

大到使用这个对象的方法,

都是跨进程的,

这种累积性的性能损耗,

可想而知影响有多大。


第二:它会制造混乱

假设我们在渲染进程中通过remote模块使用了主进程的某个对象,

此对象在某个时刻会触发一个事件(BrowserWindow对象中就有很多这样的事件),

事件处理程序是在渲染进程中注册的,

当事件发生时,实际上是主进程的原始对象先接到这个事件,

再异步的通知渲染进程要执行事件处理程序,

此时可能已经错过了很多事情,

类似event.preventDefault()这样的操作可能毫无意义。

在一个业务复杂的应用中这类错误非常难排查。


第三:它会制造假象

我们在渲染进程中通过remote模块使用了主进程的某个对象,

得到的是这个对象的映射,是一个代理对象,

它看起来像是真正的对象,但实际上不是。

首先这个对象原型链上的属性不会被映射到渲染进程的代理对象上。

其次类似NaN、Infinity这样的值不会被正确的映射给渲染进程,

如果一个主进程方法返回一个NaN值

那么渲染进程通过remote模块访问这个方法将会得到undefined。

 

第四:它存在安全问题

因为remote模块底层还是通过IPC管道与主进程通信的,

那么假设你的应用需要加载第三方网页,

即使你让这些网页运行在安全沙箱内,

恶意代码仍可能通过原型污染攻击来模拟remote模块的远程消息

以获取访问主进程模块的权力,逃离沙箱的控制。

 

反思

remote模块并非一无是处

Electron进程间通讯确实非常复杂,

不但增加了开发人员的劳动,还增加了开发人员的心智负担

没有remote模块开发人员该怎么办呢

要么就实现自己的进程间通信工具(我就做过一个跨进程的消息总线)

要么就强行引入remote模块

实际上remote模块并非被干掉了

而是从核心模块变成了可供开发者选择的模块

决策权交给了开发者

但开发者再使用remote模块时,一定要考虑上面提到的那四个问题

不然你的应用程序可能会存在不稳定的现象。

上一篇:postman使用教程11- sign 签名预处理(pre-request)


下一篇:redis-BitMaps(位图)【redis】