大多數(shu)(shu)App都要(yao)與服務(wu)器進(jin)行數(shu)(shu)據的(de)交換，App向服務(wu)器發出(chu)數(shu)(shu)據請(qing)求，服務(wu)器接(jie)收到請(qing)求之后向App傳(chuan)輸相(xiang)應(ying)數(shu)(shu)據，App接(jie)收成功后顯示數(shu)(shu)據內容，沒有接(jie)收成功則反饋數(shu)(shu)據接(jie)收失(shi)敗(bai)。

在這(zhe)(zhe)個數據(ju)交(jiao)換(huan)過程中，由于(yu)網絡原因(yin)，需要(yao)花費一定時(shi)間，也就是說用戶(hu)要(yao)等(deng)待加載(zai)完成，這(zhe)(zhe)個時(shi)候就要(yao)用到loading加載(zai)機制，它告(gao)訴用戶(hu)，App正在努(nu)力(li)為您加載(zai)數據(ju)，您稍(shao)安勿躁。好的loading設計(ji)能減弱用戶(hu)的等(deng)待焦慮，不合理的loading設計(ji)就會讓(rang)用戶(hu)罵爹罵娘了。

標題欄loading：微信、釘釘

釘(ding)釘(ding)&微信

微信、釘釘等(deng)都采用了(le)這(zhe)種形式。聊(liao)天列表頁的(de)(de)聊(liao)天記(ji)錄(lu)是儲存在(zai)本地(di)的(de)(de)，所(suo)以頁面內容(rong)不為空。這(zhe)個時候加載(zai)無需獲取用戶的(de)(de)視覺(jue)焦(jiao)點，只要(yao)在(zai)標題(ti)欄展示App正在(zai)加載(zai)，加載(zai)成功則(ze)標題(ti)欄loading消失，若因(yin)為網絡(luo)錯(cuo)誤(wu)未連接服(fu)務器，則(ze)在(zai)標題(ti)欄顯示未連接狀態。

白屏loading

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

進度條

Safari&微信

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

toast

當用(yong)戶(hu)執(zhi)行了某(mou)個操(cao)作(zuo)時，為了防(fang)止(zhi)用(yong)戶(hu)繼續操(cao)作(zuo)導致數據加載失敗，則用(yong)Toast的(de)樣式來提示正(zheng)在加載，同時限制用(yong)戶(hu)繼續操(cao)作(zuo)。這種情(qing)況(kuang)用(yong)戶(hu)一般只(zhi)能(neng)執(zhi)行返回到上一級頁面(mian)的(de)操(cao)作(zuo)，其他操(cao)作(zuo)都被禁用(yong)。

為(wei)了防止(zhi)數據(ju)一直(zhi)加(jia)(jia)(jia)(jia)載(zai)(zai)不(bu)(bu)出(chu)來，可(ke)以(yi)在(zai)Toast上加(jia)(jia)(jia)(jia)個取(qu)消(xiao)按鈕，讓用戶主(zhu)動停止(zhi)加(jia)(jia)(jia)(jia)載(zai)(zai)狀(zhuang)態，由于加(jia)(jia)(jia)(jia)載(zai)(zai)數據(ju)失敗的情(qing)況極少出(chu)現，所以(yi)在(zai)Toast上加(jia)(jia)(jia)(jia)取(qu)消(xiao)按鈕的App并(bing)不(bu)(bu)多。

下拉刷新

下拉(la)刷(shua)新廣(guang)泛(fan)被運用(yong)(yong)于大多數App，這(zhe)種加載(zai)機制，保證了用(yong)(yong)戶能看到(dao)本地緩存數據的前提下，還(huan)能告(gao)知用(yong)(yong)戶頁面(mian)正在刷(shua)新，同時(shi)，用(yong)(yong)戶還(huan)可(ke)以通過下拉(la)的手勢操(cao)作(zuo)來自己選擇重新加載(zai)數據，一定(ding)程度上(shang)滿足了強迫癥患(huan)者。

預設圖/占位符

當頁(ye)面的(de)框架(jia)固定時，只(zhi)需(xu)要加(jia)(jia)載框架(jia)內數據(ju)時，采用這種刷新樣式，即先加(jia)(jia)載框架(jia)，再加(jia)(jia)載框架(jia)內的(de)數據(ju)。為了(le)反之框架(jia)內的(de)內容為空(kong)，會用占位符(fu)或(huo)者預設(she)圖片(pian)來(lai)填充。

上面(mian)簡單將(jiang)六種(zhong)常見的(de)loading加(jia)(jia)載(zai)(zai)樣式介紹了一下(xia)，樣式雖然有(you)六種(zhong)，但是其實(shi)只有(you)兩種(zhong)加(jia)(jia)載(zai)(zai)原理(li)：一種(zhong)是整體加(jia)(jia)載(zai)(zai)頁面(mian)數據(ju)，加(jia)(jia)載(zai)(zai)完(wan)成后一次顯(xian)示；第(di)二種(zhong)是先加(jia)(jia)載(zai)(zai)部分內(nei)容，再(zai)加(jia)(jia)載(zai)(zai)剩余內(nei)容（先加(jia)(jia)載(zai)(zai)文字(zi)再(zai)加(jia)(jia)載(zai)(zai)圖片；先加(jia)(jia)載(zai)(zai)框架再(zai)加(jia)(jia)載(zai)(zai)框架內(nei)的(de)數據(ju)）。

我常說的(de)一句話是(shi)設計形式永遠是(shi)服(fu)務于產(chan)品(pin)功(gong)能(neng)(neng)的(de)，而產(chan)品(pin)功(gong)能(neng)(neng)則(ze)是(shi)為(wei)了(le)(le)滿足用戶(hu)(hu)需求(qiu)。了(le)(le)解了(le)(le)這(zhe)些(xie)loading加載(zai)的(de)設計形式，進一步(bu)深(shen)度思考一下：這(zhe)些(xie)形式是(shi)為(wei)了(le)(le)減少(shao)用戶(hu)(hu)等待數據加載(zai)時(shi)的(de)焦慮感(gan)(gan)。那么有沒(mei)有更好的(de)機制來降低用戶(hu)(hu)等待時(shi)的(de)焦慮感(gan)(gan)？當然有。

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

第二：采用預加載機制。拿閱(yue)讀App打比方(fang)，當用(yong)戶(hu)在(zai)看第一頁的時(shi)候，App在(zai)后臺(tai)加(jia)(jia)載完后面的幾頁，等(deng)用(yong)戶(hu)翻到第二頁的時(shi)候就不(bu)需要等(deng)待加(jia)(jia)載了(le)，因(yin)為(wei)App已(yi)經幫用(yong)戶(hu)提前加(jia)(jia)載好了(le)。這(zhe)(zhe)種加(jia)(jia)載機(ji)(ji)制(zhi)(zhi)對用(yong)戶(hu)體驗特別好，但(dan)是(shi)存在(zai)一個問題，就是(shi)要預測用(yong)戶(hu)行為(wei)，加(jia)(jia)載其他(ta)數(shu)據，這(zhe)(zhe)樣會消(xiao)耗(hao)不(bu)少流量，所(suo)以建(jian)議(yi)在(zai)WiFi網絡環境(jing)下(xia)采取這(zhe)(zhe)種預加(jia)(jia)載機(ji)(ji)制(zhi)(zhi)，而在(zai)蜂窩(wo)網絡狀態(tai)下(xia)則不(bu)采用(yong)預加(jia)(jia)載機(ji)(ji)制(zhi)(zhi)。這(zhe)(zhe)個要和開發人員討論溝(gou)通，確(que)保預加(jia)(jia)載機(ji)(ji)制(zhi)(zhi)完美運行。

第三：異步處理。這一點(dian)(dian)(dian)做得好(hao)(hao)的(de)(de)App莫過于Instagram，不(bu)(bu)(bu)知道你(ni)有(you)沒有(you)發現，用(yong)Instagram的(de)(de)時(shi)候會覺得特別流暢，即使在(zai)網(wang)(wang)(wang)絡(luo)不(bu)(bu)(bu)好(hao)(hao)的(de)(de)情(qing)況(kuang)下(xia)。這是(shi)(shi)為什么？因為在(zai)網(wang)(wang)(wang)絡(luo)不(bu)(bu)(bu)好(hao)(hao)的(de)(de)情(qing)況(kuang)下(xia)，你(ni)給好(hao)(hao)友(you)點(dian)(dian)(dian)了(le)(le)贊(zan)(zan)，Instagram并不(bu)(bu)(bu)會提示(shi)你(ni)網(wang)(wang)(wang)絡(luo)不(bu)(bu)(bu)好(hao)(hao)，操(cao)(cao)作失敗，而(er)是(shi)(shi)提示(shi)你(ni)點(dian)(dian)(dian)贊(zan)(zan)成功了(le)(le)，其實將(jiang)它只是(shi)(shi)將(jiang)你(ni)點(dian)(dian)(dian)贊(zan)(zan)的(de)(de)操(cao)(cao)作記錄了(le)(le)下(xia)來，等網(wang)(wang)(wang)絡(luo)一好(hao)(hao)就將(jiang)點(dian)(dian)(dian)贊(zan)(zan)的(de)(de)行為上(shang)傳到(dao)服務器，從而(er)完成點(dian)(dian)(dian)贊(zan)(zan)行為。這就是(shi)(shi)減(jian)少用(yong)戶(hu)的(de)(de)操(cao)(cao)作負擔，讓產品自(zi)己去(qu)解決問(wen)題，而(er)不(bu)(bu)(bu)是(shi)(shi)把問(wen)題拋給用(yong)戶(hu)。

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