小程序优化

前言：

小程序已上线一段时间，评测结果性能良好，这个成绩相对来说还是不错，但是良好不是我们的目标，优秀才是。

 

依据提示，点击查看性能体检报告，列出了几点待改善的意见，但是没有具体细则。开发工具-调试器-Audis面板可进行详细跳转有优化

1、开发者工具进行评测

评测步骤：

微信开发者工具­——》调试器——》Audits——》运行（操作）——》结束

点击运行以后，尽可能多的对小程序进行操作，最好覆盖全页面和所有的交互动作。操作完成以后，点击结束，出行评测结果以及评测的具体列表，需要优化的地方。

 

 

2、性能优化

2.1存在将未绑定在 WXML 的变量传入 setData

详解：setData 是小程序开发中使用最频繁的接口，setData操作会引起框架处理一些渲染页面的相关工作，一个未在页面结构绑定的变量意味着与界面渲染无关，传入不必要的setData会造成不必要的性能消耗。

常见的setData错误操作：

1. 频繁的去setData，（页面不停的渲染，导致卡顿）

2. setData 都传递大量新数据。(渲染压力太大，会出现延迟，页面不显示的数据不要传递)

3. 所有的变量都定义在data属性，进行setData操作，进行数据渲染（不需要渲染页面的数据要定义在外面，定义成变量）

Demo解决实例：

如上图，contentWidth肯定不是被绑定的数据，在给出的页面路径里，找到这个变量，把他从data属性里面移出去，放在外面，定义成一个全局变量。

2.2 存在网络图片资源未开启 HTTP 缓存控制

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

解决方案：片请求里，服务器没有返回cache-control头部。一般对于资源请求建议加上缓存头部，这样下次访问相同的资源就不用重新向服务发起请求。

2.3 存在可能没有对请求进行缓存的情况

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

解决方案：对相同的请求进行缓存，但是如果遇到需要实时获取动态数据的，就没有办法了

2.4  存在图片太大而有效显示区域较小

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

解决方案：例如，前端展示图片大小为100*100，那么后台维护图片大小最好也是100*100，如果后台图片1000*1000，势必增加下载时间和内存的消耗。

3、体验优化

3.1存在可点击元素的响应区域过小

详解：我们应该合理地设置好可点击元素的响应区域大小，如果过小会导致用户很难点中，体验很差，在前期设计的时候，应该尽量避免点击元素相应区域过小的问题。来提高用户体验。

3.2页面设计

详解：文字颜色与背景色需要搭配得当，适宜的颜色对比度可以让用户更好地阅读，提升小程序的用户体验。设计尽量符合小程序的设计原则。

小程序设计规范：

https://developers.weixin.qq.com/miniprogram/design/#%E9%87%8D%E7%82%B9%E7%AA%81%E5%87%BA最佳实践优化

4、最佳实践

4.1存在定时器未跟随页面回收

详解：时器是全局的，并不是跟页面绑定的，当小程序从一个页面路由到另一个页面之后，前一个页面定时器应注意手动回收。

解决：离开页面的时候，释放定时器。

4.2 wxss 覆盖率较低，存在未使用的样式 

详解：们应该按需引入 wxss 资源，如果小程序中存在大量未使用的样式，会增加小程序包体积大小，从而在一定程度上影响加载速度

解决：随着业务的调整和优化，会有冗余代码和样式文件，应该及时的删除。

 

最后总结，上面的这些问题，是没有经过小程序评审通过。评审的过程还会涉及到其他很多问题，以此类推，遇到问题解决，如果解决不了，去社区搜索提问。问题总会得到解决。