桌面应用跨平台移动开发【免费下载链接】tauriBuild smaller, faster, and more secure desktop and mobile applications with a web frontend.项目地址https://gitcode.com/GitHub_Trending/ta/tauri点击查看免费下载导读tauri-macros是 Tauri 框架中承载魔法的底层过程宏 crate开发者日常书写的#[tauri::command]、tauri::generate_handler![]、tauri::generate_context!()等语法最终都由它展开为可运行的 Rust 代码。本文以 crates/tauri-macros/README.md 为骨架结合 lib.rs 及各子模块源码完整讲解每个宏的用法、可配置参数、展开原理与底层调用链帮助你理解前端invoke()到 Rust 命令函数之间究竟发生了什么以及如何利用这些宏写出更高效、更安全的 Tauri 应用。Tauri 与过程宏模块的定位Tauri 是一个多语言、可组合的通用系统使用 Rust 工具链与 Webview 中渲染的 HTML 构建桌面应用应用可以按需携带可选的 JS API / Rust API通过消息传递message passing让 Webview 控制系统开发者还可以用自己的功能扩展默认 API轻松桥接 Webview 与 Rust 后端。由于使用系统 Webview 且最终二进制由 Rust 直接编译Tauri 应用体积很小、不捆绑运行时逆向分析也并非易事。而tauri-macros这个模块的职责正如其 README 所述Create macros for the context, handler, and commands by leveraging thetauri-codegencrate.即基于tauri-codegen生成Context、invoke handler 与命令相关的过程宏。它依赖tauri-codegen负责配置解析、资源嵌入、ACL 解析等繁重代码生成与tauri-utils提供 ACL、配置解析等工具函数自身专注于语法解析与代码拼接。从 Cargo.toml 可以看到它是一个proc-macro true的 crate版本号与主 crate 同步当前 2.7.0。需要特别强调正常应用不要直接依赖tauri-macros而应使用tauri主 crate 的再导出。在 crates/tauri/src/lib.rs 中可以确认再导出关系pub use tauri_macros::include_image; pub use tauri_macros::mobile_entry_point; pub use tauri_macros::{command, generate_handler}; // 以及第 298 行的 pub use tauri_macros::generate_context;因此文章中的示例一律以tauri::前缀书写这也是官方推荐写法。#[tauri::command]把普通函数变成可被前端调用的命令command是属性过程宏用来把函数标记为命令处理器command handler并创建一个带有必要胶水代码的包装函数wrapper。包装后的函数可以传给generate_handler![]从而被前端通过invoke()调用#[tauri::command] fn greet(name: String) - String { format!(Hello, {name}!) }展开原理wrapper 与__cmd__命名从 wrapper.rs 的实现看宏的核心工作是解析函数签名 → 生成一个名为__cmd__{函数名}的隐藏macro_rules!包装宏 → 再生成一个名为__tauri_command_name_{函数名}的宏返回命令名字符串。展开后的包装宏接收($path:path, $invoke:ident)在闭包内取出tauri::ipc::Invoke { message, resolver, acl }三个绑定然后调用真实函数。命令执行分两种模式body_blocking/body_async同步命令Blocking直接在调用线程上执行参数解析失败时通过resolver.invoke_error(err)提前返回错误异步命令Async通过resolver.respond_async_serialized(async move { ... })包裹借助async_kind()统一 await 返回值不阻塞主线程。展开代码中有一个针对 Windows 栈溢出的防护包装宏内部使用立即执行闭包{ move || { ... } }()对应源码注释里引用的 tauri-apps/tauri issue #12488 场景。参数解析与键名转换parse_arg函数把每个FnArg转换成一个tauri::ipc::CommandArg::from_command(CommandItem { ... })调用其中key决定前端 payload 的键名。命令函数只支持命名参数、通配符_、结构体模式与元组结构体模式且不允许使用self作为参数宏会给出unable to use self as a command function parameter编译错误。可配置选项attribute options#[tauri::command]接受逗号分隔的以下选项对应WrapperAttributes的解析逻辑async—— 让同步函数在异步运行时上执行避免阻塞主线程#[tauri::command(async)] fn expensive_computation() - u64 { // 函数体在异步运行时执行不阻塞主线程 42 }注意async fn命令本身总是异步执行此选项只对想异步执行但不写 async 签名的同步函数有意义。此外若async fn命令包含引用或带生命周期泛型参数宏会强制要求返回Result否则直接报编译错误对应历史 issue #2533wrapper.rs 中通过#[diagnostic::on_unimplemented]生成友好提示。rename_all—— 设置前端 payload 键与 Rust 参数名的匹配大小写规则camelCase默认或snake_case// JavaScript 中调用 invoke(send_message, { messageBody: Hello }) #[tauri::command] fn send_message(message_body: String) {} // JavaScript 中调用 invoke(send_message, { message_body: Hello }) #[tauri::command(rename_all snake_case)] fn send_message_snake(message_body: String) {}源码中通过heckcrate 的to_lower_camel_case/to_snake_case完成转换见 wrapper.rs 的ArgumentCase枚举传入其他值会报expected camelCase or snake_case。rename—— 修改前端调用时使用的命令名默认是函数名// 前端调用 invoke(greetUser) // 注册时仍写 generate_handler![greet_user] #[tauri::command(rename greetUser)] fn greet_user() {}rename的值会被字符串化进__tauri_command_name_*宏handler 匹配命令名时优先使用重命名后的字符串。root—— 指定tauricrate 的路径当它在Cargo.toml中被重命名或被其他 crate 再导出时使用。默认::tauri特殊值crate解析为$crateTauri 内部自用时使用// Cargo.toml: tauri_framework { package tauri, version 2 } #[tauri::command(root tauri_framework)] fn my_command() {}内联插件标注当命令属于应用自身的一部分inline plugin而非独立 crate 时需要在generate_handler![]列表中用#![plugin(your_plugin_name)]内部属性标注这样build removeUnusedCommands才能把它与插件权限匹配起来做死代码消除。generate_handler![]把命令集合组装成 invoke handlergenerate_handler是声明式过程宏接受一组命令函数生成一个允许 JS 通过invoke()调用这些命令的 handleruse tauri_macros::{command, generate_handler}; #[command] fn command_one() { println!(command one called); } #[command] fn command_two() { println!(command two called); } fn main() { let _handler generate_handler![command_one, command_two]; }展开结构从 handler.rs 看宏最终展开为一个move |invoke| { let __tauri_cmd__ invoke.message.command(); match __tauri_cmd__ { ... } }闭包对每个命令生成一个match分支分支守卫调用对应命令的__tauri_command_name_{fn}!()宏拿到命令名字符串命中时调用__cmd__{fn}!包装宏并传入原始路径与invoke未命中则返回false表示该 handler 不认识此命令。插件名识别与 ACL 过滤try_get_plugin_name会先尝试解析列表顶部的#![plugin(...)]内部属性下划线会被替换为连字符__TAURI_CHANNEL__为历史兼容保留否则回退读取CARGO_PKG_NAME环境变量并剥离tauri-plugin-前缀。filter_unused_commands则读取tauri-utils::acl::read_allowed_commands()得到的允许命令列表对不在列表中的命令直接从 handler 中剔除此时宏还会额外给包装宏加上#[allow(unused)]以配合死代码消除并在编译期打印Removed unused commands from ...提示。应用级命令非插件只有在存在应用级 ACL 时才会被过滤。这正是 Tauri 权限系统capabilities能够裁剪二进制中未授权命令的底层机制。generate_context!()读取配置并生成Contextgenerate_context读取 Tauri 配置文件并生成一个::tauri::Context。该 Context 会把前端资源frontend assets、应用图标、解析后的访问控制列表ACL以及解析后的配置全部嵌入二进制并传给tauri::Builder::run/tauri::Builder::buildtauri::Builder::default() .run(tauri::generate_context!()) .expect(error while running tauri application);在 context.rs 中ContextItems的解析还涉及目标平台判断宏会读取TARGET或TAURI_ENV_TARGET_TRIPLE环境变量缺省用当前平台随后调用tauri-codegen的get_config与context_codegen完成真正的代码生成出错时统一输出compile_error!。配置选项所有选项都是可选的可组合成逗号分隔列表配置文件路径第一个字符串字面量—— 指定读取的 Tauri 配置文件路径相对于CARGO_MANIFEST_DIR默认为 crate 目录下的tauri.conf.json。旁边同目录的平台特定配置文件如tauri.windows.conf.json会照常合并tauri::generate_context!(../tauri.conf.json);源码中会通过does_supported_file_name_exist校验该文件存在否则报no file at path ... exists, expected tauri config file。Root 路径—— 任意非key value形式的路径参数用于改变生成代码引用的 crate 路径默认::tauri仅在tauri被重命名、被其他 crate 再导出或本身就是要编译的 cratecrate时需要tauri::generate_context!(../tauri.conf.json, ::my_framework::tauri);capabilities [...]—— 在capabilities目录和应用配置app security capabilities之外额外附加的 capability 文件列表。每个元素是相对编译器当前工作目录通常是 crate 目录的 JSON 或 TOML 路径内容可以是单个 capability、capability 列表或命名 capability 列表tauri::generate_context!(capabilities [./capabilities/extra.json]);assets 表达式—— 解析为自定义tauri::Assets实现的表达式用于替换从build frontendDist嵌入资源的默认行为。典型用途从自定义来源提供前端或在测试中跳过资源嵌入tauri::generate_context!(assets tauri::test::noop_assets());test true—— 置为true时跳过在测试二进制中会产生问题的代码生成当前是 macOS 开发构建中的Info.plist嵌入默认falselet context tauri::generate_context!(../tauri.conf.json, test true);mobile_entry_point移动端应用入口与 FFI 桥接mobile_entry_point是属性宏把构建并运行 Tauri 应用的库目标函数标记为移动端入口对于 CLI 创建的应用即src-tauri/src/lib.rs中的run()这是生成的 Android 与 iOS 项目启动时调用的函数。规范用法是只在移动端目标上启用让桌面二进制的main.rs仍可调用同一函数#[cfg_attr(mobile, tauri::mobile_entry_point)] pub fn run() { tauri::Builder::default() .run(tauri::generate_context!()) .expect(error while running tauri application); }从 mobile.rs 的展开代码看宏会生成stop_unwind用std::panic::catch_unwind捕获 panic 而不是跨越 FFI 边界展开unwind失败时打印错误并std::process::abort()若run()是async生成{函数名}_wrapper用tauri::async_runtime::block_on阻塞等待_start_appiOS 上调用tauri::log_stdout()设置 stdout 日志Android 上通过tauri::android_binding!(domain, app_name, _start_app, ::tauri::wry)建立 JNI 绑定包名取自配置identifier拆分出的 domain 与 app_name最终导出#[no_mangle] pub extern C fn start_app()C 符号Tauri CLI 会检查该符号重命名需谨慎。关于 Android 包名它来自tauri-build设置的环境变量TAURI_ANDROID_PACKAGE_NAME_PREFIX/TAURI_ANDROID_PACKAGE_NAME_APP_NAME因此应用必须提供调用tauri_build::build的 build script否则宏会直接报env var not set, do you have a build script with tauri-build?编译错误。include_image!把图标编译进二进制include_image!把.png或.ico图标转换为tauri::Image供tray::TrayIconBuilder、WebviewWindowBuilder等任何接收Image的 API 使用相对路径从CARGO_MANIFEST_DIR解析而非当前文件const APP_ICON: Image_ include_image!(./icons/32x32.png); // 用于托盘 TrayIconBuilder::new().icon(APP_ICON).build().unwrap(); // 或用于窗口 WebviewWindowBuilder::new(app, main, WebviewUrl::default()) .icon(APP_ICON) .unwrap() .build() .unwrap();宏内部调用tauri_codegen::image::CachedIcon生成代码见 lib.rs 的include_image实现。注意图片以原始像素存入最终二进制请保持图标宽高较小否则会明显增大可执行文件体积路径不存在时宏会给出Provided Image path ... doesnt exists的编译错误提示。两个隐藏宏default_runtime与do_menu_item这两个宏在文档中标记为#[doc(hidden)]属于内部基础设施普通应用无需直接使用。default_runtime为最后一个泛型参数约定为 runtime 类型设置默认值条件是指定 feature 开启。语法为#[default_runtime(crate::Wry, wry)即启用wryfeature 时把最后泛型默认到crate::Wry。从 runtime.rs 看它支持struct、enum、type、trait定义仅修改最后一个没有默认值的泛型参数并通过#[cfg(feature ...)]/#[cfg(not(feature ...))]输出两套代码。do_menu_item接受类闭包语法在按kind匹配并从resources_table按rid取回菜单项后对其执行任意代码。第 5 个参数可选用|分隔的菜单项种类列表限定匹配范围也支持!取反do_menu_item!(resources_table, rid, kind, |i| i.set_text(text), Check | Submenu); // 或取反列表 do_menu_item!(resources_table, rid, kind, |i| i.set_text(text), !Check); do_menu_item!(resources_table, rid, kind, |i| i.set_text(text), !Check | !Submenu); // 不允许正负混用下面这行是编译错误 // do_menu_item!(resources_table, rid, kind, |i| i.set_text(text), !Check | Submenu);从 menu.rs 的展开代码看它会生成对ItemKind::{Submenu, MenuItem, Predefined, Check, Icon}的match分别从resources_table.get::SubmenuR(rid)?等取回类型化句柄后执行表达式默认匹配全部五种未命中返回crate::Error::UnexpectedMenuKind。实战串联一个完整的命令 上下文示例仓库 examples/state/main.rs 是三个宏协同工作的最小范例——它用State管理共享计数器四个命令均带#[tauri::command]generate_handler![]统一注册generate_context!指定显式配置路径use tauri::State; struct Counter(Mutexisize); #[tauri::command] fn increment(counter: State_, Counter) - isize { let mut c counter.0.lock().unwrap(); *c 1; *c } #[tauri::command] fn decrement(counter: State_, Counter) - isize { /* ... */ } fn main() { tauri::Builder::default() .manage(Counter(Mutex::new(0))) .invoke_handler(tauri::generate_handler![increment, decrement, reset, get]) .run(tauri::generate_context!( ../../examples/state/tauri.conf.json )) .expect(error while running tauri application); }注意State_, Counter参数的键名经 camelCase 转换后为counter前端 payload 中对应的就是counter键。这印证了完整调用链invoke(increment, {...})→ handler 的match命中命令名 →__cmd__increment!包装宏展开CommandArg::from_command解析参数 → 执行真实函数 → 经blocking_kind()序列化返回结果给前端 resolver。稳定性与语义化版本按 README.md 与 lib.rs 的文档声明上述宏展开产出的代码由 Tauri 内部管理不应在普通应用中直接访问其输出未来可能发生破坏性变更tauri遵循 Semantic Versioning 2.0本 crate 遵循 MIT 或 MIT/Apache 2.0 双许可Logo 遵循 CC-BY-NC-ND。小结#[tauri::command]函数 → 命令处理器支持async、rename_all、rename、root四个选项与内联插件标注generate_handler![]命令列表 → invoke handler含插件名识别与 ACL 死代码过滤generate_context!()配置文件 → 嵌入前端资源、图标、ACL 与配置的Context支持自定义配置路径、root、capabilities、assets、test选项mobile_entry_point桌面/移动共用入口函数 → Android/iOS 原生启动桥接include_image!图标文件 →Image常量default_runtime与do_menu_item为隐藏内部宏服务于 runtime 默认类型与菜单资源操作。理解这些宏的展开逻辑有助于排查命令参数不匹配、理解权限裁剪、以及编写更贴合 Tauri 运行时模型的高效应用。想要进一步从架构层面了解各 crate 如何协同可继续阅读仓库根目录的 ARCHITECTURE.md。赞分享桌面应用跨平台移动开发【免费下载链接】tauriBuild smaller, faster, and more secure desktop and mobile applications with a web frontend.项目地址https://gitcode.com/GitHub_Trending/ta/tauri点击查看免费下载相关推荐tauri-macros 2.x 完全指南Tauri 过程宏体系的演进、命令宏原理与源码剖析tauri macros 2.x 完全指南Tauri 过程宏体系的演进、命令宏原理与源码剖析 本篇技术指南以仓库中 crates/tauri macros/C桌面应用跨平台移动开发Tauri 跨平台应用打包深度指南tauri-bundler 配置体系与源码实现解析Tauri 跨平台应用打包深度指南tauri bundler 配置体系与源码实现解析 Tauri 项目的应用分发离不开打包环节。本指南以仓库中的 crates桌面应用跨平台移动开发Rawkit 过程宏深度解析Tag 派生宏与 build_camera_data 宏的源码实现与实战Rawkit 过程宏深度解析Tag 派生宏与 build_camera_data 宏的源码实现与实战 导读 本文聚焦 Graphite 开源仓库中 libr图形学桌面应用图像处理上一篇Cloud Torrent与Docker完美结合容器化部署的最佳实践下一篇文档电子签名ONLYOFFICE Docs实现PDF文档的数字签名功能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
