APP的六種loading加載樣式，全在這

　今天這篇文章是給大家分享的loading加載的設計，文章裡面會有一些執行個體在這分享給大家!

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

　　①标題欄loading

　　 id="iframe_0.9456599992720294" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fwww.cdtedu.com%2Fuploads%2Fallimg%2F160921%2F1-1609211004523C.png&maxWidth=1274&origin=http://www.cnblogs.com&iframeId=iframe_0.9456599992720294" frame scrolling="no" height="532" style="margin: 0px; padding: 0px; border-width: initial; border-style: none; width: 1274px;">

　　釘釘&微信

　　微信、釘釘等都采用了這種形式。聊天清單頁的聊天記錄是儲存在本地的，是以頁面内容不為空。這個時候加載無需擷取使用者的視覺焦點，隻要在标題欄展示App正在加載，加載成功則标題欄loading消失，若因為網絡錯誤未連接配接伺服器，則在标題欄顯示未連接配接狀态。

　　②白屏loading

　　 id="iframe_0.8528660163554596" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fwww.cdtedu.com%2Fuploads%2Fallimg%2F160921%2F1-160921100501639.png&maxWidth=1274&origin=http://www.cnblogs.com&iframeId=iframe_0.8528660163554596" frame scrolling="no" height="532" style="margin: 0px; padding: 0px; border-width: initial; border-style: none; width: 1274px;">

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

　　③進度條

　　 id="iframe_0.29777102308489556" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fwww.cdtedu.com%2Fuploads%2Fallimg%2F160921%2F1-1609211005103D.png&maxWidth=1274&origin=http://www.cnblogs.com&iframeId=iframe_0.29777102308489556" frame scrolling="no" height="538" style="margin: 0px; padding: 0px; border-width: initial; border-style: none; width: 1274px;">

　　Safari&微信

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

　　④toast

　　 id="iframe_0.2037633358843356" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fwww.cdtedu.com%2Fuploads%2Fallimg%2F160921%2F1-16092110051K50.png&maxWidth=1274&origin=http://www.cnblogs.com&iframeId=iframe_0.2037633358843356" frame scrolling="no" height="538" style="margin: 0px; padding: 0px; border-width: initial; border-style: none; width: 1274px;">

　　當使用者執行了某個操作時，為了防止使用者繼續操作導緻資料加載失敗，則用Toast的樣式來提示正在加載，同時限制使用者繼續操作。這種情況使用者一般隻能執行傳回到上一級頁面的操作，其他操作都被禁用。

　　為了防止資料一直加載不出來，可以在Toast上加個取消按鈕，讓使用者主動停止加載狀态，由于加載資料失敗的情況極少出現，是以在Toast上加取消按鈕的App并不多。

　　⑤下拉重新整理

　　 id="iframe_0.46370536953109" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fwww.cdtedu.com%2Fuploads%2Fallimg%2F160921%2F1-160921100525958.png&maxWidth=1274&origin=http://www.cnblogs.com&iframeId=iframe_0.46370536953109" frame scrolling="no" height="537" style="margin: 0px; padding: 0px; border-width: initial; border-style: none; width: 1274px;">

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

　　⑥預設圖/占位符

　　 id="iframe_0.8883164400771473" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fwww.cdtedu.com%2Fuploads%2Fallimg%2F160921%2F1-160921100536213.png&maxWidth=1274&origin=http://www.cnblogs.com&iframeId=iframe_0.8883164400771473" frame scrolling="no" height="542" style="margin: 0px; padding: 0px; border-width: initial; border-style: none; width: 1274px;">

　　當頁面的架構固定時，隻需要加載架構内資料時，采用這種重新整理樣式，即先加載架構，再加載架構内的資料。為了反之架構内的内容為空，會用占位符或者預設圖檔來填充。

　　上面簡單将六種常見的loading加載樣式介紹了一下，樣式雖然有六種，但是其實隻有兩種加載原理：一種是整體加載頁面資料，加載完成後一次顯示;第二種是先加載部分内容，再加載剩餘内容(先加載文字再加載圖檔;先加載架構再加載架構内的資料)。

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

　　第一：優化App的加載算法，使得App與伺服器互動資料的時間簡短。這個需要開發人員的精益求精了。這個是從根本上解決了問題，因為直接減少了加載資料的時間，也就是減少了使用者需要等待的時間。

　　第二：采用預加載機制。拿閱讀App打比方，當使用者在看第一頁的時候，App在背景加載完後面的幾頁，等使用者翻到第二頁的時候就不需要等待加載了，因為App已經幫使用者提前加載好了。這種加載機制對使用者體驗特别好，但是存在一個問題，就是要預測使用者行為，加載其他資料，這樣會消耗不少流量，是以建議在WiFi網絡環境下采取這種預加載機制，而在蜂窩網絡狀态下則不采用預加載機制。這個要和開發人員讨論溝通，確定預加載機制完美運作。

　　第三：異步處理。這一點做得好的App莫過于Instagram，不知道你有沒有發現，用Instagram的時候會覺得特别流暢，即使在網絡不好的情況下。這是為什麼?因為在網絡不好的情況下，你給好友點了贊，Instagram并不會提示你網絡不好，操作失敗，而是提示你點贊成功了，其實将它隻是将你點贊的操作記錄了下來，等網絡一好就将點贊的行為上傳到伺服器，進而完成點贊行為。這就是減少使用者的操作負擔，讓産品自己去解決問題，而不是把問題抛給使用者。

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