V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ninjaJ
V2EX  ›  程序员

2024 年了,兄弟们说说用 Tauri 遇到的哪些坑

  •  
  •   ninjaJ · 184 天前 · 5747 次点击
    这是一个创建于 184 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前我的主力桌面端开发框架用 javafx ,简单点的用 electron ,但是各自有各自的缺点。

    我司开发的主要是工业软件,涉及到串口通信等硬件交互,IO 密集、计算密集。但是我又很想用前端技术栈把 UI 分离出来( PS:原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等,各种绑定事件样板代码,写一个软件大部分时间都在写这些东西),可能主要还是已经习惯了前端技术栈那一套丰富的生态和灵活性。

    选了一大圈好像还是基于 rust 的 Tauri 对我胃口,就是不知道它现在怎么样了,还有那么多坑吗?

    第 1 条附言  ·  183 天前
    1 、关于兼容性,我会要求客户操作系统不低于 win10 。
    2 、不会有太多的窗口创建和销毁。

    补充说明一下:UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢?因为我的目标是构建一个灵活的产品架构,第一层是大量组合式、动态(比如动态列表)的前端交互面板;第二层是中间层,将前端的数据结构翻译成底层的执行命令;第三层是底层控制部分。通过这种方式将多参数、多任务、多设备统一起来,只需要一个客户端,用户可以通过这种组合式交互执行一系列的复杂控制。
    那么虽然我的核心工作在第二层和第三层,但是工作量却在第一层,我希望提升的是这一部分。electron 无法支撑我的第三层,其他的选型无法满足我的第一层。

    我另外还有 2 个问题有:
    1 、我的实时高频( 10ms 级)数据从 rust 传递到 webview 有没有性能问题,比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。
    2 、诸位所说的 webview 的坑除了兼容性,还有哪些?大量数据图表的性能问题是否存在(不过这个我有数据层面的优化算法)? webview 长期运行是否会越来越卡(对 GC 又爱又恨)?
    44 条回复    2024-11-11 09:46:02 +08:00
    subframe75361
        1
    subframe75361  
       184 天前 via Android
    现在的最佳实践似乎是 electron + napi-rs
    skye
        2
    skye  
       184 天前
    javafx 更好吧,毕竟 jni 和 jna 比 napi 还是成熟一些。
    iugo
        3
    iugo  
       184 天前
    Tauri 可以包含多个自己的服务端, 比如 Go 写个工具, 向外部暴露一个 HTTP 服务, Tauri 将其打包在内, Tauri 内部调用这个 HTTP 服务. Tauri 只做最简单的 UI 及渲染, 然后使用 Tauri 的工具链打包什么的, 任何复杂功能不需要重构, 只需要暴露出 HTTP 服务供调用就行.
    ninjaJ
        4
    ninjaJ  
    OP
       184 天前
    @subframe75361 我的粗浅理解是 electron 和 Tauri 的 UI 层对我来说都一样,既然都用 napi-rs 了,为什么不直接上 Tauri 呢?您说的这个最佳实践评判的方式可以详细分享一下吗?
    ninjaJ
        5
    ninjaJ  
    OP
       184 天前
    @skye 我本身很擅长 java ,但是用 javafx 写的唯一的难受点是 UI 不够灵活高效,写的太难受了
    sunjiayao
        6
    sunjiayao  
       184 天前
    我目前碰到的问题可能就是 js api 有的比较简陋。比如读取剪切板只能读纯文本,做不到注册 windows 监听事件。需要用 rust 对接 windows api 。但用下来整体觉得没什么问题,可能是因为我大部分代码工作都在 rust 导致的。webview 基本只做 ui 展示。

    然后由于我用的是 tauri 2.0 所以会有一些 bug ,不过目前都能绕过去。还未碰到卡住无法实现功能的问题。
    ZField
        7
    ZField  
       184 天前   ❤️ 1
    可以试试 compose multiplatform for desktop ,ui 部分使用 kotlin 。其他的 Java 代码可以拿来就用
    per
        8
    per  
       184 天前 via iPhone   ❤️ 1
    直接上 Twitter 上搜 yetone tauri
    lsk569937453
        9
    lsk569937453  
       184 天前
    多窗口不成熟。
    subframe75361
        10
    subframe75361  
       184 天前 via Android
    @ninjaJ electron 的坑踩的差不多了,业务逻辑也是 js 写的快一些,工业软件包体积应该不是问题,总体开发效率比 tauri 高。如果 ui 只是简单交互,tauri 也可以胜任,只是目前没听说过有成熟的产品,多是一些小工具
    w568w
        11
    w568w  
       184 天前
    > 原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等,各种绑定事件样板代码,写一个软件大部分时间都在写这些东西

    可以试试 Flutter 或者楼上说的 Compose Multiplatform ,应该都独立于 Web 技术解决了这个阻碍。

    > 串口通信等硬件交互,IO 密集、计算密集

    Flutter 用的 Dart ,直接编译成原生代码,计算性能不会太差,但搞硬件交互可能要研究一下,估计要调第三方包; Kotlin 应该轻松一些。


    > Tauri 对我胃口,就是不知道它现在怎么样了,还有那么多坑吗?

    最大的问题是性能和兼容性差。我自己的不准确经验来看 Tauri 开发稍微大点的应用就会特别特别粘滞:冷启动慢、响应点击慢、拖动窗口慢、调整窗口大小卡,而且 Tauri 首次编译速度也慢得令人头秃(即便和 Electron 作比较,以上缺点也成立);另外,因为一定要接系统的 Webview 库,写的时候也得注意兼容性问题。
    w568w
        12
    w568w  
       184 天前
    补:Flutter 有 rust_bridge ,如果你一定想掺 Rust 进来,也不麻烦。
    vivisidea
        13
    vivisidea  
       184 天前
    @per 哈哈,自从这哥被 tauri 坑了之后,疯狂反向安利 tauri😁
    subframe75361
        14
    subframe75361  
       184 天前 via Android
    另外说一点,从我的个人体验上来说,tauri 的优势只有一个体积小。内存占用只要开着窗口就和 electron 没区别,启动体验在 windows 11 上不如 electron ,electron 在关闭 node 集成后也可以很安全
    duan602728596
        15
    duan602728596  
       184 天前
    还是老老实实用 Electron 吧,真的。
    我曾经也想过换其他框架,但是一想到用的东西,其他框架都不提供,就算了。
    roundgis
        16
    roundgis  
       184 天前 via Android
    知道 javafx 被用在工業軟件

    還是有點意外的
    lisongeee
        17
    lisongeee  
       184 天前   ❤️ 2
    js 写页面还有一个在开发页面速度上其它语言无法相比的优点啊

    那就是配合声明式 ui 框架 react/vue 和构建工具 vite/webpack 可以有 hot module replace 即 HMR

    效果就是更改一个组件的文件后,页面无需重启直接就能看到更新后的组件渲染效果,这对开发速度提升得不是一点半点啊

    上面说的那些 javafx compose 受制于语言特性都没有这个功能(或者是残废)啊,大项目改一个文件编译尼玛大半天然后重启进程还得手动点击回到原来页面的位置才能看到效果
    mark2025
        18
    mark2025  
       184 天前
    @lisongeee 再配合上 TypeScript 提供的静态类型检查,真是很不错的
    hanaTsuk1
        19
    hanaTsuk1  
       184 天前
    可以等 2.0 正式版出来试试 2.0-alpha 到 beta 的改动还挺多
    xieren58
        20
    xieren58  
       184 天前
    工业用 c# , 库多, UI 可以用 https://avaloniaui.net/
    RogerL
        21
    RogerL  
       184 天前
    等 2.0 吧,感觉 2.0 改动太多了
    8520ccc
        22
    8520ccc  
       184 天前
    真的没必要 tauri 对于旧版系统支持太拉了 无脑 electron

    而且很多功能都不支持 生态不完善。。
    mayli
        23
    mayli  
       184 天前 via Android
    @ZField 技术栈过于先进了, 考虑下传统的 imgui?
    xling
        24
    xling  
       184 天前
    运行不起来
    xiaocaiji111
        25
    xiaocaiji111  
       184 天前
    @ninjaJ 是的,javafx 一般都是一些类似工具类的东西再用,比如 dbeaver 啥的这种
    YetToCome
        26
    YetToCome  
       184 天前
    涉及硬件最好不要轻易换技术栈,转换的坑短时间是填不上的。
    jetbrains 那一套 Compose multiplatform 除了生态比较差以外,基本上是可用的
    hhacker
        27
    hhacker  
       184 天前
    尝鲜过 tauri, 最终还是回到 electron, 最终你想要的功能都是 tauri 没有但是 electron 有的
    ninjaJ
        28
    ninjaJ  
    OP
       184 天前
    @lisongeee 你的回答,戳中了我的心巴
    xclidongbo
        29
    xclidongbo  
       184 天前
    动了。这就 electron
    maplelin
        30
    maplelin  
       184 天前
    用 vue 和 react 开发 webview 没法用对应的开发者工具浏览器扩展
    ruchuby
        31
    ruchuby  
       184 天前
    只要你不需要调用太多窗口、系统 API ,那 Tauri 完全可以代替 Electron 。我觉得目前毕竟麻烦的就是系统相关 API 的支持差一点。

    可以看看我的 Tauri+Vue3 项目,用 Scrcpy Mask 像模拟器一样用鼠标键盘控制 Android 设备,基于 Tarui & Rust 开发的跨平台客户端: https://github.com/AkiChase/scrcpy-mask
    lmq2582609
        32
    lmq2582609  
       184 天前
    tauri 还挺好用的
    1una0bserver
        33
    1una0bserver  
       184 天前 via Android
    其实用 compose multiplatform 感觉是最稳妥的,都有 Java fx 代码了,迁移到 compose 绝对方便,而且也支持部分热重载。不过看你踌躇满志的样子,其实心里早就想拿 tauri+rust 重造轮子了吧?既然如此不妨试试,试一遍就知道了。不过仍然建议只要不是 UI 层的东西老老实实用 rust 写,少用 js ,小心埋 cve 。也可以考虑考虑编译到 wasm 的一些框架。还有远离系统菜单和托盘,这玩意经常出问题,不管是 kmp 还是 Web 都是。
    thtznet
        34
    thtznet  
       184 天前
    工业软件首选 C#,MAUI 一把梭
    catamaran
        35
    catamaran  
       184 天前
    desktop application ,为啥不用 c#?
    l1xnan
        36
    l1xnan  
       184 天前
    纯写界面没啥坑,能在 rust 解决的也还好,就是中间如果你想突破 webview 的限制的时候各种坑,tauri 没有多少修改空间
    lisxour
        37
    lisxour  
       183 天前
    @8520ccc 因为 tauri 是直接调用系统自带浏览器内核,这种方案优缺点都非常明显
    ninjaJ
        38
    ninjaJ  
    OP
       183 天前
    @1una0bserver
    1 、关于兼容性,我会要求客户操作系统不低于 win10 。
    2 、不会有太多的窗口创建和销毁。

    补充说明一下:UI 层面主要是用户填写参数和实时数据/图表的刷新。为什么对 web 有那么大的需求呢?因为我的目标是构建一个灵活的产品架构,第一层是大量组合式、动态(比如动态列表)的前端交互面板;第二层是中间层,将前端的数据结构翻译成底层的执行命令;第三层是控制部分。通过这种方式将多参数、多任务、多设备统一起来,只需要一个客户端,用户可以通过这种组合式交互执行一系列的复杂控制。

    那么虽然我的核心工作在第一层和第二层,但是工作量却在第三层,我希望提升的是这一部分。electron 无法支撑我的第一层,其他的选型无法满足我的第三层。

    我另外还有 2 个问题有:
    1 、我的实时高频( 10ms 级)数据从 rust 传递到 webview 有没有性能问题,比如时延以及导致的阻塞。tauri 是如何实现 rust 和 js 相互调用的。
    2 、诸位所说的 webview 的坑除了兼容性,还有哪些?大量数据图表的性能问题是否存在(不过这个我有数据层面的优化算法)? webview 长期运行是否会越来越卡(对 GC 又爱又恨)?
    ninjaJ
        39
    ninjaJ  
    OP
       183 天前
    `那么虽然我的核心工作在第一层和第二层,但是工作量却在第三层,我希望提升的是这一部分。electron 无法支撑我的第一层,其他的选型无法满足我的第三层。`
    抱歉这段话的第一和第三层说反了 -> 核心工作在硬件侧,即第三层,electron 无法支撑。而工作量在视图层,即第一层,其他选项无法满足。
    zhouyg
        40
    zhouyg  
       182 天前
    第三层为啥不写个单独的客户端,然后跟第一层第二层通过 IO 等方式进行调用
    zhouyg
        41
    zhouyg  
       182 天前
    以二进制包的形式一个打包到客户端,对用的人来说还是只有一个客户端
    ninjaJ
        42
    ninjaJ  
    OP
       182 天前
    @zhouyg 我考虑过,这样做有一些弊端:1 、不同语言互相调用会提升复杂度(包括但不仅限于错误传递、打包部署、兼容性问题) 2 、这种互相调用方式会引入新的问题(如自定义协议、时延或者锁的问题,以上分别对应了不同的方案)。
    可能是我的需求掣肘比较多吧。
    另外,做软件不仅要考虑技术难度,还要考虑工程效率。
    KyleCommon
        43
    KyleCommon  
       41 天前
    @ninjaJ 老哥,你最后选择了什么平台?
    ninjaJ
        44
    ninjaJ  
    OP
       4 天前
    @KyleCommon
    最后还是用了 Tauri ,巨爽。就是要花点时间学习 Rust 。程序框架和结构设计自己来,逻辑代码一大半使用的 Claude 生成,中间会有一些坑但是好在都解决了。
    我的项目花了一个月切换过来的,我的总结是,在 AI 的加持下已经可以实现大部分应用 99%的功能了,但是如果应用有一定复杂度和技术难度,那需要对 Rust 非常精深,这时的难度会陡增。
    综上,还是需要根据自己的需要来选择,权衡利弊。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2540 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 01:28 · PVG 09:28 · LAX 17:28 · JFK 20:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.