微信小程序兼容&性能测试方法

本文为微信小程序兼容、性能测试方法介绍。

兼容
操作系统兼容
由于小程序依赖微信客户端本身，因此理论上来说只要微信客户端兼容的小程序应该都可以兼容，这里推荐覆盖Android和iOS主流版本系统即可，参考如下：

Android操作系统分布
iOS操作系统分布
UI兼容适配
不同屏幕分辨率参考如下，除常规分辨率外，还应关注刘海屏：

Android设备分辨率分布
iOS设备分辨率分布
小程序版本&微信版本兼容
小程序的功能实现依赖小程序基础库，而小程序基础库需要依赖微信客户端本身，因此当我们的小程序使用了某些相对于微信客户端自带的基础库版本较新的API时，就会出现兼容问题。我们在测试时应确保测试覆盖到市场占有率较高的微信版本。
为了避免新版本的基础库给线上小程序带来未知的影响，微信客户端都是携带上一个稳定版的基础库发布的。
在新版本客户端发布后，再通过后台灰度新版本基础库，灰度时长一般为 12 ～ 24 小时，在灰度结束后，用户设备上才会有新版本的基础库。
以微信 6.5.8 为例，客户端在发布时携带的是 1.1.1 基础库（6.5.7 上已全量的稳定版）发布，在 6.5.8 发布后，我们再通过后台灰度 1.2.0 基础库。

基础库版本分布
更新时间：2020 年 6 月 17 日

占比低于 0.01% 的版本已隐藏，灰度发布中的版本也会显示。以下只列出部分库版本进行对比

基础库版本
2.11.2
安卓版本
7.0.13
安卓用户占比
3.08%
iOS版本
7.0.12

性能
小程序前端性能分为启动性能和运行时性能，启动性能关注启动总耗时、首屏时间，运行时性能主要关注页面切换耗时和内存消耗、内存异常。

测试方法
微信小程序官方提供了两种性能分析工具，一个体验评分插件。两个工具分别是性能面板和性能Trace工具，而体验评分插件是微信开发者工具中使用，性能Trace工具只支持Android设备，这里不做介绍。

体验评分工具
使用流程

 1.打开开发者工具，在详情里切换基础库到 2.2.0 或以上版本。
 2.在调试器区域切换到 Audits 面板。
 3.点击”开始“按钮，然后自行操作小程序界面，运行过的页面就会被“体验评分”检测到。


4.点击 “停止" 则结束检测，在当前面板显示相应的检测报告，开发者可根据报告中的建议对相应功能进行优化。
5.如需再次运行体验评分，可点击报告上方的“清空体验评分”恢复初始状态。请注意，目前系统不提供报告存储服务，一旦清空体验评分，将无法再查看本次评分结果。

自动运行
为了方便开发者能够及时发现小程序的体验问题，从开发者工具 1.02.1811150 版本起支持体验评分的 “自动运行” 功能。

该功能会在开发调试小程序时，实时检查，一旦发现体验分数低于 70 分时，系统会在 console 面板打印一个 warning 信息提示开发者，此时开发者可以切到 Audits 面板查看详情。

开发者在工具的右上角 “详情” 面板的 本地设置 中勾选 “自动运行体验评分” 选项即可开启。

体验评分关注性能板块给出的问题列表即可：

体验评分性能指标

1. 首屏时间
   首屏时间是指用户从打开小程序看到第一屏主要内容的时间，首屏时间太长会导致用户长时间看到的都是白屏，影响使用体验。

优化首屏时间，可以分为以下几种情况：

 1. 首屏渲染的内容较多，需要集合多份数据进行渲染。这种情况需要开发者把内容分优先级，把优先级高的内容做优先展示，缩短白屏时间；
 2. 首屏内容依赖的数据从服务端请求的时间太长。开发者需要从服务端侧具体分析服务端数据返回的时间长的原因；
 3. 一次性渲染数据太大或依赖的计算过于复杂。减少渲染的数据量、优化渲染相关数据的算法可以解决这类问题。

得分条件：首屏时间不超过 5 秒

2. 渲染时间
   渲染时间指的是首次渲染或因数据变化带来的页面结构变化的渲染花费的时间。

渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大（例如列表过长），或渲染依赖的计算是否过于复杂。

得分条件：渲染时间不超过 500ms

3. 脚本执行时间
   脚本执行时间是指JS脚本在一次同步执行中消耗的时间，比如生命周期回调、事件处理函数的同步执行时间。

执行脚本的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑

得分条件：一个执行周期内脚本运行时间不超过 1 秒

4. setData调用频率
   setData接口的调用涉及逻辑层与渲染层间的线程通信，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用。

得分条件：每秒调用setData的次数不超过 20 次

5. setData数据大小
   由于小程序运行逻辑线程与渲染线程之上，setData的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间。

得分条件：setData的数据在JSON.stringify后不超过 256KB

6. 避免setData数据冗余
   setData操作会引起框架处理一些渲染界面相关的工作，一个未绑定的变量意味着与界面渲染无关，传入setData会造成不必要的性能消耗。

得分条件：setData传入的所有数据都在模板渲染中有相关依赖

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

得分条件：页面WXML节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个

8. 图片缓存
   开启 HTTP 缓存控制后，下一次加载同样的图片，会直接从缓存读取，大大提升加载速度。

得分条件：所有图片均开启 HTTP 缓存

9. 图片大小
   图片太大会增加下载时间和内存的消耗，应根据显示区域大小合理控制图片大小。

得分条件：图片宽高都不超过实际显示宽高的3倍

10. 请求耗时
    请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应。

得分条件：所有网络请求都在 1 秒内返回结果

11. 网络请求数
    短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等。

得分条件：每秒通过wx.request发起的请求数不超过 10 个

12. 图片请求数
    短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处理等待。应该合理控制数量，可考虑使用雪碧图技术或在屏幕外的图片使用懒加载。

得分条件：每秒发起的图片请求数不超过 20 个

13. 网络请求缓存
    发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存

得分条件：3 分钟以内同一个url请求不出现两次回包大于 128KB 且一模一样的内容

性能面板
打开方法：进入开发版小程序，进入右上角更多按钮，点击「显示性能窗口」

小程序助手
使用[小程序助手]中「性能分析」板块，来持续关注小程序性能。性能分析从 启动性能、运行性能和网络性能三个维度提供性能数据，可根据平台、机型、网络环境和访问来源等条件做精细化分析。扫描下方小程序码即可立即体验。

大家可通过以上各点完成小程序优化及性能评测，参考文章：https://www.jianshu.com/p/209...