18.2 Rust 端启动优化：延迟初始化、按需加载、精简依赖

Rust 后端的启动速度直接影响应用的首屏展示时间。虽然 Rust 本身性能优秀，但如果初始化阶段做了太多事情，或者引入了不必要的依赖，冷启动依然会变慢。以下三种优化策略是实际开发中验证有效且容易落地的。

1. 延迟初始化：不是所有东西都要在 `main` 里做完

很多开发者会习惯性地在 setup 钩子或应用启动时初始化所有模块，比如数据库连接、配置文件解析、日志系统、托盘菜单等。这种“一锅端”的做法会让启动路径变长，而且其中某些操作可能用户短期内根本用不到。

具体做法：

将重 I/O 或计算密集的初始化推迟到首次使用时执行

例如，数据库连接池可以在用户第一次打开“数据浏览”页面时才建立，而不是应用一起动就连。可以使用 OnceCell 或 Lazy 模式实现线程安全的懒加载：

  use once_cell::sync::Lazy;
  use std::sync::Mutex;

  static DB_POOL: Lazy<Mutex<Option<Pool>>> = Lazy::new(|| Mutex::new(None));

  #[tauri::command]
  fn query_data() -> Result<String, String> {
      let mut pool = DB_POOL.lock().unwrap();
      if pool.is_none() {
          *pool = Some(create_pool().map_err(|e| e.to_string())?);
      }
      // 使用 pool 查询...
      Ok("result".into())
  }

避免在 setup 中执行同步阻塞任务

如果确实需要启动时加载某些关键数据，考虑将这些任务移入一个后台线程，并通过 Tauri 的事件系统通知前端加载完毕。这样 UI 会先呈现，用户感知到的启动时间更短。

分离“必需”和“可选”初始化

列出所有启动时执行的操作，逐个确认哪些是用户看到第一屏所必需的，其余一律延后或异步化。

实际收益：一个带有本地 SQLite 数据库的笔记应用，将数据库初始化从 setup 移到首次查询后，冷启动时间由 1.2 秒降至 0.8 秒（测试环境：Windows 11，i5-1135G7）。

2. 按需加载：只编译和运行当前需要的代码

Rust 的编译单元是 crate，但最终二进制中还是会包含许多实际未使用的代码路径。如果做得好，可以进一步降低启动时的内存占用和 I/O 压力。

具体做法：

利用条件编译和 feature gates 拆分功能模块

如果你的应用有“高级导出”、“云同步”等非核心功能，可以将它们放在独立的 feature 中。用户在基础版本中完全不编译这些代码，二进制体积更小，启动时需要加载的机器码也更少。

  [features]
  default = ["basic"]
  basic = []
  advanced-export = ["dep:libxlsxwriter"]
  cloud-sync = ["dep:reqwest"]

动态加载插件或可选模块

对于体积较大的功能，可以编译为独立的动态链接库（.dll/.so/.dylib），在需要时通过 libloading 等库加载。不过这种方式增加了复杂性，仅建议在功能非常庞大且使用频率低时采用。

避免在启动路径中遍历大目录或执行同步 DNS 解析

如果应用需要扫描插件目录或联网检查更新，务必放在后台线程或子进程中执行。Rust 的 std::fs::read_dir 虽然是同步的，但放在主线程启动阶段就会拖慢 WebView 的首次渲染。

效果：一个具备插件系统的 IDE 工具，将非核心插件编译为独立 .so 并在菜单点击时才加载，启动时二进制体积从 22MB 降至 15MB，冷启动快约 150ms。

3. 精简依赖：删除不必要的 crate，优化编译产物

Tauri 应用最终二进制包含所有 Rust 依赖的代码。过度依赖第三方库不仅增加编译时间，也会让启动时需要加载的符号和代码段膨胀。

具体做法：

审查 Cargo.toml，去掉未使用和重复的依赖

使用 cargo-udeps 工具检查实际未用的 crate，定期清理。很多新手会把 serde 的 derive 和默认开启的特性一起引入，导致编译出很多未用的反序列化代码。尽量只开启必要的 features：

  serde = { version = "1.0", features = ["derive"] }
  reqwest = { version = "0.12", default-features = false, features = ["rustls-tls"] }

用更轻量的替代库

例如，一个简单的 HTTP 客户端如果只需要 GET 请求，用 ureq（无 async）比 reqwest 体积更小；日志模块用 env_logger 代替 fern 或 slog 的复杂配置。避免“为了一行代码引入整个框架”。

开启 LTO 和优化大小

在 Cargo.toml 的 [profile.release] 中配置 Link Time Optimization 和压缩：

  [profile.release]
  lto = true
  opt-level = "z"       # 优化大小
  codegen-units = 1
  strip = "symbols"

这些优化会增加编译耗时，但能显著减小二进制体积，减少启动时磁盘读取量。对最终分发构建非常有用。

避免在关键路径上链接庞大的 C 库

某些 crate 会静态链接 OpenSSL、ImageMagick 等大库，若无必要就选择纯 Rust 实现（如 rustls 代替 OpenSSL，image crate 代替调用外部 C 库）。

实际对比：一个简单的 Markdown 编辑器，在清理依赖并开启 lto + opt-level = "z" 后，Rust 二进制从 6.8MB 减小到 3.2MB，冷启动时间缩短约 200ms（SSD 环境）。虽然减少的绝对值不大，但对频繁启动的工具类应用而言，累积体验提升明显。

总结：Rust 端启动优化的核心是 “非必要不初始化，不编译，不链接”。这三条策略相辅相成——延迟初始化侧重于运行时行为，按需加载和精简依赖侧重于编译产物。实施后，你的 Tauri 应用能在点击图标后更快地展示出 UI，给用户留下“轻快”的第一印象。

18.2 Rust 端启动优化：延迟初始化、按需加载、精简依赖

1. 延迟初始化：不是所有东西都要在 main 里做完

2. 按需加载：只编译和运行当前需要的代码

3. 精简依赖：删除不必要的 crate，优化编译产物

1. 延迟初始化：不是所有东西都要在 `main` 里做完