信不只是我，用過（或看過）macOS 和 Windows 兩個版本 Notion 客戶端的同學，應該都會覺得 Windows 上的 Notion 用戶「處于水深火熱」之中。

Notion 的桌面客戶端是「網頁套殼」的成果，受限于 Windows 上的 Electron API，Notion 官方的 Windows 客戶端擁有 Windows 桌面應用的一切特征：

• 對 Notion 來說沒有什么用處的「工具欄」
• 粗大的 Windows 老式「滾動條」
• 與 Notion 整體顏色不符的「標題欄」
• ……

不過 Notion 客戶端是用 Electron 封裝的，其樣式、布局等和網頁的定義方法一致。因此我們可以通過一些手段對 Notion 的 Windows 客戶端進行定制，使之更符合我們的審美與使用習慣。比如下面這樣：

這里用到的是來自烏克蘭的開發者 @Uzver 的 Notion Enhancer，借助這款工具，我們可以對 Notion 的 Windows 桌面客戶端進行一系列魔改和美化。

準備工作

在開始美化 Notion 客戶端之前我們需要安裝一些工具，為接下來的魔改進行準備工作。下面的步驟在 Windows 10 Pro 19041.25 版本下進行，使用 Windows 上的軟件包管理工具 Scoop 進行安裝。

關聯閱讀：「一行代碼」搞定軟件安裝卸載，用 Scoop 管理你的 Windows 軟件

首先，Notion Enhancer 本身是一個 Python 腳本，我們需要安裝 Python 環境。打開 PowerShell，在其中輸入：

scoop install python

等待安裝完成即可。

接下來，由于 Notion 的桌面客戶端是 Electron 套殼應用，用 Node.js 作為其運行環境，因此我們需要安裝 Node.js 與 npm 包管理工具。在 PowerShell 中繼續輸入：

scoop install nodejs

等待安裝完成即可。

最后，我們需要使用 npm 包管理工具安裝 asar 工具，用來解密 Electron 應用包，從而改造 Electron 應用（也就是 Notion 客戶端）的內部代碼。在 PowerShell 中繼續輸入：

npm install -g asar

在 PowerShell 中輸入 asar，如果出現如下的結果，那么我們的 asar 工具就安裝成功了。

驗證 asar 工具安裝成功

至此，準備工作就基本完成了。

安裝「美化」套裝

接下來，我們下載「美化」套裝：Notion Scripts V4。解壓之后我們會得到這樣的幾個文件：

• Customization Patcher.py：Python 腳本，用于將樣式施加于 Notion 客戶端
• Customization Remover.py：Python 腳本，用于移除已經添加的樣式
• resources 資源文件夾：
• main.user.js：用戶 JavaScript 腳本，用于加載用戶 CSS 樣式，并修改 Notion 客戶端外殼的樣式（比如標題欄、窗口控件等）
• custom_style.css：用戶 CSS 樣式表，用于自定義 Notion 客戶端內部實際功能區的樣式
• ……

我們將 NotionScriptsV4 文件夾放置妥當（可以放在云存儲同步文件夾中，方便后續保管），在 PowerShell 中定位至這一文件夾，進行接下來的「安裝」操作。

關掉所有 Notion 客戶端，在 PowerShell 中輸入下面的命令，執行 Python 腳本：

python 'Customization Patcher.py'

在這一步驟中，Customization Patcher.py 實際上為我們做了以下的事情：

• 找到 Notion 客戶端的安裝地點，并將其 Electron 核心軟件包 app.asar 用我們剛剛安裝的 asar 工具解壓（解密）并放置在 ./Notion/resources/app 位置。同時將原先的 app.asar 進行備份（重命名為 app.asar.bak）
• 在解壓之后的 Electron 軟件包里面，加載我們的自定義用戶 CSS 文件 custom_style.css 與自定義用戶 JavaScript 文件 main.user.js
• 修改 Notion 桌面客戶端的窗口屬性為「無邊框窗口」，并調整相應的「可拖拽區域」
• 修改 Notion 桌面客戶端的入口，添加「顯示與隱藏 Notion 窗口」的注冊快捷鍵
• 為 Notion 客戶端添加任務欄圖標（方便設置開機啟動與窗口恢復樣式）

隨后重啟 Notion 客戶端就可以看到樣式已經生效，客戶端被我們成功魔改。

另外，如果后續希望將 Notion 客戶端恢復原樣，我們同樣直接運行移除樣式腳本 Customization Remover.py 即可：

python 'Customization Remover.py'

功能與配置

事實上，Notion Enhancer 為我們添加、修改并自定義了很多 Notion 客戶端的功能與樣式。

Windows 默認控件的修改

首先 Notion Enhancer 最大、最值得使用的功能特性就是將 Notion 原有的 Windows 菜單欄、工具欄與滾動條全部去掉，修改成了更符合 Notion 整體風格的樣式。下面是一個對比：

可以看到，Notion Enhancer 將 Windows 原生的與 Notion 界面風格不匹配的控件全部隱藏了起來，并重繪了右上角的「最小化」、「最大化」和「關閉窗口」的控件，并將「滾動條」也重新繪制，使之與無論在深色主題還是淺色主題下都能完美契合。

另外，Notion Enhancer 還在右上角添加了一個實用的新控件 ↑，用于置頂 Notion 窗口。

表格視圖去掉兩側空白

Notion Enhancer 將 Notion 表格、看板視圖左右兩側的「空白區域」去掉，從而讓二者能顯示更多的橫向內容。

去掉表格視圖兩側的空白部分

這部分樣式在文件 custom_style.css 的 87 行往下開始定義的，如果不希望開啟這一功能，我們直接刪掉或注釋掉 87 行至 97 行與 103 行至 107 行的代碼內容（即下圖中藍色框中代碼內容）即可。另外也可以在 Notion 客戶端里面用快捷鍵 Ctrl + R 重新加載樣式。

表格與看板視圖的 CSS 樣式定義

調整圖標與頭圖的位置

Notion Enhancer 將帶有頭圖的頁面也進行了相應的調整。為了使縱向空間充分利用，Notion Enhancer 將圖標向上移動至頭圖中央，并調整了頭圖的顯示區域。

需要注意這部分樣式定義是作者針對 15.6 寸與 24 寸顯示器進行的參數調整，如果發現自己的 Notion 客戶端顯示出現了問題，那么我們需要手動調整這部分參數，也就是 custom_style.css 的第 109 行下面的部分。

這里我們需要調整兩個 height 參數，其中 12vh、20vh 分別代表 Notion 頁面內容距離頂端的高度與頭圖的顯示高度，我們適當進行調整，使得圖標在頭圖里面垂直居中即可。

添加自定義的 Notion 樣式

在上面的兩個例子中可以看到，無論是桌面客戶端的 Notion 還是網頁版本的 Notion，其樣式實際上是完全可以很大程度上進行自定義的。我們直接在 custom_style.css 里面添加或修改相應的 CSS 樣式定義內容即可讓 Notion 界面按照我們希望的樣子顯示。

快捷鍵顯示隱藏 Notion 窗口

Notion Enhancer 還為我們添加了隱藏/顯示 Notion 窗口的快捷鍵定義。

默認的隱藏 / 顯示 Notion 快捷鍵是 Ctrl + Shift + A，不過我們也可以自定義這一功能。在 Customization Patcher.py 中，第 34 行定義了快捷鍵 windowToggleHotkey 的變量，這里我們就可以將默認定義的：

windowToggleHotkey="'ctrl+shift+a'"

修改為我們自己的快捷鍵，比如 Win + Shift + N：

windowToggleHotkey="'super+shift+n'"

這里的修改需要重新運行 Customization Patcher.py，再次給 Notion 客戶端打補丁，才能讓快捷鍵生效。

添加任務欄設置圖標

最后，為了方便設置 Notion 開機自啟以及啟動的窗口樣式，Notion Enhancer 還添加了一個任務欄設置區域，方便我們設置 Notion 開啟啟動、自動隱藏窗口、自動最大化窗口與最小化到托盤等選項。

小結

為了拯救 Notion 的 Windows 用戶于水深火熱之中，Notion Enhancer 的作者也是煞費苦心，為我們修改了 Notion 的界面并提供了諸多增強功能，包括能夠任意自定義 Notion 頁面樣式的入口：custom_style.css。

Notion Enhancer 目前已經更新至第四個版本，作者將在 Notion Enhancer - Notion 這一頁面持續更新工具及其相應的功能和配置方法，感興趣的同學可以持續關注。本文的介紹就到這里，感謝閱讀。

文由vivo技術團隊Yang Kun分享，原題“electron 應用開發優秀實踐”，本文有修訂。

1、引言

在上篇《Electron初體驗(快速開始、跨進程通信、打包、踩坑等)》的分享中，我們已經對Electron跨端框架的開發有了大概的了解。

本篇將基于vivo技術團隊的技術實踐，詳細闡述了vivo在使用Electron進行跨端桌面開發時的技術棧選型考量，同時分享了在打包構建、版本更新、性能優化、質量保障、安全性等方面的實踐方案和踩坑總結。

2、系列文章

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

• 《IM跨平臺技術學習(一)：快速了解新一代跨平臺桌面技術——Electron》
• 《IM跨平臺技術學習(二)：Electron初體驗(快速開始、跨進程通信、打包、踩坑等)》
• 《IM跨平臺技術學習(三)：vivo的Electron技術棧選型、全方位實踐總結》（* 本文）
• 《IM跨平臺技術學習(四)：蘑菇街基于Electron開發IM客戶端的技術實踐》（稍后發布.. ）
• 《IM跨平臺技術學習(五)：融云基于Electron的IM跨平臺SDK改造實踐總結》（稍后發布.. ）
• 《IM跨平臺技術學習(六)：網易云信基于Electron的IM消息全文檢索技術實踐》（稍后發布.. ）

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：

• 1）軟件生成： icofx3；
• 2）網頁生成： https://tool.520101.com/diannao/ico/。

MacOS：

• 1）軟件生成： icofx3；
• 2）網頁生成： https://tool.520101.com/diannao/ico/；
• 3）命令行生成： 使用 sips 和 iconutil 生成。

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）開發和生產環境，獲取二進制程序路徑方法是不一樣的 可以采用如下代碼進行動態獲?。?/span>

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個方面分享：

• 1）自動化測試；
• 2）崩潰監控；
• 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的聊天消息全文檢索技術實踐

學習交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4044-1-1.html）

、引言

本系列文章的前面幾篇主要是從Electron技術本身進行了討論（包括：第1篇初步了解Electron、第2篇進行了快速開始和技術體驗、第3篇基于實際開發考慮的技術棧選型等），各位讀者也應該對Electron的開發有了較為深入的了解。

本篇將回到IM即時通訊技術本身，根據蘑菇街的實際技術實踐，總結和分享基于Electron開發跨平臺IM客戶端的過程中，需要考慮的典型技術問題以及我們的解決方案。希望能給你帶來幫助。

學習交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4051-1-1.html