微信小程序性能优化汇总

12）不使用废弃接口：

因为使用即将废弃或已废弃的接口，可能导致小程序运行不正常。一般而言，接口不会立即去掉，但保险起见，建议不要使用，避免后续小程序突然运行异常；

13）避免过大的 WXML 节点数目：

建议一个页面使用少于 1000 个 WXML 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 WXML 节点树会增加内存的使用，样式重排时间也会更长；

14）避免将不可能被访问到的页面打包在小程序包里：

因为小程序的包大小会影响加载时间，所以应该尽量控制包体积大小微信小程序一直加载中?，避免将不会被使用的文件打包进去；

15）及时回收定时器：

因为定时器是全局的，并不是跟页面绑定的，所以当页面因后退被销毁时，定时器应注意手动回收；

16）避免使用 css ':active' 伪类来实现点击状态：

使用 css ':active' 伪类来实现点击状态微信小程序一直加载中?，很容易触发，并且滚动或滑动时点击状态不会消失，体验较差；建议使用小程序内置组件的 'hover-*' 属性来实现；

17)滚动区域可开启惯性滚动以增强体验：

因为惯性滚动会使滚动比较顺畅，在安卓下默认有惯性滚动，而在 iOS 下需要额外设置 -webkit-overflow-scrolling: touch 的样式；

常见的优化方向

总结一些经常会出现问题的地方，并介绍可以使用的解决方法；

1、启动加载性能优化：

11、控制代码包大小：

勾选开发者工具中"上传代码时自动压缩"；

及时清理无用代码和资源文件；

减少代码包中的图片等资源文件的大小和数量；

12、分包加载：

将小程序中不经常使用的页面放到多个分包内，主包是保留最常用的核心页面；启动时只加载主包，使用时按需下载分包；

使用分包加载会出现用户首次进入分包页面时需要进行分包的下载和注入，造成页面切换的延迟；开发者可使用分包预下载，预先配置页面可能会跳转到的分包，框架在进入页面后根据配置进行预下载；

13、独立分包：

从分包页面启动时，需要先依赖于主包的下载和注入，启动速度受主包限制；使用独立分包，从独立分包页面启动，只要下载和注入分包就可以打开页面；

2、首屏加载的体验优化建议：

21、提前请求：异步数据请求不需要等待页面渲染完成（onLoad 阶段就可以发起请求，不用等ready）；

22、利用缓存：利用storage API对异步请求数据进行缓存，二次启动时先利用缓存数据渲染页面，而下拉刷新或者缓存过期才更新数据；

23、避免白屏：先展示页面骨架和基础内容；

24、及时反馈：即时地对需要用户等待的交互操作给出反馈，避免用户以为小程序无响应；

3、避免不当使用setData：

31、存在setData的数据过大（通讯耗时与数据量相关，页面更新延期；使用setData的特殊key实现局部更新）；

// 1: 初始一个list，存储列表数据
this.data = startList
// 2: 监听滚动事件，滚动到底部获取新数据，并追加到list尾部,最后重新setData
onReachBottom:()=>{
  const {list} = this.data
  fetchNewData().then((res)=>{
    list.push(res.list);
    this.setData({list})
  }
}

大部分人面对长列表滚动的时候，一开始的处理方式都是这样的，如果数据不多，只有几页可能不会太暴露问题；但当页数过多，几十页甚至上百页的情况，list的数据会越来越大，每次setData的数据就会越来越多，因而每次页面重新渲染的节点就会越来越多，从而导致滚动到后面，加载越来越慢。另外，由于小程序的视图渲染层和数据逻辑处理层是分开的，不是在同一个线程上面的，从用户触发页面交互，到处理数据逻辑，最后呈现页面，数据到视图是需要传输的，因而小程序本身对数据大小也有限制，不能超过1M。

我们可以通过数据路径的写法，来将数据分批的传输到视图层中，减少一次性setData的数据大小。具体写法如下：

// 1.通过一个二维数组来存储数据
let feedList = [[array]];
// 2.维护一个页面变量值，加载完一次数据page++
let page = 1
// 3.页面每次滚动到底部，通过数据路径更新数据
onReachBottom:()=>{
  fetchNewData().then((newVal)=>{
    this.setData({
      ['feedList[' + (page - 1) + ']']: newVal,
    })
  }
}
// 4.最终我们的数据是[[array1],[array2]]这样的格式，然后通过wx:for遍历渲染数据

32、列表局部更新：

比如，将点赞的id传过去，查找相对应id的那条数据的下标（index是不会改变的），用setData进行局部刷新

this.setData({
    list[index] = newList[index]
})

33、短时间内频繁调用setData：

因为会出现操作卡顿、交互延迟、页面渲染延迟等问题； 优化：避免不必要的setData，对连续setData调用进行合并；

34、避免后台态页面进行setData，因为后台态页面去setData也会抢占前台页面的执行

4、存在短时间内发起太多图片请求：

就是渲染页面时，一次性发送了过多的图片请求，导致了同一时间发起了过多的http请求，http连接是非常耗时的，尤其是一次性发起这么多，并且一次性发起的http链接也是有限制的，比如chrome浏览器就限制一次性最多6个。

所以在渲染页面时，不在视图范围内的图片我们不加载，只有元素出现在视图范围内了，再渲染。

常规的做法是，通过 getBoundingClientRect() 获取元素的位置，然后与页面滚动位置比较，如果出现在视图内，就将 img 显示。这种方式有2个问题：

1）getBoundingClientRect()方法调用本身容易引起页面重排；

2）监听滚动事件本身就频繁触发，虽然可以通过节流的方式来减少，但还是容易增加无谓代码处理；

微信提供了 IntersectionObserver 对象，IntersectionObserver 对象，用于推断某些节点是否可以被用户看见、有多大比例可以被用户看见。

通过这个api我们不用再主动去监听元素位置了，在页面渲染一开始，通过这个api指明需要监听的元素，系统会自动去监听了元素位置。

let data = list;

data.forEach((item,index)=>{
  this.createIntersectionObserver().relativeToViewport.observe(`.img-${index}`,res=>{
    if (res.intersectionRatio > 0){
      this.setData({
        item.imgShow:true
      })
    }
  })
})

intersectionRatio值大于0，说明元素出现在视图中了，重新setData数据，显示图片组件。

5、存在图片太大而显示区域过小：

这个问题就是指图片尺寸太大了，而页面上我们显示的尺寸又太小了，图片尺寸大，请求图片就越慢，导致页面渲染速度下降。

对于页面里面的图片，最好都把图片存储在cdn服务器上，一个是能充分利用cdn缓存来加快请求速度，另外一个就是cdn上能够将图片进行一定的处理，比如裁剪。我司就是通过cdn来响应图片处理，然后请求图片时告诉cdn服务器需要什么要的尺寸图片，由cdn服务器响应对应尺寸图片。

6、key值在列表渲染中的作用：

key值在列表渲染的时候，能够提升列表渲染性能，为什么呢？首先得想想小程序的页面是如何渲染的，主要分为以下几步：

1. 将wxml结构的文档构建成一个vdom虚拟数

2. 页面有新的交互，产生新的vdom数，然后与旧数进行比较，看哪里有变化了，做对应的修改（删除、移动、更新值）等操作

3. 最后再将vdom渲染成真实的页面结构

key值的作用就在第二步，当数据改变触发渲染层重新渲染的时候，会校正带有 key 的组件，框架会确保他们被重新排序，而不是重新创建，以确保使组件保持自身的状态，并且提高列表渲染时的效率。

key值如果不指明，默认会按数组的索引来处理，因而会导致一些类似input等输入框组件的值出现混乱的问题。

因而，在做list渲染时，如果list的顺序发生变化时，最好增加key，且不要简单地使用数组索引当做key。

7、避免不当使用onPageScroll：

只在必要的时候监听pageScroll事件；

避免在onPageScroll中执行复杂逻辑；

避免在onPageScroll中频繁调用setData；

避免频繁查询节点信息（SelectQuery）；

8、canvas渲染：

分层绘制到不同canvas，不变的部分单独绘制到一个canvas，动态生成地绘制到一个canvs，最后再合入到一个canvas。

总结

上文总结的只是平时一些常见的问题，并不是全部的问题；且随着微信小程序基础库的升级，有些问题可能会被优化解决，但也可能会产生其他的新问题。