編輯導語：產品設計在任何產品中都是非常重要的，用户在使用產品時的用户體驗以及一些交互體驗，都會影響到產品的各方面；在產品頁面中，用户在等待加載頁面時，也需要合適的設計進行操作；本文作者分享了關於加載功能的原理和設計，我們一起來了解一下。
作為產品設計師，我們設計的功能都會面臨用户的使用；在用户使用的過程中會因為使用時長的延長和上次文件等情況，從而產生大量的文件數據，這些文件數據的堆積會讓整個數據庫越發的臃腫，從而造成用户體驗上的不流暢。
一、狹義和廣義上的加載狹義上的加載是由用户體驗和交互動效組成
為什麼我會説是狹義上的，因為問起加載，大家首先想到的是頁面上的加載，那種思考用户體驗和頁面動態的加載，並且我們還會脱口而出：
我們要讓用户在等待的過程中也有很好用户的體驗，讓用户在等待的時候可以感知到我們正在努力加載的情況，這能減緩用户的焦慮；同時，我們還要順便把加載做的更加有趣，吸引用户注意力，讓用户沉浸其中，讓用户享受等待時刻。
不是説這些內容説的不對，而是因為這些話從UI、UE、UXD等設計師口中説出，我覺得十分正常且合理。因為他們在進行思考，思考如何中感官上提升用户對我們產品的正向感官；但如果這話從產品經理的口中説出來，那我感覺會感到十分驚豔，因為這比較的忘本逐末了。
上面一長串的回答，是我們大部分人的想法，“狹隘”的從體驗上出發去思考問題，想通過卓越的體驗來緩解用户焦慮，從而降低跳失率，避免用户的大量流失。沒有思考和挖掘周圍更多的外在因素，糅合在一起評估思考，所以我説是狹義上的加載。
作為產品設計師，以後是產品經理我們，我們的核心能力應該在於有深度的思考和評估優劣後的決策；我們要從錯綜複雜的問題中抽離問題，通過衡量多方面因素進行評估，再決策出適合當前環境的最優解方案，哪怕這個方案看起來是又瓜又蠢，但這就是我們的核心價值之一。
而廣義上的加載,是除了用户體驗，交互特效外還有數據、系統耗時組成。
前者我們上面説，加載主要形式體現在動效上。但這裏需要補充的是，後者數據上的加載才是真正加載問題的核心。要知道系統加載一條數據和十條數據所花費的時間在我們看來是相似的，這樣低量的數據幾乎可以在0.01秒內就能運算出來。
但是要知道系統數據一般是上萬級別的，讀寫一百萬條數據的時候，我們就能明顯感知到花費的時間大大的增加，這個感知時間增加也就形成了加載。
在理解加載的時候，我們還需要了解數據上的加載屬於後端加載，頁面上的顯示內容的加載就屬於前端的加載了；因為每次讀寫都需要進行時間等到系統反饋，每次頁面內容的顯現，都是內容的緩存，點擊的反饋組合一起的結果，這些都是需要耗時的。這也是我為什麼説這是廣義上的加載。
二、常見的加載因加載刷新實現原理相同，只是文字描述的定義不同，這裏我們暫時當成一體看待，如果要區分，也可以認為第一次裝載內容時叫加載，對已裝載的內容進行再次裝載我們叫刷新即可。
1. 全屏這種加載方式在手機APP中十分常見，但是在PC網頁端不常見（甚至是不用做）。
常見平台：移動端
優點：完整性好，在對完整性有特殊要求的閲讀類等應用中，使用全屏加載可以很好的保障用户閲讀內容的完整性。
缺點：在弱網（流量信號弱）、服務器異常（服務器響應時間過長）等情況下，會長時間處於加載狀態。如果未做瀏覽緩存功能，會讓用户像傻子一樣等着。
2. 拉拽（觸發式）移動端：
PC端：
優點：比較符合用户的交互習慣，不管是上拉還是下拉，都屬於用户正常的操作行為。能夠增加產品的趣味性和“温度”。
缺點：當用户操作行為幅度不夠大的時候，不容易觸發當前加載機制。特別是在部分中老年人使用的時候，常常無法正常喚起加載。
當然除了滑動行為觸發的加載，還有就是用户主動點擊按鈕加載的方式，我將他們統稱為觸發式加載。因為不管是滑動還是點擊都屬於用户的交互而作出的觸發，因此將他們歸於一類。
3. 骨架移動端：
PC端：
優點：銜接用户感官，和真實內容佈局相似提升體驗
缺點：研發調試成本高，有可能出現做了效果，但是從來都沒有觸發過。
骨架屏加載常用和自動加載、懶加載以及預加載幾個配合使用。這也照常其實很多人很難區分他們三個的區別，所以簡單的提及一下。
- 骨架加載：正式在加載前，等待後端反饋接口，本地無最新緩存內容後觸發，配合自動加載、懶加載使用。
- 自動加載：監控用户操作行為進行觸發。如：滑動、點擊等
- 懶加載：通過接口或代碼延遲加載某些內容或符合固定行為進行加載。如：對內容接口拆分處理，根據優先反饋數據進行展示。
優點：在網絡暢通情況下，讓用户對內容的加載無任何感官。抖音、快手的利器之一。
缺點：對部分低流量用户不太友好，畢竟後台要偷跑流量。
在設計的時候可以適當的明確自動加載邊界，是加載後續多少內容。內容是全量標題、圖片、視頻一起全部加載完成，還是低量只是加載標題和骨屏結合懶加載進行顯示。
5. 懶加載（分步驟、漸進加載）
優點：在網絡暢通情況下，讓用户對大內容都加載有一定的連貫性，適合feel模式（瀑布式）。
缺點：只要技術不拉垮就沒問題，如果拉垮，內容會顯示不全。
再次申明我理解他們是從技術角度進行名詞區分的，如有失誤請諒解。
6. 預加載
這裏可能會讓你感覺和上面幾個加載相似沒有什麼區別，那是因為他們主要區別在於技術實施上。
這種預加載可以是在加載外部內容列表的時候就已經將所有列表的文字內容進行緩存了。就是在無網絡情況下點擊進入文章也能正常閲讀文字，在閲讀文字的時候進行圖片、視頻的加載（自動加載和懶加載都説的同，只是代碼邏輯不通而已）。
優點：對文字內容產品支撐較好，因為文字對流量、存儲要求較低，後台偷跑流量很少，幾乎可不記。
7. 多態（異步加載）這種比較靈活，可以因為需要加載過長，所以強行以為了驗證你的賬户安全進行驗證，之後在你輸入驗證碼的時間內進行加載。同理還讓你玩遊戲等待等。
上面這些內容簡單的列舉了我們常見的加載樣式，接下來我們便深入一丟丟講解下技術上的加載，以便從產品角度解決技術的上問題。
三、後端的加載我們可以把負責業務能力開發，並將業務數據存儲到數據庫的開發人員統稱為後端開發（研發）。同時數據在展示到頁面之前，都需要通過後端技術手段先從數據提取出數據再通過設計好的邏輯運算得到結果，最後將結果反饋給前端用於頁面呈現，便形成了系統。所以後端是我們認知加載的第一步。
後端開發在寫代碼的時候一定會遵循開發模式進行開發，因為開發工作本就是多人配合的工作，只有大家按照約定成俗的設計規範進行開發，才能相互維護和迭代。雖然也有不遵循的開發，但與我們無關，我們瞭解一下即可。
後端的開發模式會按照各自負責的模塊進行拆分，分成業務、工具、數據庫、對象和服務等模塊。代碼們根據各自職能做到各司其職，好似流水線工人流水作業。因此，這樣能夠避免出現代碼冗餘出現代碼雜亂和耦合，也能有效減少資源浪費和維護困難等問題。
想知道加載時間是多少，只需要計算數據在服務器中花費時間之和就行，這便是所謂的加載時間了。同時，我們還需要分成兩部分來進行認知。一個是系統耗時，另一個是數據庫耗時。
後端系統耗時主要是由於數據要在不同模塊之間扭轉所耗費的時間組成，這類耗時可以説是十分少，但也會出現系統耗時過長的時候，但只要我們確定了問題，很快就能對這部分代碼進行優化從而恢復到最佳效果。
但是還有一種無法優化代碼的情況，那就是產品邏輯上的問題造成的系統耗時增加，這種是優化代碼都無法縮短縮短耗時的，因為修改了就無法實現業務邏輯。所以為了避免出現這種情況，我們在設計產品功能的時候需要注意幾個問題：
1. 預讀緩存、異步處理在不必要環節使用異步處理作為主選方式，所謂的實時反饋也不一定需要實時處理。例如在設計含有首頁信息的產品，我們可以先讓用户查閲緩存的內容，這個緩存內容可以是前端緩存（緩存到用户客户端上的內容），也可以是後端緩存內容（實現預緩存好的內容）。
因為是瀏覽緩存內容，所有用户幾乎是感觸不到加載耗時，就算是從後端讀取的緩存內容，這個加載時間也會很短暫，比直接讀取實時數據快捷幾倍。
同時，我們在當用户瀏覽的時候，我們這是就可以進行前後端的預加載等待用户的再次加載行為（等待接口的觸發的時候，後端已開始進行相關內容的預加載）。
常見加載場景：預加載、自動加載、懶加載
常見應用場景：電商產品、內容產品
2. 冷熱數據切換冷熱數據分別是指冷數據和熱數據，冷數據代指固定數據，不會發生變化，不會被其他服務使用的數據。熱數據代指短期內大量被讀寫查詢的數據。
在做產品時會遇見一些奇怪的需求，比如強制需要查看實時數據（老闆、投資人需求無法拒絕）。在面對這種需求的時候我們會遇見很多問題。
比如，線上數據在實時讀寫，每秒有大量的數據在寫入，這時提取數據會增加數據庫負載，有可能造成數據庫負載過高影響用户使用（直接數據庫“爆炸”）。
所以我們在設計功能時，要儘可能對實時數據少用，如果無法避免必須大量使用，那麼協調研發復刻數據庫作熱數據向冷數據轉化使用。設計固定週期如30分鐘、1小時，每到固定時間同步一次，將線上實時數據庫或指定數據同步至我們復刻的冷數據庫中以便正常使用。
這個問題也可以用異步的方式出了，比如要使用的時候必須先發起查詢請求，之後等待一定的時間，在等待時間結束後才給結果。
但這種方式實效性比較差，遇見強制要求實時查詢的需求，那麼還是冷熱數據切換比較滿足需求（研發：再急也必須等我把數據撈出來啊，不然你來），又或者通過新技術去獲取。
常見加載場景：拉拽加載（觸發式加載）
常見應用場景：ERP、B端產品
3. 避免動態計算數據我們要知道後端服務是給用户提供基礎服務能力的，但這種服務能力只是包含少量的計算服務，而非專門作為計算而衍生出的計算服務。
所以我們要儘可能減少數據的計算，避免所展示的內容是需要通過繁重的計算而產生。需要注意的是推薦策略或推薦系統其實也算額外的計算服務，使用他們勢必造成耗時增加，但這種耗時增加屬於可控範圍，同時優勢大於劣勢，所以不必過於排斥。
如果結果卻是需要計算處理，可以通過建立產品矩陣，通過另一條產品線（單獨部署一套服務給他用户）進行處理，又或者將未處理數據進行導出，讓他人工處理。
還有就是通過熱冷數據轉化後，定時在固定週期內用閒置時間內的服務進行計算（比如每天凌晨人少的時候進行異步計算），計算後再存儲至冷數據庫中，以便直接使用。
常見加載場景：骨架加載
常見應用場景：數據可視化、數據類產品功能
從產品角度來説，能夠從產品角度去優化後端加載的暫時我就瞭解上面幾種，下面我們接着説從產品角度如何去優化前端的加載。
四、前端的加載前端的加載耗時更多是技術上的耗時，以產品角度調整功能設計其實比較難以進行優化，，每當你看頁面加載半天不顯示結果的時候去問前端研發。前端常説：
“你去找後端，這是後端的問題。你看我這接口已經請求了，是後端數據沒反過來，所以一直卡在加載…..“
不要以為這是前端開騙你，但確實是事實。因為大部分情況下前端加載時間過長都是因為後端問題造成。所以和研發好好溝通定位問題即可。雖然問題大部分是後端問題，但我們簡單的瞭解下前端可優化加載速度還是有好處的。
前端主要核心在於效果呈現和用户交互兩個方面。效果呈現主要是説前端要通過代碼和框架將內容將數據內容可視化成用户可以理解的畫面，而用户交互則是將用户在可視化頁面上的接觸行為轉化成數據交互。
1. 資源整合複用（雪碧圖）頁面上會有很多icon小圖標和圖片組成，其實單獨一個一個加載這些圖片是十分麻煩的，先不説請求多，其次還會因為加載順序的問題，出現部分icon圖標提前顯示，一部分icon圖標不顯示。
這時可以使用資源整合複用的方式，將很小的icon圖標或小圖，合併成一張大圖，再通過相關技術去識別所需求的小圖能極大的縮減時間。
常見應用場景：移動端app、小程序
還有我們場景的預加載，懶加載和自動加載等技術，這都屬於前端技術。在數據內容較多時採用分頁、自動加載等形式在用户瀏覽等間隙進行加載後續內容，等內容加載完成後放置本地緩存，用户點擊下一頁或滑動時可立即看到頁面內容。
常見應用場景：瀏覽場景下
3. 前後端配合：資源最小化利用原理很簡單，協調前後端進行約束，在需要加載圖片的地方將高質量圖片轉化成低質量圖片進行展示（原圖1MB，在展示的時候展示20KB低質量版），在需要展示原圖時再暫時原圖。
還有就是約束視頻內容的緩存是在加載頁面的時候進行緩存還是在用户點擊播放的時候進緩存。這也會影響頁面內容的加載。
五、總結文章就在這裏，其實對於加載技術上還有很多可以説的東西。比如：耗時最嚴重地方其實是數據SQL（數據庫操作語言）查詢方面，要對SQL、索引、表結構進行優化才能減少耗時等。
但我們畢竟不是研發，而且這文章是從產品角度去思考的，大家簡單的瞭解下就行不用去研究那麼多。另外，我不想過多的從技術角度去講解，畢竟我也不太會技術哈哈。
這篇文章的意義在於，我想告訴大家不要一説到加載，只能想到什麼加載樣式、用户體驗的。我們要知道是什麼原因造成了這裏會加載，這個加載耗時會是多久，能不能優化，能優化該找前端還是後端。
不能優化那麼該如何協調其他人從用户體驗上去改變用户對我們產品的感官等。畢竟做產品經理容易做產品難，要學的東西太多了，學無止境呀。
作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）
本文由 @Wcof 原創發佈於人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CC0協議。