小程序开发：使用本机还是选择框架（wepy / mpvue / uni-app / taro）？

自2017年1月9日微信小程序诞生以来，经过2年多的迭代升级，数百万小程序上线，成为继Web，iOS和Android之后的第四种主流开发技术。

随之，从最初的微信本地开发到wepy，mpvue，芋头和uni-app等框架的出现，小程序的开发生态也蓬勃发展，从砍杀，烧毁到现代发展。生态越来越丰富。

还有更多选择，问题就来了。开发小程序时，应该使用本机框架还是三方框架？

首先，微信的本机开发位置主要集中在以下位置：

本机开发不支持Node，预编译器和webpack，这会影响开发效率和工程构建过程。 微信定义了一个非描述性语法。最好学习vue并认真反应并学习所有目的的通用目标，而不只是学习微信小程序 vue / react生态系统中的外围工具太多，这些工具可以提高开发效率，例如ide，verifier和Third-政党图书馆。 。 。 微信与专业编辑人员相比，该ide确实不容易使用

同时，开发人员始终对三方框架有各种担忧：

恐怕表现不如原始表现。恐怕某些功能框架无法实现。我只能使用原始的。恐怕该框架是不稳定的。我跳入深渊和许多三方框架。

面对这样一个纠结的场景，许多热心的开发人员发表了评估文章来分享他们的经验，但是他们感到意见分歧并且信息太多了。它缺乏流行的非常专业，深入或“硬核”的评估报告。

制作评估报告与一般经验分享不同。实际上需要很多时间。它需要：

换句话说：如果您想考虑评估，就必须做得深入！

Uni-app团队花了2周的时间来完成此报告，并坚持每个季度更新此评估报告。当前更新时间为2019年5月。

本文从面向用户和面向开发人员这两个维度的七个细节中水平比较了微信本机和主流的wepy，mpvue，芋头和uni-app开发框架，并希望向小程序中的开发人员展示选择框架时提供参考参考。本文基于可在每个框架的官方网站上收集的公共数据和真实测试数据，并希望客观公正地评估每个框架的现状和优缺点。但是，由于与利益相关的问题，本文中的观点可能会带有偏见。您可以用挑剔的眼光看它。如果您在本文中发现任何评估失真，请在此处向issuse报告。

面向用户和面向开发人员的维度，包括：

用户：提供完整的业务实施并确保获得高性能体验。开发人员：平滑的学习曲线，现代的开发经验（工程），高效的社区支持，积极的开发迭代，多终端重用

2.用户

1.1函数实现

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

在Web开发中，如果使用诸如vue和react之类的框架导致开发人员无法操作浏览器提供的所有API，那么这种框架肯定是不成熟的。 小程序开发也是如此。没有任何开发框架可以限制底层的api调用。

各种业务功能的底层依赖于微信公开的组件和接口（在微信官方网站上介绍的组件和API规范，即微信原生API），并且三方框架基于在微信上本地开发对于二级打包，开发人员此时经常会提出一个问题：小程序正在不断迭代升级，如果某项业务依赖于最新的小程序 API，但尚未打包第三方框架，该如何处理？我该怎么办？

实际上，就像Web开发的vue和react一样，浏览器具有一个新的API，该API不会涉及vue and react的升级。此评估中的所有框架都不会限制开发人员调用基础功能。这是原因的详细说明：

注意：上面的顺序基于每个帧的出生顺序，如下所示。

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

但是，区别在于性能体验。

1.2表演经验

三方框架大部分具有内置的封装层。这些封装会增加工作负荷并导致性能下降吗？尤其是如何将性能与本地微信小程序开发进行比较，这是一个普遍关注的问题。

为了客观地进行比较，我们特意建立了一个测试模型，具体如下：

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

1.2. 1载入很长的名单

仿制微博客列表是包含许多组件的列表。这种复杂的列表给性能带来了更大的压力，非常适合于性能测试。

从触发上拉负载到数据更新和页面渲染完成，需要准确的时间。人眼的视觉定时肯定不好，我们在程序中采用埋点的方法，并设置定时时间如下：

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

测试方法：从页面的空白列表开始，程序自动触发上拉和加载，每添加20个新列表，一次记录就需要时间；定期连续触发N个上拉和加载，使页面达到20 * N个项目列表，并计算从N个触发到渲染完成的平均时间。

测试结果如下：

描述：以400个微博客的列表为例。从页面上的空白列表开始，每1秒钟触发一次上载加载（添加20个微博客），并记录一次，然后触发20次Stop（此后达到400个微博客），计算这20次的平均时间，结果微信会自然触发这20次的上拉->渲染的平均时间为876毫秒，最快的uni-app为741毫秒，最慢的mpvue为4493毫秒

乍一看这些数据，您可能会更加困惑，不用担心，下面有详细的说明

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

在mpvue和wepy诞生之初，微信小程序还不支持自定义组件，因此无法开发为组件。 mpvue和wepy将用户编写的Vue组件编译到WXML中的模板中，以解决此问题。 ，它以变相的形式实现了组件开发功能并提高了代码重用性，这是在当前技术条件下的绝佳技术解决方案。

但是这样一种解决方案，当页面复杂且组件很多时，它将大大增加页面上dom节点的数量，甚至超过微信中dom节点数量的限制。我们在Redmi 6 Pro上进行了测试。当页面组件超过500个时，由mpvue和wepy实现的仿制微 Bo App将报告以下异常并停止呈现，因此这两个测试框架都在组件中。如果更多，则测试数据不完整。这也意味着，当页面组件过多时，将无法使用这两个框架。

超出了区域限制，请检查您是否犯了任何错误

提示1：wepy官方网站上的CHANGELOG，提到v 1.7.2测试版本增加了对小程序本机组件的支持。有许多实际的测试坑。由于是测试版本，官方在问题中表示不建议使用；根据官方网站文档，默认安装的v 1.7.3官方版本不支持本机组件

提示2：为什么在400个列表内wepy的性能要比微信本机框架的性能高？这与自定义组件管理开销和业务场景有关（wepy被编译为模板，并且不涉及组件创建和管理开销）。 微博喜欢它。当涉及到组件数据传输时，微信就会显示出本机框架的性能优势。有关详细信息，请参见下面的测试数据。

注2：为什么测试数据显示uni-app比微信本机框架稍好？

实际上，当页面上有200条记录（200个组件）时，芋头性能数据要优于微信本机框架。

微信本机框架的耗时主要是在setData的调用中。如果开发人员没有单独进行优化，则每次都会传输大量数据；而uni-app和taro会在调用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和芋头的性能差距并不大

此结果类似于Web开发。 Web开发中也有本机js开发，vue和react框架。如果不进行特殊优化，以本机js编写的网页的性能通常不如vue和react框架的性能。

正是由于出色的Vue和react框架，良好的性能和良好的开发经验，才逐渐减少了对本机js开发的使用。

复杂的长列表加载下一页评估结论：微信本机开发手动优化，uni-app> 微信本机开发非手动优化，芋头> wepy> mpvue

提示：有些人认为uni-app和mpvue是相同的。早期的uni-app确实使用mpvue，但后来由于性能和vue语法支持问题而被重新开发。

1.2. 2类似组件的响应速度

长列表中的某个组件（例如，喜欢的组件）是否可以在单击时及时修改不喜欢和喜欢的状态？这是该测试的评估点。

测试方法：

在Redmi 6 Pro上进行了多次测试，得出平均值，结果如下：

注意：也就是说，当列表数为400时，微信个本机开发的应用程序从单击like按钮到状态更改需要111毫秒。

测试结果数据的说明：

组件数据更新性能评估：微信本机开发，uni-app，芋头> wepy> mpvue

总而言之，该性能测试已经完成了两项测试，即长列表加载和组件状态更新，并结合了两项实验，结论如下：

微信本机开发手动优化，uni-app> 微信本机开发无需手动优化，taro> wepy> mpvue

2.开发人员

在满足用户业务需求的前提下，让我们讨论一下开发人员的需求，并从以下几个方面进行比较：

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语法，例如过滤器，复杂的JavaScript表达式等；

Taro对JSX的语法支持也达到了大多数人所支持的完善水平。

DSL语法支持评估：taro，uni-app> mpvue> wepy> 微信本地

2. 1.2学习材料的完整性

官方文档，问题搜索和示例演示的完整性：

关于教学课程：

学习材料完整性的评估：微信母语> uni-app> mpvue，芋头> wepy

2. 2现代前端开发经验

在开发经验级别，微信本地开发处于显着劣势，主要差距在于：

其他小程序开发框架均支持cli模式，该模式可以在主流前端工具中开发，并且基本上具有d.ts语法提示库。

由于mpvue，uni-app和taro直接支持vue和react语法，因此支持的ide工具链更加丰富，具有完整的着色，验证和格式设置； wepy较弱，并且有一些第三方vscode插件。

好的开发工具肯定可以极大地改善开发经验。在这个维度上，更高的框架是uni-app。其产品公司也是HBuilder 公司 DCloud.io的产品。 HBuilder是四种主要的前端开发工具（与百度索引相比）。它对uni-app进行了许多优化，因此uni-app的开发效率和易用性无法与其他框架媲美。

发展经验维度，比较结果：uni-app> taro，mpvue> wepy> 微信母语

在这里可以得出一个结论：如果您需要工程能力，那就忘了微信本机开发。

2. 3高效的社区支持

学习和发展将不可避免地遇到问题。官方技术支持和社区活动非常重要。

在本评估演示的开发过程中，我们的同学（既掌握观点又做出反应）在学习和研究各种多端框架时，由于语法，学习材料和社区的差异，确实感受到了学习的门槛。呕吐了很多。

综合评估，该评估的结论：微信原生，uni-app> taro> mpvue> wepy

2. 4主动开发迭代

开发人员必须关注一个问题：项目是否可以长期维护？

可以通过github提交的频率，产品更改日志（changelog）和百度搜索索引等指标来衡量和比较此问题。

github提交的频率

我们收集了2019年4月（时间为4.1〜4.30），每个项目在github的master分支上提交的天数，结果如下：

提示：

从提交记录来看，芋头和uni-app处于相对活跃的更新状态，而wepy和mpvue则相对较弱且无法维护。

产品更新日志

通过浏览产品更新日志，可以确认产品是否正在积极迭代，添加新功能以及修复用户错误。

我们分别检查每个框架的官方链接的更改日志（CHANGELOG），链接地址如下：

通过比较产品更新日志，微信本机，芋头和uni-app会经常更新，并且错误修复和新功能添加处于相对紧凑的状态；而mpvue和wepy很久没有发布了。 Wepy甚至还没有发布正式版本将近一年，因此开发人员在选择模型时需要谨慎。

2. 5多终端多路复用

随着微信小程序的流行，支付宝，百度，ByteDance等。公司也进入了小程序领域。这些公司每天生活超过1亿，并且拥有大量用户。企业主希望能够挽救自己，无论用户身在哪个小程序，企业都可以触及到每个用户。

需求转移到程序员，程序员应该怎么做？每个平台都真的到处移动砖块吗？这时，一套代码，多终端发布已成为许多程序员的梦想，小程序跨终端框架应运而生。

现实可以这么理想吗？每个跨端框架都可以开发一次并按照官方网站上的广告发布到所有小程序平台上吗？甚至在H5平台上重复使用代码？

我们用事实说话，仍然使用上述的微模仿博客应用程序，依次发布到每个平台，验证每个框架在两端的兼容性，结果如下：

测试结果说明：

通过这个简单的示例，我们可以看到跨端支持评估结论：uni-app，taro> mpvue>本机微信小程序，wepy

但是，仅上述测试并不全面，实际业务要比该测试用例复杂得多。但是我们无法开发许多复杂的评估服务，因此我们需要针对每个文档添加一些信息。因为每个框架的文档都描述了各种组件和API的跨端支持程度。我们浏览了几份文档，发现每个公司基本上都以微信小程序为基准，然后在另一端实现了各种组件和API：

跨端框架，一方面，我们需要考虑框架提供的通用api跨端支持，同时，我们还必须考虑不同端的特征如何兼容。毕竟，每个端都有自己的特征，不可能做到完全一致。

跨端框架，也涉及UI框架的跨端问题，评估结果如下：

最后补充交叉终端的情况：

基于以上信息，该产品的最终评估结论：uni-app> taro> mpvue> native 微信小程序，wepy

可以在此处输出结论。如果存在多个发行要求，则可以直接排除微信本机开发和wepy。

结论

实验和数据始终是真实客观的，而不是结论。根据上述实验数据，有不同需求的开发人员可以得出自己的选择结论。

但是，作为完整的评论，我们还必须提供摘要，尽管它可能会增加我们的主观感受：

如果您仅开发微信小程序而没有做多端，那么使用uni-app和芋头是一个更好的选择。它们等效于vue，并在网络世界中做出反应。使用这些工具，您不再需要使用本机wxml开发。

如果您开发多端，则可以使用uni-app和芋头。您可以根据自己熟悉的技术堆栈进行选择。相对而言，uni-app的多端成熟度更高。

喜欢这篇文章吗？欢迎奖励~~