本文由vivo技術團隊Yang Kun分享，原題“electron 應用開發優秀實踐”，即時通訊網有修訂。
1、引言
在上篇《Electron初體驗(快速開始、跨進程通信、打包、踩坑等)》的分享中，我們已經對Electron跨端框架的開發有了大概的了解。
本篇將基于vivo技術團隊的技術實踐，詳細闡述了vivo在使用Electron進行跨端桌面開發時的技術棧選型考量，同時分享了在打包構建、版本更新、性能優化、質量保障、安全性等方面的實踐方案和踩坑總結。
學習交流：
（本文已同步發布于：http://www.52im.net/thread-4044-1-1.html）
2、系列文章
本文是系列文章中的第3篇，本系列總目錄如下：
3、技術背景
因業務發展，我們需要用到桌面端技術，技術特性涉及離線可用、調用桌面系統能力等要求。
那么什么是桌面端開發？一句話概括就是：以 Windows 、MacOS 和 Linux 為操作系統的桌面軟件開發。
對此我們做了詳細的技術調研：桌面端的開發方式主要有 Native 、 QT 、 Flutter 、 NW 、 Electron 、 Tarui 。
這些技術各自優劣勢如下表格所示：
我們最終的桌面端技術選型是 Electron，Electron 是一個可以使用 Web 技術來開發跨平臺桌面應用的開發框架。
其技術組成如下：
Electron = Chromium + Node.js + Native API
各技術能力如下圖所示：
整體架構如下圖所示：
Electron 是多進程架構，架構具有以下特點：
- 1）由一個主進程和 N 個渲染進程組成；
- 2）主進程承擔主導作用，用于完成各種跨平臺和原生交互；
- 3）渲染進程可以是多個，使用 Web 技術開發，通過瀏覽器內核渲染頁面；
- 4）主進程和渲染進程通過進程間通信來完成各種功能。
這里回顧一下 Electron 進程間通信技術原理。
electron 使用 IPC （interprocess communication） 在進程之間進行通信。
如下圖所示：
其提供了 IPC 通信模塊，主進程的 ipcMain 和渲染進程的 ipcRenderer。
從 electron 源碼中可以看出， ipcMain 和 ipcRenderer 都是 EventEmitter 對象。
源碼如下圖所示：
看到源碼實現，是不是覺得 IPC 不難理解了。知其本質，方可游刃有余。
限于篇幅，這里對Electron的基礎知識就不再展開，有興趣的讀者可回顧一下本系列的前兩篇《快速了解新一代跨平臺桌面技術——Electron》、《Electron初體驗(快速開始、跨進程通信、打包、踩坑等)》（這篇中的“5、進程詳解”特別介紹了Electron進程間的關系以及通信原理）。
4、開發技術棧選型
4.1編程語言選型
我們最終選擇的是Typescript，理由如下。
針對開發者：
- 1）Javascript 的超集（無縫支持所有的 es2020+ 所有的特性，學習成本小）；
- 2）編譯生成的 JavaScript 的代碼保持很好的可讀性；
- 3）可維護性明顯增強；
- 4）完整的 OOP 的支持（extends, interface， private， protect， public等）；
- 5）類型即文檔；
- 6）類型的約束，更少的單元測試的覆蓋；
- 7）更安全的代碼。
針對工具：
- 1）更好的重構能力；
- 2）靜態分析自動導包；
- 3）代碼錯誤檢查；
- 4）代碼跳轉；
- 5）代碼提示補齊。
社區支持：大量的社區的類型定義文件 提升開發效率。
4.2構建工具選型
我們選擇的是 Electron-Forge。
理由很充分：Electron-Forge簡單而又強大，目前 electron 應用最好的構建工具之一。
這里提一下 electron-builder 其和 electron-forge 的介紹和區別。
看下圖所示：
兩者最大的區別在于自由度，兩者在能力上基本沒什么差異了，從官方組織中的排序看，有意優先推薦 electron-forge 。
4.3Web方案選型
我們采用的是 Vue3 ，同時使用 Vite 作為構建工具，具體優點，大家可以查看官網介紹，這套組合是目前主流的 Web 開發方案。
4.4monorepo方案選型
目前的 monorepo 生態百花齊放，正確的實踐方法應該是集大成法，也就是取各家之長，目前的趨勢也是如此，各開源 monorepo 工具達成默契，專注自己擅長的能力。
如 pnpm 擅長依賴管理， turbo 擅長構建任務編排。遂在 monorepo 技術選型上，我選擇了 pnpm 和 turbo 。
以下是pnpm的官網：
pnpm 理由如下：
- 1）目前最好的包管理工具（pnpm 吸收了npm、yarn、lerna等主流工具的精華，并去其糟粕）；
- 2）生態、社區活躍且強大；
- 3）結合 workspace 可以完成 monorepo 最佳設計和實踐；
- 4）在管理多項目的包依賴、代碼風格、代碼質量、組件庫復用等場景下，表現出色；
- 5）在框架、庫的開發、調試、維護方面，表現出色。
相比于 vue 官網，在使用 pnpm 上，我加了 workspace 。
turbo 理由如下：
- 1）它是一個高性能構建系統（擁有增量構建、云緩存、并行執行、運行時零開銷、任務管道、精簡子集等特性）；
- 2）具有非常優秀的任務編排能力（可以彌補 pnpm 在任務編排上的短板）。
4.5本地數據庫選型
Electron 應用數據庫有非常多的選擇如 lowdb 、 sqlite3 、 electron-store 、 pouchdb 、 dedb 、 rxdb 、 dexie 、 ImmortalDB 等。
這些數據庫都有一個特性，那就是無服務器。
Electron本地數據庫技術選型考慮因素主要有：
- 1）生態（使用者數量、維護頻率、版本穩定度）；
- 2）能力；
- 3）性能；
- 4）其他（和使用者技術匹配度）。
我們通過以下渠道進行了相關調研：
- 1）github 的 issues、commit、fork、star；
- 2）sourcegraph 關鍵字搜索結果數；
- 3）npm 包下載量、版本發布；
- 4）官網和博客。
給出四個最優選擇，分別是 lowdb 、 sqlite3 、 nedb 、 electron-store 。
我們的理由如下：
- 1）lowdb：生態、能力、性能三方面表現優秀， json 形式的存儲結構， 支持 lodash 、 ramda 等 api 操作，利于備份和調用；
- 2）sqlite3：生態、能力、性能三方面表現優秀， Nodejs 關系型數據庫第一選擇方案；
- 3）nedb：能力、性能三方面表現優秀，缺點是基本不維護了，但底子還在，尤其操作是 MongoDB 的子集，對于熟悉 MongoDB 的使用者來說是絕佳選擇；
- 4）electron-store：生態表現優秀，輕量級持久化方案，簡單易用。
我們使用的數據庫最終選型是 lowdb 方案。
PS：提一下 pouchdb ，如果需要將本地數據同步到遠端數據庫，可以使用 pouchdb ，其和 couchdb 可以輕松完成同步。
4.6腳本工具選型
軟件開發過程中，將一些流程和操作通過腳本來完成，可以有效地提高開發效率和幸福度。
依賴 node runtime 的優秀選擇就兩個：shelljs 和 zx 。
選擇 zx 的理由如下：
- 1）自帶 fetch 、 chalk 等常用庫，使用方便快捷；
- 2）多個子進程方便快捷（執行遠端腳本、解析 md 、 xml 文件腳本、支持 ts），功能豐富且強大；
- 3）谷歌出品、大廠背景，生態非常活躍。
至此，技術選型就介紹完了。
5、打包構建實踐
5.1應用圖標生成
不同尺寸圖標的生成有以下方法。
Windows：
MacOS：
5.2二進制文件構建
本章節內容是基于 electron-forge 闡述的，不過原理是一樣的。
在開發桌面端應用時，會有場景要用到第三方的二進制程序，比如 ffmpeg 這種。
在構建二進制程序時，要關注以下兩個注意項。
1）二進制程序不能打包進 asar 中 可以在構建配置文件（forge.config.js）進行如下設置：
const os = require('os')
const platform = os.platform()
const config = {
packagerConfig: {
// 可以將 ffmpeg 目錄打包到 asar 目錄外面
extraResource: [`./src/main/ffmpeg/`]
}
}
2）開發和生產環境，獲取二進制程序路徑方法是不一樣的 可以采用如下代碼進行動態獲取：
import { app } from 'electron'
import os from 'os'
import path from 'path'
const platform = os.platform()
const dir = app.getAppPath()
let basePath = ''
if(app.isPackaged) basePath = path.join(process.resourcesPath)
elsebasePath = path.join(dir, 'ffmpeg')
const isWin = platform === 'win32'
// ffmpeg 二進制程序路徑
const ffmpegPath = path.join(basePath, `${platform}`, `ffmpeg${isWin ? '.exe':
5.3按需構建
如何對跨平臺二進制文件進行按需構建呢？
比如桌面應用中用到了 ffmpeg ， 它需要有 windows 、 mac 和 linux 的下載二進制。
在打包的時候，如果不做按需構建，則會將 3 個二進制文件全部打到構建中，這樣會讓應用體積增加很多。
可以在 forge.config.js 配置文件中進行如下配置，即可完成按需構建。
代碼如下：
const platform = os.platform()
const config = {
packagerConfig: {
extraResource: [`./src/main/ffmpeg/${platform}`]
},
}
通過 platform 變量來把對應系統的二進制打到構建中，即可完成對二進制文件的按需構建。
5.4性能優化
主要是構建速度和構建體積優化，構建速度這塊不好優化。這里重點說下構建體積優化，拿 mac 系統舉例說明， 在 electron 應用打包后，查看應用包內容。
如下圖所示：
可以看到有一個 app.asar 文件。
這個文件用 asar 解壓后可以看到有以下內容：
可以看出 asar 中的文件，就是我們構建后的項目代碼，從圖中可以看到有 node_modules 目錄， 這是因為在 electron 構建機制中，會自動把 dependencies 的依賴全部打到 asar 中。
結合上述分析，我們的優化措施有以下4點：
- 1）將 web 端構建所需的依賴全部放到 devDependencies 中，只將在 electron 端需要的依賴放到 dependencies；
- 2）將和生產無關的代碼和文件從構建中剔除；
- 3）對跨平臺使用的二進制文件，如 ffmpeg 進行按需構建（上文按需構建已介紹）；
- 4）對 node_modules 進行清理精簡。
這里提下第 4） 點，如何對 node_modules 進行清理精簡呢？
如果是 yarn 安裝的依賴：我們可以在根目錄使用下面命令進行精簡：
yarn autoclean -I
yarn autoclean -F
如果是 pnpm 安裝的依賴：第 4）點應該不起作用了。我在項目中使用 yarn 安裝依賴，然后執行上述命令后，發現打包體積減少了 6M ， 雖然不多，但也還可以。
6、版本更新實踐
6.1全量更新
全量更新就是通過下載最新的包或者 zip 文件，進行軟件更新，需要替換所有的文件。
整體設計流程圖如下：
按照流程圖去實現，我們需要做以下事情：
- 1）開發服務端接口，用來返回應用最新版本信息；
- 2）渲染進程使用 axios 等工具請求接口，獲取最新版本信息；
- 3）封裝更新邏輯，用來對接口返回的版本信息進行綜合比較，判斷是否更新；
- 4）通過 ipc 通信將更新信息傳遞給主進程；
- 5）主進程通過 electron-updater 進行全量更新；
- 6）將更新信息通過 ipc 推送給渲染進程；
- 7）渲染進程向用戶展示更新信息，若更新成功，則彈出彈窗告訴用戶重啟應用，完成軟件更新。
6.2增量更新
增量更新是通過拉取最新的渲染層打包文件，覆蓋之前的渲染層代碼，完成軟件更新，此方案只需替換渲染層代碼，無需替換所有文件。
按照流程圖去實現，我們需要做以下事情：
- 1）渲染進程定時通知主進程檢測更新；
- 2）主進程檢測更新；
- 3）需要更新，則拉取線上最新包；
- 4）刪除舊版本包，復制線上最新包，完成增量更新；
- 5）通知渲染進程，提示用戶重啟應用完成更新。
全量更新和增量更新各有優勢，多數情況下，采用增量更新來提高用戶更新體驗，同時使用全量更新作為兜底更新方案。
7、性能優化實踐
打包構建優化在上節內容中已經詳細介紹過了，這里不再介紹，下面將介紹我們對“啟動時優化”和“運行時優化”的實踐。
7.1啟動時優化
主要從以下幾個方面著手：
- 1）使用 v8-compile-cache 緩存編譯代碼；
- 2）優先加載核心功能，非核心功能動態加載；
- 3）使用多進程，多線程技術；
- 4）采用 asar 打包：會加快啟動速度；
- 5）增加視覺過渡：loading + 骨架屏。
7.1.1）使用 v8-compile-cache 緩存編譯代碼：
使用 V8 緩存數據，為什么要這么做呢？
因為 electorn 使用 V8 引擎運行 js ， V8 運行 js 時，需要先進行解析和編譯，再執行代碼。其中，解析和編譯過程消耗時間多，經常導致性能瓶頸。而 V8 緩存功能，可以將編譯后的字節碼緩存起來，省去下一次解析、編譯的時間。
主要使用 v8-compile-cache 來緩存編譯的代碼，做法很簡單：在需要緩存的地方加一行。
1require('v8-compile-cache')
其他使用方法請查看此鏈接文檔 ：https://www.npmjs.com/package/v8-compile-cache
7.1.2）優先加載核心功能，非核心功能動態加載：
偽代碼如下：
export functionshare() {
const kun = require('kun')
kun()
}
7.2運行時優化
主要從以下幾個方面著手：
1）對渲染進程 進行 Web 性能優化；
2）對主進程進行輕量瘦身。
7.2.1）對渲染進程 進行 Web 性能優化：
用一個思維導圖來完整闡述如何進行 Web 性能優化，如下圖所示：
上圖基本包含了性能優化的核心關鍵點和內容，大家可以以此作為參考，去做性能優化。
7.2.2）對主進程進行輕量瘦身：
核心方案就是將運行時耗時、計算量大的功能交給新開的 node 進程去執行處理。
偽代碼如下：
const { fork } = require('child_process')
let { app } = require('electron')
functioncreateProcess(socketName) {
process = fork(`xxxx/server.js`, [
'--subprocess',
app.getVersion(),
socketName
])
}
const initApp = async () => {
// 其他初始化代碼...
let socket = await findSocket()
createProcess(socket)
}
app.on('ready', initApp)
通過以上代碼，將耗時、計算量大的功能，放在 server.js ，然后再 fork 到新開 node 進程中進行處理。
至此，性能優化實踐就介紹完了。
8、質量保障實踐
8.1概述
質量保障的全流程措施如下圖所示：
本節主要從以下3個方面分享：
下面將會依次介紹上述內容。
8.2自動化測試
自動化測試是什么？
上圖是做自動化測試一個完整步驟，大家可以看圖領會。
自動化測試主要分為 單元測試、集成測試、端到端測試。
三者關系如下圖所示：
一般情況下：作為軟件工程師，我們做到一定的單元測試就可以了。而且從我目前經驗來說，如果是寫業務性質的項目，基本上不會編寫測試相關的代碼。
自動化測試主要是用來編寫庫、框架、組件等需要作為單獨個體提供給他人使用的。
electron 的測試工具推薦 vitest 、 spectron 。具體用法參考官網文檔即可，沒什么特別的技巧。
8.3崩潰監控
對于 GUI 軟件，尤其桌面端軟件來說，崩潰率非常重要，因此需要對崩潰進行監控。
崩潰監控原理如下圖所示：
崩潰監控技巧：
- 1）渲染進程崩潰后，提示用戶重新加載；
- 2）通過 preload 統一初始化崩潰監控；
- 3）主進程、渲染進程通過 process.crash() 進行模擬崩潰；
- 4）對崩潰日志進行收集分析。
崩潰監控做好后，如果發生崩潰，該如何治理崩潰呢？
8.4崩潰治理
崩潰治理難點：
- 1）定位出錯棧困難：Native 錯誤棧，無操作上下文；
- 2）調試門檻高：C++ 、 IIdb/GDB；
- 3）運行環境復雜：機器型號、系統、其他軟件。
崩潰治理技巧：
- 1）及時升級 electron；
- 2）用戶操作日志和系統信息；
- 3）復現和定位問題比治理重要；
- 4）把問題交給社區解決，社區響應快；
- 5）善于用 devtool 分析和治理內存問題。
9、安全性實踐
9.1概述
俗話說的好，安全大于天，保證 electron 應用的安全也是一項重要的事情。
本章節將安全分為以下 5 個方面：
- 1）源碼泄漏；
- 2）asar；
- 3）源碼保護；
- 4）應用安全；
- 5）編碼安全。
下面將會依次介紹上述內容。
9.2源碼泄漏
目前 electron 在源碼安全做的不好，官方只用 asar 做了一下很沒用的源碼保護，到底有多沒用呢？
你只需要下載 asar 工具，然后對 asar 文件進行解壓就可以得到里面的源碼了。
如下圖所示：
通過圖中操作即可看到語雀應用的源碼。上面提到的 asar 是什么呢？
9.3asar介紹
asar 是一種將多個文件合并成一個文件的類 tar 風格的歸檔格式。Electron 可以無需解壓整個文件，即可從其中讀取任意文件內容。
可以直接看 electron 源碼，都是 ts 代碼，容易閱讀，源碼如下圖所示：
9.4源碼保護
避免源碼泄漏，按照從低到高的源碼安全，可以分為幾個程度。
具體如下：
- 1）asar；
- 2）代碼混淆；
- 3）WebAssembly；
- 4）Language bindings。
其中：Language bindings 是最高的源碼安全措施，其實使用 C++ 或 Rust 代碼來編寫 electron 應用代碼，通過將 C++ 或 Rust 代碼編譯成二進制代碼后，破譯的難度會變高。
這里我說下如何使用 Rust 去編寫 electron 應用代碼。
方案是：使用 napi-rs 作為工具去編寫，如下圖所示：
我們采用 pnpm-workspace 去管理 Rust 代碼，使用 napi-rs 。
比如我們寫一個 sum 函數，rs代碼如下：
fn sum(a: f64, b: f64) -> f64 {
a + b
}
此時我們加上 napi 裝飾代碼，如下所示：
use napi_derive::napi;
#[napi]
fn sum(a: f64, b: f64) -> f64 {
a + b
}
在通過 napi-cli 將上述代碼編譯成 node 可以調用的二進制代碼。
編譯后，在electron使用上述代碼，如下所示：
import { sum as rsSum } from '@rebebuca/native'
// 輸出 7
console.log(rsSum(2, 5))
napi-rs 的使用請閱讀官方文檔，地址是：https://napi.rs/
至此，language bindings 的闡述就完成了。我們通過這種方式，可以完成對重要功能的源碼保護。
9.5應用安全
目前熟知的一個安全問題是克隆攻擊，此問題的主流解決方案是將用戶認證信息和應用設備指紋進行綁定。
整體流程如如下圖所示：
如上圖所示：
- 1）應用設備指紋生成：可以用上文闡述的 napi-rs 方案去實現；
- 2）用戶認證信息和設備指紋綁定：使用服務端去實現。
9.6編碼安全
主要有以下措施：
- 1）常用的 web 安全，比如防 xss 、 csrf；
- 2）設置 node 可執行環境；
- 3）窗體開啟安全選項；
- 4）限制鏈接跳轉。
以上具體細節不再介紹，自行搜索上述方案。
除此之外，還有個官方推薦的最佳安全實踐，有空可以看看，地址如下：https://www.electronjs.org/docs/latest/tutorial/security。
至此，安全性這塊實踐就介紹完了。
10、本文小結
本文介紹了我們對跨系統桌面端技術的調研、確定技術選型，以及用 electron 開發過程中，總結的實踐經驗及踩坑填坑過程，如構建、性能優化、質量保障、安全等。
希望對讀者在開發跨端桌面應用過程中有所幫助，文章難免有不足和錯誤的地方，歡迎讀者評論。
11、參考資料
[1] Electron官方開發者手冊
[2] 快速了解新一代跨平臺桌面技術——Electron》
[3] Electron初體驗(快速開始、跨進程通信、打包、踩坑等)
[4] Electron 基礎入門 簡單明了，看完啥都懂了
[5] 網易云信Web端IM的聊天消息全文檢索技術實踐
（本文已同步發布于：http://www.52im.net/thread-4044-1-1.html）