这里back比较特殊，在webview中会检查history的记录，如果大于1则后退，否则会退回上一步操作。 我们可以看出，back的功能是很单一的，往往不能满足我们的需求，所以常常使用forward+pop动画当做back使用，而这一做法将引起令人头疼的history错乱问题，针对这种情况我们有一些特殊API，但是因为这个API需要Native支持，所以使用需要慎重，最好是新增一个native接口，用于跳转后，清除所有的history webview。

Header约定是Hybrid的重要一环，也是移动体系化，技术体系化中重要的一小环，与之对应的会有：

① 分享约定

② 登录唤醒约定

③ 离线包机制

④ 跳转机制

......

这里体系化做的足够好的话就会出现类似微信SDK一般的东西，但是这个要看你们是不是有足够多的第三方接入方需要你们费这个神了，但是只要做到这一些，你的移动端便已经体系化了，所有的H5项目的账号系统与基本native打通是完成了。

这种体系化的东西形成后需要做到通用，比如两个app能同时运行同一个H5站点，甚至离线包机制都是一致的，header交互也是一致的

数据可视化

上述工作做完，表现层的东西就做了一大部分了，站在前端的角度的话，可以做的东西好像不多了，其实细细一想，有这种想法真的是图样图森破，就算要把上面的事情做完都要费老大的劲，况且真正的难点可能才真正的开始，如我们第一张图，我们有一个项目外包了，那个外包的用户是游离于我们账户体系外的，我们应该如何处理？而更让我们头疼的可能是数据收集与分析，猛的回头，你会发现，对于前端，还有数据可视化这么一大坨的东西需要你去挖掘！

随着技术的沉淀，公司的发展，公司的业务虽然越来越复杂，但是在我们的体系下，都还能很好的运转，但是业务才是技术的祖宗，我们可能会收到类似这种需求：

① 请给我一下上次迎新活动3个月后的用户留存率

② 请给我XX推广人员的订单推广率

③ 请给我APP由XX二维码推广活动的数据

④ 请告诉我为什么我们转化率低

......

用户&订单渠道

可以相信，所有这一切必定会将你问懵，一般来说，不是所有前端一开始设计便能考虑到这些问题，也不是考虑到这些问题就能设计得好，这里简单以用户业务渠道做一个说明。

为了解决以上问题，我们在设计用户表的时候就得新增一些字段了（比较痛苦的是最开始没有这些东西，后面加就恼火了）：

① 项目来源，标志该用户（订单）来源于哪个子系统

② 业务来源，标志该用户（订单）来源于什么渠道

这个渠道就比较复杂了，可以是推广人的拼音，可以是一个活动的标志......

这个设计其实比较简单，就是新增几个数据表字段嘛，真正的难点在于前端&native调用，一般来说，我们希望业务开发无感的便存入进去了，所以我们可以这样设计：

① 在url（cookie也行，就是麻烦）上加入一个channel的参

这里如果不使用cookie需要前端框架做处理，保证每次跳转将这个channel参数一直带下去

② 每次ajax请求的时候将这种新增一个入common的字段，让server端自动处理

所以，业务开发只需要在url做处理（生成二维码的时候带上参数），前端框架统一处理后，每次请求就自动带上了，比如：

?med_channel=qq

native处理方案类似，这里处理完了，我们便可以收集到用户（订单）来源于哪个渠道了，有了这个数据收集便能很好的做后续的分析。

补足体系

上述是业务方的数据收集，这个属于精准定制结果，直接接口存储，除此之外，我们还需要对整个子系统进行数据打点采集，比如页面pv+uv+按钮点击，这个是比较简单的需求，如果一个H5站点用于了多个容器（微信、qq），而每个容器（渠道）产生的pv信息需要记录起来的话，便会有些麻烦。

数据采集这块是我最近准备做的东西，事实上这块我也很有一点一筹莫展的感觉，首先碰到第一个问题就比较令人头疼？

我们到底是应该自己从无到有做一套采集打点系统还是应该直接使用友盟或者百度统计这种第三方的东西？

这里因为我也还没有想清楚，便不做展开，当这块形成后我们整个体系就变成了这个样子了：

经过将近一年的努力，我们逐步构建了这个移动体系化，并且正在向各部分添砖加瓦，现在在以下模块仍然有所缺失：

① 数据可视化缺失，如上所言，这块是我们接下来需要补足的，这里又包括了数据采集，存储，分析，展示多个方面，总之可以做的很多。

② 通用IM消息系统缺失

我们现在Native使用的自身的IM，H5与Native由于原来北京成都两个团队而选择了融云体系，现在整个消息系统没有打通，这里是需要打通的，以后就算大家选用第三方的服务，都一定记得让自己server端做一次收口工作，做一次proxy，这个如果后期需要改造更换消息系统会轻易的多！

③ 日志监控

我们的日志监控与预警一块做的也不够完善，这里包括前端预警与server端预警，这块接下来要加强

④ 全站https化

......

其实除了上面的一些，应该还有很多其他体系模块没有被提出，比如：

① 开发环境

一般环境分为开发、QA、预览（生产某一个机器）、生产四个环境，环境是比较好做区分的，但是难点在于通用的发布系统与各环境的数据处理问题，比如QA环境就是需要一些生产环境的数据，这个时候该怎么做？？？

② 小流量发布

有些时候，我们为了测试，可能需要小流量发布，一方面为了关注流量变化，一方面为了确认没有错误，我们需要这种系统，同时也需要我们的可视化系统记录各种情况的转化率等数据