为了账号安全,请及时绑定邮箱和手机立即绑定

小程序首屏加载过慢的性能优化策略

2021.01.13 11:51 368浏览

一. 问题描述

01. 问题现象
小程序初次打开首屏加载很慢,已经超出用户等待时长。

02. 理想加载
理想状态加载不超过5s,数据渲染不出现卡顿现象。

二. 加载机制

首屏的加载速度除了和网络有关系,和小程序自身启动机制也有关系,首先要了解小程序的启动机制,小程序的启动分为冷启动和热启动。

01. 冷启动

简介:如果用户首次打开,或小程序销毁后被用户再次打开,此时小程序需要重新加载启动,即冷启动。

触发场景:

新用户第一个进入小程序

用户已经进入过小程序,但是小程序被销毁,销毁的原因有,小程序被删除,小程序在后台等待时间过长,自动销毁了。

02. 热启动
简介:如果用户已经打开过某小程序,然后在一定时间内再次打开该小程序,此时小程序并未被销毁,只是从后台状态进入前台状态,这个过程就是热启动。

触发场景:

用户打开了小程序,在小程序没有被销毁时再次打开小程序,此时小程序还能保存用户上一次的操作状态。

首屏加载慢大部分原因是冷启动时加载的数据过多,需要依赖过多的服务端的接口数据等。

三. 检查

对于程序员来说,遇到问题应该解决问题。首先要要几个基础检查:

01. 检查图片

检查图片包括:
1. 图片是否过大
检查图片属性,如果图片加载过大,就利用工具压缩图片。此时要考虑如果图片像素要求很高,压缩要注意不能失真,其次压缩要注意等比例,留意是否不小心剪裁了图片大小等。
2. 图片懒加载
如果首页要加载的有很多列表或者图片展示,此时要注意图片加载时长,如果超过一定时间,懒加载是个不错的办法。
3. 图片是否可以用cdn托管
对于icon小图标可以放在小程序项目image文件夹里,但是如果图片占用资源,放在cdn托管既可以缩小代码包的大小还可以提升加载效率。

02. 检查首屏接口耗时

一个接口一个接口的排查,在network中查看加载的时间,逐个排查原因,所有请求最好在1s内返回结果。

03. 检查有无错误日志

在JS中如果在同步任务中,一个错误的发生会造成后面整段代码都不执行。
此时应该排查下是否有异常错误,避免出现首屏一直处于加载的状态。必要的时候try catch处理。

04. 检查界面是否使用定时器
定时器一般设置为全局变量,或者定时器和倒计时相关功能绑定,用定时器一定要记得及时回收。

05. 检查基础版本库

如果首页使用里自定义组建,不同颁布要注意基础库要一致。可能不同基础库有些功能的支持条件不一致,要做兼容处理。

四. 优化策略

01. 分包加载
开发者通过在 app.json subpackages 字段声明项目分包结构

{
  "pages":[
    "pages/index",
    "pages/logs"
  ],
  "subpackages": [
    {
      "root": "packageA",
      "pages": [
        "pages/cat",
        "pages/dog"
      ]
    }, {
      "root": "packageB",
      "name": "pack2",
      "pages": [
        "pages/apple",
        "pages/banana"
      ]
    }
  ]
}

分包之后优先加载主tab,二级界面可以理解为按需加载。
分包要注意,主包不能使用二级界面的样式或者js等,因为主包在加载时分包是不加载的。

02. 利用缓存
当小程序被销毁需要重新渲染界面时,此时冷启动会再次请求接口加载数据,可以利用小程序提供了缓存方法wx.setStorage、wx.getStorage将数据存储在本地。

03. 不使用空白屏
所谓空白屏就是当请求接口的数据没有被返回时,整个界面被hidden的,此时给用户的感觉就是白屏。
推荐做法:当数据没有被渲染时展示页面的基本骨架,利用toast提示加载进度,给用户反馈出加载的进度,会延长用户的等待时间。把优先级高的内容做优先展示,缩短白屏时间;

04. 首页架构调整
调整页面展示顺序等,尽量让首屏简洁化。数据展示的尽量精简化。

05. 渲染优化
避免首页多次setData,未绑定的变量或者和界面无关的变量都不要在setData中体现,这样的情况大多出现在一个变量可能在初版的时候使用,下一个版本更改需求,有些变量不需要渲染界面里,但是程序员并有及时删除。

06. 代码优化
第一:在样式上,检查wxss的使用率,这个很重要又经常被忽视,经常发生在不同版本迭代中,需求和样式是经常被改动的,下一个版本更改没有及时删除掉不用的样式,可能有些程序员心里是想着有可能下次被用到,但是记得项目是有git托管的,可以借助git查找之前的代码记录,所以不是此版本的css大胆的删除吧。
第二:在js上,一个js可能到上千行了,这个原因可能和业务逻辑有关,也可能是你写了太多的函数,没有用函数的封装处理。调用接口,没有用Promise封装或者其他封装办法。

点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消