本文通過講解組合使用技術(shù)、交互和界面這三個層次的常用策略，希望能驅(qū)動你更好的決策。

一、研究問題的方式

組合使用技術(shù)、交互和界面策略來解決具體問題及目標

用全面的思考來做出更好的決策，這三個層次的思考永遠是相關(guān)的。

本文通過講解這三個層次的常用策略，希望能驅(qū)動你更好的決策。

二、技術(shù)策略

因為加載的本質(zhì)是通信的過程（此處只涉及數(shù)據(jù)傳輸，不涉及系統(tǒng)底層進程，但是原理相同），例如有些游戲進度條加載時會提示「加載不消耗流量」，此時的加載屬于系統(tǒng)硬件加載，沒有產(chǎn)生數(shù)據(jù)通信，所以暫不考慮。

1、同步加載

（1）什么是同步？

我們來講一個小朋友的故事：有一天大雄正在學校做數(shù)學作業(yè)（當前任務），有個特別強壯的同學胖虎走了過來，把作業(yè)本猛的丟到大雄桌子上叫到「先把我的做完，我就在這看著你！」（收到同步任務），大雄對比了一下身型差距，敢怒不敢言，只好先拿過胖虎的作業(yè)本開始做（中斷當前任務，開始處理同步任務），直到做完了胖虎的作業(yè)，很不情愿的交給胖虎（返還任務數(shù)據(jù)），等到胖虎美滋滋的走掉了，大雄才開始繼續(xù)做自己的（繼續(xù)之前的任務）。

這個持強凌弱的故事就和同步的原理類似：同步加載請求執(zhí)行某一任務，直至該請求返回數(shù)據(jù)之前，請求端什么也不干就在旁邊等待。這種方式類似產(chǎn)品開發(fā)流程中的瀑布模型，產(chǎn)品設(shè)計之后才能交付開發(fā)，開發(fā)完成之后才能交付測試。還有某些應用，有新版本更新時彈出一個模態(tài)提醒（一種必須操作的提醒樣式），點擊「更新」之后就在模態(tài)提醒內(nèi)下載，此時不能返回不能退出也不能進行任何操作，除非你殺死應用進程。

（2）為什么用同步加載？

• 即時性，加載完成／失敗會立即得到反饋結(jié)果，上下步操作關(guān)聯(lián)性強
• 技術(shù)上更易于實現(xiàn)，避免了異步加載產(chǎn)生的各種資源利用和同步問題（比如在客戶端更改某屬性值，因為網(wǎng)絡延遲，服務器沒有收到更改消息，而客戶端顯示已經(jīng)更改成功，于是去請求了其它數(shù)據(jù)產(chǎn)生錯誤。PS：真實情況要復雜得多）

（3）同步加載適用情況

• 登錄注冊，提交訂單，上傳資料等下一步操作與當前操作相關(guān)的情況，俗稱順序操作（例如登陸之后才能發(fā)帖）
• 掃碼支付，修改重要資料等獲得操作結(jié)果特別重要的情況
• 產(chǎn)品開發(fā)資源不足的情況，程序猿開發(fā)異步是要工時的（亂加需求是要被打的哈哈）

2、異步加載

（1）什么是異步？

回到剛才的故事，大雄被人欺負心里很苦悶，晚上回家找到正在吃魚的哆啦A夢，對它說「能不能給我做個道具收拾胖虎，等你做好叫我一聲」（收到異步任務），然后就去做別的事情了，哆啦A夢抬頭看看他繼續(xù)吃魚（繼續(xù)之前任務），而大雄就等著什么時候收到道具收拾胖虎了（等待返還任務數(shù)據(jù)）。

異步加載在發(fā)送信息之后，繼續(xù)執(zhí)行下一步操作，等什么時候收到請求的信息，再進行處理。舉個不太恰當?shù)睦?，異步加載就相當于產(chǎn)品開發(fā)流程中的敏捷開發(fā)，現(xiàn)在可以研發(fā)工作和測試工作交叉進行了（同時開展，完成不同任務）。在同步加載小節(jié)更新應用的例子里就是，點擊「更新」之后，下載任務跑到后臺下載去了，你依舊可以在應用里隨便玩，終于不怕突然點錯什么卡住啦。

（2）為什么用異步加載

• 有效的提升用戶體驗，界面跳轉(zhuǎn)動畫和異步加載會讓用戶覺得反饋很靈敏，增強操作的流暢度，避免用戶被阻塞在等待界面產(chǎn)生負(bao)面(zao)情緒，但是操作之間關(guān)聯(lián)性差，若異步處理不好容易讓用戶產(chǎn)生疑惑
• 如果同步加載速度太慢，很可能會長時間停留在加載界面，讓人欲罷不能（不過現(xiàn)在有些應用已經(jīng)開始提供同步加載時的用戶出口）

（3）異步加載適用情況

• 只要不涉及重要資料和順序操作的數(shù)據(jù)加載都適合異步加載
• 大量圖片／視頻的頁面
• 大量item的列表頁
• 涉及大量數(shù)據(jù)計算的頁面
• 體量龐大的H5頁面

3、回調(diào)

（1）什么是回調(diào)？

簡單來講，就是你給別人發(fā)個郵件，他處理完之后給你回郵件，回郵件的過程就是回調(diào)。微信登錄就是典型的回調(diào)過程，在你的應用里點擊微信登陸，然后調(diào)用微信，微信授權(quán)成功之后，再回調(diào)登錄成功的信息給你的應用，你的應用就知道「噢，他登錄成功了」。

（2）回調(diào)的意義

回調(diào)是異步實現(xiàn)的基礎(chǔ)，回調(diào)實現(xiàn)了應用間數(shù)據(jù)傳輸，服務器和客戶端之間的主動數(shù)據(jù)交互等，在此就不多說了，在數(shù)據(jù)加載這里我們就按同步異步來講就好。

三、交互策略

此處要注重強調(diào)一下，不同的交互策略運用了不同的技術(shù)策略，這是兩個維度，并不是簡單的一對一關(guān)系，要學會配合使用。

1、啟動頁加載

同步加載時的常用策略是：加載完某些數(shù)據(jù)才能進入應用，適合對某些關(guān)鍵數(shù)據(jù)進行檢查，例如檢查用戶身份信息，此種策略為了保證一些關(guān)鍵數(shù)據(jù)的可控性。

異步加載的常用策略是：進入應用內(nèi)在加載使用的數(shù)據(jù)，例如進入應用再刷新首頁，這種策略為了提高進入應用的速度。

2、當前頁加載

大部分都是的同步加載，要在當前頁面完成數(shù)據(jù)加載，才能進入下一頁面。網(wǎng)不好？那就在這呆著吧（；￣ェ￣）。

不過一般會在加載期間顯示一些小動畫，例如小菊花，來減緩用戶等待的阻塞感＝ ＝。

在APP里，一般加載失敗留在當前頁面；而在H5頁面里，一般加載失敗，頁面為空或報錯。

3、下一頁加載

為保證用戶體驗，現(xiàn)在大多數(shù)應用都采用下一頁面加載策略，畢竟在當前頁面卡住和在下一頁面卡住是兩種不同的感受哦，用戶心理如是也-_-#，而且網(wǎng)絡差導致頁面加載過慢時，在下一頁加載能一定程度上轉(zhuǎn)移仇恨，讓用戶感覺進不去界面是因為網(wǎng)絡或者其它原因，而我們（APP）可是在很努力的幫他加載呢，千萬不要怪我們呦～

敲黑板：「下一頁加載不等同于異步加載」

（1）白屏加載

這種就是下一頁加載的同步加載版本，一進入頁面出現(xiàn)一個大白屏，直到加載完成一次性顯示全部頁面。

（2）分步加載

一般我們說的分布加載都是異步加載，但是異步加載不是分布加載，要分清楚包含關(guān)系呦～

• 分布加載一般先加載占網(wǎng)絡資源小的元素，隨后再加載圖片、視頻等占大量網(wǎng)絡資源的元素，這種方式多用在大量圖片／視頻的頁面
• 另一種形式是先加載頁面的框架，然后再加載框架里的內(nèi)容，這種方式多用在頁面元素有層級關(guān)系的頁面（例如嵌套），可以保證頁面打開后顯示的格式可控
• 還有一種形式是加載固定數(shù)量的item，現(xiàn)在有大量內(nèi)容的列表頁面的產(chǎn)品，在Feed流頁面普遍使用分布加載，來保證用戶流量和閱讀體驗的平衡

（3）延遲加載

有些內(nèi)容不是界面初始化的時候就需要的，可能在用戶下一步操作（例如上滑頁面）的時候才會出現(xiàn)的，而這些內(nèi)容又占用很多的網(wǎng)絡資源（比如圖片、視頻）這時就使用到延遲加載的策略，延遲加載也屬于分步加載。

例如淘寶，用戶瀏覽時只加載當前屏幕的圖片，直至上滑界面使新的圖片進入可視區(qū)域時，才會加載新圖片，這樣可以節(jié)省用戶流量，同時保證用戶操作的可用性。

（4）預加載

我們和延遲加載對比一下：延遲加載是進入可視區(qū)域后才會加載，預加載就是在進入可視區(qū)域前加載。

預加載是一種在節(jié)省流量和流暢體驗二者中向流暢性優(yōu)化的例子，理想情況下是使用戶感覺不到內(nèi)容的加載過程，滑到哪就能看到哪。

5、智能加載

斷網(wǎng)或弱網(wǎng)時，緩存加載策略能有效提升用戶體驗，在頁面中顯示之前緩存在本地的內(nèi)容，使頁面不至于出現(xiàn)大白屏或者錯誤代碼等。

6、漸進加載

傅立葉變換的實際應用，主要用于高清圖片的加載，在傳輸大圖的過程中，先顯示一個模糊效果，隨著下載數(shù)據(jù)的增多，逐漸精細圖片的細節(jié)，形成一個平滑的加載過程（形成平滑的用戶體驗），最終變成完整分辨率的清晰圖片。

漸進式加載要預先處理圖片和優(yōu)化應用支持，這有點麻煩，所以有一些替代方案的嘗試，舉例如下：

• 微信的加載方式：先顯示一個小圖／縮略圖，隨后加載完成大圖／高清圖再顯示大圖；
• 傳統(tǒng)的加載方式：圖片從上至下／從左至右顯示完成，類似打印機逐行掃描；

四、界面策略

在UI設(shè)計里，關(guān)于數(shù)據(jù)加載的表現(xiàn)形式千變?nèi)f化，具體處理方式總結(jié)起來大概有以下幾種。諾，你看

1、狀態(tài)欄加載

2、導航欄加載

3、白屏加載

簡單粗暴你看是不是？

4、Toast加載

5、進度條加載

6、下拉刷新加載

額外提一下，細膩的下拉動畫是包含下拉加載、釋放加載、正在加載三種狀態(tài)的呦～

7、頁面上滑加載

8、全屏加載

白屏加載的變種，加入了用戶體驗的優(yōu)化，別說效果就是不一樣，在解決問題上的每一點探索都值得尊重，所以我單獨把它列為一類（啟動應用加載也屬于全屏加載）

五、策略組合

如果能看到這里，你一定對技術(shù)、交互、和UI三個層面的數(shù)據(jù)加載解決方案有了大致的了解。非常重要的是，在實際設(shè)計中，這三個層次的解決方案是互相交叉組合來匹配具體的應用場景的，使用不同的策略優(yōu)勢互補，配合解決復雜問題，其目的都是為了更好的用戶體驗或完善業(yè)務邏輯。

此處就先不討論具體策略組合來解決場景問題的方案了，希望正在看文章的你也能思考思考，有哪些有意思的策略組合，解決了復雜場景的問題，可以留言我們一起討論交流～

本文從技術(shù)、交互、UI三個角度梳理了移動應用數(shù)據(jù)加載的常見設(shè)計模式。但是大家一定要記住，模式只是一些比較成熟的解決方案，在實際設(shè)計中不要被模式約束，也不要濫用模式，要深入剖析每個設(shè)計模式是在什么環(huán)境下為解決什么問題而設(shè)計的，明確問題環(huán)境的約束，找到合適的妥協(xié)點，完成你自己的設(shè)計。

關(guān)于用戶體驗：文內(nèi)多次提到用戶體驗，但是因為涉及篇幅太多，而且本篇文章不打算深入聊用戶體驗，所以沒有深入講解，請見諒。

作者：王雪峰，工業(yè)設(shè)計轉(zhuǎn)產(chǎn)品經(jīng)理，奮斗在創(chuàng)業(yè)IT公司，擅長用設(shè)計思維思考產(chǎn)品問題。

本文由 @王雪峰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自?Pixabay，基于?CC0?協(xié)議