相信大家在運用APP的時分都有過這樣的經(jīng)歷，等候加載頁面。絕大部分的APP都需求與服務(wù)器進行數(shù)據(jù)交換，APP發(fā)出數(shù)據(jù)懇求，繼而服務(wù)器接納后傳輸相應(yīng)數(shù)據(jù)到APP，APP成功接納后，顯現(xiàn)數(shù)據(jù)內(nèi)容，而接納失利即無法顯現(xiàn)數(shù)據(jù)內(nèi)容。用戶在運用APP的時分可能會由于網(wǎng)絡(luò)原因，需求等候必定的時刻進行這個數(shù)據(jù)交換數(shù)據(jù)加載的進程，而這個等候的時刻就需求APP開發(fā)中的loading加載機制，好的loading規(guī)劃能讓用戶耐心等候，而不合理的loading會讓用戶欠好的運用體會。

一. 用戶、客戶端和服務(wù)器

       作為用戶體會規(guī)劃師，不管是APP開發(fā)產(chǎn)品、交互仍是UI，都習(xí)氣于站在人機交互的角度去考慮產(chǎn)品規(guī)劃問題，在這個進程中往往會疏忽了一個重要進程：客戶端和服務(wù)器之間的數(shù)據(jù)懇求和傳輸。先看下面這張圖。

用戶、客戶端、服務(wù)器

      用戶與客戶端進行人機交互，觸發(fā)某個操作，客戶端會將用戶觸發(fā)的操作轉(zhuǎn)化為相應(yīng)指令，向服務(wù)器懇求數(shù)據(jù)，若網(wǎng)絡(luò)和服務(wù)器正常，服務(wù)器會回來數(shù)據(jù)到客戶端，用戶便能看到自己操作所引發(fā)的成果。整個進程是用戶、客戶端、服務(wù)器一起完成的，人與客戶端之間是人機交互研究的領(lǐng)域，而客戶端和服務(wù)器之間的數(shù)據(jù)傳輸更多的是開發(fā)人員所考慮的。

      已然數(shù)據(jù)傳輸是開發(fā)人員考慮的問題，身為規(guī)劃師是不是就不必考慮了?當(dāng)然不是，原因很簡單：數(shù)據(jù)傳輸?shù)臓顩r會影響到人機交互。例如，假如數(shù)據(jù)傳輸遇到網(wǎng)絡(luò)不穩(wěn)定或許服務(wù)器反常，就要在人機界面體現(xiàn)出來，不然用戶會手足無措，發(fā)生焦慮，影響用戶體會，這便是UED要考慮網(wǎng)絡(luò)和服務(wù)器反常時的交互規(guī)劃的原因。再比如，一個頁面包含許多信息，即便網(wǎng)絡(luò)穩(wěn)定，也要加載不少時刻，那怎樣經(jīng)過交互規(guī)劃來緩解用戶的焦慮。

二. 數(shù)據(jù)加載的幾種方法及對應(yīng)的交互規(guī)劃

1. 標(biāo)題loading

      聊天列表頁的聊天記錄是儲存在本地的，所以頁面內(nèi)容不為空。這個時分加載無需獲取用戶的視覺焦點，只要奉告用戶頁面正在懇求新數(shù)據(jù)，所以挑選在標(biāo)題欄展現(xiàn)App正在加載是個不錯的挑選，加載成功則標(biāo)題欄loading消失，若由于網(wǎng)絡(luò)錯誤未銜接服務(wù)器，則在標(biāo)題欄顯現(xiàn)未銜接狀態(tài)。

2. 白屏loading

當(dāng)頁面內(nèi)容比較單一，直接一次性加載完再顯現(xiàn)數(shù)據(jù)。多出現(xiàn)在H5 頁面。內(nèi)容加載完成之前界面都會停留在loading界面。許多產(chǎn)品都會選用無限循環(huán)的小菊花，但進度條和有趣的動畫規(guī)劃，更能減輕用戶等候時的焦慮感。

      除了進度條+卡通動畫+案牘的方法，還有種更為高級的白屏loading款式。

3. 優(yōu)先加載

      當(dāng)有文字和圖片時，圖片會比文字加載的慢，這個時分往往文字先加載，圖片在加載進程中運用占位符，直到圖片加載成功。當(dāng)加載的頁面內(nèi)容有固定的結(jié)構(gòu)時，能夠先加載結(jié)構(gòu)，再加載結(jié)構(gòu)內(nèi)的內(nèi)容。經(jīng)過先加載頁面結(jié)構(gòu)，規(guī)劃占位符等方法能夠削減用戶的心思等候時長，進步產(chǎn)品體會。

3. Skeleton Screen

      這種加載方法你可能沒聽過，可是必定見過。它是一種將未加載出來的內(nèi)容區(qū)域，用灰色的色塊填充的方法。所以整個頁面在加載進程中會給用戶很連接的感覺。這種方法一般用于內(nèi)容結(jié)構(gòu)固定的頁面，假如頁面可能會出現(xiàn)空數(shù)據(jù)的狀況也不宜運用。合作前面講的優(yōu)先加載的方法，作用會更佳。

5. 下拉改寫加載

6. 分段加載

      當(dāng)新頁面的內(nèi)容有好幾百條乃至更多時，假如一次性加載一切內(nèi)容，會添加設(shè)備的擔(dān)負，而且加載內(nèi)容過大，加載時刻會過長，一起APP自身也能夠由于運算本錢太高而崩潰。為了處理這個問題，發(fā)生了一種叫分段加載的方法。即：先加載最新的幾十條數(shù)據(jù)，當(dāng)用戶繼續(xù)向上滑動想閱讀更多時，再加載幾十條。

      分段加載要在PRD或許交互規(guī)劃文檔里清晰注明，一次性加載多少條內(nèi)容，假如內(nèi)容以圖片為主，主張加載 20 到 30 條左右，假如內(nèi)容以文本為主，主張 40 到 60 條左右。

7. 智能加載

      當(dāng)網(wǎng)絡(luò)狀態(tài)欠好時，能夠考慮加載低質(zhì)量的圖片，當(dāng)網(wǎng)絡(luò)杰出時，則加載高質(zhì)量的圖片。同理，當(dāng)檢測到用戶正在運用蜂窩數(shù)據(jù)時，則顯現(xiàn)占位符而不顯現(xiàn)圖片，當(dāng)運用WiFi時則直接加載出圖片。這些規(guī)劃計劃都是站在用戶的角度，替用戶著想，為用戶帶來價值，用戶才會真實喜愛上你的產(chǎn)品。

三. 關(guān)于加載的更多考慮

      由于存在網(wǎng)速不快、網(wǎng)絡(luò)反常、服務(wù)器反常、bug等狀況，讓用戶等候的狀況是必不可少的。可是我們都知道，等候會發(fā)生焦慮感，分分鐘卸載你的產(chǎn)品，除了用上文介紹的其間loading，還有沒有其他方法來下降或緩解用戶的焦慮感?

1. 優(yōu)化App的加載算法，使得App與服務(wù)器數(shù)據(jù)傳輸?shù)臅r刻減短

      這個需求開發(fā)人員的精益求精了。這個是從根本上處理了問題，由于直接削減了加載數(shù)據(jù)的時刻，也就削減了用戶需求等候的時刻。

2. 選用預(yù)加載和智能加載的方法

      拿閱讀App打比方，當(dāng)用戶在看第一頁的時分，App在后臺加載完后面的幾頁，等用戶翻到第二頁的時分就不需求等候加載了，由于App現(xiàn)已幫用戶提早加載好了。這種加載機制對用戶體會特別好，可是存在一個問題，便是要預(yù)測用戶行為，加載其他數(shù)據(jù)，這樣會耗費不少流量，所以主張在WiFi網(wǎng)絡(luò)環(huán)境下采取這種預(yù)加載機制，而在蜂窩網(wǎng)絡(luò)狀態(tài)下則不選用預(yù)加載機制。這個要和開發(fā)人員評論交流，確保預(yù)加載機制完美運轉(zhuǎn)。

3. 異步處理

4. 規(guī)劃有趣的loading動畫

      假如能和自身品牌元素結(jié)合起來，一起能反映出產(chǎn)品的調(diào)性，那就再好不過了。

      回到文章的開頭，APP的開發(fā)也好，微信定制開發(fā)也好，企業(yè)網(wǎng)站建造也好，等等都產(chǎn)品開發(fā)人員都不應(yīng)該把視野限制在人與客戶端之間的交互，也要把客戶端和服務(wù)端之間的數(shù)據(jù)傳輸考慮進來，站在用戶、客戶端和服務(wù)器閉環(huán)的角度去考慮產(chǎn)品，只有這樣，才能規(guī)劃出體會更好的數(shù)據(jù)加載計劃，而不會有失偏頗。