深度评测:小程序多端框架全面对比与实际开发问题解析

2024-12-18
来源:网络整理

上周,Taro团队发布了《小程序多端框架综合评测》,让开发者对业界主流跨端框架有了初步的了解。感谢太郎团队的辛勤付出。

不过,想要完善横评,其实还需要花费很多时间。它不仅仅需要查看文档,还需要:

我们的 uni-app 团队花费了一周的时间来完成这项深入的评估。下面我们将分享实际开发不同框架的测试用例时遇到的问题以及最终的测试结果。

评估实验简介

Tips:如果有同学觉得测试代码写得不好,请提交PR或者

1. 跨终端支持如何?

一次开发,随处运行是每个程序员的梦想。但现实往往是一次开发,到处调整。

待评估的各种框架是否真的像宣传的那样一次开发并在多个设备上发布?

我们将上述仿微博App依次发布到各平台,以验证各端各框架的兼容性。结果如下:

平台微信原生-

微信小程序

⭕️

⭕️

⭕️

⭕️

⭕️

⭕️

支付宝小程序

⭕️

⭕️

⭕️

百度小程序

⭕️

⭕️

⭕️

今日头条小程序

⭕️

⭕️

⭕️

H5结束

上拉加载/下拉刷新失败

⭕️

上拉加载/下拉刷新失败

应用端

上拉加载失败

⭕️

列表无法滚动,无法测试上拉加载/下拉刷新。

测试结果说明:

从这个简单的例子可以看出,跨端支持评测结论:uni-app > taro >> wepy,原生微信小程序

但仅靠上面的测试是不全面的,实际业务比这个测试用例复杂得多。但我们无法开发很多复杂的业务进行评估,所以我们需要通过与每个公司的文件进行比较来补充一些信息。

由于每个框架的文档都描述了对各种组件和API的跨端支持程度。我们查阅了几家公司的文档,发现各家公司基本都是以微信小程序为基准,然后在其他终端上实现各种组件和API:

对于跨终端框架,一方面要考虑框架提供的通用API跨终端支持,同时还要考虑不同终端的特性差异如何兼容。毕竟每个端都会有自己的特点,不可能完全一致。

跨端框架也涉及到UI框架的跨端问题。评价结果如下:

最后添加跨终端的情况:

综合以上信息,本项目最终评价结论为:uni-app > taro > > > wepy,原生微信小程序

此前有朋友发起了真跨端和假跨端的争论。通过这个demo测试,这场争论就可以结束了。

2、跨端框架的性能如何?

跨端框架基本上都是+模式。引入它会降低运行性能吗?

尤其是与原生微信小程序开发相比性能如何,是大家共同关心的问题。

我们还是以上面提到的仿微博小程序为例,测试两个容易出现性能问题的点:长列表加载和大量同类组件的响应。

2.1 长列表加载

模仿微博的列表是一个包含很多组件的列表。这个复杂的列表对性能带来了较大的压力,非常适合性能测试。

从触发上拉加载到数据更新、页面渲染完成,都需要准确的时序。人类视觉计时肯定是不可能的。我们利用程序埋点,制定了如下的计时时序:

Tips:回调函数的开始可以认为是页面渲染完成的时间,因为微信定义如下(微信规范):

字段类型 必填描述

数据

是的

本次要更改的数据

渲染完成后界面更新引起的回调函数

测试方法:从页面空列表开始,程序自动触发上拉加载,每次添加20个列表,记录单次耗时;固定间隔连续触发上拉加载N次,使页面达到20*N个列表。计算这N次触发上拉的平均时间->渲染完成。

测试结果如下:

微信原生列表项数量-

200

第770章

625

969

第752章

第641章

1261

400

第876章

第781章

4493

第974章

第741章

1970年

600

1111

1250

910

2917

800

1406

第1547章

1113

4040

1000

1690

1878年

1321

5196

注:以400条微博列表为例,从页面空列表开始,每1秒触发一次上拉加载(新增20条微博),记录单次耗时,触发20次后停止(页面达到400条微博),计算这20次的平均耗时。结果,微信原生触发这20次上拉->完成渲染的平均时间是876毫秒。 uni-app最快741毫秒,最慢4493毫秒

当你第一次看到这些数据时,你可能会感到困惑。别担心,下面有详细的解释。

注1:为什么/wepy测试数据不完整?

,wepy诞生时,微信小程序还不支持自定义组件,无法开发为组件; ,wepy为了解决这个问题,将用户编写的Vue组件编译成WXML中的(),变相实现组件化开发能力和提高代码复用性,在当时的技术条件下是很好的技术方案。

但这种方案,在组件较多、复杂的页面上,会增加大量的DOM节点,甚至超过微信对DOM节点数量的限制。我们实际在红米手机(6 Pro)上进行了测试。当页面组件数量超过500个时,wepy和wepy实现的仿微博App会报如下异常并停止渲染。因此,这两个测试框架会在组件较多的情况下进行测试。数据不完整。这意味着当页面组件过多时,这两个框架都无法使用。

dom 如果你做了什么

Tips:Wepy的列表不到400条,为什么它的性能比微信原生框架高?这与自定义组件管理开销和业务场景有关(wepy编译成模板,不涉及组件创建和管理开销)。微博跟进,说到组件数据传输,微信原生框架的性能优势就暴露出来了。详细请看下面的测试数据。

注2:uni-app 的性能比微信原生框架好吗?难以置信?

事实上,当页面有200条记录(200个组件)时,taro性能数据也优于微信原生框架。

微信原生框架主要消耗时间在调用上。如果开发者不单独优化,每次都会传输大量数据;而uni-app和taro在调用前会自动进行diff计算,并且每次只传输变化的数据。

例如当前页面有20条数据。当触发上拉加载时,会加载20条数据。此时,当原生框架通过下面的代码测试时,将会传输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-

200

第770章

第572章

第641章

第752章

400

第876章

第688章

第741章

第974章

600

1111

第855章

910

1250

800

1406

1055

1113

第1547章

1000

1690

1260

1321

1878年

从测试结果可以看出,经过开发者手动优化后,微信原生框架能够取得较好的性能,但相比微信原生,uni-app和taro的性能差距并不大。

这个结果与Web开发类似,Web开发也包括原生js开发、vue、框架等。如果不进行专门的优化,原生JS编写的网页性能往往不如Vue和框架。

正是因为Vue和框架的优秀,其良好的性能和良好的开发体验,使得原生js开发的使用逐渐减少。

复杂长列表加载下一页评测结论:微信原生开发手动优化,uni-app>微信原生开发未手动优化,taro>>wepy>

2.2同类元件响应速度

长列表中的某个组件,例如点赞组件,是否能够在点击时及时修改不喜欢和喜欢的状态?这是本次测试的评价点。

测试方法:

在红米手机(6 Pro)上进行多次测试,求平均值。结果如下:

微信原生列表数量-

200

91

第279章

第666章

92

93

101

400

111

501

1507

125

107

145

600

144

152

148

178

800

176

214

181

236

1000

220

229

234

第272章

注意:当列表数量为 400 时,对于微信原生开发的应用,点赞按钮从被点击到改变状态需要 111 毫秒。

测试结果数据说明:

组件数据更新性能评估:微信原生开发、uni-app、taro>>wepy>

总结一下,本次性能测试做了两个测试,长列表加载和组件状态更新。根据两次实验,得出以下结论:

微信原生开发手动优化,uni-app>微信原生开发未手动优化,taro>>>wepy>

3.学习阈值DSL语法支持

主流跨端框架基本遵循Vue(类Vue)语法。其主要目的是复用工程师现有的技术栈,降低学习成本。这时,跨端框架对原有框架(/Vue)语法的支持就是一个重要标准。如果支持度低且语法与原始框架有很大不同,开发人员将不得不学习新的语言。框架的话,成本太高了。

在实际开发过程中,发现各种多端框架并没有完全实现Vue以及web上的所有语法:

taro 对 JSX 的语法支持比较完善,其文档描述了未来的版本计划。

更多 JSX 语法支持。 1.3 之后限制生产力的唯一语法是只能使用 map 来创建循环组件。

,uni-app框架基于Vue.js核心。通过修改Vue.js之和,可以运行在小程序端,支持大部分Vue语法; uni-app之前是编译到微信端使用的,后来重写了。框架支持更多Vue语法如复杂表达式等;

Wepy 和 Vue 都是类似 Vue 的实现,仅支持 Vue 的部分语法。开发时需要单独学习它们的规则;

DSL语法支持评估:taro,uni-app >> wepy,

学习材料的完整性

学习材料完整性评价:uni-app > 、taro > > wepy

技术支持和社区活动

开发难免会遇到问题,官方的技术支持和社区活动非常重要。

目前uni-app和taro都有专职技术支持人员。由于通讯群过多,Uni-app还推出了单独的智能客服机器人。

活跃的社区意味着当你遇到问题时,有人可以请教,或者说以前的人会将他们的经验存入文章中供你搜索。 uni-app官方拥有30多个交流群(其中很多群有上千人),自建论坛里有大量的交流帖子;芋头,拥有9个微信群,500人; wepy官网微信无法添加,发布较晚。用户基数仍然很小。除uni-app外,其他框架都没有自建论坛社区。

在本次评测demo的开发过程中,我们的同学(同时掌握了Vue和Vue)在学习各种多端框架时,真实感受到了语法、学习资料、社区差异带来的学习门槛,并吐槽了不少。

综合评价,本次评价的结论:uni-app > taro > > wepy >

Tips:本次评测忽略了Vue以及两个框架本身的学习门槛。

4.工具及周边生态工具

所有多端框架均支持cli模式,可以在主流前端工具中进行开发。

每个框架基本上都带有一个 d.ts 语法提示库。

由于uni-app和taro直接支持Vue和语法,所以支持的IDE工具链比较丰富,着色、验证、格式化都齐全。建议某些编辑器使用插件。 Wepy 有一些由第三方维护的插件。

从工具属性来看,明显较高的框架是uni-app,其制作公司也是.io的制作公司。

/系列是一款拥有300万开发者用户的国产开发工具。

对uni-app做了很多优化,因此uni-app的开发效率和易用性是其他框架无法比拟的。

当然,对于不习惯的开发者来说,uni-app的这个优势就无法体现出来。

周边生态

一个底层框架,其周边的配套设施非常重要,比如UI库、js库、项目模板等。

值得注意的是,uni-app和uni-app的插件生态是可以互通的,而且都是vue插件。因此,双方还联合举办了一场外挂大赛。这个联合生态的周边丰富度是目前所有框架中最丰富的。

顺便宣传一下,欢迎有能力的同学参加uni-app/插件开发大赛,获得Xs Max等丰厚奖品。

综上所述,工具及周边生态评价结论:uni-app,>wepy>taro>

其他常见评价指标

星星:

-

4728

4287

星数对比: wepy > taro > > uni-app >

尖端:

百度指数

分享