title: JsBridge设计和规范
版 本 历 史
| 版本 | 责任人 | 日期 | 备注 |
|---|---|---|---|
| V1.0 | 曾维铭 | 2017-07-04 | 创建文档 |
1. 前言
混合开发最大的优势，在于页面的热更新。而混合开发的难点，在于Native与前调的交互，以及兼容性问题。
JsBridge的目标，就是要屏蔽差异和封装逻辑，让前端、IOS和Android有一套统一的可交互的规范。
在PhiHome项目里，我们计划把所有设备相关的控制页做成H5，Native相当一个容器，提供必要的支撑，以减少App主体的升级迭代，同时又能保持设备模块的更新能力。
本文分以下几个部分：JsBridge整体设计，Native调前端，前端调Native，API，待讨论的问题。
2. JsBridge整体设计
Native和前端交互，分两个方面：Native调前端的方法，前端调Native的方法。
由于前者比较简单，因此JsBridge主要是为后者服务，即前端调Native。
JsBridge的核心思想，在于消息的传递。前端通过传递一段有意义的消息给Native，IOS和Android各自解析这段消息，然后得出需要调用的方法，调用完成之后，再将结果回调给前端。
因此，只要统一好消息的规范，屏蔽好差异，真正应用时，前端完全不需要关心IOS和Android的差异，只需要把必要的信息传递给Native，接下来就是IOS和Android各自实现的事情。但是，在向前调回调结果时，IOS和Android又有统一的规范。
[站外图片上传中...(image-769e1c-1533530100948)]
3. Native调前端
先说Native调前端，流程比较简单。
对于前端，只要把相应的JS方法写好即可，然后告知Android和IOS方法名和所需参数，Native端能直接调用JS的方法。
假设前端有一个alert(msg)方法，Android可以这样调用webView.loadUrl("javascript:alert('hello')")，而IOS也同样有自己的调用API。
4. 前端调Native
前端调原生的方法，是JsBridge最重要的部分。正如前面所述，前端调Native核心在于消息的传递。
按现在封装好的JSBridge，传递消息给IOS和Android走的是两套逻辑。但IOS和Android收到的都是同一条消息，这条消息包含了各种必要的信息，让Native端知道应该调哪个类里面的哪个方法。先来看消息的规范：
4.1 消息规范
标准协议：phihome://class/method?params
实例：phihome://common/switch?{"action":1}
这个协议有四个部分：phihome、class、method、params，每一个部分都是必需的，且整体格式不能改变，否则Native端会解析失败。
phihome：协议头，用于标记当前产品，整个项目基本上是唯一不变的。
class：类名。注意，这里的类名只是一个代号，因为IOS和Android在类的定义上是不一样的。但IOS和Android，可以在Native代码上，为这个代号映射一个具体的类。比如前端统一定义了一个"common"的类名，代表通用工具类。Android和IOS分别为common这个类名映射一个实体类。
method:具体的方法名。IOS和Android必须一致。
params：参数。params是一串JSON数据，把需要传递的参数都封装在里面。
4.2 消息传递机制
前端生成统一的消息后，通过不同的Api，向IOS和Android传递消息。
见以下JS代码：
var message = "phihome://" + clazz + "/" + method + "?" + params;
//传递消息给Android
if (PrivateMethod.isAndroid()) {
window.prompt(message,"");
}
//传递消息给IOS
if (PrivateMethod.isIos()) {
PrivateMethod.loadURL(message)
}
//该函数给IOS使用，相当于在H5页面的DOM结构下，增加一个0px不可见的iframe，同时把消息作为iframe的一个属性（src）传递过去。
loadURL: function (url) {
var iFrame;
iFrame = doc.createElement("iframe");
iFrame.setAttribute("src", url);
iFrame.setAttribute("style", "display:none;");
iFrame.setAttribute("height", "0px");
iFrame.setAttribute("width", "0px");
iFrame.setAttribute("frameborder", "0");
doc.body.appendChild(iFrame);
// 发起请求后这个iFrame就没用了，所以把它从dom上移除掉
iFrame.parentNode.removeChild(iFrame);
iFrame = null;
},
所以说，前端传递消息给IOS和Android，用的是两套逻辑，但传递的消息是一致的。
至于Android和IOS怎么拿到前端传递过来的消息，也是由各端自己实现。比如在Android上，是通过WebView的WebChromeClient下面的一个onJsPrompt的回调方法，来拿到完整的消息。
4.3 调用方式
解析：Native端拿到前端传递过来的消息后，首先会进行解析，拿到其中的类名和方法名，以及参数。
调用：通过解析拿到必要的参数后，就可以具体地调用某个方法。在Android端，是用过Java反射的方式进行调用的。
回调：从解析到完成调用的整个过程，如果Native端遇到任何异常，都会回调一个失败的结果给前端。如果方法执行成功，也会回调一个成功的结果给前端。回调必须带上必要的参数，让前端方便处理。
4.4 回调说明
Native端回调结果，本质是通过调用前调JS的一个方法（onComplete(result)），将结果传递给前端。其中result是一串Json格式的字符串。
Android和IOS回调的结果，必须有统一的格式规范，见以下两个示例（成功和失败）：
{"error_code":0,"error_msg":"success","method":"getToken","result":{"refresh_token":"11111","token":"222222"}}
{"error_code":103,"error_msg":"method not found","method":"getToken","result":""}
所有的回调必须含以下4个字段：
error_code：错误码。0为成功，非0代表调用Native方法失败。
error_msg：对error_code的补充说明。
method：调用的方法名。
result：方法执行后的结果，result里面还可以包含一个JSON对象。
4.5 回调码表
| err_code | 说明 |
|---|---|
| 101 | 消息不合法（前端传递过来的消息为空或格式不对） |
| 102 | class找不到（找不到要调用的类） |
| 103 | method找不到（找不到要调用的方法） |
| 104 | 方法调用失败 |
| 105 | params不合法（即参数为空或格式不正确） |
5. API
Native（IOS和Android）应该提供统一的API，供前端调用，这些API可以分成以下几个类别：
5.1 原生功能API
- 调用原生的Toast、弹窗和加载动画等。
- 获取手机的设备信息和各种状态，如分辨率、型号、网络状态等。
- 控制状态栏的属性：颜色、标题、返回键、菜单键。
5.2 业务API
- Token的传递。
- 设备的控制。
- 网络请求（GET和POST）。
5.3 扩展API
- 调用原生相册或相机，选择照片或拍照后将图片压缩并回调给前端。
- DeepLink。
6 待讨论的问题
问题一：加载H5页面的方式
1. 把所有的H5、JS、CSS等文件打成zip包下载到本地
- 优点：离线有缓存，加载速度快，用户体验好。
- 缺点：保存和更新的逻辑比较复杂，如果没处理好可能会出问题。
2. 加载URL
- 优点：逻辑简单。
- 缺点：加载速度依赖于网络速度，没有访问过的网页就没有缓存。
问题二：前端的职责（网络请求）
1. 完全由前端自己处理。
- 优点：降低对Native的依赖，有利于设备业务的更新迭代。
- 缺点：前端工作量较大，同时接口的具体细节要暴露出来。
2. 完全由Native处理（Native将每一个接口，都封装成相应的方法，供前端调用）
- 优点：简单直接，避免向前端暴露接口的具体细节。
- 缺点：过于依赖Native端，业务变化可能还是会导致App必须升级，违背了混合开发的初衷。
3. Native端抽象出主要的方法，前端将请求和参数透传给Native（京东微联类似这种方式）
- 优点：只需要提供几个统一的方法，便能包含各种操作，比如控制设备（controlDevice），获取设备状态（getDevice）、定时（timming）等。
- 缺点：设计困难，可能还会牵扯到后台。
