8.4 启动与运行性能优化

出厂前的最后一关不是功能而是手感：双击图标到可交互要多久、开一下午内存涨了多少、操作卡不卡。本节给性能工作一套可复现的方法：先测量（链路上的测量点与工具）、再定位（高频问题的归因路径）、后优化（按收益排次的清单）。读完本节，性能优化从"听说要懒加载"变成一张有数字的验收单。

先测量：启动链路与观测点

没有测量的优化是玄学。把"双击图标到界面可交互"拆成可观测的四段：进程启动（原生代码装载）→ Setup 钩子（你的同步初始化）→ 窗口创建与页面加载（WebView 起来、加载首屏资源）→ 前端就绪（框架挂载、首屏数据返回）。观测方法按段配：前两段用日志打点（芯侧 println 或 log 插件，记录各钩子进出时刻）；第三段看 WebView 开发者工具的 Network 面板（首屏资源量与瀑布）；第四段用 Performance 面板录一次首屏（渲染与脚本耗时）。各段打一次基线数字记在案，之后每次改动对比同一测量法——同一把尺子量到底。

图 8-3：性能问题定位路径

启动优化：三招覆盖九成

招一：Setup 减负。 2.4 定的纪律在此兑现：同步初始化只留"必须先于首帧"的项（窗口属性、核心状态），数据库连接、索引重建、设置迁移全部 async_runtime::spawn 异步化。判断标准一句话：晚十毫秒可见的东西，就不该挡在首帧前面。

.setup(|app| {
    // 必须先于首帧：主窗属性与核心状态，同步做
    let notes = NoteStore::open_or_create()?;
    app.manage(Mutex::new(notes));

    // 不挡首帧：索引重建与设置迁移，异步做
    let handle = app.handle().clone();
    tauri::async_runtime::spawn(async move {
        if let Err(e) = rebuild_index(&handle).await {
            eprintln!("索引重建失败，稍后重试: {e}");
        }
    });
    Ok(())
})
​

异步化的纪律别漏两条：后台任务失败不能静默吞掉（至少留日志与重试入口），且任务若依赖应用状态，用 AppHandle 在任务内部再取——不要在闭包外长时间借用。

一次实测：随身笔记的启动瘦身

方法落到实处才有说服力。走一遍随身笔记的完整验收：先按四段法打点测基线，冷启动五次取中位数，数字如下（量级示意）：

解读这张表：大头在 Setup 的 900 毫秒——正是"把所有初始化都写进同步钩子"的惯性账；异步化这一项零风险、半小时，拿走了总耗时的一半。首屏加载的 380 毫秒节省里，分包贡献最大，字体子集化次之。而表格最后一行从 2.1 秒到 0.7 秒，用户主观感受跨过的是"明显等待"与"即时响应"的分界线。实测还有个副产品：打点日志留了下来，此后每次发版顺手记录启动数字，性能回归在出厂前就会被抓到，而不是等用户评论区长篇控诉。

招二：首屏减重。 前端侧的路由分包与按需加载（框架标准能力），让首帧只带首屏代码；首屏接口合并——开屏要的"列表加设置加用户信息"合成一个命令返回，减少过桥往返（2.1 序列化边界的老朋友）。首屏资源瘦身：字体子集化、图片压缩与懒加载。

招三：别给自己挖坑。 更新检查不在启动路径上同步跑（8.3 定过）；日志初始化轻量；开发期与生产期的启动差异要分开测——dev 模式带热更新服务，不能代表出厂手感。

运行期：内存与卡顿的两个高频根因

根因一：监听器泄漏。 4.3 的三军规在这里变成排查动作：Memory 面板抓三次快照（加载、操作二十次、再操作二十次），对比增长曲线；增长源头常是未退订的 listen 与未清理的定时器。现象特征明显——"每点一次按钮，事件回调多执行一遍"。

根因二：事件风暴。 芯侧高频事件（文件监视、进度推送）直接灌前端，渲染压力骤增。解法组合在芯：攒批（每 N 条或每 M 毫秒合并推送）、节流（定时器窗口内只发最新值）、负载裁剪（推送差量不是全量）。前端侧配套：高频更新的界面只更新变化项，避免整列表重渲染。

优化次序表

按性价比排好的动手顺序：一，Setup 异步化（零风险高收益，半小时）；二，首屏分包与接口合并（半天，收益立竿见影）；三，监听器与定时器审计（防恶化，性能问题的止损点）；四，事件攒批节流（高频场景才需要）；五，编译与包体瘦身（8.2 的清单，收益在分发不在运行）。前两项做完，多数应用已从"能用"到"顺滑"；后面的按实测数字决定要不要做——没有数字，不做优化。

三个反模式：越努力越卡

性能工作的另一面是不做无效功，三个高频反模式先列出来避坑。**反模式一：过早微优化前端。**把力气花在重排重绘的微观调整上，而瓶颈其实在芯侧的一次同步 I/O——测量数据不支持的方向，改得再勤也是原地踏步。**反模式二：无上限的缓存。**给列表、图片、查询结果全部加缓存，内存曲线变成只涨不跌的台阶；缓存要有淘汰策略（条数上限或时间窗），"缓存一切"是内存问题的加速器而非解药。反模式三：把优化押在一次大重构上。"等我们重写渲染层就好了"是性能会议上的经典句子，而验收数字只认小步实测——按上面的次序表逐项做、逐项量，两周的小步通常胜过一个季度的豪赌。

本节要点回顾

• 启动四段测量：进程、Setup、加载、就绪，分段打点同尺对比；
• 启动三招：Setup 异步化、首屏减重合并接口、不在启动路径挖坑；
• 内存泄漏头号根因是监听器未退订，快照对比定位；
• 事件风暴芯侧治：攒批、节流、差量推送；
• 优化次序表：Setup 减负 → 首屏减重 → 泄漏审计 → 事件节流 → 包体瘦身，动手前先有数字。

全书八章至此合卷：从壳与芯的装配观出发，经图纸、备料、装壳、造芯、上锁、领件，到出厂、上路、验收——一套完整的 Tauri 装配手册交到你手上。下一步在你：打开终端，把第 3 章的第一条命令敲进去。