最常見的APP六種loading加載樣式

大多數App都要與服務器進行數據的交換，App向服務器發(fā)出數據請求，服務器接收到請求之后向App傳輸相應數據，App接收成功后顯示數據內容，沒有接收成功則反饋數據接收失敗。在這個數據交換過程中，由于網絡原因，需要花費一定時間，也就是說用戶要等待加載完成，這個時候就要用到loading加載機制，它告訴用戶，App正在努力為您加載數據，您稍安勿躁。好的loading設計能減弱用戶的等待焦慮，不合理的loading設計就會讓用戶罵爹罵娘了。

標題欄loading

釘釘&微信

微信、釘釘等都采用了這種形式。聊天列表頁的聊天記錄是儲存在本地的，所以頁面內容不為空。這個時候加載無需獲取用戶的視覺焦點，只要在標題欄展示App正在加載，加載成功則標題欄loading消失，若因為網絡錯誤未連接服務器，則在標題欄顯示未連接狀態(tài)。

白屏loading

當頁面內容比較單一，需要一次性加載完成才顯示，則采用這種白屏加載樣式。這種加載方式用戶在完全加載完成之前是看不到任何內容的，所以一旦超過時間太久一定要提示用戶什么原因加載失敗，而不是一直在那轉啊轉。同時將加載圖標做得更有趣些，也會減輕用戶等待時的焦慮（上面右圖就比左圖更讓用戶感覺良好）。

進度條

Safari&微信

進度條的加載樣式，多見于瀏覽器，包括PC端和移動端的瀏覽器。一些App頁面會用H5的形式去做，這種頁面多數也都會采用進度條的樣式來顯示loading過程。

toast

當用戶執(zhí)行了某個操作時，為了防止用戶繼續(xù)操作導致數據加載失敗，則用Toast的樣式來提示正在加載，同時限制用戶繼續(xù)操作。這種情況用戶一般只能執(zhí)行返回到上一級頁面的操作，其他操作都被禁用。

為了防止數據一直加載不出來，可以在Toast上加個取消按鈕，讓用戶主動停止加載狀態(tài)，由于加載數據失敗的情況極少出現，所以在Toast上加取消按鈕的App并不多。

下拉刷新

下拉刷新廣泛被運用于大多數App，這種加載機制，保證了用戶能看到本地緩存數據的前提下，還能告知用戶頁面正在刷新，同時，用戶還可以通過下拉的手勢操作來自己選擇重新加載數據，一定程度上滿足了強迫癥患者。

預設圖/占位符

當頁面的框架固定時，只需要加載框架內數據時，采用這種刷新樣式，即先加載框架，再加載框架內的數據。為了反之框架內的內容為空，會用占位符或者預設圖片來填充。

上面簡單將六種常見的loading加載樣式介紹了一下，樣式雖然有六種，但是其實只有兩種加載原理：一種是整體加載頁面數據，加載完成后一次顯示；第二種是先加載部分內容，再加載剩余內容（先加載文字再加載圖片；先加載框架再加載框架內的數據）。

我常說的一句話是設計形式永遠是服務于產品功能的，而產品功能則是為了滿足用戶需求。了解了這些loading加載的設計形式，進一步深度思考一下：這些形式是為了減少用戶等待數據加載時的焦慮感。那么有沒有更好的機制來降低用戶等待時的焦慮感？當然有。

第一：優(yōu)化App的加載算法，使得App與服務器交互數據的時間簡短。這個需要開發(fā)人員的精益求精了。這個是從根本上解決了問題，因為直接減少了加載數據的時間，也就是減少了用戶需要等待的時間。

第二：采用預加載機制。拿閱讀App打比方，當用戶在看第一頁的時候，App在后臺加載完后面的幾頁，等用戶翻到第二頁的時候就不需要等待加載了，因為App已經幫用戶提前加載好了。這種加載機制對用戶體驗特別好，但是存在一個問題，就是要預測用戶行為，加載其他數據，這樣會消耗不少流量，所以建議在WiFi網絡環(huán)境下采取這種預加載機制，而在蜂窩網絡狀態(tài)下則不采用預加載機制。這個要和開發(fā)人員討論溝通，確保預加載機制完美運行。

第三：異步處理。這一點做得好的App莫過于Instagram，不知道你有沒有發(fā)現，用Instagram的時候會覺得特別流暢，即使在網絡不好的情況下。這是為什么？因為在網絡不好的情況下，你給好友點了贊，Instagram并不會提示你網絡不好，操作失敗，而是提示你點贊成功了，其實將它只是將你點贊的操作記錄了下來，等網絡一好就將點贊的行為上傳到服務器，從而完成點贊行為。這就是減少用戶的操作負擔，讓產品自己去解決問題，而不是把問題拋給用戶。

請記住，目前App常見的loading加載樣式就這六種，當然還有其他的加載設計樣式，但是這有什么關系？你已經掌握了產品加載的原理，真正理解了加載機制，這樣你才可以不變應萬變。