本文由融云技術(shù)團(tuán)隊(duì)分享，有修訂和改動。
1、引言
Electron 憑借其相對更低的研發(fā)成本投入、強(qiáng)大的跨平臺支持、擁有基數(shù)龐大的 Javascript 開發(fā)者受眾等優(yōu)勢，在 PC 端跨平臺桌面開發(fā)領(lǐng)域異軍突起，大受歡迎。
本文分享的是融云基于Electron的IM跨平臺PC端SDK改造過程中所總結(jié)的一些實(shí)踐經(jīng)驗(yàn)，希望對你有用。
* 友情提示：如果您對Electron的基礎(chǔ)概念還不太了解，建議您先從本系列文章的首篇《快速了解新一代跨平臺桌面技術(shù)——Electron》和第2篇《Electron初體驗(yàn)(快速開始、跨進(jìn)程通信、打包、踩坑等)》開始閱讀，否則可能難以理解本文的有關(guān)內(nèi)容。
學(xué)習(xí)交流：
（本文已同步發(fā)布于：http://www.52im.net/thread-4060-1-1.html）
2、系列文章
本文是系列文章中的第5篇，本系列總目錄如下：
3、本次改造的技術(shù)目標(biāo)
針對本次改造，我們需要達(dá)到以下4個技術(shù)目標(biāo)：
- 1）需提供與傳統(tǒng)桌面通訊軟件相匹配的能力支持；
- 2）需實(shí)現(xiàn)瀏覽器與Electron不同運(yùn)行時代碼的高度復(fù)用；
- 3）便于開發(fā)者構(gòu)建多窗口、多進(jìn)程的復(fù)雜桌面端應(yīng)用；
- 4）需同步適配同一IM端SDK的多個版本。
以下，我們將逐條討論這4個目標(biāo)所有實(shí)現(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實(shí)時雙工通信通道。
借助這些原本在瀏覽器環(huán)境下不便實(shí)現(xiàn)的技術(shù)能力，來整體提高用戶對于桌面端產(chǎn)品的使用體驗(yà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ù)代碼，從而推高項(xiàng)目整體的復(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àn)積累。
為降低類似需求場景的業(yè)務(wù)實(shí)現(xiàn)復(fù)雜度，我們需要在 PaaS 能力層面上解決多進(jìn)程連接共享、多進(jìn)程消息同步問題，讓開發(fā)者在既有編程思維模式下將每個業(yè)務(wù)實(shí)現(xiàn)的更為順暢。
7、技術(shù)目標(biāo)4：需同步適配同一IM端SDK的多個版本
我們的既有Web端 IM SDK 存在一個端多個不同版本的情況（主要是為了兼容老用戶，舊版本很難一刀切直接扔掉，只能新老版末同時并存）。
各版本都有不同數(shù)量的客戶積累，且各版本 API 接口設(shè)計(jì)迥異，跨版本升級成本較高。
考慮到使用不同版本的客戶未來將業(yè)務(wù)向 Electron 遷移的可能性，我們期望通過架構(gòu)設(shè)計(jì)的改進(jìn)來避免既有客戶做過多的集成代碼修改，在確保既有客戶不因版本升級而流失的前提下降低 Web 研發(fā)團(tuán)隊(duì)自身的多版本 SDK 維護(hù)成本。
8、本次改造的落地實(shí)踐
針對上面章節(jié)中確定的技術(shù)目標(biāo)，我們將從以下3個方向著手落地實(shí)踐：
- 1）剝離各版本的共同業(yè)務(wù)與對外差異性 API 定義；
- 2）Electron 與瀏覽器平臺下 IM SDK 的區(qū)分；
- 3）解決多進(jìn)程消息同步、多進(jìn)程連接共享問題。
以下，我們將逐條分享這3個方面的具體實(shí)踐內(nèi)容。
9、落地實(shí)踐1：剝離各版本的共同業(yè)務(wù)與對外差異性API定義
我們的 IM SDK 各版本分別為不同的代碼倉庫獨(dú)立維護(hù)，互無干系。（白話就是，所有端的IM SDK都是獨(dú)立開發(fā)，從頭造輪子）
這導(dǎo)致所有的功能（包括即將開發(fā)的 Electron 桌面解決方案）都可能要在各個版本倉庫上單獨(dú)實(shí)現(xiàn)，不僅開發(fā)成本高，還會導(dǎo)致實(shí)現(xiàn)質(zhì)量無法保證、或代碼實(shí)現(xiàn)不統(tǒng)一，同時也推高了產(chǎn)研后續(xù)流程的測試、上線等環(huán)節(jié)的成本。
▲ IM SDK 不同版本獨(dú)立維護(hù)
基于前述技術(shù)目標(biāo)4的要求，在既有現(xiàn)狀下繼續(xù)開發(fā)，就意味著需要在兩個版本的基礎(chǔ)上做不同實(shí)現(xiàn)，既不符合程序員的代碼審美，也影響團(tuán)隊(duì)整體的研發(fā)效率。（白話就是，如果又要從頭造輪子實(shí)在太難受）
為更好地達(dá)成技術(shù)目標(biāo)4，團(tuán)隊(duì)決定優(yōu)先通過重構(gòu)將既有業(yè)務(wù)分層，即各個版本所必須的業(yè)務(wù)代碼抽象下沉為 IM Engine 包，并為各個版本 IM SDK 分別實(shí)現(xiàn)不同的API Layer以便與既有線上版本接口對齊，這樣既可以降低團(tuán)隊(duì)的研發(fā)成本，也可以滿足既有線上客戶后續(xù)的升級需求。
▲ 重構(gòu)代碼實(shí)現(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、落地實(shí)踐2：Electron 與瀏覽器平臺下 IM SDK 的區(qū)分
在將 Engine 與業(yè)務(wù)層隔離后（見上一節(jié)），需要考慮 Engine 在不同的運(yùn)行時下的關(guān)鍵能力差異，并依據(jù)能力差異落實(shí) Engine 的底層設(shè)計(jì)。
Electron 環(huán)境下的連接、消息存儲等能力由 c++ 模塊編寫提供（即后面提到的 CppProto.node）：
在瀏覽器與 Electron 平臺下，從連接管理、到消息收發(fā)等實(shí)現(xiàn)方式迥異，團(tuán)隊(duì)需要對 Engine 包繼續(xù)分層，通過 AEngine 抽象類來定義 IM Engine 的能力接口，并抽象 APIContext 類用來管理 AEngine 的能力調(diào)用。
考慮到純 Web 應(yīng)用構(gòu)建尺寸問題，Electron 的能力實(shí)現(xiàn)代碼不應(yīng)被打包到標(biāo)準(zhǔn) Web 頁面內(nèi)，因此還需要將 Electron 平臺下的實(shí)現(xiàn)代碼單獨(dú)抽離出來作為一個獨(dú)立包（即ElectronSolution），作為可選模塊由開發(fā)者選擇安裝使用。
▲ Electron相關(guān)的代碼抽離為可選模塊
如上圖所示，CppEngine 在 ElectronSolution 包中定義，其需要由開發(fā)者在 Electron 應(yīng)用創(chuàng)建 BrowserWindow 實(shí)例時通過 webPreferences.preload 配置屬性向渲染進(jìn)程窗口預(yù)掛載。
APIContext 在初始化 AEngine 實(shí)例時，優(yōu)先檢測 CppEngine 是否已定義。當(dāng)發(fā)現(xiàn)有 CppEngine 定義時，則初始化 CppEngine 提供更豐富的本地化能力，否則初始化 JSEngine。
就像下面的代碼的展現(xiàn)的邏輯：
const engine: AEngine = typeofCppEngine !== 'undefined'
? newCppEngine()
: newJSEngine()
11、落地實(shí)踐3：解決多進(jìn)程消息同步、多進(jìn)程連接共享問題
ElectronSolution 包截止目前的設(shè)計(jì)中，所有代碼都運(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)程中實(shí)現(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)用，實(shí)現(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)程中實(shí)現(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)功能實(shí)現(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)用軟件來說相對薄弱，我們有計(jì)劃探索借助 node.js 的拓展能力，提供更為底層的 WebRTC 能力拓展如音效、音質(zhì)、視頻特效等。
13、參考資料
[1] 快速了解新一代跨平臺桌面技術(shù)——Electron
[2] Electron初體驗(yàn)(快速開始、跨進(jìn)程通信、打包、踩坑等)
[3] WebSocket從入門到精通，半小時就夠！
[4] Comet技術(shù)詳解：基于HTTP長連接的Web端實(shí)時通信技術(shù)
[5] 一套海量在線用戶的移動端IM架構(gòu)設(shè)計(jì)實(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）