单入口与多入口地址
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.cn/user/377887729918589
个人微信号与公众号
微信：csnikey,或者扫码加我
达摩空间订阅号：damo_kongjian，或者扫描下面的二维码
