-
存在图片太大而有效显示区域较小
图片太大会增加下载时间和内存的消耗,应根据显示区域大小合理控制图片大小
-
存在请求的响应状态码出现异常
请求失败可能导致小程序的交互无法进行下去,应当保证所有请求都能成功
-
存在可点击元素的响应区域过小
我们应该合理地设置好可点击元素的响应区域大小,如果过小会导致用户很难点中,体验很差
-
存在定时器未跟随页面回收
定时器是全局的,并不是跟页面绑定的,当页面因后退被销毁时,定时器应注意手动回收
-
所有资源请求都建议使用 HTTPS
使用 HTTPS,可以让你的小程序更加安全,而 HTTP 是明文传输的,存在可能被篡改内容的风险
-
存在图片没有按原图宽高比例显示
图片若没有按原图宽高比例显示,可能导致图片歪曲,不美观,甚至导致用户识别困难。可根据情况设置 image 组件的 mode 属性,以保持原图宽高比。 更多学习
-
存在将不可能被访问到的页面打包在小程序包里
小程序的包大小会影响加载时间,应该尽量控制包体积大小,避免将不会被使用的文件打包进去
- 小程序应避免出现任何 JavaScript 异常
出现 JavaScript 异常可能导致小程序的交互无法进行下去,我们应当追求零异常,保证小程序的高鲁棒性和高可用性
- 网络图片资源应开启 HTTP 缓存控制
开启 HTTP 缓存控制后,下一次加载同样的图片,会直接从缓存读取,提升加载速度
- 所有请求的耗时不应太久
请求的耗时太长会让用户一直等待甚至离开,应当优化好服务器处理时间、减小回包大小,让请求快速响应
- 避免短时间内发起太多的图片请求
短时间内发起太多图片请求会触发浏览器并行加载的限制,可能导致图片加载慢,用户一直处理等待。应该合理控制数量,可考虑使用雪碧图技术或在屏幕外的图片使用懒加载 更多学习
- 避免短时间内发起太多的请求
短时间内发起太多请求会触发小程序并行请求数量的限制,同时太多请求也可能导致加载慢等问题,应合理控制请求数量,甚至做请求的合并等
- 避免 setData 的数据过大
由于小程序运行逻辑线程与渲染线程之上,setData的调用会把数据从逻辑层传到渲染层,数据太大会增加通信时间 更多学习
- 避免 setData 的调用过于频繁
setData接口的调用涉及逻辑层与渲染层间的线程通过,通信过于频繁可能导致处理队列阻塞,界面渲染不及时而导致卡顿,应避免无用的频繁调用 更多学习
- 避免将未绑定在 WXML 的变量传入 setData
setData操作会引起框架处理一些渲染界面相关的工作,一个未绑定的变量意味着与界面渲染无关,传入setData会造成不必要的性能消耗 更多学习
- 避免渲染界面的耗时过长的情况
渲染界面的耗时过长会让用户觉得卡顿,体验较差,出现这一情况时,需要校验下是否同时渲染的区域太大
- 避免执行脚本的耗时过长的情况
执行脚本的耗时过长会让用户觉得卡顿,体验较差,出现这一情况时,需要确认并优化脚本的逻辑
- 对网络请求做必要的缓存以避免多余的请求
发起网络请求总会让用户等待,可能造成不好的体验,应尽量避免多余的请求,比如对同样的请求进行缓存
- wxss 覆盖率较高,较少或没有引入未被使用的样式
我们应该按需引入 wxss 资源,如果小程序中存在大量未使用的样式,会增加小程序包体积大小,从而在一定程度上影响加载速度
- 文字颜色与背景色搭配较好,适宜的颜色对比度更方便用户阅读
文字颜色与背景色需要搭配得当,适宜的颜色对比度可以让用户更好地阅读,提升小程序的用户体验 更多学习
- 未发现使用废弃接口
使用即将废弃或已废弃接口,可能导致小程序运行不正常。一般而言,接口不会立即去掉,但保险起见,建议不要使用,避免后续小程序突然运行异常。
- 避免过大的 WXML 节点数目
建议一个页面使用少于 1000 个 WXML 节点,节点树深度少于 30 层,子节点数不大于 60 个。一个太大的 WXML 节点树会增加内存的使用,样式重排时间也会更长。
- 避免首屏时间太长的情况
首屏时间是指用户开始看到第一屏的内容的时间,首屏时间太长会导致用户长时间看到的都是白屏,会一直等待有意义的内容展示出来。出现这一情况,应仔细检查这个过程都有哪个操作,一般来说,可能是请求数据的时间太长,或者是一次渲染的数据太大导致渲染时间太长。
- 避免使用 css ':active' 伪类来实现点击态
使用 css ':active' 伪类来实现点击态,很容易触发,并且滚动或滑动时点击态不会消失,体验较差。建议使用小程序内置组件的 'hover-*' 属性来实现 更多学习
- 滚动区域可开启惯性滚动以增强体验
惯性滚动会使滚动比较顺畅,在安卓下默认有惯性滚动,而在 iOS 下需要额外设置 `-webkit-overflow-scrolling: touch` 的样式