本文共5280字，預計閱讀20分鐘

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

狹義和廣義上的加載

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

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

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

Emmm....

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

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

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

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

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

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

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

常見的加載

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

1、全屏

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

常見平臺：移動端

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

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

2、拉拽（觸發(fā)式）

移動端：

PC端：

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

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

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

3、骨架

移動端：

PC端：

優(yōu)點：銜接用戶感官，和真實內(nèi)容布局相似提升體驗

缺點：研發(fā)調(diào)試成本高，有可能出現(xiàn)做了效果，但是從來都沒有觸發(fā)過。

骨架屏加載常用和自動加載、懶加載以及預加載幾個配合使用。這也照常其實很多人很難區(qū)分他們?nèi)齻€的區(qū)別，所以簡單的提及一下。

骨架加載：正式在加載前，等待后端反饋接口，本地無最新緩存內(nèi)容后觸發(fā)，配合自動加載、懶加載使用。

自動加載：監(jiān)控用戶操作行為進行觸發(fā)。如：滑動、點擊等

懶加載：通過接口或代碼延遲加載某些內(nèi)容或符合固定行為進行加載。如：對內(nèi)容接口拆分處理，根據(jù)優(yōu)先反饋數(shù)據(jù)進行展示。

4、自動加載

優(yōu)點：在網(wǎng)絡暢通情況下，讓用戶對內(nèi)容的加載無任何感官。抖音、快手的利器之一。

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

在設計的時候可以適當?shù)拿鞔_自動加載邊界，是加載后續(xù)多少內(nèi)容。內(nèi)容是全量標題、圖片、視頻一起全部加載完成，還是低量只是加載標題和骨屏結(jié)合懶加載進行顯示。

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

優(yōu)點：在網(wǎng)絡暢通情況下，讓用戶對大內(nèi)容都加載有一定的連貫性，適合feel模式（瀑布式）。

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

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

6、預加載

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

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

優(yōu)點：對文字內(nèi)容產(chǎn)品支撐較好，因為文字對流量、存儲要求較低，后臺偷跑流量很少，幾乎可不記。

7、多態(tài)（異步加載）

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

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

后端的加載

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

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

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

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

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

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

1、預讀緩存、異步處理

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

因為是瀏覽緩存內(nèi)容，所有用戶幾乎是感觸不到加載耗時，就算是從后端讀取的緩存內(nèi)容，這個加載時間也會很短暫，比直接讀取實時數(shù)據(jù)快捷幾倍。同時，我們在當用戶瀏覽的時候，我們這是就可以進行前后端的預加載等待用戶的再次加載行為（等待接口的觸發(fā)的時候，后端已開始進行相關內(nèi)容的預加載）。

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

常見應用場景：電商產(chǎn)品、內(nèi)容產(chǎn)品

2、冷熱數(shù)據(jù)切換

冷熱數(shù)據(jù)分別是指冷數(shù)據(jù)和熱數(shù)據(jù)，冷數(shù)據(jù)代指固定數(shù)據(jù)，不會發(fā)生變化，不會被其他服務使用的數(shù)據(jù)。熱數(shù)據(jù)代指短期內(nèi)大量被讀寫查詢的數(shù)據(jù)。

在做產(chǎn)品時會遇見一些奇怪的需求，比如強制需要查看實時數(shù)據(jù)（老板、投資人需求無法拒絕）。在面對這種需求的時候我們會遇見很多問題。比如，線上數(shù)據(jù)在實時讀寫，每秒有大量的數(shù)據(jù)在寫入，這時提取數(shù)據(jù)會增加數(shù)據(jù)庫負載，有可能造成數(shù)據(jù)庫負載過高影響用戶使用（直接數(shù)據(jù)庫“爆炸”）。

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

這個問題也可以用異步的方式出了，比如要使用的時候必須先發(fā)起查詢請求，之后等待一定的時間，在等待時間結(jié)束后才給結(jié)果。但這種方式實效性比較差，遇見強制要求實時查詢的需求，那么還是冷熱數(shù)據(jù)切換比較滿足需求（研發(fā)：再急也必須等我把數(shù)據(jù)撈出來啊，不然你來），又或者通過新技術去獲取。

常見加載場景：拉拽加載（觸發(fā)式加載）

常見應用場景：ERP、B端產(chǎn)品

3、避免動態(tài)計算數(shù)據(jù)

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

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

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

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

常見加載場景：骨架加載

常見應用場景：數(shù)據(jù)可視化、數(shù)據(jù)類產(chǎn)品功能

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

前端的加載

前端的加載耗時更多是技術上的耗時，以產(chǎn)品角度調(diào)整功能設計其實比較難以進行優(yōu)化，，每當你看頁面加載半天不顯示結(jié)果的時候去問前端研發(fā)。前端常說：

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

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

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

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

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

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

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

2、分頁預加載

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

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

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

原理很簡單，協(xié)調(diào)前后端進行約束，在需要加載圖片的地方將高質(zhì)量圖片轉(zhuǎn)化成低質(zhì)量圖片進行展示（原圖1MB，在展示的時候展示20KB低質(zhì)量版），在需要展示原圖時再暫時原圖。

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

總結(jié)

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

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

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

不能優(yōu)化那么該如何協(xié)調(diào)其他人從用戶體驗上去改變用戶對我們產(chǎn)品的感官等。畢竟做產(chǎn)品經(jīng)理容易做產(chǎn)品難，要學的東西太多了，學無止境呀。

- END -

接受不完美的自己，學習需要慢慢來。

作者：wcof，在努力做產(chǎn)品不做產(chǎn)品經(jīng)理的人