本文由得物技術團隊Uni分享，即時通訊網收錄時有內容修訂和排版優化。
一、引言
本文要分享的是得物技術團隊基于Electron開發客服IM桌面端的技術實踐過程，內容包括桌面技術選型、Electron的基礎概念、具體的實施技術方案、遇到的棘手問題等。
Electron社區雖然很活躍，但是不一樣的場景遇到的技術問題，幾乎找不到對應的解決方案，我們很多都是在探索過程中不斷的去完善，希望本文能帶給你一些啟發。
學習交流：
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）
（本文已同步發布于：http://www.52im.net/thread-4159-1-1.html）
二、系列文章
本文是系列文章中的第7篇，本系列總目錄如下：
三、業務背景
隨著公司業務的快速發展，商家客服也納入了我們的服務范圍，商家客服工作臺的定位是通過工具和數據服務商家，一站式解決用戶購買咨詢訴求。通過工具和運營策略協助商家提升服務品質，讓品牌商家有動力運營好潛在的客戶，從而達到提升用戶服務的目標。
已有web端聊天系統的前提下，商家客服為什么要遷移桌面應用？
首先我們收到部分商家客服反饋：
用戶是上帝，我們是很重視用戶的反饋的，所以首先我們想的是如何在web端解決這些問題，下面我們逐一分析下以上問題我們能不能在網頁端解決呢？
1）針對客服A同學問題：大多數客服職場的臺式機是不會安裝音頻設備，如果人家沒音頻，沒外音，我們能強迫他買個播放器嗎，那肯定是不能.，如果是自營客服還有點處理方案，真需要，公司可以統一采購，但是ToC的顯然不能強制做什么事情，所以此問題無解.
2）針對客服B同學問題：這句話怎么理解呢？是這樣的，在一屏既有web瀏覽器，又有其他應用如飛書之類的PC應用疊著放，web notification通知由于是瀏覽器級別的，提醒不到最上層，瀏覽器的提醒確實有點弱（看不到提醒會影響到客服的首響，首響會影響客服的績效，咱公司對于用戶的服務效率是比較嚴格的），所以此問題無解。
3）針對客服C同學問題：em。。。好的，您說的對，web網頁給商家客服的感覺就是我們平臺有點趕不上形勢。
基于上面的一些場景，想必大家已經對為何做桌面應用有個初步的了解。下面以一張圖來看下Web應用跟桌面應用的區別。
四、技術選型
為什么會選擇Electron而不是其他應用開發框架？
4.1、Electron架構簡介
Electron的構成主要是上面的3個大模塊，每個模塊各司其職，讓Electron有了桌面應用的能力。
逐個理解Electron的3個大模塊：
- 1）Chromium：可以為Electron提供UI渲染能力，再加上Chromium本身就是跨平臺的，所以也不用考慮代碼的兼容性（只要有Chromium，就能用JavaScript，HTML，CSS這些前端開發工程師所熟知的三劍客來開發頁面）；
- 2）Node.js：Chromium并不具備原生GUI操作的能力，所以Node.js正好補足了這個能力（能夠調用操作系統的底層 API，比如path、fs、crypto 這些模塊，甚至能集成C++）；
- 3）Native APIs：Native API讓Electron有了跨平臺和桌面端的原生能力（比如說它有統一的原生界面，窗口、托盤這些）。
4.2、Electron與其他框架的區別
下面是Electron與Native、QT、NW應用的對比圖：
如上圖所示：
- 1）Native(C++/C#/Objective-C)不管從原生體驗、包的體積、性能方面來說都是最佳的選擇，但是開發門檻高、迭代速度慢；
- 2）QT是基于C++的跨平臺開發框架，跨平臺應用十分廣泛(Mac、Windows、ios、Android、Linux、嵌入式)，眾所周知的WPS就是用QT開發的。性能很好，甚至于可以媲美原生的體驗，但是整體門檻還是比較高的；
- 3）Web技術的代表Electron 和 NW.js ，相比之前選擇Electron，Electron有非常活躍的社區（有102k star），有Atom、vscode這樣的大型應用都是基于Electron開發的，性能相比于natvie是肯定要差一些，但綜合來看，Electron是作為開發桌面應用的目前首選；
- 4）值得一提的是Flutter desktop，從渲染原理看flutter是skia自繪性能優于Electron，但問題還是穩定性和生態。Electron由于是nodejs+chromium，前端的生態可以直接用，所以Flutter desktop就不納入考慮范圍的，但值得關注。
除了以上這些，最主要的一點：Electron能快速交付，業務層復用web系統的代碼，只需要關注主進程就好了，并且也能滿足業務需要的系統級別的一些功能。
五、技術實現
5.1、項目架構
首先介紹下Electron框架里面兩個重要的概念主進程和渲染進程。
- 1）主進程：主要負責創建和管理BrowserWindow實例以及應用程序事件。它可以執行注冊全局快捷方式，創建系統菜單和對話框，響應自動更新事件等操作（主進程以及所有Node.js模塊中都提供了一部分Electron API）；
- 2）渲染進程：渲染過程負責運行應用程序的用戶界面，渲染進程中提供了所有DOM API、Node.js API和Electron API的子集。
如上面截圖：打開Electron項目之后會有多個進程，一個項目有且只有一個主進程，創建窗口等有關系統事件寫在主進程中進行，但是渲染進程可能有多個。
那為什么會有多個渲染進程呢？
Electron應用是Chromium內核，所以多進程的架構也來源于Chromium，Chromium會單獨運行每個標簽，任何一個標簽頁崩潰了都不會影響到其他標簽。因此，每個進程在自己的空間中運行，由操作系統調度。如果某個進程觸發了無限循環，也不會導致整個應用down掉。
在上文說到兩個字“遷移”：是的，我們在開發桌面應用之前有非常成熟的web端商家客服聊天系統了，所以我們在開發桌面應用的時候大多數時候是關心主進程的，渲染進程并不太需要關心。
5.2、主進程功能模塊
5.2.1通信模塊
主要是調用Electron框架本身的API以及通用方法的封裝：
5.2.1.1）主進程到渲染進程的通信：
5.2.1.2）渲染進程到主進程的通信：
有兩種方案。
方案一：是在主進程開啟了nodeIntegration: true之后在渲染進程里面可以使用window.require('Electron')來引入寫通信相關代碼：
方案二：是需要在主進程編寫preload.js（在初始化窗口的時候引入）：
5.2.1.3）通信的同步和異步問題：
異步：渲染進程->發送->主進程
同步：渲染進程->發送->主進程
5.2.2菜單模塊
主要是調用Electron框架本身的API，滿足快速擴展菜單功能以及自定義菜單功能：
但是商家客服項目沒用到原生菜單，而是用了自定義的菜單。
沒有使用原生菜單的主要原因是：
- 1）原生菜單樣式較死板，不能調整；
- 2）自定義編寫菜單能有各種自己想要的功能，可控制其展示。
5.2.3 托盤模塊
托盤屬于系統級的操作，所以是在主進程中設置的。在開始之前需要注意的地方，設置托盤必須在程序ready之后。
實現較簡單，代碼如下：
5.2.4 異常處理模塊
主要調用Electron框架本身API，結合Node.js API，檢測系統異常后自動刷新并上報，渲染進程的異常已經使用sls&arms處理，主進程的異常主要是通過Electron的crashReporter API來記錄日志。
上面提交參數有兩個需要注意的點：
- 1）submitURL 是以post方式上傳；
- 2）extra 一個你可以定義的對象，附帶在崩潰報告上一起發送（只有字符串屬性可以被正確發送，不支持嵌套對象）。
5.3、渲染進程功能模塊
渲染進程的代碼大部分跟商家客服IM web端一致，很多只是遷移即可。
5.3.1登錄改造
登錄信息本地化，在登錄成功的時候，把賬號信息緩存，下次打開應用的時候客服無需再重新輸入，直接從緩存獲取即可。
邏輯如下圖所示：
5.3.2靜態資源
傳統Web應用，將項目代碼部署服務器，項目運行時，訪問的是服務器靜態資源，現在版本發布流程，走的是cdn資源，總而言之都是通過網絡獲取。
Electron提供將靜態資源打包到安裝程序，在安裝時，將項目文件同步安裝到用戶電腦，使其具備訪問本地文件，減少了請求占用資源。一定程度上也能改善因網速問題導致的靜態資源不能實時獲取，頁面白屏問題。
5.3.3 數據存儲
Electron應用里面的數據存儲是通過Electron-store第三方庫來實現的。
實現比較簡單，如下：
5.3.4 渲染進程打包
這塊為什么要單拎出來講渲染進程打包呢，是因為web項目遷移變成應用渲染進程的時候不能像web應用一樣直接打包，需要調整請求API代碼，API前綴需要區分本地調試和應用環境。
代碼如下：
使用Electron, 將項目打包成離線應用。使用file協議，在本地讀取靜態資源。但是ajax請求如果用相對路徑，打包之后，會直接找到根目錄。如下截圖。
所以打包的時候需要給ajax提供完整的url路徑。
六、技術挑戰
6.1、概述
我們在從0到1搭建商家客服IM桌面端的過程中，遇到了很多的問題。
原因是Electron社區雖然很活躍，但是不一樣場景遇到的問題，幾乎找不到對應的解決方案，所以很多都是在探索過程中不斷的去完善。
這里主要圍繞發布構建流程和安全性來講下，我們是怎么解決的。
6.2、安全性問題
Electron客戶端的安全問題也是非常重要的，那都遇到了哪些安全問題以及我們又是如何解決的呢？
具體如下：
- 1）渲染進程XSS：Electron實現的桌面端軟件渲染層的原理實際是通過chrome內核渲染的，同樣存在XSS注入的風險（舉個例子：在html頁面中可以執行命令： ，就可以打開當前操作系統的計算器。接入了公司統一的XSS治理方案，該問題即得到解決）；
- 2）用戶認證信息泄漏問題：商家客服桌面端登錄調用商家的授權接口，APP網關有校驗，可以確保登陸沒有問題；
- 3）本地緩存明文讀取問題：本地數據泄漏（例如：indexDB、localStorage、sessionStorage等），我們主要用加密和解密算法對本地緩存信息進行處理。
沒有絕對的安全，我們能做的就是盡可能的提高安全門檻，過程中我們也積極同公司的安全部門進行溝通，讓他們排查桌面端發布之后的安全漏洞，最終驗證都是滿足安全標準，符合發布的條件。
6.3、發布構建流程
應用發布涉及到渲染進程和主進程，渲染進程主要是負責給主進程提供渲染包，主進程使用Electron-builder庫來打包部署所發布的包。
前面已經說過：Electron的好處是可以無縫集成web端的業務邏輯代碼，這里上圖左邊紅色的是web端構建出的產物，我們會把這部分構建產物同步到主進程的app/render目錄下（即渲染進程目錄），這樣在打包應用包的時候，就能集成渲染進程的業務邏輯，而不需要維護兩份web端的代碼。
此方案還存在不少的缺陷：由于生產構建環境需要window環境，所以暫時不支持在遠程打包，目前都是在本地window機器上打出完整的包之后再上傳到CDN，商家客服通過加載CDN的更新包來替換本地安裝文件，實現軟件的本地安裝。
6.4、應用更新問題
應用開發離不開“更新”這個話題，比如飛書應用會時不時彈出一個更新窗口，讓你選擇是否更新。我們的商家客服IM在推廣桌面應用之后，也存在更新這個問題。
在業務快速發展的同時，如何將業務需求更好的同步給商家使用，這是商家客服桌面應用面臨的最大的挑戰。
6.4.1全量更新：手動下載安裝
這是最基礎的更新模式，主要思路是在打開app（其他時候也行，我們業務主要是打開app的時候）的時候訪問遠程的json文件，文件內容包含版本號，更新內容等等最新版本的信息，拿到遠程版本號會跟本地應用版本號做比較，如果版本號不一致，就詢問用戶是否更新，需要更新的話會下載到本地，用戶手動點擊安裝即可。
這個更新方式不推薦使用，如果你的應用一年更新一次，ok，是可以這么做的。
6.4.2增量更新
在網速快的情況下，全量更新跟增量更新幾乎是沒有區別的。但是網速慢的情況下它倆之間的差距會被放大，用戶體驗不是很好。
我們不能想當然的以為所有用戶網速都很好，這是不現實的，所以不管是PC應用還是移動端應用，大多數情況下是需要做增量更新。
下面表格是網速不一樣情況下的下載耗時對比：
6.4.3增量更新方案1：electron-updater
現在就開始介紹我們在商家客服IM應用（windows應用）中是怎么實現增量更新功能的。
更新在大的分類上區分全量以及增量更新，在每個小分類里面也區分強更新、弱更新（業務上的區分，底層實現沒區別）。
簡單來說：
- 1）強更新指的是用戶必須更新，不更新將無法使用系統功能；
- 2）弱更新指的是用戶想要的時候再去觸發應用的更新，完全由用戶自主選擇。
更新流程：
其中electron-updater作用于“更新應用”這個節點，主要是依賴新舊版本blockmap文件的對比來實現增量更新。
下圖為electron-builder打包出來的release包，每次打包都會有對應的blockmap文件。
electron-updater更新實現主要流程分兩大步。
生產的blockmap文件：
- 1）使用7z壓縮安裝包；
- 2）讀取安裝包的header；
- 3）計算出每個file的offset和end得到相應的hash生產blockmap。
使用blockmap文件：
- 1）下載云上的blockmap文件跟本地blockmap文件對比（從上面截圖可以看出blockmap文件很小，所以下載并不會對應用性能產生影響）；
- 2）使用range，request(范圍請求)請求更新內容的部分。
6.4.4增量更新方案2：文件替換
還有一種增量更新方式就是文件替換，只更新需要更新的模塊。
這種方式只更新需要渲染進程的資源，大部分情況下主進程的資源不用更改，所以下載的資源會比較小，更新較快。因為是在線熱更新，更新完成后不用重新啟動軟件，只需要刷新頁面重新加載資源即可。
其實之前我覺的這樣的思路挺好的，看下面的流程圖也是可以實現的，也很符合商家客服桌面應用產品需求。
可是后來發現其實忽略了以下兩個點：
- 1）替換用戶本地文件這個本身有權限問題（比如windows用戶安裝到了C盤，寫入文件是有管理員權限限制的）；
- 2）文件被占用問題（眾所周知，當文件夾中存在正在被占用的文件時，刪除會失敗）。
所以在覆蓋原文件同時需要退出應用避免占用，所以這個方式也不是很可靠。
七、遇到的問題
我們在基于Electron開發客服IM桌面端的過程無疑遇到了很多問題，我揀主要的幾個問題分享一下。
問題一：Electron 的硬件加速功能，在 win7 或者 Linux 系統上，容易出現黑屏或者卡死：
解決方案：判斷是不是win7及以下系統，如果是app.disableHardwareAcceleration()，禁用當前應用程序的硬件加速。
問題二：“Uncaught ReferenceError: require is not defined”：
這個報錯是試圖在渲染進程使用node的時候出現的，不是不能用，只要開啟 主進程的nodeIntegration: true就好了， 但不建議（有安全問題）。
解決方案：
問題三：“Note：you may have one or two (large) stale temporary file(s) left in your temporary directory (Generally this only happens on Windows 9x)”：
這個是打包了半天都打不出來一個完整的包的情況下出現的。
解決方案：當時是因為我沒刪除原來的包導致我放打包文件的C盤滿了。所以刪除一些緩存就好了，nsis打包大概率都是跟磁盤有關。
問題四：下載npm包特別慢：
解決方案：yarn安裝、Electron相關的包優先使用淘寶鏡像安裝、使用公司鏡像安裝公司內部包。
八、本文小結
一路開發下來，感慨很多。
作為公司第一個Electron應用，不管是在開發上，打包上，或者說在部署上，都遇到了一些挑戰。
在網上也沒有比較詳細的文檔，外面做的好的也不會把詳細方案分享出來。但是即使遇到了這些問題，也不能否認Electron是目前最適配于我們業務目標以及適配于開發資源的一個框架。
目前我們已有線上穩定版本，也逐步在推廣到全部商家客服。
接下來需要完善的開發流程，克服的技術難點有很多，商家客服工作臺應用也會越來越完善。
九、參考資料
[1] Electron官方開發者手冊
[2] 快速了解新一代跨平臺桌面技術——Electron
[3] Electron初體驗(快速開始、跨進程通信、打包、踩坑等)
[4] Electron 基礎入門 簡單明了，看完啥都懂了
[5] vivo的Electron技術棧選型、全方位實踐總結
[6] 融云基于Electron的IM跨平臺SDK改造實踐總結
[7] 閑魚IM基于Flutter的移動端跨端改造實踐
[8] 網易云信基于Electron的IM消息全文檢索技術實踐
（本文已同步發布于：http://www.52im.net/thread-4159-1-1.html）