大多數App都要與服務(wù)器進(jìn)行數據的交換，App向服務(wù)器發(fā)出數據請求，服務(wù)器接收到請求之后向App傳輸相應數據，App接收成功后顯示數據內容，沒(méi)有接收成功則反饋數據接收失敗。
在這個(gè)數據交換過(guò)程中，由于網(wǎng)絡(luò )原因，需要花費一定時(shí)間，也就是說(shuō)用戶(hù)要等待加載完成，這個(gè)時(shí)候就要用到loading加載機制，它告訴用戶(hù)，App正在努力為您加載數據，您稍安勿躁。好的loading設計能減弱用戶(hù)的等待焦慮，不合理的loading設計就會(huì )讓用戶(hù)罵爹罵娘了。
標題欄loading：微信、釘釘
釘釘&微信
微信、釘釘等都采用了這種形式。聊天列表頁(yè)的聊天記錄是儲存在本地的，所以頁(yè)面內容不為空。這個(gè)時(shí)候加載無(wú)需獲取用戶(hù)的視覺(jué)焦點(diǎn)，只要在標題欄展示App正在加載，加載成功則標題欄loading消失，若因為網(wǎng)絡(luò )錯誤未連接服務(wù)器，則在標題欄顯示未連接狀態(tài)。
白屏loading
當頁(yè)面內容比較單一，需要一次性加載完成才顯示，則采用這種白屏加載樣式。這種加載方式用戶(hù)在完全加載完成之前是看不到任何內容的，所以一旦超過(guò)時(shí)間太久一定要提示用戶(hù)什么原因加載失敗，而不是一直在那轉啊轉。同時(shí)將加載圖標做得更有趣些，也會(huì )減輕用戶(hù)等待時(shí)的焦慮(上面右圖就比左圖更讓用戶(hù)感覺(jué)良好)。
進(jìn)度條
Safari&微信
進(jìn)度條的加載樣式，多見(jiàn)于瀏覽器，包括PC端和移動(dòng)端的瀏覽器。一些App頁(yè)面會(huì )用H5的形式去做，這種頁(yè)面多數也都會(huì )采用進(jìn)度條的樣式來(lái)顯示loading過(guò)程。
toast
當用戶(hù)執行了某個(gè)操作時(shí)，為了防止用戶(hù)繼續操作導致數據加載失敗，則用Toast的樣式來(lái)提示正在加載，同時(shí)限制用戶(hù)繼續操作。這種情況用戶(hù)一般只能執行返回到上一級頁(yè)面的操作，其他操作都被禁用。
為了防止數據一直加載不出來(lái)，可以在Toast上加個(gè)取消按鈕，讓用戶(hù)主動(dòng)停止加載狀態(tài)，由于加載數據失敗的情況極少出現，所以在Toast上加取消按鈕的App并不多。
下拉刷新
下拉刷新廣泛被運用于大多數App，這種加載機制，保證了用戶(hù)能看到本地緩存數據的前提下，還能告知用戶(hù)頁(yè)面正在刷新，同時(shí)，用戶(hù)還可以通過(guò)下拉的手勢操作來(lái)自己選擇重新加載數據，一定程度上滿(mǎn)足了強迫癥患者。
預設圖/占位符
當頁(yè)面的框架固定時(shí)，只需要加載框架內數據時(shí)，采用這種刷新樣式，即先加載框架，再加載框架內的數據。為了反之框架內的內容為空，會(huì )用占位符或者預設圖片來(lái)填充。
上面簡(jiǎn)單將六種常見(jiàn)的loading加載樣式介紹了一下，樣式雖然有六種，但是其實(shí)只有兩種加載原理：一種是整體加載頁(yè)面數據，加載完成后一次顯示;第二種是先加載部分內容，再加載剩余內容(先加載文字再加載圖片;先加載框架再加載框架內的數據)。
我常說(shuō)的一句話(huà)是設計形式永遠是服務(wù)于產(chǎn)品功能的，而產(chǎn)品功能則是為了滿(mǎn)足用戶(hù)需求。了解了這些loading加載的設計形式，進(jìn)一步深度思考一下：這些形式是為了減少用戶(hù)等待數據加載時(shí)的焦慮感。那么有沒(méi)有更好的機制來(lái)降低用戶(hù)等待時(shí)的焦慮感?當然有。
第一：優(yōu)化App的加載算法，使得App與服務(wù)器交互數據的時(shí)間簡(jiǎn)短。這個(gè)需要開(kāi)發(fā)人員的精益求精了。這個(gè)是從根本上解決了問(wèn)題，因為直接減少了加載數據的時(shí)間，也就是減少了用戶(hù)需要等待的時(shí)間。
第二：采用預加載機制。拿閱讀App打比方，當用戶(hù)在看第一頁(yè)的時(shí)候，App在后臺加載完后面的幾頁(yè)，等用戶(hù)翻到第二頁(yè)的時(shí)候就不需要等待加載了，因為App已經(jīng)幫用戶(hù)提前加載好了。這種加載機制對用戶(hù)體驗特別好，但是存在一個(gè)問(wèn)題，就是要預測用戶(hù)行為，加載其他數據，這樣會(huì )消耗不少流量，所以建議在WiFi網(wǎng)絡(luò )環(huán)境下采取這種預加載機制，而在蜂窩網(wǎng)絡(luò )狀態(tài)下則不采用預加載機制。這個(gè)要和開(kāi)發(fā)人員討論溝通，確保預加載機制完美運行。
第三：異步處理。這一點(diǎn)做得好的App莫過(guò)于Instagram，不知道你有沒(méi)有發(fā)現，用Instagram的時(shí)候會(huì )覺(jué)得特別流暢，即使在網(wǎng)絡(luò )不好的情況下。這是為什么?因為在網(wǎng)絡(luò )不好的情況下，你給好友點(diǎn)了贊，Instagram并不會(huì )提示你網(wǎng)絡(luò )不好，操作失敗，而是提示你點(diǎn)贊成功了，其實(shí)將它只是將你點(diǎn)贊的操作記錄了下來(lái)，等網(wǎng)絡(luò )一好就將點(diǎn)贊的行為上傳到服務(wù)器，從而完成點(diǎn)贊行為。這就是減少用戶(hù)的操作負擔，讓產(chǎn)品自己去解決問(wèn)題，而不是把問(wèn)題拋給用戶(hù)。
請記住，目前App常見(jiàn)的loading加載樣式就這六種，當然還有其他的加載設計樣式，但是這有什么關(guān)系?你已經(jīng)掌握了產(chǎn)品加載的原理，真正理解了加載機制，這樣你才可以不變應萬(wàn)變。