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

一. 用戶、客戶端和服務器

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

用戶、客戶端、服務器

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

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

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

1. 標題loading

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

2. 白屏loading

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

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

3. 優(yōu)先加載

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

3. Skeleton Screen

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

5. 下拉改寫加載

6. 分段加載

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

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

7. 智能加載

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

三. 關于加載的更多考慮

      由于存在網速不快、網絡反常、服務器反常、bug等狀況，讓用戶等候的狀況是必不可少的�？墒俏覀兌贾�道，等候會發(fā)生焦慮感，分分鐘卸載你的產品，除了用上文介紹的其間loading，還有沒有其他方法來下降或緩解用戶的焦慮感?

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

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

2. 選用預加載和智能加載的方法

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

3. 異步處理

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

      假如能和自身品牌元素結合起來，一起能反映出產品的調性，那就再好不過了。

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