原创作者：庄晓立（LIIGO）
原创时间：2025年03月10日（发布时间）
原创链接：https://blog.csdn.net/liigo/article/details/146159327
版权所有，转载请注明出处。
20250310 LIIGO备注：本文源自系列文章第1篇《初次体验Tauri和Sycamore (1)》，从中抽取出来独立成文（但并无更新和修订），专注于探究Tauri通道的底层实现（实际上也没有足够底层）。理由：1.原文已经很长，需要精简；2.原文主体是初级技术内容，仅这一节相对深入，显得格格不入。（如无意外，这将是本系列文章的终结。）
20241118 LIIGO补记：出于好奇，简单研究一下Tauri通道的底层实现。
在JS层，创建Channel对象生成通道ID，并关联onmessage处理函数；在传输层，通过invoke()调用后端Command，传入Channel对象作为参数（实质上是传入通道ID）；在Rust层，根据通道ID构造后端Channel对象，向客户端指定的Channel发送Message。如何向通道发送Message是后续关注的重点。
JS层创建Channel的源码如下：
class Channel<T = unknown> {id: number// @ts-expect-error field used by the IPC serializerprivate readonly __TAURI_CHANNEL_MARKER__ = true#onmessage: (response: T) => void = () => {// no-op}#nextMessageId = 0#pendingMessages: Record<string, T> = {}constructor() {this.id = transformCallback(({ message, id }: { message: T; id: number }) => {// the id is used as a mechanism to preserve message orderif (id === this.#nextMessageId) {this.#nextMessageId = id + 1this.#onmessage(message) // 前端用户收到此message// process pending messages// ...} else {this.#pendingMessages[id.toString()] = message}});}// ...
}function transformCallback<T = unknown>(callback?: (response: T) => void, once = false): number {return window.__TAURI_INTERNALS__.transformCallback(callback, once)
}
JS层Channel构造函数内部，调用transformCallback为一个回调函数生成唯一ID（它基于Crypto.getRandomValues()的实现能保证ID唯一吗我存疑），并将二者关联至window对象：window['_回调ID'] = ({message, id})=>{ /*...*/};。此处生成的ID也称为通道ID，将被invoke函数传递给Rust层（参见上文前端调用Command）。后端数据通过通道到达前端后，可通过通道ID反查并调用该回调函数接收后端数据。注意区分通道ID、消息ID和后文的数据ID。
Rust层通过JavaScriptChannelId::channel_on和Channel::new_with_id构造Channel对象实例。
impl JavaScriptChannelId {/// Gets a [`Channel`] for this channel ID on the given [`Webview`].pub fn channel_on<R: Runtime, TSend>(&self, webview: Webview<R>) -> Channel<TSend> {let callback_id = self.0;let counter = AtomicUsize::new(0);Channel::new_with_id(callback_id.0, move |body| {let i = counter.fetch_add(1, Ordering::Relaxed);if let Some(interceptor) = &webview.manager.channel_interceptor {if interceptor(&webview, callback_id, i, &body) {return Ok(());}}let data_id = CHANNEL_DATA_COUNTER.fetch_add(1, Ordering::Relaxed);webview.state::<ChannelDataIpcQueue>().0.lock().unwrap().insert(data_id, body);webview.eval(&format!("window.__TAURI_INTERNALS__.invoke('{FETCH_CHANNEL_DATA_COMMAND}', null, {{ headers: {{ '{CHANNEL_ID_HEADER_NAME}': '{data_id}' }} }}).then((response) => window['_' + {}]({{ message: response, id: {i} }})).catch(console.error)",callback_id.0))?;Ok(())})}
}
Channel::new_with_id有两个参数，一个是通道ID（或称callback_id），一个是向前端发送数据的on_message函数。这个on_message的命名有误导性，让人以为是接收函数，但看Channel::send()函数源码可以确认on_message是发送函数。
impl<TSend> Channel<TSend> {fn new_with_id<F: Fn(InvokeResponseBody) -> crate::Result<()> + Send + Sync + 'static>(id: u32,on_message: F,) -> Self {// ...}/// Sends the given data through the channel.pub fn send(&self, data: TSend) -> crate::Result<()> where TSend: IpcResponse, {(self.on_message)(data.body()?)}
}
Rust层Channel发送数据的实现代码就在上面JavaScriptChannelId::channel_on(webview)函数内部，即new_with_id()的on_message参数闭包函数内，它主要干了如下几件事：
- 生成数据ID(data_id)：
let data_id = CHANNEL_DATA_COUNTER.fetch_add(1, Ordering::Relaxed); - 将要数据存入发送缓存队列并关联data_id：
webview.state::<ChannelDataIpcQueue>()...insert(data_id, body) - 生成JS代码并提交给前端执行（分两步）：
webview.eval(JSCODE)- fetch:
invoke('plugin:__TAURI_CHANNEL__|fetch', null, ...data_id...) - callback:
window['_通道ID']({ message: response, id: {i} })(调用JS端回调函数,{i}为此通道内消息ID，即序号)
- fetch:
再看一下fetch源码（上文invoke('plugin:__TAURI_CHANNEL__|fetch', ...)将调用此后端Command）：
#[command(root = "crate")]
fn fetch(request: Request<'_>,cache: State<'_, ChannelDataIpcQueue>,
) -> Result<Response, &'static str> {if let Some(id) = request.headers().get(CHANNEL_ID_HEADER_NAME).and_then(|v| v.to_str().ok()).and_then(|id| id.parse().ok()){if let Some(data) = cache.0.lock().unwrap().remove(&id) {Ok(Response::new(data))} else {Err("data not found")}} else {Err("missing channel id header")}
}
fetch命令的作用是从发送缓存队列中取出与参数data_id关联的数据返回给前端，同时从发送缓存队列中移除。fetch执行后，通过通道发送的数据就从后端到了前端。注意时序，是后端主动提交JS代码让前端执行，前端才被动发起fetch调用，Tauri正是通过这种方式实现后端向前端“推送”数据。数据被推送至前端后，可能还要经历缓存阶段才提交给Channel用户，确保用户有序接收。
调用链：（JS层）创建Channel，发起调用后端某Command（传入通道ID），（Rust层）把通道ID反序列化为Channel，将待发送数据缓存，调度前端执行JS代码（webview.eval()），（JS层）通过fetchCommand拉取后端缓存数据，处理乱序数据接收，执行用户层onmessage回调，完成单次数据传输。
我原来猜测通道Channel是Command之外另一种更高效的数据传输方案，但事实证明我错了。通过上述源码分析可知，Channel实际上是基于Command实现的更高层的逻辑抽象。Tauri通道发送数据，本质上还是调用Command，只是经过封装之后更适合“后端推送流式数据”应用场景。相比使用普通无通道Command传输数据，其区别在于工作模式：无通道传输，是前端单次主动拉取；有通道传输，是后端多次主动推送，且保证有序送达。
