这是为《小程序跨端框架全面测评》准备的仓库。

本项目分别使用微信原生版、wepy版、mpvue版、taro版、uni-app版、chalemeon版，各自开发一个仿微博小程序首页的复杂长列表，支持下拉刷新、上拉翻页、点赞功能。

该项目主要用于两项测试：

• 跨端支持度如何：是否真能实现各框架宣传的那样，一次开发、多端发布？真的不需要二次开发？
• 跨端框架性能如何：跨端框架基本都是compiler + runtime模式，引入的runtime是否会降低运行性能？尤其是与原生微信小程序开发相比性能怎么样？

大家可自助测试，启动测试请修改 utils --> config.js 下各项配置：

• PERF_MAX 总翻页次数
• PERF_LIKE_MAX 总点赞次数
• PERF_AUTO 是否开启自动测试
• PERF_USING_COMPONENTS 是否为原生组件，mpvue、wepy 为 false, 其他均为 true，请勿手动修改

是否真能实现各框架宣传的那样，一次开发、多端发布？真的不需要二次开发？

我们将上述仿微博App依次发布到各平台，验证每个框架在各端的兼容性，结果如下：

测试结果说明：

• ⭕ 表示支持且功能正常，❌ 表示不支持，其它则表示支持但存在部分bug或兼容问题
• 测试框架版本为按照官网指引通过cli方式安装的默认版；
• wepy 2.0 宣称版已支持其他家小程序，本次测试基于wepy官网指引安装的wepy-cli版本为1.7.3，尚不支持多端
• chameleon尝鲜版宣称支付宝、百度小程序，本次测试基于chameleon官网指引安装的chameleon-tool版本为0.1.1，尚不支持其它小程序

通过这个简单的例子可以看出，跨端支持度测评结论：uni-app > taro > chameleon > mpvue >wepy、原生微信小程序

跨端框架基本都是compiler + runtime模式，引入的runtime是否会降低运行性能？

尤其是与原生微信小程序开发相比性能怎么样，这是大家普遍关心的问题。

我们依然以上述仿微博小程序为例，测试2个容易出性能问题的点：长列表加载、点赞交互。

测试方式： 仿微博的列表是一个包含很多组件的列表，这种复杂列表对性能的压力更大，很适合做性能测试。 加载下一页速度的快慢，如果人手拖、视觉计时是无法准确的。我们采取程序化的加载和打点计时方式。 程序自动触发上拉加载，每次新增20条记录，直到1000条记录结束，记录每次从开始触发下拉即onReachBottom，到列表数据项设置完毕即setData回调完成，计算它们之间的耗时，并多次试验计算平均值。

计时时机：

• 计时开始时机：交互事件触发，框架赋值之前，如：上拉加载（onReachBottom）函数开头
• 计时结束时机：页面渲染完毕(微信setData回调函数开头)

测试结果如下：

数据说明：以页面有400条微博列表数据为例，加载完成下一页的时间，微信原生开发是876毫秒，最快的uni-app是741毫秒，最慢的mpvue是4493毫秒

大家初看这个数据，可能比较疑惑，别急，下方有详细说明

说明1：为何 mpvue/wepy 测试数据不完整?

mpvue、wepy 诞生之初，微信小程序尚不支持自定义组件，无法进行组件化开发；mpvue、wepy 为解决这个问题，将用户编写的Vue组件，编译为WXML中的模板（template)，变相实现了组件化开发能力，提高代码复用性，这在当时的技术条件下是很棒的技术方案。

但如此方案，在页面复杂、组件较多的时，会大量增加页面 dom 节点数量，甚至超出微信的 dom 节点数限制。我们在 红米手机（Redmi 6 Pro）上实测，页面组件超过500个时，mpvue、wepy 实现的仿微博App就会报出如下异常，并停止渲染，故这两个测试框架在组件较多时，测试数据不完整。这也就意味着，当页面组件太多时，无法使用这2个框架。

dom limit exceeded please check if there's any mistake you've made

说明2：uni-app 比微信原生框架性能更好？逆天了？

其实，在页面上有200条记录（200个组件）时，Taro 性能数据也比微信原生框架更好。

微信原生框架耗时主要在setData调用上，开发者若不单独优化，则每次都会传递大量数据；而 uni-app、Taro 都在调用setData之前自动做diff计算，每次仅传递变动的数据，只不过uni-app的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 | |:- |:- |:- |:- | |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、react框架等情况。如果不做特殊优化，原生js写的网页，性能经常还不如vue、react框架的性能。

也恰恰是因为vue、react框架的优秀，性能好，开发体验好，所以原生js开发已经逐渐减少使用了。

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

长列表中的某个组件，比如点赞组件，在列表较长时，点击点赞图标，是否能及时的修改未赞和已赞状态？是这项测试的评测点。

测试方式：

• 选中某微博，点击“点赞”按钮，实现点赞状态状态切换（已赞高亮、未赞灰色），
• 点赞按钮 onclick函数开头开始计时，setData回调函数开头结束计时；

在红米手机（Redmi 6 Pro）上进行多次测试，求其平均值，结果如下：

也就是在列表数量为400时，微信原生开发的应用，点赞组件从点击开始到状态变化需要111毫秒。

测试结果数据说明：

• wepy/mpvue 测试数据不完整的原因同上，在组件较多时，页面已经不再渲染了
• 基于微信自定义组件实现组件开发的框架（uni-app/Taro/chameleon），组件数据通讯性能接近于微信原生框架，远高于基于template实现组件开发的框架（wepy/mpvue）性能

组件数据更新性能测评：微信原生开发,uni-app,taro > chameleon > wepy > mpvue

综上，本性能测试做了2个测试，长列表加载和组件状态更新，综合2个实验，结论如下：

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