文章針對APP的幾類加載狀態(tài)展開分析，希望能夠?qū)δ阌兴鶐椭?/p>

我們產(chǎn)品各模塊的加載樣式全部由開發(fā)自己定，結(jié)果是百花齊放，各有各的用法，前階段被領(lǐng)導(dǎo)噴了一頓。關(guān)于加載這一塊，交互規(guī)范恰好缺失，于是交互開始嘗試梳理相應(yīng)規(guī)范。本文梳理時，我查看了相關(guān)文章，我們部門也組織了討論，但感覺并沒有完全解決我的疑惑，于是在其基礎(chǔ)上重新組織，擴展了一些，也咨詢了一些前后端同學(xué)，本文算是我階段性的梳理結(jié)果，拿出來和大家討論，期待完善。

加載是什么

加載是一種反饋狀態(tài)，常見樣式有菊花、進度條等。用戶與產(chǎn)品的每一次互動都需要反饋，用戶依賴反饋信息，才能順利完成連貫的操作。用戶在等待反饋結(jié)果時，焦急專注的盯著界面，這時，系統(tǒng)需要告訴用戶“hi，我還活著，正在努力干活呢，別走！” 下圖摘自 Ant Design ：

什么時候使用

“1s是對話中可以有的最長間隔，又因為交互系統(tǒng)的操作是一個對話的形式，所以交互系統(tǒng)應(yīng)該避免自己一方的長時間間隔，否則用戶會懷疑發(fā)生了什么。系統(tǒng)有1s的時間去執(zhí)行用戶要求做的任務(wù)或者標志出操作需要多少時間，要不然用戶會失去耐心”——摘自《認知與設(shè)計》

結(jié)合上面這句話，關(guān)于何時使用，我這么理解：如果系統(tǒng)1s內(nèi)就能完成任務(wù)，可以不給加載圖標，如果系統(tǒng)1s內(nèi)不能完成任務(wù)，則需要在1s內(nèi)彈出加載中的提示。

加載的邏輯

討論加載類型前，先梳理一下加載的邏輯，這有利于我們理清楚各種加載的關(guān)系?？v軸為時間（請忽略圖的配色，盡力了?_?）

客戶端接收到用戶操作后，向服務(wù)端發(fā)送請求，服務(wù)端響應(yīng)然后返回數(shù)據(jù)，客戶端把數(shù)據(jù)翻譯成用戶看的懂的元素。用戶從執(zhí)行操作后就一直在等待結(jié)果?？蛻舳藦陌l(fā)送到接收到數(shù)據(jù)這段時間在等待結(jié)果。比較耗時的是發(fā)送接收數(shù)據(jù)以及渲染展示的環(huán)節(jié)。服務(wù)器查找時間取決于服務(wù)器性能和存儲等；發(fā)送耗時受網(wǎng)絡(luò)影響；渲染展示時間取決于前端和機器性能，知道這些，就可以對癥下藥了，誰家的孩子，誰拎回去修理，交互能做的就是配和他們的方案，選擇合適的方式，做好對用戶的宣傳。

用戶等待時容易焦慮，用戶正看著屏幕呢，于是各種加載，各種轉(zhuǎn)移注意力就上場了，穩(wěn)住用戶，別讓他離開。

• 第一件事：告訴用戶我在工作，沒有偷懶。
• 第二件事：轉(zhuǎn)移用戶注意力，減少用戶等待的焦慮感，可以看看漂亮有趣的加載動畫，或者瀏覽歷史的加載內(nèi)容等。

模態(tài)加載與非模態(tài)加載

模態(tài)加載

模態(tài)加載屬獨占姿態(tài)，會阻斷用戶的其他操作，加載時，用戶只能眼睜睜等待。屬強勢女魔頭，老娘最美，看我；模態(tài)加載簡單粗暴，也最容易實現(xiàn)，但對用戶來說卻不友好。就像點餐一樣，服務(wù)員非要等到所有菜都做好了才給端上來，客人很可能直接走人了。

模態(tài)加載一般形式是浮在頁面上的旋轉(zhuǎn)菊花，也可以根據(jù)自己品牌設(shè)計具有特色和情調(diào)的加載樣式，我們就是因為樣式混亂被領(lǐng)導(dǎo)批。

何時使用

模態(tài)加載體驗不佳，但它有其合理性和不可替代性，我根據(jù)收集的頁面，粗略歸納了幾類，應(yīng)該沒有覆蓋完全，關(guān)于技術(shù)方便的描述也不準確，歡迎留言補充和指正

1 加載的內(nèi)容必須一起呈現(xiàn)出來，否則會出問題，可能是功能未準備完全，不能夠使用，少給開發(fā)哥哥找麻煩；也可能因為丑，必須色香味俱全加雕花都做好。具體細節(jié)還需要跟開發(fā)同學(xué)仔細溝通。

2 舊命令正在處理中，當前不允許你再修改請求。如圖2的微信發(fā)紅包，系統(tǒng)正在處理發(fā)1元紅包的請求，正在準備支付頁面。此時不允許你修改金額，否則我當前處理的1元怎么辦？我魚都給你紅燒了，你突然要清蒸。如果很多人都頻繁的修改、提交，系統(tǒng)的壓力應(yīng)該會很大、也浪費了資源。這時候的模態(tài)是綜合考量后的合理處理方式。

3 初次加載，不知道結(jié)果去哪里，頁面長什么樣。如圖3，系統(tǒng)正在發(fā)送請求，還沒有收到服務(wù)器返回的數(shù)據(jù)，客戶端頁不知道最終傳來的是什么。此刻用戶面對空空的頁面也確實沒有其他的事可做，此刻的模態(tài)加載可以接受，但如果請求進行時，當前頁面有內(nèi)容，且用戶操作不會對剛才請求造成影響時，需要使用非模態(tài)的加載。

如上圖，空頁面第一次加載時，使用模態(tài)加載；頁面返回數(shù)據(jù)后，再次加載則使用了非模態(tài)，細分場景，體驗很舒服。

注意，如果模態(tài)加載時間較長，需要給出加載進度，長時間加載，用戶可能以為界面死了，不知道進度也會失去耐心

非模態(tài)加載

非模態(tài)加載，比較溫和，你繼續(xù)做你的事，同時我加載你要的東西，準備好了就給你。在某個角落，不干擾你做事，又不離開你視線，貼心小棉襖。讓用戶在等待的時候有事可做，不用干等，緩解用戶等待的焦慮。

何時使用

如上文提到的，當前頁面有數(shù)據(jù)，用戶有事可做，且用戶行為不會影響到原來的加載請求，這時候適合使用非模態(tài)加載。常見的有上拉加載、下拉加載。加載的提示信息可以放在頁內(nèi)，狀態(tài)欄 、操作欄等，位置比較靈活

非模態(tài)的加載方式，一定成都減輕了在當前頁面有內(nèi)容時，用戶的等待焦慮；在空頁面加載時效果不理想。還能再優(yōu)化一些？程序員那里還有更高階的方法。為了減少用戶感知的等待時間，系統(tǒng)可以盡早的向用戶展示信息。

Skeleton Screen/加載占位圖

還是用點餐的例子，去餐廳點餐，你點的是套餐，這就很舒服了，服務(wù)員、廚師都套餐的流程，菜品都非常熟悉。菜還沒開始做，就可以先把紅酒、蠟燭、刀叉給你擺好了。頁面也是，當用戶請求的頁面布局，我們已知時，可以先在頁面加載占位圖，等到數(shù)據(jù)回來后再陸續(xù)的填進去，給用戶加載很快的感覺。

如下圖，餓了么h5，先加載頁面布局，這時候數(shù)據(jù)還沒有返回，界面已經(jīng)開始響應(yīng)。

何時使用

Skeleton Screen 適合內(nèi)容排班比較固定或排版布局已知的頁面，先加載大致輪廓，再加載細節(jié)。使用競品時發(fā)現(xiàn)，有些產(chǎn)品發(fā)布了新版本，占位圖卻沒做更新，導(dǎo)致加載前后有閃屏的感覺。所以，布局未知，布局多變的頁面，不要使用。

懶加載

當用戶請求的頁面包含大量內(nèi)容，如文本、圖片、音視頻等，全部渲染完成需要較長時間。懶加載就像餐廳服務(wù)員一樣，把菜一個一個的送給用戶，懶加載解決的是客戶端渲染展示給用戶這一環(huán)節(jié)。

從圖上看，懶加載進步一壓縮了用戶的等待時間，用戶不必等到頁面全部加載完成就可以開始閱讀（一些工具類頁面，懶加載過程不允許操作或操作無響應(yīng)），減少用戶的等待焦慮。對客戶端而言，原來3s要加載完的內(nèi)容可以拖到5s分批給，減輕了壓力。如果用戶不喜歡中途離開了，剩下的內(nèi)容可以不用渲染，少干了不少活。

懶加載的實現(xiàn)方式（摘自http://www.jianshu.com/p/4876a4fe7731）

1. ?延遲加載，比如先加載文字再加載圖片
2. 條件加載 即符合某些條件，或者觸發(fā)了某些事件才開始異步下載
3. 可視區(qū)域加載，僅加載用戶可以看到的區(qū)域，不可見區(qū)域不加載，當該區(qū)域可見后再加載

如下圖示例，今日頭條先加載文字，后加載圖片；高德地圖可視區(qū)域外的區(qū)域等到用戶滑動屏幕時才加載，節(jié)省流量。

綜上，懶加載更像是打著緩解用戶等待焦慮的旗號，客戶端偷懶的方法。

預(yù)加載

懶加載將原來5秒全部加載完成優(yōu)化到了2秒就可以提供部分內(nèi)容，但用戶說別人家瞬間就加載完了，你還要拖拖拉拉，5s才能加載完！這又是什么黑科技。

再看這張圖，預(yù)加載是更貼心的小棉襖，會揣摩用戶的心思，偷偷提前做準備。用戶在看A頁面時，客戶端就在準備用戶可能會看的B頁面，用戶需要時，立刻給他，然后去準備C頁面，給用戶提供無縫鏈接的感覺，代價就是服務(wù)端、客戶端都累的夠嗆，耗費用戶更多的流量。預(yù)加載一直走在用戶前面，勤快、周到。懶加載一致等待用戶發(fā)號施令，是真的懶。

如下圖，刷新今日頭條列表，詳情頁就已經(jīng)開始準備了。此刻切換飛行模式，點開文章詳情，能看到文字已經(jīng)顯示在那里了，為什么沒有圖片？機智的程序員為了給用戶省流量，確認用戶點開后才開始請求圖片。

綜上，為了能讓頁面加載流暢，達到最好的使用體驗，需要結(jié)合產(chǎn)品和場景組合使用加載方式，文中舉例的產(chǎn)品都不止使用了一種加載手段。具體實現(xiàn)方案還需要結(jié)合自己的產(chǎn)品和場景來確定。

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