练习小程序性能优化(程序性能优化方法)

微信小程序开发教程专栏总结了小程序的性能优化。

项目简介首先，简单介绍一下这个项目，它是一个常规的订购程序。

如图所示:

左边是一个分类菜单，右边是一个长长的列表。货物有多种类别。滚动一个类别后，您可以继续滚动并切换到下一个类别。同时，左侧类别菜单的选中状态会切换到当前商品列表中显示的类别。

考虑到更好的用户体验，并参考美团等订餐程序，本次商品清单数据返回一次。目前的问题是，商品数量多的时候，第一次渲染时间很长，页面会卡顿。

优化方向逻辑优化悄悄话bb:其实原代码(由于历史原因)写的太差了...……OTL

先放一张图。

Bb:连小程序都看不下去了。我必须警告你。

微信开发者工具有警告，提示也有具体代码的位置，所以关键是这个setData！!!

我们来看看官方对小程序性能和setData优化的一些建议。(developers.weixin.qq.com/miniprogram…)

具体做法:

1.setData不能一次传输太多数据。如果列表太长，可以单独渲染[比如转换成二维数组，每次循环渲染一个数组]。V1:简单粗暴的版本

//一次呈现一个类别//假设goodsList是一个二维数组goodslist.foreach ((item，index)= >；{ this . setdata({[` goods list[$ { index }]`]:item } })如上复制代码会有问题。页面的首屏渲染速度很快，但是当你点击页面操作(比如购买按钮等。)，页面会卡，过一会儿会有回应。操作的反馈严重滞后。

其实这是因为，这个循环减少了单个setData的数量，却变成了多个setData循环。我们看第一屏显示的还不错，但实际上其他类别(其他数组)还在渲染，线程还在忙。JS线程一直在编译渲染，点击事件无法及时交付给逻辑层，逻辑层无法及时交付操作处理结果给视图层。

V2:计时器黑客版

由于js线程忙于渲染，我们可以先强制它停止。于是就有了v2的定时器hack版本。

//一次呈现一个分类let len = data.goodsList？data . goods list . length:0；设idx = 0 let timer = setInterval(()= gt；{ if(idx lt；len){ that . setdata({[` goods list[$ { idx }]`]:data . goods list[idx]})；idx++ } else { clear interval(timer)} }，15)；现在复制代码解决了首屏渲染速度的问题，点击按钮时响应延迟的问题也解决了。只是代码有点hack，逼强迫症。

V3:大黑仔-虚拟列表

简单来说，虚拟列表的原理就是只渲染当前显示屏幕区域，前N屏，后N屏的数据，用单独的字段保存当前要显示的数组(即当前屏+前N屏+后N屏)，列表每次滚动重新计算要显示的数据，更新这个字段，页面就会相应更新。这样页面上的元素节点数量就不会太多，可以支持大量数据的长列表。

更详细的原理和实现，同学们可以自行搜索，这里不展开。

小程序官方还有一个开源的虚拟列表组件:recycle-view。

2.setData可以支持粒子更新和指定给特定的属性。比如额外购买需要更新产品右上角的小数字，可以这样写:

this . setdata({[` goods list[$ { category index }][$ { good index }])。num`]: gooditem.num})复制代码3。与页面无关的数据不应该保存在data中，用setdata更新，因为setData会触发页面渲染。例如:

页面({数据:{...}，//与页面呈现状态无关的数据:{haslogin: false，}，...})//更新的时候直接赋值就可以了。this.state.hasLogin = true复制代码PS:或者你甚至不需要挂载到page对象下，用普通变量保存就可以了。

4.图像尺寸优化。如果长列表中没有对图片大小的限制，大量的大图片会占用大量内存，可能会导致iOS客户端的内存占用上升，从而触发系统回收小程序页面。除了内存问题，大图也会导致页面切换卡顿。

解决方法是根据当前显示图片区域的大小，拍摄大小刚好合适的图片(2x -3x)。

图片建议用CDN。一般CDN服务商都会提供一个剪贴图片的接口，然后接口只会返回原图的链接，前端会根据需要发送参数来剪贴图片。前端可以自己编写一个公共的图像处理方法，也可以自己封装图像组件。

CDN服务提供商的图像剪辑API文档，带有常用图像:

阿里云图像缩放七牛云图像处理5。减少不必要的数据请求。比如订餐页面进入，需要获取位置，然后根据位置获取最近的门店。需要请求前两个接口(具体根据业务需求)。最后，如果最近的店铺和上次一样，就不需要再次获取店铺详情和产品数据。

体验优化1。短时间内合并多个装货提示仍然是订单页面流程。如上所述，进入页面需要获取位置界面。位置接口返回结果后，可以获取位置值来获取最近的店铺，最后可以请求店铺和商品数据。

这三个接口是串行的。此时，如果我们对每个界面都弹出加载提示，就会出现加载显示一会儿，消失，显示一会儿，又消失的现象...这种体验不是很好。

建议短时间内多次发起的多个加载请求，可以通过封装请求，在请求中统一处理加载的方式进行合并。

例如:

设showLoadingTimer = null设showRequestLoading = false//标记是否加载/** *封装请求* @param {*} {showLoading:是否加载，选项:请求url、数据等参数。需要显示} */函数请求({showloading = true，...options}) {//显示请求加载句柄Show loading(Show loading)wx . request({...complete () {//关闭requestloading句柄showLoading (false)}}}/* *封装请求加载*如果短时间内多次调用showLoading，则一起显示。而不是闪烁* @ param show loading */function handle show loading { if(show loading){//显示加载清除超时(show loading timer)；如果(！showRequestLoading){ showRequestLoading = true；wx . shownavigationbarloading()；wx . show loading({ title: ；Loading "，mask: true})} else {//200 ms后关闭加载show loading timer = settimeout(()= >；{ showRequestLoading = falsewx . hidenenavigationbarloading()；Wx.hideLoading() }，200) }}复制代码2。可以在第一次加载整页时使用页面加载动画或者骨架屏来优化加载体验。3.静默获取和更新数据。比如这个订餐页面，每次onShow都会调用位置接口，得到最近店铺的界面，但是如果不显示加载，用户就没有感知，体验会更好。

界面优化需要重点关注界面的粒度控制。有时候前端因为合并接口可以减少一个请求，体验更好；但有时候如果界面数据太多，响应太慢，可以考虑是否可以后期采集一些数据，让主页面内容先渲染，按照这个设计拆分界面。

例如，在项目的订购页面中，原始购物车数据和商品规格弹出窗口显示的详细数据都是从获取商店商品的界面一次性返回的。但是这个接口本来是为了一次性返回所有商品而设计的，这样会导致后端需要查询的数据太多，表也更多。因此，用于获取购物车和产品细节的界面被拆分到单独的界面中，从而减少了用于获取商店产品的界面的响应时间，并且可以更快地显示页面。

其实上面说的很多逻辑优化和界面优化都是细节，并不是太高级的技术。我们平时迭代的时候可以关注一下。体验的优化，要求前端学生除了前端技术之外，更注重用户体验和设计方面的知识，这也是一个有追求的前端应该具备的技能

因此.....技术之路漫漫，我们互相鼓励吧。

也就是上面的实践总结了小程序性能优化的细节。请多关注主机参考其他相关文章！

这几篇文章你可能也喜欢：

• 实践总结小程序性能优化(小程序性能测试)

本文由主机参考刊发，转载请注明：练习小程序性能优化(程序性能优化方法) https://zhujicankao.com/81967.html