2022-1-6 鶴鶴
先看目錄，大家按需取用，當(dāng)然更建議全文閱讀（全文7756字，建議閱讀20分鐘）
大部分設(shè)計(jì)師應(yīng)該都遇到過這種場景：在做設(shè)計(jì)前并沒有考慮到加載，但在進(jìn)行還原度走查或者驗(yàn)收的時(shí)候才發(fā)現(xiàn)，由于某些頁面數(shù)據(jù)請(qǐng)求較慢，導(dǎo)致在頁面中會(huì)出現(xiàn)空屏狀態(tài)。這時(shí)才想起需要在這些頁面添加動(dòng)畫來承載頁面的過渡。
歸根結(jié)底是因?yàn)樵O(shè)計(jì)師在設(shè)計(jì)過程中，更多關(guān)注頁面本身，而很少去思考頁面在呈現(xiàn)過程中何時(shí)會(huì)出現(xiàn)白屏狀態(tài)，都是后知后覺去補(bǔ)充完善。加載作為必備的一環(huán)，卻總是被忽略。目前很多B端產(chǎn)品在這方面都沒有一個(gè)系統(tǒng)合理的規(guī)劃，導(dǎo)致系統(tǒng)的加載體驗(yàn)缺失或者不統(tǒng)一。
因此希望這篇文章能夠講清楚中后臺(tái)加載出現(xiàn)的場景和規(guī)則，對(duì)需要深入了解加載以及在制定加載規(guī)則的設(shè)計(jì)師朋友們帶來一些幫助。
加載通俗來講就是用戶從觸發(fā)頁面操作，到頁面最終呈現(xiàn)的一個(gè)等待過程。這個(gè)過程始終存在不可避免，只是時(shí)間有快有慢。快的加載只需要幾百毫秒就結(jié)束，但慢的加載就可能會(huì)達(dá)到幾秒甚至十幾秒，讓人產(chǎn)生焦慮。
而為什么會(huì)有如此大的差距，這就需要從頁面渲染的整體過程來進(jìn)行說明。當(dāng)我們從瀏覽器輸入網(wǎng)址，再到我們看到完整頁面的這個(gè)過程，網(wǎng)頁到底經(jīng)過了哪些步驟呢。經(jīng)過資料查詢和與前端確認(rèn)，整體過程可以闡述如下：
從這里我們可以看到頁面的呈現(xiàn)是程序經(jīng)過了一系列操作才最終呈現(xiàn)到我們面前的。在這里可以將其簡化為四個(gè)階段：用戶操作功能→頁面向服務(wù)器發(fā)送請(qǐng)求→服務(wù)器接受并返回?cái)?shù)據(jù)→頁面呈現(xiàn)。
而決定整個(gè)頁面加載快慢的就在于請(qǐng)求與數(shù)據(jù)這里。一般我們可以將頁面的數(shù)據(jù)分為2種類型：靜態(tài)資源和動(dòng)態(tài)資源。
靜態(tài)資源：前端的固定頁面，這里面包含HTML、CSS、JS、圖片等等，不需要查數(shù)據(jù)庫也不需要程序處理，直接就能夠顯示的頁面。可以簡單理解為你頁面上的固定字段和結(jié)構(gòu)。這種頁面一般加載速度比較快，比如我們看到的展示型官網(wǎng)一般都是前端寫好的靜態(tài)資源。
動(dòng)態(tài)資源：而對(duì)于頁面上的動(dòng)態(tài)變化的，需要程序處理或者從數(shù)據(jù)庫中讀數(shù)據(jù)，能根據(jù)不同的條件在頁面顯示不同的數(shù)據(jù)，比如表格數(shù)據(jù)、統(tǒng)計(jì)數(shù)據(jù)等稱為動(dòng)態(tài)資源，這種都需要調(diào)用后臺(tái)接口來進(jìn)行返回，因此加載速度相比于靜態(tài)資源就會(huì)更慢。
而它們的區(qū)分點(diǎn)用下圖可以表示：
可以看到靜態(tài)資源基本是直接返回，而動(dòng)態(tài)資源還需要連接數(shù)據(jù)庫調(diào)取資源，尤其是在遇到數(shù)據(jù)庫調(diào)取較慢時(shí)就會(huì)花費(fèi)更多時(shí)間。而我們加載緩慢的大多數(shù)問題，也基本上更多出現(xiàn)在動(dòng)態(tài)資源的獲取上。
當(dāng)我們清楚加載形成的原因，接下來要做的就是在需要加載的地方對(duì)其進(jìn)行處理。這也是在設(shè)計(jì)過程中我們經(jīng)常遺漏的地方。我們先看一下目前常見的2種處理方式：「默認(rèn)處理」和「使用進(jìn)度指示器」
當(dāng)我們對(duì)加載過程不進(jìn)行任何處理時(shí)，程序就會(huì)以默認(rèn)的方式進(jìn)行-即根據(jù)資源獲取速度一步步呈現(xiàn)。可以看到嘿店后臺(tái)的處理過程就是一種默認(rèn)處理方式：
但是這種做法就會(huì)導(dǎo)致我們?cè)陧撁婕虞d過程中會(huì)出現(xiàn)空屏狀態(tài)，比如上圖切換到概覽時(shí)出現(xiàn)了空屏狀態(tài)，尤其是當(dāng)遇到了網(wǎng)絡(luò)緩慢的情況，會(huì)造成在加載時(shí)頁面停留在當(dāng)前狀態(tài)下不動(dòng)，往往會(huì)讓用戶陷入到「系統(tǒng)故障」的錯(cuò)覺。
這個(gè)名詞說起來可能比較陌生，它指代的就是我們平時(shí)經(jīng)常看到的加載動(dòng)畫、骨架屏或者進(jìn)度條等。進(jìn)度指示器的作用就是告知用戶當(dāng)前頁面并沒有故障，而是正在讀取數(shù)據(jù)。
通過添加進(jìn)度指示器來對(duì)空屏狀態(tài)進(jìn)行承載，能夠減輕用戶的焦慮感。目前很多B端產(chǎn)品更通用的形式是添加動(dòng)畫來過渡。
但是在體驗(yàn)過程中很容易發(fā)現(xiàn)一個(gè)問題，就是在產(chǎn)品的整體加載過程中，某些空屏狀態(tài)是沒被加載動(dòng)畫覆蓋到的。當(dāng)這些沒被覆蓋到的加載過程過長時(shí)，很容易出現(xiàn)焦慮感。比如神策數(shù)據(jù)在左側(cè)列表切換時(shí)的加載過程就沒被覆蓋：
想要更全面的把加載動(dòng)畫覆蓋到所有頁面，我們就需要弄清頁面在哪些狀態(tài)下會(huì)出現(xiàn)空屏狀態(tài)，從而制定統(tǒng)一的加載動(dòng)畫規(guī)則。這個(gè)問題可以先思考一下，后面解答。
在制定統(tǒng)一加載規(guī)則之前，我們需要明確一個(gè)概念，就是加載的模態(tài)與非模態(tài)。
模態(tài)加載的含義就是當(dāng)前加載會(huì)中斷用戶其余操作，用戶在這個(gè)期間只能等待加載而不能進(jìn)行其他操作（有的模態(tài)會(huì)提供取消按鈕）。如果你的頁面涉及到以下2種情況，可以考慮使用：
1.用戶當(dāng)前的操作本身不能與其他操作同時(shí)進(jìn)行。比如系統(tǒng)更新，或者工具類的導(dǎo)入導(dǎo)出相關(guān)操作，我們只能等待更新、導(dǎo)出完成才能繼續(xù)進(jìn)行后續(xù)的操作。這時(shí)候可以使用模態(tài)加載來承載，比如protopie的導(dǎo)入操作；
2.當(dāng)用戶進(jìn)入到一個(gè)全新的頁面時(shí)，這個(gè)時(shí)候頁面什么都沒有，我們只能等待頁面加載完成才能進(jìn)行后續(xù)的操作，因此在這種情況下也可以采用模態(tài)加載，比如我們剛進(jìn)入Asanan產(chǎn)品頁面看到的首屏加載動(dòng)畫：
除了上述2種情況外，你也可以根據(jù)你的業(yè)務(wù)場景來進(jìn)行模態(tài)加載的選擇，但建議是盡量少用模態(tài)加載，其會(huì)對(duì)用戶的打斷和干擾性比較強(qiáng)。
非模態(tài)加載的話，這種加載通常只會(huì)出現(xiàn)在需要加載的部分，不會(huì)中斷用戶其他操作。對(duì)用戶干擾比較小。比如我們常見的功能切換加載、數(shù)據(jù)篩選加載等都屬于非模態(tài)加載。
非模態(tài)加載相比于模態(tài)加載會(huì)更輕量，因?yàn)橛脩綦S時(shí)都可以打斷也不會(huì)影響到其他操作。因此建議在大部分情況下都可以使用非模態(tài)彈窗來進(jìn)行承載，比如飛書的左側(cè)欄切換操作：
接下來我們進(jìn)入正題，在這里我從加載的角度將網(wǎng)頁整體加載過程分為呈現(xiàn)加載規(guī)則和操作加載規(guī)則。
我們先談頁面呈現(xiàn)規(guī)則。前面已經(jīng)明確加載產(chǎn)生的原因和類型后，我們就可以開始為我們的產(chǎn)品制定統(tǒng)一的加載規(guī)則，以保證后續(xù)頁面加載的一致性。
在拆解頁面的加載過程前，我們進(jìn)一步闡述之前提到的渲染原則，從前文中提到最后會(huì)經(jīng)過「解碼」和「渲染」2個(gè)步驟，這也是決定了我們看到的頁面的最終呈現(xiàn)順序：
我們看到的頁面是由HTML、CSS和JavaScript來進(jìn)行構(gòu)成的。HTML可以看作最簡單的框架、CSS則是賦予了框架樣式，JavaScript則是負(fù)責(zé)頁面中的交互(當(dāng)然JS也可以控制樣式，這里只描述主要功能)。
頁面在「解碼」階段，拿到的HTML文檔會(huì)被解碼為DOM樹，同時(shí)將CSS文件解析成CSSOM，這兩者結(jié)合后一起渲染頁面，JS一般是在最后渲染。所以邏輯上就是框架和樣式一起渲染，最后渲染交互。視覺的角度來講就是先看到元素樣式，然后才能進(jìn)行對(duì)應(yīng)操作。
由于瀏覽器渲染順序一般會(huì)根據(jù)代碼的順序進(jìn)行渲染，而代碼在頁面中的構(gòu)建一般也是按照頁面的上下和左右的順序去寫的，因此我們看到的頁面的視覺呈現(xiàn)順序也是遵循從上到下，從左到右。
所以幾乎所有的產(chǎn)品都是先看到頂欄，然后左側(cè)邊欄，然后其他內(nèi)容。因此我們可以通過這個(gè)原則來拆解對(duì)應(yīng)的頁面，我們按照頁面常規(guī)結(jié)構(gòu)可以將其分為三個(gè)加載部分：頂欄、左側(cè)導(dǎo)航欄、內(nèi)容區(qū)域。而其加載順序如圖所示：
當(dāng)知道對(duì)應(yīng)頁面的渲染順序后，我們就能夠清楚在頁面渲染的過程中哪些地方會(huì)出現(xiàn)空屏了。因此將頁面加載過程拆解為如下順序：
我們的加載動(dòng)畫需要承載的就是上述這些白屏的地方，從而將加載細(xì)化為三種場景的拆分：全局加載+局部加載+內(nèi)部加載。如圖所示：
通過這三種加載就可以涵蓋頁面所涉及到的所有部分。接下來詳細(xì)闡述一下這三種類型的定義和用法。
如上圖所示，全局加載的目的是為了覆蓋用戶從輸入網(wǎng)址到頁面的資源渲染的這個(gè)中間過程的空屏狀態(tài)而存在的。而這種狀態(tài)會(huì)涉及三種場景：
1.通過網(wǎng)址進(jìn)入到一個(gè)新的頁面時(shí)；
2.通過鼠標(biāo)右鍵或網(wǎng)頁刷新按鈕對(duì)該頁面刷新時(shí)；
3.通過頁面操作需要新開頁面時(shí)。
該全局加載的動(dòng)畫構(gòu)成為：
1：覆蓋整個(gè)頁面的加載，由純白色+加載動(dòng)畫構(gòu)成；
2：加載類型為模態(tài)加載，因?yàn)橛脩粼谶@種頁面狀態(tài)下并不能進(jìn)行其它操作。
但在這里我們需要注意全局加載的開始和結(jié)束時(shí)間：
開始時(shí)間：當(dāng)進(jìn)入頁面時(shí)立即呈現(xiàn)加載動(dòng)畫；
結(jié)束時(shí)間：當(dāng)頁面加載出頂欄的時(shí)候，此時(shí)停止加載。
為何要這么處理結(jié)束時(shí)間，原因其實(shí)圖中已經(jīng)給出了。這里再解釋一下原則：只要有頁面資源返回，我們的全局加載動(dòng)畫就會(huì)結(jié)束，隨后啟用局部加載來承接后續(xù)的狀態(tài)，避免用戶在當(dāng)前狀態(tài)長時(shí)間等待。而頂欄在一般情況下都是最先加載出來的，所以以頂欄出現(xiàn)作為結(jié)束全局加載的標(biāo)準(zhǔn)。當(dāng)然如果你的結(jié)構(gòu)沒有頂欄，可以以左側(cè)欄來作為結(jié)束標(biāo)準(zhǔn)。
局部加載是用在頁面整體框架加載的過程中，承接在全局加載后。局部加載的使用場景可以概括如下：
1.頂欄加載結(jié)束后，用在剩余框架的加載效果（具體體現(xiàn)為左側(cè)邊欄和右側(cè)內(nèi)容區(qū)域）；
2.對(duì)于涉及到局部頁面的切換操作都會(huì)進(jìn)行局部加載（比如左側(cè)邊欄的切換）；
光看文字可能不是特別清晰，在這里可以舉一個(gè)動(dòng)態(tài)的例子來幫助理解：
上述展示的是在頁面呈現(xiàn)的時(shí)候一個(gè)完整的局部加載。在這里需要注意的是我們首次渲染和第二次渲染在加載動(dòng)畫上是可以有區(qū)分的，可以通過程序控制讓這種加載動(dòng)畫只在初次加載時(shí)出現(xiàn)。
第一次加載時(shí)出現(xiàn)是因?yàn)槲覀冃枰屑虞d動(dòng)畫來承接框架首次加載的空屏?xí)r間：
但第二次的時(shí)候由于有緩存（緩存會(huì)加載我們的靜態(tài)資源，能夠讓我們的頁面框架在第二次時(shí)更快顯示），這樣在讀取框架時(shí)基本不需要加載，我們就可以通過程序來直接去掉其中的局部加載動(dòng)畫，直接顯示框架來進(jìn)行呈現(xiàn)。
目前在飛書和釘釘?shù)菳端產(chǎn)品后臺(tái)均采用了這種處理方式。可以看到圖中我在第一次切換到角色管理時(shí)是有碰撞小球的局部動(dòng)畫存在的，而第二次再次進(jìn)入時(shí)則直接出現(xiàn)框架。這樣既能夠保證加載動(dòng)畫能夠覆蓋所有的空屏狀態(tài)，又避免了局部加載動(dòng)畫的頻繁出現(xiàn)。
內(nèi)部加載是用在頁面內(nèi)部不同模塊數(shù)據(jù)間的加載。當(dāng)框架都已經(jīng)加載結(jié)束，但某些數(shù)據(jù)由于接口比較慢，此時(shí)還沒有返回，這時(shí)我們就可以用內(nèi)部加載來進(jìn)行承載。這應(yīng)該是我們更常見的加載情況：
在進(jìn)行內(nèi)部加載的時(shí)候，需要注意，內(nèi)部加載的時(shí)候一般標(biāo)題是存在的，因?yàn)闃?biāo)題基本都是固定的，所以能夠很快被拉取。比如Zoho的內(nèi)部加載，加載時(shí)標(biāo)題已經(jīng)出現(xiàn)了：
通過這三種類型的加載，能夠覆蓋從用戶輸入網(wǎng)址，到頁面渲染完成這個(gè)頁面呈現(xiàn)過程中的全部加載場景。
說完頁面的呈現(xiàn)規(guī)則，再談頁面操作加載規(guī)則。頁面的操作其實(shí)對(duì)應(yīng)的是頁面控件的反饋。而我們的常用的控件比如有按鈕、tab切換等。我們不僅需要考慮控件本身的加載狀態(tài)，而且需要考慮到控件影響的其他頁面范圍。
控件的加載并不是隨時(shí)都需要，我們要根據(jù)實(shí)際的數(shù)據(jù)量大小及業(yè)務(wù)場景來選擇性使用。目前我們需要考慮的控件及其加載狀態(tài)主要有如下：
比如圖中的按鈕的加載狀態(tài)是必備的，在很多場景下都會(huì)用到。但是下拉列表和級(jí)聯(lián)列表，在一般的場景下都不太需要進(jìn)行加載，當(dāng)遇到列表中的數(shù)據(jù)特別多或者調(diào)取特別慢時(shí)就可以考慮為其加上加載狀態(tài)。
這種控件比如日期篩選、表格篩選或者保存等操作，當(dāng)你切換篩選條件后所有與其相關(guān)的頁面元素都會(huì)發(fā)生變化。在這種情況下我們需要考慮到被影響元素的狀態(tài)。目前的設(shè)計(jì)實(shí)現(xiàn)上有兩種做法：
1.被影響元素不可被操作，且該區(qū)域有遮罩+加載動(dòng)畫來覆蓋；
2.被影響元素可進(jìn)行操作，無任何動(dòng)畫，但操作并不會(huì)影響之前提交的結(jié)果；
這兩種方案一種是利用遮罩防止用戶無效操作，另一種則是保持了足夠的操作自由性。個(gè)人在這里更傾向于處理方式1，我認(rèn)為被影響的元素是需要有遮罩+動(dòng)畫的，來避免用戶在加載期間對(duì)其進(jìn)行無效操作，比如示例中方案2后面修改的名稱是沒有被系統(tǒng)保存的。
需要注意的是如果在產(chǎn)品中使用方案1，我們的遮罩區(qū)域只需要覆蓋被影響的元素就可以了（保存這種可以將按鈕一起覆蓋），比如通過篩選導(dǎo)致圖表數(shù)據(jù)發(fā)生變化，這時(shí)只需覆蓋圖表區(qū)域，而不用覆蓋篩選區(qū)域。這樣的好處是當(dāng)某些篩選數(shù)據(jù)出現(xiàn)加載過慢問題時(shí)，用戶可以通過切換篩選項(xiàng)來打斷當(dāng)前加載。
上述描述的操作都是針對(duì)于當(dāng)前頁加載。當(dāng)控件導(dǎo)致頁面刷新或者跳轉(zhuǎn)時(shí)，則整體遵照頁面呈現(xiàn)的規(guī)則進(jìn)行加載。
上面闡述的加載已經(jīng)完全能夠覆蓋我們頁面整體的加載，但是還是需要提及一下骨架屏和進(jìn)度條這兩種加載形式。
先說骨架屏。實(shí)際上骨架屏的使用效果體驗(yàn)是優(yōu)于加載動(dòng)畫的體驗(yàn)的（骨架屏的加入使用會(huì)讓用戶感覺網(wǎng)頁出現(xiàn)的更快）。那么為什么在大部分的B端業(yè)務(wù)頁面中沒被用到呢，主要有2點(diǎn)原因：
1.每種骨架屏都需要進(jìn)行對(duì)應(yīng)的定制開發(fā)，需要與加載后的頁面框架保持一致，這會(huì)增加了開發(fā)成本。
2.中后臺(tái)的業(yè)務(wù)界面對(duì)來說固定結(jié)構(gòu)的頁面會(huì)較少，這對(duì)于骨架屏的使用機(jī)會(huì)就相對(duì)較少。
個(gè)人認(rèn)為在前期可以以統(tǒng)一加載體驗(yàn)為主，在后期業(yè)務(wù)相對(duì)成熟后，可以針對(duì)固定結(jié)構(gòu)，通過骨架屏的使用優(yōu)化加載體驗(yàn)。
再說進(jìn)度條。我理解的進(jìn)度條的使用條件：對(duì)于加載時(shí)間較長的規(guī)定場景可以考慮用進(jìn)度條來承載，比如我們常見的游戲加載中進(jìn)度條就用得比較多，因?yàn)橛螒蛞话阗Y源比較大。還比如figma在進(jìn)入設(shè)計(jì)文件的過程中也采用了進(jìn)度條加載也是因?yàn)樵O(shè)計(jì)文件可能會(huì)很大。
進(jìn)度條在特定場景下能夠緩解用戶焦慮，讓用戶知道進(jìn)展。但進(jìn)度條在多數(shù)情況下都抓取不到程序的真實(shí)進(jìn)度，這也會(huì)導(dǎo)致有時(shí)候我們看著加載到99%，那最后的1%遲遲加載不出來的的原因。目前很多中后臺(tái)產(chǎn)品對(duì)于進(jìn)度條加載使用相對(duì)較少的原因，很大程度是沒有那種加載特別長的場景。
因此這兩種加載場景的使用會(huì)更加定制化，如果需要使用請(qǐng)根據(jù)具體的業(yè)務(wù)場景來進(jìn)行選擇。
如果把加載動(dòng)畫等比作頁面加載的外在，那么緩存和加載策略則是頁面加載的內(nèi)核，合理使用緩存和加載策略可以從根本上提升我們頁面的加載速度，讓用戶更快速地看到頁面。
大家肯定聽過緩存這個(gè)概念，前后端都可以使用緩存。緩存就是數(shù)據(jù)交換的緩沖區(qū)（稱作Cache），是存貯數(shù)據(jù)（使用頻繁的數(shù)據(jù)）的臨時(shí)地方。在這里主要講一下瀏覽器緩存：
從這張圖可以看出，服務(wù)器在請(qǐng)求數(shù)據(jù)時(shí)，會(huì)進(jìn)行緩存的判斷，如果有緩存則首先讀取緩存，如果沒有則從服務(wù)器中拿取。調(diào)取緩存會(huì)在很大程度上提升頁面的加載速度，縮短了從服務(wù)獲取數(shù)據(jù)的時(shí)間。通常瀏覽器會(huì)主動(dòng)對(duì)頁面的靜態(tài)資源進(jìn)行對(duì)應(yīng)的緩存，這也就解釋了我們第二次進(jìn)入頁面會(huì)比初次進(jìn)入頁面時(shí)加載快的原因。
但程序其實(shí)也可以對(duì)動(dòng)態(tài)資源（也就是需要從數(shù)據(jù)庫等拿到的資源）進(jìn)行緩存的，并且可以設(shè)置緩存的過期時(shí)間（比如設(shè)置過期時(shí)間為1小時(shí)，那么1小時(shí)過后就會(huì)重新拉取新資源）。對(duì)于某些動(dòng)態(tài)資源拉取過慢并且更新頻率不高的我們可以采用動(dòng)態(tài)資源緩存的策略，從而提升整體的頁面加載體驗(yàn)。
現(xiàn)階段我們常用的主要有下列6種加載策略：
加載策略的本質(zhì)就是通過對(duì)應(yīng)的加載設(shè)置來縮短產(chǎn)品與服務(wù)器交換數(shù)據(jù)的時(shí)間，接下來我們?cè)敿?xì)看一下每種加載策略的具體使用策略：
懶加載是當(dāng)內(nèi)容落入視窗被用戶看到時(shí)，才會(huì)進(jìn)行加載。這種比較節(jié)省資源和減輕服務(wù)器壓力。對(duì)于當(dāng)前頁面內(nèi)容很多的可以采用這種加載策略。而這種加載策略的設(shè)計(jì)，能夠讓用戶更快看到當(dāng)前屏幕內(nèi)的內(nèi)容，減少等待時(shí)間。
比如蘋果官網(wǎng)的加載策略就采取了這樣的一種方式。我們可以看到右側(cè)的資源只有在我們向下滾動(dòng)出現(xiàn)在屏幕中時(shí)才會(huì)進(jìn)行對(duì)應(yīng)的加載，這樣能夠保證用戶在進(jìn)入網(wǎng)頁第一時(shí)間看到首屏內(nèi)容，并且用戶幾乎感知不到這種加載延遲。
預(yù)加載是在頁面空閑的時(shí)候就把用戶即將用到的資源加載完存到緩存中，等用戶需要使用時(shí)，通過緩存直接調(diào)用呈現(xiàn)。比如用戶在看A頁面的時(shí)候，就可以通過預(yù)加載來準(zhǔn)備用戶需要的B頁面資源。當(dāng)用戶需要B頁面的時(shí)候，立刻就可以呈現(xiàn)。
比如某些頁面在實(shí)際中加載比較慢，這個(gè)時(shí)候就可以考慮是否用預(yù)加載的策略來提升網(wǎng)頁整體加載速度。比如知乎的視頻和文字在都進(jìn)行了對(duì)應(yīng)的預(yù)加載。即使當(dāng)你處于斷網(wǎng)狀態(tài)（圖中我將頁面網(wǎng)絡(luò)切換為斷開狀態(tài)），可以看到依舊可以點(diǎn)擊全文進(jìn)行查看和視頻的部分預(yù)覽。
當(dāng)頁面中有文字和圖片時(shí)，優(yōu)先加載占用網(wǎng)絡(luò)資源小的，比如文字資源，然后再進(jìn)行占用資源較大的加載，比如圖片資源。通過分步加載也能有效減少頁面等待時(shí)間。比如大眾點(diǎn)評(píng)等圖片很多的網(wǎng)站往往會(huì)采用這種加載策略。
分頁加載是我們目前很常見的方式，比如我們常用的百度和谷歌等搜索引擎都是使用的分頁加載，分頁適用于數(shù)據(jù)量比較大的內(nèi)容，比如表格數(shù)據(jù)或者大數(shù)據(jù)搜索場景可以使用。
分頁加載可以理解為當(dāng)前獲取到100條數(shù)據(jù)，但是將100條數(shù)據(jù)分別拆成5頁每頁20條數(shù)據(jù)提供給用戶，這樣也可以讓用戶減少等待時(shí)間：
在目前還有一種滾動(dòng)分頁的加載，就是不提供視覺上的分頁，而是當(dāng)用戶進(jìn)行滾動(dòng)時(shí)，自動(dòng)加載一定數(shù)量的內(nèi)容，這樣從用戶的視角看就是一個(gè)連續(xù)不間斷的數(shù)據(jù)展示。比如一些資訊類的網(wǎng)站就是采用的這種加載策略，有的也把這種滾動(dòng)分頁的方式稱為自動(dòng)加載。
這里講的延遲加載更多的是一種防護(hù)加載機(jī)制，一般延遲設(shè)置的時(shí)間為300ms。這里的延遲加載有2種使用，第一種多用于搜索，通過延遲加載能夠讓用戶更好進(jìn)行連續(xù)輸入，避免搜索結(jié)果被高頻率刷新，同時(shí)緩解服務(wù)器壓力。如下圖，可以看到我在輸入1后會(huì)有個(gè)延遲才出現(xiàn)加載列表，并且我在連續(xù)輸入12306的過程中是沒有對(duì)結(jié)果進(jìn)行更新的，當(dāng)我輸入完后才更新。
第二種則是通過延遲加載可以更好防止反復(fù)操作。當(dāng)用戶在同一組件上面進(jìn)行切換時(shí)，如果該操作小于300ms,則只記錄最后的點(diǎn)擊操作。這種情況可以用在我們的表格翻頁和開關(guān)等狀態(tài)上，防止用戶瘋狂點(diǎn)擊導(dǎo)致數(shù)據(jù)反復(fù)請(qǐng)求和屏幕閃爍的情況。我們可以通過下面這個(gè)組件演示例子來進(jìn)行對(duì)應(yīng)的感知：
延遲加載更多用于上述2種場景，對(duì)于其他情況的加載，直接加上就可以了，并不需要刻意設(shè)置延遲。
這里想要表達(dá)的含義是當(dāng)用戶在操作后，客戶端立即反饋操作成功，然后把請(qǐng)求放到后臺(tái)與服務(wù)器交互，這一過程用戶不需要了解，不需要等待。無論在什么網(wǎng)絡(luò)環(huán)境下你基本上都能操作成功。比如微信的朋友圈發(fā)布就是這樣的操作，即使你在斷網(wǎng)的情況下都能夠立刻發(fā)布，但實(shí)際上這個(gè)時(shí)候并沒有發(fā)送成功，還需要上傳到服務(wù)器后才你的朋友們才能看見。
這樣的好處是用戶使用起來非常流暢，但是壞處就是，當(dāng)操作不成功時(shí)，用戶并不能及時(shí)進(jìn)行感知，仍然以為操作已經(jīng)成功了。所以這種場景我們也需要根據(jù)場景進(jìn)行對(duì)應(yīng)的判斷和選擇。對(duì)于復(fù)雜的B端場景個(gè)人建議慎用或者不用這種操作，畢竟很多發(fā)布的功能會(huì)同時(shí)影響很多業(yè)務(wù)線。
這里就拿微信的朋友圈發(fā)布來進(jìn)行舉例，下方手機(jī)狀態(tài)都為斷網(wǎng)狀態(tài)，可以看到微信立即發(fā)布，而貼吧在這種狀態(tài)下提示網(wǎng)絡(luò)錯(cuò)誤。
通過這些加載策略的選擇性使用，能夠在特定環(huán)境下提升我們系統(tǒng)的整體使用體驗(yàn)。因此我們需要對(duì)這些加載策略有一個(gè)比較全面的認(rèn)識(shí)，這樣我們不僅知道加載慢的原因，還可以利用加載策略去提升頁面性能。
在整體的加載過程中，別忘了考慮加載異常的情況。在通常情況下我們會(huì)我們會(huì)遇到網(wǎng)絡(luò)速度過慢或者突然斷網(wǎng)這兩種狀況讓頁面一直加載不出來，這時(shí)我們需要考慮對(duì)長時(shí)間的加載過程進(jìn)行處理。
通常做法是我們要對(duì)加載狀態(tài)有一個(gè)最長時(shí)間的限制，一般為加載不超過10s，超過最長時(shí)間后就進(jìn)行異常狀態(tài)顯示（提示語+刷新按鈕）。這樣用戶可以選擇重新加載或者離開此頁面，而不是一直等待。
在這里還想到一點(diǎn)，就是對(duì)于編輯頁面，我們應(yīng)當(dāng)加入網(wǎng)絡(luò)連接是否異常的判斷，比如當(dāng)進(jìn)入到編輯頁面后，如果遇到網(wǎng)絡(luò)斷開，需要在頁面的頂部加上常駐提示條【當(dāng)前網(wǎng)絡(luò)連接斷開】，這樣用戶能夠及時(shí)進(jìn)行察覺并修復(fù)。避免在無網(wǎng)環(huán)境下繼續(xù)輸入。這對(duì)于某些需要輸入很多內(nèi)容且并不提供本地保存的頁面來講是非常有必要的。
加載在設(shè)計(jì)中是非常容易被忽略的模塊，因?yàn)樵诖蟛糠智闆r下網(wǎng)絡(luò)速度都較快，人們很難深刻地感受到加載過程。但加載卻在產(chǎn)品運(yùn)行中起著不可或缺的作用。通過這篇文章想要告訴大家的有幾個(gè)點(diǎn)：
1.我們需要明白加載為什么會(huì)出現(xiàn)，這個(gè)過程是怎么樣的；
2.加載的通用處理手段是怎么樣的，非通用處理方式有哪些；
3.通過緩存和對(duì)應(yīng)加載策略能夠讓頁面加載速度有本質(zhì)上的提升。
這樣當(dāng)我們?cè)陧撁嫔嫌龅郊虞d速度慢的問題時(shí)，在為其加上動(dòng)畫承載過渡的同時(shí)，還應(yīng)該思考其加載緩慢背后的原因，是因?yàn)閿?shù)據(jù)量太大還是加載策略的相關(guān)問題，是否可以將其進(jìn)行懶加載或者分步加載，這時(shí)我應(yīng)該去找前端或者后端如何溝通。從源頭上解決加載時(shí)間長的問題，才是后續(xù)產(chǎn)品設(shè)計(jì)過程中的長久思路。
藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群，每天會(huì)分享國內(nèi)外的一些優(yōu)秀設(shè)計(jì)，如果有興趣的話，可以進(jìn)入一起成長學(xué)習(xí)，請(qǐng)掃碼ben_lanlan，報(bào)下信息，會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作，也請(qǐng)與我們聯(lián)系。
免責(zé)聲明：藍(lán)藍(lán)設(shè)計(jì)尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系，我們立即更正或刪除。
藍(lán)藍(lán)設(shè)計(jì)( www.gerard.com.cn )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)
藍(lán)藍(lán)設(shè)計(jì)的小編 http://www.gerard.com.cn