北京华网天下

小程序原生开发的槽点与 uni-app 的解决方案

2024-08-07

来源：网络整理

小程序原生开发存在很多坑：

原生的wxml开发对Node和预编译器的支持不好，影响开发效率和工程构建进度，所以大公司会采用框架开发

微信定义的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等框架使得开发者无法操作浏览器提供的所有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要好。

在小程序中，需要频繁写代码来更新数据，这里最重要的是差异化数据更新，如果不做差异化数据，代码性能会很差，如果每一条逻辑都确定差异化数据更新，代码写起来就太麻烦了。

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

我们从优化理论和实测数据两个维度进行详细阐述。

2.1 理论：框架优化解决方案

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

逻辑层与视图层分离，避免JS操作阻塞视图渲染。单独定义组件标签（wxml），降低DOM复杂度。简化样式（wxss），提升渲染性能。复杂组件原生化（/map等），解决web组件功能缺失/体验不足通过这些标准化的约束，小程序整体的性能体验得到了很大的提升，但仍然存在不少性能坑，其中最频繁、最常见的就是。

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

小程序的视图层目前作为渲染载体，而逻辑层则是独立的运行环境。从架构上看，和是独立的模块，并没有直接的数据共享通道。数据传输其实是通过双方提供的服务来实现的。

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

的执行受很多因素影响，如果每次传输的数据量过大或者调用频繁（见微信官方介绍），都有可能引发性能体验问题。

幸运的是，uni-app针对这两方面都进行了优化。

2.1.1 减少传输的数据量

假设当前页面有一个列表（初始值为a,b,c,d），现在我们想往列表中追加4个新的列表项（e,f,g,h），我们分别使用微信原生和uni-app两种模式来编写代码。

小程序原生代码：

如上微信原生代码所示，在执行方法时，会把列表中a、b、c、d、e、f、g、h这8个列表项全部传输出去。

uni-app代码：

如上uni-app代码所示，执行方法时，只会传输列表中新增的四个列表项e，f，g，h，大大简化了传输量。

Uni-app采用了JSON Diff库，在调用前会先对比历史数据，精准高效的计算出有变化的差异数据，然后再调用，只传输变化的数据，从而达到传输数据量的最小化，大大提高通信性能。

Tips：也许有的同学并不关心把a,b,c,d,e,f,g,h这8个列表项的数据转移到e,f,g,h这4个列表项的优化，但是我们提醒大家千万不要小看这个机制，以上只是一个demo例子：

在实际列表场景中，每个列表项可能包含缩略图、标题、摘要、时间等各种信息，每个列表项的数据会比较大（假设1k）；假设当前页面有20个列表项，上拉4次之后页面就变成100条记录；如果再次上拉，页面就变成120条记录，此时的情况会和上面微信原生的方法不一样，120条记录（120k）全部传到上面的uni-app模式下，只会传新增的20（101~120）条记录（20k），数据量是原生模式的1/6！页面列表项越多，这个差别越大，当有100条记录时，uni-app传输的数据量就会变成微信原生传输数据的1/10！ 2.1.2.降低调用频率

假设我们需要改变多个变量的值，我们分别在微信原生和单应用模式下编写代码。

以上四个调用会触发四个逻辑层和视图层的数据通信。

限制程序内存使用_开发的小程序内存限制_内存限制的作用

上面uni-app的代码会把一条数据{"a":1,"b":2,"c":3,"d":4}合并成一条，然后一次调用就可以把所有数据全部传输过去，大大减少了时间消耗，减少了调用频率。

uni-app之所以有这样的优势，是因为uni-app基于Vue进行了深度定制，并且利用了Vue的机制。

2.2. 实测：性能对比数据

有了以上的理论分析之后，我们接下来会进行实机测试，并使用数据进行对比。

测试模型如下：

开发内容：开发一个模仿微博小程序首页的复杂长列表，支持下拉刷新，上拉翻页，点赞，模仿微博的列表是一个包含很多组件的列表，这种复杂列表对性能的压力比较大，非常适合做性能测试。

界面如下：

开发版本：分别使用微信原生和uni-app开发两套代码，uni-app使用cli方式默认安装。测试机型： 6 Pro、MIUI 10.2.2.0稳定版(最新版)、微信版本7.0.3(最新版)测试环境：在开始各个框架的测试前，杀掉各个App进程并清除内存，保证测试机环境基本一致；每次都从本地电脑读取静态数据，屏蔽网络差异。在更新和页面渲染完成后，需要精准计时，人的视觉计时肯定是不够的，我们利用程序追踪制定了以下计时时序：

定时开始时间：交互事件触发，在框架赋值之前，如：上拉load（）函数开始定时结束时间：页面渲染完成（微信回调函数开始） Tips：回调函数开始可以认为是页面渲染完成的时间，因为微信定义如下（微信规范）：

测试方法：从页面上空的列表开始，通过程序自动触发上拉加载，每次添加20个列表，记录每次所用时间；以固定间隔连续触发N次上拉加载，使页面共有20*N个列表，计算这N次从触发上拉到渲染完成的平均时间。

测试结果如下：

注：以 400 条微博列表为例，从页面空列表开始，每隔 1 秒触发一次上拉加载（添加 20 条微博），记录每次加载耗时，加载 20 次后（页面达到 400 条时）停止，计算这 20 次的平均耗时。结果发现，这 20 次中微信原生触发上拉 -> 渲染的平均耗时为 876 毫秒，uni-app 为 741 毫秒。

这个数据可能和很多人的直觉相反，uni-app的性能其实是比微信原生还要好的！

当然，使用微信原生开发，也可以自己写代码优化。但每个业务都写太多的判断不现实，还是用框架舒服点。

这个结果和web开发类似，也包括原生js开发，vue，框架等等，如果不做特别的优化，使用原生js编写的网页性能往往比vue和框架差。

正是因为Vue以及框架的优秀，良好的性能，以及良好的开发体验，导致原生js开发的使用逐渐减少。

3. 社区生态

3.1：外围轮

小程序脱离Web构建了自己的生态，很多轮子在Web生态里无法使用。

微信小程序尚有周边的生态，但其他几个小程序平台的生态基本没有建立起来。

uni-app周边生态非常丰富，插件市场有近800个插件。

首先uni-app兼容小程序生态，各类自定义组件可直接引入使用，在此基础上uni-app的插件市场拥有更多vue组件，可同时跨多端使用，性能优异。

这使得uni-app生态成为最丰富的小程序开发生态。

例如在富文本解析、图表等组件上，uni-app的插件性能超越了wx-等微信小程序组件。