V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
jackiesteed
V2EX  ›  程序员

请问大家使用 uniapp 框架做多平台 app 的实践多吗? 是否适合使用?

  •  
  •   jackiesteed · 151 天前 · 5095 次点击
    这是一个创建于 151 天前的主题,其中的信息可能已经有所发展或是发生改变。
    61 条回复    2024-07-29 16:23:41 +08:00
    flytsuki
        1
    flytsuki  
       151 天前
    看你需求。你的需求网页就能实现的话打包成 app 就不错。否则的话用 flutter 会比这个好点
    nomytwins
        2
    nomytwins  
       151 天前
    我们做过十几个 app 都是用的 uniapp ,也能生成 h5 和小程序,可以推荐几个他们的框架 graceui
    ala2008
        3
    ala2008  
       151 天前
    有用,坑也不少的
    wangsd
        4
    wangsd  
       151 天前
    做项目用, 对于我这种后端来说也没其他选择.
    LuckyLauncher
        5
    LuckyLauncher  
       151 天前
    现在跨平台就是个坑
    技术没有银弹,无非是取舍罢了
    laobobo
        6
    laobobo  
       151 天前
    正准备尝试一下,做个小程序,不过大家普遍说坑多,不建议使用,哈哈
    uqf0663
        7
    uqf0663  
       151 天前
    在 V 站问,大部分人跟你说不行的,你去 uni 那几十个群问问看咯
    Li83Xi7Gai4
        8
    Li83Xi7Gai4  
       151 天前
    做小程序,h5 没问题,做 app 就算了吧
    samnya
        9
    samnya  
       151 天前 via Android
    我做小程序和 h5 都用,不过有些地方还是要踩踩坑的,比如要用到 canvas 这些地方。
    做 app 如果你对它的要求是在小程序级别的话还是没有问题的。
    不过有出海需求的话之前有段时间引入的 sdk 会导致 Play 商店下架,虽然解决了但不知道会不会再有类似的坑。
    tanranran
        10
    tanranran  
       151 天前   ❤️ 1
    做过,适合。有一个插件市场,各种现成轮子。全国各种外包首选框架
    NoManPlay
        11
    NoManPlay  
       151 天前
    考虑一下 taro ,个人感觉使用体验好于 uniapp ,最少不需要那个 hbuilder
    aaronzhang404
        12
    aaronzhang404  
       151 天前
    对于轻量级 APP 来说,抛开 Bug 不谈还挺流畅的,在 iPhone 上可以 80hz 。后来用 flutter 重写,只能 60hz 。至于为什么要重写,因为 uniapp 的 bug 抛不开。
    jones2000
        13
    jones2000  
       151 天前
    主打一个便宜。 几千的开发成本。
    TimPeake
        14
    TimPeake  
       151 天前
    感觉这些跨平台框架非常适合做一些信息流/购物等 简单的 app , 如果追求极致体验、需要用到一些专业的插件/贴近系统底层的功能/交互,大概率是不适合的。
    markgor
        15
    markgor  
       151 天前
    你可以看看 GOV 部分的 APP ,都是 UNIAPP 打包的。
    另外“实践多吗”----多
    “是否适合使用”---看場景,如果你是大廠那些 APP ,擁有龐大的用戶,那不適合,如果你沒去到大廠那些用戶體量,那就適合。
    uniapp 非 uts 和 weex 模式下,界面和功能基本能覆蓋 90%,剩下 10%可以通過自己封裝 sdk 給 uniapp 調用;
    weex 模式就是功能上基本一致,但是 CSS 用法和 JS 部分有一點差異,但是主打性能。
    而 uts 新出的模式,看了下文檔好像就是類似 flutter 那樣。
    hbuilder 則不做評論,我用的時候經常莫名閃退,或者提示異常。但是都在我忍受範圍內。
    fu82581983
        16
    fu82581983  
       151 天前
    如果功能不复杂,本身前端技术栈是 vue ,那还是挺适合的,当然假如遇到 bug 可能很难解决。
    markgor
        17
    markgor  
       151 天前
    @markgor 就類似 v2 看到的帖子,大量 dom 元素 h5 下的性能調優。
    通過 UNIAPP 去開發,和 H5 一樣甚至性能不如 H5 ,但是市場有很多插件,如虛擬滾動之類的來降低性能的影響。
    如果你想用安卓和 ios 原生的解決方式降低損耗,你可以變異為 weex 模式,這個模式下有專用的組件可以讓變異出來的和原生性能上基本一致。但是很麻煩很麻煩。
    而 utx 模式下官方我看建議是用類似 canvas 的方式去繪製過多的 dom 元素來提升性能。
    crocoBaby
        18
    crocoBaby  
       151 天前
    轻交互可以,一些信息展示类的,重交互不推荐
    mtjgu
        19
    mtjgu  
       151 天前
    bug 多 维护麻烦
    retrocode
        20
    retrocode  
       151 天前   ❤️ 2
    有用, 我从 19 年开始用 uni-app 至今, 目前新项目采用的 nvue +ts+vue3, 使用体验很好, nvue 是原生渲染性能也没大问题, 坑主要是跨端的通用坑, 类似 小程序的 shadow-dom 导致的样式问题之类的, 都是些初见杀知道了注意下就不会再踩的坑, 再者就是现在 vue3 在插件市场找插件的时候得注意看插件兼容度之类的.

    我以前总结过相关问题你可以参考下, 文档时间较老但截至目前依然可以参考.
    ![uniapp 踩坑记录]( https://retrocode.io/#/%E8%B8%A9%E5%9D%91/uniapp%E8%B8%A9%E5%9D%91%E8%AE%B0%E5%BD%95)



    另外除非你只做小程序多平台, 否则不要碰 taro, 生态坑的呀批, 几年了一套能同时用于小程序和 RN 的组件库都没有, 天天换域名 taro.jd.com taro.auto.io taro.zone 文档地址天天变
    lonjin
        21
    lonjin  
       151 天前
    @laobobo 只要不涉及 app ,uni 爽的很
    murmur
        22
    murmur  
       151 天前
    我宁可选 capacitor ,这个在线打包就给我劝退了,还是有源码安全点,现在都讲自主可控,越是大企业越要这个

    一个在线打包直接 pass 了
    exploreexe
        23
    exploreexe  
       151 天前 via Android
    做 APP 的话 还是算了,坑很多。
    FreshOldMan
        24
    FreshOldMan  
       151 天前
    之前这框架还在命令行插广告来着,这种国产垃圾框架到底谁在用啊,除了那种垃圾外包我想不到谁会用
    K332
        25
    K332  
       151 天前
    跨平台看下涉及到原生功能是否有插件可以满足,否则自己开发或者修改别人插件时,就很麻烦,至于普通的 ui 展示,这个无所谓什么技术栈
    MMDeJeVS3GtMVLeu
        26
    MMDeJeVS3GtMVLeu  
       151 天前
    @NoManPlay taro 比 uniapp 差,uniapp 可以 cli 开发,小程序的话挺推荐用的,比起写原生丝滑不少
    antowa
        27
    antowa  
       151 天前
    纯网页类应用可以。uniapp 做多平台坑很多的
    wsseo
        28
    wsseo  
       151 天前
    uniapp 适配 鸿蒙的版本已经出了,开发成本大大降低
    bug51
        29
    bug51  
       151 天前
    @markgor 好多招聘描述说要 weex 啥的。原来如此。一开始以为 weex 凉透了
    gongquanlin
        30
    gongquanlin  
       151 天前
    强绑定 hbuilder ,难用的不行,即是选了 vscode 的快捷键,很多也不对。而且很多好用的前端组件即是魔改上了 uniapp ,也各种问题。
    推荐 taro ,vscode 、react 体验良好,vue 的没试过。给公司上了几个项目了
    C603H6r18Q1mSP9N
        31
    C603H6r18Q1mSP9N  
       151 天前
    正常使用问题不大

    app 、小程序、h5 ,整套适配算很好的;
    但是预期不要非常高,就是一个本地版本的 VUE 项目,动画效果就是 h5 那套

    电商、旅游、展示类的 适合,社交、直播、音视频效果和原生有差距。

    国内感觉 uniapp 必 reactnative 好,RN 支付、分享、推送、地图,每一个常用功能都没有很好的 SDK 选择,官方版本包基本没有。。。,uniapp 最起码这些都给集成进去了,还有维护那种。
    bzj
        32
    bzj  
       151 天前
    @FreshOldMan

    接私活的时候用
    ajan
        33
    ajan  
       151 天前
    @NoManPlay

    @gongquanlin

    我猜你们不知道 uni-app 有 cli 模式,不需要 HBuilder 。

    https://uniapp.dcloud.net.cn/quickstart-cli.html

    我们做了很多项目了,挺好的。
    JohnH
        34
    JohnH  
       151 天前
    uniapp 生态健全,社区活跃。
    我也使用它做过很多类型小程序,也制作过需要对接硬件的 app 。比如串口通信、安卓原生 sdk 封装对接,都是通过 uniapp 这一整套来实现的。
    markgor
        35
    markgor  
       151 天前
    @bug51 weex 是阿里开源的一个技术吧,然后 uniapp 跟进,就上面有人说到的 nvue ,但是吧,之后阿里好像是没继续维护 weex 了,然后就变成 uniapp 这边接手维护 nvue 。说真的我目前上线了 2 个 APP ,均没使用 nvue ,限制比较多,而且我也还没到达性能瓶颈,你看看现在换手机架构的迭代频率......大部分情况下性能没太大问题。
    不过现在 uniapp 好像也停止维护 nvue 了,改成了主要维护推进 uts ,编译成原生语言,但这个我没接触过。


    而 uniapp 其实没那么万金油,针对不同平台小程序和不同平台(IOS/ANDROID/H5/MP-*)都有特定的条件编译方法。
    当跨平台的时候,你可以理解为:80%的代码是复用的,剩下 20%可能需要针对特定环境做差异化条件编辑。
    我没接触过 flutter 和 react 这些没法比较,但是就目前而言,uniapp 的缺点在我接受的范围内,所以我选择 uniapp 。


    我觉得更多时候,项目还没上线,就按着几万日活的方向去考虑选型,完全是没必要。
    打造 100 款 APP ,都未必能有一个到达几万日活量,何必在这里浪费时间呢。
    倒不如一把梭,用 uniapp 快速上线验证业务,然后真的到达了过万的日活量,再去考虑替换。
    betty00
        36
    betty00  
       151 天前
    需求比较简单还是可以用,但是陈年 bug 是真的多
    NoManPlay
        37
    NoManPlay  
       151 天前
    @ajan 确实不知道这个,react 用的比较多,感谢告知
    anyele
        38
    anyele  
       151 天前   ❤️ 1
    uniapp 已经是目前最优方案了
    anyele
        39
    anyele  
       151 天前
    @anyele #37 虽然不完美, 但没得选
    laters
        40
    laters  
       151 天前
    flutter
    abelmakihara
        41
    abelmakihara  
       151 天前
    坑多 尤其用插件市场插件的时候 不过还是可用的
    不过做小程序 用 taro 感觉比 uniapp 要好 没用 taro 编译 app 过
    markyun
        42
    markyun  
       151 天前
    @abelmakihara 用 taro 适合做小程序吧,做 app 好像有很多限制,比如如果要生成 RN 项目,有很多 API 和组件都不支持。
    iv8d
        43
    iv8d  
       151 天前
    多端你用就完了,肯定是能做出来的。
    sL83OdzP0RtI2l31
        44
    sL83OdzP0RtI2l31  
       151 天前
    看你需求,我一般就是 uniapp 做个壳,里面嵌 H5 ,我们主要还是搞小程序
    chniccs
        45
    chniccs  
       151 天前
    还好,用过几次,没碰到什么大问题
    herewego
        46
    herewego  
       151 天前
    又不是个个都是原生大佬
    大部分都是做外包,一个后端或者前端,你要啥自行车
    人家这么久没夸,还有真么多公司用,肯定是有他得道理的
    RightHand
        47
    RightHand  
       151 天前 via Android
    新坑的话,小程序优先就 uniapp ,app 优先就 flutter 。旧坑?当然是有什么用什么
    zencodex
        48
    zencodex  
       151 天前   ❤️ 1
    首先任何技术栈都有坑,核心问题是我们有没有办法和能力把坑填平。

    当所有坑都填过,沉淀下来的就是属于你自己的最佳实践。每个开发者不论采用什么技术栈,最好都能沉淀出一套属于自己的最佳实践。从而将更多的精力放在打造产品本身的价值上,而非技术。


    早期在跨平台这个事情上,我也做过很多探索,从最初 cordova ,react native ,Xamarin ,MUI ( uniapp 的前身)都有过尝试,也在 uniapp 这个上面产生过动摇,是否切换到 react native+taro 。

    直到现在坚定的使用 uniapp 做产品,并将我自己积累出来的最佳实践形成开源作品 `uapp`。uapp 通过集成 uni-app, electron, tauri ,让开发者仅需维护一套代码,就能横扫所有平台。

    uapp 弥补了 uniapp 在 app 离线打包上的各种坑,让开发效率也直接拉满。可以不需要开启 HBuiderX ,在命令行下就能做各种编译。比如生成离线打包的自定义基座,仅需命令 `uapp run build:dev` 即可。

    还有,比如查看提交审核的包名,微信开放平台用到的签名等,`uapp info` 一条命令,直接给出。

    甚至 app 或 小程序里用到的《用户注册协议》《隐私协议》,都可以 `uapp privacy` 一条指令生成(任何框架里都可以用这个命令,配合 vitepress 生成协议文档)。

    社区里还有人给出了需要自动化集成的 jenkins 配置文件 (看 github 的 issue 里),linux 上需要配合我做的 linux 环境包,需要的这里安装:

    <https://artisansoft.feishu.cn/docx/NZRHdetSzoi8VEx7KcYcuivpnqd>

    我有款产品是视频剪辑工具,音视频处理是对 native 能力依赖度很大的,不是简单的有 UI 就行了,这个产品我已经通过自己的解决方案,抹平了 桌面端 Electron (windows/macosx/linux),app 端( android ,ios )上的差异,并且积累了丰富的跨平台经验,完全可以让 Web 开发者仅需维护一套代码,就能横扫所有平台。

    本人不对各种跨平台方案的好坏做评价,适合你自己的就是最好的,各种跨平台方案的原理和优劣,uniapp 官网文章也说的挺详细了:

    <https://doc.dcloud.net.cn/uni-app-x/select.html>


    如果你在使用 uniapp 开发,在跨平台开发有困惑需要协助的话,可以从 github 上添加我微信,也欢迎能给 uapp 一个 star 支持下 🙏 ,开源本身都是用爱发电,没有收益的。
    Features
        49
    Features  
       150 天前
    有时候我感觉 uniapp 就是赛博菩萨
    非常简单易用的一个平台,做点小东西还是不错的
    中大型公司建议肯坑其他的
    BealuoC
        50
    BealuoC  
       150 天前
    用他做过商城类的,还不错,小问题都能找到解决
    linyongxin
        51
    linyongxin  
       150 天前
    低成本高效跨平台,文档插件丰富
    galikeoy
        52
    galikeoy  
       150 天前
    虽然生态这方面,taro 没有 uniapp 好,但还是投 taro 一票,不用绑定 hbuilder 太好了,taro+vue+ts 已经上了两个项目了
    mrpzx001
        53
    mrpzx001  
       150 天前
    @galikeoy uniapp 也不需要绑定 hb
    lauginwing
        54
    lauginwing  
       150 天前
    如果你是前端,只有一个人,要开发一个要求不那么高的 app ,uniapp 是最好的选择
    soya2
        55
    soya2  
       150 天前
    虽然 uniapp 写起来有些时候会出现莫名其妙的问题,但也是小成本下多平台不错的选择了,希望以后能做的更好,文档啥的都完善一下
    chungon
        56
    chungon  
       150 天前
    说强绑定 HBuilder 的真的用过吗?我们项目基本都是 uniapp ,bug 不少,但用起来其实也没那么难用
    zencodex
        57
    zencodex  
       149 天前
    看了一些回复,应该都是做的单一平台。只有做过多平台才能体会,先不说 Electron 这种桌面集成了,至少小程序和 app ,h5 都一套代码搞一个项目就有体会了。

    hbx 的确相当于强绑定,如果只有 uniapp-cli ,环境搭建就会遇到多少问题,app 也没法开发,虽然能编译出 app 资源,但总得调试和打包吧,没 hbx 都没法调试。

    taro 如果做了多个平台,也就知道多麻烦了,并且他的原理就没法抹平 UI 差距,RN 和 WEB 完全不同的 UI 形式。uniapp 至少都是 h5 (实际 nvue 类似 RN ,问题很多),我后期 nvue 全改回用 vue 了。

    按目前跨端接口统一程度看,没有比 uniapp 更多的了。如果不做跨端,那还不如什么平台就用原生方法做,uniapp 只有真正跨多端才能体会到便利。

    做多端跨平台, `uapp`不会让你失望的,欢迎来入坑:

    <https://github.com/uappkit/uapp>
    zy0829
        58
    zy0829  
       149 天前
    @chungon uniapp cli 贼难用个人觉得,热更新经常有问题
    bug51
        59
    bug51  
       146 天前
    @retrocode uniapp 踩坑记,3 年没更新了啊。

    都 3 年一大变了,参考意义没那么大
    retrocode
        60
    retrocode  
       146 天前   ❤️ 1
    @bug51 #59 我文章里总结那几条数据多端兼容坑, 至今依然存在, 为啥没参考意义.
    retrocode
        61
    retrocode  
       146 天前   ❤️ 1
    @bug51 #59 没更新主要是因为, 后来我再没遇到其他新坑了就一直没更新...... 可能是我变强了......
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2610 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 10:53 · PVG 18:53 · LAX 02:53 · JFK 05:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.