1 window.Hybrid = window.Hybrid || {}; 2 var bridgePostMsg = function (url) { 3 if ($.os.ios) { 4 window.location = url; 5 } else { 6 var ifr = $('<iframe src="' + url + '"/>'); 7 $('body').append(ifr); 8 setTimeout(function () { 9 ifr.remove(); 10 }, 1000) 11 } 12 }; 13 var _getHybridUrl = function (params) { 14 var k, paramStr = '', url = 'scheme://'; (params.callback) { 17 url += '&callback=' + params.callback; 18 delete params.callback; 19 } 20 if (params.param) { 21 paramStr = typeof params.param == 'object' ? JSON.stringify(params.param) : params.param; 22 url += '&param=' + encodeURIComponent(paramStr); 23 } 24 return url; 25 }; 26 var requestHybrid = function (params) { tt = (new Date().getTime()); 29 var t = 'hybrid_' + tt; 30 var tmpFn; (params.callback) { 34 tmpFn = params.callback; 35 params.callback = t; 36 window.Hybrid[t] = function (data) { 37 tmpFn(data); 38 delete window.Hybrid[t]; 39 } 40 } 41 bridgePostMsg(_getHybridUrl(params)); 42 }; getHybridInfo = function () { 45 var platform_version = {}; 46 var na = navigator.userAgent; 47 var info = na.match(/scheme\/\d\.\d\.\d/); (info && info[0]) { 50 info = info[0].split('http://www.cnblogs.com/'); 51 if (info && info.length == 2) { 52 platform_version.platform = info[0]; 53 platform_version.version = info[1]; 54 } 55 } 56 return platform_version; 57 };

因为Native对于H5来是底层，框架&底层一般来说是不会关注业务实现的，所以真实业务中Native调用H5场景较少，这里不予关注了。

良好的交互设计是成功的第一步，在真实业务开发中有一些API一定会用到。

跳转是Hybrid必用API之一，对前端来说有以下跳转：

① 页面内跳转，与Hybrid无关

② H5跳转Native界面

③ H5新开Webview跳转H5页面，一般为做页面动画切换

如果要使用动画，按业务来说有向前与向后两种，forward&back，所以约定如下，首先是H5跳Native某一个页面

requestHybrid({ 4 tagname: 'forward', 5 param: { topage: 'home', type: 'native', data2: 2 12 } 13 });

比如携程H5页面要去到酒店Native某一个页面可以这样：

requestHybrid({ 3 tagname: 'forward', 4 param: { topage: 'hotel/detail', type: 'native', id: 20151031 11 } 12 });

比如H5新开Webview的方式跳转H5页面便可以这样：

1 requestHybrid({ 2 tagname: 'forward', 3 param: { topage: 'hotel/detail ', type: 'webview', id: 20151031 10 } 11 });

back与forward一致，我们甚至会有animattype参数决定切换页面时的动画效果，真实使用时可能会封装全局方法略去tagname的细节，这时就和糯米对外释放的接口差不多了。

最初我其实是抵制使用Native提供的UI组件的，尤其是Header，因为平台化后，Native每次改动都很慎重并且响应很慢，但是出于两点核心因素考虑，我基本放弃了抵抗：

① 其它主流容器都是这么做的，比如微信、手机百度、携程

② 没有header一旦网络出错出现白屏，APP将陷入假死状态，这是不可接受的，而一般的解决方案都太业务了

PS：Native吊起Native时，如果300ms没有响应需要出loading组件，避免白屏

因为H5站点本来就有Header组件，站在前端框架层来说，需要确保业务的代码是一致的，所有的差异需要在框架层做到透明化，简单来说Header的设计需要遵循：

① H5 header组件与Native提供的header组件使用调用层接口一致

② 前端框架层根据环境判断选择应该使用H5的header组件抑或Native的header组件

一般来说header组件需要完成以下功能：

① header左侧与右侧可配置，显示为文字或者图标（这里要求header实现主流图标，并且也可由业务控制图标），并需要控制其点击回调

② header的title可设置为单标题或者主标题、子标题类型，并且可配置lefticon与righticon（icon居中）

③ 满足一些特殊配置，比如标签类header

所以，站在前端业务方来说，header的使用方式为（其中tagname是不允许重复的）：