公司新产品要求发布到各家小程序,最近研究对比了社区主流的几家小程序开发框架,独坑不如拉人众坑,分享给各位,欢迎和我一起入坑:)
背景
最近老板不知怎的很重视各种小程序平台,感觉要靠小程序完成今年大半kpi。。。
产品和运营自然找我们要方案,一方面要快速铺开各种小程序,另一头hr又不给前端团队加headcount,我只能
目前几杆枪,主要在微信和H5上,若按照各家规范进行原生小程序开发,肯定是不够的;
所幸业内有人在做跨各种小程序的框架,趁机研究一番,看看到底做的怎么样。
可选的小程序框架
我们主要分析了如下小程序开发框架(应该差不多全了),主要包括:
框架 | 技术栈 | 案例 | 微信小程序 | 支付宝小程序 | 百度小程序 | 头条小程序 | H5 | App |
---|---|---|---|---|---|---|---|---|
Taro | React | 丰富 | ⭕ | ⭕ | ⭕ | ⭕ | ⭕ | ⭕ |
娜娜奇 | React | 少 | ⭕ | ⭕️ | ⭕️ | ⭕️ | ⭕️ | ❌ |
wepy | Vue | 丰富 | ⭕ | ❌ | ❌ | ❌ | ❌ | ❌ |
mpvue | Vue | 丰富 | ⭕ | ❌ | ❌ | ❌ | ⭕️ | ❌ |
uni-app | Vue | 丰富 | ⭕ | ⭕️ | ⭕️ | ⭕ | ⭕️ | ⭕ |
megalo | Vue | 少 | ⭕ | ⭕️ | ⭕️ | ❌ | ❌ | ❌ |
OKAM | Vue | 少 | ⭕ | ⭕ | ⭕ | ⭕ | ❌ | ❌ |
Mpx | Vue | 少 | ⭕ | ❌ | ❌ | ❌ | ❌ | ❌ |
我们的筛选权重:
- 跨端:权重最高,毕竟第一诉求就是覆盖各家小程序,故wepy、mpx这种针对微信小程序的增强型开发框架首先排除,其次mpvue虽支持 H5 平台代码复用,但未跟进其它几家小程序,也放弃;
- 案例:权重次之,案例多说明使用者多,坑应该都踩得差不多了,有坑也应该是明坑;案例少的话,就要自己上去踩,暗坑多少不清楚;从官网公开案例来看,taro、uni-app公开展示的案例是最多的(mpvue、wepy虽案例也很多,但已被权重最高的跨端能力给淘汰了)
- 技术栈:权重再次之,我们团队对于react、vue技术栈都有涉及,只是使用深度问题上有差异
最后,我们决定把taro、uni-app两个框架作为候选,做进一步对比。
uni-app其实内置了mpvue,感觉是个加强版,拓展到多端了。
其实这2个框架的github star差的有点多,taro远超uni-app,但不能根据这个直接做决定,对比报告还是得做的,果然最后发现不能以star取人。
Taro VS uni-app
看了几天文档对2个框架大概摸到门道,理了下对比思路,还是认真从如下几个维度比较下taro、uni-app两个框架:
- 跨端程度:真实运行项目到各平台,对比平台差异抹平程度
- 运行性能:框架是否带来了额外的性能开销,降低用户体验
- 开发体验:是否支持现代开发流程,是否对工程师提供高效友好的协助
- 社区生态:社区是否繁荣,是否有大量可用轮子?
跨端
数量对比
双方都宣传能支持微信、百度、支付宝、今日头条等小程序,H5,以及iOS和Android的App。看起来都不错。
质量对比
为验证最终跨端效果,我们分别下载 taro、uni-app的示例项目,体验编译到不同平台的运行效果。
首先选择 taro 官方账号下的知乎小程序示例(github地址),运行到各端后的效果:
从如上截图来看,taro成功实现了多端编译;我们接着更细致的对比了一下各端运行,发现taro在如下方面存在问题:
- H5端:选项卡高亮状态错误,如上图,内容显示的是第二个选项卡,但底部高亮的依然是第一个选项卡
- H5端:下拉刷新不生效
- 百度小程序端:下拉刷新触发后,回弹失败;若页面同时存在下拉刷新和上拉加载,则和页面滚动冲突
之后点击二级页、三级页,发现H5端的其它问题:
- 所有页面缺少导航栏,小程序端导航栏是原生控件,taro在H5端未对应生成
- 跳转到二级页后,底部选项卡依然不消失,难道所有页面都要包含选项卡?如下图所示,不合理
针对这些问题,我们复查了一遍taro官网,官网倒是明确说明部分事件函数在H5端不生效,主要包括:
方法 | 作用 |
---|---|
onPullDownRefresh | 页面相关事件处理函数--监听用户下拉动作 |
onReachBottom | 页面上拉触底事件的处理函数 |
onShareAppMessage | 用户点击右上角转发 |
onPageScroll | 页面滚动触发事件的处理函数 |
onTabItemTap | 当前是 tab 页时,点击 tab 时触发 |
不过进一步仔细发现,taro文档里大量存在只有微信平台打勾的情况,H5和App侧大量的X。这说明跨其他平台很难平滑迁移。
接着运行uni-app示例项目,选择官方账号下的看图App模板(github地址)测试,运行到各端后效果:
从上图来看,uni-app 同样成功的实现了多端编译;我们接着更细致的对比了一下各端运行,发现如下问题:
- 支付宝平台:下拉刷新、上拉加载无效
之后点击二级页、三级页,没再发现明显问题。
从两个项目的实际运行来看,uni-app的跨端效果更好(其实不止对比了官方demo,我们自己也写了小demo),特别是在H5平台相比taro要完善不少。
另外,在进行两个框架的发行编译时,我们还发现了一个差异点:
- taro 的
dist
目录下不区分编译平台,同一时间仅可编译到一个平台,不支持多个平台对比查看运行效果; - uni-app 的
dist
目录区分编译平台,故支持同时编译到多个平台,可同时对比查看不同平台运行效果,这个体验是不错的,更有跨端开发的感觉
另外uni-app的条件编译比较完善,这个在处理平台差异时很有用。
案例对比
两个框架都在官网放上了众多案例,只是taro案例清一色是微信小程序,没看到其他端,难道大家使用taro,只是为了用react开发微信小程序,不需要跨端?
uni-app的案例什么平台都有,很多App做了多个平台。说起来我们领导还问过跨iOS、Android App的事情,不过目前另有原生团队,我们也只是做个备份调研。最终还是决定先把前端的技术统一了,稳定后再考虑App是否也迁移到这类框架下。
综合比较,uni-app跨端质量更好,真实跨端案例也更多。
运行性能
我们在网上查阅了一些文章,有人认为taro的运行性能好于mpvue,而uni-app集成了mpvue,这个性能问题就得重点关注了。
不管是taro还是uni-app,setData
的优化都是小程序性能优化中最为重要之事,且优化主要有两个方向:
- 尽可能减少
setData
调用的频次 - 尽可能减少单次
setData
传输的数据
然后在调研中发现,uni-app其实还集成了另一个前述参选的框架megalo
(怎么都被它揉进去了)
前面调研时知道megalo
是做了差量数据更新的,那就应该问题不大。
我们自己动手写了一个长列表测试,分别写了taro版、uni-app版、原生小程序版,前几页数据滚动时差不多,7、8页过去发现uni-app加载新页面时有变慢的感觉。
推测uni-app的长列表没有recycle机制,花了点时间把demo改进了下,滚动下面时把前面几页的数据干掉,然后再滚动就感受不到流畅度的差别了。
总结:taro在性能优化上做的更细致,使用uni-app需要自己注意代码优化。
开发体验
taro 和 uni-app 的环境搭建及项目创建、运行编译都比较简单。
taro的安装及使用:
# 全局安装 @tarojs/cli
$ npm install -g @tarojs/cli
# 创建 taro 项目
$ taro init myApp
# 进入项目目录
$ cd myApp
# 运行到微信小程序,调试模式
$ npm run dev:weapp
# 发行到微信小程序
$ npm run build:weapp
uni-app的安装及使用:
# 全局安装 vue-cli
$ npm install -g @vue/cli
# 创建uni-app项目
$ vue create -p dcloudio/uni-preset-vue my-project
# 进入项目目录
$ cd my-project
# 运行到微信小程序,调试模式
$ npm run dev:mp-weixin
# 发行到微信小程序
$ npm run build:mp-weixin
开发流程方面,taro和uni-app均是以微信小程序为基础,也都针对小程序的开发弊端,提供了更优秀的体验,比如:
- 均支持使用 npm/yarn 安装管理第三方依赖
- 均支持使用 ES6 甚至更新的ES规范
- 均支持使用 less/scss/ts 等预编译器
- 均支持进行应用状态管理,taro 支持 Redux/Mobx,uni-app 支持 vuex
开发工具方面,taro官方未特别推荐IDE,但提供了vscode支持的d.ts;
uni-app推荐的开发工具是他自家的HBuilderX,用它可以不配环境,开箱即用;
hbuilder以前接触过,当时没深研究,新版还挺让我意外,真没想到国人的开发工具可以做到这样,尤其是他家的markdown支持真心不错,于是本文就是在hbuilder里写的(已经有情感分了哈哈)。
总结:两个框架都支持现代前端开发流程。hbuilder对uni-app提供了优化定制,但对不熟悉的开发者有一定适应成本。另外hbuilder自带一个编译器,和cli装在项目下的编译器是2个,这个坑不少新人要注意别踩。
社区生态
学习交流
Taro通过Github Issues+微信群方式交流,微信群活跃,贡献代码的人也多。
uni-app有专门的论坛,还有视频教程,QQ群微信群都活跃。
另外文档角度,uni-app的文档比taro要完善,数了数交流群的数量,也是uni-app多不少。
生态
taro官方发布了taro-ui库,awesome里三方组件不太多。
uni-app官方发布了uni-ui库,还有个插件市场,里面轮子很多,做业务应该可以很快拼轮子做出来。
基于公司业务及团队人员技能考虑
橱窗里的衣服再漂亮,适合自己的才有用,开发框架亦是如此。
我们根据业务需求及团队成员现状,形成如下对比:
- 如何在有限前端团队人数下搞定更多平台,是我们的首要考虑,我们可不想踩太多坑导致任务完不成,跨端方面uni-app更成熟;
- 团队里熟悉vue技术栈的同学多一点,全员培训react的风险还是略高,使用uni-app内部培训时间短、风险低。
因此,我们团队最后决定使用uni-app作为新项目的开发框架。
但挺诚心感谢其他开源框架的作者的,各位大牛的无私奉献,让我们可以节省这么多人力,拜谢!
喜欢taro的朋友也莫喷我,大家各有所好,react和vue谁更好之类的骂战就不要继续延续到这里了。
接下来肯定会有很多uni-app的坑,等着我们去跳,但我等猿类的宿命就是不断跳坑、爬坑ㄟ( ▔, ▔ )ㄏ,待我们项目结束,再写一篇《uni-app爬坑血泪史》分享给大家。