uniapp_为什么大公司不用uniapp

Uniapp适用领域

搞外包可以，做持续可维护高质量的产品，不太适合。

Unia2021年了，uniapp发展的怎么样了?

来自某乎用户（）[1]：

从19年将信将疑接触，到2020年一边写一边骂，到现在，我基本认可。

认可的原因：

1、技术选型方面：公司产品有全平台运营的需求，前端技术多基于vue开发，且有成本要求，所以在多次选择中都把它作为首选。

如果只需要做app的话，其实有很多其他的替代方案，像weex、rn，应该都有不错的组件库。我们在选择uni之前，还使用过eros，是基于weex的，对于原生和热更新方面都支持很好，可惜去年停止维护了。

另外，很多人说uni-app是套壳的html，其实不是的。uni的nvue模式，是基于原生引擎渲染。

2、维护方面：相比之下，uni更值得信赖的，我认为是他们的定位。我最开始了解他们的产品，不过是hbuilder这个编译器，后来才知道他们不仅要做全平台的功能框架，而且还要支持像统计、推送、广告这些变现项目，走的是生态发展思路。这至少证明他们在目前来看是赚钱的，加上开发者用户基数接近千万，我相信没那么容易狗带。

对于版本更新，我们虽然每个星期都要吐槽一次，但总的来说成本还是可以接受的。

3、技术支持：刚开始接触的时候，由于对框架的理解不够，我遇到很多抓破脑袋都想不明白的问题，但是和技术专家直接对接请教后，都得到了及时的解决。

4、文档和社区：他们家的文档我基本上都是夸的。社区也很活跃，平时遇到的问题基本能搜索到。

5、兼容问题：个人觉得很满足了，写一套代码，三个端运行。只是，这个前提是要很好地理解weex规范。基于这个前提，大部分的样式和功能是兼容的。当然，前期肯定要有一段时间的试错。不过对于严重依赖原生的功能除外，如canvas

说了这么多好话，再来吐槽一下我的怨言：

1、最最最想吐槽的，就是打包。app的打包分两种模式，一种离线打包，一种线上打包。

离线打包是要使用原生打包方式的，如android的studio、ios的xcode，是把我们在uni这边编写的文件打包成资源文件，再放到原生环境下打包。而原生环境需要用到uni这边一大堆的lib包，你知道的，他们每星期至少更新一次，这意味着我们每个星期都要更新lib包。而且每次更新之后的打包，都可能出现一些奇怪的西西。。。

所以我们换成了线上打包，说起这个打包，我真的，咬牙切齿。uni大概是为了支持自己的统计，多渠道打包的话就只支持官方的，你要用别的，就只能一个一个打。要知道，我们公司5个产品，11个应用市场，每次更新一个产品至少有一两个小时浪费在打包上。

而且线上打包收费，每个账号每天限免5个，之后一个包两块钱。但是没办法，只能这么办。

2、渲染方面：依我目前的经验来看，uni支持交互更简单的场景，对于复杂交互，支持度较差，编码难度也更高。nvue模式虽然也支持原生插件，但是如果你有编写原生代码的实力，倒也不必在这里花功夫。

怎么说，这也不能算是个坑。做技术选型的时候，就要搞明白，自己的产品对交互方面的要求是什么样的。还有公司目前在什么样的发展阶段，究竟是要为了成本考虑暂时快速开发，还是要为长远发展从一开始就做到精致。

3、编译器：hbuilder几乎在方方面面都能被vs code秒杀，这我就不说了。只不过，你用了他们家的产品，就得附带用这个编译器，免费的午餐多少也得付出一点代价，能满足满足基本的开发需求就得了。

4、组件库：uni组件库不少，但如果用nvue模式的，可用组件真是少得可怜。目前我见过比较好的两个组件库，mypUI、graceUI。myp我们自己用过，虽然调用简单，但是耦合性太高，后来参考他们的思路写了个适合我们自己的。grace说实话是在这个问题下面看到的，因为收费，所以还没买下来具体去了解，但应该还可以，等后面空了再看看。

我们公司目前的几个产品，组件基本徒手撸的。记得最开始上手的时候，一个复杂一点的表单，我写了整一个星期，就是因为uni自带组件原生化程度太高。尤其是picker，数据要动态组装，监听一大堆，像着各种情况，你就不得不自己去封装。

不过还好，写到后面，自己的东西基本都能复用，后面的开发速度和成本会将前面的摊平。而且写的组件也可以放到插件市场上去。

另外，关于稳定性。我之前开发过原生Android，是会经常遇到程序卡死、闪退的情况的，但是uni开发很少遇到。

大概就是这些了，开发过程中具体的问题我也不能详尽，只是觉得使用了一年多下来，所遇到的问题多多少少的都处理掉了。

总而言之，如果你的公司规模不大、对原生技术没有那么追求、对交互要求不过分，相信uni-app还是值得一试的。只是前期多少会走弯路，要有这个心理准备。

这为乎友的主观感受颇深：

作者：社交联盟流量共享
链接：https://www.zhihu.com/question/444976489/answer/1971329385
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
 

本人典型的吃饭砸锅，希望uniapp越来越好，也真的觉得官方好讨厌，好不务正业，是真的不会考虑开发者的看法，固执己见，一切为了他们所谓的开发效率，你搞个ai开发不更提高开发效率？抬杠谁不会，都是个取舍，别说你们做的就能更多的提高开发效率，你好好修复uniapp的bug，修一个bug，开发者们就少用几个小时去解决问题，这不是在提高开发效率？

动不动就给你来句一切向开发效率妥协，问题是除了uniapp其他的东西你提高毛线开发效率了啊，

1. hbuilder官方自认好用，胜webstorm，你能顶他百分之50，我就觉得你做的有意义，啥也不是，多看看评论区，github的issues里用户怎么说吧，老说自己用户多，比webstorm多，也不知道你咋统计的，你统计有多少人是一个月用一次，打包才用一次，或者迫不得已才用的了吗，自己骗自己好玩吗
2. uni_cloud，uni_modules，集成后端能力插件，提供免费数据库，不用写后端代码，js梭哈

免费的数据库，外部无法使用正常方式访问，用了他的数据库就必须用他的cloud，不兼容其他后端代码，其他后端代码想要调用数据库内容，可以是可以，反正比正常后端应用访问数据库是难多了，别人要访问你的接口，一定要提前配置允许的ip啥的，开放接口这种需求肯定是不支持的了。

可能跟经历有关，我不知道谁家数据库里的数据是只有一个应用使用的，后端那些各种功能特性肯定是都不支持。

就目前这种情况，你作为一个附加功能来说，是不错的，可非要作为一个对标后端的功能来说，就垃圾的要死了。

本人经历有限，所以就我看来，没几个正经公司会用uni_cloud的去上生产，也就是搞个小demo级别的项目，这玩意想限制一大堆，谁敢用。

自己接触的公司，项目，也还都是在用标准的后端，没几个用这玩意的，不是说不好，是还不完善，没到强推的阶段，就跟50年前你非要强推下线自动驾驶汽车一样，撞死一堆人。

这东西可能也就萌新感兴趣，接触接触，可真正的萌新有多少人，大部分还是搞了几年开发，上了几年班的打工人，谁公司没几个后端，谁不懂点后端。就感觉官方意淫出来一个小需求，就自己高潮了，嗨皮了两年了，有效果么，有数据吗，欢迎贴个数据打脸，劝浪子回头，迷途知返，别越陷越深，你越高越好我拦不住你，你搞了半天没效果，还不知道反省吗

啥都要自己搞一套，你有那么多员工吗，人的精力有限，专注做好一件事，做精湛不好吗，啥都要搞，啥也搞不好，气死，uniapp给我带来了很多好处，但官方不务正业也让人好难受，就发泄发泄

真心希望dcloud能专注，跨端编译这件事，少搞些乱七八糟的绑定，什么编辑器、uni_modules,uni_cloud全都绑定他家全家桶，只能用他家的。

信仰技术的，不都应该喜欢开放自有，拥抱开放的生态么，什么都要自己搞一套，又不跟别人相同，难用的要死.

[2]

长远角度出发，还是先别碰Uniapp了...

参考：

[1]:https://www.zhihu.com/question/444976489/answer/1847318055

[2]:https://www.zhihu.com/question/309676351/answer/786889882