渲染性能优化

一起看海

1. 适当监听页面或组件的 scroll 事件
只要用户在 Page 构造时传入了 onPageScroll 监听，基础库就会认为开发者需要监听页面 scoll 事件。此时，当用户滑动页面时，事件会以很高的频率从视图层发送到逻辑层，存在一定的通信开销。

类似的，对于 <scroll-view>、<page-meta> 等可以通过 bindscroll 监听滑动事件的组件，也会存在这一情况。

正是由于 scroll 事件触发的频率很高，因此开发者很容易误用，在使用时需要注意：

非必要不监听 scroll 事件；
在实现与滚动相关的动画时，优先考虑滚动驱动动画（仅 <scroll-view>）或 WXS 响应事件
不需要监听事件时，Page 构造时应不传入 onPageScroll 函数，而不是留空函数；
避免在 scroll 事件监听函数中执行复杂逻辑；
避免在 scroll 事件监听中频繁调用 setData 或同步 API。
Page({
  onPageScroll () {} // 不要保留空函数
})

Page({
  // 应直接不传入
})
2. 选择高性能的动画实现方式
开发者在开发界面动画时，应该选择高性能的动画实现方式。

优先使用 CSS 渐变、CSS 动画、或小程序框架提供的其他动画实现方式完成动画；
在一些复杂场景下，如果上述方式不能满足，可以使用 WXS 响应事件 动态调整节点的 style 属性做到动画效果。同时，这种方式也可以根据用户的触摸事件来动态地生成动画；
避免通过连续 setData 改变界面的形式来实现动画。虽然实现起来简单灵活，但是极易出现较大的延迟或卡顿，甚至导致小程序僵死；
如果不得不采用 setData 方式，应尽可能将页面的 setData 改为自定义组件中的 setData 来提升性能。
3. 使用 IntersectionObserver 监听元素曝光
部分业务场景会需要监控元素曝光情况，用于进行一些页面状态的变更或上报分析。

建议使用节点布局相交状态监听 IntersectionObserver 推断某些节点是否可见、有多大比例可见；
避免通过监听 onPageScroll 事件，并在回调中通过持续查询节点信息 SelectQuery 来判断元素是否可见。
4. 控制 WXML 节点数量和层级
一个太大的 WXML 节点树会增加内存的使用，样式重排时间也会更长，影响体验。

建议一个页面 WXML 节点数量应少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个。
5. 控制在 Page 构造时传入的自定义数据量
为了便于开发，开发者可以添加任意的函数或数据到 Page 构造传入的 Object 参数中，并在页面的函数内用 this 访问。例如：

Page({
  data: {}
  userInfo: {} // 自定义数据
  currentUser: 'Wechat' // 自定义数据
  onTap() { }
  onLoad() {
    console.log(this.currentUser)
  }
})
为了保证自定义数据在不同的页面实例中也是不同的实例，小程序框架会在页面创建时对这部分数据（函数类型字段除外）做一次深拷贝，如果自定义数据过多或过于复杂，可能带来很大的开销。

对于比较复杂的数据对象，建议在 Page onLoad 或 Component created 时手动赋值到 this 上，而不是通过 Page 构造时的参数传入。
// 使用复杂对象作为自定义数据
Page({
  onLoad() { }
  bigData: { /* A complex object */ },
  longList: [ /* A long complex array*/ ]
})

//  运行时手动赋值到 this。开发者可以根据需要选择进行深拷贝、浅拷贝或不拷贝。
Page({
  onLoad() {
    this.bigData = { /* A complex object */ },
    this.longList = [ /* A long complex array*/ ]
  }
})