我们都知道，性能的好坏直接影响用户的体验。本文首先论述下如何评判一个小程序页面的性能情况，之后通过具体的案例重点讲解下几点实践技巧，最后再讲讲key值在渲染一个列表时发挥了一个怎么样的作用，以此来论述为啥key值对性能提升有帮助。
评判小程序页面性能
由于小程序开发环境的特殊性，我们不能像普通网页那样通过chrome开发工具或者一些成熟的性能测试工具（例如Lighthouse）来了解一个页面的性能，但微信官方提供了一个性能评分的工具，点击这里可以查看工具详情。
体验评分是一项给小程序的体验好坏打分的功能，它会在小程序运行过程中实时检查，分析出一些可能导致体验不好的地方，并且定位出哪里有问题，以及给出一些优化建议。
后面我会以一个实际的例子来展示如何通过该工具来优化页面性能，我们先看下我们页面优化前的一个评分情况。
存在setData的数据过大
我们的功能里面有个滚动到底部加载的功能，优化前我们的做法是这样的
我估计大部分人面对长列表滚动的时候，一开始的处理方式都是这样的，如果数据不多，只有几页可能不会太暴露问题，如果页数过多，几十页甚至上百页的情况，list的数据会越来越大，每次setData的数据就会越来越多，因而每次页面重新渲染的节点就会越来越多，从而导致滚动到后面，加载越来越慢。另外，由于小程序的视图渲染层和数据逻辑处理层是分开的，不是在同一个线程上面的，从用户触发页面交互，到处理数据逻辑，最后层现页面，数据到视图是需要传输的，因而小程序本身对数据大小也有限制，不能超过1M。
setData数据路径
怎么解决呢？小程序setData里面的key支持数据路径的写法，比如
所以我们可以通过数据路径的写法，来将数据分批的传输到视图层中，减少一次性setData的数据大小。具体写法如下
存在短时间内发起太多图片请求（图片懒加载）
这个应该好理解，就是渲染页面时，一次性发送了过多的图片请求，导致了同一时间发起了过多的http请求，http连接是非常耗时的，尤其是一次性发起这么多，并且一次性发起的http链接也是有限制的，比如chrome浏 览器就限制一次性最多6个。
所以在渲染页面时，不在视图范围内的图片我们不加载，只有元素出现在视图范围内了，再渲染。
常规的做法是，通过getBoundingClientRect()获取元素的位置，然后与页面滚动位置比较，如果出现在视图内，就将img显示。这种方式有2个问题
getBoundingClientRect()方法调用本身容易引起页面重排
监听滚动事件本身就频繁触发，虽然可以通过节流的方式来减少，但还是容易增加无谓代码处理
IntersectionObserver
其实，微信提供了IntersectionObserver对象。
IntersectionObserver 对象，用于推断某些节点是否可以被用户看见、有多大比例可以被用户看见
通过这个api我们不用再主动去监听元素位置了，在页面渲染一开始，通过这个api指明需要监听的元素，系统会自动去监听了元素位置。
intersectionRatio值大于0，说明元素出现在视图中了，重新setData数据，显示图片组件。
存在图片太大而显示区域过小
这个问题就是指图片尺寸太大了，而页面上我们显示的尺寸又太小了，图片尺寸大，请求图片就越慢，导致页面渲染速度下降。
CDN图片处理
对于页面里面的图片，最好都把图片存储在cdn服务器上，一个是能充分利用cdn缓存来加快请求速度，另外一个就是cdn上能够将图片进行一定的处理，比如裁剪。我司就是通过cdn来响应图片处理，然后请求图片时告诉cdn服务器需要什么要的尺寸图片，由cdn服务器响应对应尺寸图片。
key值在列表渲染中的作用
key值在列表渲染的时候，能够提升列表渲染性能，为什么呢？首先得想想小程序的页面是如何渲染的，主要分为以下几步：
1.将wxml结构的文档构建成一个vdom虚拟数
2.页面有新的交互，产生新的vdom数，然后与旧数进行比较，看哪里有变化了，做对应的修改（删除、移动、更新值）等操作
3.最后再将vdom渲染成真实的页面结构
key值的作用就在第二步，当数据改变触发渲染层重新渲染的时候，会校正带有 key 的组件，框架会确保他们被重新排序，而不是重新创建，以确保使组件保持自身的状态，并且提高列表渲染时的效率。
key值如果不指明，默认会按数组的索引来处理，因而会导致一些类似input等输入框组件的值出现混乱的问题。
相关测试代码可以查看：
wxkey:https://developers.weixin.qq.com/s/ZqKQ6hmM727z
可以看到
不加key,在数组末尾追加元素，之前已渲染的元素不会重新渲染。但如果是在头部或者中间插入元素，整个list被删除重新渲染，且input组件的值还出现了混乱，值没有正常被更新
添加key，在数组末尾、中间、或者头部插入元素，其它已存在的元素都不会被重新渲染，值也能正常被更新
因而，在做list渲染时，如果list的顺序发生变化时，最好增加key，且不要简单的使用数组索引当做key。
最后看看我们的成果：
