小程序开发：原生还是框架（wepy/mpvue/uni-app/taro）？

2017-1-9微信小程序诞生以来，经过2年多的反复升级，已推出数百万个小程序，已成为继Web、iOS和Android之后的第四大开发技术安卓。

此外，小程序的开发生态也在蓬勃发展，从最初的微信原生开发，到wepy​​、mpvue、taro、uni-app等框架相继出现，从刀耕火种的农业发展到现代发展，生态系统越来越丰富。

有这么多的可能性，一个问题就出现了。开发小程序应该使用原生还是选择第三方框架？

首先，微信原生开发的大部分缺点如下：

1. 原生开发对Node、预编译器和webpack没有很好的支持，影响了开发效率和工程构建流程
2. 微信是由非描述性语法定义。不如认真学习Vue和React，学会全部使用，而不是只学微信
3. 在vue/react生态中，有太多可以提高开发效率的外围工具，比如IDE、验证器、第三方库。 。 。
4. 微信IDE相比专业编辑器确实不太好用

同时，开发者对于第三方框架总是有不同的顾虑：

1. 他们担心性能不如原生
2. 一些功能框架恐怕可以实现。不行，只能用原生的
3. 你怕框架不稳定跳坑
4. 还有很多第三方框架应该用

面对如此复杂的场景，很多热心人开发者已经发表了评论文章，分享您的经验，但我认为有不同的意见和太多过时的信息。缺乏非常专业、深入或者用现在流行的说法“硬核”的评估报告。

评估报告的制作不同于一般的经验交流。实际上需要很多时间。要求：

• 必须成为每个框架的专业用户，而不是对这些框架有肤浅的了解
• 为多个平台编写真实的测试用例，比较并了解每个平台的特性和性能 社区状态和技术服务状态
• 你必须能够长期监控和更新报告，防止半年后变成过期信息

也就是说：想要认真评估，就得努力！

uni-app团队花了2周的时间完成了这份报告，并坚持每季度更新这份评估报告。目前更新时间为2019年5月。

本文从两个维度为用户和开发者重点介绍七个细节，分析微信原生和常规wepy​​、mpvue、。开发框架taro和uni-app进行横向对比，希望为开发者在选择小型框架时提供参考思路。本文基于各框架官网可以收集到的公开数据和真实测试数据，希望能够客观公正地评价各框架的现状和优缺点。但由于涉及利益，本文的观点很可能存在偏见。你可以用批判的眼光来看待它。如果您发现本文中存在任何估值扭曲，您可以在此处报告问题。

以用户为中心，以开发者为中心 维度，特别包括：

1. 用户：提供完整的业务实现，提供高性能体验
2. 开发者：平坦的学习曲线、现代化的开发体验（工程）、高效社区支持，积极开发迭代，多终端复用

1.用户

1.1 功能实现

软件开发的主要目标是为用户闭环提供完整的业务功能。

如果在Web开发中使用vue、react这样的框架让开发者无法管理浏览器提供的所有API，那么这样的框架肯定是不成熟的。小程序的开发也是如此。没有任何开发框架可以限制基本的API调用。

各种业务功能底层依赖于微信暴露的组件和接口（微信官网介绍的API组件和规范，也称为微信原生API）。三方框架是在原有微信的基础上进行二次封装。开发者经常会出现一个问题：小程序是不断迭代升级的。如果某个公司依赖了最新的小程序API，但第三方框架尚未封装怎么办？

其实就像web开发中的vue和react一样，浏览器有新的API，不包含vue和react升级。本次评测中并非所有框架都会限制开发者调用基本功能。这里详细解释一下原因：

• wepy：小程序API没有重新封装。该API仍然是微信原生的。框架与微信小部件是否有新的API无关。
• mpvue：支持所有微信原生组件和api，无限制。同时框架覆盖了自己的交叉API，使用方法类似于mpvue.request()
• taro：支持所有微信原生组件和API，无限制。同时，该框架包含自己的交叉API。使用方法与Taro.request()类似。支持Taro代码和小程序代码混合编写，可以通过混合编写调用框架未封装的新小程序。 API
• uni-app：无限制支持所有微信原生组件和API。在交叉使用方面，即使你仍然使用微信原生组件和API，也可以直接交叉翻译到app、H5、支付宝、百度头条等小程序中。但为了清晰管理，建议使用uni封装的API，如uni.request()。它还支持条件翻译。各平台新的API和组件可以在条件编译代码块中任意调用

注：以上顺序按各框架诞生的顺序，下同。

因此，所有第三方框架都可以调用所有小程序API来满足用户的业务需求。在这个维度上，框架之间没有区别。

然而，不同之处在于实施体验。

1.2 性能体验

大多数第三方框架都是内部封装的。这些封装会增加工作量并导致性能下降吗？首先，性能与微信小程序原生开发相比如何，是大家共同关心的问题。

为了客观对比，我们特地制作了一个测试模型，具体如下：

• 开发内容：开发一个模仿微博迷你主页的复杂长列表，支持下拉刷新、下拉翻页等功能。
• 界面如下：

• 开发版本：共开发了5个版本，包括微信原生版、wepy版、mpvue版、taro版、uni-app版，根据官网指引通过cli 默认安装。
• 测试代码开源（Github仓库地址：https://github.com/dcloudio/test-framework），提示：如果有同学觉得测试代码写得不对，请发PR或测试问题
• 型号：Redmi 6 Pro、MIUI 10.2.2.0稳定版（最新版本）、微信版本7.0.3（最新版本）
• 测试环境：开始测试每一帧之前，停止每个应用程序处理并清除内存，保证测试机环境基本一致；每次都在本地读取静态数据，以保护网络差异。

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

1.2.1 加载长列表

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

从触发拉取负载到数据更新、页面渲染完毕，需要一段准确的时间。人类视觉时间测量是绝对不可能的。我们使用程序埋点并创建以下时间表：

• Start Timing：在分配帧之前触发交互事件，例如：onReachBottom 函数的开始
• Time End Time：页面渲染完成（微信setData回调函数开始）

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

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

测试结果如下：

说明：以400条微博列表为例，从页面空列表开始，每1秒触发一次上传（新增20条微博），记录一次耗时，触发20次后停止（页面达到400条微博），并计算这20次的平均耗时。结果，微信原生在这20次触发引发->渲染完成平均耗时876毫秒，最快的uni-app为741毫秒。十亿秒，最慢的mpvue是4493毫秒

当你第一次看这个数据时，你可能会一头雾水，不用担心，详情如下。注

注1：为什么mpvue/wepy测试数据不完整？

mpvue、wepy​​微信小程序诞生之初，不支持自定义组件，无法进行组件化开发。 ; mpvue、wepy​​为了解决这个问题，用户编写的组件Vue被翻译成模板在WXML中，组件的开发实现了皮肤中的功能并提高了代码重用。这在当时的技术条件下是一个非常优秀的技术方案。

但是采用这种方案，当页面复杂、组件较多时，页面上的DOM节点数量会大幅增加，甚至超过微信对DOM节点数量的限制。我们在红米手机（红米6 Pro）上进行了测试。当页面组件数量超过500个时，mpvue和wepy​​运行的仿微博应用会报如下异常并停止。渲染，所以当这两个测试帧中有很多组件时，测试数据是不完整的。这意味着如果页面组件太多，这两个框架就无法使用。

超出首页限制，检查是否有误

Tips1：wepy​​官网的CHANGELOG提到试用版v1.7.2增加了对原生小程序组件的支持，实测有很多陷阱，由于是测试版本，官方在编号中表示不建议使用；根据官网文档，默认安装的正式版 v1.7.3 不支持原生组件

Tips2: wepy​​ 在 400 项列表里面，为什么性能比原来高微信框架？这与管理自定义组件和业务场景的成本有关（wepy​​编译成模板，不包含创建和管理组件的成本）。微博上继续。在传输组件数据时，微信原生框架的性能优势就显现出来了。详细请看下面的测试数据。

说明2：为什么测试数据显示uni-app的性能比微信原生框架略好？

事实上，当页面有200条记录（200个组件）时，taro比原生微信框架有更好的性能数据。

原来的微信框架需要花费很多时间，尤其是在调用setData。除非开发者专门优化，否则每次都会传输大量数据；和 uni-app、 taro 都会在调用 之前自动执行 diff 计算setData

每次只下载更改的数据。

当前页有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开发类似。 Web开发还包括原生js开发、vue、react框架等。如果不进行专门的优化，原生 JS 编写的网站性能往往不如 Vue 和 React 框架的性能。

正是因为Vue和react优秀、良好的性能和良好的开发体验，原生js开发逐渐被使用得越来越少。

复杂长列表加载下一页，回顾结论：微信原生开发手动优化,uni-app>微信原生开发未手动优化 ,taro>wepy​​>mpvue

提示：有些人认为uni-app和mpvue是一样的。早期的uni-app使用mpvue，后来为了性能和语法而使用vue。支持问题已重新开发。

1.2.2 Like组件的响应速度

长列表中的某个组件，比如Like组件，是否可以在点击“时及时改变Like和Like的状态？”这是本次测试的评估点。

测试方法：

• 选择微博，点击“点赞”按钮即可切换点赞状态（点赞高亮，不动灰色），
• 点赞按钮onclick时间从年初开始计算函数和计时在回调函数setData开始时结束；

我在红米手机（红米6 Pro）上做了几次测试，得出了平均值。结果如下：

描述：这意味着当列表数量为 400 时，对于最初在微信上开发的应用程序，“点赞”按钮从点击到改变状态需要 111 毫秒。

测试结果数据说明：

• wepy/mpvue 测试数据不完整原因同上。当组件较多时，页面不再渲染。
• 基于微信自定义组件的组件开发框架（uni-app /taro），组件的数据通信性能接近微信原生框架，远高于基于的框架（wepy/mpvue）性能组件开发模板

组件数据更新成功评估：微信原生开发者、uni-application ，taro

>

wepy > mpvue

综上，本次性能测试通过了2个测试。加载一长串并更新组件状态，广泛进行了两次实验，结论如下：

微信原生开发手动优化、Uni-APP>微信原生开发是不是手动优化。接下来我们讨论一下开发者的需求，首先从以下几个维度进行比较：

• 平坦的学习曲线：简单易学，最好复用现有的技术集，丰富的学习资料
• 高效的开发体验：现代前端开发流程，工程支持
• 有效的社区支持：遇到问题可以快速获得帮助
• 积极的开发迭代：框架主动更新升级，无需担心停止更新

2.1 平缓的学习曲线

2.1.1 DSL 语法支持

选择开发团队熟悉且能够快速使用的DSL，是选择团队框架的基本点。

首先，微信原生开发语法类似于React和Vue，有点难以形容。对于开发人员来说，这意味着他们必须学习新的语法，这是一件大事。大家都批评他增加了学习成本。

其他开发框架基本遵循React和Vue的语法（与Vue类似）。他们的主要目的是重用现有的工程师技术组并降低学习成本。目前，一个重要的标准是框架对原始框架（React/Vue）语法的支持。如果支持度低，并且语法与原来的框架有很大不同，那么开发人员就必须学习新的框架。 ，成本太高了。

实际开发中发现没有一个开发框架完全实现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的完整性：

• 微信出身：丰富的文档、详细的API搜索、官方示例demo、支持在官网运行微信开发者工具并预览执行效果详情参见
• wepy：文档只有2页，没有搜索，组件API等文档可以直接在微信文档中查看。没有示例演示，许多配置都需要猜测。详情参见
• mpvue：文档较少，但概念并不复杂。组件API等文档可以直接从微信文档查看，学习更轻松。发现问题的效果一般。没有提供示例演示。详情请参见
• taro：基础文档齐全，具体使用问题的资源很少，问题搜索性能一般。该demo仅包含基础功能，仅发布微信端。详情请参考
• uni-app：基础文档和各种使用主题内容丰富，问题查找效果良好，示例演示功能完成，面向7个终端发布。详情参见

教学课程：

教材完整性评价：微信原生>uni-app>mpvue，taro >

wepy​​2.2 现代前端开发经验

在开发经验方面，微信原生开发明显处于劣势。主要差距是：

• 框架开发提供了简化的代码组织（微信源码开发，页面由4个文件组成，写代码时打开的选项卡太多）
• 框架开发提供了更强的组件化能力
• 开发框架允许应用程序状态管理（如Vuex/Redux/Mobx等）
• 开发框架可以灵活支持各种Sass和其他预处理器
• 开发框架可以提供对ES Next语法的全面支持
• 让开发框架更容易自定义构建策略

支持其他小程序开发框架 cli模式可以在常见的前端工具中进行开发，基本自带d.ts语法提示库。

因为mpvue、uni-app、taro直接支持vue、响应语法、配套的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月各项目在github上master分支提交的天数（时间为4.1~4.30）。结果如下：

提示：

• 原微信是闭源的，看不到确认数量，但保持至少每月一次的更新节奏。详情请参阅
• wepy​​。 master 分支没有提交，最新的 2.0.x 分支只有四月份的一天。 commit 记录

从 commit 记录来看，taro 、uni-app 处于更新相对活跃的状态， wepy

、 mpvue

相对较弱且不可持续。

产品更新日志

通过浏览产品更新日志，您可以查看产品是否在积极迭代、添加新功能、修复用户Bug等。

我们来看看各个框架官方链接的更新日志（CHANGELOG）。下面是链接地址：

• 微信核心库更新日志
• wepy官网CHAGELOG
• mpvue官网Changelog
• taro github更新日志
• uni-app官网更新日志

B l 产品更新日志比较、微信原生、taro、uni-app 经常更新错误修复和新功能添加。处于比较紧凑的状态；而mpvue、wepy​​已经很久没有发布了，而wepy​​甚至几乎没有正式发布一年。版本、开发请谨慎选择。

2.5多终端复用

随着微信小程序的流行，支付宝、百度、字节跳动等公司也纷纷进入小程序领域。这些公司均拥有超过1亿的日活跃用户，拥有庞大的用户基础。企业主希望您的业务能够触及每一位用户，无论用户使用哪个小程序。

请求被传送给编程器。程序员要做什么？各个平台真的到处搬砖吗？这时，一套代码、多终端发布成为了很多程序员的梦想，终端间小程序的框架就这样诞生了。

现实真的可以这么理想吗？每个跨框架真的可以像官网宣传的那样，一次开发，面向所有小件平台发布吗？还可以在H5平台上复用代码吗？

我们用事实说话。我们仍然使用上面提到的微博模型，依次发布到各个平台，检查各端各个框架的兼容性。结果如下：

测试结果说明：

• ⭕表示支持且功能正常，❌表示不支持，其他表示支持，但有一些bug或兼容性问题

从这个简单的例子可以看出，结论交叉支持评价：uni-app, taro>mpvue> 微信原生小程序

、wepy​​​ ​ 但仅限于以上。测试尚未完成，实际操作比这个测试用例复杂得多。 。然而，我们无法开发很多复杂的公司来进行估值，因此我们需要通过与每个公司的文件进行比较来补充一些信息。因为每个框架的文档都描述了对不同组件和 API 的交叉支持级别。我们查阅了几家公司的文档，发现每个公司基本都是以微信小程序为基础，然后在其他终端上实现不同的组件和API：

• taro：H5终端实现了微信的大部分API
• uni-app：大多数组件、API 和配置都在所有终端上实现。某些 API 的指令在某些终端上不受支持。我们可以看到uni-app在H5页面上已经完全实现了微信模拟器在终端之间设置

框架。一方面需要考虑框架提供的终端间通用API支持，但同时也需要考虑不同终端特性的差异如何兼容。最终，每个结局都会有自己的特点，不可能完全一致。

• taro：提供判断js环境变量的多端文件和统一的接口。它可以在组件、js和文件方面扩展多终端。不支持其他链接的分平台处理。
• uni-app：提供条件编译模型。所有代码包括组件、js、css、json配置、文件和目录都支持条件编译，你可以无限制地为每一端编写差异化代码。

跨框架还包括UI框架的跨问题。评测结果如下：

• taro：官方提供taro ui，仅支持微信小程序和H5端。 ，不支持该app，详情请见
• uni-app：官方优惠uni ui，可在所有页面运行； uni-app 还有一个插件市场，其中包含许多第三方 UI 组件。详情见

最后添加了相互的例子：

• mpvue：微信上有很多例子，但没有其他例子
• taro：微信上有很多例子，但也有百度、支付宝和H5上的一些例子
• uni -app：多端案例较多，官方示例已发布在7个终端（含app端）

综合以上信息，本项最终评测结论为：uni- app > taro > mpvue > 原创应用微信

、wepy​​结论可以在这里找到。如果有多端发帖的需求，微信原生开发，wepy​​这两种方法可以直接淘汰。

结论

实验和数据永远是真实客观的，而不是结论。不同需求的开发者可以根据上面的实验数据做出自己的选择。

但作为一个完整的概述，我们也必须提供一个总结，尽管它可能会增加我们的主观感受：

如果你只开发微信应用，做的事情不多，那么使用uni -app、taro是更好的选择。它们相当于网络世界中的vue和react。无需使用这些工具进行本机 wxml 开发。

• 如果你坚持微信原生开发，要注意手动编写优化控制代码setdata并且注意它的工程能力很弱
• 如果你正在行动系统，则使用taro
• 如果vue，则使用uni-app， uni-app 在性能、环保方面生态和开发效率更有优势

如果开发更多终端，uni-app和taro都可以接受。您可以根据您所了解的技术组合进行选择。相对来说，uni-app更加成熟。

作者：CHB
链接：https://juejin.im/post/5cfdcf056fb9a07ecd3d5068
来源：掘金
版权归作者所有。商业转载请联系作者获得许可。非商业转载请注明来源。