自微信小程序于2017年1月9日诞生以来，经过数年的迭代升级，数百万个小程序已启动，成为继Web，iOS等之后的第四种主流开发技术。

在此之后，小型程序的开发生态也在蓬勃发展。从最初的微信本机开发到wepy，芋头，uni-app等框架的出现，从刀耕火种到现代发展，生态学正变得越来越多。富有。

还有更多选择，并且出现了问题。在开发小型程序时，我应该使用本机框架还是三方框架？

首先，微信原生开发的插槽主要集中在以下方面：

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

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

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

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

换句话说：如果您想忠于评估，则必须付出很多努力！

本文从面向用户和面向开发人员这两个维度的七个细节中水平比较了微信的本机和主流的wepy，芋头和uni-app开发框架。希望开发人员能够选择小型程序框架。提供参考提示。

本文基于可在每个框架的官方网站上收集的公共数据和实际测试数据，希望客观，公正地评估每个框架的现状和利弊。但是，由于与利益相关的问题，本文中的观点可能会带有偏见。您可以用挑剔的眼光看它。如果您在本文中发现任何评估失真，欢迎在此处报告。

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

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

01

用户

1. 1函数实现

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

在Web开发中，如果使用诸如vue和其他框架之类的框架阻止开发人员操作浏览器提供的所有api，则此类框架必须不成熟。小程序开发也是如此。没有任何开发框架可以限制底层的API调用。

各种业务功能的底层取决于微信公开的组件和接口（微信官方网站上介绍的组件和API规范，也称为微信本机API）。三方框架基于微信本机的二次打包。开发人员经常会有一个问题：小程序会不断地进行迭代升级。如果企业依赖于最新的Mini API，但尚未封装三方框架怎么办？

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

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

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

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

1. 2表演经验

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

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

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

1. 2. 1长列表加载

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

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

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

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

测试结果如下：

说明：以400个微博列表为例。从页面上的空白列表开始，每1秒钟触发一次上拉加载（添加了20个微博），记录一次，然后在20个触发后停止（页面达到400个微博），计算这20个触发的平均时间次，结果是在这20次中本机触发上拉->渲染完成的平均时间为876毫秒，最快的uni-app为741毫秒，最慢的为4493毫秒

当您初次查看这些数据时，您可能会更加困惑，不用担心，下面有详细的说明

注1：/ wepy测试数据为何不完整？

在wepy诞生之初，微信小程序不支持自定义组件，因此无法开发为组件。 wepy为了解决此问题，我们将用户编写的Vue组件编译为WXML（）中的模板，这些模板是变相实现的。组件开发能力和代码可重用性得到了改进，这在当时的技术条件下是一个很好的技术解决方案。

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

dom（如果有的话）

：在wepy的官方网站上，提到v 1. 7. 2的测试版本增加了对本机组件的支持。有很多实际的测试坑。由于是测试版本，因此官方表示不建议在官方网站上使用。文档，默认安装的v 1. 7. 3正式版不支持本机组件

：Wepy在400个列表中，为什么性能要比的本机框架更高。这与自定义组件管理开销和业务场景有关（wepy被编译为模板，并且不涉及组件创建和管理开销）。关于微博的后续报告是的，在组件数据传输方面，微信的本机框架具有性能优势。有关详细信息，请参见下面的测试数据。

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

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

本机框架主要在调用上很耗时。如果开发人员没有单独进行优化，则每次都会传输大量数据；而uni-app和芋头将在调用之前自动进行差异计算，并且每次仅传输更改的数据。

例如，当前页面有20条数据。触发上拉加载时，将重新加载20条数据。这时，当本机框架通过以下代码测试时，将传输40条数据

开发人员可以使用微信本机框架自行优化和简化数据传输。例如，修改以下内容：

经过上述优化和修改后，再次测试，微信本机框架的性能数据如下：

从测试结果可以看出，微信本机框架经过开发人员的手动优化可以达到较好的性能，但是uni-app和芋头与微信本机相比并没有较大的性能差距。

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

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

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

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

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

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

测试方法：

在手机（6 Pro）上进行了多次测试，并计算了平均值，结果如下：

说明：也就是说，当列表数为400时，“赞”按钮从单击更改为微信开发的应用程序的状态更改需要111毫秒。

测试结果数据的说明：

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

总的来说，该性能测试完成了2个测试，长列表加载和组件状态更新，并结合了2个实验，结论如下：

微信本机开发手动优化，uni-app>微信本机开发不是手动优化，芋头> wepy>

02

开发人员

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

2. 1平滑的学习曲线2. 1. 1 DSL语法支持

选择开发团队熟悉并可以快速入门的DSL是团队框架选择的基本要点。

首先，类似于Vue的原生开发语法有点难以描述。对于开发人员来说，这相当于学习一套新的语法，这极大地增加了学习成本。这一直被每个人批评。

其他开发框架基本上遵循Vue（类似于Vue）语法。其主要目的是重用现有的工程师技术堆栈并降低学习成本。在这一点上，框架对原始框架（/ Vue）语法的支持是一项重要措施。如果支持程度低，并且语法与原始框架有很大不同，则开发人员无异于学习新的框架。成本太高了。

在实际开发中，发现所有开发框架并没有完全实现Vue的所有语法并在Web上实现：

DSL语法支持评估：芋头，uni-app >> wepy>微信本机

2. 1. 2学习材料的完整性

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

关于教学课程：

学习材料完整性的评估： > uni-app>，芋头> wepy

2. 2现代前端开发经验

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

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

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

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

开发经验维度，比较结果：uni-app>芋头，> wepy>微信原生

可以在此处输出结论：如果您需要工程能力，那么就不用考虑微信本机开发了。

2. 3高效的社区支持

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

在开发此评估演示的过程中，我们的同学（掌握了vue和vue）在学习和研究各种多端框架时，由于语法，学习材料和社区的差异而感到真正的学习门槛，并且吐口水很多插槽。

综合评估，该评估的结论： ，uni-app>芋头>> wepy

2. 4主动开发迭代

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

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

频率

我们收集了每个项目分支在2019年4月的天数（时间为4. 1〜4. 3 0），结果如下：

提示：

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

产品更新日志

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

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

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

2. 5多终端多路复用

随着微信小程序的普及，支付宝，百度，字节跳动等公司也进入了小程序领域。这些公司中的每家的日常生活都超过1亿，并且拥有大量用户。企业主希望与每个企业保持联系。用户，无论用户位于哪个小程序中。

需求已转移给程序员，程序员应该怎么做？每个平台都真的到处移动砖块吗？这时，一组代码和多终端发布已成为许多程序员的梦想，并且出现了用于小程序的跨终端框架。

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

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

测试结果说明：

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

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

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

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

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

结合以上信息，此项的最终评估结论：uni-app> taro >>原生微信小程序wepy

可以在此处输出结论。如果有多个发布要求，可以直接排除本机开发和wepy的两种方法。

03

结论

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

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

1、如果您仅开发微信小程序而不进行多端，那么使用uni-app和芋头是一个更好的选择。它们相当于vue和网络世界。使用这些工具，您不再需要使用本机wxml开发。

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