Electron團隊為什麼要幹掉remote模組
- 2021 年 9 月 2 日
- 筆記
- javascript/jQuery/ExtJs, Node.js
Electron團隊提供remote模組給開發者，
主要目的是為了簡化渲染進程和主進程互訪的難度，
這個目的卻是達到了。
但也帶來了很多問題，
歸納起來主要分為以下四點：
第一：它很慢
通過remote模組可以訪問主進程的對象、類型、方法，
但這些操作都是跨進程的，
跨進程操作性能上的損耗可能是進程內操作的幾百倍甚至上千倍。
假設你在渲染進程通過remote模組創建了一個BrowserWindow對象，
不但你創建這個對象的過程很慢，
後面你使用這個對象的過程也很慢。
小到更新這個對象的屬性，
大到使用這個對象的方法，
都是跨進程的，
這種累積性的性能損耗，
可想而知影響有多大。
第二：它會製造混亂
假設我們在渲染進程中通過remote模組使用了主進程的某個對象，
此對象在某個時刻會觸發一個事件（BrowserWindow對象中就有很多這樣的事件），
事件處理程式是在渲染進程中註冊的，
當事件發生時，實際上是主進程的原始對象先接到這個事件，
再非同步的通知渲染進程要執行事件處理程式，
此時可能已經錯過了很多事情，
類似event.preventDefault()這樣的操作可能毫無意義。
在一個業務複雜的應用中這類錯誤非常難排查。
第三：它會製造假象
我們在渲染進程中通過remote模組使用了主進程的某個對象，
得到的是這個對象的映射，是一個代理對象，
它看起來像是真正的對象，但實際上不是。
首先這個對象原型鏈上的屬性不會被映射到渲染進程的代理對象上。
其次類似NaN、Infinity這樣的值不會被正確的映射給渲染進程，
如果一個主進程方法返回一個NaN值
那麼渲染進程通過remote模組訪問這個方法將會得到undefined。
第四：它存在安全問題
因為remote模組底層還是通過IPC管道與主進程通訊的，
那麼假設你的應用需要載入第三方網頁，
即使你讓這些網頁運行在安全沙箱內，
惡意程式碼仍可能通過原型污染攻擊來模擬remote模組的遠程消息
以獲取訪問主進程模組的權力，逃離沙箱的控制。
反思
remote模組並非一無是處
Electron進程間通訊確實非常複雜，
不但增加了開發人員的勞動，還增加了開發人員的心智負擔
沒有remote模組開發人員該怎麼辦呢
要麼就實現自己的進程間通訊工具（我就做過一個跨進程的消息匯流排）
要麼就強行引入remote模組
實際上remote模組並非被幹掉了
而是從核心模組變成了可供開發者選擇的模組
決策權交給了開發者
但開發者再使用remote模組時，一定要考慮上面提到的那四個問題
不然你的應用程式可能會存在不穩定的現象。
