性能文章>从零开始搞监控系统(6)——较长的白屏时间>

从零开始搞监控系统(6)——较长的白屏时间原创

1年前
135912

一、加载慢

  在直播间有一个小时榜的Web页面,经常有用户反映点击小时榜,弹出的页面会有蛮长的一段(3秒上下)时间白屏。

  

  查看性能监控中的白屏时间,发现最多1.6秒,最少0.4秒平均每小时的白屏在1秒左右(有待优化),那么大概还有2秒的时间可能是其他原因造成的。

  

  在页面中会包含很多主播头像,有可能是图片太多阻塞了渲染,于是将主播的头像都改成异步加载,在调试的时候直接将他们都隐藏掉,并且在动态读取的部分加入loading效果。

  发到预生产做调试,通过Charles把线上地址映射成预发地址。为了让APP的环境更加纯粹,特地删除了APP重新安装。

  但是在iOS中打开小时榜的时候,还是会有2秒以上非常明显的白屏时间。查询资源瀑布图,也就900ms的样子,离体验到的白屏时间还是差点。

  

  让iOS和安卓给WebView加了个加载进度条,确认白屏的时候到底有没有开始请求资源。

  安卓的情况比iOS好很多,白屏时间并不长,几乎是一闪而过。

  后面让iOS的人查看代码才发现,原来他们是在等到弹出动画结束后开始请求资源,差不多有1秒的动画时间。怪不得每次都要2、3秒的白屏时间。

二、预请求

  经过观察发现每次请求后端数据的API大概要花100~200ms,如果把这段时间省下来,那么也能减少白屏时间,于是想到了数据预请求。

  数据预请求是将数据预请求的时机由业务发起请求的时机,提前到用户点击时,并行发送数据请求,缩短数据等待时间。

  

  在Webview启动的时候,并行的去请求首屏需要的数据,流程图如下所示:

  

  首屏数据的接口信息,可以通过一些配置关联起来,比如一个单独的配置接口。

  对客户端而言,H5初始化的时间和数据请求的时间先后不确定。

  所以,如果客户端先拿到数据,会把数据缓存在一个全局变量中,等待H5来调用。

  具体的实现方案:

  • 客户端分析出当前URL中的路径和参数,其中 refresh 参数(有的话)是一个时间戳(秒),这次参数用来控制客户端是否需要重新请求配置接口。
  • 当分析的URL参数中无 refresh 字段时,访问 https://xxx.com/settings 接口,并将URL路径、客户端默认带的参数(包含用户ID等)和 URL 本身的参数全部传递过来,然后本地缓存。
https://xxx.com/settings?path=game%2Fstrick&uid=xxxxx&refresh=1618451992
  • 客户端会将settings接口的响应数据缓存到本地,而key就是当前URL,也就是说URL不变的话,默认就不会去请求settings接口。若要穿透缓存,那么加上refresh参数,赋一个与之前不同的值即可。
  • settings 接口返回的JSON格式,包含 urls 字段,是个数组,由接口集合组成,已经拼接好参数。
{
    "urls": [
        "http://xxx.com/xx/xx?id=2",
        "http://xxx.com/yy/yy?uid=1"
    ]
}
  • 客户端将读取到的数据注入到 WebView 的全局对象中,可以用全局变量同步读取,名字叫 TheLClientResponse,读取方式:window.TheLClientResponse,JSON格式如下,其中key是api的路径,如果无数据可以返回 null。
 
{
    "xx/xx": {
        code: 0,
        msg: "test",
        data: {
            list: []
        }
    },
    "yy/yy": {
        code: 0,
        msg: "test",
        data: {
            list: []
        }
    }
}
 
点赞收藏
分类:标签:
咖啡机KFJ

https://www.cnblogs.com/strick

请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
2
1