timg (3).jpeg

将近一个月没有更新博文,是因为最近一个月在不停的更新折腾小程序,看看这个玩意到底能搞什么飞机。

某天boss看到一个文章说小程序启动超过1.6秒会有流失,彻夜未眠。早上截图给我们催促我们踏上了优化之路。

我们的小程序打开逻辑

正常打开

  • 直接打开 -> index页面 -> home首页

分享tab页打开

  • 不同的分享地址(比如设置) -> index页面 -> switch tab 到设置页面

分享其他tab页的内容页打开

  • 不同的分享地址(比如设置) -> index页面 -> switch tab 到设置页面 -> 跳转进内容页

这样做的目的就是分享进去哪个页面,使用之后返回也可以按原来的逻辑和操作去继续处理。

启动页index页面的效果优化

小程序的第一个页面index/index页面,基本上就拿来当启动页。但是如果在跳转到其他页面之前,网络还没有回调完,那么这个页面就会出现卡在白屏的问题,所以做一张漂亮的启动页会好很多。

最早之前为了拿取到登录信息,所以是在index页面做登录login操作,到网络成功回调之后再跳转到了其他页面。

为什么不先跳转,然后在首页去登录?

这个是因为小程序可以有很多分享页面,而分享出去跳转进来的并不只是像app一样跳转进来,而是会跳转到对应的页面,比如直接跳转到个人详情,所以是多入口的,严格意义上来说index页面既是启动页,也是首页和分发页。

这样就会产生如果请求信息太慢,网速太慢,那么就会一直卡顿在首页的问题。所以比较好的解决方案就是请求登录的同时去跳转。

如果跳转的页面请求信息需要登录信息怎么办?那就是后面说的网络优化

网络请求优化

断线重连和重试次数

网络请求的优化,首先就是失败重试和限制重试次数,这个也是APP开发中很常见的。小程序最多并发10个http连接和2个websocket连接,并且如果一直重试的话会出现手机发烫的问题。

所以我现在设置的500毫秒重试一次,重试60次,相当于30s,如果依旧不行,那就弹网络错误的报错信息就可以了。

身份登录信息重试

前面说到的跳转和登录请求同时发送,那如果登录请求过慢,先跳转到页面,而这个页面的请求需要使用登录请求怎么办?那就是网络处理的问题了,现在我采用的是服务端约定登录信息报错的code,出现这个code的话就去重新登录并且记录当前的请求,登录成功之后再继续请求即可。

图片优化

图片除了使用必要的cdn存储外,最好不要返回大大的原图,可以返回较小清晰度可以接受的小图即可,同时小程序已经对图片做了缓存,目前网页图片的缓存用的是webview的缓存策略,所以cdn如果每次返回的图片都有时间戳的话,这个自带的缓存就用不上了,所以最好去掉时间戳,直接缓存即可。

合并接口

如果接口的请求是串行的,可以考虑合并接口,当然不是合并所有的串行接口,因为数据量太大也会出现问题,所以根据情况考虑某些页面的接口,这样大概又可以省下一秒多。

当然还有官方说的不要频繁的setData,合并setData等代码级别的操作,这些可以考虑下,但是感觉提升不大,最大的时间消耗其实还是网络请求。

先写这么多,最近也在完善懒猪计划和懒猪清单的iCloud同步部分,等后续稳定再分享一下。


☟☟可点击下方广告支持一下☟☟

最后修改:2023 年 08 月 02 日
请我喝杯可乐,请随意打赏: ☞已打赏列表