混合开发H5通信方案

现在，混合开发是APP的主流开发模式——NATIVE+H5。金科支持的各site也是采取同样的做法。混合开发的优点很多，百度一下就知道，不是本文的重点。这里简单介绍下hyperion的工作原理，重点分析亿账通运营服务小组现在使用的方案——H5框架里面耳熟能详的两个hyperion JS文件走读下代码。

大纲：

一 背景介绍

二 hyperion.adapert.js

   2.1 如何交互

   2.2 代码走读

   2.3 目前遇到情况，Android/iOS  对接目前的问题

三 hyperion.js 新增配置

---

一 背景介绍

    由于APP和H5各自的优势劣势，混合开发能弥补APP打包、审核、发布耗时长，也解决了H5不能调用系统接口的局限。两者的结合既保留APP的性能优势，也充分发挥H5的跨平台性，这种方式也被很多业内知名的互联网公司采用，如淘宝、京东、微信公众号，包括平安集团的大多数APP也采用混合开发的模式。

    有了混合App（Hybrid App）的诞生，那么NATIVE和H5是如何进行交互的，需要我们做哪些事情，是想要在这篇文章说明的重点。

二 hyperion.adapert.js

     2.1 交互原理

混合APP需要开启webview的功能，并且在webview加载H5页面的时候需要注入js脚本。通过类似iframe、prompt、alert、confirm等方法和webview交互，webview能监听到js的事件拿到所传输的数据，在进行处理后返回接触的结果数据告诉H5执行的回调。总结起来就是下图示意：

2.1H5-NATIVE交互

2.2 hyperion.adapert.js

    这个文件是定义H5和NATIVE交互的方法。文件可以分成两个部分，下面的一段(function(global){})(this)自执行函数，和上面的定义全局变量HFEasyJS。（本人不太明白IOS和JAVA开发，仅从H5的角度来分析代码的逻辑，说的不全的地方请大家留言指正。）

    (function(global){})(this)里面干了两件事情。一是定义了Hyperion的方法，其中一个属性Hyperion.call传参给native，另一个Hyperion._callback处理JS回调。JS自身并不清楚回调要什么时候来触发，所以其实这里的Hyperion._callback的触发是native端来调起的。查阅Android端的回调代码：

jsContent = "javascript:Hyperion._callback('" + callBackFunName + "'," + callBackCode + ","+ callBackParam + ")";

...  

 loadUrl(jsContent);

...

找到传过去的callBackFunName，调起已注入JS的代码，并在webview里面执行。

    H5的框架我们默认一定要引入hyprion.adapte.js和hyperion.js两个脚本文件，但是在调试Android端的时候发现，hyprion.adapte.js其实是有注入进webview的，就是我们实际上调起的Hyperion方法是覆盖了脚本文件用的Android端的脚本：

public static String getCommonInjectedJS(){

return "javascript:(function(Global){var Hyperion=Global.Hyperion||{};var slice=Array.prototype.slice,ua=Global.navigator?Global.navigator.userAgent:\"\",isiOS=/iPhone|iPad|iPod|iOS/i.test(ua),isAndroid=/Android/i.test(ua),callbackId=0;var noop=function(){}; ...略

}

确实看起来和我们hyprion.adapte.js很像，但是还少了一部分代码，因为Android端到这里已经结束了。在Hyprion.call里面有别与Android和IOS的部分：

if (isAndroid) {

prompt(callData);

} else if (isiOS) {

try {

global.Hyperion_NATIVE.call(callData);

} catch (e) {}

}

对照图2.1来理解，Android端用了prompt的方法和webview进行传参，但是IOS用了另一种方式iframe，就是Hyperion.adapte.js的上面部分定义的HFEasyJS。(为什么不能用一个方法来传值了，还区分平台，这个已经无从考证，是历史代码原因还是平台版本的兼容性问题有了解更多的大神欢迎指导留言)

window.HFEasyJS = {

__callbacks: {},

invokeCallback: function(cbID, removeAfterExecute) {

...

},

call: function(obj, functionName, args) {

...

var iframe = document.createElement("IFRAME");

iframe.setAttribute("src", "easy-js:" + obj + ":" + encodeURIComponent(functionName) + argStr);

},

inject: function(obj, methods) {

for (var i = 0, l = methods.length; i < l; i++) {

jsObj[jsMethod] = function() {

return HFEasyJS.call(obj, method, Array.prototype.slice.call(arguments));

 }}};

IOS用iframe进行传值，在document内append(iframe)的时候会把参数拼接成字符串通过src进行传值例:  src:'easy-js:Hyperion_NATIVE:call:'，NATIVE在接收到定义的协议后并不去请网络资源，而是解析传入的方法。

2.3 目前遇到情况，Android/iOS  对接目前的问题

    定义接口的文件综上所述。发现Android和IOS都有注入hyperion.adapter.js，而且H5在框架层也引入了此文件。注入的原因可能是为了解决加载H5资源过多，但是也会存在注入时机的问题，如果页面初始化的需要调用例如Hyperion.actions.onEvent()的方法，注入脚本是在静态资源加载完成时，那么就会导致找不到方法报错。可能NATIVE有多次注入，其实为了防止报错的问题，H5的框架保险起见再次引入了hyperion.adapter.js。那初衷为了减少请求开支的目的也没用达到，而且如果协议文件改了Android和IOS都要改脚本并且打包，（用了这么久应该也不会改了吧，实际上却是碰到了问题，需要改动native端的脚本）所以的site也要更新代码，搞得挺麻烦，H5来维护更方便。

三 hyperion.js 新增配置

相对来说hyperion.js更容易理解，其实就是封装的各个方法，其中Hyperion 文档有介绍如何写的比较详细，这里就不赘述。