【Electron】酷家樂客戶端開發實踐分享 — 進程通信

作者:鐘離,酷家樂PC客戶端負責人
原文地址:https://webfe.kujiale.com/electron-ku-jia-le-ke-hu-duan-kai-fa-shi-jian-fen-xiang-jin-cheng-tong-xin/
酷家樂客戶端:下載地址 https://www.kujiale.com/activity/136
文章背景:在酷家樂客戶端在V12改版成功后,我們積累了許多的寶貴的經驗和最佳實踐。前端社區里關于Electron知識相對較少,因此希望將這些內容以系列文章的形式分享出來。
系列文章:

前言

Electron中的進程,其實就是計算機中的進程,我們先來看看什么是進程通信

進程間通信(IPC,Inter-Process Communication),指至少兩個進程或線程間傳送數據或信號的一些技術或方法

每個進程都有自己的一部分獨立的系統資源,彼此是隔離的。為了能使不同的進程互相訪問資源并進行協調工作,才有了進程間通信。

一個Electron應用有一個主進程和多個渲染進程,渲染進程還可能內嵌多個webview。兩兩之間都可能需要進行通信,情況還是比較復雜的。

需要通信的對象

主進程: 使用ipcMain進行通信
渲染進程: 使用ipcRendererremote模塊進行通信
webview: 一般會禁用webview的node集成,然后使用preload的方式拿到ipcRenderer來做進程通信。

// preload.js

const electron = require('electron');

const { ipcRenderer } = electron;

// 把ipcRenderer掛載到window上,webview內部的js可以拿到這個模塊
window.ElectronIpcRenderer = ipcRenderer;

ipcRenderer/ipcMain VS remote

主進程和渲染進程通信方式,擰出來單獨說一下。先來看一個簡單例子的:

點擊創建按鈕,創建一個新的窗口。點擊關閉按鈕,關掉這個新窗口。


ipc VS remote

左側代碼使用ipcRenderer/ipcMain進行通信,右側代碼使用remote進行通信。實現的功能都是一樣的。從這個例子中可以發現:

  1. 使用ipcMain/ipcRenderer通信,業務邏輯同時存在于主進程和渲染進程的代碼中。同時為了通信,會產生非常多的event & event handler
  2. 使用remote通信,渲染進程直接獲取主進程模塊。而且,使用remote通信不需要使用事件和回調函數,寫出來的代碼清晰直觀。

主進程可以視作為模塊提供者,而渲染進程是模塊的消費者,渲染進程通過remote來獲取主進程的模塊,實現業務邏輯。這樣做有以下好處:

  1. 主進程/渲染進程代碼解耦,職責分明,提升可維護性
  2. 業務邏輯內聚在渲染進程
  3. 減少主進程/渲染進程冗余無用的代碼

具體實現

介紹了一下前置知識,現在來看看不同情況下,Electron進程通信的實現方法。

主進程和渲染進程通信

主進程發消息、渲染進程收消息:主進程使用窗口的webContents發消息,渲染進程內使用ipcRenderer收消息

// main.js
const win = new BrowserWindow();
win.load('index.html');
win.webContents.send('hello', {a: 1});


// index.html 中的js
const { ipcRenderer } = require('electron');
ipcRenderer.on('hello', (e, data) => {
    console.log(data); // 打印出 {a: 1}
})

渲染進程發消息、主進程收消息: 渲染進程使用ipcRenderer發消息,主進程使用ipcMain收消息。

// main.js
const { ipcMain } = require('electron');
ipcMain.on('hello', (e, data) => {
    console.log(data); // 打印出 {a: 1}
});


// index.html 中的js
const { ipcRenderer } = require('electron');
ipcRenderer.send('hello', {a: 1});

一般遇到主進程和渲染進程通信的情況,大部分都是渲染進程來需要獲取主進程的模塊,此時推薦使用remote來做通信。


// main.js
// 主進程無需添加任何代碼

// index.html 中的js,獲取主進程模塊
const { remote } = require('electron');
const {app, BrowserWindow, dialog, ...} = remote;

渲染進程與渲染進程通信

渲染進程之間也是會頻繁通信的,具體場景舉例:在設置窗口點擊更換皮膚,需要通知所有窗口進行顏色、背景的更新。

最佳實踐:渲染進程A通過remote模塊,獲取到需要目標窗口的webContents對象,然后通過webContents向目標窗口的發送消息。目標窗口使用ipcRenderer監聽事件。

const { remote } = require('electron')
const allWindows = remote.BrowserWindow.getAllWindows();

// 窗口A中的邏輯

// 1、第一步,獲取到目標窗口的webContents
// 可以根據id,title來找到目標窗口,也可以用其他辦法
const targetId = 1;
const targetTitle = '目標窗口';
// let targetWindow = allWindows.find(w => w.id === targetId);
let targetWindow = allWindows.find(w => w.title === targetTitle);

// 2、第二步,使用目標窗口的webContents發送消息
targetWindow.webContents.send('theme-change', 'gray');


// 目標窗口內的邏輯,使用ipcRenderer監聽事件
// 窗口收到theme-change事件,改變窗口顏色。不需要關注事件從哪里發出,只需要關注接收到該事件后做什么
ipcRenderer.on('theme-change', (e, theme) => {
    console.log(theme); // gray
});

還有一種傳統的辦法,不用remote,改用ipcMain做通信,但是會在主進程冗余很多事件代碼。因此還是推薦使用remote,理由同上。小例子:


// mian.js 
// 用于事件轉發,沒有實際的邏輯
ipcMain.on('send-event-to-window', (e, id, eventName, ...args) => {
    BrowserWindow.getAllWindows()
    .find(w = > w.id === id)
    .webContents
    .send(eventName, ...args);
});

// 窗口A內部,向主進程發事件
const targetId = 1;
ipcRenderer.send('send-event-to-window', id, 'theme-change', 'gray');

// 目標窗口
ipcRenderer.on('theme-change', (e, theme) => {
    console.log(theme); // gray
});

webview與渲染進程通信

內嵌的web頁面運行在客戶端中,也可以獲取本地化的能力。此時,webview就需要與渲染進程通信了。

在文章開頭講到了,為了應用的安全性webview是需要禁用node集成的,通過preload的方式,注入了一個ipcRenderer并掛載到window上。

webview發消息,渲染進程收消息:webview內部使用ipcRenderer.sendToHost來發消息。渲染進程獲取到webview的dom元素,監聽dom元素的ipc-message事件接收消息


// 渲染進程拿到webview的dom,接收事件
const webview = document.querySelector('webview')
webview.addEventListener('ipc-message', (event) => {
  console.log(event.channel); // hello
});

// webview頁面內,假裝點了一個按鈕,發送事件
btn.onclick = () => {
    window.ElectronIpcRenderer.sendToHost('hello')
}

渲染進程發消息,webview收消息:渲染進程使用webview.send發消息。webview使用內置的ipcRenderer收消息。

// webview內部
window.ElectronIpcRenderer.on('event-from-renderer', (e, data) => {
    console.log(e, data); // {a: 1}
});

// 渲染進程內部
const webview = document.querySelector('webview')
webview.send('event-from-renderer', {a: 1})

總結

這三種通信方式是最基礎的,在此之上進行排列組合也是很常見的,這個由開發者自行拓展即可。

進程通信

舉一個小例子:webview內部觸發更換皮膚功能 -> 通知渲染進程同步更新皮膚 -> 渲染進程收到消息,向其他渲染進程通信 -> 同步更新皮膚完成。

最后

歡迎大家在評論區討論,技術交流 & 內推 -> zhongli@qunhemail.com

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,197評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,415評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,104評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,884評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,647評論 6 408
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,130評論 1 323
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,208評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,366評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,887評論 1 334
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,737評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,939評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,478評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,174評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,586評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,827評論 1 283
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,608評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,914評論 2 372

推薦閱讀更多精彩內容