編輯導語：產品設計在任何產品中都是非常重要的，用戶在使用產品時的用戶體驗以及一些交互體驗，都會影響到產品的各方面；在產品頁面中，用戶在等待加載頁面時，也需要合適的設計進行操作；本文作者分享了關于加載功能的原理和設計，我們一起來了解一下。

作為產品設計師，我們設計的功能都會面臨用戶的使用；在用戶使用的過程中會因為使用時長的延長和上次文件等情況，從而產生大量的文件數據，這些文件數據的堆積會讓整個數據庫越發的臃腫，從而造成用戶體驗上的不流暢。

一、狹義和廣義上的加載

狹義上的加載是由用戶體驗和交互動效組成

為什么我會說是狹義上的，因為問起加載，大家首先想到的是頁面上的加載，那種思考用戶體驗和頁面動態的加載，并且我們還會脫口而出：

我們要讓用戶在等待的過程中也有很好用戶的體驗，讓用戶在等待的時候可以感知到我們正在努力加載的情況，這能減緩用戶的焦慮；同時，我們還要順便把加載做的更加有趣，吸引用戶注意力，讓用戶沉浸其中，讓用戶享受等待時刻。

不是說這些內容說的不對，而是因為這些話從UI、UE、UXD等設計師口中說出，我覺得十分正常且合理。因為他們在進行思考，思考如何中感官上提升用戶對我們產品的正向感官；但如果這話從產品經理的口中說出來，那我感覺會感到十分驚艷，因為這比較的忘本逐末了。

上面一長串的回答，是我們大部分人的想法，“狹隘”的從體驗上出發去思考問題，想通過卓越的體驗來緩解用戶焦慮，從而降低跳失率，避免用戶的大量流失。沒有思考和挖掘周圍更多的外在因素，糅合在一起評估思考，所以我說是狹義上的加載。

作為產品設計師，以后是產品經理我們，我們的核心能力應該在于有深度的思考和評估優劣后的決策；我們要從錯綜復雜的問題中抽離問題，通過衡量多方面因素進行評估，再決策出適合當前環境的最優解方案，哪怕這個方案看起來是又瓜又蠢，但這就是我們的核心價值之一。

而廣義上的加載,是除了用戶體驗，交互特效外還有數據、系統耗時組成。

前者我們上面說，加載主要形式體現在動效上。但這里需要補充的是，后者數據上的加載才是真正加載問題的核心。要知道系統加載一條數據和十條數據所花費的時間在我們看來是相似的，這樣低量的數據幾乎可以在0.01秒內就能運算出來。

但是要知道系統數據一般是上萬級別的，讀寫一百萬條數據的時候，我們就能明顯感知到花費的時間大大的增加，這個感知時間增加也就形成了加載。

在理解加載的時候，我們還需要了解數據上的加載屬于后端加載，頁面上的顯示內容的加載就屬于前端的加載了；因為每次讀寫都需要進行時間等到系統反饋，每次頁面內容的顯現，都是內容的緩存，點擊的反饋組合一起的結果，這些都是需要耗時的。這也是我為什么說這是廣義上的加載。

二、常見的加載

因加載刷新實現原理相同，只是文字描述的定義不同，這里我們暫時當成一體看待，如果要區分，也可以認為第一次裝載內容時叫加載，對已裝載的內容進行再次裝載我們叫刷新即可。

1. 全屏

這種加載方式在手機APP中十分常見，但是在PC網頁端不常見（甚至是不用做）。

常見平臺：移動端

優點：完整性好，在對完整性有特殊要求的閱讀類等應用中，使用全屏加載可以很好的保障用戶閱讀內容的完整性。

缺點：在弱網（流量信號弱）、服務器異常（服務器響應時間過長）等情況下，會長時間處于加載狀態。如果未做瀏覽緩存功能，會讓用戶像傻子一樣等著。

2. 拉拽（觸發式）

移動端：

PC端：

優點：比較符合用戶的交互習慣，不管是上拉還是下拉，都屬于用戶正常的操作行為。能夠增加產品的趣味性和“溫度”。

缺點：當用戶操作行為幅度不夠大的時候，不容易觸發當前加載機制。特別是在部分中老年人使用的時候，常常無法正常喚起加載。

當然除了滑動行為觸發的加載，還有就是用戶主動點擊按鈕加載的方式，我將他們統稱為觸發式加載。因為不管是滑動還是點擊都屬于用戶的交互而作出的觸發，因此將他們歸于一類。

3. 骨架

移動端：

PC端：

優點：銜接用戶感官，和真實內容布局相似提升體驗

缺點：研發調試成本高，有可能出現做了效果，但是從來都沒有觸發過。

骨架屏加載常用和自動加載、懶加載以及預加載幾個配合使用。這也照常其實很多人很難區分他們三個的區別，所以簡單的提及一下。

• 骨架加載：正式在加載前，等待后端反饋接口，本地無最新緩存內容后觸發，配合自動加載、懶加載使用。
• 自動加載：監控用戶操作行為進行觸發。如：滑動、點擊等
• 懶加載：通過接口或代碼延遲加載某些內容或符合固定行為進行加載。如：對內容接口拆分處理，根據優先反饋數據進行展示。

4. 自動加載

優點：在網絡暢通情況下，讓用戶對內容的加載無任何感官。抖音、快手的利器之一。

缺點：對部分低流量用戶不太友好，畢竟后臺要偷跑流量。?

在設計的時候可以適當的明確自動加載邊界，是加載后續多少內容。內容是全量標題、圖片、視頻一起全部加載完成，還是低量只是加載標題和骨屏結合懶加載進行顯示。

5. 懶加載（分步驟、漸進加載）

優點：在網絡暢通情況下，讓用戶對大內容都加載有一定的連貫性，適合feel模式（瀑布式）。

缺點：只要技術不拉垮就沒問題，如果拉垮，內容會顯示不全。

再次申明我理解他們是從技術角度進行名詞區分的，如有失誤請諒解。

6. 預加載

這里可能會讓你感覺和上面幾個加載相似沒有什么區別，那是因為他們主要區別在于技術實施上。

這種預加載可以是在加載外部內容列表的時候就已經將所有列表的文字內容進行緩存了。就是在無網絡情況下點擊進入文章也能正常閱讀文字，在閱讀文字的時候進行圖片、視頻的加載（自動加載和懶加載都說的同，只是代碼邏輯不通而已）。

優點：對文字內容產品支撐較好，因為文字對流量、存儲要求較低，后臺偷跑流量很少，幾乎可不記。

7. 多態（異步加載）

這種比較靈活，可以因為需要加載過長，所以強行以為了驗證你的賬戶安全進行驗證，之后在你輸入驗證碼的時間內進行加載。同理還讓你玩游戲等待等。

上面這些內容簡單的列舉了我們常見的加載樣式，接下來我們便深入一丟丟講解下技術上的加載，以便從產品角度解決技術的上問題。

三、后端的加載

我們可以把負責業務能力開發，并將業務數據存儲到數據庫的開發人員統稱為后端開發（研發）。同時數據在展示到頁面之前，都需要通過后端技術手段先從數據提取出數據再通過設計好的邏輯運算得到結果，最后將結果反饋給前端用于頁面呈現，便形成了系統。所以后端是我們認知加載的第一步。

后端開發在寫代碼的時候一定會遵循開發模式進行開發，因為開發工作本就是多人配合的工作，只有大家按照約定成俗的設計規范進行開發，才能相互維護和迭代。雖然也有不遵循的開發，但與我們無關，我們了解一下即可。

后端的開發模式會按照各自負責的模塊進行拆分，分成業務、工具、數據庫、對象和服務等模塊。代碼們根據各自職能做到各司其職，好似流水線工人流水作業。因此，這樣能夠避免出現代碼冗余出現代碼雜亂和耦合，也能有效減少資源浪費和維護困難等問題。

想知道加載時間是多少，只需要計算數據在服務器中花費時間之和就行，這便是所謂的加載時間了。同時，我們還需要分成兩部分來進行認知。一個是系統耗時，另一個是數據庫耗時。

后端系統耗時主要是由于數據要在不同模塊之間扭轉所耗費的時間組成，這類耗時可以說是十分少，但也會出現系統耗時過長的時候，但只要我們確定了問題，很快就能對這部分代碼進行優化從而恢復到最佳效果。

但是還有一種無法優化代碼的情況，那就是產品邏輯上的問題造成的系統耗時增加，這種是優化代碼都無法縮短縮短耗時的，因為修改了就無法實現業務邏輯。所以為了避免出現這種情況，我們在設計產品功能的時候需要注意幾個問題：

1. 預讀緩存、異步處理

在不必要環節使用異步處理作為主選方式，所謂的實時反饋也不一定需要實時處理。例如在設計含有首頁信息的產品，我們可以先讓用戶查閱緩存的內容，這個緩存內容可以是前端緩存（緩存到用戶客戶端上的內容），也可以是后端緩存內容（實現預緩存好的內容）。

因為是瀏覽緩存內容，所有用戶幾乎是感觸不到加載耗時，就算是從后端讀取的緩存內容，這個加載時間也會很短暫，比直接讀取實時數據快捷幾倍。

同時，我們在當用戶瀏覽的時候，我們這是就可以進行前后端的預加載等待用戶的再次加載行為（等待接口的觸發的時候，后端已開始進行相關內容的預加載）。

常見加載場景：預加載、自動加載、懶加載

常見應用場景：電商產品、內容產品

2. 冷熱數據切換

冷熱數據分別是指冷數據和熱數據，冷數據代指固定數據，不會發生變化，不會被其他服務使用的數據。熱數據代指短期內大量被讀寫查詢的數據。

在做產品時會遇見一些奇怪的需求，比如強制需要查看實時數據（老板、投資人需求無法拒絕）。在面對這種需求的時候我們會遇見很多問題。

比如，線上數據在實時讀寫，每秒有大量的數據在寫入，這時提取數據會增加數據庫負載，有可能造成數據庫負載過高影響用戶使用（直接數據庫“爆炸”）。

所以我們在設計功能時，要盡可能對實時數據少用，如果無法避免必須大量使用，那么協調研發復刻數據庫作熱數據向冷數據轉化使用。設計固定周期如30分鐘、1小時，每到固定時間同步一次，將線上實時數據庫或指定數據同步至我們復刻的冷數據庫中以便正常使用。

這個問題也可以用異步的方式出了，比如要使用的時候必須先發起查詢請求，之后等待一定的時間，在等待時間結束后才給結果。

但這種方式實效性比較差，遇見強制要求實時查詢的需求，那么還是冷熱數據切換比較滿足需求（研發：再急也必須等我把數據撈出來啊，不然你來），又或者通過新技術去獲取。

常見加載場景：拉拽加載（觸發式加載）

常見應用場景：ERP、B端產品

3. 避免動態計算數據

我們要知道后端服務是給用戶提供基礎服務能力的，但這種服務能力只是包含少量的計算服務，而非專門作為計算而衍生出的計算服務。

所以我們要盡可能減少數據的計算，避免所展示的內容是需要通過繁重的計算而產生。需要注意的是推薦策略或推薦系統其實也算額外的計算服務，使用他們勢必造成耗時增加，但這種耗時增加屬于可控范圍，同時優勢大于劣勢，所以不必過于排斥。

如果結果卻是需要計算處理，可以通過建立產品矩陣，通過另一條產品線（單獨部署一套服務給他用戶）進行處理，又或者將未處理數據進行導出，讓他人工處理。

還有就是通過熱冷數據轉化后，定時在固定周期內用閑置時間內的服務進行計算（比如每天凌晨人少的時候進行異步計算），計算后再存儲至冷數據庫中，以便直接使用。

常見加載場景：骨架加載

常見應用場景：數據可視化、數據類產品功能

從產品角度來說，能夠從產品角度去優化后端加載的暫時我就了解上面幾種，下面我們接著說從產品角度如何去優化前端的加載。

四、前端的加載

前端的加載耗時更多是技術上的耗時，以產品角度調整功能設計其實比較難以進行優化，，每當你看頁面加載半天不顯示結果的時候去問前端研發。前端常說：

“你去找后端，這是后端的問題。你看我這接口已經請求了，是后端數據沒反過來，所以一直卡在加載…..“

不要以為這是前端開騙你，但確實是事實。因為大部分情況下前端加載時間過長都是因為后端問題造成。所以和研發好好溝通定位問題即可。雖然問題大部分是后端問題，但我們簡單的了解下前端可優化加載速度還是有好處的。

前端主要核心在于效果呈現和用戶交互兩個方面。效果呈現主要是說前端要通過代碼和框架將內容將數據內容可視化成用戶可以理解的畫面，而用戶交互則是將用戶在可視化頁面上的接觸行為轉化成數據交互。

1. 資源整合復用（雪碧圖）

頁面上會有很多icon小圖標和圖片組成，其實單獨一個一個加載這些圖片是十分麻煩的，先不說請求多，其次還會因為加載順序的問題，出現部分icon圖標提前顯示，一部分icon圖標不顯示。

這時可以使用資源整合復用的方式，將很小的icon圖標或小圖，合并成一張大圖，再通過相關技術去識別所需求的小圖能極大的縮減時間。

常見應用場景：移動端app、小程序

2. 分頁預加載

還有我們場景的預加載，懶加載和自動加載等技術，這都屬于前端技術。在數據內容較多時采用分頁、自動加載等形式在用戶瀏覽等間隙進行加載后續內容，等內容加載完成后放置本地緩存，用戶點擊下一頁或滑動時可立即看到頁面內容。

常見應用場景：瀏覽場景下

3. 前后端配合：資源最小化利用

原理很簡單，協調前后端進行約束，在需要加載圖片的地方將高質量圖片轉化成低質量圖片進行展示（原圖1MB，在展示的時候展示20KB低質量版），在需要展示原圖時再暫時原圖。

還有就是約束視頻內容的緩存是在加載頁面的時候進行緩存還是在用戶點擊播放的時候進緩存。這也會影響頁面內容的加載。

五、總結

文章就在這里，其實對于加載技術上還有很多可以說的東西。比如：耗時最嚴重地方其實是數據SQL（數據庫操作語言）查詢方面，要對SQL、索引、表結構進行優化才能減少耗時等。

但我們畢竟不是研發，而且這文章是從產品角度去思考的，大家簡單的了解下就行不用去研究那么多。另外，我不想過多的從技術角度去講解，畢竟我也不太會技術哈哈。

這篇文章的意義在于，我想告訴大家不要一說到加載，只能想到什么加載樣式、用戶體驗的。我們要知道是什么原因造成了這里會加載，這個加載耗時會是多久，能不能優化，能優化該找前端還是后端。

不能優化那么該如何協調其他人從用戶體驗上去改變用戶對我們產品的感官等。畢竟做產品經理容易做產品難，要學的東西太多了，學無止境呀。

作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）

本文由 @Wcof 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議。