前言

现在混合式开发有好几种，一种就是 Hybrid，一种是 RN，一种是原生内嵌 RN 或 Weex。那你们公司目前是采用哪一种呢？3 月 21 号早读文章来自百度 @ 三水清的授权分享。

正文从这开始～

Hybrid开发中，web页面往往会跟native进行交互，而JSBridge就是web页面和native进行通信的桥梁，通过JSBridge可以实现web调用native的方法，native可以通过 webview.loadUrl之类的方法，将 javascript:xxx代码放在页面执行，这有点类似在浏览器地址栏直接输入： javascript:xxx

JSBridge多种形式

web和native进行通信，方法有很多，接下来一一列举一下JSBridge的多种形式，及其利弊。

JavaScriptInterface

js Interface 直接注入到window对象

JSInterface是安卓4.2-官方推荐的解决方案，原理是通过WebView提供的 addJavascriptInterface方法给浏览器 window注入一个命名空间，然后给Web增加一些可以操作Java 的反射。

mWebView.addJavascriptInterface(new Class(),'android');
public class Class(){
    @JavascriptInterface  
        public void method(){
    }
}
window.android.method();

JSInterface在4.2之前的版本都可以，但是存在严重的安全隐患，容易被利用提权，从而调用各种Java的类和权限，甚至页面可以挂马。在我们实际产品（手机百度）开始阶段，用过这个方法，不过现在已经不使用了。

改写浏览器原有对象

这个方法主要是通过修改原来浏览器的 window某些方法，然后拦截固定规则的参数，然后分发给Java对应的方法去处理。这里常用的是以下四个方法：

alert，可以被webview的 onJsAlert监听
confirm，可以被webview的 onJsConfirm监听
console.log，可以被webview的 onConsoleMessage监听
prompt，可以被webview的 onJsPrompt监听

prompt简单举例说明，Web页面通过调用 prompt()方法，安卓客户端通过监听 onJsPrompt事件，拦截传入的参数，如果参数符合一定协议规范，那么就解析参数，扔给后续的Java去处理。这种协议规范，最好是跟iOS的协议规范一样，这样跨端调起协议是一致的，但具体实现不一样而已。比如： hybrid://action?arg1=1 这样的协议，而其他格式的 prompt参数，是不会监听的，即除了 hybrid://action?arg1=1 这样的规范协议， prompt还是原来的 prompt。

这四个方法也是各有利弊，比如：

alert/ console.log是调试最常用的，如果你要看看协议是不是写错了，但是传入协议却被拦截了。。

confirm和 prompt都带返回值， prompt是四个里面唯一可以自定义返回值，可以做同步的交互，要比写各种回调更「顺」，但是一旦串行调用了，就要骂爹了

prompt是我们目前安卓用的比较多的JSBridge解决方案。

URL scheme

这个叫法不是特别贴切，scheme是URI的一种格式，上文提到的 hybrid://action?arg1=1就是一个scheme协议，这里说的scheme（或者schema）泛指安卓和iOS的schema协议，因为它通用。

安卓和iOS都可以通过拦截跳页URL请求，然后解析这个scheme协议，符合约定规则的就扔个Native的方法处理。安卓和iOS分别用到拦截URL请求的方法是：

安卓：shouldOverrideUrlLoading方法

iOS：UIWebView的delegate函数

唤起APP技术

上文介绍到的JSBridge是在APP内的Web页面跟APP进行交换，还有一种特别多的需求，就是在APP外（浏览器、微信等）调起APP自己，给APP进行导流。这时候就要用到APP的唤起技术。这里有一下几种方法：

intent：安卓
localserver：安卓
Universal links：iOS 9+
Deep link/Applink：安卓
smart app banner：iOS

安卓intent

intent格式示例如下：

intent:
HOST/URI-path
#Intent;
package=[string];
action=[string];
category=[string];
component=[string];
scheme=[string];
S.xxx=xxx
end;

第一部分：host和path是跟url无异

第二部分：#intent到end是完整的intent，包含了调起的app包名，action等是常用的配置项

因为Intent不仅仅是调起APP，而是安卓客户端内部模块通信也会用，所以权限很大，一般浏览器都给封掉了，

安卓localserver

这是一个黑科技，早前安卓允许在本地启动一个本地server，这个server是在后台守候的，通过这个localserver都可以进行各种需求：app间通信、app调起、收集数据、基础服务。百度的moplus就是这样的一个localserver。

举例说明：启动一个本地server，端口号是： 8888，那么在手机上，网页就可以通过： http://127.0.0.1:8888 访问这个server，server接收到请求就可以进行一些native的操作，对于需要回调数据的，就通过返回请求内容来执行，比如：

获取个定位信息，js执行 $.get(‘http://127.0.0.1:8888/getGeoLocation?callback=cbname‘)

server收到请求之后，调用native方法，获取GPS的定位信息，然后将数据通过response： window.cbname&&cbname({xxx})给页面返回定位数据

如果控制不好权限，因为localserver是一直后台守候的，容易被利用，比如提权获取通讯录、甚至给通讯录发短信、容易造成蠕虫攻击，感兴趣的可以搜下moplus的文章。另外安卓各种安全软件，都会清理内存和后台程序，很容易被干掉进程。浏览器也会封杀本地server调起，碰见127.0.0.1的请求就直接拦截。

Universal links / Deep link / Applink

这三个是官方推荐的调起方法，调起协议格式也是可以统一的，比如前文提到的 hybrid://action?arg1=xxx这类scheme协议就是。这样可以统一安卓和iOS调起和JSBridge通信。

其实简单来说，这三个出发点是想给应用做分发，但是如果用户手机没有安装这个APP，那么就调起失败，这时候直接不管不问，肯定体验不好，而且浪费了点击资源，那么做成分发吧！将调起协议做成一个调起页面，放到一个域名下，点击这个URL就可以打开这个页面，页面执行代码调起APP，如果调起失败就展现APP的介绍，做分发。

Universal links / Deep link / Applink，就是这样的一个过程，通过这个域名授权，把URL分发给APP进行处理，唯一不同的是：如果用户安装了APP，那么就不用打开这个分发页面了。

Universal Links

iOS 9新出的一个功能，需要在App内声明一个https域名（ul.test.com），然后在该网站根目录放置apple-app-site-association文件，文件指明了转发规则，例如：

{
  "applinks":{
    "apps":[],
    "details":[
      {
        "appID":“xxx.com.baidu.SomeApp”,
        "paths": ["*"]
      }
    ]
  }
}

当APP安装成功之后，会下载这个文件，明确知道遇见 ul.test.com的域名的URL时候，会把这个URL扔给你的APP，让你去解析，APP拿到这个URL就可以解析出来需要做什么事情。

Universal Link是iOS 9+的底层实现，所以在任何地方都可以直接调起APP，不受微信这类封闭APP的限制。

Deep link / Applink

Deep link 是安卓一开始推出的，主要用于搜索调起APP，后来推出 Applink，实际是Deep link的升级版。

这里需要提到微信的APPlink，毕竟微信作为SuperApp，是很大的分发资源，微信有自己的分发方法，安卓内可以申请微信的APPlink，跟Universal link一样，也是一个域名下面的URL，符合一定规则就由微信（ios是底层系统）扔个对应的域名APP进行解析。

smart app banner

在页面的head中添加下面meta，在Safari浏览器中就会出现下面的banner
AppStore

JSBridge安全

在APP内JSBridge可以实现Web和Native的通信，但是如果APP打开一个恶意的页面，页面可以任意调用JSBridge方法，获取各种隐私的数据，就会引起安全问题。

JSBridge的安全有两个方法：通过Native进行白名单配置，通过Server云端授权。Server的云端授权这块，放到后续JSSDK的设计部分进行详细讲解。本文主要说下通过Native的方式来控制JSBridge的安全。

假设JSBridge的协议格式如下：

hybrid://action/method?arg1=xxx&arg2=xxx

可以通过下面方式进行安全设置：

配置某些方法的使用范围，比如固定的Webview，固定的domain

通过正则来设置细化的权限，比如：baidu.com网页可以使用 ，hao123.com可以使用： hybrid://hao123/

JSBridge的最佳实践

介绍了这么多，什么是最佳实践的JSBridge呢？结合文章内容，要求JSBridge做到以下几点：
官方认可，不走「歪门邪道」

跨平台通用
APP内和APP外规范通用
安全可靠
约定大于配置的原则

综合上文介绍的内容，JSBridge的最佳实践是：

协议规范都使用： hybrid://action/method?arg1=xxx&arg2=xxx
iOS使用Universal Link和UIWebview的delegate
安卓使用shouldOverrideUrlLoading和Applink

协议规范

先贴个URL scheme的图片，理解下URL的组成部分：

URL scheme

约定我们的规范如下：

yourappscheme://module/action?arg1=x&arg2=x&ios_version=xxx&andr_version=xxx&upgrade=1/0&callback=xxx&sendlog=1/0

整体小写
yourappscheme：就是你的scheme，可辨识，别冲突，通过这个可以进行Universal Link和Applink的分发
module和action：某个模块组件的某个方法
?后面是querystring，这里预定了几个特殊的参数：

ios_version/andr_version：非必须，iOS和安卓的最小版本，即本协议从哪个版本开始支持的，低版本不支持则忽略，配合upgrade使用进行APP升级
upgrade：是否强制升级，即当版本低于设置的ios/andr_version是否弹出提示用户升级的对话框（yourappscheme已经可以调起app，只不过功能可能因为版本低不支持，这时候可以引导用户升级）
callback：异步回调函数，下面详细树下callback的最佳实践
sendlog：调起后是否打点发送日志

举例：

# 账号相关
## 打开用户个人主页
fb://account/userprofile?id=xxx
## 打开登录界面
fb://account/login?callback=xxx
# 工具类
## 获取定位
fb://utils/getgeolocation?callback=xx

callback的设计

当native操作成功之后，会将处理结束后的结果或者数据通过 callback回调传给Web，当然有成功就又失败， callback的参数设计有两种方式：

错误优先

即下面的回调方法格式：

function callback(error,data){
  if(error){
    throw error
  }
  console.log(data)
}

JSON API式

即回调方法只接收一个JSON对象，JSON格式如下：

{
  error_code:0,
  data:{}
}

预留升级/日志能力

做APP开发经常会遇见下面的问题：

功能/端能力是从某个版本开始的，低版本用不了，但是scheme还是会调起APP（APP懵逼）
对于低版本，PM希望提示用户升级，统计调起成功率，分发次数之类的统计需求
问题解决：
scheme的querystring部分由 ios_version/andr_version和upgrade这三个成对的参数，可以解决升级问题，sendlog解决日志统计问题。

ios_version/andr_version：是标示该协议的最低支持版本，如果低于这个版本可能因为功能并未实现而能识别。
upgrade：是是否强制低版本弹出升级对话框
sendlog：当为1的时候，则发送调起成功失败之类的统计需求

简单JSBridge调用封装

简单封装下JSBridge调用的方法，参数如下：

module：类名称，如果account
action：具体操作方法，如login
args：非必须，协议参数，支持string和对象
callback：非必须，回调单独提出来，方便全局方法命名

具体代码如下

function invoke (module,action,args,callback){
  let scheme =yourappscheme://${module}/${action}?
  if(isFunction(args)){
    callback =args
    args =null
  }
  if(isString(args)){
    scheme += args
  }else if(isObject(args)){
    each(args, (k, v)=>{
      if(isObject(v)|| isArray(v)){
        v = JSON.stringify(v)
      }
      scheme +=${k}=${v}
    })
  }
  if(isFunction(callback)){
    var funcName ='jsbridge_cb'+ getId()
    window[funcName]=function(){
      callback.apply(window, ([]).slice.call(arguments, 0))
    }
    scheme += (!~scheme.indexOf('?') ? '&' : '?') + callback=${funcName}
  }
  if (os.ios && versionCompare(os.version, '9.0')>=0){
    window.location.href =scheme
  }else{
    var $node = document.createElement('iframe')$node.style.display = 'none'
    $node.src = scheme
    var body = document.body || document.getElementsByTagName('body')[0]
    body.appendChild($node)
    setTimeout(function(){
      body.removeChild($node)$node = null
    }, 10)
  }
}

总结

介绍了JSBridge常用的方法，然后介绍了APP外如何唤起APP，还介绍了scheme协议，最后比较了优缺点，做个最佳实践。希望有用~

最后，你还可以看看：

【第626期】浅谈Hybrid技术的设计与实现

关于本文作者：@三水清（ID：三水清）原文：http://dwz.cn/5zm9Yr

偏前端开发实用技能

Hybrid 开发：JsBridge

前言

JSBridge多种形式

JavaScriptInterface

改写浏览器原有对象

URL scheme

唤起APP技术

安卓intent

安卓localserver

Universal links / Deep link / Applink

Universal Links

Deep link / Applink

smart app banner

JSBridge安全

JSBridge的最佳实践

协议规范

callback的设计

预留升级/日志能力

简单JSBridge调用封装

总结