Tauri 与 Electron 对比：性能、包大小及实际权衡

原文链接：Tauri vs. Electron: performance, bundle size, and the real trade-offs，2025.04.09，by Costa Alexoglou。

在跨平台应用开发中选择 Tauri 还是 Electron？本文通过实际对比和基准测试数据，深入剖析两者的差异。

引言

最近我们公司在开发一款跨平台远程控制应用程序，既能实现低延迟的远程结对编程体验，又能为用户提供最佳体验。

开发初期，我们面临着使用 Tauri 还是 Electron 来构建应用程序的决策。选择这两个框架中的任何一个，都有望避免为每个平台（Windows、macOS、Linux）编写原生代码，当然也要求我们需要慎重考虑这个选择。

Tauri 和 Electron 都是强大的框架，但它们存在着根本差异。我们必须仔细权衡这些差异，来确定哪个框架能为Hopp的长期发展提供最佳支持。

如果你目前也在为自己的项目权衡选择 Tauri 还是 Electron，希望这篇文章能给你带来一些帮助。

本文涵盖内容

• Tauri 和 Electron 底层的核心差异。
• 每个框架的优势和局限性。
• 关于应用程序大小、启动时间和内存使用情况的基准测试。
• 我们选择 Tauri 的原因。

Tauri 与 Electron 的主要差异

开发者在初次研究 Tauri 时，经常会看到一些文章将其描述为"更轻量的 Electron"，或者强调需要"学习 Rust 语言"。虽然这些说法有一定道理，但并没有全面地展现两者的差异。这两个领先的跨平台框架在架构上存在差异，这些差异会对开发过程和性能产生影响。

让我们深入了解一下 Tauri 和 Electron 在幕后是如何运作的。

Electron 的运行模式

Electron 的主进程作为一个 NodeJS 进程运行的。这种架构要求在应用程序中附带一个 Node.js 运行时，来确保它能在任何用户的机器上正确运行。

因此，应用程序的事件处理依赖于 Node.js 的事件循环。对于高性能任务或更深入的操作系统级交互，通常必须生成一个单独的进程，并通过进程间通信（IPC）或其他协议（如 Unix 套接字）来建立通信。

Electron 的渲染进程

Electron 的渲染进程可以看作是由主进程生成的单个浏览器标签页。实际上，在 Electron 应用程序中打开的每个窗口都会创建一个新的渲染进程。

这表示当打开多个窗口的应用程序时会同时运行多个渲染进程。开发者必须考虑这些进程累积的内存和 CPU 使用情况，这就好比在后台运行多个小型 Chromium 实例。

Electron 团队给出了一个很形象的比喻：

Tauri 的运行模式

Tauri 的后端使用 Rust 语言。其一个关键优势在于，Rust 可以编译成本地二进制文件**，无需在应用程序中捆绑运行时（如 Node.js）**，这就让应用程序更加轻量，不过后面也会讨论到这其中存在的权衡。

Tauri 没有捆绑整个 Chromium 引擎，而是使用操作系统的原生 WebView 组件来渲染用户界面。这个组件通常比完整的浏览器引擎要轻量。目前，Tauri 在不同操作系统上的使用情况如下：

• 在 Windows 上使用 WebView2（基于微软 Edge/Chromium）
• 在 macOS 上使用 WKWebView（基于 Safari/WebKit）
• 在 Linux 上使用 WebKitGTK

通过依赖系统的 WebView，Tauri 生成的应用程序包更小，但这也有一定代价。

使用 Tauri 的开发者可能会面临跨平台用户界面一致性的挑战。可能会出现特定浏览器的怪异问题，比如在 Safari 中出现但 Chrome 中没有的问题，或者 Firefox 在不同操作系统上表现不同。由于 Tauri 在每个操作系统上使用不同的底层 Web 引擎，这些平台差异在应用程序开发过程中成为开发者必须处理的因素。

功能对比

以下是一个对比表格，突出了 Tauri 和 Electron 的关键方面，其中略微侧重了对我们来说比较重要的因素。在表格之后，我将详细介绍关于应用程序大小、启动时间和内存使用情况的简单基准测试。

功能	**Tauri **🦀	**Electron **⚛️
启动时间	🏎️ 快速	🏎️ 快速
内存使用（基准测试）	172MB	409MB
浏览器技术	WebView	Chromium
后端语言	Rust	JavaScript
构建时间（首次）	🐢 缓慢	🏎️ 快速
包大小（基准测试）	8.6MiB	244MiB

应用基准测试

为了说明实际差异，本次基准测试对比了分别使用这两个框架构建的两个应用程序。它们的功能如下：

• 显示一个主窗口，窗口中有一个按钮，用于打开新窗口。
• 同时打开 6 个窗口，观察资源使用情况。

创建这两个应用程序的命令如下：

# 创建 Electron 应用
npx create-electron-app@latest electron-demo-app --template=vite-typescript
# 创建 Tauri 应用（选择 TypeScript、Vite 和 React）
yarn create tauri-app

最终生成的应用程序界面如下：

🚧声明：这是在我的 MacBook Pro 上进行的一次基本基准测试（N=1）。请谨慎对待以下数据。

构建时间

Tauri 的首次构建时间明显更长，这主要是因为 Rust 编译步骤。不过后续构建通常会快很多。

# Electron
❯ time yarn make
...[LOGS]...
yarn make  13.23s user 1.55s system 93% cpu 15.818 total

# Tauri
❯ time yarn tauri build
...[LOGS]....
yarn tauri build  380.11s user 28.37s system 504% cpu 1:20.94 total

包大小

正如架构差异所预期的那样，Tauri 生成的应用程序包更小。这是因为：

• Tauri 不捆绑 JavaScript 运行时（Node.js）。
• Tauri 使用系统的 WebView，而不是捆绑 Chromium。

两者差异十分明显，Tauri 的包大小为 8.6MiB，而 Electron 的包大小为 244MiB：

❯ du -h -d 1.
8.6M    ./tauri-demo-app.app
244M    ./electron-demo-app.app

内存使用

这方面凸显了 Tauri"更轻量"的特点。差异主要源于两个方面：

• Electron 的主进程：Node.js 运行时本身会消耗内存。
• 渲染进程：在 macOS 上，Electron 基于 Chromium 的渲染进程在相同窗口数量下，消耗的内存大约是 Tauri 的 WKWebView 进程的两倍。

在两个应用程序中都打开6个窗口后，测量得到的大致内存使用情况如下：

• Tauri：约 172 MB
• Electron：约 409 MB

启动时间

启动时间是另一个常见的考量因素。在这个简单的基准测试中，两者的差异可以忽略不计。说实话，对于大多数应用程序而言，仅仅基于不到 1500 毫秒的启动时间差异来决定选择哪个框架，可能有些多虑了。

如需了解各框架更详细的基准数据，请查看这里的 Web 到桌面框架比较资料库。

我们选择 Tauri 的原因

上述对比展示了 Tauri 和 Electron 之间的权衡。我们选择 Tauri 主要基于以下几个关键原因：

后端性能

我们公司的应用依赖定制版的 WebRTC 来实现超低延迟的屏幕共享功能。应用程序需要从后端进程直接传输视频流，而不是使用浏览器的标准屏幕共享应用程序编程接口（screen-sharing Application Programming Interfaces）。

Rust 的性能非常适合这项高强度的任务。如果在 Electron 中实现，就需要为视频流管理一个单独的进程，这会使架构变得复杂。

边车支持

虽然 Tauri 的主进程使用 Rust，但我们需要一个单独的进程（即"Sidecar support"）来处理屏幕流和远程控制输入（点击、打字）。这样可以将这个组件与应用程序的其他部分分开进行开发和测试。

Tauri 内置的边车概念简化了对这个外部二进制文件生命周期的管理。而在 Electron 中实现同样的功能，则需要手动生成、监控并与外部进程进行通信，这会增加复杂性。

需要注意的是，Tauri 的边车在概念上与 Kubernetes 模式有所不同，但目的都是管理一个伴随进程。

我们还利用边车进程来绘制控制器的光标。未来，我们可能会切换使用 Tauri egui。

功能可用性

尽管 Tauri 比 Electron 出现得晚，但它发展迅速。特别是 Tauri v2，缩小了功能差距，将内置更新器等重要功能作为核心特性。这个项目的发展势头以及对性能和安全性的关注与我们的需求相契合。

结论

希望这篇对比文章能为你带来启发，尤其是当你正在为下一个项目在 Tauri 和 Electron 之间做选择的时候。

并没有绝对"正确"的答案。最佳选择取决于你的具体用例、团队专业知识和项目需求。这两个框架都能构建强大的桌面应用程序，它们各自都有独特的优势和局限性。