分享移動端app與h5的產品差異(一)

單入口與多入口地址

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，或者掃描下面的二維碼