作者 | 崔洪宝编辑 | 王颖
自 2017 年 1 月 9 日微信小程序诞生以来，经过两年多的迭代升级，已上线数百万小程序，成为继 Web、iOS 和 .
随之而来的，小程序的开发生态也在蓬勃发展。从最初的微信原生开发，到wepy、taro、uni-app等框架，从刀耕火种发展到现代开发，生态越来越丰富。
有了更多的选择，问题就来了，开发小程序，我们应该使用原生框架还是三方框架？
首先，微信原生开发的槽位大多集中如下：
原生开发对Node、预编译器支持较差，影响开发效率和项目建设进程。
微信定义了一个不伦不类的语法。不如学vue，学会通用，不只是微信小程序。
vue/生态圈的周边工具太多了，可以提高开发效率的，比如IDE、、第三方库……
与专业编辑相比，微信ide有一些劣势和不足。
同时，开发者对三方框架总是有各种顾虑：
怕是性能不如原版。
恐怕有些功能框架无法实现，只能使用原生的。
怕车架不稳，跳坑。
还有很多三方框架，用哪一个。
面对如此纠结的场景，不少热心的开发者纷纷发表评论文章分享心得，但又觉得意见不一，信息过时。缺乏当今流行的非常专业、深入或“硬核”的评估报告。
制作评估报告不同于一般的经验分享免费小程序开发公司，实际上是非常耗时的。它需要：
换句话说：要评价真实，就必须下功夫！
uni-app 团队花了 2 周时间完成这份报告，并坚持每季度更新这份评估报告。当前更新是 2019 年 5 月。
本文从面向用户和面向开发者两个维度对微信原生与主流的wepy、taro、uni-app开发框架进行横向对比，希望为开发者提供一种选择小程序框架的途径。参考思路。本文基于各个框架官网可以收集到的公开数据和真实测试数据，希望客观公正地评价各个框架的现状和优缺点。但是，由于利益关系，本文的观点很可能有偏颇。你可以用批判的眼光看待它。如果您发现本文评价有任何歪曲，欢迎在此举报：
面向用户和面向开发者的维度，包括：
用户：提供完整的服务实现，保证高性能体验。
开发者：平坦的学习曲线、现代化的开发经验（工程）、高效的社区支持、积极的开发迭代、多终端复用。
1.用户1.1函数实现
软件开发的首要目标是为用户提供完整的、闭环的业务功能。
在web开发中，如果使用vue等框架使得开发者无法操作浏览器提供的所有API，那么这样的框架肯定是不成熟的。小程序开发也是如此。没有开发框架可以限制底层 API 调用。
各种业务功能的底层依赖于微信暴露的组件和接口（微信官网介绍的组件和API规范，即微信原生API）。三方框架是基于微信原生的二次封装。问：小程序不断迭代升级。业务依赖最新的小程序API，但是三方框架没有封装怎么办？
其实和vue做web开发一样，浏览器有了新的API，并不涉及vue的升级。本次评测中的所有框架都不会限制开发者调用底层能力。原因在这里详细解释：
注：以上顺序是按照各个框架的诞生顺序排序的，下同。
相关链接：
芋头代码与小程序代码混合：
条件编译：
因此，三方框架可以调用所有的小程序API来满足用户的业务需求。在这个维度上，框架之间没有区别。
然而，不同之处在于性能体验。
1.2 性能经验
大多数三方框架都是逐层封装的。这些封装会增加运行负载并导致性能下降吗？尤其是与原生微信小程序的开发相比性能如何，这是大家普遍关心的问题。
为了客观对比，我们特地搭建了一个测试模型，具体如下：
我们以上述微博小程序为例，测试容易出现性能问题的两个点：长列表加载和大量点赞组件的响应。
1.2.1 长列表加载
模仿微博的榜单是一个有很多组成部分的榜单。这种复杂的列表对性能的压力更大，非常适合性能测试。
从触发上拉加载到数据更新和页面渲染完成，都需要准确的时序。人类视觉计时绝对是不够的。我们采用程序嵌入的方法，制定如下时序：
温馨提示：回调函数的开始时间可以认为是页面渲染完成的时间，因为微信定义（详见下方链接）如下：
相关链接：
微信规范：
测试方法：从页面上的一个空列表开始，程序自动触发上拉加载，每次添加20个列表，记录单次耗时；以固定间隔连续触发N次上拉加载，使页面达到20*N个列表，计算从触发上拉到渲染完成的平均时间。
测试结果如下：
说明：以400条微博列表为例，从页面空列表开始，每1秒触发一次上拉加载（新增20条微博），记录单次耗时，停止触发20次后（页面达到400条微博），计算这20次的平均时间，结果是这20次微信原生触发上拉->渲染的平均时间是876毫秒，最快的uni -app 是 741 毫秒，最慢的是 4493 毫秒
当你第一次看这个数据时，你可能会感到困惑。别担心，下面有详细的说明。
解释1：为什么/wepy 测试数据不完整？
、 wepy诞生之初，微信小程序不支持自定义组件，无法组件化开发；、Wepy 为了解决这个问题，wepy 将用户编写的 Vue 组件编译成 WXML 中的 ()，变相实现了组件化开发能力和代码复用性的提高，是当时技术条件下的一个很好的技术方案。那时。
但是在这种方案中，当页面复杂，组件较多时，页面上的DOM节点数会大大增加，甚至超过微信DOM节点数的限制。我们在红米手机（6 Pro）上实测，当页面组件超过500个时，wepy实现的仿微博App会报如下异常并停止渲染，所以这两个测试框架是在组件多的时候测试的。数据不完整。这也意味着当页面组件过多时，这2个框架就不能使用了。
dom 如果你做了什么
相关链接：
自定义组件：
模板（）：
:#/
注2：为什么测试数据显示uni-app的性能略好于微信原生框架？
事实上，当页面有 200 条记录（200 个组件）时，taro 性能数据也优于微信原生框架。
微信原生框架的耗时主要在调用。如果开发者不单独优化，每次都会传递大量数据；而 uni-app 和 taro 会在调用前自动做 diff 计算，每次只传递改变的数据。
例如，当前页面有20条数据。触发上拉加载时，将新加载20条数据。这时，当原生框架通过下面的代码测试时，会传输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开发类似，也包括原生js开发、vue、等。如果不做特别优化，原生 js 编写的网页性能往往不如 Vue 和框架。
正是因为优秀的Vue和框架，良好的性能和良好的开发体验，使得使用原生js开发的人逐渐减少。
复杂的长列表加载下一页。评测结论：微信原生开发手动优化，uni-app > 微信原生开发没有手动优化，taro > wepy >
Tips：有人认为uni-app和uni-app是一样的。早期使用它，但由于性能和 vue 语法支持问题，它已经重新开发。
1.2.2 类组件响应速度
对于长列表中的一个组件，比如like组件，点击后是否可以及时修改和like状态？是本次测试的评价点。
测试方法：
对红米（6 Pro）进行多次测试，取平均值，结果如下：
注：即当列表数为400时，点赞按钮从点击变为微信原生开发的app状态需要111毫秒。
测试结果数据说明：
组件数据更新性能评测：微信原生开发、uni-app、taro > wepy >
综上所述，本次性能测试做了2个测试，长列表加载和组件状态更新，结合2个实验，得出如下结论：
微信原生开发手动优化，uni-app>微信原生开发不手动优化，taro > wepy >
2. 开发者
在满足用户业务需求的前提下，我们来谈谈开发者的需求，从以下几个维度进行对比：
2.1 平滑的学习曲线2.1.1 DSL 语法支持
选择开发团队熟悉并能快速上手的DSL，是团队框架选择的基本点。
首先，微信原生的开发语法，和Vue类似，有点不伦不类。对于开发者来说，相当于学习了一套新的语法，大大增加了学习成本，一直被大家诟病。
其他开发框架基本遵循 Vue（类 Vue）语法。其主要目的是复用工程师现有的技术栈，降低学习成本。此时，框架对原框架（/Vue）语法的支持是一项重要措施。如果支持度低，原框架的语法差异较大，开发者无异于学习一个新框架。成本太高了。
在实际开发中，发现各个开发框架并没有完全实现Vue和web的所有语法：
Wepy的开发风格接近Vue.js，属于类Vue的实现。相比微信原生开发来说是一大步，但相比完整的Vue语法还是有很大差距的。开发时需要单独学习其规则；
，uni-app框架基于Vue.js核心，通过修改Vue.js的总和，实现小程序端的操作。支持的Vue语法略少，uni-app基本支持大部分Vue语法，比如复杂的表达式等；
Taro 对 JSX 的语法支持也达到了大部分人都支持的完美程度。
DSL语法支持评测：taro,uni-app > > wepy > 微信原生
2.1.2 学习资料的完整性
官方文档、问题搜索和示例演示的完整性：
教学课程：
学习资料完整性评价：微信原生 > uni-app > , taro > wepy
2.2 现代前端开发经验
在开发体验层面，微信原生开发处于明显劣势。主要差距有：
其他小程序开发框架都支持cli方式，可以在主流前端工具中开发，基本都有d.ts的语法提示库。
由于、uni-app、taro直接支持vue和语法，支持的IDE工具链丰富，着色、校验、格式化完善；wepy比较弱，还有一些第三方维护的插件。
一个好的开发工具绝对可以大大提升开发体验。在这个维度上，显着更高的框架是uni-app，它的生产公司也是生产公司，.io()。四大主流前端开发工具之一（堪比百度指数，详情见下方链接）。
开发体验维度，对比结果：uni-app > taro, > wepy > 微信原生
这里可以得出一个结论：如果需要工程能力，微信原生开发就别想了。
相关链接：
比较百度指数：#//?=,,,
2.3 有效的社区支持
学习和发展难免会遇到问题。官方技术支持和社区活动非常重要。
在开发这个评测demo的过程中，我们的同学（同时掌握vue和Vue），在学习研究各种多端框架的时候，真切感受到了语法、学习资料、社区的差异带来的学习门槛，吐槽了一句很多凹槽。
综合评测，本评测结论：微信原生，uni-app > taro > > wepy
2.4 次活跃的开发迭代
开发者必须关心一个问题：项目是否长期维护？
这个问题可以通过频率、产品更新日志()、百度搜索指数等指标来衡量和比较。
频率
我们收集了2019年4月（时间为4.1~4.30），每个项目在分支上的天数，结果如下：
提示：
从记录来看，taro 和 uni-app 更新比较活跃，而 wepy 和 wepy 比较弱，没有维护。
产品更新日志
通过浏览产品更新日志，可以确认产品是否在积极迭代、添加新功能、修复用户Bug。
我们分别查看各个框架的官方链接的 log()，链接地址如下：
通过产品更新日志对比，微信原生、taro、uni-app更新频繁，bug修复和新功能添加都处于比较紧凑的状态；而 wepy 已经很久没有发布了，而且 wepy 甚至已经有将近一年的时间了。正式版当时尚未发布，开发者在选择机型时需谨慎。
2.5 多路复用
随着微信小程序的火爆，支付宝、百度、字节跳动等企业也纷纷进入小程序领域。这些公司拥有超过 1 亿日活跃用户和大量用户。企业主希望通过他们的业务接触到每一位用户。无论用户在哪个小程序中。
需求转给程序员，程序员该怎么办？每个平台都搬砖是真的吗？这时，一套代码和多终端发布成为了很多程序员的梦想，小程序的跨终端框架应运而生。
现实真的可以这么理想吗？每个跨端框架真的能像官网宣传的那样开发一次，发布到所有小程序平台吗？甚至在 H5 平台上重用代码？
我们用事实说话，依然使用上面提到的仿微博App：依次发布到各个平台，并在各个端验证各个框架的兼容性。结果如下：
测试结果说明：
从这个简单的例子可以看出跨端支持评测结论：uni-app、taro >> 原生微信小程序、wepy
但是，只有上面的测试并不全面，实际的业务要比这个测试用例复杂的多。但是我们不能开发很多复杂的业务来进行评估，所以需要根据各种文件补充一些信息。由于每个框架的文档都描述了对各种组件和 API 的跨端支持程度。我们浏览了几家公司的文档，发现他们基本上都是以微信小程序为基准，然后在另一端实现各种组件和API：
对于一个跨端的框架，一方面要考虑框架提供的通用API的跨端支持，同时还要考虑不同的特性如何区别两端是兼容的。毕竟每一端都会有自己的特点，不可能完全一致。
跨端框架还涉及到一个ui框架的跨端问题。评估结果如下：
最后，添加跨端案例：
综合以上信息，本项最终评测结论：uni-app > taro > > 原生微信小程序，wepy
这里可以得出一个结论。如果有多个端到端的发布需求，可以直接排除微信原生开发和wepy这两种方式。
结语
真实客观的永远是实验和数据，而不是结论。不同需求的开发者可以根据以上实验数据得出自己的结论。
但作为一个完整的回顾，我们也必须提供一个总结，虽然它可能会增加我们的主观感受：
如果只开发微信小程序，不做多终端，那么使用uni-app和taro是更好的选择。它们相当于网络世界中的 vue 和 taro。有了这些工具，就不再需要使用原生的 wxml 开发了。
如果开发多终端，uni-app和taro都可以用。您可以根据自己熟悉的技术栈进行选择。相对来说，uni-app的多终端成熟度更高。
如果读者认为本文中的任何评价存在歪曲，请在此处举报：
点击查看更少的错误