2020版深度回顾小程序跨端开发框架

这一年，小程序在用户规模和商业化方面都取得了巨大成功。微信小程序日活跃用户超过3亿，支付宝、百度、字节跳动小程序月活跃用户也超过3亿。

从小程序开发领域来看，今年也发生了巨大的变化。开发框架已经从简单的微信小程序开发过渡到以多终端框架为标准，进一步提高开发效率成为开发者的强烈需求。

今年mpvue停止更新，Taro探索， uni-app产品和生态不断完善，微信重新上线了kbone框架，支持H5和微信小程序……所以是时候来一波新横评2020版来了。

评估目标筛选

跨端框架是一项投入较大的工作。在各框架长达一年多的竞争中，不少框架因投入不足而逐渐被开发者放弃。 uni-App和taro依靠进一步的重磅投入成为市场主流。

taro基于稳定版本，taro next于近期上线。这两个版本有很大不同，这次将分别进行审核。

kbone框架虽然发布时间不长，但终于由微信正式发布，也有很多人关注，所以这次kbone成为评测对象。

所以，本次评测对象（按发表时间排序）：

• 微信原生开发
• taro，京东实验室出品，官网地址：https://taro.jd.com/
• Uni-App，DCloud出品，官网地址：https://uniapp.dcloud.net.cn
• kbone，腾讯微信团队出品，官网地址：https://wechat-miniprogram.github .io/kbone/docs/

本次评测除了运行表现等实测数据外，还通过框架官网以及Github、掘金、腾讯课堂等三方社区公开收集数据：尽可能多。我们希望为大家提供一个全面的评价依据。

功能实现

taro和uni-App是比较典型的可发布的多端框架。而kbone仅支持H5微信小程序。

taro和uni-App都封装了通用接口和组件以及跨端API和跨端组件。组件规范遵循微信小程序的规范，以及一些平台特定的API。这两个框架也有解决方案：

• taro：支持与小程序代码混合编写，可以通过混合编写为框架未加密的小程序调用新的 API
• uni-app：支持条件编译，分别是在条件编译代码块中找到，您可以从任何平台自由调用新的API和组件。

taro和uni-app可以无限制调用任何小程序平台的所有API和组件。

kbone遵循web的开发习惯，配合

除了接口和组件之外，我们以微信小程序为例，找不同的典型能力来对比框架支持：

补充说明：如果Taro项目引用了小程序原生的第三方组件，则该项目不再具备多终端转换能力。例如，如果使用了微信小程序的第三方组件，那么该项目只能转换为微信小程序，转换到其他平台就会失效。详情请参阅taro官方网站

wxs是改善性能体验的重要工具。除了微信小程序的wxs，还有支付宝的SJS和百度erer，这些先进的技术uni -app 完全支持。参考：神秘的wxs，Uni-App如何利用它大幅提升性能测试模型，看看近一年来各种小程序开发框架的性能是否有所提升。详细内容如下：

• 开发内容：开发模仿微博小程序首页的复杂长列表，支持下拉刷新、上拉翻页、点赞等。
• 界面如下：

• 开发版本：共开发了5个版本，包括微信原生版、taro版、Uni-App版、kbone版。根据官网指南，默认使用 cli 方法安装它们。
• taro 目前的稳定版本是 2.0 版本，但最近正在推广跨框架 taro next，所以我们基于相同的反应代码测试了 taro 2.0 和 taro next 版本的数据。
• 测试代码开源（Github仓库地址：https://github.com/dcloudio/test-framework），

提示：如果同学认为测试代码写得不正确，请发送PR或Issus测试机型：Redmi 6 Pro、MIUI 11.0.5稳定版（最新版本）、微信版本7.0.12（最新版本）

我们以上面的仿微博小程序为例，测试一下容易出现性能问题的两个点：长列表加载和大量相似组件的响应。

加载长列表

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

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

• 时序开始时序：交互事件触发，在帧任务之前，如：上拉加载（onReachBottom）函数开始
• 计时结束时间：页面渲染完成（微信setData回调函数的开始）

提示：setData页面渲染完成时即可完成回调函数的开始。 ，因为微信setData定义如下（微信规范）：

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

测试结果如下：

说明：以400条微博列表为例，从页面空列表开始，每1秒触发一次上拉加载（新增20条微博） ），并记录单次耗时，触发20次后停止（页面达到400条微博），并计算这20次的平均耗时。结果微信原生这20次触发上拉->渲染完成平均耗时538毫秒，最快的❀秒，最慢的kbone是4057毫秒

当你第一次看到这个数据时，你可能会感到困惑。别担心，下面有详细介绍。注

注1：为什么taro Next/kbone测试数据不完整？

因为taro下一个和kbone使用动态数的解，如果解很多dom 节点将大幅增加，甚至超过微信的dom节点数量限制（警报信息如下）。我们在红米手机（红米6 Pro）上进行了测试。当页面组件数量超过600个时，taronext、kbone实现的仿微博应用报屏，因此白屏停止这两个测试框架中的组件，测试数据不完整。这意味着如果页面组件太多，这两个框架就无法使用。

超出 dom 限制，请参阅是否是你犯的错误

另外，kbone官网有如下介绍：

kbone用一定的表演功能损失来换取更多的网页支持。

taro接下来、kbone的测试数据明显和2一样。 、 不是来自同一应用程序尺寸。

如果你的申请是长名单场景，那么taro下一个、kbone显然不适合。

解释2：为什么测试数据显示Uni应用的性能比微信原生框架略好？

这个问题在去年的评测中已经得到了解释。为了避免新同学混淆，这里再解释一下。

微信原生框架耗时的部分主要在setData调用。如果开发者不单独优化的话，每次都会传输大量的数据；和 uni-App、taro 自动运行diff计算setData

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) //增量数据，发送数据到视图层
}