微信小程序分页setData数据太大限制问题
合理使用 setData
setData 是小程序开发中使用最频繁、也是最容易引发性能问题的接口。
1. setData 的流程
setData 的过程，大致可以分成几个阶段：
- 逻辑层虚拟 DOM 树的遍历和更新，触发组件生命周期和 observer 等；
- 将 data 从逻辑层传输到视图层；
- 视图层虚拟 DOM 树的更新、真实 DOM 元素的更新并触发页面渲染更新。
2. 数据通信
对于第 2 步，由于小程序的逻辑层和视图层是两个独立的运行环境、分属不同的线程或进程，不能直接进行数据共享，需要进行数据的序列化、跨线程/进程的数据传输、数据的反序列化，因此数据传输过程是异步的、非实时的。
iOS/iPadOS/MacOS 上，数据传输是通过
evaluateJavascript实现的，还会有额外 JS 脚本解析和执行的耗时。
数据传输的耗时与数据量的大小正相关，如果对端线程处于繁忙状态，数据会在消息队列中等待。
3. 使用建议
3.1 data 应只包括渲染相关的数据
setData 应只用来进行渲染相关的数据更新。用 setData 的方式更新渲染无关的字段，会触发额外的渲染流程，或者增加传输的数据量，影响渲染耗时。
- ✅ 页面或组件的 data 字段，应用来存放和页面或组件渲染相关的数据（即直接在 wxml 中出现的字段）；
- ✅ 页面或组件渲染间接相关的数据可以设置为「纯数据字段」，可以使用 setData 设置并使用 observers 监听变化；
- ✅ 页面或组件渲染无关的数据，应挂在非 data 的字段下，如
this.userData = {userId: 'xxx'}； - ❌ 避免在 data 中包含渲染无关的业务数据；
- ❌ 避免使用 data 在页面或组件方法间进行数据共享；
- ❌ 避免滥用 纯数据字段 来保存可以使用非 data 字段保存的数据。
3.2 控制 setData 的频率
每次 setData 都会触发逻辑层虚拟 DOM 树的遍历和更新，也可能会导致触发一次完整的页面渲染流程。过于频繁（毫秒级）的调用 setData，会导致以下后果：
- 逻辑层 JS 线程持续繁忙，无法正常响应用户操作的事件，也无法正常完成页面切换；
- 视图层 JS 线程持续处于忙碌状态，逻辑层 -> 视图层通信耗时上升，视图层收到消息的延时较高，渲染出现明显延迟；
- 视图层无法及时响应用户操作，用户滑动页面时感到明显卡顿，操作反馈延迟，用户操作事件无法及时传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层。
因此，开发者在调用 setData 时要注意：
- ✅ 仅在需要进行页面内容更新时调用 setData；
- ✅ 对连续的 setData 调用尽可能的进行合并；
- ❌ 避免不必要的 setData；
- ❌ 避免以过高的频率持续调用 setData，例如毫秒级的倒计时；
- ❌ 避免在 onPageScroll 回调中每次都调用 setData。
3.3 选择合适的 setData 范围
组件的 setData 只会引起当前组件和子组件的更新，可以降低虚拟 DOM 更新时的计算开销。
- ✅ 对于需要频繁更新的页面元素（例如：秒杀倒计时），可以封装为独立的组件，在组件内进行 setData 操作。必要时可以使用 CSS contain 属性限制计算布局、样式和绘制等的范围。
官方文档传送门 this.setData单次设置数据不能超过1024kb
1. 常规的分页做法:
这里可以看到，每次获取新的一页，都要重新setData新的数组，仔细想想，当这个数组到后面越来越大的时候，很容易就超出了单次设置数据超过1024kb的限制了
2. 二维数组, 优化做法:
参考链接: https://zhuanlan.zhihu.com/p/181485977
https://juejin.cn/post/6844903693544849415
