在知乎上看到个问题
uniapp 真的很垃圾么？
我就想着好像确实没看到过，比较笼统的介绍 uniapp 的文章，很多都是上来就是怎么用/踩坑记录之类的。
就想写一篇，我使用uniapp开发的体验，讲一讲它的优缺点。很多一提到 uniapp 就是辣鸡/狗都不用之类的状态，包括我自己刚开始用 uniapp 的时候也是这种心理，主观比较强，不太客观。接下来我尽可能的客观一点讲讲uniapp 开发过程中的优缺点，希望可以帮助到正在考虑是否要用 uniapp的大家。
因为现在公司的原因，写 uniapp 也 3年多了。最开始写呢，是因为外包交付过来的就是uniapp开发的小程序。本来外包代码质量就不太好，然后我本来是react栈的，不是很喜欢vue2的语法，就导致我一开始对 uniapp 特别抵触，觉得什么垃圾，还不如用 react-native。这个外包交付的项目加上后来用 uniapp + vue3 + ts 做了2个app，都是长期维护迭代，到现在也算是非常熟悉 uniapp 了。
我就以我的体验来评价一下uniapp，欢迎讨论。
这一切的前提是你确实有跨端开发的需求，希望是一套代码多段打包这种情况。如果就单纯开发某一个平台的 app 或者 web 之类的，快跑。
先说优点吧：
- vue 语法，脚手架也算方便，web开发基本上可以无障碍上手。只需要看一些基本配置介绍，了解清楚文档结构，知道去哪找什么配置就行了。就类似于 react 用 antd，或者 vue 用 element 这种，愿意查文档 + 搜索引擎基本上可以说是无痛开发常见功能。
- 跨平台，这也是算是 uniapp 的立身之本吧。react-natvie/flutter 不能开发小程序，taro又不能开发 app（现在是可以转 rn，我没试过，不知道效果如何）。uniapp 先不说开发体验/性能这些，起码一套代码加一部分条件编译，就可以同时适配web&小程序&app。
- dcloud 有相关配套生态，比如云打包/云发布/uni-static之类的。在一定程度上我觉得是减轻了运维负担，对于人手不足的公司来讲还是蛮不错的，毕竟不是所有公司都有配套的完整的开发团队。
- 社区纯中文，不要小瞧这点，虽然现在看英文文档似乎已经是开发的标配了，但是拿我自己来讲，看英文文档转换率很低的，有些需要仔细反复阅读才能比较好的理解意思。中文则大多都是瞟一下就大致懂了，当然文档写的烂就会出现看英文的效果（每个字我都认识，怎么组成句子了我反而不懂了），uniapp 的有些文档就有这个感觉，这是缺点我放下面单独说
接下来说缺点：
- 社区垃圾的一批。我觉得这个垃圾是双方的，一方面官方似乎没有太多精力运营维护社区，一方面用 uniapp 的开发者大多数的目的就是快速开发迭代，不愿意花太多精力去研究。结果就是，官方又不能较快的响应，用户的提问/答案质量又很差（其实官方的回答质量也很差）。又不像 github 这种，我直接issue 里提交个repo，别人可以相对容易的复现问题。最重要的是，对于普通开发者，在这个社区里贡献其实没啥收益。github 如果是对某个有点知名度的仓库提过 pr 之类的，起码简历上还是可以吹一下。
- 文档做的比较垃圾，可能是迭代的太多了，文档维护不过来。先不说内容表述的是否清楚，文档里很多连接都失效或者是老版本的内容。功能比较复杂的框架，文档本身就比较难维护，能理解。但是呢，echarts api 还是蛮复杂的嘛，文档内容也多。它提供的在线 code，可以直接快速验证配置效果这些，我觉得就很提升效率。
- 跨平台的通病，对不同平台的适配表现不好。比如你本来是开发 web，各种直接操作dom，想转成 app 或者小程序就直接裂开。再比如很多库表现不同，比如 echarts 在web 就能正常，app 就有的配置会失效之类的，这个我估计主要是 canvas 的兼容性。其实客观来讲，这个不能叫缺点吧，跨平台兼容性是一直存在的问题，并不是uniapp 一家这样。
- 本地打包太难受了，因为受不了云打包在高峰期排队，在提测阶段非常低效。就自己弄了 ios 和 andoird 的工程和流水线做本地打包，就很容易出现两边工程配置不同。这个主要是 uniapp 机制造成的，它是先打包 uniapp 的内容，在分别用包的内容在 ios 和 android 的工程里打包，容易出现配置不同步的情况，特别是多人开发的时候。如果可以根据 mainfest 自动生成基本的AndroidManifest.xml和 plist.info 就好了。
- Hbuilder 太难用了，我平时开发基本上就是 vscode + cli。作为 ide，HBuilder 从 ui 和功能上都让我觉得比 vscode 差的不是一点点，拿他们俩比，我甚至觉得有点侮辱 vscode 了。但是又需要开hbuilder去dev热更新，就很难受。我也尝试过自己写脚本热更新包内容到本地 ios 和 android 工程，确实不如直接 hbuilder 方便。我觉得 dcloud 不如考虑一下，开发个vscode 插件，放弃 hbuilder，或者套壳魔改 vscode（doge）
- 插件市场四舍五入跟没有是一样的，我就没看到过比较好的插件，有些付费的插件都做的稀烂，不如自己写，起码出了问题自己好查。
这里就不讨论性能问题了，无论是 react/vue，或者 flutter/rn/uniapp 哪个性能更好/渲染更丝滑之类的，都不是我选择技术栈的主要因素。首先，我自己没有验证过，虽然网上有很多讲 flutter 渲染性能多好多好，rn多差多差（好像重构了，据说现在性能还不错？）之类的。其次，本身业务场景也很少做 canvas动画或者超大量的 dom 操作，所以几乎没渲染性能要求。我一直觉得对于普通web开发者，大多数性能问题，主要是自己的代码设计或者实现的有问题，而不是框架的问题。有的写代码连基本的时间复杂度都不考虑，还说为啥点击反馈慢。基本的时间换空间/空间换时间还是要有点概念嘛。退一步说，量大了能不能从需求层面进行优化，非要上来就要在前端处理几十万数据么，这合理么。
扯远了，本来还写了 webview 通信，但是细想一下，小程序里 webview 本身就通信机制不咋地。不像 ios 或者 android 里 jsbridge，可以更好进行通信。uniapp 的 webview 通信自然也会受到一些限制， h5plus 啥的也可以在 app 里做一些 webview通信，也不算是啥问题。
最后做个总结，就是如果只是做常规的 app，不涉及特别多或者复杂的canvas/dom/文件读取操作之类的，uniapp基本上是无痛使用。但是反过来，就要慎重一点。 尤其对于团队配套不足（小公司/独立开发者之类的） 又需要多端的，如果没有特别的技术喜好， uniapp其实是一个很不错的选择（甚至是唯一的选择）。希望大家不要掉进那种技术鄙视链里，技术永远都只是工具。没有跨端开发需求的话，一定有多远跑多远。用 uniapp 要做好遇到一些阴间问题，叫天天不应叫地地不灵，只能自己硬干的心理准备。
我现在维护的一个app用arcgis做地图，问题多的一批，我现在都还有个图层在web和android里能渲染，在 ios 里渲染不出来的问题没解决，还好不是优先级比较高的，领导也就想起来问一下情况。 echarts 也经常抽风，比如之前发现 Axis 的 formater函数在 app 里无效。反正遇到这种问题大概率是很难从原理上解决，只能变着法通过一些歪门邪道处理。
希望这些内容能帮到你。
愿世间没有跨平台开发！太费头发了。
