一句话总结就是,坑是真的多,填完一个坑等着你的就是下个坑。
缘起
因为所在项目组属于生活服务类相关的,需要做电影、蛋糕、打车、加油、车票、酒店等一系列的板块,需要嵌入在其他项目的 app 、小程序、h5 中。我们需要提供 H5 和 小程序双端服务,由于每个项目周期又短,为了节省开发周期时间,所以选了 uni-app 来开发。
初识
uni-app 使用上,基本上和普通 vue 开发差不多,只要避免直接使用 web api 就可以,捋一遍文档基本可以上手了。踩得的第一个坑来了,由于我入职时第一个板块已经开始做了,项目使用 HBuilderX 创建的。HBuilderX 创建的项目只能使用 HBuilderX 启动,HBuilderX 这东西也不好用,只能再开个 vscode 开发了,开发阶段也没觉得啥,无非多开发编辑器多占点内存。
等测试阶段傻眼了,HBuilderX 创建项目只能再 HBuilderX 构建发布,没法集成到现有 CI/CD 上去,再 HBuilderX 打包就打包吧,这玩意还强制登陆,一个编辑器不登陆还不让打包。搜索了一下,还是有方法将 HBuilderX 创建项目转换成 cli 形式的,不过由于项目模块导入方式混用,无法无痛切换过去,项目也快上线,于是就没有去折腾了,在下一个项目去切换到 cli 方式。
生态
uni-app 有自己插件市场,有很多现成的插件可以用。但是呢当你去下载插件是骚操作来了,首先是强制需要你登陆,然后登陆后还需要你强制看广告才能下载,这波骚操作真的是骚。有些作者希望整点插件赚点外快,可以收费下载可以理解,但是别人免费开源的插件,uni-app 还强制你扫码看广告是真的恶心了。
uni-app 一直都在加新功能,对于 bug 处理速度真的是慢,官方论坛一大堆没人回复的问题,一个劲的堆新功能,bug 没见修复多少,bug 全留着当传家宝了。HBuilderX 也是有点离谱,第一次在开发者工具里边看到招聘广告的,只能说 newb 了。
踩坑
定位
在 H5 中 uni.getLocation,内部抛出异常,没做处理,导致无法捕获到,也不会进入 fail 回调,导致无法得知定位失败。比如 地图 key ip 定位超上限, navigator.geolocation 定位失败等。
解决方式:
h5 端自己对 navigator.geolocation 封装,其他端使用 uni.getLocation。或者对 uni.getLocation 进行封装增加超时设置,超过几秒未返回,返回默认定位点。自己封装 navigator.geolocation 需要做好坐标转换,应该浏览器默认返回是 wgs84 ,需要自己转换为 gcj02 或其他的坐标系。
定时失败时候,只要你配置了地图 key,就会使用对应地图服务商 ip 定位。因为正常情况下前端的地图的 key 只需有地图绘制相关功能使用,不需要包含地图服务商 WebService API 功能的, 为了避免盗刷也不会将 WebService API 的 key 存放在前端,这就导致你使用 uni-app 的 map 组件,就会使用 ip 定位,但你的 key 并不支持。
解决方式:
和上面处理方式一样,最直接就是自己封装 h5 定位,将 ip 定位地址,替换成自己服务器地址作为代理。
uni.openLocation 在 vue3 + ts 中,H5 端是以组件形式存在的,不想其他 vue2 是以路由形式存在,看内部实现并没有监听路由变化卸载组件,会导致通过浏览时返回上一页时,组件还是覆盖在页面上。
解决方式:
自定义查看位置组件,在 H5 端替换掉 uni-app 的。
map 渲染问题
uni-app 的 map 封装了一些覆盖物绘制属性。比如绘制多边形区域绘制,如果在地图绘制前就已经给 map 的 polygons 属性设置了数据,第一次打开页面不会生效。避免这种情况出现,需要在地图渲染后在设置这些数据,但是在 updated 事件触发后立即设置也会出现问题,这种情况在第一打开页面时生效,第二次进入时候会出现不生效情况,未找到出现这种问题原因。
解决方式: updated 事件后,再加入定时器延迟执行绘制操作。
嵌套渲染
有多个 v-for 嵌套渲染时候, 内层的 v-for 上的点击事件在小程序中无法触发。
解决方式: 将部分 v-for 拆分成组件形式,避免页面上 v-for 嵌套过多。
其他
组件差异性
有些组件会在不同平台出现不同差异效果,需要你慢慢去踩坑填坑,一个个的趟过去。比如 popup 组件,小程序会出现滚动透传问题,而在 h5 上做了兼容处理,但是如果你打开后,未关闭直接跳转到新的页面,会导致新的页面无法滚动,需要在路由变化时关闭当前页面里的 popup 组件,这种问题真的是只能自己遇到一个填一个了。
文档混乱
uni-app 做了很多平台封装保证 api 的一致性,但是还是会经常写着发现平台不支持,只能自己另辟蹊径。
结语
由于没有 app 需求,不知道在 app 上坑多不多,据以前同事使用体验来看据说坑更多🤣。不过对于一些简单应用可以尝试使用,毕竟能一套代码构建多端还是能提升不少效率的。但是你的应用复杂起来,什么多端开发,提高效率,这玩意效率真的不一定能高到哪里去,还不如分开效率高.
- 本文链接:
- 版权声明:本博客所有文章除特别声明外,均默认采用 CC BY-NC-SA 4.0 许可协议。