為什么要處理“加載”狀態(tài)
在頁(yè)面拉取數(shù)據(jù)、或提交某些數(shù)據(jù)時(shí)，需要一定的時(shí)間來等待服務(wù)端返回結(jié)果。如果不處理加載，用戶可能會(huì)看到一片空白，以為你的軟件出錯(cuò)；或者因沒有建立心理預(yù)期，被突然出現(xiàn)的內(nèi)容嚇到。所以，你可以利用這段時(shí)間來降低用戶的焦慮情緒、讓用戶對(duì)即將出現(xiàn)的內(nèi)容有一定的預(yù)期。這就是處理“加載”狀態(tài)的意義。

在交互設(shè)計(jì)階段，經(jīng)常會(huì)遇到需要處理“加載”的情況，接下來我從兩方面來講解下如何快速設(shè)計(jì)“加載”這件事：

---

“加載”的流程是怎樣的

要處理加載狀態(tài)，必須要理解整個(gè)加載流程，這4個(gè)狀態(tài)必須要搞懂：

• 【觸發(fā)】：即自動(dòng)進(jìn)行加載，或者點(diǎn)擊某個(gè)按鈕后進(jìn)行的加載，這個(gè)觸發(fā)行為要明確；
• 【加載中】：這個(gè)就是出現(xiàn)一個(gè)loading，一般就是執(zhí)行一個(gè)動(dòng)畫。看似簡(jiǎn)單，但這個(gè)不一定每個(gè)人都能處理好，一會(huì)兒會(huì)細(xì)說；
• 【加載成功】：成功后的行為，通常會(huì)顯示具體內(nèi)容，或者進(jìn)入某個(gè)頁(yè)面或流程，這在交互設(shè)計(jì)文檔中要明確標(biāo)注；
• 【加載失敗】：有成功就有失敗，失敗的處理往往考驗(yàn)交互設(shè)計(jì)師的邏輯完整性。在此狀態(tài)下應(yīng)給與“重新加載”的機(jī)制。

所以你的交互流程必須涵蓋這四點(diǎn)，這樣一個(gè)基本的設(shè)計(jì)思路就有了。

---

“加載”應(yīng)該怎樣分類

經(jīng)常有人分為【全局加載 / 局部加載】，這種分類方式是片面的，在我看來不夠好。【全局】本身包含了【局部】這個(gè)概念，且到底多大算”局部“，全頁(yè)面算不算一個(gè)“大局部”，用起來容易混淆。

經(jīng)過實(shí)踐，應(yīng)以使用場(chǎng)景來為“加載”進(jìn)行分類，分別是：

• 內(nèi)容加載
• 模態(tài)加載
• 上拉/下拉加載

內(nèi)容加載

無(wú)論是整頁(yè)內(nèi)容的加載，或是局部?jī)?nèi)容的加載，均屬于這類，整體流程如下圖：

整頁(yè)內(nèi)容的加載示意

局部?jī)?nèi)容的加載示意

一般進(jìn)入頁(yè)面會(huì)自動(dòng)觸發(fā)，在加載時(shí)，允許用戶進(jìn)行其他操作（如返回）；加載成功時(shí)，顯示對(duì)應(yīng)的內(nèi)容；加載失敗時(shí)，可以點(diǎn)擊按鈕進(jìn)行重新加載。

現(xiàn)在流行的框架圖，是一種加載形式上的演進(jìn)，好處是讓用戶對(duì)接下來出現(xiàn)的內(nèi)容有預(yù)期，但本質(zhì)上仍然是內(nèi)容的加載：

框架圖占位-本質(zhì)上是一種加載形式的演進(jìn)

模態(tài)加載

應(yīng)用場(chǎng)景一般是點(diǎn)擊某個(gè)按鈕后，此時(shí)需要和服務(wù)端進(jìn)行交互，且需等待服務(wù)端返回結(jié)果，這個(gè)過程會(huì)消耗一定時(shí)間，此時(shí)需明確告知用戶：

一個(gè)典型的表單提交流程

使用模態(tài)加載時(shí)，典型的觸發(fā)時(shí)機(jī)是點(diǎn)擊某個(gè)按鈕；在加載中的時(shí)候，一般不允許用戶進(jìn)行操作，會(huì)出現(xiàn)蒙層將頁(yè)面整體遮擋（這個(gè)蒙層可以是黑色半透明，也可能是全透明的，視覺效果不同而已）；

也有部分APP在loading時(shí)帶個(gè)關(guān)閉操作，如百度地圖、高德地圖，可以臨時(shí)關(guān)閉loading動(dòng)畫，來讓用戶重新獲取對(duì)APP的控制；但只要設(shè)置好loading的超時(shí)時(shí)間，一般不需要此關(guān)閉按鈕。

加載成功時(shí)，會(huì)視業(yè)務(wù)流程而進(jìn)入其他頁(yè)面；加載失敗時(shí)，一般會(huì)彈出toast進(jìn)行提示，用戶可以點(diǎn)擊按鈕再次進(jìn)行加載。

上拉/下拉加載

這是一種帶有交互手勢(shì)的加載行為，其實(shí)和點(diǎn)擊某個(gè)按鈕進(jìn)行加載沒有本質(zhì)區(qū)別。Twitter最先開始使用“下拉加載”，慢慢的變?yōu)樾袠I(yè)內(nèi)的標(biāo)準(zhǔn)行為，以至于影響用戶的習(xí)慣。

這個(gè)交互最應(yīng)關(guān)注的是【觸發(fā)機(jī)制】，以“下拉加載”為例，它包含3個(gè)過程：

開始下拉，直到一個(gè)閾值；

達(dá)到閾值后，松手進(jìn)行加載；

加載成功或失敗后，收起此控件。

加載過程中，可以使用一些富有創(chuàng)意的動(dòng)畫，來突顯品牌形象；加載成功時(shí)，頁(yè)面內(nèi)容進(jìn)行刷新；加載失敗時(shí)，一般會(huì)進(jìn)行toast提示。

這個(gè)例子比較多，大家隨便找找常用的APP，都能發(fā)現(xiàn)一些使用場(chǎng)景，我這里就不舉例了。

---

需要注意的問題

• 加載類型不要混用，有不少APP為了省事，在應(yīng)該使用全頁(yè)面的【內(nèi)容加載】時(shí)，反而使用了【下拉加載動(dòng)畫】進(jìn)行替代，這有時(shí)會(huì)導(dǎo)致一些莫名其妙的問題。

比如有一個(gè)長(zhǎng)列表，每次刷新都使用下拉加載動(dòng)畫，用戶已將列表滾動(dòng)了一段距離，在數(shù)據(jù)刷新后列表可能會(huì)被重置在頂部，讓用戶之前滾動(dòng)操作失效。

• 涉及到圖片的加載流程，會(huì)有兩次網(wǎng)絡(luò)請(qǐng)求：第一次會(huì)詢問服務(wù)端“是否有圖片”，如果有圖片，那么第二次會(huì)根據(jù)服務(wù)端返回的地址，再去拉取圖片資源。

這種情況下，一般在第一次請(qǐng)求時(shí)不建議出現(xiàn)局部loading，因?yàn)閳D片可能會(huì)不存在。在確認(rèn)圖片存在后，會(huì)使用占位圖（一般是個(gè)灰底圖片，占位用的）來等待第二次的返回結(jié)果。當(dāng)然，這也要視具體場(chǎng)景而設(shè)計(jì)。

• 全文只描述了“加載”這一種場(chǎng)景，完善的加載流程也需要考慮到“刷新機(jī)制”及“緩存策略”（如X秒自動(dòng)刷新數(shù)據(jù)、提前緩存數(shù)據(jù)以減少加載時(shí)間等），這里就不展開講了，感興趣的同學(xué)可以自行搜索“加載、刷新、緩存”三者的聯(lián)系。

---

以上，希望能幫助到你。

總結(jié)

以上是生活随笔為你收集整理的android中常用的下拉刷新加载更多_如何设计“加载流程”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。