最近在 macOS 上开发 Tauri 桌面应用，遇到一个启动白屏的问题：运行 tauri dev 后，窗口很快打开，但要等几秒才进入登录页。

前言

项目使用 React + Vite 开发前端，通过 Tauri 构建桌面应用。当时的开发环境：

• macOS 15.5（24F74）
• Safari 18.5（WebKit 20621.2.5.11.8）
• Tauri 2.12.4、tauri-runtime-wry 2.12.2、Wry 0.57.0

一开始怀疑是前端资源加载慢，就把主界面和更新弹窗改成按需加载。同时在 index.html 里加了“正在启动…”占位，这部分内容不依赖 JavaScript。调整后，启动时需要加载的代码减少了，白屏却没什么变化。

反而 “正在启动…” 刚显示出来，页面就进入了登录界面。

在「Rust 学习笔记 - mpsc 与消息通信」中，通过 tokio::spawn 创建了一个负责发送消息的异步任务。当时主要学习任务之间的消息通信，这里继续展开任务本身的执行、等待和退出。

前言

1
2
3
4
5
6
7
8

let agent_task = tokio::spawn(agent.run());

handle("login", &out_tx);

// 释放主任务的发送端
drop(out_tx);

agent_task.await.unwrap();

这里通过 tokio::spawn 创建任务，最后又通过 agent_task.await 等待它结束。这两个操作分别做了啥？

在「Rust 学习笔记 - Future、Waker 与异步任务调度」中提到过，Future 可以看作一个状态机。它会保存当前执行到了哪里、后续需要哪些局部变量，以及正在等待什么。

前言

async/await 可以让异步代码看起来像普通的顺序代码：

1
2
3
4
5
6
7
8
9

use tokio::time::{sleep, Duration};

async fn run() {
    println!("start");

    sleep(Duration::from_secs(1)).await;

    println!("finished");
}

这段代码先输出 start，等待 1 秒后再输出 finished。等待期间，run() 对应的 Future 会返回 Poll::Pending，执行到这里暂停。

定时器到期后，运行时会再次调用这个 Future 的 poll。这次不会重新输出 start，而是从 sleep(...).await 后面继续执行。

那么，Future 是怎么记住上次执行到哪里呢？

在「Rust 学习笔记 - Future、Waker 与异步任务调度」中实现异步任务执行器 block_on 时，用到了 Pin 来保证某些值在内存中不被移动，想着展开学习一下。

什么是值的移动

Rust 中的值默认可以移动。移动通常发生在赋值、传参和从函数返回时，例如：

1
2
3
4
5

let name = String::from("hallo");
let other = name;

// println!("{}", name); // error: borrow of moved value: `name`
println!("{}", other);

这里不是把 String 中的文本复制了一份。name 持有的值被转移给 other，之后也不能再通过 name 访问它。对于 String 这类普通类型，移动通常不需要关心它在内存中的具体位置。只要所有权完成转移，内部管理的堆内存仍然可以正常释放和访问。

异步任务可以理解成一段能够暂停和继续执行的代码。在 Rust 中任务的暂停和恢复，主要和 Future、poll、Waker 这些概念有关。

前言

很多语言都提供了异步编程的能力，本质上就是在“等结果”的这段时间里，不让线程白白挂住。像 C# 里有 Task 和 async/await，JavaScript 里有 Promise 和 async/await，目的都差不多，就是想让异步逻辑写起来不要那么蛋疼。

Rust 也有 async/await，但它背后的实现思路和其他语言不完全一样。比如下面这个异步函数：

1
2
3

async fn hallo() {
    println!("hallo");
}

调用 hallo() 时，并不会立刻执行完整个函数，而是先返回一个 Future。

mpsc 是 multiple producer, single consumer 的缩写，表示多个发送端、一个接收端。它是一种常见的消息通信模型：多个地方可以把消息发送到同一个 channel 中，再由一个接收方按顺序取出并处理。

前言

写服务端时，很多模块都可能需要给同一个客户端发消息。比如登录回包、消息广播、系统通知，甚至定时任务产生的推送。如果这些模块都直接操作连接对象，代码很容易碰到借用和并发访问的问题，连接本身也会变得难以维护。

一种更自然的做法是，让连接只由一个地方持有，其他模块只负责投递消息，再由持有连接的任务统一写出。mpsc 适合解决的，正是这类“多处发送、单点处理”的通信问题。

标准库的 mpsc

先看一个简单的例子：

1
2
3
4
5
6
7
8
9
10
11

use std::sync::mpsc;

fn main() {
    let (tx, rx) = mpsc::channel();

    tx.send(String::from("hallo")).unwrap();

    let message = rx.recv().unwrap();
    println!("received: {}", message);
    // received: hallo
}

最近在使用 Rust 重写一些老项目时，经常会碰到 Arc、RwLock、Mutex 以及 RefCell 这些类型。它们都和“共享”或“可变”有关，这里简单整理一下它们的区别和常见使用场景。

前言

假设现在设计一个在线用户管理模块，并且需要支持通过编号获取对应的用户实例，看起来这个需求不复杂，但如果再往前走一步，就会发现后面很快会碰到共享所有权和内部状态修改的问题。

先看一个最简单的版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

pub struct User {
    pub id: u64,
    pub email: String,
}

pub struct UserMgr {
    users: HashMap<u64, User>,
}

impl UserMgr {
    pub fn new() -> Self {
        Self {
            users: HashMap::new(),
        }
    }

    pub fn get(&self, id: u64) -> Option<&User> {
        self.users.get(&id)
    }

    pub fn add(&mut self, user: User) {
        self.users.insert(user.id, user);
    }

    pub fn remove(&mut self, id: u64) {
        self.users.remove(&id);
    }
}

一开始这样写没什么问题，UserMgr 负责保存用户，通过 id 取出来就行了。

Deque（Double-Ended Queue，双端队列）是一种允许在头尾两端进行插入和删除的线性数据结构。

前言

从定义上来看，Deque 只是比 Queue 多了一端的操作能力。但与 Queue 不同的是，Deque 同时具备 Stack 和 Queue 的访问模式，因此在需要灵活处理头尾两端元素的场景中广泛应用。

它们之间的区别很直观：

Queue: FIFO（First In, First Out，先进先出）

Deque: FIFO / LIFO（先进先出 / 后进先出）