桌面应用跨平台移动开发【免费下载链接】tauriBuild smaller, faster, and more secure desktop and mobile applications with a web frontend.项目地址https://gitcode.com/GitHub_Trending/ta/tauri点击查看免费下载Tauri 仓库中的bench模块是一个仅限内部使用Internal use only的 Rust 基准测试工具集专门运行于 CI 环境用于持续采集 Tauri 核心的运行时性能指标为框架的回归检测与版本演进提供量化依据。本文基于 bench/README.md 并结合 bench/ 目录下的完整源码系统拆解该模块的基准场景设计、指标采集原理、结果数据结构以及历史数据的聚合流程帮助读者理解 Tauri 团队如何用三个最小示例应用度量启动速度、二进制体积、系统调用、内存峰值与依赖规模等关键维度。模块定位CI 上的内部度量工具bench是 Tauri 仓库中的一个独立 Rust crate包名为tauri_bench见 bench/Cargo.toml其定位非常明确运行环境CI持续集成流水线而非本地开发者工具产出目标提供 Tauri 的内部度量internal metrics结果汇聚到独立的benchmark_results仓库进行发布与追踪使用边界README 明确标注**\*_Internal use only_**即该模块服务于 Tauri 项目自身的工程质量保障不面向外部应用开发者作为通用基准工具。从源码结构看该 crate 定义了两个二进制见 bench/Cargo.toml二进制名入口文件职责run_benchmarkbench/src/run_benchmark.rs实际执行全部基准测试采集指标并生成bench.json结果文件build_benchmark_jsonsbench/src/build_benchmark_jsons.rs将最新一次结果追加到历史数据集中生成全量与最近 20 条两份 JSON两个二进制共享 bench/src/utils.rs 中的工具函数与数据结构并依赖anyhow错误处理、serde/serde_json结果序列化、timeRFC3339 时间戳、tempfile临时文件等 crate。三个基准场景从最小启动到数据密集传输get_all_benchmarksbench/src/run_benchmark.rs定义了三个被度量的示例应用它们分别对应三类典型负载1. tauri_hello_world —— 最小应用启动对应 bench/tests/helloworld/src-tauri/src/main.rs应用仅注册一个app_loaded_successfully命令Web 页面加载完成后立即调用它使进程退出std::process::exit(0)。该场景度量的是最简 Tauri 应用从进程启动到 WebView 就绪并完成一次 IPC 往返的完整耗时是框架启动路径开销的底线指标。值得注意的是源码中特意注释了// The benchmark cant use this or we cant measure the command time即不能启用windows_subsystem windows隐藏控制台窗口否则hyperfine无法捕获命令完成时机——这是基准设计对度量精确性的一个细节约束。2. tauri_cpu_intensive —— WebView 内计算密集型任务对应 bench/tests/cpu_intensive/src-tauri/src/main.rs 及其前端 bench/tests/cpu_intensive/public/site.js前端在DOMContentLoaded后创建一个 Web Workerbench/tests/cpu_intensive/public/worker.js在THRESHOLD 10_000_000范围内逐个执行素数判断isPrime每 250ms 通过postMessage回报进度计算完成后通过window.__TAURI__.core.invoke(app_completed_successfully)通知 Rust 侧由app_completed_successfully命令调用std::process::exit(0)结束进程。该场景度量的是基于系统 WebView 的 JS 引擎执行重计算任务的吞吐能力用于观察不同平台 WebView 内核如 macOS WKWebView、Windows WebView2、Linux WebKitGTK在相同算法负载下的性能差异。3. tauri_3mb_transfer —— IPC 大数据传输对应 bench/tests/files_transfer/src-tauri/src/main.rsRust 侧注册了异步命令read_file通过app.path().resolve(.tauri_3mb.json, BaseDirectory::Home)读取用户主目录下约 3 MB 的 JSON 测试文件并以Response::new(contents)直接返回二进制内容前端bench/tests/files_transfer/public/index.html调用invoke(read_file)读取成功后再以退出码 0 或 1 调用app_should_close结束进程。该场景度量的核心是Rust 后端与 WebView 前端之间的 IPC 通道在传输 MB 级数据时的吞吐与延迟是 Tauri IPC 协议层性能的直接反映。测试数据文件json_3mb.json会在基准运行时自动下载到用户主目录详见下文准备阶段。run_benchmark完整基准流程剖析bench/src/run_benchmark.rs 的main函数按固定顺序执行六步采集最终将结果序列化为bench.json并通过 BENCHMARK RESULTS标记输出到 stdout 供 CI 捕获。准备阶段获取测试数据并定位目标目录let json_3mb utils::home_path().join(.tauri_3mb.json); if !json_3mb.exists() { println!(Downloading test data...); utils::download_file(3MB 测试数据 URL, json_3mb)?; }通过 bench/src/utils.rs 的download_file下载 3 MB 测试数据若 URL 非 http/https 则退化为直接文件复制。随后env::set_current_dir(utils::bench_root_path())将工作目录切到 bench crate 根保证后续strace、mprof、hyperfine等外部工具以相对路径解析示例可执行文件。第一步执行时间hyperfinerun_exec_timebench/src/run_benchmark.rs调用hyperfine对三个示例二进制进行计时关键参数--export-json导出结构化结果、--warmup 3预热 3 次、--prepare sleep 1每次运行前休眠 1 秒注释说明是避免 macOS/Windows 上连续运行导致执行时间递增的系统级干扰Windows 特判--shell powershell否则cmd无法执行sleep 1重定向结果过滤仅保留[mean, stddev, user, system, min, max]六个统计键见RESULT_KEYS常量按示例名存入exec_time。第二步二进制体积get_binary_sizesbench/src/run_benchmark.rs采集两类体积三个示例应用 release 二进制的文件大小fs::metadata().len()核心渲染库wry的 rlib 静态库体积rlib_sizebench/src/run_benchmark.rs遍历target/target/release/build/wry/*/out目录累加所有libwry-*.rlib文件大小同一 crate 前缀去重——该指标用于追踪 WebView 适配层在 Rust 依赖链中的静态体积变化。第三步Cargo 依赖规模cargo_depsbench/src/run_benchmark.rs遍历TARGETS中列出的所有目标三元组详见下文平台覆盖对每个目标执行cargo tree --no-dedupe --edges normal --prefix none --target triple统计输出的唯一行数减去 wry 自身一行作为该目标的依赖数量并取同一 OS 下所有目标中的最大值写入结果若计数小于等于 10 会打印Warning: dependency count ... seems low警告用于早期发现依赖图异常如被意外裁剪。第四步仅 Linux系统调用与线程数stracerun_strace_benchmarksbench/src/run_benchmark.rs在 Linux 上执行strace -c -f -o 临时文件 示例可执行文件随后用 bench/src/utils.rs 的parse_strace_output解析strace -c的汇总表得到每个系统调用名对应的percent_time时间占比、seconds、usecs_per_call每次调用微秒、calls调用次数、errors错误次数。其中syscall_count total 行的调用次数总和thread_countclone与clone3两个系统调用次数之和作为进程创建线程数的代理指标。第五步仅 Linux内存峰值mprofrun_max_mem_benchmarkbench/src/run_benchmark.rs执行mprof run -C -o 输出文件 示例可执行文件然后由parse_max_membench/src/utils.rs逐行解析mprof输出的时间 内存MB三元组空格分隔且恰好 3 段的行将 MB 换算为字节并取最大值作为该应用的内存峰值max_memory解析完毕后删除临时文件。第六步结果组装与输出let mut new_data utils::BenchResult { created_at: /* RFC3339 UTC 时间戳 */, sha1: /* git rev-parse HEAD 取当前提交哈希 */, exec_time, binary_size, cargo_deps, ..Default::default() };Linux 平台额外填充thread_count、syscall_count、max_memory。最终以serde_json::to_writer_pretty将完整结果输出到 stdout并用 BENCHMARK RESULTS与 /BENCHMARK RESULTS标记包裹方便 CI 脚本正则截取同时写入target/target-triple/release/bench.json见 bench/src/run_benchmark.rs。结果数据结构BenchResultbench/src/utils.rs 定义了所有指标的载体BenchResult其字段即基准体系的完整清单pub struct BenchResult { pub created_at: String, // 运行时间RFC3339 pub sha1: String, // 被测提交哈希 pub exec_time: HashMapString, HashMapString, f64, // hyperfine 六项统计 pub binary_size: HashMapString, u64, // 二进制与 wry rlib 体积字节 pub max_memory: HashMapString, u64, // Linuxmprof 内存峰值字节 pub thread_count: HashMapString, u64, // Linuxclone/clone3 次数 pub syscall_count: HashMapString, u64, // Linux系统调用总数 pub cargo_deps: HashMapString, usize, // 各 OS 依赖数量最大值 }其中exec_time的键为mean/stddev/user/system/min/max与RESULT_KEYS常量一一对应各HashMap的键统一使用tauri_hello_world、tauri_cpu_intensive、tauri_3mb_transfer三个场景名保证历史数据的横向可比性。build_benchmark_jsons历史数据聚合CI 在每次run_benchmark之后运行build_benchmark_jsonsbench/src/build_benchmark_jsons.rs完成数据归档读取本次运行生成的target/triple/release/bench.json作为current_data读取仓库根gh-pages/目录下按平台命名的历史数据tauri-data-platform.json其中 platform 通过cfg!(target_os)判定为macos/windows/linux将current_data追加到全量数组all_data若全量数据超过 20 条截取最近 20 条作为recentall_data[all_data.len() - 20..]分别写回tauri-data-platform.json全量与tauri-recent-platform.json最近 20 条。这份全量 最近 20 条的双 JSON 设计既保留了完整的演进曲线又为趋势图提供了固定窗口的轻量数据源是benchmark_results仓库可视化页面的直接数据基础。平台与目标三元组覆盖基准在平台识别上做了细致区分运行平台判定cfg!(target_os)将当前环境映射为macos/windows/linux同时用于gh-pages数据文件名与是否执行 Linux 专属指标strace、mprof的开关见 bench/src/run_benchmark.rs依赖分析目标集TARGETS常量bench/src/run_benchmark.rs覆盖 Windows4 个 triple、Linux3 个 triple、macOS2 个 triple用于cargo tree --target的跨目标依赖统计本地编译目标get_targetbench/src/utils.rs按当前平台返回默认 triple如 Linux 为x86_64-unknown-linux-gnu决定target/triple/release目录与示例可执行文件路径Windows 上示例名会追加.exe扩展名见get_all_benchmarks中的extension处理。运行前提与限制说明该模块面向 CI 运行本地复现需要满足以下前提均以当前仓库源码为准已安装外部工具hyperfine计时、straceLinux 系统调用、mprofLinux 内存、curl下载测试数据、cargo依赖分析先编译三个示例应用的 release 版本bench_helloworld、bench_cpu_intensive、bench_files_transfer对应各 bench/tests/*/src-tauri/Cargo.toml 中的包名产物位于target/triple/release/首次运行需联网下载 3 MB 测试数据至用户主目录~/.tauri_3mb.jsonWindows 为USERPROFILEstrace与mprof指标仅 Linux 平台采集macOS/Windows 只产出执行时间、二进制体积与依赖数据示例应用刻意未启用windows_subsystem windows隐藏窗口属性以保证命令行进程可被计时工具捕获源码注释明确说明该权衡。版本语义与许可Tauri 主项目遵循 Semantic Versioning 2.0。bench 模块作为仓库组成部分与整体保持 Apache-2.0 OR MIT 双许可见 bench/Cargo.toml 的license字段与各源码文件头部的 SPDX 标识代码版权归 The Tauri Programme within The Commons Conservancy。小结bench模块是 Tauri 工程化质量保障体系中的一个闭环三个精心设计的示例应用覆盖最小启动、WebView 计算、IPC 大数据传输三类核心路径run_benchmark用hyperfine/strace/mprof/cargo tree采集时间、体积、系统调用、内存与依赖六类指标build_benchmark_jsons完成按平台归档与最近 20 条滑动窗口的数据沉淀最终通过 CI 输出到独立的benchmark_results仓库形成可追踪的长期趋势。虽然 README 明确其仅限内部使用但它为任何基于 WebView 的跨平台框架建立持续性能监控体系提供了一个结构清晰、指标可扩展的参考范本——这正是 Tauri 得以在版本迭代中持续守住小、快、安全承诺的度量基石。赞分享桌面应用跨平台移动开发【免费下载链接】tauriBuild smaller, faster, and more secure desktop and mobile applications with a web frontend.项目地址https://gitcode.com/GitHub_Trending/ta/tauri点击查看免费下载相关推荐Lance CI 基准测试体系详解IO/内存基准的编写、运行与结果分析Lance CI 基准测试体系详解IO/内存基准的编写、运行与结果分析 导读 本篇文章围绕 Lance 仓库中 python/python/ci_benchm数据库向量数据库数据湖全文检索uv 基准测试体系深入 crates/uv-bench 的 Criterion 微基准、合成工作区与 CodSpeed CI 集成uv 基准测试体系深入 crates/uv bench 的 Criterion 微基准、合成工作区与 CodSpeed CI 集成 uv 的性能主张快速解析包管理器开发工具CLIChainlink 集成测试体系解析基于 CTF 框架的测试配置、Docker/Kubernetes/CI 三种运行模式与源码级实践Chainlink 集成测试体系解析基于 CTF 框架的测试配置、Docker/Kubernetes/CI 三种运行模式与源码级实践 本文基于 Chainli区块链Web3后端上一篇GtkRadiant游戏地图设计终极指南轻松创建专业级游戏关卡下一篇Visual Studio Code JavaScript调试器常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考