스크립트
00:00:00过去构建跨平台桌面应用通常意味着选择 Electron，但如今我们
00:00:04有了多种选择。为了消除困惑，今天我们将对比三种最佳的
00:00:09跨平台桌面应用构建方案：基于 Rust 的 Tauri，来自 Bun 团队的 Electro Bun，
00:00:14以及 Deno 推出的新产品 Deno Desktop。我们还会以 Electron 作为基准。如果你想
00:00:20在这个频道看到其他工具的测评，请在评论区告诉我。
00:00:23我们将从四个方面进行对比：包体积、启动性能、运行时性能和开发
00:00:29体验。我编写了同一个应用四次：一个屏幕录制工具，支持在
00:00:35时间轴上编辑录制结果并导出为 MP4。我之所以选择这类应用，是因为视频处理
00:00:40可以将这些工具推向极限。当然，并非一切都取决于性能，
00:00:44团队的技能储备和你正在构建的产品类型，都会影响你选择的
00:00:49框架选择，但希望这能为您提供一些预期方面的指导
00:00:58那么让我们快速进入我们所构建应用程序的演示，首先启动我们的应用
00:01:03应用，选择要录制的屏幕，然后点击录制按钮。现在我们可以进行一段简短的
00:01:08屏幕录制。完成后点击停止，窗口会显示时间轴上的录制内容。
00:01:12我们可以对片段进行剪辑以去除空白，然后点击导出为 MP4。这个应用
00:01:18其实非常简单，但由于我们使用了多种 API，包括录制、处理视频和
00:01:24渲染 UI，这应该算是一个不错的测试。首先我们要检查的是
00:01:28包体积。请记住，这些应用的功能完全相同。作为基准的 Electron 是 323
00:01:35兆字节，Tauri 仅为 57 兆字节，Electro Bun 为 418 兆字节，而 Deno 为 111 兆字节。
00:01:44它们都集成了用于导出 MP4 的 FFmpeg，这部分本身就占了 45 兆字节。Electro Bun 之所以
00:01:52这么大，是因为我必须随附 Chromium。我尽了最大努力，但确实无法
00:01:56让屏幕录制功能在使用原生系统 WebView 的情况下正常工作，特别是通过 JavaScript 录制。
00:02:01你需要 Screen Capture API 和 getDisplayMedia 函数。你向浏览器请求屏幕，
00:02:06它会给你一个流，由 Media Recorder 进行编码，Electron 和 Deno 就是这么做的。Electro Bun
00:02:12完全不包含该 API，因此唯一的使用方法就是重新引入 Chromium，这
00:02:17带来了额外的 200 兆字节的臃肿。Deno 的 API 实现了这一功能，所以代码逻辑相同，
00:02:24但无需 Chromium，这就是为什么 Deno 的包体积约为 100 兆字节，而 Electro
00:02:30Bun 接近 400 兆字节。Rust 不需要这些，因为 Tauri 根本不通过
00:02:35Webview 录制，它完全通过后端使用原生的 Screen Capture Kit 来完成。这是
00:02:40macOS 原生的框架，QuickTime 也在使用，完全在后端直接录制。你只需要
00:02:46提供显示器、编解码器和文件路径，它就会自行写入文件。WebView 仅负责 UI，从不
00:02:52触碰任何帧，而且你还能免费获得 JavaScript 构建版本必须手动处理的功能。
00:02:56Screen Capture Kit 会自动混合麦克风和系统音频，并生成正确的 MP4。我
00:03:02确实在 Tauri 应用中保留了 FFmpeg 以便导出为其他格式，但技术上这是
00:03:07可选的。好了，现在我们可以启动这些应用来检测启动时间。我编写了一个脚本
00:03:13运行了 10 次并取中位数。作为基准的 Electron 为 273 毫秒，Tauri
00:03:19实际为 311 毫秒，Electro Bun 为 773 毫秒，Deno 为 242 毫秒。
00:03:29令我惊讶的是 Tauri 竟然不是最快的，它比 Electron 慢了一点点，而 Deno
00:03:34居然击败了所有人。人们通常认为 Rust 加上原生系统 WebView 会实现瞬间
00:03:39启动，但由于渲染引擎无论如何都需要加载，这可能就是导致
00:03:44启动速度稍慢的原因。Electro Bun 是个异类，几乎是 Electron 的三倍，因为它启动
00:03:50一个启动器，进而启动 Bun，再启动 Chromium，这是一连串的三个运行时，确实能感觉到。
00:03:56现在看看启动后的内存占用。应用运行后，Electron 再次作为基准，
00:04:01它是 128 兆字节，Tauri 是 109 兆字节，Electro Bun 是 208 兆字节，Deno 是 98
00:04:10兆字节。所以 Deno 和 Tauri 基本持平，而 Electro Bun 基本上是其他产品的一倍。
00:04:15对于 Tauri 来说，这与营销中所暗示的 10 倍性能提升相去甚远。在磁盘空间上，它确实要
00:04:21小得多，但实际运行时的内存占用与其他
00:04:26工具非常相似。在你自己进行这些测试时需要注意的一点是，Tauri 使用了
00:04:31系统 WebView，而这些进程并不是你应用的子进程。macOS 会单独启动它们，所以
00:04:36活动监视器显示 Tauri 约为 36 兆字节，看起来它比 Electron 优越三倍，
00:04:42但其实不然。当你把所有进程加在一起时，36 兆字节会更接近测试中记录的 109 兆字节。
00:04:48就屏幕录制本身而言，我确实注意到 Tauri 应用的性能好得多，
00:04:53这可能是因为我们没有在 Web
00:04:58View 中录制数据，然后再通过桥接传输。相反，它是通过系统自带的
00:05:04原生 SDK 录制的。如果你想达到接近 60 帧的录制效果，Rust 和 Tauri 是
00:05:10最佳选择。现在看看开发体验。由于各平台差异，这个简单的
00:05:15应用其实一点也不好做。总的来说，Electron 和 Tauri 最容易
00:05:20实现，但 Deno 和 Electro Bun 确实遇到了很多问题。在 Deno 中，当我们
00:05:26开始录制然后隐藏应用时，整个程序就会直接关闭。我想这是因为
00:05:30当没有屏幕可见时，Deno 就认为应用已经结束，从而终止了
00:05:36整个进程。因此，解决这个问题的黑客手段就是把视图隐藏到屏幕外。
00:05:41Electro Bun 在屏幕录制需要打包 Chromium 方面有各种问题，而且出于某种原因，
00:05:46该包居然依赖于用于 3D 渲染的 Three.js 和 Babylon.js，这也导致了
00:05:53包体积臃肿。所以总的来说，我个人会选择 Tauri，但如果你真的不想用 Rust
00:05:58编程，那么 Electron 依然是 TypeScript 开发者的成熟平台。Deno 看上去还可以，但我认为
00:06:04该平台仍需时间成熟。而 Electro Bun 对我来说是其中最差的一个。
00:06:09希望你能做出自己的判断。请在评论区告诉我你的想法。我们还
00:06:13制作了一个专门关于 Deno Desktop 的视频，如果你想了解更多，可以点击这个
00:06:18视频。我是来自 Betterstack 的 Warren，感谢观看，下次见。