設計移動端應用產品時，我們絕大多數的精力和時間都會花在各個頁面的設計上。但與此同時，網絡環境的復雜性，會造成在網速偏慢、弱網、無網的條件下，用戶相當一部分停留時長會用在Loading上——無論頁面最終呈現出來的狀態我們設計得多么精美，它的加載總是需要一個過程。

而頁面打開和跳轉時的加載過程，很多時候會在設計中被嚴重忽視，最后在項目上線前倉促、隨意地進行設計，甚至任由開發找一個「菊花」放上去轉一轉就完事了。

Loading過程的設計缺失對用戶體驗的傷害無法量化，但長此以往，猶如一劑慢性毒藥，總有突破用戶忍耐極限，導致用戶流失的一天。

本文將簡單梳理移動端應用設計中常見的加載模式，并結合一些國內外應用的實例，探討如何針對場景特點選用合適的加載方式。

一. 模態加載

提到加載方式的分類，最明確的一個界限應該就是模態加載和非模態加載。而說起模態加載，可能有人會根據一些經典書籍中的觀點認為模態一定是不好的，非模態才是正義。

但事實上，選用模態加載還是非模態加載，首先要做的是問自己一個問題，這個加載是否出現在不可逆流程?

1. 模態加載與「不可逆流程」

這里說的「不可逆」并非表達平日語境下「無法挽回」的含義，只是指一些單向通行的線性流程。典型如注冊類(注冊、登錄、找回密碼)、交易類(下單、支付、轉賬)流程，比如下圖易信的注冊流程和微信發紅包的流程。

在不可逆流程中，一個步驟加載時如果允許用戶隨意觸發其他行為，極易導致各種分支和異常。為了防止用戶犯錯，也為了設計和開發時減少異常流數量，在這類流程中使用模態加載是很正常的選擇。

2. 其他場景下，避免模態阻斷

而在無關不可逆路徑的情況下，確實如經典論述所說的，應該減少模態阻斷的使用。

采用模態加載則會讓用戶在等待期間無所事事，等待時間較長時會加劇焦躁情緒的產生。尤其是一些APP直接在啟動頁采用模態加載，這會導致用戶感覺與產品每次見面都有一道無法逾越的鴻溝。

在國內，這種情況已經比較少了。不過少數金融類的APP仍然會直接在啟動頁進行阻斷式的模態加載，考慮到金融類APP需要保障資金安全，這樣的處理方式可能有一些行業特殊性。

一貫傳統的日本，時至如今，很多APP仍然保留了在登錄頁就模態加載的習慣。即使是毫無阻斷必要的。

電商類APP和交通查詢類APP也是如此，以服飾電商ZOZOTOWN和東京メトロ為例。

當然，這兩個APP實際上內部的設計質量已經非常不錯了，有許多細節是值得借鑒的，這里只是就事論事討論它們的啟動加載問題。

它們在啟動加載中使用了蒙層式的模態加載，即使東京メトロ設計了極富特色的加載指示符(9個代表不同線路的小圓圈)，仍然改變不了一種將用戶拒之門外的隔閡感。

如果說電商APP的啟動多是在用戶較為閑暇、安靜的場景，模態登錄帶來的傷害相對較小。那么交通查詢類APP就不一樣了，啟動場景多是在戶外移動，急于知道結果以確定下一步往哪走的情形之下，更不適合使用模態加載。地鐵查詢APP更為特殊，很大比例的場景是用戶正在地鐵中查詢換乘信息，在信號不佳的情況下直接模態阻斷，這樣的體驗是致命的。

綜上，我的判斷是，除了不可逆流程外，基本上沒太大必要去使用模態加載。

百度地圖在搜索地點中使用了模態，相比之下，而iOS自帶的地圖，搜索地點就沒有采取模態加載，用戶可以在不耐煩時隨時嘗試其他操作，體驗上的差別顯而易見。

3. 模態阻斷要有「取消」選項

即使確信模態加載是正確的，最好也給用戶一個「取消」的選項，避免用戶只有殺掉進程以結束漫長的等待。

上面例子中，百度地圖的搜索采用模態或許必要性不大，但至少設計師意識到了「取消」選項的重要性，用戶在加載過程過慢時可以隨時點擊「×」終止行為。

反例是EBAY的登錄頁，上面有一個「×」，會讓用戶誤以為是「取消」，但實際上是關閉登錄頁的按鈕，在登錄加載過程中是無法點擊的。弱網環境下的用戶唯有漫長的等待，唯一能做的就是殺掉進程。用戶被卡住后不停地點擊「×」卻毫無反應，帶來的焦躁和挫敗感可想而知。

二. 整屏加載

另一類常見的加載嚴格來說不屬于模態，因為對于產品整體來說，用戶可以自由選擇執行其他操作，但對當前正在瀏覽的內容層而言卻又是一種阻斷性的加載。準確的描述應該稱為「局部模態」或者「內容層模態加載」，這里為了敘述方便，簡稱為「整屏加載」。

1. 整屏加載

原生應用的整屏加載，常見的做法是內容區整體保持空白，中間或內容區頂部有加載提示符(多數是Spinner，就是我們俗稱的轉菊花)告知用戶耐心等待，直至所有數據請求就緒，再整體展示整個頁面。

整屏加載是最簡單的一種加載處理方法，適用于頁面中所有數據，每次查看都需要重新請求、不存在本地數據的情況。在知乎、Behance、Airbnb、網易云音樂、ENJOY、熊貓直播等各類型的APP中都有廣泛應用。

整屏加載的本質是內容層的模態加載，因此和模態加載一樣，需要一個明確的超時判斷，在超過指定時間數據仍未請求成功時，告知用戶可能存在的原因和下一步行動點，避免一直卡在加載進程中。

告知加載失敗的結果時，融合一些品牌特征和情感化設計，可以有效緩解用戶加載失敗的挫敗情緒，甚至會在心底給產品設計的用心加分。

2. 瀏覽器加載

瀏覽器加載，是瀏覽器APP中最常見到的加載呈現方式——在地址欄下方以線性進度條的形式告知用戶當前加載進度。

同時，許多原生APP中也有加載Web頁面的場景。在調用內置瀏覽器內核的時候，就會自然而然地繼承很多瀏覽器的交互形式。例如微信內置的是QQ瀏覽器內核，所以在加載公眾號、朋友圈文章等Web頁面時，會在頂欄下顯示迷你進度條。

3. 為什么整屏加載不像瀏覽器加載一樣展示具體進度？

這里稍微延伸一個問題。

關于Loading的很多論述中都提到，加載提示符如果有進度提示，可以更好地讓用戶對等待時間有一個預期，有效地減輕等待的未知感和焦躁情緒。

這句話本身毫無疑問是有道理的。但我們回想一下，除了瀏覽器加載之外，無論是一個普通應用，還是以重視設計、關心用戶體驗著稱的應用中整屏加載時，為什么都很少見到帶進度信息的加載提示符，而是廣泛地使用Spinner和它各式各樣的衍生形式?

我個人的判斷是，移動端應用需要讓用戶忽略等待時間，減少具體進度帶來的壓迫，所以通常都要求速度極快(在網速正常的情況下)，這種情況下進度條連看都看不清，自然沒有必要一閃而過。原生頁面的加載，通常情況下也比一個Web頁面從DOM開始加載的速度要快，所以無論于目標于能力，都不需要也不適合具體進度的展示。反觀Web頁面的加載，一方面平均耗時較長，另一方面也有繼承PC端遺留習慣的因素，所以展示進度條就成了一個不成文的慣例。

其次，告知用戶真實加載進度的愿望很美好，而現實很骨感，絕大多數情況下，資源的加載時間都是不固定且無法預知的。預先判斷需要請求的數據量并迅速折算出真實進度，對開發來說并不是一件容易的事。即使做到了，真實的加載進度實際上是「一卡一卡」非常不流暢的過程。

所以，在瀏覽器加載中，我們所看到流暢推進的進度條，多數都是假的，所以會經常出現進度條走到99%，頁面實際加載完畢還遙遙無期的情況。

瀏覽器的進度判斷是通過監聽加載狀態實現的。而在大量結構標簽和內容數據的加載中，只有為數不多的節點會有事件產生，最容易想到的自然是開始和結束兩個節點。很多情況下，會在DNS解析和資源下載完成時就讓進度條跑到90%甚至99%，但后續的加載過程有時遠比下載過程更耗時，所以卡節點的情況在所難免。

這里補充一個設計上的小技巧，兩個節點之間同樣的進度條，相比勻速前進、按真實節點前進，先快后慢地前進能讓用戶產生加載更快的錯覺。雖然是種假象，但用戶需要的就是這樣的假象。

三. 非模態加載

1. 標題欄加載

IM、郵箱這類應用在內容加載上特點非常鮮明。首先，這類應用的大量數據都是存在本地的;其次，本地數據的瀏覽在任何情況下都不應該受制于網絡速度。試想，沒信號的時候連歷史聊天記錄都看不了是一件多么可怕的事情。

因此，在這類應用中通常會在頂欄(也有在底欄)顯示加載提示符(通常是以文字+Spinner的形式)，這里簡稱為標題欄加載。這種方式的優勢在于不妨礙用戶在內容區點擊查看任何已有消息。