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

在刷新加載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協議。