如何設計移動APP的加載與刷新策略？

你好，我是餿麪包，本文 4489 字，分享一些移動端APP的加載和刷新機制。

本篇文章我會從“加載目的”的維度來對加載進行分類，主要分為：數據加載和操作過程加載。

1）數據加載

包含從單個元素到整個頁面在內的所有對數據的加載。

2）操作過程加載

應用中所有操作（提交信息、關注、訂閲等）的加載過程。

一、數據加載

數據加載分為兩種情況：頁面有緩存和頁面無緩存。

大家可以嘗試關掉WiFi和4G，然後打開淘寶和美團，你會發現它們的首頁都是有內容的，或者説只會存在少部分內容缺失，這時候頁面的內容就是上次打開APP緩存的內容。

APP為了避免空白情況的出現，會對數據做緩存處理，這樣即使用户網絡不好的時候打開APP也不會出現空白的現象，然後APP再進行加載，就能把內容銜接上。

這樣處理的目的有兩個：

1. 一是提升用户體驗，增加使用流暢感。
2. 二是減少用户關閉APP的概率，增加粘性，人的注意力和忍耐有限，一旦出現空白而網絡又不流暢，用户耐心耗盡的後果就是關閉APP，除非你是微信這樣的户“不得不用”的產品。

那麼網絡不好的時候有緩存和無緩存該如何處理，用户體驗會更好？

1.1 有緩存

現在大多數APP都做了緩存處理，打開APP的時候首先展示緩存內容，然後才進行數據的加載，這樣處理的目的前文也説過：用户體驗更好，使用更流暢。

先顯示緩存再加載新內容的知乎

知乎會把用户上次瀏覽的內容緩存下來，用户再次打開APP的時候顯示的是上次最後瀏覽的內容。

但是值得探討的是，在網絡連接的時候知乎的‘推薦’和‘熱榜’板塊以及虎嗅網的首頁新聞並沒有自動加載內容，而是選擇讓用户手動加載，而知乎的‘關注’板塊卻在進入頁面時自動進行刷新。

我想這裏的策略應該是基於用户的習慣而來的，對於‘關注’的內容，用户既然單擊了它説明用户是想看自己關注的內容的最新動態，就如我們每次進入朋友圈時想看的一定是最新的朋友圈動態，這是人的習慣或者説人性。

對於熱榜的手動刷新起初我是不理解的，但是當我多次切換tab的時候就發現了，如果我每次切換熱榜都更新一次，那麼就會導致這樣一種情況：我點擊熱榜，熱榜更新，此時我查看榜單的內容，我看到了一半，這時候我突然又想搜索一下“怎麼瘦小腿”，看完了之後我想去把剩下的熱榜內容看了，這時候我點擊熱榜，熱榜刷新，我發現榜單完全變了，我看不到之前的內容了。現在知乎的熱榜有50條，如果頻繁刷新的話，那麼可能導致熱榜後半部分內容展現率很低。

除了內容資訊類APP外，音樂視頻類也是緩存大户。

畢竟這些產品是由內容撐起來的，一旦沒有內容，APP就空了。

網易雲音樂目前採取的方式是WiFi環境自動緩存歌曲，這樣就能在無網絡的環境也能聽歌。

利用這個方法可以讓我用過期的會員賬號聽會員才能聽的歌曲，不過一旦聯網……就game over了……

顯示緩存同時給與無網絡提示的網易雲音樂

1.2 無緩存

無緩存的刷新場景較有緩存的情況會多很多，畢竟手機容量有限，總不能把所有內容都給用户緩存下來。

無緩存有以下幾種加載方式：

1.2.1 白屏加載

白屏加載意思是進入界面前無緩存，進入界面後才加載內容，由於事先沒有緩存，會出現白屏的現象。

白屏加載的加載方式有進度條加載和loading動畫。

H5頁面和瀏覽器網頁一般會使用進度條加載，APP原生加載一般使用加載動畫，也就是常見的‘菊花’加載，或者有的APP為了緩解用户點焦慮感和提升品牌曝光度會自制有趣的加載動畫。

瀏覽器使用進度條，美團使用菊花

白屏加載在APP中適合界面內容不固定或者內容不多的頁面。

1.3 分步加載

分佈加載有三種：

1.3.1 先文字後圖片

顧名思義即是先加載數據少的文字，後加載數據大的圖片。

目前很多應用包括美團和得到都包含這種設計方式，這樣的加載策略可以很大程度上提升產品的流暢性。

如下圖，美團商家詳情先加載文字信息，後加載商家圖；以及得到的課程詳情也是先加載文字信息後加載圖片信息。

先加載文字後加載圖片

1.3.2 兜底圖

上一點説的是分步加載，先圖片後文字，那麼如果圖片加載比較慢怎麼辦？

這時候就可以使用兜底圖的方式。

兜底圖是在加載圖片的時候對圖片或者類似圖片的位置做的一個佔位圖。

加載順序是：兜底圖→線上圖

兜底圖是目前市面上產品應用得比較多的加載策略，我想幾乎每個叫得上名字的APP都會使用這個加載方式，少數產品會直接使用色塊顯示，多數產品會展示品牌logo。

36氪和網易新聞的佔位圖則直接使用的純色色塊，個人比較傾向於增加品牌曝光和趣味性的logo展示。但是純色色塊的好處是可以讓研發直接寫，不用切圖，一定程度可以減少頁面資源佔用。

使用純色色塊佔位

1.3.3 骨架屏

骨架屏最先是應用在網頁上的一種佔位方式，一般使用和頁面佈局相似的矩形色塊來展示，現在也廣泛用在移動應用上。

由於是固定的矩形塊佈局，所以骨架屏更加適合頁面內容佈局相對固定的頁面，比如列表頁、詳情頁等。

目前有相當多的產品都應用了骨架屏，比如知乎、美團、得到、企鵝體育等等。

加載骨架屏

1.4 智能加載

智能加載的意思是根據手機網絡狀況選擇加載方式。

這種判定方式在流量還沒這麼便宜的時候尤為重要，不然不小心看個視頻就可能把話費燒光，雖説現在流量便宜很多甚至很多人都花不光每個月的流量，但是這個提示還是非常有必要的。

因為在直播和短視頻如此盛行的今天，即使用户願意為流量買單我們也需要給與提示，避免用户看直播和視頻導致流量用光。

如果不做流量提示，一來體驗不好甚至會遭到投訴，二來用户會沒有掌控感。

畢竟每個人內心其實都有一個想要掌控全世界的小怪獸不是嗎，雖無法掌控世界，至少能讓我掌控自己的手機流量吧…

智能加載我調研了目前市面上主流APP（主要是視頻直播類）的處理方法，主要有以下幾種：

操作後加載：

• 適用於：非即時播放和耗流量高的應用（長視頻、音頻等）
• 形式：彈出框、播放區域提示
• 策略1：彈框給用户選擇提示頻次
• 策略2：手動點擊繼續播放後播放，下次進入使用toast提示（愛奇藝）

輕提示：

• 適用於：即時播放和耗流量低的應用（直播、微視頻等）
• 形式：toast提示
• 策略1：toast提示1次後不再提示（印客直播、大眾點評、今日頭條）
• 策略2：每次看視頻/直播均提示（淘寶）
• 策略3：自行設置提示次數
• 個人中心設置允許3G/4G自動播放

1.4.1 操作後加載

操作後加載形式上有彈出彈框提示或者讓用户選擇提示次數。

一種形式是彈出框提示

比如懶人聽書（聽書類APP）目前就是這樣設計的，用户可以自行選擇播放設置，用户選擇今日不再提醒之後，今天內用户聽語音都不再提示。

針對語音類產品這樣設計影響不大，聽語音產生的流量比視頻要少得多。

主動給用户選擇權

另一種形式是播放區域提示：

這種方式主要應用在視頻類產品中，比如優酷視頻、QQ、騰訊視頻、愛奇藝等視頻或者包含視頻板塊的APP。

由於視頻會消耗較多流量，大多數包含視頻的APP都會做比較強的流量提示。

個人比較欣賞的是騰訊視頻和QQ這樣的提示方式，針對單個視頻做流量統計，點擊可繼續播放，流量數據展示能給用户最大的安全感。

統計視頻流量

當然，這種方式的開發成本不低，如果資源有限的情況下選擇其它方式也無可厚非。

比如愛奇藝和優酷在播放窗口的提示，用户選擇繼續播放後下次進入界面時可以使用輕提示即可，即可以提示用户當前網絡環境又可以避免每進入視頻頁都需要手動選擇播放。

提示用户當前使用流量

1.4.2 輕提示

針對一些直播類產品更傾向於使用toast提示，因為這類產品的視頻是即時播放的，如果直接打斷用户的觀看過程在使用不夠好。

目前淘寶、映客等直播均使用的是toast這樣輕量級的提示方式，儘量做到不中斷用户的觀看過程。

僅做toast輕量提示

1.5 懶加載

懶加載也叫延遲加載，意思是首次加載用户看得見的部分，當用户滑動屏幕時再進行加載，也可以説是按需加載。

懶加載的目的其實很好理解，一次性加載完數據對服務器壓力會比較大而且也沒太大必要，按需加載是比較好的節省資源的方式。

懶加載是目前應用中用得非常多的一種加載方式，尤其是列表的加載場景，比如電商APP淘寶京東的商品列表、美團的訂單列表、新聞列表等等都會用到懶加載。

上拉加載更多數據

需要我們注意的是，做交互的時候需要定義加載數量規則，實際工作中會根據場景來定義加載數量。

既能讓用户無感加載又能減輕服務器的壓力。

一般文字類的數據少的列表一次可以多加載幾條，20到50不等，圖文和視頻類加載可以少加載幾條，一般10到20不等，不過具體還是需要根據場景定義。

1.6 預加載

預加載顧名思義就是提前幫用户加載的意思，有預測用户行為的意思，預測用户可能會打開某幾個頁面，然後提前將這些頁面的內容加載出來，這樣用户在點擊的時候幾乎能夠無縫銜接，體驗會非常好。

劣勢也很明顯，由於是預測，就避免不了用户可能不會點擊到下一個頁面，這就導致我們事先加載的資源白加載了，所以預加載的應用目前還是不夠廣泛的，下面會舉幾個例子具體説明。

預加載下一級界面內容在新聞資訊類的產品中應用得較多，比如今日頭條、虎嗅，當我進入首頁後把網關掉後仍然點擊進入前2條新聞仍然可以看到新聞的文字內容。

這裏涉及到一個預加載的加載策略：

• 預加載新聞前2條（或3條）數據的下一級頁面
• 下一級頁面僅加載文字部分（圖片部分可以進入頁面後再行加載）

目前今日頭條和虎嗅就是這樣處理的。

二、操作過程加載

操作過程加載在優先級上我認為比數據加載更重要，數據加載影響體驗，但是操作過程加載不完善可能涉及到業務流程出現問題。

舉一個常見的提交信息場景：

用户提交訂單時會點擊【提交】按鈕，點擊後將數據傳給服務器生成訂單。

此時如果網絡不好，數據還沒到達服務器端，用户再次點擊【提交】按鈕，那麼就會提交兩次數據，也會生成兩條訂單，嚴重的話會造成用户損失。

但是如果這裏的【提交】按鈕增加了一個提交中的加載狀態，或者加一個全屏加載中的loading效果，使得用户無法點擊，那麼用户就不能重複提交數據，也不會造成重複訂單的出現。

所以可見，操作過程的加載是多麼重要。而這部分又是新手設計師最容易忽略的地方，往往等到產品測試甚至上線後出現問題才來修改，給別人留下不專業的印象事小，造成用户的損失事大。

下面我總結了3種常見的操作過程加載形式：

2.1 模態加載

在數據加載的章節提到過白屏加載中包含了模態加載，模態加載一般會使用一個loading動畫來展示。

加載過程中用户無法進行其它的操作，最大程度保證了流程的單向性。

這裏提到的模態加載是針對數據提交的‘加載中’的一種狀態表示，用户提交數據後無法進行其他操作。

這裏需要注意的是需要保留【返回】按鈕。

萬一用户因為網絡不好或者其它問題出現了無限加載中的狀態，還能依靠返回來結束當前加載。不然用户只能依靠“殺”後台來關掉APP，這是極其不好的體驗。

提交過程中的模態加載

2.2 控件自身加載

控件自身加載最常見的是按鈕的‘加載中’狀態，大多數網絡良好的時候我們甚至看不見這個狀態，但是它確實實實在在非常重要的。

相比全屏的模態加載，按鈕的加載有一個弊端就是用户可能更改其它部分的數據，雖然概率極其微小，但是保險起見，涉及金錢類的歷程最好只用模態加載。

提交過程中的按鈕加載

2.3 後台加載

後台加載的意思是用户在操作後，客户端立刻反饋操作成功，然後把請求放到後台與服務器交互。

比如常見的點贊、收藏等操作，當我們點擊後會發現狀態立即改變，然後在後台和服務器進行交互操作，雖然可能操作失敗導致收藏點贊失敗，但是相比成功的概率，失敗微不足道，何況及時反饋能夠大大提升用户體驗呢。

還有一個非常典型的例子是朋友圈的點贊，即使把網絡關閉後仍然可以點贊。

先改變狀態，後處理交互

本文由 @餿麪包 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議