桌面應用開發

在處于移動互聯網的當下，雖然桌面應用的重要性已經不能同往日而語，但在我們平常的日常工作和生活中，還是扮演著非常重要的角色和地位。在我們的日常工作中，離不開Lark、VSCode等桌面應用。

相比較于移動端而言，桌面端應用的生態多種多樣，因此也誕生了各種各樣的桌面應用開發技術棧。本次分享將會對相關常用的一些桌面應用開發框架進行介紹和分析，同時對當下比較流行（GitHub 50k star）的跨平臺桌面應用開發框架Tauri進行介紹。

原生技術棧

原生技術棧是指通過操作系統相關API或者操作系統廠家（如Apple/Microsoft）提供的SDK/工具來開發桌面應用的方式。使用原生技術開發的應用，通常能夠在性能、體積以及系統的交互等方面做到非常不錯的效果。

• 優點

構建產物體積小

性能好

系統API調用方便

兼容性好

和系統應用的交互融合度高，如要實現如下的一些系統原生UI組件非常方便

• 缺點

無法做到跨平臺，所開發的應用只能在對應的平臺上運行，如果需要跨平臺運行，則需要在不同的操作系統上分別開發，開發成本高

對于使用的技術棧有限制（Windows使用C#，macOS使用ObjC/Swift）

Windows平臺

作為目前使用率最高的操作系統，Windows平臺的GUI程序開發經歷了漫長的迭代和演化的過程：Win32 API作為Windows GUI開發的鼻祖，通過C語言調用Windows底層的繪圖函數來進行開發；在Win32 API之后出現了MFC（Microsoft Fundation Class），MFC通過C++語法將原有的Win32 API封裝成了控件類（對話框控件、按鈕控件等）；在MFC之后，微軟推出了Windows Form（2002年），Windows Form依賴于.NET的運行時，提供了組件化的開發能力；在此之后，微軟推出了WPF（Windows Presentation Fundation，2006年），WPF提供了基于XML的語言XAML來描述UI；在Windows8的時代，微軟又推出了UWP（Universal Windows Platform，2015年），UWP支持在各種平臺上運行（PC/Windows Phone/Xbox），API也支持多種語言（C++/VB/C#/JS）。

從Windows平臺應用的開發技術迭代來看，也可以大致看出GUI程序的技術發展史：

• Win32API時代：函數調用，指令式，Windows系統處理
• MFC時代：面向對象，把一些指令式調用封裝成類，由來自UI的消息驅動程序處理數據
• Windows Form時代：組件化，在類的基礎上封裝成組件，消息被封裝成事件，事件驅動
• WPF時代：使用類XML語言來描述UI，引入數據驅動UI的理念
• UWP時代：跨平臺、多語言

macOS平臺

現有的macOS原生應用主要基于Cocoa框架開發，Cocoa是從1980年代由NeXT（macOS的前身）開發的編程環境NeXTSTEP和OPENSTEP演變而來，是面向對象的API。

在2020年的WWDC上，蘋果推出了新一代的UI框架SwiftUI，和Flutter/React等現代GUI框架類似，支持聲明式的方式使用Swift語言作為DSL來編寫UI，同時也支持跨平臺的特性，可以在macOS/iOS/tvOS等多平臺運行。

Linux平臺

Linux其源碼只包含了操作系統內核的部分，桌面并不屬于Linux源碼的一部分，因此嚴格意義上來說，從「使用系統API和操作系統廠商提供的SDK開發的應用為原生應用」的定義上來說，并無所謂「原生技術棧」的概念。我們日常使用的發行版提供了桌面環境如KDE、Gnome等，Linux發行版的這些桌面環境也提供了相關的一些庫或者API來幫助繪制GUI程序，如gtk+等，可以認為是「原生技術棧」。

跨平臺技術棧

Web技術棧

Atwood's Law: Any application that can be written in JavaScript, will eventually be written in JavaScript.

一個你或許不知道的冷知識，macOS的系統設置頁面是Webview+React寫的[1]

提到跨平臺，就不得不提Web生態了，Web相關的技術在跨平臺中永遠是最受青睞的選擇，無論是開發的便捷程度，還是龐大的JS開發者生態等等因素，都使得Web技術無論是在移動端還是桌面端的跨平臺應用開發上都穩坐使用率最高的技術棧。

• 優點

開發成本比原生低，可以方便做到一套代碼在不同操作系統上運行

實現復雜的UI和動效方便，可以更快地實現一些比較炫酷的UI界面

• 缺點

調用系統原生API不方便通常需要使用打包其他的運行時環境或JSBridge的方式來進行調用

Electron

Electron（原名為Atom Shell）是GitHub開發的一個開源框架，最初用來開發Atom編輯器。它通過使用Node.js（作為后端）和Chromium的渲染引擎（作為前端）完成跨平臺的桌面GUI應用程序的開發。

• 代表應用：VSCode（303M）、Figma（213M）、Bilibili（397M）、Discord（367M）、QQ Beta（747M）、1Password8（343M）、MS Teams（264M，根據參考文獻[2]，微軟正在替換Electron的實現，但目前看我電腦中下載的版本解包中，依然還有Electron.framework的文件）
• 優點

開發方便，技術棧適合前端同學（UI使用Web技術，系統API交互部分使用NodeJS）

• 缺點

打包體積大，需要打包Chromium和NodeJS的運行時環境

內存消耗大：Chromium本身比較吃內存，同時NodeJS是JIT運行的，相比較C++等AOT的語言來說內存消耗也更大。

• 性能需要多花點時間優化

實際上，并不代表Electron技術開發的應用性能就一定不如其他技術棧，總的來說，具體的性能表現還是取決于開發者的投入，例如微軟在VSCode的博客中給到了一個例子，能夠將VSCode在渲染括號顏色匹配的速度提高10000倍[3]。

CEF（Chromium Embedded Framework）

由于需要將Chromium和NodeJS的運行時打包進去，所以Electron構建應用的體積都會非常大，但是CEF的存在解決了Electron的這個問題（實際上，CEF出現的時間比Electron早多了）。由于Chromium里面有許多第三方組件（如ffmpeg等），在開發應用的過程中，我們通常不會使用到Chromium的全部能力，因此CEF提供了一個輕量級的嵌入式Chromium，同時還可以根據自己的需求進行裁剪。

CEF提供了將Chromium嵌入到應用中，展示Webview的能力，同時也提供了C++的一些API，在需要做一些瀏覽器無法實現的原生API依賴的功能時（如系統文件讀寫等），則需要使用C++（或其他語言，但是CEF的原生接口是C++的）來編寫相關的能力，并提供JSBridge給前端代碼進行調用。

• 代表應用：網易云音樂、Spotify、飛書等

自渲染技術棧

要實現跨平臺的GUI應用，比較流行的的方式是實現自渲染的管線。上層通過提供類Canvas的繪制、渲染和排版能力，下層使用OpenGL/Vulkan/Metal等圖形API進行繪制。在Web的跨平臺桌面應用開發技術棧發展之前，許多應用開發框架都采用了類似的思路去實現跨平臺的應用開發，如QT（C++語言）、Flutter（Dart語言，基于Skia渲染）和Swing（Java語言）等。相比于Electron和CEF的方案，由于不需要打包運行時環境（Swing除外，需要打包JRE）和減少了Bridge轉換，所以體積和運行效率通常會優于Web技術棧。

• 優點

自繪性能通常會優于Web跨平臺技術（具體還是取決于框架實現）

• 缺點

開發成本略高于Web技術棧

實現復雜效果的能力不如原生和Web技術棧，通常情況下需要寫更多復雜的代碼（取決于具體框架的設計，這一點Flutter做得比較好）

Qt（C++）

Qt（/?kju?t/）是一個跨平臺的C++應用程序開發框架，廣泛用于開發GUI程序，在工業、嵌入式等領域的桌面程序中有著非常深入的使用。

代表應用：WPS Office、剪映桌面版、AutoDesk

• 優點

性能好，與Native開發的應用性能相差無幾

支持的操作系統豐富，跨平臺性能好

• 缺點

C++開發成本高

GPL協議，商業版本需要給錢，不符合咱們去肥增瘦的理念

Flutter（Dart）

Flutter是一個由Google開發的跨平臺應用開發框架，最初只用于移動端為Android、iOS開發應用。2015年4月，Flutter正式發布，其目標是希望可以在跨平臺的特性上，實現120FPS的渲染性能。2018年，Flutter 1.0發布，是該框架的第一個穩定版本。2022年5月，Google 在 Google I/O 2022 發布了 Flutter 3.0版本，宣布對 Windows、macOS、Linux 桌面操作系統提供支持。

• 代表應用：？（Flutter在2022年5月份發布3.0版本，此時桌面應用才進入正式版支持，目前還并不成熟，所以在線上使用的較少，暫時沒聽過有啥桌面應用是用Flutter寫的）
• 優點

性能好（相比較Web技術棧）

Dart語言容易學習和上手、開發成本低

缺點

桌面端才剛剛發布穩定版支持，生態和穩定性都有待考量

Swing（Java）

Swing是一個用于開發Java GUI應用的框架。它采用純 Java 實現，不再依賴于本地平臺的圖形界面，所以可以在所有平臺上保持相同的運行效果，對跨平臺支持比較出色。

• 代表應用：Jetbrains IDE
• 優點

跨平臺性能好：write once run anywhere（write once debug everywhere)

• 缺點

需要打包JRE，體積大

總的來說，雖然不同大類技術棧的應用具體實現原理有所不同，但是相關開發的技術棧的大致特點可以歸納如下：

• 系統API調用和交互：原生應用 > 自渲染應用 > Web應用
• 開發便捷程度：Web應用 >> 自渲染應用 > 原生應用
• 打包體積：Web應用 > 自渲染應用 > 原生應用
• 性能：原生應用 > 自渲染應用 > Web應用

Tauri介紹

從上面的介紹可以看出，不同的技術棧的實現原理和特點各有區別，但是很難做到開發便捷程度、UI復雜效果、打包體積和性能等多個方面的兼顧，只能是根據應用的類型和具體的業務場景去決定到底使用哪種框架。

所以有沒有一種開發方式，可以在性能、體積、開發等多個角度上，取得一個比較好的平衡呢？這就來到了我們今天需要介紹的桌面應用開發框架Tauri。

Build an optimized, secure, and frontend-independent application for multi-platform deployment.

從上面Tauri官網的宣傳語可以看出Tauri主打的幾個賣點[4]：

• optimized：性能高、體積小
• secure：安全性強
• frontend-independent：前端獨立
• multiplatform：跨平臺

那么Tauri是如何通過在框架層面的設計來保證這樣的一些特性的呢？我們一起接著往下看??

Rust

Tauri框架是由Rust語言實現的，同時Tauri應用的后端也是由Rust來編寫的。Rust是由Mozilla主導開發的通用、編譯型的系統編程語言。設計準則為“安全、并發、實用”，支持函數式、并發式、過程式以及面向對象的編程風格。[5]相比較其他語言，Rust有如下的一些特性：

• 性能高（optimized）：Rust的性能和C/C++的性能不相上下，由于Rust的「所有權」機制，Rust不需要GC，同時也能避免如C/C++之類需要手動管理內存的語言忘記釋放內存導致的內存泄露的問題；
• 安全性強（secure）：Rust設計了一個所有權系統，其中所有值都有一個唯一的所有者，并且值的作用域與所有者的作用域相同。值可以通過不可變引用（&T）、可變引用（&mut T）或者通過值本身（T）傳遞。任何時候，一個變量都可以有多個不可變引用或一個可變引用，這實際上是一個顯式的讀寫鎖。Rust編譯器在編譯時強制執行這些規則，并檢查所有引用是否有效。能夠有效避免C/C++等語言中的懸垂指針等問題；
• FFI編譯友好（multiplatform）：FFI是可以用一種編程語言寫的程序能調用另一種編程語言寫的代碼的機制，使用Rust可以方便地提供接口給其他語言調用；

?WRY[1]：Webview Render Library?

由于Web技術的表現力強、開發成本低的特點，與Electron、CEF等框架類似，Tauri應用的前端實現也是使用Web技術棧編寫的。那么Tauri是如何解決Electron/CEF等框架遇到的Chromium內核體積過大的問題呢？

大家可能會想，如果每一個應用都需要把瀏覽器內核打包進去才能實現Web頁面的渲染，要是所有的應用都共享同一個內核就好了，這樣我們在分發應用的時候，不需要打包瀏覽器內核，只需要打包Web頁面的資源不就好了嗎？所以Tauri就采用了這樣的一個方案，WRY是Tauri封裝的Webview框架，它在不同操作系統的平臺上，封裝了系統Webview的實現：在macOS上使用WebKit.WKWebview[2]，在Windows上使用Webview2[3]，在Linux上使用WebKitGTK[4]。這樣在運行Tauri應用時，會直接使用系統Webview來渲染應用前端的展示。

?API接口?

對于不會使用Rust的同學來說，學習Rust還是存在著不少的學習成本，但是別擔心，在需求簡單的情況下，你完全可以不寫Rust代碼。Tauri框架提供了如下的一些API，可以方便地在JS中對原生能力進行調用：

• cli：解析應用啟動時的命令行參數
• clipboard：對系統剪貼板的讀寫
• dialog：展示系統文件選擇、文件保存彈窗
• event：給后端發出一些事件，后端監聽并處理
• fs：文件系統的操作，提供文件讀寫等能力
• globalShortcut：注冊全局快捷鍵
• http：使用Rust的Http客戶端進行網絡請求
• notification：系統通知
• os：獲取操作系統的一些信息
• path：文件和文件夾路徑處理的一些工具
• process：對當前的進程進行一些操作
• shell：對系統shell的一些操作

需要注意的是，上述的一些API，為了保證安全性，對于權限都有著嚴格的限制，都是默認關閉的狀態，需要修改配置以手動啟用相關的功能。

進程模型

和Electron類似，Tauri也采用的是多進程的架構（Electron中有主進程和渲染進程），多進程的好處是能夠更好更有效地利用現代多核CPU的能力，同時一個組件的崩潰也不會影響到其他組件的運行，因為組件被隔離在了不同的進程中。如果應用中的某個進程崩潰了，我們只要重啟該進程即可。還可以通過只給每個進程分配足夠完成工作的最低限度的權限，來限制潛在漏洞的破壞范圍。這種模式被稱為最小權限原則。

在Tauri中，進程分為兩類：主進程和Webview進程。每個 Tauri 應用程序都有一個主進程，它作為應用程序的入口點，是唯一可以完整訪問操作系統的組件。主進程的主要職責是使用訪問權限來創建和管理應用程序窗口、系統托盤菜單或通知。Tauri 實現了必要的跨平臺抽象來簡化該操作。它還通過核心進程路由所有的IPC，通過類似于事件總線的機制，可以方便地攔截、過濾和操作 IPC 消息。主進程還應該負責管理全局狀態，例如數據庫連接。這使你能夠輕松地在窗口間同步狀態，并保護你的業務敏感數據。主進程自身并不渲染實際的用戶界面，它會直接利用操作系統提供的 WebView 庫來實現頁面渲染，不同的窗口之間會擁有不同的WebView進程，WebView進程用來負責渲染對應的UI。

IPC模式

Brownfield 模式（默認）

Brownfield 軟件開發是指在現有或遺留軟件系統存在的情況下開發和部署新的軟件系統。[6]

使用 Tauri 的最簡單和直接的模式，因為 Brownfield 模式會盡最大可能嘗試與現有的前端項目兼容。在這種模式下，無需現有的瀏覽器前端項目進行任何操作即可遷移。

隔離模式

隔離模式是一種在到達 Tauri 主進程前，攔截并修改由Webview進程發送的 Tauri API 信息的IPC模式，其完全使用 JS 編寫。由隔離模式保障的JS代碼即稱為隔離應用。隔離模式的目的是為開發者提供一種保護機制，防止其應用程序被預料之外或惡意的Webview進程調用 Tauri 主進程。隔離模式的需求來自于前端中不可信任的內容所帶來的威脅，常見于需要許多依賴的應用。隔離模式在設計之初時設想的最大威脅為開發威脅，因為前端構建工具不僅僅由許許多多嵌套很深的依賴組成，而且還有很多嵌套很深的依賴被打包到最終的網頁構建產物中。

• 原理：隔離模式就是在Webview進程和 Tauri 主進程之間注入一個安全的應用程序，用以攔截和修改傳入的 IPC 信息。它使用<iframe> 的沙盒特性，與Webview進程一起安全地執行 JS 代碼。Tauri 在加載頁面時會強制執行隔離模式，使所有對 Tauri 主進程的 IPC 調用必須先通過沙盒隔離應用程序。當消息準備被傳遞給 Tauri 主進程時，其就會被使用瀏覽器的 SubtleCrypto API[5] 實現加密，并傳遞回主前端程序，之后，它將會被直接傳遞給 Tauri 主進程來解密和讀取數據。
• 步驟：

• 缺點

由于信息經過加密，所以隔離模式相比 Brownfield 模式而言存在額外開銷。除去性能敏感的應用 (使用很少依賴來提升性能的應用) 之外，使用 AES-GCM 算法來加解密 IPC 信息會對大部分應用造成相對較小的性能影響。

Windows平臺上，Webview限制了因為沙盒環境下加載<iframe> 標簽內的外部文件，Tauri在構建時實現一些步驟將腳本注入，但是ES Modules可能無法正常加載。

安全性

• 動態AOT：Tauri 應用啟動時將多次進行編譯。通過使用Tauri提供的動態預編譯器，可以生成每個會話都不同的代碼引用，但技術上一致的代碼單元；
• 函數 ASLR：函數地址空間布局隨機化 (Address Space Layout Randomization) 將在運行時隨機調整函數名稱，且可以實現 OTP 哈希功能，這樣將永遠不會出現相同的會話。在Tauri應用啟動時，或可選在每次執行后，隨機生成函數名稱。每個函數指針均使用 UID 以防止靜態攻擊；
• 自殺式函數注入：一種高級的ASLR技術，Rust在運行時載入進入Webview的閉包Promise和隨機的句柄，API接口在Promise處理中就被鎖定，在執行完畢后被立即設置成null；

可以有效防止惡意頁面被加載

• 使用Event Bridge：Tauri內部的信息通信使用Event Bridge，Event Bridge用來保證只能傳遞信息和指令給一個指定的中間代理，而不是直接傳遞不安全的函數調用；
• API Allow List：Tuari提供的API都是關閉狀態，若沒有啟用相關API，應用構建時不會包括相關功能函數的代碼。這可以減少二進制文件大小及攻擊面。同時API還有嚴格的權限選項，如文件讀寫相關API可以設置只讀/只寫/指定目錄或文件等功能；
• CSP：Tauri會對本地的HTML頁面強制使用內容安全策略，本地腳本經過哈希處理，同時樣式、外部腳本經由加密隨機字符串引用，防止禁止內容被加載；
• 反編譯難：Tauri在構建時，會將相關前端代碼直接構建在二進制可執行文件中，這意味著和Electron的ASAR文件不同，具體的代碼無法被輕松地反編譯；
• 一次性Token和哈希：使用OTP加鹽哈希處理重要的信息，可以在前端和Rust后端之間加密信息；

Tauri-egui[6]

因為Tauri應用的前端是用了Web相關的技術棧，因此在運行時總有辦法來使用開發者模式/調試工具等來進行檢查元素等。在某些情況下，如密碼輸入等場景，我們希望能夠保證前端的UI展示是無法被修改的，這時可以使用Tauri-egui這個庫，這個庫對egui進行了封裝，可以使用Rust來編寫前端的UI。

優點

Benchmark

• 內存使用

• 構建產物體積

缺點

兼容性：由于Tauri使用的是系統Webview，因此在構建時前端的代碼需要做polyfill；且Windows平臺上，由于Webview2只在Windows10/11上有默認推送安裝，要想在Windows7/8等較低版本的平臺上運行的話，還需要另外安裝Webview2的運行時。

參考資料

[1] 在macOS中打開系統Webview的檢查元素開關, https://blog.jim-nielsen.com/2022/inspecting-web-views-in-macos/

[2] 微軟開始在Teams應用中放棄Electron, https://blog.devgenius.io/microsoft-is-finally-ditching-electron-9e081757f9db

[3] VSCode優化括號顏色匹配, https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization

[4] Tauri官網, https://tauri.app

[5] Rust Wikipedia, https://zh.wikipedia.org/zh-cn/Rust

[6] Brownfield, https://en.wikipedia.org/wiki/Brownfield_(software_development)