这一年,小程序在用户规模及商业化方面都取得了极大的成功。微信小程序日活超过3亿,支付宝、百度、字节跳动小程序的月活也纷纷超过3亿。
对应小程序开发领域,这一年也发生了巨大变化。开发框架从单纯的微信小程序开发,过渡到多端框架成为标配,进一步提升开发效率成为开发者的强烈需求。
这一年 mpvue 停止更新,Taro开始探索 taro next,uni-app 产品和生态持续完善,微信新推出了支持H5和微信小程序的 kbone 框架…
去年的深度横评中很多老将已经退出江湖,一些新秀吸引眼球,因此,是时候来一波2020版的新横评了。
评测目标筛选
跨端框架是一个重投入工作,在各框架的1年多的比拼中,很多框架因为投入不足而逐渐被开发者放弃,uni-app和taro依靠持续的大力度投入,成为了市场主流。
taro 在稳定版的基础之上,最近也推出了 taro next,这2个版本差异较大,本次会分别评测。
kbone 框架虽面世不久,但毕竟是微信官方发布,关注的人不少,故本次将 kbone 加入评测目标。
所以,本次评测的对象(按发布时间排序):
- 微信原生开发
- taro
- uni-app
- kbone
本次评测除了运行性能等实测数据外,尽可能得通过框架官网及github、掘金、腾讯课堂等三方社区公开采集数据,希望给大家一个综合全面的评估依据。
功能实现
taro 和 uni-app 是比较典型的多端框架,发布到各个端均可。而 kbone 只支持微信小程序和H5。
taro 和 uni-app 均将常用接口及组件封装了成了跨端API和跨端组件,组件规范沿用微信小程序的规范,部分平台特有API,这两个框架亦有应对方案:
- taro:支持与小程序代码混写,可通过混写的方式调用框架尚未封装的小程序新增API
- uni-app:支持条件编译,可在条件编译代码块中,随意调用各个平台新增的API及组件
taro 和 uni-app 可以不受限的调用各家小程序平台所有的API及组件。
kbone 沿用web的开发习惯,使用html标签及js api;涉及微信特有api时,可通过
process.env.isMiniprogram判断环境,然后编写微信原生代码。对于html中没有标签可替代的微信内置组件(如swiper),需要使用 wx-component 标签或者使用 wx- 前缀,这样的内置组件会被包裹一层自定义组件,带来相应的性能开销。
除了接口、组件之外,我们以微信小程序为例,找几个典型能力对比框架支持度:
补充说明:
- 如果在 Taro 项目引用了小程序原生的第三方组件,那么该项目将不再具备多端转换的能力,例如,如果使用了微信小程序的第三方组件,那么项目只能转换成微信小程序,转义成其他平台会失效。
- uni-app 中使用微信自定义组件的话,支持编译发行到App/H5/微信小程序/QQ小程序4个平台。
- taro 不支持 wxs的依据:#2959
- kbone 不支持微信三方插件的依据:#58;不支持wxs的依据:#129
- 云开发在微信平台,三个框架都支持,但taro/kbone仅支持微信小程序平台,uni-app支持App/H5/小程序所有平台使用云开发。
wxs是提升性能体验的重要利器,除了微信小程序的wxs外,还有支付宝的SJS、百度的Filter,这些高级技术 uni-app 均完善支持。
从如上功能对比来看:微信原生 ~ uni-app > taro > kbone
运行性能(微信小程序)
我们继续沿用去年的测试模型,看看一年来,各家开发框架的性能是否有提升。详细如下:
-
开发内容:开发一个仿微博小程序首页的复杂长列表,支持下拉刷新、上拉翻页、点赞。
-
界面如下:
-
开发版本:一共开发了5个版本,包括微信原生版、taro版、uni-app版、kbone版,按照官网指引通过cli方式默认安装。
-
taro 目前稳定版本是2.0版,但近期在宣传跨框架的taro next,故我们基于同样的 react代码,同时测试了taro 2.0 和taro next 两个版本的数据。
-
测试代码开源(Github仓库地址:https://github.com/dcloudio/test-framework),
-
Tips:若有同学觉得测试代码写法欠妥,欢迎提交 PR 或 Issus
-
测试机型:红米 Redmi 6 Pro、MIUI 11.0.5 稳定版(最新版)、微信版本 7.0.12(最新版)
-
测试环境:每个框架开始测试前,杀掉各App进程、清空内存,保证测试机环境基本一致;每次从本地读取静态数据,屏蔽网络差异。
我们以上述仿微博小程序为例,测试2个容易出性能问题的点:长列表加载、大量点赞组件的响应。
长列表加载
仿微博的列表是一个包含很多组件的列表,这种复杂列表对性能的压力更大,很