自2017年1月9日微信小程序诞生以来,经过2年多的迭代升级,已上线数百万小程序,成为继Web、iOS、Android之后的第四大主流开发技术。
有了它,小程序的开发生态也在蓬勃发展。从最初的微信原生开发,到wepy、mpvue、taro、uni-app等框架,从刀耕火种进化到现代开发。 ,生态越来越丰富。
选择太多,问题来了,开发小程序,到底该用原生还是三方框架?
首先,微信原生开发中的大部分槽点如下:
原生开发对Node、预编译器、webpack的支持不好,影响开发效率和工程构建过程。一个不伦不类的语法,不如认真学vue和react,学会通用,不只是为了微信小程序。 vue/react生态中有太多可以提高开发效率的周边工具,比如ide、validator、第三方库等。 . . 相比专业编辑,微信的ide真的不好用。
同时,开发者对三方框架总是有各种顾虑:
怕性能不如原生,又怕有些功能框架无法实现,只能用原生框架,怕不稳定,跳坑和许多三方框架。我应该使用哪一个?
面对如此纠结的场景,很多热心的开发者发表评测文章分享心得,但我觉得意见不一,信息过时。缺乏当今流行的非常专业、深入或“核心”的评估报告。
做评估报告不同于一般的经验分享,其实很费时间。它需要:
也就是说:评价要真实,努力要深!
uni-app 团队花了 2 周时间完成这份报告,并坚持每季度更新这份评估报告。当前更新时间为 2019 年 5 月。
本文从面向用户和面向开发者两个维度以及七大细节对微信原生与主流的wepy、mpvue、taro、uni-app开发框架进行横向对比,希望对小众开发者有所帮助在选择程序框架时提供参考思路。本文基于各个框架官网可以收集到的公开数据和真实测试数据,希望客观公正地评价各个框架的现状和优缺点。不过由于利益关系,这篇文章的观点很可能有偏颇小程序开发,大家可以用批判的眼光来看待。如果您发现本文的评价有任何歪曲,欢迎您在此报告issue。
面向用户和面向开发者的维度,包括:
用户:提供完整的业务实现,确保高性能体验开发者:平缓的学习曲线、现代化的开发体验(Engineering)、高效的社区支持、积极的开发迭代、多终端复用业务功能。
在web开发中,如果使用vue、react等框架让开发者无法操作浏览器提供的所有API,那么这样的框架肯定是不成熟的。 小程序开发同样如此,任何开发框架都不能限制底层API调用。
各种业务功能的底层依赖微信暴露的组件和接口(微信官网引入的组件和API规范,也称为微信原生API),三方框架基于微信原生的二次封装, 开发者这时候经常有一个疑问:小程序在不断迭代升级。如果一个业务依赖最新的小程序API,但是三方框架没有封装怎么办?
其实和web开发的vue和react一样,浏览器有一个新的API,不涉及vue和react的升级。本次评测中的所有框架都不会限制开发者调用底层能力。原因在这里详细解释:
注意:以上顺序以各个框架的诞生顺序为准,下同。
因此,三方框架可以调用所有的小程序API来满足用户的业务需求。这个维度的框架没有区别。
但是,不同之处在于性能体验。
1.2 表演经验
三方框架大多是分层封装的。这些封装会增加运行负载并导致性能下降吗?尤其是对比原生微信小程序开发的表现,这是大家普遍关心的问题。
为了客观对比,我们特地搭建了一个测试模型,具体如下:
我们以上述仿微博小程序为例,测试2个容易出现性能问题的模型Points:响应来自长列表加载,大量点赞组件。
1.2.1 长列表加载
模仿微博的列表是一个包含很多组件的列表。这种复杂的列表给性能带来了更大的压力。大,非常适合性能测试。
从触发上拉加载到数据更新和页面渲染完成都需要准确的时间。人类视觉计时绝对是不够的。我们采用程序埋藏的方法来制定如下时序:
提示:setData回调函数的开始可以认为是页面渲染完成的时间,因为微信setData定义如下(微信规范):
测试方法:从页面上的空列表开始,通过程序自动触发上拉加载,每次添加20个列表,记录列表耗时;以固定间隔连续触发N次上拉加载,使页面达到20*N个列表,计算这N次触发上拉到完成渲染的平均耗时。
测试结果如下:
说明:以400条微博列表为例,从页面上的空列表开始 外包小程序定制 ,每1秒触发一次上拉加载(新增20条微博),记录单条耗时,并20 次触发后停止(页面达到 400 条微博)。计算这 20 次的平均耗时。触发上拉->平均完成渲染时间876毫秒,uni-app最快741毫秒,mpvue最慢4493毫秒
当您第一次查看这些数据时,您可能会感到困惑。别着急,下面有详细说明
解释一:为什么mpvue/wepy测试数据不全?
在mpvue和wepy诞生之初,微信小程序不支持自定义组件。无法进行基于组件的开发; mpvue和wepy为了解决这个问题,将用户编写的Vue组件编译成WXML的模板,变相实现了组件化开发能力,提高了代码复用。在这种情况下,这是一个很好的技术解决方案。
但是,在这种方案中,当页面复杂,组件较多时,页面上的DOM节点数会大大增加,甚至超过微信DOM节点数的限制。我们在 Redmi 6 Pro 上进行了测量。当页面组件超过500个时,mpvue和wepy实现的仿微博App会报如下异常并停止渲染。因此,这两个测试框架在组件多的情况下,组件也多。 ,测试数据不完整。这也意味着当页面组件过多时,这两个框架就不能使用了。
dom 超出限制,请检查您是否犯了任何错误
Tips1:wepy官网,提到v1.7.2测试版添加为了支持小程序的原生组件,实际测试有很多坑。因为是测试版,官方也在issue中表示不推荐;根据官网文档,默认安装v1.7.3正式版,不支持Native组件
Tips2:wepy在列表中不到400条,为什么性能比微信原生框架高,这个和自定义组件的管理开销和业务场景有关(wepy编译成模板小程序开发,不涉及组件创建和管理开销),跟微博一样,在组件数据传输的时候,微信原生框架的性能优势就发挥出来了,具体看下面的测试数据。
注2:为什么测试数据显示uni-app的性能略好于微信原生框架?
实际上,当页面有200条记录(200个组件)时,taro的性能数据也比微信原生框架好。
微信原生框架主要是setData调用比较耗时。如果开发者不单独优化,每次都会传递大量数据;而 uni-app 和 taro 会在调用 setData 之前自动进行 diff 计算。仅传递更改的数据。
例如当前页面有20条数据。触发上拉加载时,将新加载20条数据。这时候原生框架通过如下代码测试,setData会传输40条数据
data: {
listData: []
},
onReachBottom() { //上拉加载
let listData = this.data.listData;
listData.push(...Api.getNews());//新增数据
this.setData({
listData
}) //全量数据,发送数据到视图层
}
复制代码
通过使用微信原生框架,开发者可以自行优化和简化数据传输。例如修改如下:
data: {
listData: []
},
onReachBottom() { //上拉加载
// 通过长度获取下一次渲染的索引
let index = this.data.listData.length;
let newData = {}; //新变更数据
Api.getNews().forEach((item) => {
newData['listData[' + (index++) + ']'] = item //赋值,索引递增
})
this.setData(newData) //增量数据,发送数据到视图层
}
复制代码
经过以上优化修改,再次测试,微信原生框架的性能数据如下:
从测试结果可以看出,经过开发者手动优化后,微信原生框架可以达到更好的性能,但是uni-app和taro相比微信原生的性能差距并不大。
这个结果,和web开发类似,也包括原生js开发,vue,react框架等。如果不做特别优化,原生js写的网页性能往往不如vue和反应框架。
正是因为优秀的Vue和React框架,良好的性能和良好的开发体验,使得原生js开发的使用逐渐减少。
复杂长列表加载下一页评测结论:微信原生开发手动优化,uni-app>微信原生开发未手动优化,taro > wepy > mpvue
Tips:有人认为uni-app和mpvue是一样的。早期uni-app确实使用了mpvue,但是因为性能和vue语法支持问题,重新开发了。
1.2.2 Like 组件响应速度
长列表中的一个组件,比如like组件,点击Unliked和Like状态时可以及时修改吗?是本次测试的评估点。
测试方法:
在Redmi 6 Pro上进行了多次测试,并计算了平均值。结果如下:
注意:即当列表数为400时,从点赞按钮到微信原生开发的应用程序状态变化需要111毫秒。
测试结果数据说明:
组件数据更新性能评测:微信原生开发、uni-app、taro > wepy > mpvue
综上所述,本次性能测试做了2次测试,长列表加载和组件状态更新,结合2次实验,结论如下:
微信原生开发手动优化,uni-app>微信原生开发不手动优化,taro > wepy > mpvue
2.开发者
在满足用户业务需求的前提下,我们来谈谈开发者的需求,从以下几个维度进行对比:
2.1 平滑的学习曲线2.1.1 DSL 语法支持
选择开发团队熟悉并能快速上手的DSL,这是团队框架选择的基本点。
首先,微信原生的开发语法,和 React 和 Vue 一样,有点不同。对于开发者来说,意味着学习一套新的语法,大大增加了学习成本。每个人都批评。
其他开发框架基本遵循 React 和 Vue(类 Vue)语法,其主要目的是复用工程师现有的技术栈,降低学习成本。此时,框架对原框架(React/Vue)语法的支持是一个重要的衡量标准。如果支持度低,原框架的语法差异较大,开发者无异于学习一个新框架。 ,成本太高了。
在实际开发中,发现所有的开发框架并没有完全实现web上Vue和React的所有语法:
Wepy的开发风格接近Vue.js,属于类Vue的实现,相比微信原生开发进步了一大步,但与完整的Vue语法相比还是有很大差距的,而且它的规则需要在开发过程中单独学习;
mpvue和uni-app框架都是以Vue.js为核心,通过修改Vue.js的运行时和编译器,实现小程序端的操作。 mpvue支持的vue语法略少,uni-app基本支持大部分vue语法,比如filter、复杂的javascript表达式等;
taro 对 JSX 的语法支持也达到了绝大多数的支持完整性。
DSL语法支持评估:taro,uni-app > mpvue > wepy > 微信原生
2.1.2 学习资料的完整性
完成官方文档,问题搜索,demo演示:
教学课程:
学习资料完成评测:微信原生>uni-app>mpvue,taro>wepy
2.2 现代前端开发经验
在开发体验方面,明显劣势是微信原生开发,主要区别在于:
其他小程序开发框架都支持cli模式,可以在主流前端工具中开发,基本都有d.ts的语法提示库。
由于mpvue、uni-app、taro直接支持vue和react语法,配套的IDE工具链丰富,着色、校验、格式化完善; wepy比较弱小程序开发,有一些vscode由三方插件维护。
一个好的开发工具绝对可以大大提升开发体验。在这个维度中,显着更高的框架是uni-app,其生产公司也是HBuilder的生产公司DCloud.io。 HBuilder是四大主流前端开发工具之一(可比),对uni-app做了很多优化,所以uni-app的开发效率和易用性是其他框架无法企及的。
开发体验维度,对比结果:uni-app > taro, mpvue > wepy > 微信原生
这里可以得出一个结论:如果需要工程能力,就算了,还是用微信原生开发吧。
2.3 高效的社区支持
学习和发展难免会遇到问题。官方技术支持和社区活动非常重要。
在开发这个评测demo的过程中,我们的同学(同时掌握vue和react),在学习研究各种多终端框架的时候,真切的感受到由于语法、学习资料、学习门槛带来的社区的差异,吐槽很多。
综合评测,本评测结论:微信原生,uni-app > taro > mpvue > wepy
2.4 次活跃的开发迭代
开发者必须关心一个问题:项目是否长期维护?
这个问题可以通过github提交频率、产品变更日志(changelog)、百度搜索索引等指标来衡量和比较。
github 提交频率
我们收集了2019年4月(时间是4.1~4.30),每个项目在github上master分支上都有commit days-app在一个more主动更新状态,而 wepy 和 mpvue 相对较弱且无人维护。
产品更新日志
通过浏览产品更新日志,可以确认产品是否在积极迭代,添加新功能,修复用户Bug。
我们分别查看各个框架的官方链接的CHANGELOG,下面的链接就是链接地址:
通过产品更新日志对比,微信原生、taro、uni-app更新频繁,bug修复和新功能添加都处于比较紧凑的状态;而 mpvue 和 wepy 已经很久没有发布了,而 wepy 甚至已经将近一年没有正式发布了。版本,开发者需要谨慎选择。
2.5 多端复用
随着微信小程序的火爆,支付宝、百度、字节跳动等公司也纷纷进入小程序领域。这些公司中的每一个都拥有超过1亿的日常生活,并且拥有大量的用户。企业主希望通过他们的业务接触到每一位用户,无论用户在哪个小程序中。
需求转移 当我收到一个程序员时,程序员应该怎么做?是不是每个平台都在到处搬砖?这时,一套代码、多终端发布成为了很多程序员的梦想,小程序的跨终端框架应运而生。
现实真的可以这么理想吗?每个跨端框架真的能像官网宣传的那样开发一次,发布到所有小程序平台吗?甚至 H5 平台的代码重用?
我们用事实说话,我们还是用上面的仿微博App,依次发布到各个平台,在各个端验证各个框架的兼容性。结果如下:
测试结果说明:
通过这个简单的例子可以看出跨端支持评测结论:uni-app, taro > mpvue> 原生微信小程序, wepy
但是只有上面的测试并不全面,实际的业务比这个测试用例要复杂的多。但是我们不能开发很多复杂的业务来进行评估,所以我们需要根据各种文档添加一些信息。由于各个框架的文档对各种组件和API的跨端支持在上面已经介绍过了。我们浏览了几家公司的文档,发现他们基本上都是以微信小程序为基准,然后在另一端实现各种组件和API。再次:
跨端框架,一方面要考虑框架提供的通用API的跨端支持,同时考虑不同端的特性差异如何兼容。毕竟每一端都会有自己的特点,不可能完全一致。
跨端框架也涉及到一个ui框架的跨端问题。评估结果如下:
最后加上跨端案例:
基于以上信息,本文对该项目的最终评测结论:uni-app > taro > mpvue > 原生微信小程序,wepy
可以在这里输出结论。如果有多个发布需求,可以直接排除微信原生开发和wepy这两种方式。
结论
真实客观的永远是实验和数据,而不是结论。不同需求的开发者可以根据以上实验数据得出自己的结论。
但作为一个完整的评论,我们还必须提供一个总结 小程序开发系统 ,尽管它可能会增加我们的主观感受:
如果只开发微信小程序,不要多终端,那么使用uni-app和taro是更好的选择。它们相当于网络世界中的 vue 和 react。有了这些工具,就不再需要使用原生 wxml 开发了。
如果你开发多终端,uni-app和taro都可以使用。您可以根据自己熟悉的技术栈进行选择。相对来说,uni-app的多终端成熟度更高。
如果读者认为本文中的任何评论存在歪曲,请在此处报告问题。
发现、改变
探知、求新
共享,感恩一路相伴
昱远品牌形象已完成全面升级
点击访问新官网