我们知道，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回调。

与简单框架相比，兔子洞框架的实现有几个关键点：

1. Rabbit接口可传递js function，用作回调callback处理。
2. Hole层为每个callback生成一id，并保存到Map中；Hole调用Native时，会传递这个id，Native处理完成后，回调到Hole时，需要传递这个id，Hole根据id找到对应的function，并进行调用，实现回调。
3. Rabbit层和Hole层主要通过JS实现，Native端在使用WebView时需要注入rabbit.js和hole.js。

总结

简单的Web-Native交互框架能够很好地实现Web和Native之间的交互，虽然简单，但是普适性和扩展性比较强。
平台级Web-Native交互框架解决的是Native应用作为一个容器，为Web提供指定的本地功能，适用平台级产品，如轻应用分发器。