起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識解析移動應用數據加載的三層策略與模式
本文通過講解組合使用技術、交互和界面這三個層次的常用策略，希望能驅動你更好的決策。
一、研究問題的方式
組合使用技術、交互和界面策略來解決具體問題及目標
用全面的思考來做出更好的決策，這三個層次的思考永遠是相關的。
本文通過講解這三個層次的常用策略，希望能驅動你更好的決策。
二、技術策略
因為加載的本質是通信的過程（此處只涉及數據傳輸，不涉及系統底層進程，但是原理相同），例如有些游戲進度條加載時會提示「加載不消耗流量」，此時的加載屬于系統硬件加載，沒有產生數據通信，所以暫不考慮。
1、同步加載
（1）什么是同步？
我們來講一個小朋友的故事：有一天大雄正在學校做數學作業（當前任務），有個特別強壯的同學胖虎走了過來，把作業本猛的丟到大雄桌子上叫到「先把我的做完，我就在這看著你！」（收到同步任務），大雄對比了一下身型差距，敢怒不敢言，只好先拿過胖虎的作業本開始做（中斷當前任務，開始處理同步任務），直到做完了胖虎的作業，很不情愿的交給胖虎（返還任務數據），等到胖虎美滋滋的走掉了，大雄才開始繼續做自己的（繼續之前的任務）。
這個持強凌弱的故事就和同步的原理類似：同步加載請求執行某一任務，直至該請求返回數據之前，請求端什么也不干就在旁邊等待。這種方式類似產品開發流程中的瀑布模型，產品設計之后才能交付開發，開發完成之后才能交付測試。還有某些應用，有新版本更新時彈出一個模態提醒（一種必須操作的提醒樣式），點擊「更新」之后就在模態提醒內下載，此時不能返回不能退出也不能進行任何操作，除非你殺死應用進程。
（2）為什么用同步加載？
- 即時性，加載完成／失敗會立即得到反饋結果，上下步操作關聯性強
- 技術上更易于實現，避免了異步加載產生的各種資源利用和同步問題（比如在客戶端更改某屬性值，因為網絡延遲，服務器沒有收到更改消息，而客戶端顯示已經更改成功，于是去請求了其它數據產生錯誤。PS：真實情況要復雜得多）
（3）同步加載適用情況
- 登錄注冊，提交訂單，上傳資料等下一步操作與當前操作相關的情況，俗稱順序操作（例如登陸之后才能發帖）
- 掃碼支付，修改重要資料等獲得操作結果特別重要的情況
- 產品開發資源不足的情況，程序猿開發異步是要工時的（亂加需求是要被打的哈哈）
2、異步加載
（1）什么是異步？
回到剛才的故事，大雄被人欺負心里很苦悶，晚上回家找到正在吃魚的哆啦A夢，對它說「能不能給我做個道具收拾胖虎，等你做好叫我一聲」（收到異步任務），然后就去做別的事情了，哆啦A夢抬頭看看他繼續吃魚（繼續之前任務），而大雄就等著什么時候收到道具收拾胖虎了（等待返還任務數據）。
異步加載在發送信息之后，繼續執行下一步操作，等什么時候收到請求的信息，再進行處理。舉個不太恰當的例子，異步加載就相當于產品開發流程中的敏捷開發，現在可以研發工作和測試工作交叉進行了（同時開展，完成不同任務）。在同步加載小節更新應用的例子里就是，點擊「更新」之后，下載任務跑到后臺下載去了，你依舊可以在應用里隨便玩，終于不怕突然點錯什么卡住啦。
（2）為什么用異步加載
- 有效的提升用戶體驗，界面跳轉動畫和異步加載會讓用戶覺得反饋很靈敏，增強操作的流暢度，避免用戶被阻塞在等待界面產生負(bao)面(zao)情緒，但是操作之間關聯性差，若異步處理不好容易讓用戶產生疑惑
- 如果同步加載速度太慢，很可能會長時間停留在加載界面，讓人欲罷不能（不過現在有些應用已經開始提供同步加載時的用戶出口）
（3）異步加載適用情況
- 只要不涉及重要資料和順序操作的數據加載都適合異步加載
- 大量圖片／視頻的頁面
- 大量item的列表頁
- 涉及大量數據計算的頁面
- 體量龐大的H5頁面
3、回調
（1）什么是回調？
簡單來講，就是你給別人發個郵件，他處理完之后給你回郵件，回郵件的過程就是回調。微信登錄就是典型的回調過程，在你的應用里點擊微信登陸，然后調用微信，微信授權成功之后，再回調登錄成功的信息給你的應用，你的應用就知道「噢，他登錄成功了」。
（2）回調的意義
回調是異步實現的基礎，回調實現了應用間數據傳輸，服務器和客戶端之間的主動數據交互等，在此就不多說了，在數據加載這里我們就按同步異步來講就好。
三、交互策略
此處要注重強調一下，不同的交互策略運用了不同的技術策略，這是兩個維度，并不是簡單的一對一關系，要學會配合使用。
1、啟動頁加載
同步加載時的常用策略是：加載完某些數據才能進入應用，適合對某些關鍵數據進行檢查，例如檢查用戶身份信息，此種策略為了保證一些關鍵數據的可控性。
異步加載的常用策略是：進入應用內在加載使用的數據，例如進入應用再刷新首頁，這種策略為了提高進入應用的速度。
2、當前頁加載
大部分都是的同步加載，要在當前頁面完成數據加載，才能進入下一頁面。網不好？那就在這呆著吧（；￣ェ￣）。
不過一般會在加載期間顯示一些小動畫，例如小菊花，來減緩用戶等待的阻塞感＝ ＝。
在APP里，一般加載失敗留在當前頁面；而在H5頁面里，一般加載失敗，頁面為空或報錯。
3、下一頁加載
為保證用戶體驗，現在大多數應用都采用下一頁面加載策略，畢竟在當前頁面卡住和在下一頁面卡住是兩種不同的感受哦，用戶心理如是也-_-#，而且網絡差導致頁面加載過慢時，在下一頁加載能一定程度上轉移仇恨，讓用戶感覺進不去界面是因為網絡或者其它原因，而我們（APP）可是在很努力的幫他加載呢，千萬不要怪我們呦～
敲黑板：「下一頁加載不等同于異步加載」
（1）白屏加載
這種就是下一頁加載的同步加載版本，一進入頁面出現一個大白屏，直到加載完成一次性顯示全部頁面。
（2）分步加載
一般我們說的分布加載都是異步加載，但是異步加載不是分布加載，要分清楚包含關系呦～
- 分布加載一般先加載占網絡資源小的元素，隨后再加載圖片、視頻等占大量網絡資源的元素，這種方式多用在大量圖片／視頻的頁面
- 另一種形式是先加載頁面的框架，然后再加載框架里的內容，這種方式多用在頁面元素有層級關系的頁面（例如嵌套），可以保證頁面打開后顯示的格式可控
- 還有一種形式是加載固定數量的item，現在有大量內容的列表頁面的產品，在Feed流頁面普遍使用分布加載，來保證用戶流量和閱讀體驗的平衡
（3）延遲加載
有些內容不是界面初始化的時候就需要的，可能在用戶下一步操作（例如上滑頁面）的時候才會出現的，而這些內容又占用很多的網絡資源（比如圖片、視頻）這時就使用到延遲加載的策略，延遲加載也屬于分步加載。
例如淘寶，用戶瀏覽時只加載當前屏幕的圖片，直至上滑界面使新的圖片進入可視區域時，才會加載新圖片，這樣可以節省用戶流量，同時保證用戶操作的可用性。
（4）預加載
我們和延遲加載對比一下：延遲加載是進入可視區域后才會加載，預加載就是在進入可視區域前加載。
預加載是一種在節省流量和流暢體驗二者中向流暢性優化的例子，理想情況下是使用戶感覺不到內容的加載過程，滑到哪就能看到哪。
5、智能加載
斷網或弱網時，緩存加載策略能有效提升用戶體驗，在頁面中顯示之前緩存在本地的內容，使頁面不至于出現大白屏或者錯誤代碼等。
6、漸進加載
傅立葉變換的實際應用，主要用于高清圖片的加載，在傳輸大圖的過程中，先顯示一個模糊效果，隨著下載數據的增多，逐漸精細圖片的細節，形成一個平滑的加載過程（形成平滑的用戶體驗），最終變成完整分辨率的清晰圖片。
漸進式加載要預先處理圖片和優化應用支持，這有點麻煩，所以有一些替代方案的嘗試，舉例如下：
- 微信的加載方式：先顯示一個小圖／縮略圖，隨后加載完成大圖／高清圖再顯示大圖；
- 傳統的加載方式：圖片從上至下／從左至右顯示完成，類似打印機逐行掃描；
四、界面策略
在UI設計里，關于數據加載的表現形式千變萬化，具體處理方式總結起來大概有以下幾種。諾，你看
1、狀態欄加載
2、導航欄加載
3、白屏加載
簡單粗暴你看是不是？
4、Toast加載
5、進度條加載
6、下拉刷新加載
額外提一下，細膩的下拉動畫是包含下拉加載、釋放加載、正在加載三種狀態的呦～
7、頁面上滑加載
8、全屏加載
白屏加載的變種，加入了用戶體驗的優化，別說效果就是不一樣，在解決問題上的每一點探索都值得尊重，所以我單獨把它列為一類（啟動應用加載也屬于全屏加載）
五、策略組合
如果能看到這里，你一定對技術、交互、和UI三個層面的數據加載解決方案有了大致的了解。非常重要的是，在實際設計中，這三個層次的解決方案是互相交叉組合來匹配具體的應用場景的，使用不同的策略優勢互補，配合解決復雜問題，其目的都是為了更好的用戶體驗或完善業務邏輯。
此處就先不討論具體策略組合來解決場景問題的方案了，希望正在看文章的你也能思考思考，有哪些有意思的策略組合，解決了復雜場景的問題，可以留言我們一起討論交流～
本文從技術、交互、UI三個角度梳理了移動應用數據加載的常見設計模式。但是大家一定要記住，模式只是一些比較成熟的解決方案，在實際設計中不要被模式約束，也不要濫用模式，要深入剖析每個設計模式是在什么環境下為解決什么問題而設計的，明確問題環境的約束，找到合適的妥協點，完成你自己的設計。
關于用戶體驗：文內多次提到用戶體驗，但是因為涉及篇幅太多，而且本篇文章不打算深入聊用戶體驗，所以沒有深入講解，請見諒。
作者：王雪峰，工業設計轉產品經理，奮斗在創業IT公司，擅長用設計思維思考產品問題。
本文由 @王雪峰 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自?Pixabay，基于?CC0?協議
- 目前還沒評論，等你發揮！
