阅读(2304)
赞(8)
百度智能小程序 体验评分
2020-08-12 18:03:30 更新
评分标准
体验评分从三个方面来评估智能小程序，分别是性能、体验、最佳实践。每个分类下的权重见下面的表格。
性能
| 评分规则 | 说明 | 标准 | 权重 |
|---|---|---|---|
| 渲染界面时间 | 渲染界面时间指的是首次渲染 (initData) 或因数据变化 (setData) 带来的页面结构变化的渲染花费的时间。渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大（例如列表过长），或渲染依赖的计算是否过于复杂。 | 单次渲染时间不超过 500 ms | 7 |
| 脚本执行时间 | 脚本执行时间是指 JS 脚本在一次同步执行中消耗的时间，比如生命周期回调、事件处理函数的同步执行时间。执行脚本的耗时过长让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑。 | 一个执行周期内脚本运行时间不超过 1 秒 | 6 |
| setData 调用频率 | setData 接口的调用涉及逻辑层与渲染层间的线程通信，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用 | 每秒调用 setData 的次数不超过 20 次 | 7 |
| setData 数据大小 | 由于小程序运行逻辑线程与渲染线程之上，setData 的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间。 | setData 的数据在 JSON.stringify 后不超过 256 KB | 6 |
| 避免 setData 数据冗余 | setData 操作会引起框架处理一些渲染界面相关的工作，一个未绑定的变量意味着与界面渲染无关，传入 setData 会造成不必要的性能消耗。 | setData 传入的所有数据都在模板渲染中有相关依赖 | 3 |
| SWAN 节点数 | 建议一个页面使用少于 1000 个 SWAN 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 SWAN 节点树会增加内存的使用，样式重排时间也会更长 | 页面 SWAN 节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个 | 5 |
| 请求耗时 | 请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应。 | 所有网络请求都在 1 秒内返回结果 | 7 |
| 网络请求频率 | 短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等。 | 每秒通过 swan.request 发起的请求数不超过 10 个 | 4 |
| 图片请求频率 | 短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处于等待状态。应该合理控制数量，可考虑使用雪碧图技术或在屏幕外的图片使用懒加载。 | 每秒发起的图片请求数不超过 20 个 | 4 |
| 网络请求缓存 | 发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存 | 3 分钟以内同一个 url 请求不出现两次回包大于 128KB 且一模一样的内容 | 1 |
| 图片缓存 | 开启 HTTP 缓存控制后，下一次加载同样的图片，会直接从缓存读取，大大提升加载速度。 | 所有图片均开启 HTTP 缓存 | 4 |
| 图片大小 | 图片太大会增加内存的消耗，应根据显示区域大小合理控制图片大小。 | 图片宽高都不超过实际显示宽高的 3 倍 | 4 |
| 文件数量 | 小程序的解压过程包含了文件 Hash 值的对比，文件数量过多会影响到解压速率。 | 文件数量少于 200 个 | 8 |
| 图片压缩 | 小程序包内的图片压缩可以减少包体积，对于网络图片，压缩也可以提高图片的下载速度。 | 小程序包内图片无损压缩后体积减少 10% 以内 | 1 |
体验
| 评分规则 | 说明 | 标准 | 权重 |
|---|---|---|---|
| 避免使用 :active 伪类来实现点击态 | 使用 css :active 伪类来实现点击态，很容易触发，并且滚动或滑动时点击态不会消失，体验较差。
建议使用小程序内置组件的 hover-* 属性来实现。 |
不使用 :active 伪类，使用 hover-class 替换 :active | 8 |
| 保持图片大小比例 | 图片若没有按原图宽高比例显示，可能导致图片歪曲，不美观，甚至导致用户识别困难。
可根据情况设置 image 组件的 mode 属性，以保持原图宽高比。 |
显示的高/宽与原图的高/宽不超过 10% | 4 |
| 可点击元素的响应区域 | 我们应该合理地设置好可点击元素的响应区域大小，如果过小会导致用户很难点中，体验很差。 | 可点击元素的宽高都不小于 20px | 7 |
| 合理的颜色搭配 | 文字颜色与背景色需要搭配得当，适宜的颜色对比度可以让用户更好地阅读，提升小程序的用户体验。 | · 较大字体(font-size >= 24px，或同时满足 font-size >= 19px 与 font-weight >= 700）：文字颜色和背景颜色的对比度不小于 1.2；
· 其他字体：文字颜色和背景颜色的对比度不小于 1.25。 |
0 |
最佳实践
| 评分规则 | 说明 | 标准 | 权重 |
|---|---|---|---|
| 避免 JS 异常 | 出现 JavaScript 异常可能导致程序的交互无法进行下去，我们应当追求零异常，保证程序的高鲁棒性和高可用性。 | 不出现任何 JS 异常。 | 3 |
| 避免网络请求异常 | 请求失败可能导致程序的交互无法进行下去，应当保证所有请求都能成功。 | 所有网络请求都正常返回 | 3 |
| 使用 HTTPS | 使用 HTTPS，可以让你的小程序更加安全，而 HTTP 存在数据泄露和被篡改内容的风险。 | 所有网络请求都使用 HTTPS | 1 |
| 移除不可访问到的 template | 小程序的包大小会影响加载时间，应该尽量控制包体积大小，避免将不会被使用的文件打包进去。 | 不存在访问不到的 template 被打包到小程序中。 | 0 |
| CSS 使用率 | 我们应该按需引入 CSS 资源，如果小程序中存在大量未使用的样式，会增加小程序包体积大小，从而在一定程度上影响加载速度。 | 每个 CSSS 资源的未使用部分不超过 2KB | 0 |
| 及时回收定时器 | 定时器是全局的，并不是跟页面绑定的，当页面因后退被销毁时，定时器应注意手动回收。 | 所有定时器的回调执行时所在的页面都与设置定时器的页面一致。 | 0 |