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