历史回顾:
本文主要是根据微信小程序官方优化建议和《2018微信公开课第七季上海站·小程序专场》的性能优化方案,针对性我们的小程序项目进行性能优化实践,将过程记录下来,方便以后查看,同时也希望能帮助到其他小伙伴,做好性能优化。毕竟一切性能优化都是为了更好的用户体验。
加绿色小旗子的优化方案是实践过的
小程序常见性能问题
- 这个小程序为什么这么慢?
- 这个小程序为什么滑不动了,卡住了?
- 小程序在切页面的时候为什么会有延迟?
- 为什么点击了没有反应,是不是挂掉啦?
这些问题的场景都反映了小程序的性能问题,直接影响到用户体验。
小程序如何进行性能优化?
官方建议从这两方面进行优化:
- 启动性能优化
- 渲染性能优化
启动性能优化
小程序在整个启动流程中,一般需要完成几项工作:
- 1.准备运行环境(微信自己处理的)
- 2.下载,注入并执行对应小程序代码包
- 3.渲染小程序首页
开发者可以在第2,3去优化小程序的启动性能。
1.代码包大小优化
小程序在首次打开时,会去下载并执行代码包,随着代码包大小的上升,耗时也会相应增加。可以采取以下方案:
分包
使用分包
对开发者而言,能使小程序有更小的代码体积,承载更多的功能与服务;而对用户而言,可以更快地打开小程序,同时在不影响启动速度前提下使用更多功能。
建议开发者按照功能的划分,拆分成几个分包,当需要用到某个功能时,才加载这个功能对应的分包。
实践
我们的一个小程序在两年多前开始开发的,在设计之初,我们没有考虑到这一点,当时也没有小程序分包的功能。好吧,我们还是迎来了这个问题。
微信小程序在开发文档中明确指出,小程序的所有包大小必须限制在2M以内,超过大小,就算在开发者工具中都不能正常预览,更不能上传发版。解决问题的方法:
将静态资源图片压缩,因为小程序的压缩算法对图片的压缩微乎其微,于是乎,笔者对图片进行一轮压缩,并且将重复使用的图片,进行了公共提取,虽然官方推荐使用网络图片,但是还需要去维护静态资源,嫌麻烦,就放弃了。
将项目中的弃用的页面,以及不用的三方,进行了一波清除。
很多项目现在都是通过webpack打包成不同的分包,资源懒加载的形式来优化,小程序也提供了这个功能:分包,笔者按照按照功能划分的原则,将同一个功能下的页面和逻辑放置于同一个目录下,成为一个分包。
分包之后:
注意:1. 自定义第三方组件,需要放在主包内,miniprogram_npm文件会直接打到主包里;2. 小程序的tab切换页,必须放在主包里。
分包预下载
分包预下载是为了解决首次进入分包页面时的延迟问题而设计的。如果能够在用户进入分包页面之前就预先将分包下载完毕,那么进入分包页面的延迟就能够尽可能降低。
实践
用户进行了某个操作,再去下载分包,延迟操作导致用户体验很差,于是乎笔者对上面的分包设置分包预下载。在 app.json
文件中配置:
"preloadRule": {
"pages/work/index": {
"network": "all",
"packages": [
"package-work",
"package-field-statistics"
]
},
"pages/appeal/index": {
"network": "all",
"packages": [
"package-appeal"
]
}
},
复制代码
这里建议不要一次性把所有分包预下载,这样的操作同样回带来性能问题。
独立分包
小程序中的某些场景(如广告页、活动页、支付页等),通常功能不是很复杂且相对独立,对启动性能有很高的要求。使用独立分包,可以独立于主包和其他分包运行。从独立分包中页面进入小程序时,不需要下载主包。
建议开发者将部分对启动性能要求很高的页面放到特殊的独立分包中。
实践
项目中没有适合的场景,尚未实践。
2.首屏渲染优化
1. 提前首屏数据请求
大部分小程序在渲染首页时,需要依赖服务端的接口数据,接口请求放到页面的生命周期 onLoad
中,而不是 onReady
里。
实践
监听到页面加载,就校验登录情况,请求页面数据
onLoad: function (options) {
app.checkAuth((error, token) => {
if (error) {
return
}
// 请求该页面的数据
})
},
复制代码
2. 缓存请求数据
小程序提供了wx.setStorageSync等异步读写本地缓存的能力,数据存储在本地,返回的会比网络请求快。
实践
登录成功后将用户的token,以及用户信息都可以缓存到本地,记得退出登录的时候清楚缓存,