现如今，在做移动端?H5?开发时，少不了与?Native?之间进行交互。而在Native中，H5的承载容器为?WebView，其核心是使用?WebView?控件实现加载?url。

　　WebView的概念

　　WebView用来展示网页的?view组件，该组件是你运行自己的浏览器或者在你的线程中展示线上内容的基础。使用?Webkit渲染引擎来展示，并且支持前进后退等基于浏览历史，放大缩小，等更多功能。

　　简单来说?WebView是手机中内置了一款高性能?Webkit内核浏览器，在?SDK中封装的一个组件。不过没有提供地址栏和导航栏，只是单纯的展示一个网页界面。

　　以上是一个客户端开发者描述的，而站在一个前端开发者的角度，使用过后的感受就是：

　　WebView可以简单理解为页面里的?iframe。原生app与?WebView?的交互可以简单看作是页面与页面内?iframe页面进行的交互。就如页面与页面内的?iframe?共用一个?Window一样，原生与?WebView也共用了一套原生的方法。

　　既然我们使用了?WebView?来承载?H5?，那么便少不了与?Native?之间发生交互，?WebView?所承载的页面，通过?JS?与?Native?进行通信，我们将这个通信“桥梁”为?JSBridge?。如果你参与过微信内置浏览器的?H5?开发，会发现一个经常出现的东西，叫做?WeixinJSBridge。

　　JSBridge

　　JSBridge?简单来讲，主要是?给?Java?提供调用?Native?功能的接口，让混合开发中的『前端部分』可以方便地使用地址位置、摄像头甚至支付等?Native?功能。

　　既然是『简单来讲』，那么?JSBridge?的用途肯定不只『调用?Native?功能』这么简单宽泛。实际上，JSBridge?就像其名称中的『Bridge』的意义一样，是?Native?和非?Native?之间的桥梁，它的核心是?构建?Native?和非?Native?间消息通信的通道，而且是?双向通信的通道。

　　所谓?双向通信的通道:

　　JS?向?Native?发送消息?:?调用相关功能、通知?Native?当前?JS?的相关状态等。

　　Native?向?JS?发送消息?:?回溯调用结果、消息推送、通知?JS?当前?Native?的状态等。

　　Java?是运行在一个单独的?JS?Context?中(例如，WebView?的?Webkit?引擎、JSCore)。由于这些?Context?与原生运行环境的天然隔离，我们可以将这种情况与?RPC(Remote?Procedure?Call，远程过程调用)通信进行类比，将?Native?与?Java?的每次互相调用看做一次?RPC?调用。如此一来我们可以按照通常的?RPC?方式来进行设计和实现。

　　在?JSBridge?的设计中，可以把前端看做?RPC?的客户端，把?Native?端看做?RPC?的服务器端，从而?JSBridge?要实现的主要逻辑就出现了：?通信调用(Native?与?JS?通信)和?句柄解析调用。(如果你是个前端，而且并不熟悉?RPC?的话，你也可以把这个流程类比成?JSONP?的流程。)

　　通过以上的分析，可以清楚地知晓?JSBridge?主要的功能和职责，接下来，就分析一下在?Android?WebView?和?iOS?WebView?中实现?Native?与?JS?通信的原理。

　　Android?WebView

　　Android?4.4前：Android?WebView在低版本?&?高版本采用了不同的Webkit版本的内核(正因为如此，H5的很多新特性，在Android版本小于4.4的安卓机上，都不支持)

　　Android?4.4后：原本基于Webkit的WebView开始基于?Chromium内核，这一改动大大提升了?WebView组件的性能以及对?HTML5,?CSS3,?Java的支持。不过它的API却没有很大的改动，在兼容低版本的同时只引进了少部分新的API，并不需要你做很大的改动。

　　在?Android?WebView，要实现?JS?调用?Java，有?3?种?方法：

　　JavaInterface

　　WebViewClient.shouldOverrideUrlLoading

　　WebChromeClient.onXXX

　　1、JavaInterface

　　这是?Android?提供的?JS?与?Native?通信的官方解决方案。

　　首先?Native?端需要实现这么一个类，给?Java?调用。

　　publicclassWebAppInterface{?@JavaInterface?publicvoidshowToast(String?toast){?Toast.makeText(mContext,?toast,?Toast.LENGTH_SHORT).show;?}?}

　　然后将这个?WebAppInterface类，通过以下代码，添加到?WebView?的?JavaInterface?中。

　　WebView?webView?=?(WebView)?findViewById(R.id.webview);?webView.addJavaInterface(?newWebAppInterface(?this),?"Android");?//?这里的Android会被当做一个变量，注入到页面的window中。

　　接着就可以在?JS?中调用?Native?了。

　　functionshowAndroidToast(?toast)?{?Android.showToast(toast);?}

　　2、WebViewClient.shouldOverrideUrlLoading

　　这个方法的作用是拦截所有?WebView?的?URL?Scheme。

　　URL?Scheme是一种类似于?url?的链接，是为了方便?app?直接互相调用设计的，形式和普通的?url?近似，主要区别是?protocol?和?host?一般是自定义的。

　　拦截?URL?Scheme的主要流程是：Web?端通过某种方式(例如?iframe.src/location.href)发送?URL?Scheme?请求，之后?Native?拦截到请求并根据?URL?Scheme(包括所带的参数)进行相关操作。

　　页面可以构造一个特殊格式的?URL?Scheme触发，shouldOverrideUrlLoading?拦截?URL?后判断其格式，然后?Native?就能执行自身的逻辑了。

　　publicclassCustomWebViewClientextendsWebViewClient{?@Override?publicbooleanshouldOverrideUrlLoading(?WebView?view,?String?url?){?if(isJsBridgeUrl(url))?{?//?JSbridge的处理逻辑?returntrue;?}?returnsuper.shouldOverrideUrlLoading(view,?url);?}?}

　　3、WebChromeClient.onXXX

　　通过修改原来浏览器的?window某些方法，然后拦截固定规则的参数，然后分发给Java?对应的方法去处理

　　alert，可以被?WebView?的?WebChromeClient.onJsAlert?监听

　　confirm，可以被?WebView?的?WebChromeClient.onJsConfirm?监听

　　console.log，可以被?WebView?的?WebChromeClient.onConsoleMessage?监听

　　prompt，可以被?WebView?的?WebChromeClient.onJsPrompt?监听

　　prompt?简单举例说明，Web?页面通过调用?prompt方法，安卓客户端通过监听WebChromeClient.onJsPrompt事件，拦截传入的参数，如果参数符合一定协议规范，那么就解析参数，扔给后续的?Java?去处理。

　　window.prompt(message,?value);

　　WebChromeClient.onJsPrompt就会受到回调。onJsPrompt方法的?message参数的值正是JS的方法?window.prompt的?message的值。

　　publicclassCustomWebChromeClient?extendsWebChromeClient?{?@Override?publicbooleanonJsPrompt(?WebView?view,?Stringurl,?Stringmessage,?StringdefaultValue,?JsPromptResult?result?)?{?//?处理JS?的调用逻辑?result.confirm;?returntrue;?}?}

　　Java?调用?Java

　　Android，在?Kitkat(4.4)只能用?loadUrl?一段?Java?代码。

　　webView.loadUrl("?java:"?+?javaString);

　　而?Kitkat?之后的版本，也可以用?evaluateJava方法实现：

　　webView.evaluateJava(javaString,?newValueCallback<?String>?{?@Override?publicvoidonReceiveValue(?Stringvalue)?{?//?native代码?}?});

　　IOS?WebView

　　In?apps?that?run?in?iOS?8?and?later,?use?the?WKWebView?class?instead?of?using?UIWebView.?Additionally,?consider?setting?the?WKPreferences?property?javaEnabled?to?NO?if?you?render?files?that?are?not?supposed?to?run?Java.

　　在?IOS8?之前，苹果手机的?WebView?使用的?UIWebView，UIWebView长期以来存在某些问题：

　　加载速度慢

　　存在内存泄漏

　　内存占用多，内存优化困难

　　如果内存占用过多还可能因为占用过多被系统kill掉

　　在?WWDC?2014?大会上，IOS8推出了?WKWebView，WKWebView是现代?Webkit?API?在?iOS?8?和?OS?X?Yosemite?应用中的核心部分。它代替了?UIKit?中的?UIWebView和?AppKit?中的?WebView，提供了统一的跨双平台?API。拥有?60fps?滚动刷新率、内置手势、高效的?app?和?web?信息交换通道、和?Safari?相同的?Java?引擎。

　　Java?？？?Swift?对话机制

　　使用用户脚本来注入?Java

　　WKUser允许在正文加载之前或之后注入到页面中。这个强大的功能允许在页面中以安全且唯一的方式操作网页内容。

　　一个简单的例子如下，用户改变背景的用户脚本被插入到网页中：

　　letsource?=?"document.body.style.background?=?"#777;?//?注入脚本?在文档加载完成后执行?let?user?=?WKUser?let?user?=?WKUser(source:?source,?injectionTime:?.AtDocumentEnd,?forMainFrameOnly:?true)?let?userContentController?=?WKUserContentController?userContentController.addUser(user)

　　let?configuration?=?WKWebViewConfigurationconfiguration.userContentController?=?userContentControllerself.webView?=WKWebView(frame:?self.view.bounds,?configuration:?configuration)

　　对象可以以?Java?源码形式初始化，初始化时还可以传入是在加载之前还是结束时注入，以及脚本影响的是这个布局还是仅主要布局。于是用户脚本被加入到?WKUserContentController中，并且以?WKWebViewConfiguration属性传入到?WKWebView的初始化过程中。

　　这个样例可以简单扩展为更为高级的页面修改方法，例如去除广告、隐藏评论等。

　　Message?Handlers

　　利用以下代码，可以跟Native进行通信

　　window.webkit.messageHandlers.{NAME}.postMessage

　　Handler的name可以通过?WKMessageHandler协议中的?addMessageHandler接口函数设置：

　　classNotificationMessageHandler:?NSObject,?WKMessageHandler{?funcuserContentController(userContentController:?WKUserContentController,didReceiveMessage?message:?WKMessage!){?println(message.body)?}}letuserContentController?=?WKUserContentControllerlethandler?=?NotificationMessageHandleruserContentController.addMessageHandler(handler,?name:?"notification")

　　于是当通知进入?app?的时候，比如说在页面中创建一个新对象，相关信息就可以这样传递：

　　window.webkit.messageHandlers.notification.postMessage({?body:?'发送给Native'});

　　添加用户脚本来对?web?事件监听并用?Message?Handler?将信息传回?app。

　　总结

　　通信原理是?JSBridge?实现的核心，实现方式可以各种各样，但是万变不离其宗。这里，推荐的实现方式如下：

　　Java?调用?Native?推荐使用?注入?API?的方式。(?iOS6?忽略，Android?4.2以下使用?WebViewClient?的?onJsPrompt?方式。)

　　Native?调用?Java?则直接执行拼接好的?Java?代码即可。

　　对于其他方式，诸如?React?Native、微信小程序?的通信方式都与上描述的近似，并根据实际情况进行优化。

　　以?React?Native?的?iOS?端举例：Java?运行在?JSCore?中，实际上可以与上面的方式一样，利用注入?API?来实现?Java?调用?Native?功能。不过?React?Native?并没有设计成?Java?直接调用?Object-C，而是?为了与?Native?开发里事件响应机制一致，设计成?需要在?Object-C?去调?Java?时才通过返回值触发调用。原理基本一样，只是实现方式不同。