桌面應(yīng)用開發(fā)

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

相比較于移動(dòng)端而言，桌面端應(yīng)用的生態(tài)多種多樣，因此也誕生了各種各樣的桌面應(yīng)用開發(fā)技術(shù)棧。本次分享將會(huì)對相關(guān)常用的一些桌面應(yīng)用開發(fā)框架進(jìn)行介紹和分析，同時(shí)對當(dāng)下比較流行（GitHub 50k star）的跨平臺(tái)桌面應(yīng)用開發(fā)框架Tauri進(jìn)行介紹。

原生技術(shù)棧

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

• 優(yōu)點(diǎn)

構(gòu)建產(chǎn)物體積小

性能好

系統(tǒng)API調(diào)用方便

兼容性好

和系統(tǒng)應(yīng)用的交互融合度高，如要實(shí)現(xiàn)如下的一些系統(tǒng)原生UI組件非常方便

• 缺點(diǎn)

無法做到跨平臺(tái)，所開發(fā)的應(yīng)用只能在對應(yīng)的平臺(tái)上運(yùn)行，如果需要跨平臺(tái)運(yùn)行，則需要在不同的操作系統(tǒng)上分別開發(fā)，開發(fā)成本高

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

Windows平臺(tái)

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

從Windows平臺(tái)應(yīng)用的開發(fā)技術(shù)迭代來看，也可以大致看出GUI程序的技術(shù)發(fā)展史：

• Win32API時(shí)代：函數(shù)調(diào)用，指令式，Windows系統(tǒng)處理
• MFC時(shí)代：面向?qū)ο螅岩恍┲噶钍秸{(diào)用封裝成類，由來自UI的消息驅(qū)動(dòng)程序處理數(shù)據(jù)
• Windows Form時(shí)代：組件化，在類的基礎(chǔ)上封裝成組件，消息被封裝成事件，事件驅(qū)動(dòng)
• WPF時(shí)代：使用類XML語言來描述UI，引入數(shù)據(jù)驅(qū)動(dòng)UI的理念
• UWP時(shí)代：跨平臺(tái)、多語言

macOS平臺(tái)

現(xiàn)有的macOS原生應(yīng)用主要基于Cocoa框架開發(fā)，Cocoa是從1980年代由NeXT（macOS的前身）開發(fā)的編程環(huán)境NeXTSTEP和OPENSTEP演變而來，是面向?qū)ο蟮腁PI。

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

Linux平臺(tái)

Linux其源碼只包含了操作系統(tǒng)內(nèi)核的部分，桌面并不屬于Linux源碼的一部分，因此嚴(yán)格意義上來說，從「使用系統(tǒng)API和操作系統(tǒng)廠商提供的SDK開發(fā)的應(yīng)用為原生應(yīng)用」的定義上來說，并無所謂「原生技術(shù)?！沟母拍?。我們?nèi)粘Ｊ褂玫陌l(fā)行版提供了桌面環(huán)境如KDE、Gnome等，Linux發(fā)行版的這些桌面環(huán)境也提供了相關(guān)的一些庫或者API來幫助繪制GUI程序，如gtk+等，可以認(rèn)為是「原生技術(shù)?！?。

跨平臺(tái)技術(shù)棧

Web技術(shù)棧

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

一個(gè)你或許不知道的冷知識(shí)，macOS的系統(tǒng)設(shè)置頁面是Webview+React寫的[1]

提到跨平臺(tái)，就不得不提Web生態(tài)了，Web相關(guān)的技術(shù)在跨平臺(tái)中永遠(yuǎn)是最受青睞的選擇，無論是開發(fā)的便捷程度，還是龐大的JS開發(fā)者生態(tài)等等因素，都使得Web技術(shù)無論是在移動(dòng)端還是桌面端的跨平臺(tái)應(yīng)用開發(fā)上都穩(wěn)坐使用率最高的技術(shù)棧。

• 優(yōu)點(diǎn)

開發(fā)成本比原生低，可以方便做到一套代碼在不同操作系統(tǒng)上運(yùn)行

實(shí)現(xiàn)復(fù)雜的UI和動(dòng)效方便，可以更快地實(shí)現(xiàn)一些比較炫酷的UI界面

• 缺點(diǎn)

調(diào)用系統(tǒng)原生API不方便通常需要使用打包其他的運(yùn)行時(shí)環(huán)境或JSBridge的方式來進(jìn)行調(diào)用

Electron

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

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

開發(fā)方便，技術(shù)棧適合前端同學(xué)（UI使用Web技術(shù)，系統(tǒng)API交互部分使用NodeJS）

• 缺點(diǎn)

打包體積大，需要打包Chromium和NodeJS的運(yùn)行時(shí)環(huán)境

內(nèi)存消耗大：Chromium本身比較吃內(nèi)存，同時(shí)NodeJS是JIT運(yùn)行的，相比較C++等AOT的語言來說內(nèi)存消耗也更大。

• 性能需要多花點(diǎn)時(shí)間優(yōu)化

實(shí)際上，并不代表Electron技術(shù)開發(fā)的應(yīng)用性能就一定不如其他技術(shù)棧，總的來說，具體的性能表現(xiàn)還是取決于開發(fā)者的投入，例如微軟在VSCode的博客中給到了一個(gè)例子，能夠?qū)SCode在渲染括號(hào)顏色匹配的速度提高10000倍[3]。

CEF（Chromium Embedded Framework）

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

CEF提供了將Chromium嵌入到應(yīng)用中，展示W(wǎng)ebview的能力，同時(shí)也提供了C++的一些API，在需要做一些瀏覽器無法實(shí)現(xiàn)的原生API依賴的功能時(shí)（如系統(tǒng)文件讀寫等），則需要使用C++（或其他語言，但是CEF的原生接口是C++的）來編寫相關(guān)的能力，并提供JSBridge給前端代碼進(jìn)行調(diào)用。

• 代表應(yīng)用：網(wǎng)易云音樂、Spotify、飛書等

自渲染技術(shù)棧

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

• 優(yōu)點(diǎn)

自繪性能通常會(huì)優(yōu)于Web跨平臺(tái)技術(shù)（具體還是取決于框架實(shí)現(xiàn)）

• 缺點(diǎn)

開發(fā)成本略高于Web技術(shù)棧

實(shí)現(xiàn)復(fù)雜效果的能力不如原生和Web技術(shù)棧，通常情況下需要寫更多復(fù)雜的代碼（取決于具體框架的設(shè)計(jì)，這一點(diǎn)Flutter做得比較好）

Qt（C++）

Qt（/?kju?t/）是一個(gè)跨平臺(tái)的C++應(yīng)用程序開發(fā)框架，廣泛用于開發(fā)GUI程序，在工業(yè)、嵌入式等領(lǐng)域的桌面程序中有著非常深入的使用。

代表應(yīng)用：WPS Office、剪映桌面版、AutoDesk

• 優(yōu)點(diǎn)

性能好，與Native開發(fā)的應(yīng)用性能相差無幾

支持的操作系統(tǒng)豐富，跨平臺(tái)性能好

• 缺點(diǎn)

C++開發(fā)成本高

GPL協(xié)議，商業(yè)版本需要給錢，不符合咱們?nèi)シ试鍪莸睦砟?/p>

Flutter（Dart）

Flutter是一個(gè)由Google開發(fā)的跨平臺(tái)應(yīng)用開發(fā)框架，最初只用于移動(dòng)端為Android、iOS開發(fā)應(yīng)用。2015年4月，F(xiàn)lutter正式發(fā)布，其目標(biāo)是希望可以在跨平臺(tái)的特性上，實(shí)現(xiàn)120FPS的渲染性能。2018年，F(xiàn)lutter 1.0發(fā)布，是該框架的第一個(gè)穩(wěn)定版本。2022年5月，Google 在 Google I/O 2022 發(fā)布了 Flutter 3.0版本，宣布對 Windows、macOS、Linux 桌面操作系統(tǒng)提供支持。

• 代表應(yīng)用：？（Flutter在2022年5月份發(fā)布3.0版本，此時(shí)桌面應(yīng)用才進(jìn)入正式版支持，目前還并不成熟，所以在線上使用的較少，暫時(shí)沒聽過有啥桌面應(yīng)用是用Flutter寫的）
• 優(yōu)點(diǎn)

性能好（相比較Web技術(shù)棧）

Dart語言容易學(xué)習(xí)和上手、開發(fā)成本低

缺點(diǎn)

桌面端才剛剛發(fā)布穩(wěn)定版支持，生態(tài)和穩(wěn)定性都有待考量

Swing（Java）

Swing是一個(gè)用于開發(fā)Java GUI應(yīng)用的框架。它采用純 Java 實(shí)現(xiàn)，不再依賴于本地平臺(tái)的圖形界面，所以可以在所有平臺(tái)上保持相同的運(yùn)行效果，對跨平臺(tái)支持比較出色。

• 代表應(yīng)用：Jetbrains IDE
• 優(yōu)點(diǎn)

跨平臺(tái)性能好：write once run anywhere（write once debug everywhere)

• 缺點(diǎn)

需要打包JRE，體積大

總的來說，雖然不同大類技術(shù)棧的應(yīng)用具體實(shí)現(xiàn)原理有所不同，但是相關(guān)開發(fā)的技術(shù)棧的大致特點(diǎn)可以歸納如下：

• 系統(tǒng)API調(diào)用和交互：原生應(yīng)用 > 自渲染應(yīng)用 > Web應(yīng)用
• 開發(fā)便捷程度：Web應(yīng)用 >> 自渲染應(yīng)用 > 原生應(yīng)用
• 打包體積：Web應(yīng)用 > 自渲染應(yīng)用 > 原生應(yīng)用
• 性能：原生應(yīng)用 > 自渲染應(yīng)用 > Web應(yīng)用

Tauri介紹

從上面的介紹可以看出，不同的技術(shù)棧的實(shí)現(xiàn)原理和特點(diǎn)各有區(qū)別，但是很難做到開發(fā)便捷程度、UI復(fù)雜效果、打包體積和性能等多個(gè)方面的兼顧，只能是根據(jù)應(yīng)用的類型和具體的業(yè)務(wù)場景去決定到底使用哪種框架。

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

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

從上面Tauri官網(wǎng)的宣傳語可以看出Tauri主打的幾個(gè)賣點(diǎn)[4]：

• optimized：性能高、體積小
• secure：安全性強(qiáng)
• frontend-independent：前端獨(dú)立
• multiplatform：跨平臺(tái)

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

Rust

Tauri框架是由Rust語言實(shí)現(xiàn)的，同時(shí)Tauri應(yīng)用的后端也是由Rust來編寫的。Rust是由Mozilla主導(dǎo)開發(fā)的通用、編譯型的系統(tǒng)編程語言。設(shè)計(jì)準(zhǔn)則為“安全、并發(fā)、實(shí)用”，支持函數(shù)式、并發(fā)式、過程式以及面向?qū)ο蟮木幊田L(fēng)格。[5]相比較其他語言，Rust有如下的一些特性：

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

?WRY[1]：Webview Render Library?

由于Web技術(shù)的表現(xiàn)力強(qiáng)、開發(fā)成本低的特點(diǎn)，與Electron、CEF等框架類似，Tauri應(yīng)用的前端實(shí)現(xiàn)也是使用Web技術(shù)棧編寫的。那么Tauri是如何解決Electron/CEF等框架遇到的Chromium內(nèi)核體積過大的問題呢？

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

?API接口?

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

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

需要注意的是，上述的一些API，為了保證安全性，對于權(quán)限都有著嚴(yán)格的限制，都是默認(rèn)關(guān)閉的狀態(tài)，需要修改配置以手動(dòng)啟用相關(guān)的功能。

進(jìn)程模型

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

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

IPC模式

Brownfield 模式（默認(rèn)）

Brownfield 軟件開發(fā)是指在現(xiàn)有或遺留軟件系統(tǒng)存在的情況下開發(fā)和部署新的軟件系統(tǒng)。[6]

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

隔離模式

隔離模式是一種在到達(dá) Tauri 主進(jìn)程前，攔截并修改由Webview進(jìn)程發(fā)送的 Tauri API 信息的IPC模式，其完全使用 JS 編寫。由隔離模式保障的JS代碼即稱為隔離應(yīng)用。隔離模式的目的是為開發(fā)者提供一種保護(hù)機(jī)制，防止其應(yīng)用程序被預(yù)料之外或惡意的Webview進(jìn)程調(diào)用 Tauri 主進(jìn)程。隔離模式的需求來自于前端中不可信任的內(nèi)容所帶來的威脅，常見于需要許多依賴的應(yīng)用。隔離模式在設(shè)計(jì)之初時(shí)設(shè)想的最大威脅為開發(fā)威脅，因?yàn)榍岸藰?gòu)建工具不僅僅由許許多多嵌套很深的依賴組成，而且還有很多嵌套很深的依賴被打包到最終的網(wǎng)頁構(gòu)建產(chǎn)物中。

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

• 缺點(diǎn)

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

Windows平臺(tái)上，Webview限制了因?yàn)樯澈协h(huán)境下加載<iframe> 標(biāo)簽內(nèi)的外部文件，Tauri在構(gòu)建時(shí)實(shí)現(xiàn)一些步驟將腳本注入，但是ES Modules可能無法正常加載。

安全性

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

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

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

Tauri-egui[6]

因?yàn)門auri應(yīng)用的前端是用了Web相關(guān)的技術(shù)棧，因此在運(yùn)行時(shí)總有辦法來使用開發(fā)者模式/調(diào)試工具等來進(jìn)行檢查元素等。在某些情況下，如密碼輸入等場景，我們希望能夠保證前端的UI展示是無法被修改的，這時(shí)可以使用Tauri-egui這個(gè)庫，這個(gè)庫對egui進(jìn)行了封裝，可以使用Rust來編寫前端的UI。

優(yōu)點(diǎn)

Benchmark

• 內(nèi)存使用

• 構(gòu)建產(chǎn)物體積

缺點(diǎn)

兼容性：由于Tauri使用的是系統(tǒng)Webview，因此在構(gòu)建時(shí)前端的代碼需要做polyfill；且Windows平臺(tái)上，由于Webview2只在Windows10/11上有默認(rèn)推送安裝，要想在Windows7/8等較低版本的平臺(tái)上運(yùn)行的話，還需要另外安裝Webview2的運(yùn)行時(shí)。

參考資料

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

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

[3] VSCode優(yōu)化括號(hào)顏色匹配, https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization

[4] Tauri官網(wǎng), https://tauri.app

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

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