我们知道，Native也就是通常所说的App，拥有好的本地特性，也可以方便地访问本地设备，并且具有良好的用户交互性能，而Web具有好的动态性扩展性和跨平台特性。所有很多人都在尝试将两者结合起来，比如Hybrid，Facebook的React-Native，微信的JS-SDK。
本文主要想要探讨的是，一个使用Web方式来呈现业务功能的Native应用，如何更好地实现Web和Native之间的结合。本文的Native应用主要针对Android App。iOS原理类似，只是实现细节不同。
WebView JS交互接口
所谓交互，简单来说，就是双向调用。Web-Native之间的通信是双向的，即Native端和Web端互为调用者和被调用者。
在Android上，Native端使用WebView来展现Web页，WebView自身提供了与Web交互的接口。
Native调用Web
Native端作为调用者，它通过WebView注入JS的方式来实现Web接口的调用：
webview.evaluateJavascript()
或者早期接口
webview.loadUrl("javascript://...")
Web调用Native
JavascriptInterface方式
Native端作为被调用者，它是通过WebView的addJavascriptInterface接口实现Web端对它的回调。WebView内核层会为页面的window对象添加了一个属性，并将这个属性绑定到Native端的一个Java对象，页面使用这个属性访问到Java对象的方法，实现Web端对Native端的调用。
举个例子，在Native端，定义一个Java类JsCallbacker，并定义一个toast方法供Web端调用：
public class JsCallbacker extends LeContextContainer {
@JavascriptInterface
public void toast(final String msg) {
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
Toast.makeText(sContext, msg, Toast.LENGTH_LONG).show();
}
})
}
}
由于回调方法是在异步线程回调的，所以在回调中执行UI操作时需要抛到主线程执行。
注册JavascriptInterface对象
webView.addJavascriptInterface(new JsCallbacker(), "callbacker");
Web页JS调用：
window.callbacker.toast('This is webpage');
由于Android在4.2版本之前WebView的JavascriptInterface有漏洞，所以使用JavascriptInterface的方式是有限制的，在4.2版本之后回调方法加上@JavascriptInterface注解即可解决漏洞问题，但是4.2之前版本没有办法解决，需要使用别的方式。
prompt方式
Web端调用Native端的另一种安全可行的方式是，使用WebChromeClient的onJsPrompt回调。
public boolean onJsPrompt(WebView view, String url, String message,
String defaultValue, JsPromptResult result)
onJsPrompt回调接口原本是页面弹出提示用的，页面JS调用prompt方法时，WebView内核会将内容回传到onJsPrompt接口，这样Native可以弹出本地提示框。
我们可以利用这个接口来实现Web端对Native端的调用，只需要将prompt的内容约定为特定的格式，Web端按照这个格式生成内容，Native端在onJsPrompt接收到内容后按照这个格式进行解析，如果内容符合约定的格式，则作为Web-Native交互逻辑处理，否则作为增加的提示逻辑处理。
简单的Web-Native交互框架
当业务变得复杂时，Web端和Native端交互会很多，需要一个交互框架来支撑底层的交互逻辑，而业务层只需要关注业务的实现即可。
简单来说，Web-Native交互框架以事件驱动，完成事件的接收和解析，然后分发到对应的业务逻辑。
具体来说，包含以下几个部分：
事件数据结构
Native接口及事件分发
Web调用Native
Web接口
Native调用Web
事件数据结构
{
"type":type,
"data":data
}
事件数据结构是JSON结构，其中type表示事件的类型，data表示事件的数据。
prompt方式是一种兼容性更好的方式，Web-Native交互框架也基于这种方式。也就是事件需要通过prompt接口传递，为了与普通的提示信息区分，需要将传递的内容定义为特殊的格式。这里将真实的事件数据包裹在这个JSON结构中：
{
"gt_web_native_event":
{
"type":type,
"data":data
}
}
其中，gt_web_native_event是一个自定义的tag，我们假定正常的提示不会采用这种结构。在解析时，只有满足该格式的信息才被认定为是Web-Native交互信息。
Native接口及事件分发
在Native端， WebChromeClient提供底层回调，并向上传递到框架进行解析和分发。
@Override
public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {
return JsManager.getInstance().parseWebpageEvent(view, message, result);
}
框架通过JsManager来处理解析和分发。
解析接口：
public boolean parseWebpageEvent(WebView webView, String message, JsPromptResult result) {
WebpageEvent webpageData = WebpageEvent.parseWebpageData(message);
if (webpageData == null) {
return false;
}
String res = onWebpageEvent(webView, webpageData.mType, webpageData.mData);
if (result != null) {
result.confirm(res);
}
return true;
}
它将数据解析为事件WebpageEvent，同时交由onWebpageEvent接口进行分发。
public String onWebpageEvent(WebView webView, int type, String data) {
LeJavaScriptListener listener = mTypeListenerMap.get(type);
if (listener != null) {
return listener.onWebpageEvent(webView, type, data);
}
return "";
}
事件的分发是通过观察者来实现的，业务模块需要首先在JsManager注册感兴趣的事件，然后JsManager在事件产生时分发到对应的观察者。所有的事件都定义在JsManager中，防止事件冲突。
public void register(int type, JavaScriptListener listener) {
mTypeListenerMap.put(type, listener);
}
Web调用Native
框架在Web端由web_native.js实现，其中提供调用接口：
function invokeNative(type, data) {
var result = formPromptData(type, data);
return prompt(result);
}
Web页使用框架需要引入web_native.js，通过JS调用invokeNative接口。
Web接口
为了向Native提供调用接口，Web页面定义一个统一的JS接口：
function onNativeEvent(type, data)
业务逻辑在此function中完成。
Native调用Web
框架在Native端提供调用Web的接口，在JsManager中：
public static void invokeWeb(WebView webView, int type, String data)
平台级Web-Native交互框架
上面简单框架原理比较简单，但是有点冗余，尤其是需要在Web端业务层定义一个onNativeEvent接口。
通常来讲，Web-Native交互过程是这样的：
Web调用Native -> Native响应 -> Native调用Web
也就是Web端是一个发起点，在业务调用时应该同时定义好回调处理逻辑，没有必要再在onNativeEvent接口定义业务回调处理逻辑。
这里就产生了一个概念，平台级Web-Native交互框架。Native提供一系列本地功能接口，供Web端调用，类似于微信的JS-SDK。
这个框架我们命名为兔子洞框架（RabbitHole）。兔子洞框架分为四层：
Web层
Rabbit层
Hole层
Native层
Rabbit层主要负责为Web提供接口，并与Hole层交互。
Hole层与Native进行交互，调用Native和处理Native回调。
与简单框架相比，兔子洞框架的实现有几个关键点：
- Rabbit接口可传递js function，用作回调callback处理。
- Hole层为每个callback生成一id，并保存到Map中；Hole调用Native时，会传递这个id，Native处理完成后，回调到Hole时，需要传递这个id，Hole根据id找到对应的function，并进行调用，实现回调。
- Rabbit层和Hole层主要通过JS实现，Native端在使用WebView时需要注入rabbit.js和hole.js。
总结
简单的Web-Native交互框架能够很好地实现Web和Native之间的交互，虽然简单，但是普适性和扩展性比较强。
平台级Web-Native交互框架解决的是Native应用作为一个容器，为Web提供指定的本地功能，适用平台级产品，如轻应用分发器。
