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

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

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

所以說它是ajax技術的進一步升華，把ajax的無刷新機制發揮到極致，因此能造就與桌面程序媲美的流暢用戶體驗。

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

##單頁應用的體驗
言歸正傳，如何盡可能增強單頁應用的操作體驗？

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

1. 頁面初始的加載速度
2. 交互的響應
3. 頁面數據的正確性（尤其是網絡異常狀況下）

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

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

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

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

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

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

####先說內存的來源，有以下幾種：

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

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

####再說內存的變更

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

#####http請求失敗

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

什么是操作補償呢？

從邏輯上來講，當我們在界面上操作，創建一條任務的時候，新的這條任務不應當立刻顯示出來，而是應當等到服務端確認成功了，才加到界面上。但很可能我們的網絡不好，這一步用戶要等很久。從用戶體驗的角度，這樣是不好的，所以我們可以先把界面放上去，然后等創建成功的消息回來之后，再把一些唯一標識之類的東西回填到內存數據中。

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

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

這里如果繼續再做也是有的做，和離線應用思路相似，把操作的結果記錄在客戶端本地，等到網絡正常，再和后臺進行數據同步。


#####斷線重連

網絡抖動、網絡的切換、電腦休眠再打開等等，導致我們需要面對更復雜的網絡狀況，那當用戶再次聯網的時候，應用需要去重新鏈接。

這時，一個理想的單頁應用，會在重新連接的時候，把之前所有發生的事件產生的最終結果，也就是最新的狀態，同步回來。

我們的應用是有協作業務的，同一企業的用戶間，享有同樣的模型，通過webSocket進行同步，保證模型的即時性和正確性。所以這也是我們遇到的一大挑戰。我們解決的方式是webSocket的重發。

#####熱更新

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

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

#####最后
曾經聽過一個說法，如何判斷一個單頁面產品的技術水準呢？
連續開幾天不關，不需要刷新頁面，應用一樣可以正常、正確、流暢的使用。

這里面的含義，相信做過單頁應用的同學們心里都懂。

##小結

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

---恢復內容結束---

以上就是有關單頁應用的體驗問題的詳細內容，更多請關注php中文網其它相關文章！