分享移动端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，或者扫描下面的二维码