借负责的小程序流量暴增事件总结下优化技巧
之前负责的锡慧在线微信小程序是一款公益性质在线教育类小程序 , 因疫情影响导致流量暴增 , 日访问过百万
![日访问次数百万级微信小程序优化技巧总结](http://img.jiangsulong.com/220411/0F45W062-0.jpg)
文章插图
高峰期每分钟1w+在线访问
![日访问次数百万级微信小程序优化技巧总结](http://img.jiangsulong.com/220411/0F45S317-1.jpg)
文章插图
视频播放卡顿严重 , 使用体验很差 。
博主已是离职状态 , 但是公司内并没有找到可以接手的同学 , 小程序前端是我从零一手做出来的 , 有点特殊情感 , 于是就以小程序顾问的身份帮忙处理了小程序端的工作 。
应对本次问题 , 视频卡顿是选择把视频课件资源从文件服务器上迁移至腾讯云存储 , 现已经修复发版完毕
![日访问次数百万级微信小程序优化技巧总结](http://img.jiangsulong.com/220411/0F45R631-2.jpg)
文章插图
【日访问次数百万级微信小程序优化技巧总结】在此总结下小程序优化相关知识 。
小程序端优化
提高加载性能
小程序呈现到用户面前 , 实际上经历了下面两个阶段:
- 运行环境的预加载
- 微信会在用户打开小程序之前就已经准备好环境 , 用户点击小程序入口后 , 直接下载小程序的代码包即可
- 下载代码包启动小程序
- 小程序代码包里面的代码 , 不是小程序的源代码 , 而是编译、压缩、打包之后的代码包
![日访问次数百万级微信小程序优化技巧总结](http://img.jiangsulong.com/220411/0F45WE0-3.jpg)
文章插图
小程序提供的运行环境 , 分为逻辑层(AppService)和 视图层(webView) , 逻辑层是执行JAVAscript的地方 , 视图层是渲染页面的地方 。当小程序的代码包下载完毕后 , 业务代码分别注入逻辑层和渲染层 。
优化关键点
控制小程序包的大小
- 代码级优化
- 压缩代码
- 清理无用的代码(含注释掉的代码、log等)
- 业务级优化 , 逻辑复用 , 组件复用
- 图片优化
- 放CDN
- 选用其它静态存储服务器
- 最其次使用优化过大小后的本地图片
- 采用分包策略
- 分包预加载
- 独立分包
- onLoad阶段就可发起请求
- 实时性要求不高的或者非频繁变动的业务数据尽量不要在onShow时请求
- 请求结果放在缓存中、利用时间戳控制有效期 , 减少更新次数
- 核心页面在请求过程中添加骨架屏展示处理
- 细节体验处理 , 及时给予用户反馈
- 如点击按钮后先改变样式(切换启停用状态) , 再发出请求 , 防止用户多次请求
setData操作优化
- 减少setData的数据量
- 不影响渲染层的数据不用放在setData
- 合并精简setData
- 避免列表数据全局刷新、局部更新单条数据
list[index] = newList[index]
})
定时器及时销毁
- 小程序多个页面会多开webview , 独立线程运行 , 当离开页面存在定时器时需要及时销毁
- 只在必要时监听pageScroll
- onPageScroll中避免执行复杂逻辑 , 频繁setData , 查询节点信息
自定义组件更新只在组件内部进行 , 不受页面其他内容影响
- 运营活动的定时模块可以单独抽出来 , 做成一个定时组件 , 定时组件的更新并不会影响页面上其他元素的更新;
- 各个组件具有各自独立的逻辑空间 , 分别拥有自己的独立的数据、setData调用
- 分层绘制到不同canvas
- 不变的部分单独绘制到一个canvas
- 动态生成的绘制到一个canvs
- 前端数据过滤及验证 , 不规范的数据不必发送请求增加服务端压力
服务端优化
硬件升级
- 服务器负载均衡
- 云数据库多台主从读写分离
- redis缓存
- 小程序静态资源使用CDN和OSS文件存储