最近需要用 Rust 做 GUI，进行了研究和实验，分享收集的数据，主要比较 Tauri、Iced 和 egui 这三个较受欢迎的选择，花费时间测试评估这些库的速度/性能，因为快速的 UI 体验很重要。

关键要点

• 对于大多数情况，三者速度可能都足够快。

• Tauri 在启动时间和调整大小性能方面稍落后于 Iced 和 egui（在作者的机器上）。

  快速介绍

• Tauri：使用操作系统的 webview 渲染 HTML/JS 前端，可选择任何前端框架（JS 或 Rust），后端用 Rust 编写，可通过内置方法与前端通信。
• Iced：受 Elm 启发的（响应式）GUI 库，在桌面端使用 wgpu 渲染，有实验性的 Web 后端创建 DOM 用于渲染，全部代码用 Rust 编写。

• egui：即时模式 GUI，使用 OpenGL 进行自定义渲染，全部代码用 Rust 编写。

  统计信息	Tauri	Iced	egui
  GitHub	60k★，10k 使用	18k★，2k 使用	13k★，6k 使用
  crates.io 下载量（近期/总下载量）	145k / 485k	30k / 180k	135k / 600k
  架构与实现	Tauri	Iced	egui
  编程模型	取决于选择的前端框架	类似 Elm 的/响应式	即时模式
  桌面	🟢 通过操作系统 webview	🟢 wgpu 基础	🟢 后端无关，默认后端是 OpenGL 基础
  Web	🟡 非内置，可手动设置	🟠 实验性，通过iced_web	🔴 通过 WebGL†
  主观评级	Tauri	Iced	egui
  稳定性/成熟度	🟢 1.0，社区大，有赞助商，多个开发者，有治理页面	🟠 0.7，“实验性”，2019 年起活跃开发，使用较多	🟠 0.20，“在活跃开发”，“接口不稳定”，“缺少功能”，2019 年起活跃开发，主要一个开发者，使用较多
  文档	相当好，有很多模板，后端的指南级文档可能不足，库文档可更好	良好的库文档，但缺少指南级文档，“书”基本不存在，有很多示例	良好的库文档，有很多示例
  开发体验（DX）	🟢 前端即时重新加载，浏览器开发工具，良好的 CLI 工具	🟠 总是重新编译，有性能指标的调试覆盖	🟠 总是重新编译
  作者机器上的性能（见下方免责声明！）	Tauri	Iced	egui
  启动时间	≈380ms（窗口约 125ms 后）	≈230ms（窗口约 33ms 后）	≈280ms
  输入延迟（帧率 = 16ms）	2 - 3 帧	3 帧	2 帧
  调整大小	🟠 10 - 15fps	🟡 12 - 30fps	🟡 12 - 30fps
  二进制大小	5MB	17MB	18MB

  † 在 Web 上使用基于画布的渲染器由于多种原因不是最优的（无法 ctrl+f，输入怪异等），更多信息见这里。

  性能

  重要免责声明

  所有测量都在作者的 Ubuntu 20.04、Gnome 3.36.8、X11、Nvidia 专有驱动、无动画（在 Gnome Tweaks 中禁用）、60Hz 显示器上进行，几乎未更改任何桌面/Gnome 配置，设置可能因多种原因出错（#linux），不要将这些性能指标视为关于这些 GUI 库的通用声明，未测试 Windows 或 macOS，它们的表现可能差异很大。

  方法

  所有测量通过用OBS记录全屏，然后在Avidemux中计数帧来进行，使用的程序有：Tauri 的helloworld示例7e8e0e76ec、Iced 的todos示例98a717383a、egui 的hello_world示例5725868b57、打开项目和多个标签的 Sublime Text 4143、侧边浏览器打开主目录但几乎没有标签的 VS Code 1.74.3、xclock，前三个自己用cargo build --release编译，后三个用于比较，作者意识到对 Sublime Text 和 VS Code 的比较不公平，因为它们是有用的程序且加载了很多数据，而非最小示例，但仍认为比较有用。

  启动时间

  直接从终端启动二进制文件，从终端绘制“Enter”按下到窗口出现/最终 UI 渲染的时间计数，不是绝对感知启动时间的精确测量，但对相对比较有用，单位为 ms，每个测试/试验一个数字。

  	最终渲染	窗口出现	视觉跳跃	窗口内容行为
  Tauri	366, 417, 400	100, 134, 150	1	先灰色，然后最终 UI
  Iced	333, 217, 266, 217, 217	33, 33, 33, 33, 50	1	先黑色，然后最终 UI
  egui	300, 200, 283, 300, 250	🠔	0	从开始就是最终 UI
  xclock	66, 100, 84	🠔	0	从开始就是最终 UI
  Sublime	450, 450, 467	🠔	0	从开始就是最终 UI
  VSCode	1450, 1250, 1450	500, 484, 517	4	先灰色，180ms 后蓝色，一帧后三个颜色区域（大致类似布局），约 400ms 后几乎是最终 UI，130ms 后绘制图标

  调整大小

  应用水平调整大小（改变宽度），通过查看记录并计数变化之间的帧来确定 FPS，“装饰”指带有关闭按钮等的窗口标题栏。

  	调整大小 FPS	行为
  **Tauri	≈10 - 15fps	UI 落后于窗口
  **Iced	≈12 - 30	UI 与窗口同步，有趣的是装饰落后
  **egui	≈12 - 30	UI 与窗口同步
  **xclock	≈20 - 30	UI 与窗口同步
  **Sublime	≈20 - 30	UI 与窗口同步
  **VSCode	≈8 - 12	UI 落后于窗口（有时黑色替换，有时蓝色）

  输入延迟

  为每个应用选择一个在悬停时改变颜色的元素，计数光标在该元素上而元素未改变颜色的帧数，光标也由 OBS 记录，不确定此测量的准确性，仅供参考。
  输入延迟（每个测试多次）：

• Tauri：3, 2, 2, 3, 3, 3, 3
• Iced：3, 3, 3, 3, 3, 3, 3
• egui：2, 2, 2, 2, 2, 2
• Sublime：2, 2, 2, 3, 2
• VSCode：3, 4, 6, 3, 3, 6
  检查了 Tauri、Sublime Text 和 VSCode，三者滚动都为 30 - 60fps，Sublime 比其他两者更常达到 60fps，但也偶尔跳过一帧。
  在 Reddit 上讨论。