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

在刷新加載loading的過程，經(jīng)歷了三個階段：

1. 客戶端觸發(fā)頂部刷新；
2. 服務器收到請求后準備要下發(fā)的數(shù)據(jù)；
3. 客戶端收到服務器數(shù)據(jù)進行展示。

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

01 第二階段：“服務器收到請求后準備要下發(fā)的數(shù)據(jù)”。

1. 預計算

在客戶端發(fā)起請求后，服務器側一般會接入推薦系統(tǒng)，計算各種必要數(shù)據(jù)后，再把相應內(nèi)容進行下發(fā)。

那么能不能提前把這些數(shù)據(jù)計算好，當用戶來請求內(nèi)容時，無需計算而直接下發(fā)呢？

答案是可行的，這也就是“預計算”的流程，預計算經(jīng)常會和紅點下發(fā)相結合，服務器在給用戶下發(fā)相應的紅點時，就提前把紅點所對應的內(nèi)容計算好；當用戶通過這個紅點來請求服務器的數(shù)據(jù)時，服務器無需再接推薦系統(tǒng)，也無需進行其它的計算，而是直接把計算好的內(nèi)容返回給客戶端。

圖1-預計算流程

2. 功能拆解

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

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

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

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

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

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

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

02 第三階段：“客戶端收到服務器數(shù)據(jù)進行展示”

1. 假加載策略

你可能會想，客戶端都已經(jīng)收到服務器的數(shù)據(jù)了，直接展示給用戶不就是最好的方法嗎？在這個階段也有耗時優(yōu)化的策略？

是的，還真有。

下面有兩個產(chǎn)品方案，作為用戶你可以考慮一下哪種更被你所接受：

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

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

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

作者：聊哥；公眾號：和產(chǎn)品經(jīng)理聊技術；騰訊工程師，一個致力于打通開發(fā)和產(chǎn)品隔閡，爭做酷炫互聯(lián)網(wǎng)人的同學。

本文由 @和產(chǎn)品經(jīng)理聊技術 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。