客戶端加載耗時優化方案(下)

0 評論 5171 瀏覽 18 收藏 6 分鐘

編輯導語:在上一篇文章中,作者分析了加載耗時優化方案中的“客戶端觸發頂部刷新”,本文將繼續從“服務器收到請求后準備要下發的數據”和“客戶端收到服務器數據進行展示”進行耗時優化策略的討論,我們一起來看一下。

在刷新加載loading的過程,經歷了三個階段:

  1. 客戶端觸發頂部刷新;
  2. 服務器收到請求后準備要下發的數據;
  3. 客戶端收到服務器數據進行展示。

本篇文章將從第二階段“服務器收到請求后準備要下發的數據”和第三階段“客戶端收到服務器數據進行展示”討論耗時優化的策略。

01 第二階段:“服務器收到請求后準備要下發的數據”。

1. 預計算

在客戶端發起請求后,服務器側一般會接入推薦系統,計算各種必要數據后,再把相應內容進行下發。

那么能不能提前把這些數據計算好,當用戶來請求內容時,無需計算而直接下發呢?

答案是可行的,這也就是“預計算”的流程,預計算經常會和紅點下發相結合,服務器在給用戶下發相應的紅點時,就提前把紅點所對應的內容計算好;當用戶通過這個紅點來請求服務器的數據時,服務器無需再接推薦系統,也無需進行其它的計算,而是直接把計算好的內容返回給客戶端。

圖1-預計算流程

2. 功能拆解

我們知道,當用戶請求服務器內容時,服務器針對這個請求做的計算越多,返回給用戶就越慢。

舉個例子:如果在視頻號頂部刷新時,返回的結果不止會告訴你【feed流信息】,還會在頂部返回【正在直播的用戶信息】。

服務器計算【feed流信息】和【正在直播的用戶信息】都會增加用戶加載的耗時,但如果把這兩個功能拆解呢?

比如用戶頂部刷新時,給后臺觸發兩路請求,一個是請求【feed流信息】,另外一個請求【正在直播的用戶信息】,那么就可以盡可能快的返回服務器的內容給用戶進行展示。

圖2-功能合并時的請求流程

圖3-功能拆解時的請求流程

注意:功能拆解是減緩用戶等待焦慮的一種辦法,但功能拆解可能會導致數據沒有同步刷新;比如可能會先展示【feed流信息】,在你預覽用戶新返回的feed流信息時,【正在直播的用戶信息】服務器延遲返回,可能就會打斷你的預覽體驗;所以當功能拆解影響到了UI展示時,就需要慎重。

02 第三階段:“客戶端收到服務器數據進行展示”

1. 假加載策略

你可能會想,客戶端都已經收到服務器的數據了,直接展示給用戶不就是最好的方法嗎?在這個階段也有耗時優化的策略?

是的,還真有。

下面有兩個產品方案,作為用戶你可以考慮一下哪種更被你所接受:

  • A.服務器一次性返回10條數據,客戶端一次性全部展示;
  • B.服務器一次性返回10條數據,但客戶端只先展示前5條,當你瀏覽完5條后,本地再做一個0.5s的刷新,把剩下的5條數據展示出來。

這里實際上存在一個用戶心理是:過期焦慮。當用戶一直在本地瀏覽內容,卻沒有看到有刷新加載的標志時,這種情況出現時間越長,用戶就會越覺得自己是在看過期的內容;當采用A方案時,可能用戶看到第7條內容時,就覺得自己已經很久沒有從服務器獲取數據了,就會回到頂部觸發刷新。

而采用B方案時,用戶不僅會有獲取新數據的提示,而且也會驚嘆于加載耗時的速度,提升用戶瀏覽的效率。

 

作者:聊哥;公眾號:和產品經理聊技術;騰訊工程師,一個致力于打通開發和產品隔閡,爭做酷炫互聯網人的同學。

本文由 @和產品經理聊技術 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!