2020-03-03 09:20:13
优化要点
首屏时间：指用户打开页面到看到第一屏主要内容的时间 渲染时间：指数据首次渲染或引起页面结构变化的渲染所花费的时间 请求耗时：请求耗时越长，用户等待的时间越长 CPU 利用率：CPU 利用率达到饱和时容易导致页面白屏或闪退 网络请求数：短时间发起太多请求会触发小程序并行请求的数量限制
分析工具
1、Performance monitor 它是小程序开发工具内置的一个可视化监控工具，能够在 OS 级别上实时记录系统资源的使用情况。
借助这个工具，可以监控 cpu 和内存占用量和波动情况，快速定位引起页面卡顿、机器发烫的模块，进而进行优化
2、测试机
小程序性能分析工具较少，且开发工具的运行效果和真机差异较大，应尽量使用真机定位性能问题。
通常，他们使用 oppo r11 和 iphone 6s plus 等低档机排查性能问题，再分别挑选用户数占比较大的低、中、高档机器检验优化效果
- 监控系统
前端进行测速数据采集和上报，再通过监控系统分析页面的各项指标健康度，了解页面加载耗时情况，对性能优化有较大的参考价值。
实践 - 性能优化历程
一、自动分页渲染
背景： 早期，为缩短白屏时间，购物车使用了分屏渲染技术，把数据分为首屏和非首屏两部分，首屏渲染完成后再渲染非首屏数据。
分屏渲染最大问题在于，一旦非首屏数据量过大，渲染耗时会很长，让用户等待很长时间，最糟的情况可能引起页面假死，严重影响用户体验。
随着业务增长，这个问题带来的影响已经越来越明显，因此我们开始考虑改用分页技术
1、技术选型
难点：
业务复杂。短期内无法实现分页请求数据，只能实现纯前端分页 数据量大。每个商品不仅包含主品的各项信息，还可能附加与商品结构类似的赠品、换购商品等 商品列表顺序动态改变。例如修改商品促销，该商品可能由列表第一项变成最后一项，操作完成后还要定位到该商品
触底加载： 优点：每次只加载一页，需要时才加载下一页 缺点：不适合数据结构复杂的场景；不适合列表项顺序经常改变的场景。
分屏渲染： 优点：通过首屏渲染数据量的减少，提高首屏渲染的速度，首屏渲染完后紧接着渲染非首屏数据 缺点：当非首屏数据特别大的时候，可能会造成页面的假死
自动分页加载：通过raf实现自动分页加载
2、基本思想
- 一次性请求全部数据
- 将数据分成若干页，每次只渲染一页
- 上一页渲染完成后，自动循环渲染下一页
3、循环渲染实现方案对比
- 通过 setData 递归。setData 的回调函数触发时立刻渲染下一页。缺点是会导致 UI 线程一直忙碌，用户操作响应变慢。
- 利用 setTimeout。setData 回调函数触发时，用 setTimeout 延迟一段时间再渲染下一页。缺点是执行时间不可控。
- 利用时间分片。通过 requestAnimationFrame（简称 raf）实现。调用 raf 之后，浏览器在准备渲染下一帧前会调用你传给 raf 的回调函数。按照帧率为 60fps 来计算，每一帧的间隔在 16.6ms 左右。
4、示例
Demo: developers.weixin.qq.com/s/XJEDb3mP7…
原理: 用 raf 代替定时器，每次 setData 完成后，延迟 16.6ms 左右，再渲染下一页
实现思路：每次 setData 时触发 wxs 事件监听器，在 wxs 事件处理函数中调用 raf，raf 回调执行时调用逻辑层函数渲染下一页 实现后左右联动的滚动怎么处理？ raf流程图 第一步：AppService - setData触发WxsPropObserve 第二步：webView - 触发wxs函数进行初始化 第三步：webView - 执行wsx事件处理函数，调用requestAnimationFrame 第四步：webView - requestAnimationFrame回调执行 第五步：AppService - setData下一页数据
