單入口與多入口地址
app的入口是確定的惟一的，只能通過app的主頁面一級級進入，這就決定了app沒有一些異常進入的途徑，從而大大的降低了app產品的複雜度。這樣的設定對於流程介面是非常好的，比如從a>b>c這樣的流程介面，我們無法繞過app的a頁面直接訪問到b頁面，在產品互動上也不會存在某使用者的app的b流程頁面被另外一個使用者拿到。即使拿到，也是app自定義好的一個可分享的頁面。
而h5卻是多入口的，h5整個站點所有的h5頁面的地址都是使用者可感知，可複製地址訪問的。因此，對於任何的h5頁面都必須考慮除了正常路徑訪問之外，使用者直接訪問某頁面，應該如何處理的問題。
是否具有宿主優勢
所謂宿主就是獨立應用所具有的一些特殊能力，這些能力對產品的體驗都至關重要，下面通過表格列舉了下：
| 能力 | 說明 |
|---|---|
| 裝置網路 | 可以區分網路情況，針對不同網路給出不同產品方案，並提供網路異常的方案 |
| 裝置資訊 | 使用者的作業系統型別以及版本，地理位置等 |
| 裝置基本能力 | 拍照，gps定位，錄音 |
| 檔案操作能力 | 手機中一些檔案的管理，應用檔案的一些本地管理 |
| 資料儲存 | 完整的應用資料儲存方案 |
| 穩定的黑盒環境 | 相比複雜的多種手機端瀏覽器，宿主的訪問環境更為確定，可除錯 |
那麼顯然會影響的產品體驗如下：
| 對比項 | app | h5 |
|---|---|---|
| 靜態資源 | 內建在app內，或快取到本地，免載入 | 需要載入，依賴於設定瀏覽器的快取策略，首次載入無法直接優化 |
| 網路載入 | 效能更佳 | 依賴於現有的工具網路請求效能 |
| ui渲染 | 更接近手機系統底層語言，渲染快、體驗好，尤其在明顯的下拉框、長列表上，體驗明顯好 | 依賴於瀏覽器的核心 |
| 環境確定 | app的打包環境以及打包之後的使用環境確定，不需要額外的根據app的情況區分，只需要注意系統版本 | 需要分析宿主瀏覽器的版本以及核心對ui的影響，當然系統的版本也是有影響的，具體針對不同瀏覽器都需要影響其打包之後的js以及css檔案 |
| 資料儲存 | 可以儲存需要的使用者操作互動資料，能最大程度的降低資料的應用儲存 | 需要藉助web儲存，並且需要藉助一些store的管理工具，目前在複雜的使用者資料永儲存上沒有好的技術方案。 |
關於頁面重新整理
| 對比項 | app | h5 |
|---|---|---|
| 是否允許直接重新整理當前頁進入 | 一般不允許，沒有重新整理操作 | 使用者操作上允許瀏覽器選單上的重新整理 |
| 重新整理時機 | 從上一個流程狀態頁面或者訪問鏈路頁；頁面互動引起的程式碼重新整理 | 根據連結用瀏覽器重新整理；從上一個流程狀態頁面或者訪問鏈路頁；頁面互動引起的重新整理 |
| 重新整理時是否需要做鑑權以及業務判斷 | 不需要，因為正常下是在app的環境裡，封閉訪問環境 | 需要對每個頁面進行必要的鑑權，並根據業務的狀態分析使用者是否應該確實訪問這個頁面還是其他頁 |
所以在app的經典體驗是某入口--列表--詳情
入口到列表頁，資料重新整理，列表到詳情 ，詳情重新整理；
但是詳情返回到列表，資料以及互動狀態保留；列表返回主頁面，狀態保留。至於如何保留的我後面會詳細描述。
在列表頁為了讓資料有更新同步的部分，一般會提供下拉重新整理或頂部雙擊重新整理。
而h5要想做到返回某個頁面時具有歷史狀態，必須藉助一些方式:
1.利用瀏覽器的歷史記錄，可行但不便利，有些使用者互動是不記錄在瀏覽器的歷史行為的。
2 利用全域性store儲存頁面的資料以及互動狀態，簡單的可以，複雜的難，工作量較大，需要區分來源是首次正常載入還是從鏈路頁面返回。
3 利用視覺效果，類似於app內的頁面棧，頁面層級管理，將新頁面展示內容變為模態框全屏覆蓋展示，返回時取消模態框顯示。簡單的1-2級鏈路可考慮。
4 元件快取效果，比如vue本身元件支援keep-alive
頁面的返回與前進
app返回與前進，在app的頭上每個跳轉都是到指定app頁面。
而h5一般很少按照app的思路去嚴格設計互動流程，一般返回和前進都是直接定義的歷史記錄的前進和後退，這在頁面上會形成非常多歷史頁面，非常容易造成頁面訪問的死迴圈。（直接每次使用新頁面渲染，也會導致體驗不好，尤其在目前的spa中，我們跳轉頁面都是直接頁面棧中push新頁面）。
在頁面返回的返回與前進中，我們需要的一個產品體驗的閉環，而不是分割的h5,同樣我們也是需要應用的起點頁、主頁、結果頁等的。
鑑權
app集中一次鑑權，一般情況下，app的使用是對登入強要求的，尤其是使用核心業務的頁面。除非產品設計了單獨的訪客模式的應用體驗。這樣的好處便是，只要進行過一次登入，那麼app內的任何頁面都是安全的，可以不考慮這個鑑權的問題，並直接使用app內登入的使用者資料，因為肯定是登入過的。（另外一點優點便是，app已經登入過的使用者名稱、密碼可長期儲存在app端，可以直接執行自動登入）
h5卻不是這樣，一般情況下很多h5頁面屬於非敏感頁面，至少從產品設計角度，覺得這可能不是一個敏感頁面，這就決定了我們在開發h5的時候很少會考慮這個頁面要不要做鑑權，是不是要某使用者才能訪問，如果不能訪問又該如何？但app內沒這個問題，因為如果你的狀態不符合，那麼你根本不會有進到這個頁面的機會。那麼如果h5要做鑑權，會做成什麼樣的？首先如果是短快取的，我們可以藉助會話sessionStorage，在加上store的工具，儲存一些資訊，然後在h5的該訪問入口首先思考是否需要鑑權，如果不需要，直接訪問，業務有要求的情況下做業務狀態判斷；如果需要，那麼就做登入授權然後做重定向。我針對h5的部分我做了詳細的鑑權邏輯分析。
app頁面棧的優越性
app的頁面體驗優化頁面棧佔了很大的部分，可以將不同的頁面按照需求不斷的層疊堆積到檢視層，而上一級頁面可以選擇不銷燬，當不需要的時候，從檢視層移除即可。對於一些快速常用的頁面，為了提升體驗可以直接常用常置到頁面中，需要時直接呼叫傳入需要的資料即可。
而h5卻沒有這樣的同時儲存多個頁面展現的銀彈功能，但有幾個方向是我們可以進行推敲的。
1 spa可以實現不跳轉頁面，不重複載入資源
2 非同步載入元件，需要的內容非同步載入，為頁面展現需要
3 常置的模態框元件，需要時，直接模態框+頁面元件彈出，可以實現類似app的頁面效果，而不是用新的頁面開啟的方式。比如一個音樂的app，歌曲的播放詳情頁就是使用的高頻頁。
同個訪問地址的單訪問與多訪問
app只能在一個環境下訪問一個具體頁面，這個頁面不能同時在app開啟兩個。
而在瀏覽器內，我可能會在兩個tab頁中都開啟了同一個h5連線頁面，在開啟時間不同或者說業務狀態不同的情況下，其展示的正確性要校驗；並通過重新整理，兩個tab展示的內容要能實現同步一致。
訪問入口的聚合
app具有tab切換皮膚，具有個人中心，banner等複雜多變的功能入口。
h5一般都是單流程相關頁或者就是單頁，針對一個應用型別的h5一般很少有人設計訪問入口整合頁，而這個其實才是剛需。
所以我們能從最近一些超級app中看到h5的微首頁的痕跡，在首頁裡配置主要功能入口，比如支付寶的服務號；微信公眾號可以設定應用的主要選單用於支援主要功能；微信小程式開啟介面的展品形態就是內嵌app。
所以像app一樣思考h5是必然的趨勢，在我們設計的h5超過2個獨立訪問需求時，就應該考慮h5方面的訪問入口的主頁地址，並著手上線app，或者小程式類似的產品作為產品矩陣。
關於我
- 我是一名前端Coder，熱愛分享生活與技術中的經驗與心得。
- 我是一名旅遊愛好者，愛好拍攝旅途中的風景與人物。
- 我是一名寫作狂人，基本每天都有新文章產出，筆耕不輟。
個人站點
- GitHub：http://github.com/robinson90
- codepen：https://codepen.io/robinson90
- personal blog: http://damobing.com
- yuque docs: https://www.yuque.com/robinson
- juejin blog: https://juejin.im/user/5a30ce0c51882561a20a768b
個人微訊號與公眾號
微信：csnikey,或者掃碼加我
達摩空間訂閱號：damo_kongjian，或者掃描下面的二維碼