有關(guān)單頁應(yīng)用的體驗(yàn)問題

##什么是單頁應(yīng)用
所謂單頁應(yīng)用，指的是在一個頁面上集成多種功能，甚至整個系統(tǒng)就只有一個頁面（一個html），所有的業(yè)務(wù)功能都是它的子模塊，通過特定的方式掛接到主界面上。

##為什么會有單頁應(yīng)用
我們知道ajax技術(shù)的產(chǎn)生，一部分原因就是為了讓訪問網(wǎng)頁的用戶在不刷新頁面的情況下，在頁面上查看數(shù)據(jù)的變更。我們可以說ajax提升了體驗(yàn)。

隨著互聯(lián)網(wǎng)的發(fā)展，瀏覽器端承載的業(yè)務(wù)愈發(fā)復(fù)雜，web前端早已不再是一個簡單頁面，ajax局部刷一刷的小玩意。動輒數(shù)十個子頁面的應(yīng)用市面上隨處可見。而這些子頁面享有許多共用的資源（靜態(tài)、動態(tài)），加載它們需要不少的時間，要想不重復(fù)加載這些資源，有一個顯而易見的辦法 —— 把他們放到一個html中。

所以說它是ajax技術(shù)的進(jìn)一步升華，把a(bǔ)jax的無刷新機(jī)制發(fā)揮到極致，因此能造就與桌面程序媲美的流暢用戶體驗(yàn)。

##單頁應(yīng)用帶來的困擾
我們知道，把十幾個二十幾個子頁面的程序，放在一個html里面，不是cut+paste就能搞定的。原本不相關(guān)的程序，放在一起的結(jié)果，就是程序世界的質(zhì)能方程 Errors = (More Code)^2

##單頁應(yīng)用的體驗(yàn)
言歸正傳，如何盡可能增強(qiáng)單頁應(yīng)用的操作體驗(yàn)？

那我們先來看一下，對于用戶來說，影響體驗(yàn)的，包括哪些

1. 頁面初始的加載速度
2. 交互的響應(yīng)
3. 頁面數(shù)據(jù)的正確性（尤其是網(wǎng)絡(luò)異常狀況下）

--
前兩點(diǎn)其實(shí)很多文章談的都比較多了，這里我盡量一筆帶過，重點(diǎn)談一談第三點(diǎn)。

####頁面初始加載速度
- 靜態(tài)資源的按需加載 （良好的模塊化前提下，使用webpack、 systemjs這類module bundler工具）
- 動態(tài)資源的按需獲取 （需要前端數(shù)據(jù)層的良好架構(gòu)）
- 服務(wù)端渲染 （把頁面加載過程中，前端“獲取”數(shù)據(jù)，并“生成”頁面的過程，放在服務(wù)端完成。不適用于首屏過于復(fù)雜的應(yīng)用）

####交互的響應(yīng)
- 速度：后端請求回來的數(shù)據(jù)，前端緩存，后續(xù)同步。避免同樣的數(shù)據(jù)重復(fù)請求。
- 異常處理：現(xiàn)今移動辦公普及，如何在網(wǎng)絡(luò)狀況欠佳時，在ui上給用戶良好的等待或者提示，也不可小視

####頁面數(shù)據(jù)的正確性
這個是我比較想談的，也是我們在實(shí)踐過程中遇到過很多問題，也嘗試過一些解決方案的。

我個人覺得，對于這件事，想要做好，就這幾個字： **“良好的緩存管理”**，這里的緩存，指的是前端緩存的模型。

別看就這幾個字，做起來相當(dāng)有難度。為何？

####先說內(nèi)存的來源，有以下幾種：

- 瀏覽器緩存（indexDB，localStorage之流）
- http請求
- webSocket推送

不同的來源，影響同一份數(shù)據(jù)，需要良好的抽象，讓業(yè)務(wù)層屏蔽對數(shù)據(jù)來源的感知，現(xiàn)有的被廣泛應(yīng)用的解決此問題的庫有RxJs, CycleJS等，早先也有人提出MVI的概念，皆為此生。

####再說內(nèi)存的變更

正常狀態(tài)的變更，無需贅言，這里只說幾類異常狀態(tài)。

#####http請求失敗

這里需要提到一個詞，叫**“操作補(bǔ)償”**

什么是操作補(bǔ)償呢？

從邏輯上來講，當(dāng)我們在界面上操作，創(chuàng)建一條任務(wù)的時候，新的這條任務(wù)不應(yīng)當(dāng)立刻顯示出來，而是應(yīng)當(dāng)?shù)鹊椒��?wù)端確認(rèn)成功了，才加到界面上。但很可能我們的網(wǎng)絡(luò)不好，這一步用戶要等很久。從用戶體驗(yàn)的角度，這樣是不好的，所以我們可以先把界面放上去，然后等創(chuàng)建成功的消息回來之后，再把一些唯一標(biāo)識之類的東西回填到內(nèi)存數(shù)據(jù)中。

單步的操作補(bǔ)償還算是不太難，如果有多步的話，就非常麻煩了，舉個極端情況的例子來說，用戶新增了一條任務(wù)，服務(wù)端還沒返回的時候，他就立刻在這條任務(wù)下創(chuàng)建子任務(wù)，但子任務(wù)這時候沒有父任務(wù)的id，如果想給這步也做操作補(bǔ)償，就比較麻煩了。甚至說，連續(xù)進(jìn)行了幾步操作之后，發(fā)現(xiàn)之前的操作失敗了，后續(xù)處理會非常復(fù)雜。

我們的產(chǎn)品一樣遇到這個問題。我們的做法是 —— **“折中”**，對于重要數(shù)據(jù)，做單步補(bǔ)償，或者兩步補(bǔ)償。如果遇到前端模型從屬關(guān)系復(fù)雜且上級模型的寫操作失敗，抑或是過多步的補(bǔ)償，就提早通知用戶，并在ui上鎖死用戶的交互入口，避免后續(xù)寫操作的發(fā)生。

這里如果繼續(xù)再做也是有的做，和離線應(yīng)用思路相似，把操作的結(jié)果記錄在客戶端本地，等到網(wǎng)絡(luò)正常，再和后臺進(jìn)行數(shù)據(jù)同步。


#####斷線重連

網(wǎng)絡(luò)抖動、網(wǎng)絡(luò)的切換、電腦休眠再打開等等，導(dǎo)致我們需要面對更復(fù)雜的網(wǎng)絡(luò)狀況，那當(dāng)用戶再次聯(lián)網(wǎng)的時候，應(yīng)用需要去重新鏈接。

這時，一個理想的單頁應(yīng)用，會在重新連接的時候，把之前所有發(fā)生的事件產(chǎn)生的最終結(jié)果，也就是最新的狀態(tài)，同步回來。

我們的應(yīng)用是有協(xié)作業(yè)務(wù)的，同一企業(yè)的用戶間，享有同樣的模型，通過webSocket進(jìn)行同步，保證模型的即時性和正確性。所以這也是我們遇到的一大挑戰(zhàn)。我們解決的方式是webSocket的重發(fā)。

#####熱更新

前面提到，用戶有可能長期開著我們的應(yīng)用，然后中間一直沒有刷新。正常情況下，業(yè)務(wù)變更都應(yīng)當(dāng)會被全部推送過來，界面所反饋的狀況始終是最新的，符合現(xiàn)狀的。但我們需要考慮到另外一個問題，系統(tǒng)升級怎么辦？

我們當(dāng)然可以推送一個通知：本系統(tǒng)已經(jīng)升級了，請點(diǎn)擊刷新。但能不能做得更好？這是有可能的，要達(dá)到這種目的，就要使用熱更新這種手段，把代碼的模塊化和變更管理都做到極致，每次更新的代碼模塊也推送過來，并且作為補(bǔ)丁應(yīng)用到當(dāng)前系統(tǒng)上。這種機(jī)制對開發(fā)團(tuán)隊(duì)的水準(zhǔn)要求很高。

#####最后
曾經(jīng)聽過一個說法，如何判斷一個單頁面產(chǎn)品的技術(shù)水準(zhǔn)呢？
連續(xù)開幾天不關(guān)，不需要刷新頁面，應(yīng)用一樣可以正常、正確、流暢的使用。

這里面的含義，相信做過單頁應(yīng)用的同學(xué)們心里都懂。

##小結(jié)

說了不少，總結(jié)一下。我們提到了一些問題和針對問題的能夠提升單頁應(yīng)用體驗(yàn)的方式，如果實(shí)現(xiàn)出來，肯定是可以讓使用者非常開心的，但需要冷靜權(quán)衡理想與現(xiàn)實(shí)之間的差距。我們做的是軟件工程，必須適當(dāng)放棄美學(xué)，將有限的人力精力投入到要害所在。

---恢復(fù)內(nèi)容結(jié)束---

以上就是有關(guān)單頁應(yīng)用的體驗(yàn)問題的詳細(xì)內(nèi)容，更多請關(guān)注php中文網(wǎng)其它相關(guān)文章！