在刷新加载loading的过程,经历了三个阶段:
- 1.客户端触发顶部刷新;
- 2.服务器收到请求后准备要下发的数据;
- 3.客户端收到服务器数据进行展示。
本篇文章将从第二阶段“服务器收到请求后准备要下发的数据”和第三阶段“客户端收到服务器数据进行展示”讨论耗时优化的策略。
第二阶段:“服务器收到请求后准备要下发的数据”。
1)预计算
在客户端发起请求后,服务器侧一般会接入推荐系统,计算各种必要数据后,再把相应内容进行下发。
那么能不能提前把这些数据计算好,当用户来请求内容时,无需计算而直接下发呢?
答案是可行的,这也就是“预计算”的流程,预计算经常会和红点下发相结合,服务器在给用户下发相应的红点时,就提前把红点所对应的内容计算好;当用户通过这个红点来请求服务器的数据时,服务器无需再接推荐系统,也无需进行其它的计算,而是直接把计算好的内容返回给客户端。
2)功能拆解
我们知道,当用户请求服务器内容时,服务器针对这个请求做的计算越多,返回给用户就越慢。
举个例子:如果在视频号顶部刷新时,返回的结果不止会告诉你【feed流信息】,还会在顶部返回【正在直播的用户信息】。
服务器计算「feed流信息」和「正在直播的用户信息」都会增加用户加载的耗时,但如果把这两个功能拆解呢?
比如用户顶部刷新时,给后台触发两路请求,一个是请求「feed流信息」,另外一个请求「正在直播的用户信息」,那么就可以尽可能快的返回服务器的内容给用户进行展示。
注意:功能拆解是减缓用户等待焦虑的一种办法,但功能拆解可能会导致数据没有同步刷新;比如可能会先展示「feed流信息」,在你预览用户新返回的feed流信息时,「正在直播的用户信息」服务器延迟返回,可能就会打断你的预览体验;所以当功能拆解影响到了UI展示时,就需要慎重。
第三阶段:“客户端收到服务器数据进行展示”
1)假加载策略
你可能会想,客户端都已经收到服务器的数据了,直接展示给用户不就是最好的方法吗?在这个阶段也有耗时优化的策略?
是的,还真有。
下面有两个产品方案,作为用户你可以考虑一下哪种更被你所接受:
- A.服务器一次性返回10条数据,客户端一次性全部展示;
- B.服务器一次性返回10条数据,但客户端只先展示前5条,当你浏览完5条后,本地再做一个0.5s的刷新,把剩下的5条数据展示出来。
这里实际上存在一个用户心理是:过期焦虑。当用户一直在本地浏览内容,却没有看到有刷新加载的标志时,这种情况出现时间越长,用户就会越觉得自己是在看过期的内容;当采用A方案时,可能用户看到第7条内容时,就觉得自己已经很久没有从服务器获取数据了,就会回到顶部触发刷新。
而采用B方案时,用户不仅会有获取新数据的提示,而且也会惊叹于加载耗时的速度,提升用户浏览的效率。