Hybrid
架构的核心就是JSBridge
交互,而实现这个交互的前提是弄清楚H5和Native端的交互javascript
本文主要介绍Native端(Android/iOS)和H5端(泛指前端)的交互原理
(以前也整理过相似的文章,本系列从新梳理)html
Native
与H5
交互的两种方式原生和前端的交互有两种方式:url scheme
以及JavaScriptCore
(在Android中是addJavascriptInterface
)前端
url scheme适用于全部的系统设备(低版本Android和低版本iOS都适用)java
可是url scheme毕竟是经过url拦截实现的,在大量数据传输,以及效率上都有影响ios
另外一种方法则在低版本中会有这样或那样的问题git
如JavaScriptCore不支持iOS7
如下,addJavascriptInterface在4.2
之前有风险漏洞github
固然了,时至今日,这些低版本形成的影响已经慢慢再也不web
这个是最广为流传的交互方式,原由是由于在hybrid刚出来时,不少低版本都须要兼容,所以几乎都用的这种api
一些概念:安全
通常清空下,url scheme是一种相似于url的连接,是为了方便app直接互相调用设计的
具体为,能够用系统的OpenURI打开一个相似于url的连接(可拼入参数),
而后系统会进行判断,若是是系统的url scheme,则打开系统应用,
不然找看是否有app注册这种scheme,打开对应app
须要注意的是,这种scheme必须原生app注册后才会生效,如微信的scheme为(weixin://)
而本文中混合开发交互的url scheme则是仿照上述的形式的一种方式
具体为,由前端页面经过某种方式触发scheme(如用iframe.src),
而后Native用某种方法捕获对应的url触发事件,而后拿到当前的触发url,
根据定义好的协议,分析当前触发了那种方法,而后根据定义来执行等
协议相似于:quickhybrid://xxx
通常这种交互的url没有必要在原生app配置中注册
注意⚠️: ️iOS10
之后,urlscheme必须符合url规范,不然会报错,
基本原理:
H5 -> 触发一个url(每个功能表明的url都不一样)-> Native端捕获到url -> Native端分析属于哪个功能并执行 -> Native端调用H5中的方法将执行结果回调给H5
以下图:
相比于其它方案的优势:
Android4.2如下,addJavascriptInterface方式有安全漏掉
iOS7如下,JavaScriptCore没法使用
因此若是须要兼容这类型低版本的机型,url scheme方案是不二选择
分别包括Android,iOS中H5和原生互相调用,总结以下:
H5调Android-原生经过addJavascriptInterface
注册,而后H5直接调用
Android调H5-原生经过loadUrl
来调用H5,4.4
及以上还能够经过evaluateJavascript
调用
H5调iOS-原生经过JavaScriptCore
注册(需ios7
以上),而后H5直接调用
iOS调H5-经过stringByEvaluatingJavaScriptFromString
H5调Android:
首先,原生webview须要先注册可供前端调用的JS函数
WebSettings webSettings = mWebView.getSettings(); // Android容器容许JS脚本,必需要 webSettings.setJavaScriptEnabled(true); // Android容器设置侨连对象 mWebView.addJavascriptInterface(getJSBridge(), "JSBridge");
// Android4.2版本及以上,本地方法要加上注解@JavascriptInterface,不然会找不到方法。 private Object getJSBridge(){ Object insertObj = new Object(){ @JavascriptInterface public String foo(){ return "foo"; } @JavascriptInterface public String foo2(final String param){ return "foo2:" + param; } }; return insertObj; }
而后H5中便可调用原生中注册的函数
// 调用方法一 window.JSBridge.foo(); // 返回:'foo' // 调用方法二 window.JSBridge.foo2('test'); // 返回:'foo2:test'
注意:
在Android4.2
以上(api17后),暴露的api要加上注解@JavascriptInterface
,不然会找不到方法。
在api17之前,addJavascriptInterface有风险,hacker能够经过反编译获取Native注册的Js对象,
而后在页面经过反射Java的内置静态类,获取一些敏感的信息和破坏
Android调H5:
在4.4
版本以前
// 即当前webview对象 mWebView = new WebView(this); mWebView.loadUrl("javascript: 方法名('参数,须要转为字符串')"); // ui线程中运行 runOnUiThread(new Runnable() { @Override public void run() { mWebView.loadUrl("javascript: 方法名('参数,须要转为字符串')"); Toast.makeText(Activity名.this, "调用方法...", Toast.LENGTH_SHORT).show(); } });
在4.4
及之后(包括)
// 异步执行JS代码,并获取返回值 mWebView.evaluateJavascript("javascript: 方法名('参数,须要转为字符串')", new ValueCallback<String>() { @Override public void onReceiveValue(String value) { // 这里的value即为对应JS方法的返回值 } });
注意:
4.4以前Native经过loadUrl来调用JS方法,只能让某个JS方法执行,可是没法获取该方法的返回值
4.4及以后,经过evaluateJavascript异步调用JS方法,而且能在onReceiveValue中拿到返回值
mWebView.loadUrl("javascript: 方法名('参数,须要转为字符串')");
函数需在UI线程运行,由于mWebView为UI控件(可是有一个坏处是会阻塞UI线程)
H5调iOS:
以OC
为例
首先,须要引入JavaScriptCore
库
#import <JavaScriptCore/JavaScriptCore.h>
而后原生须要注册API
//webview加载完毕后设置一些js接口 -(void)webViewDidFinishLoad:(UIWebView *)webView{ [self hideProgress]; [self setJSInterface]; } -(void)setJSInterface{ JSContext *context =[_wv valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]; // 注册名为foo的api方法 context[@"foo"] = ^() { //获取参数 NSArray *args = [JSContext currentArguments]; NSString *title = [NSString stringWithFormat:@"%@",[args objectAtIndex:0]]; //作一些本身的逻辑 //返回一个值 'foo:'+title return [NSString stringWithFormat:@"foo:%@", title]; }; }
以后前端就能够调用了
// 调用方法,用top是确保调用到最顶级,由于iframe要用top才能拿到顶级 window.top.foo('test'); // 返回:'foo:test'
注意:
引入官方提供的JavaScriptCore库(iOS7中出现的),而后能够将api绑定到JSContext上
(而后Html中JS默认经过window.top.*(iframe
中时需加top
)可调用)
iOS7以前,js没法直接调用Native,只能经过urlscheme方式间接调用
iOS调H5:
// 能够取得JS函数执行的返回值 // 方法必须是Html页面绑定在最顶层的window上对象的 // 如window.top.foo // Swift webview.stringByEvaluatingJavaScriptFromString("方法名(参数)") // OC [webView stringByEvaluatingJavaScriptFromString:@"方法名(参数);"];
注意:
Native调用JS方法时,能拿到JS方法的返回值
有iframe时,须要获取顶层窗口的引用
github
上这个框架的实现