今天同事聊天说到想学qt或者别的能跨平台的（他是写脚本的，说想学能做Android和ios的）

我说如果不考虑桌面端的话可以试试uniapp

(我没用这个做过商业项目，只写着玩过)

做后端的同事说这个框架很垃圾。

想问下大家uniapp有什么缺陷？我不是很了解，之后公司做Android我是考虑用uniapp的，如果真的很垃圾的话就用原生或者看看别的框架了。

这东西烂不烂取决于你做什么。

SQLite垃圾吗，挺好用，但是你拿他顶个高并发，顶个百万数据试试？

人家就不是干那个的。

很多人在技术层面上天天瞧不起这个瞧不起那个，说起来好像也头头是到，Python写不了企业级应用，php性能不好，Golang轮子太少，Java太过臃肿，vue不优雅，react滥用魔法，泛型太过死板，any又对项目可读性有损害，Mysql顶不住单表两千万数据。这些发言我常在一些技术讨论下的评论区看见。

我倒是觉得技术本身不能当饭吃，技术只是手段，钞票才应该是目的，只有在你的目的充分的达到了之后才应该去考虑一些精神层面，或者说追求层面的问题。

uni很大程度上挡住了一些烦人的甲方，这东西到底能节省多少成本我相信用过的人是很清楚的，给大伙看一个上个月遇上的甲方。

从甲方这个需求中我们能抽象出几个端呢？安卓，IOS，H5，微信公众号，后台管理(Web)

如果原生开发，就算每个端只需要一个人，这个破项目光前端，即便吧公众号和H5合并也要四个人，我都还没算鸿蒙，得亏人家没要求必须是 .hap 的包，不然安卓还要再加一个端。

而这个项目才十几万，我要是去找两个做原生的同行，再找个H5同行来帮我，十几万收入至少减一半。

这就是Uni存在的价值和意义，它是很多地方不好用，它是性能不够，但是你原生性能再好能写一遍代码打包运行四个环境？

老拿性能说事对Uni其实不是一个好的攻击点，因为作为一个有经验的开发，判断一个项目对性能的要求有没有超过一个套壳Web所能提供的能力，我认为是很容易判断的。

如果甲方要做一个直播，要PK要打赏要连麦，还要各种礼物特效和实时的视频特效，这种需求你为了节省成本用Uni做，且不论你有没有职业道德，做完怪Uni性能不够我觉得是很没有道理的一件事，他就不是干这个的。

Uni的烂，更多体现在文档和API，编译的时候烂，还有偶然需要调用一些系统底层的内容，而又恰好没这个插件的时候，这种时候会一下吧之前节省的时间补回来。以及那个HbuildX编译器更是让Uni屎上加霜。

还有人提taro，taro跟Uni属于是一个巧克力味的屎和一个屎味的巧克力。都烂，但是有时候不得不吃。

硬要比的话taro开源，不必担心闭源打包会给你塞没办法审查的代码。

这玩意我对它的定位就是用来做轻量级(乐色)的APP，顺便送一套小程序，不建议对它抱有过高的期待。

年轻时候的我，只会对uniapp嗤之以鼻，什么垃圾，这啥性能啊，编译这么慢，还一堆限制，还有bug！

现在的我只会说真香，叫亲爹app也不为过。

早期的uniapp虽然有bug，开发起来相当的难受，但总体时间还是比写几套代码来的快。早期领导们还不懂行，我做h5和小程序都是要的两份工时，多余的时间自然是自己摸鱼去了。

现在呢，我也有了些人脉资源了，接点外包做做APP，H5，小程序啥的，我也能跟客户多要个几倍的钱，而且还不用去学习新的语言，多的时间和钱花在个人和家庭上，真香。

当然你要从技术层面来说，uniapp确实没啥创新，性能也不算很好。你有技术追求的话，就多学习多卷，写各平台原生（浏览器，安卓，ios，各平台小程序）的那就是最快的。我就不奉陪了，我赚我的钱，我多余的时间摸我的鱼，您就卷技术去呗，大家各取所需。

您学您的技术，我摸我的鱼。但国内很多人呢，就是，又要靠人家吃饭，又要骂人家，jian啊