Tauri 如何跑到鸿蒙上？从 tauri-demo 看 OpenHarmony 适配链路

先说结论这个仓库的重点不是 Vue 页面也不是greet函数而是验证 Tauri 的前端、Rust 后端、Runtime、WebView 和 OpenHarmony Ability 能不能串起来。最近我看了一个很有意思的仓库richerfu/tauri-demo。第一眼看它像一个普通的 Tauri Vue Demo。页面是默认模板Rust 侧只有一个greetcommand。但如果只这么看就把重点看偏了。README 里写得很直接这是一个Tauri prototype for OpenHarmony/HarmonyNext。也就是说它不是在教你写一个桌面应用而是在验证一件事Tauri 这套应用模型能不能被搬到 OpenHarmony / HarmonyNext 上这篇先不讲实操先把这条链路讲清楚。一、它不是一个普通的 Tauri Hello World普通 Tauri 项目大概是这样的结构Web 前端 ↓ Tauri JS API ↓ Rust command ↓ Tauri Runtime ↓ 桌面系统 WebView / 窗口 / 原生能力而这个仓库要验证的是另一条链路Vue 前端 ↓ Tauri JS API ↓ Rust command ↓ Tauri Runtime ↓ OpenHarmony Ability ↓ OHOS WebView / N-API / 原生动态库所以你会发现前端代码和 Rust 业务代码都很简单。简单不是因为没写完而是因为它要验证的不是业务复杂度而是最小链路能不能打通。我建议读这个仓库时不要先盯着页面效果看而是先看构建命令、Cargo.toml、生成出来的 OHOS 工程以及EntryAbility如何接住 Rust 动态库。二、前端层Vue 只是入口不是重点从package.json看项目使用的是 Vue 3、Tauri v2 API 和 Tauri opener 插件开发侧是 Vite、TypeScript、Vue TSC 和 Tauri CLI。前端入口src/main.ts非常干净只做 Vue 挂载import{createApp}fromvue;importAppfrom./App.vue;createApp(App).mount(#app);真正的跨端调用发生在App.vue。它从tauri-apps/api/core里导入invoke然后在表单提交时调用 Rust commandasyncfunctiongreet(){greetMsg.valueawaitinvoke(greet,{name:name.value});}这行代码很小但意义很大。它代表 WebView 里的前端页面通过 Tauri 的 IPC 通道去调用 Rust 侧的本地函数。在普通桌面环境里这说明 Tauri 的前后端通信打通了。在 OpenHarmony 场景里它还多了一层意义这个调用链要能穿过 OHOS 的应用模型继续成立。三、Rust 层最小 command验证最大链路Rust 侧的代码也很克制。src-tauri/src/lib.rs里定义了一个greetcommand#[tauri::command]fngreet(name:str)-String{format!(Hello, {}! Youve been greeted from Rust!,name)}然后在run()里注册进去tauri::Builder::default().plugin(tauri_plugin_opener::init()).invoke_handler(tauri::generate_handler![greet]).run(tauri::generate_context!()).expect(error while running tauri application);这里有两个关键点。第一#[tauri::command]让 Rust 函数可以被前端调用。第二generate_handler![greet]把这个 command 注册给 Tauri。所以完整调用链是Vue 表单 ↓ invoke(greet) ↓ Tauri IPC ↓ generate_handler![greet] ↓ Rust greet() ↓ 返回字符串给前端这就是 Tauri 的最小闭环。四、真正的地图在 Cargo.toml如果只看 Vue 和greet这个项目看不出什么特别。真正关键的是src-tauri/Cargo.toml。这里的tauri和tauri-build不是普通 crates.io 版本而是指向richerfu/tauri的feat/open-harmony分支。同时项目还 patch 了 Wry、Tao、tauri-runtime、tauri-utils 等关键组件并引入了 OpenHarmony Ability 相关依赖。tauri tauri-build tauri-runtime tauri-runtime-wry wry tao openharmony-ability napi-ohos这说明一件事这个 demo 的核心工作不在业务代码而在 Tauri runtime、窗口层、WebView 层和 OHOS Ability 桥接层。也就是说这不是“写一个鸿蒙页面”而是“让 Tauri 的应用模型被 OHOS 承载”。五、构建结果不是桌面 App而是 OHOS 工程README 里的构建方式是cdsrc-tauricargotauri ohos build构建后要用 DevEco Studio 打开src-tauri/gen/ohos这一步很关键。它说明 Tauri CLI 在这里的角色不只是“打一个桌面包”而是生成一个可以被 OHOS 工具链继续处理的工程。生成的 OHOS 工程里module.json5定义了EntryAbility设备类型包含phone、tablet、2in1并申请了INTERNET权限。六、EntryAbility 是 Tauri 和 OHOS 的接头再看EntryAbility.ets。它继承自ohos-rs/ability的NativeAbility并声明了一个很重要的字段publicmoduleName:stringtauri_demo_lib这个名字正好对应 Rust 侧的动态库名称。换句话说OHOS 的 Ability 启动后会通过这层 NativeAbility把生命周期和 Rust / Tauri 侧的入口接起来。README 里也特别备注了一句RustAbility will forward lifecycle automatically.我的理解是这句话才是整个 demo 的关键OHOS 的生命周期需要被转发给 Rust/Tauri runtimeTauri 才能继续完成初始化、窗口创建、WebView 承载和事件处理。七、一张图总结把它完整串起来就是下面这条链路Vue 页面 ↓ tauri-apps/api/core invoke() ↓ Tauri IPC ↓ Rust #[tauri::command] ↓ Tauri Builder / Runtime ↓ richerfu/tauri feat/open-harmony ↓ Wry / Tao OpenHarmony 适配 ↓ src-tauri/gen/ohos ↓ EntryAbility / NativeAbility ↓ OHOS WebView / 原生动态库所以这个项目虽然小但它的价值很清楚tauri-demo 不是一个业务 demo而是一个 Tauri OpenHarmony 适配链路的最小验证工程。八、它证明了什么还没证明什么它已经证明了几个关键点Tauri CLI 可以走到 OHOS 构建路径。Vue 前端可以通过 Tauriinvoke调 Rust。Rust 侧可以作为动态库被 OHOS Ability 承接。生成的 OHOS 工程可以交给 DevEco Studio 继续运行。但它还没有证明全部能力。比如复杂插件、文件系统、窗口管理、多页面、系统权限、打包发布、生产级调试这些都还需要后续继续验证。所以这篇文章的结论很简单这个 demo 值得看不是因为它写了多少代码而是因为它把 Tauri 上鸿蒙的关键路径暴露出来了。下一篇我们不再讲原理直接动手跑一遍安装依赖、构建 OHOS 工程、用 DevEco Studio 打开并尝试改一个 Rust command。