以上按照业务逻辑的知识的话是正确的，但是以第三种情况来说，如果回到首页后再次点击后退，而首页的后退又刚好是back操作，那么会回到产品详情页（事实上用户是想退出该频道），而更加不妙的是用户再次点击产品详情的回退又回到了首页，形成了一个死循环！！！

history错乱，暂时没有很好的处理办法，我们要做的是一旦发现可能会发生history错乱的频道就都不要使用back了，比如上面首页back就写死回到app大首页

当然，有些页面也不是无规律的乱跳的，所以我们新开一个页面的时候需要让新开页面知道之前是哪个页面，如果单页应用倒是可以写在实例对象上，但是一刷新就丢了，所以比较靠谱的做法也许是带在url上，这个在新开webview的场景下是不可避免的，比如：

.forward('b'); .refer == 'a' //true //因为页面刷新会丢失这个管理，所以我们将这个关联写在url上 //b的url webapp/project/b.html?refer=a

H5开发中对Header部分的操作是不可避免的，于是我们抽象出了UIHeader组件处理这种操作，事实上在Hybrid中的Header也应该是一个通用组件，前端做的仅仅是根据约定的格式去调用这个组件即可，但是因为要保证H5与Native调用的一致性，所以要规范化业务代码的使用，一般的使用方法为：

.header.set({ 5 left: [ 6 { tagname: 'back', 9 value: '回退', lefticon: 'back', 13 callback: function () { } 14 } 15 ], 16 right: [ 17 { tagname: 'search', 20 callback: function () { } 21 }, { 24 tagname: 'me', icon: 'hotel/me.png', 27 callback: function () { } 28 } 29 ], 30 title: 'title', title: ['title', 'subtitle'], title: { 36 value: 'title', righticon: 'down', callback: function () { } 43 } 44 });

因为一般来说左边只有一个返回相关的按钮，所以会提供一个语法糖（在底层依旧会还原为上面的形式）：

1 this.header.set({ 2 left: [{ 3 tagname: 'back', 4 callback: function(){} 5 }], 6 title: '', 7 }); .header.set({ 10 back: function () { }, 11 title: '' 12 });

header组件上会有很多的图标，而根据之前的约定，tagname与图标是一一对应的，这里就要给出一些基本的映射关系了：

因为H5与native是以tagname作为标识，所以一定不能重复

这些皆需要Native同事实现，如果是新出的图标的话，可以读取线上http的图标，比如这样：

1 Hybrid.ui.header.set({ 2 back: function () { 3 requestHybrid({ 4 tagname: 'back', 5 param: { 6 topage: 'index', 7 type: 'native' 8 } 9 }); 10 }, 11 title: '读取线上资源', 12 right: [ 13 { 14 tagname: 'search', 15 icon: 'http://images2015.cnblogs.com/blog/294743/201511/294743-20151102143118414-1197511976.png', 16 callback: function () { 17 alert('读取线上资源') 18 } 19 } 20 ] 21 });

但如果是常用的图标还要去线上取的话，对性能不太好，而这里也引出了一个比较大的话题，静态资源缓存问题，这个我们在后面点描述。

其实之前我提出过拒绝使用NativeUI的想法，当时最是抵制的就是Header组件，因为如果使用Native的Header的话：

① 我们的loading将header盖不住

② 每次前端header有什么特殊需求都实现不了，必须等待Native支持（比如Header隐藏之类的）

为了抵制我还提出了一些方案，但是以后面实际项目来说，事实上是很难摆脱Header组件：

① 断网情况下白屏问题

② js报错假死问题