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