【Tauri2】37——后端处理invoke
目录
前言
正文
随便看看
看看get
看看parse_invoke_request
看看message_handler
看看handle_ipc_message
看看webview的on_message方法
第一种情况的处理
第二种情况的处理
运行通信函数
返回的处理
整个流程
前言
【Tauri2】033 __TAURI_INTERNALS__和invoke-CSDN博客文章浏览阅读1k次，点赞24次，收藏24次。前面说过许多关于的invoke的事情，有通信函数，fetch、invoke_key等这些。这篇再来看看关于invoke的东西看来内部的通信是通过window.__TAURI_INTERNALS__对象来实现的。注册通过函数用了声明宏。笔者发现看github上的源码，比看打包后的源码更清晰，以后就使用github上的tauri的源码了，不错。哈哈哈哈t=P1C7t=P1C7t=P1C7t=P1C7t=P1C7t=P1C7t=P1C7。https://blog.csdn.net/qq_63401240/article/details/147523382?spm=1001.2014.3001.5502前面介绍了前端invoke本质就是通过fetch发送一个post请求。
发送过去后，在后端是如何处理请求，如何调用并返回结果？
这篇就来看看这个核心的问题
正文
随便看看
解析请求核心源代码如下——protocol.rs
tauri/crates/tauri/src/ipc/protocol.rs at dev · tauri-apps/tauri
https://github.com/tauri-apps/tauri/blob/dev/crates/tauri/src/ipc/protocol.rsprotocol.rs主要的方法
看名字，简单说说
message_handler，消息处理器，不知道干什么
get：得到，得到什么，直觉认为，应该得到请求。
handle_ipc_message ：处理ipc消息，干什么，后面再说。
parse_invoke_message：解析invoke消息。
而且，get方法和message_handler方法是pub的
这个pub就非常有趣了。
pub说明可能会被调用，只能可能，不一定。
因此，在github中的tauri源码中搜索一下
repo:tauri-apps/tauri ipc::protocol
结果如下
居然搜到了，进去看看
tauri/crates/tauri/src/manager/webview.rs at dev · tauri-apps/taurihttps://github.com/tauri-apps/tauri/blob/dev/crates/tauri/src/manager/webview.rs在里面，笔者发现了更多东西
在如下代码调用了get方法
if !registered_scheme_protocols.contains(&"ipc".into()) {let protocol = crate::ipc::protocol::get(manager.manager_owned());pending.register_uri_scheme_protocol("ipc", move |webview_id, request, responder| {protocol(webview_id, request, UriSchemeResponder(responder))});registered_scheme_protocols.push("ipc".into());}这段代码的意思，调用get获得了protocol ，然后注册ipc 这个uri_scheme_protocol和scheme_protocol
这个pending是什么？
PendingWebview<EventLoopMessage, R>可以发现是个 PendingWebview。虽然不知道干什么。
tauri/crates/tauri-runtime/src/webview.rs at dev · tauri-apps/taurihttps://github.com/tauri-apps/tauri/blob/dev/crates/tauri-runtime/src/webview.rs#L82可以找到，就是一个结构体，
里面有uri_scheme_protocols和ipc_handler等之类的字段
还可以发现ipc是个协议，tauri自定义的协议
虽然前面说过
发送的确是post请求，但是并不是使用http协议。
总之，注册ipc这个protocol。
pending.ipc_handler = Some(crate::ipc::protocol::message_handler(manager.manager_owned(),));也使用了message_handler。
注册了这个ipc，发现请求，就会被webview处理。
以及message_handler处理handler
上面还注册了tauri这个protocol
if !registered_scheme_protocols.contains(&"tauri".into()) {......}看看get
pub fn get<R: Runtime>(manager: Arc<AppManager<R>>) -> UriSchemeProtocolHandler {Box::new(move |label, request, responder| {#[cfg(feature = "tracing")]let span =...let respond = ...match *request.method() {Method::POST => {if let Some(webview) = manager.get_webview(label) {match parse_invoke_request(&manager, request) {...}} else {....}}Method::OPTIONS => {....}_ => {let mut r = http::Response::new("only POST and OPTIONS are allowed".as_bytes().into());....}}})
}
可以发现，这个get方法
首先判断request的method，是post请求和option请求，其他请求返回，只能使用post和option。
如果是post请求就获取webview，然后调用parse_invoke_request方法，处理后续的结果
看看parse_invoke_request
fn parse_invoke_request<R: Runtime>(#[allow(unused_variables)] manager: &AppManager<R>,request: http::Request<Vec<u8>>,
) -> std::result::Result<InvokeRequest, String> {#[allow(unused_mut)]let (parts, mut body) = request.into_parts();let cmd =....let has_payload = !body.is_empty();let invoke_key = parts...let url = Url::parse...let callback = CallbackFn(...)let error = CallbackFn(...)let body = ....let payload = InvokeRequest {cmd,callback,error,url,body,headers: parts.headers,invoke_key,};Ok(payload)
}笔者删减了许多，总体上看，就是从request请求中提取数据
cmd、callback、error、url、body、header、invoke_key
将提取到的数据合并成一个InvokeRequest ，返回。
笔者省略了许多东西。
传入的是http::Request<Vec<u8>>
返回InvokeRequest
总之——将前端的request变成Rust可以处理的InvokeRequest
看看message_handler
pub fn message_handler<R: Runtime>(manager: Arc<AppManager<R>>,
) -> crate::runtime::webview::WebviewIpcHandler<crate::EventLoopMessage, R> {Box::new(move |webview, request| handle_ipc_message(request, &manager, &webview.label))
}返回WebviewIpcHandler
pub type WebviewIpcHandler<T, R> = Box<dyn Fn(DetachedWebview<T, R>, Request<String>) + Send>;WebviewIpcHandler是一个Box，Box指向一个实现了send的动态闭包。
有点复杂。
看看handle_ipc_message
fn handle_ipc_message<R: Runtime>(request: Request<String>, manager: &AppManager<R>, label: &str) {if let Some(webview) = manager.get_webview(label) {#[derive(Deserialize, Default)]#[serde(rename_all = "camelCase")]struct RequestOptions {....}#[derive(Deserialize)]struct Message {...}#[allow(unused_mut)]let mut invoke_message: Option<crate::Result<Message>> = None;let message = invoke_message.unwrap_or_else(|| {...serde_json::from_str::<Message>(request.body()).map_err(Into::into)});match message {Ok(message) => {let options = message.options.unwrap_or_default();let request = InvokeRequest {...};webview.on_message(request,Box::new(move |webview, cmd, response, callback, error| {...});}Err(e) => {....}}}
}传入了http::Request，
这一段代码
serde_json::from_str::<Message>(request.body()).map_err(Into::into)从请求中提取到Message，然后变成InvokeRequest
这个逻辑和get+parse_invoke_request差不多
获得了InvokeRequest之后，使用webview的on_message方法
实际上在get中也是这样的，从 parse_invoke_request返回InvokeRequest，然后使用。
看看webview的on_message方法
pub fn on_message(self, request: InvokeRequest, responder: Box<OwnedInvokeResponder<R>>{//获取mangerlet manager = self.manager_owned();// 判断invoke_keylet expected = manager.invoke_key();....// 初始化resolverlet resolver = ...// 初始化messagelet message = InvokeMessage...);//判断请求的来源let acl_origin = ...let (resolved_acl, has_app_acl_manifest) = ...// 初始化Invoke let mut invoke = Invoke {message,resolver: resolver.clone(),acl: resolved_acl,};// 获取插件名字和cmd的名字let plugin_command = request.cmd.strip_prefix("plugin:").map(|raw_command| {...(plugin, command)});// 判断插件是否存在以及相关权限if (plugin_command.is_some() || has_app_acl_manifest){...}将InvokeRequest传进来之后，
前面一大推都是在处理初始化和权限问题。
现在获得了plugin_command
后面就要对plugin_command 进行操作了
if let Some((plugin, command_name)) = plugin_command {...} else {...}然后就分成了两部分，因为cmd有两种情况
1、插件和插件的cmd，比如plugin:window|theme
2、自定义的cmd，比如greet
分别处理这两种情况
第一种情况的处理
// 为invoke的command设置要执行cmd的名字invoke.message.command = command_name;// 克隆一下，后面会发生所有权的转移，无法使用command let command = invoke.message.command.clone();#[cfg(mobile)]let message = invoke.message.clone();#[allow(unused_mut)] // 执行cmd，返回boollet mut handled = manager.extend_api(plugin, invoke);#[cfg(mobile)]{// 移动端的插件 }// 不是true，说明没找到命令if !handled {resolver.reject(format!("Command {command} not found"));}核心处理是这一行代码，把plugin和invoke传进去
let mut handled = manager.extend_api(plugin, invoke);对extend_api一直往下走
tauri/crates/tauri/src/plugin.rs at dev · tauri-apps/taurihttps://github.com/tauri-apps/tauri/blob/dev/crates/tauri/src/plugin.rs#L777发现如下代码
fn extend_api(&mut self, invoke: Invoke<R>) -> bool {(self.invoke_handler)(invoke)}里面的代码就是执行结构体TauriPlugin中的invoke_handler方法中的闭包。
感觉有点绕口，总之，执行闭包。
为什么是这样写的代码？(self.invoke_handler)(invoke)
看看插件中的invoke_handler的定义
invoke_handler: Box<InvokeHandler<R>>,pub type InvokeHandler<R> = dyn Fn(Invoke<R>) -> bool + Send + Sync + 'static;提取关键的部分，如下
Box<dyn Fn>这表示一种动态分发的函数类型。简单地说
1、左边的括号是用于获取Box包装的闭包
2、右边括号运行Box里面的闭包
总之，获取闭包，运行闭包。
举个简单地例子
如下代码，
fn use_world() {type World = Box<dyn Fn(String)>;struct Api {world: World,}let api = Api {world: Box::new(|s| {println!("hello {}", s);}),};(api.world)("world".to_string());
}或者直接使用
fn use_world() {(Box::new(|s|{ println!("hello {}", s);}))("world".to_string());
}闭包传参Invoke。没问题。
第二种情况的处理
只有cmd命令，没有插件
let command = invoke.message.command.clone();let handled = manager.run_invoke_handler(invoke);if !handled {resolver.reject(format!("Command {command} not found"));}使用的是run_invoke_handler这个函数
pub fn run_invoke_handler(&self, invoke: Invoke<R>) -> bool {(self.webview.invoke_handler)(invoke)}一模一样，不必细说
再看看注册通信函数用的invoke_handler
#[must_use]pub fn invoke_handler<F>(mut self, invoke_handler: F) -> SelfwhereF: Fn(Invoke<R>) -> bool + Send + Sync + 'static,{self.invoke_handler = Box::new(invoke_handler);self}
不必细说。
运行通信函数
现在把Invoke传进来了，至于内部又是如何运行的，可参考如下
【Tauri2】005——tauri::command属性与invoke函数_tauri invoke-CSDN博客https://blog.csdn.net/qq_63401240/article/details/146581991?spm=1001.2014.3001.5502
【Tauri2】007——Tauri2和cargo expand-CSDN博客https://blog.csdn.net/qq_63401240/article/details/146632055?spm=1001.2014.3001.5502不必细说。
返回的处理
调用完闭包，还是是on_message这个函数中处理结果，返回给前端
webview.on_message(request,Box::new(move |_webview, _cmd, response, _callback, _error| {...respond(response);}),);调用的respond 或者使用from_callback_fn、responder_eval
match response {....Channel::from_callback_fn(...);} else {....responder_eval(...)}}这就不细说，就是返回结果，比如需要考虑返回的字符串、还是使用回调函数callback、还是二进制数组等的原始数据等。
比如事件Event，就需要callback
返回不一样，处理不一样。
fn responder_eval<R: Runtime>(webview: &crate::Webview<R>,js: crate::Result<String>,error: CallbackFn,)从 responder_eval的函数签名中可以看出，好像还是处理错误的回调函数。
整个流程
综上所述，简单地说，后端解析的流程如下
-> invoke
-> windon._TAURI_INTERNALS__.invoke
-> fetch
-> parse_invoke_request / handle_ipc_message
-> on_message
-> extend_api / run_invoke_handler
-> invoke_handler
-> response