本文由融云技術(shù)團(tuán)隊分享吏够，有修訂和改動推正。

1顿颅、引言

Electron 憑借其相對更低的研發(fā)成本投入缸濒、強(qiáng)大的跨平臺支持、擁有基數(shù)龐大的 Javascript 開發(fā)者受眾等優(yōu)勢，在 PC 端跨平臺桌面開發(fā)領(lǐng)域異軍突起绍填，大受歡迎霎桅。

本文分享的是融云基于Electron的IM跨平臺PC端SDK改造過程中所總結(jié)的一些實踐經(jīng)驗，希望對你有用讨永。

* 友情提示：如果您對Electron的基礎(chǔ)概念還不太了解滔驶，建議您先從本系列文章的首篇《快速了解新一代跨平臺桌面技術(shù)——Electron》和第2篇《Electron初體驗(快速開始、跨進(jìn)程通信卿闹、打包揭糕、踩坑等)》開始閱讀，否則可能難以理解本文的有關(guān)內(nèi)容锻霎。

（本文已同步發(fā)布于：http://www.52im.net/thread-4060-1-1.html）

2著角、系列文章

本文是系列文章中的第5篇，本系列總目錄如下：

IM跨平臺技術(shù)學(xué)習(xí)(一)：快速了解新一代跨平臺桌面技術(shù)——Electron

《IM跨平臺技術(shù)學(xué)習(xí)(二)：Electron初體驗(快速開始旋恼、跨進(jìn)程通信吏口、打包、踩坑等)》

《IM跨平臺技術(shù)學(xué)習(xí)(三)：vivo的Electron技術(shù)棧選型冰更、全方位實踐總結(jié)》

《IM跨平臺技術(shù)學(xué)習(xí)(四)：蘑菇街基于Electron開發(fā)IM客戶端的技術(shù)實踐》

《IM跨平臺技術(shù)學(xué)習(xí)(五)：融云基于Electron的IM跨平臺SDK改造實踐總結(jié)》（* 本文）

《IM跨平臺技術(shù)學(xué)習(xí)(六)：網(wǎng)易云信基于Electron的IM消息全文檢索技術(shù)實踐》（稍后發(fā)布.. ）

3产徊、本次改造的技術(shù)目標(biāo)

針對本次改造，我們需要達(dá)到以下4個技術(shù)目標(biāo)：

1）需提供與傳統(tǒng)桌面通訊軟件相匹配的能力支持蜀细；

2）需實現(xiàn)瀏覽器與Electron不同運(yùn)行時代碼的高度復(fù)用舟铜；

3）便于開發(fā)者構(gòu)建多窗口、多進(jìn)程的復(fù)雜桌面端應(yīng)用奠衔；

4）需同步適配同一IM端SDK的多個版本谆刨。

以下，我們將逐條討論這4個目標(biāo)所有實現(xiàn)的具體技術(shù)內(nèi)容归斤。

4痊夭、技術(shù)目標(biāo)1：需提供與傳統(tǒng)桌面通訊軟件相匹配的能力支持

相較于 B/S 架構(gòu)的 Web 網(wǎng)頁應(yīng)用，我們期望能夠在 Electron 環(huán)境下向開發(fā)者提供更為豐富的本地化能力官册，以及比?Websocket（或Comet）更高效的Socket實時雙工通信通道生兆。

借助這些原本在瀏覽器環(huán)境下不便實現(xiàn)的技術(shù)能力，來整體提高用戶對于桌面端產(chǎn)品的使用體驗膝宁，將 Electron 作為一個 C/S 架構(gòu)軟件運(yùn)行平臺的潛力發(fā)揮到最大鸦难。（白話就是，我們希望借助Electron這個框架员淫，將原本W(wǎng)eb端的一些雞肋能力合蔽，做到像原生富客戶端一樣）

5、技術(shù)目標(biāo)2：瀏覽器與Electron不同運(yùn)行時代碼的高度復(fù)用

由于 Electron 與標(biāo)準(zhǔn) Web 應(yīng)用擁有幾乎相同的技術(shù)生態(tài)介返，因此多數(shù)產(chǎn)品會要求前端代碼工程兼顧瀏覽器與 Electron拴事。

也就是說沃斤，一套代碼既要打包為傳統(tǒng)桌面端應(yīng)用（利用Electron），又可發(fā)布為瀏覽器中運(yùn)行的 Web 網(wǎng)頁應(yīng)用刃宵。

基于此衡瓶，我們提供的 IM SDK 需要在兩種不同的運(yùn)行時環(huán)境下做到差異最小化，避免開發(fā)者編寫冗余的平臺兼容代碼牲证。（白話就是哮针，盡可能在基于Electron的桌面端和純Web網(wǎng)頁端之間重用更多的代碼，不然又得多擼一個全新的Electron端坦袍，這得多費(fèi)勁）

6十厢、技術(shù)目標(biāo)3：便于開發(fā)者構(gòu)建多窗口、多進(jìn)程的復(fù)雜桌面端應(yīng)用

Electron 通過對 IPC 能力的封裝為桌面端應(yīng)用開發(fā)提供了較完善的跨進(jìn)程通訊方案捂齐，借助此能力蛮放，開發(fā)者構(gòu)建的桌面端應(yīng)用也逐漸趨于復(fù)雜。

比較典型的如桌面端IM產(chǎn)品：通常用一個獨(dú)立窗口做基礎(chǔ)的 IM 聊天業(yè)務(wù)奠宜，一個窗口做歷史聊天記錄查詢業(yè)務(wù)包颁。

當(dāng)有音視頻會議業(yè)務(wù)場景時，還需要再開一個窗口做會議業(yè)務(wù)挎塌。

甚至有開發(fā)者提出了與每個聊天對象都保持一個獨(dú)立聊天窗口的需求（產(chǎn)品形態(tài)如 QQ）徘六。

在這類需求下内边，長連接狀態(tài)維持榴都、消息同步變得異常復(fù)雜，原因在于以下3個方面漠其。

1）若每個進(jìn)程窗口都維持獨(dú)立長連接嘴高，難免會出現(xiàn)某一進(jìn)程連接與其他進(jìn)程連接狀態(tài)不同步。且開發(fā)者需在各進(jìn)程同時維護(hù)連接狀態(tài)和屎，復(fù)雜度較高拴驮。同時還會造成服務(wù)的并發(fā)能力下降。

2）若僅有單一主窗口進(jìn)行連接維持柴信，其他窗口通過 IPC 能力將主窗口作為連接代理套啤，則需要在主進(jìn)程、各渲染進(jìn)程中維護(hù)復(fù)雜的跨進(jìn)程通訊業(yè)務(wù)代碼随常，從而推高項目整體的復(fù)雜度潜沦。

3）目前的 Electron 開發(fā)者絕大多數(shù)來自于 Web 開發(fā)者，既有編程思維是建立在瀏覽器頁面內(nèi)單進(jìn)程單線程的應(yīng)用模型下構(gòu)建起來的绪氛，對于處理此類多進(jìn)程模型的產(chǎn)品開發(fā)缺乏相關(guān)的經(jīng)驗積累唆鸡。

為降低類似需求場景的業(yè)務(wù)實現(xiàn)復(fù)雜度，我們需要在 PaaS 能力層面上解決多進(jìn)程連接共享枣察、多進(jìn)程消息同步問題争占，讓開發(fā)者在既有編程思維模式下將每個業(yè)務(wù)實現(xiàn)的更為順暢燃逻。

7、技術(shù)目標(biāo)4：需同步適配同一IM端SDK的多個版本

我們的既有Web端 IM SDK 存在一個端多個不同版本的情況（主要是為了兼容老用戶臂痕，舊版本很難一刀切直接扔掉伯襟，只能新老版末同時并存）。

各版本都有不同數(shù)量的客戶積累握童，且各版本 API 接口設(shè)計迥異逗旁，跨版本升級成本較高。

考慮到使用不同版本的客戶未來將業(yè)務(wù)向 Electron 遷移的可能性舆瘪，我們期望通過架構(gòu)設(shè)計的改進(jìn)來避免既有客戶做過多的集成代碼修改片效，在確保既有客戶不因版本升級而流失的前提下降低 Web 研發(fā)團(tuán)隊自身的多版本 SDK 維護(hù)成本。

8英古、本次改造的落地實踐

針對上面章節(jié)中確定的技術(shù)目標(biāo)淀衣，我們將從以下3個方向著手落地實踐：

1）剝離各版本的共同業(yè)務(wù)與對外差異性 API 定義；

2）Electron 與瀏覽器平臺下 IM SDK 的區(qū)分召调；

3）解決多進(jìn)程消息同步膨桥、多進(jìn)程連接共享問題。

以下唠叛，我們將逐條分享這3個方面的具體實踐內(nèi)容只嚣。

9、落地實踐1：剝離各版本的共同業(yè)務(wù)與對外差異性API定義

我們的 IM SDK 各版本分別為不同的代碼倉庫獨(dú)立維護(hù)艺沼，互無干系册舞。（白話就是，所有端的IM SDK都是獨(dú)立開發(fā)障般，從頭造輪子）

這導(dǎo)致所有的功能（包括即將開發(fā)的 Electron 桌面解決方案）都可能要在各個版本倉庫上單獨(dú)實現(xiàn)调鲸，不僅開發(fā)成本高，還會導(dǎo)致實現(xiàn)質(zhì)量無法保證挽荡、或代碼實現(xiàn)不統(tǒng)一藐石，同時也推高了產(chǎn)研后續(xù)流程的測試、上線等環(huán)節(jié)的成本定拟。

▲ IM SDK 不同版本獨(dú)立維護(hù)

基于前述技術(shù)目標(biāo)4的要求耘眨，在既有現(xiàn)狀下繼續(xù)開發(fā)疼鸟，就意味著需要在兩個版本的基礎(chǔ)上做不同實現(xiàn)，既不符合程序員的代碼審美，也影響團(tuán)隊整體的研發(fā)效率憎兽。（白話就是蜻势，如果又要從頭造輪子實在太難受）

為更好地達(dá)成技術(shù)目標(biāo)4读恃，團(tuán)隊決定優(yōu)先通過重構(gòu)將既有業(yè)務(wù)分層愕鼓，即各個版本所必須的業(yè)務(wù)代碼抽象下沉為 IM Engine 包，并為各個版本 IM SDK 分別實現(xiàn)不同的API Layer以便與既有線上版本接口對齊需曾，這樣既可以降低團(tuán)隊的研發(fā)成本吗坚，也可以滿足既有線上客戶后續(xù)的升級需求祈远。

▲ 重構(gòu)代碼實現(xiàn)業(yè)務(wù)分層

完成業(yè)務(wù)分層后，對于 IM SDK 有依賴的其他產(chǎn)品如 RTC SDK商源，也都可以擺脫對 IM SDK 接口的依賴而直接調(diào)用 Engine 層接口车份，業(yè)務(wù)層在拓展 RTC 業(yè)務(wù)時，也就無需再考慮 IM SDK 的版本問題牡彻。

▲ 業(yè)務(wù)分層后的結(jié)構(gòu)將保證拓展性

做分層的另一個考慮還為了達(dá)成技術(shù)目標(biāo)2扫沼，將與業(yè)務(wù)層的交互限制在 API 層，在 Engine 中處理 Electron 與瀏覽器兩種運(yùn)行時下的代碼差異庄吼，業(yè)務(wù)層只需關(guān)心 IM SDK 的接口調(diào)用而無需關(guān)心底層差異缎除，確保業(yè)務(wù)層在兩種運(yùn)行時下只需要維護(hù)極少甚至無需維護(hù)兼容代碼，便于業(yè)務(wù)層更專注于業(yè)務(wù)開發(fā)总寻。

10器罐、落地實踐2：Electron 與瀏覽器平臺下 IM SDK 的區(qū)分

在將 Engine 與業(yè)務(wù)層隔離后（見上一節(jié)），需要考慮 Engine 在不同的運(yùn)行時下的關(guān)鍵能力差異渐行，并依據(jù)能力差異落實 Engine 的底層設(shè)計轰坊。

Electron 環(huán)境下的連接、消息存儲等能力由 c++ 模塊編寫提供（即后面提到的 CppProto.node）：

在瀏覽器與 Electron 平臺下祟印，從連接管理肴沫、到消息收發(fā)等實現(xiàn)方式迥異，團(tuán)隊需要對 Engine 包繼續(xù)分層蕴忆，通過 AEngine 抽象類來定義 IM Engine 的能力接口颤芬，并抽象 APIContext 類用來管理 AEngine 的能力調(diào)用。

考慮到純 Web 應(yīng)用構(gòu)建尺寸問題孽文，Electron 的能力實現(xiàn)代碼不應(yīng)被打包到標(biāo)準(zhǔn) Web 頁面內(nèi)驻襟，因此還需要將 Electron 平臺下的實現(xiàn)代碼單獨(dú)抽離出來作為一個獨(dú)立包（即ElectronSolution），作為可選模塊由開發(fā)者選擇安裝使用芋哭。

▲ Electron相關(guān)的代碼抽離為可選模塊

如上圖所示，CppEngine 在 ElectronSolution 包中定義郁副，其需要由開發(fā)者在 Electron 應(yīng)用創(chuàng)建 BrowserWindow 實例時通過 webPreferences.preload 配置屬性向渲染進(jìn)程窗口預(yù)掛載减牺。

APIContext 在初始化 AEngine 實例時，優(yōu)先檢測 CppEngine 是否已定義存谎。當(dāng)發(fā)現(xiàn)有 CppEngine 定義時拔疚，則初始化 CppEngine 提供更豐富的本地化能力，否則初始化 JSEngine既荚。

就像下面的代碼的展現(xiàn)的邏輯：

const engine: AEngine = typeofCppEngine !== 'undefined'

??? newCppEngine()

??: newJSEngine()

11稚失、落地實踐3：解決多進(jìn)程消息同步、多進(jìn)程連接共享問題

ElectronSolution 包截止目前的設(shè)計中恰聘，所有代碼都運(yùn)行在渲染進(jìn)程內(nèi)句各。

這意味著每個進(jìn)程彼此獨(dú)立吸占，都在維護(hù)獨(dú)立的進(jìn)程狀態(tài)，無法滿足目標(biāo) 3 中多進(jìn)程狀態(tài)同步凿宾、連接共享的需求矾屯。

為了解決該問題，需要將?CppProto.node?模塊放到主進(jìn)程初厚，在主進(jìn)程中實現(xiàn)連接管理件蚕、消息收發(fā)等能力，多個渲染進(jìn)程通過 IPC 通信共享主進(jìn)程狀態(tài)产禾。

▲ 多個渲染進(jìn)程通過 IPC 通信共享主進(jìn)程狀態(tài)

為了達(dá)成技術(shù)目標(biāo)3的要求排作，ElectronSolution 需要拆分為兩個子包，即Main 與 Renderer亚情。

具體就是：

1）Main 包運(yùn)行在主進(jìn)程內(nèi)纽绍，負(fù)責(zé)維持 CppProto.node 模塊的調(diào)用，實現(xiàn)底層連接管理势似、消息管理等功能拌夏，同時通過 Electron 提供的 ipcMain 與各渲染進(jìn)程維持通信；

2）Renderer 包中定義 CppEngine 類履因，繼承自 Engine 包內(nèi)的 AEngine 抽象類障簿，依然通過 webPreferences.preload 用來作為主進(jìn)程的代理，通過 ipcRenderer 與主進(jìn)程維持通信栅迄。

▲ 拆分為Main與Renderer兩個子包

修改完成后站故，ElectronSolution 包的整體結(jié)構(gòu)基本確定。

以下列出 ElectronSolution 包關(guān)鍵目錄結(jié)構(gòu)供參考：

node_modules/@rongcloud/electron-solution

├── index.js

├── main

│?? ├── addon

│?? │?? ├── binding

│?? │?? │?? └── electron-v{electron-version}-{platform}-{arch}.node

│?? │?? └── index.js

│?? ├── dist

│?? │?? └── index.js

│?? ├── index.js

│?? └── package.json

└── renderer

│?? ├── dist

│?? │?? └── index.js

│?? ├── index.js

│?? └── package.json

└── package.json

基于上述架構(gòu)變動毅舆，當(dāng)業(yè)務(wù)層需要在多個渲染進(jìn)程中實現(xiàn) IM 能力時西篓，僅需要關(guān)注在各個進(jìn)程中的 IM SDK 接口調(diào)用，由 ElectronSolution 處理多進(jìn)程之間的狀態(tài)同步問題憋活。

當(dāng)開發(fā)者期望由既有 Web 業(yè)務(wù)向 Electron 平臺遷移時岂津，開發(fā)者也無需修改既有的 Web 業(yè)務(wù)代碼，僅需要增量編寫主進(jìn)程代碼相關(guān)功能實現(xiàn)悦即，將 ElectronSolution 安裝并集成到 Electron 桌面端應(yīng)用中即可吮成。

最終，我們形成了以下這樣的IM SDK整體結(jié)構(gòu)：

12辜梳、未來的規(guī)劃

除了上述IM相關(guān)業(yè)務(wù)粱甫，后續(xù)我們還打算在Electron平臺下提升RTC的場景能力。

目前作瞄，Electron 平臺下由 Chromium 原始提供的 WebRTC 能力對于開發(fā)桌面級音視頻應(yīng)用軟件來說相對薄弱茶宵，我們有計劃探索借助 node.js 的拓展能力，提供更為底層的 WebRTC 能力拓展如音效宗挥、音質(zhì)乌庶、視頻特效等种蝶。

13、參考資料

[1]?快速了解新一代跨平臺桌面技術(shù)——Electron

[2]?Electron初體驗(快速開始安拟、跨進(jìn)程通信蛤吓、打包、踩坑等)

[3]?WebSocket從入門到精通糠赦，半小時就夠会傲！

[4]?Comet技術(shù)詳解：基于HTTP長連接的Web端實時通信技術(shù)

[5]?一套海量在線用戶的移動端IM架構(gòu)設(shè)計實踐分享(含詳細(xì)圖文)

[6]?Web端即時通訊技術(shù)盤點(diǎn)：短輪詢、Comet拙泽、Websocket淌山、SSE

[7]?搞懂現(xiàn)代Web端即時通訊技術(shù)一文就夠：WebSocket、socket.io顾瞻、SSE

（本文已同步發(fā)布于：http://www.52im.net/thread-4060-1-1.html）