真实测评：用uni-app开发小程序，比原生开发好在哪里？

小程序原生开发有不少槽点：

原生wxml开发对Node、预编译器、webpack支持不好，影响开发效率和工程构建流程。所以大公司都会用框架开发

微信定义的这套语法，wxml、wxs，以及wx:if等语法，私有化太强。不如正经学vue，学会了全端通用，而不是只为微信小程序

vue生态里有太多周边工具，可以提高开发效率，比如ide、校验器、三方库。。。而微信的开发者工具和专业编辑器相比实在不好用，个性化设置也非常少

作为前端工程师，除了微信小程序，还要开发web、其他小程序甚至App，人们不喜欢来回切换开发工具和变更语法思考方式。

uni-app自然可以解决这些问题，但开发者又经常有些顾虑：

怕使用uni-app后，微信小程序里有的功能无法实现，受制于uni-app的更新

怕性能不如原生WXML

怕框架不成熟，跳到坑里

担心社区生态不完善

本文从开发者关心的功能、性能、学习门槛、开发体验、生态、可扩展性等维度，逐个分析对比，给予说明。

1、功能实现

开发者最常问的问题：如果小程序迭代升级，新增了一批API，但uni-app框架未及时更新，该怎么办?

其实这是误解，uni-app不限制底层API 调用;在小程序端，uni-app支持直接编写微信原生代码。

类比传统web开发，如果vue、react等框架的使用，造成开发者无法操作浏览器提供的所有api，那这样的框架肯定是不成熟的。小程序开发也一样，uni-app框架中，同样可调用微信提供的所有原生代码。

故如果存在某些API(平台特有或新增API)，uni-app尚未封装，开发者可直接在uni-app中编写微信原生API，即wx.开头的各种API。

举个例子，目前uni-app虽然尚未封装跨平台的广告(ad)组件，但开发者在小程序端依然可以使用微信组件来展现广告，代码示例如下：

包括微信小程序自定义组件、WXS、云开发这些复杂用法，在uni-app里一样全面支持。

所以，结论是：使用uni-app框架开发，在功能上和原生小程序开发没有区别，不会有任何限制。

2、性能体验

开发者常问的第二个问题：三方框架，内部大多做了层层封装，这些封装是否会增加运行负载，导致性能下降?

同样是多虑了，uni-app不会导致性能下载，甚至对很多环节做了自动优化，很多场景下性能体验比微信原生开发更好。

类似使用vue.js开发web，不但不会造成性能比原生js差，反而由于虚拟dom和差量更新技术的运用，在大多数场景下，比开发者手动写代码操作dom的性能还好。

小程序中需要频繁的写setData代码来更新数据，这里很重要的就是差量数据更新。如果不做差量，代码性能不好，如果每处逻辑都判断差量数据更新，那代码写起来太麻烦了。

使用uni-app，底层自动差量数据更新，简单而高性能。

我们从优化理论、实测数据两个维度来仔细说明。

2.1、理论：框架优化方案

为提高性能体验，小程序从架构设计层面做了很多工作：

逻辑层、视图层分离，避免JS运算阻塞视图渲染

单独定义组件标签(wxml)，减少DOM复杂度

精简样式(wxss)，提升渲染性能

复杂组件原生化(video/map等)，解决web组件的功能/体验缺失

通过这些规范约束，大幅提升了小程序的整体性能体验，但依然存在不少性能坑点，其中以setData最为频繁普遍。

这里引用微信官方的描述，简单介绍一下setData背后的工作原理：

小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。

为简化开发，微信将evaluateJavascript调用封装成了setData JS方法，实现视图层和逻辑层的数据传输，数据流示意图如下：