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

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

加載是什么

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

什么時(shí)候使用

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

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

加載的邏輯

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

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

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

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

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

模態(tài)加載

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

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

何時(shí)使用

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

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

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

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

如上圖，空頁(yè)面第一次加載時(shí)，使用模態(tài)加載；頁(yè)面返回?cái)?shù)據(jù)后，再次加載則使用了非模態(tài)，細(xì)分場(chǎng)景，體驗(yàn)很舒服。

注意，如果模態(tài)加載時(shí)間較長(zhǎng)，需要給出加載進(jìn)度，長(zhǎng)時(shí)間加載，用戶(hù)可能以為界面死了，不知道進(jìn)度也會(huì)失去耐心

非模態(tài)加載

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

何時(shí)使用

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

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

Skeleton Screen/加載占位圖

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

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

何時(shí)使用

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

懶加載

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

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

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

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

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

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

預(yù)加載

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

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

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

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

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