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