为何放弃第一种方案
UIWebView的JSContext获取
上篇中,我们通过简单的kvc获取UIWebVIew的JSContext,但是实际上,apple并未给开发者提供访问UIWebView的方法,虽然通过KVC可达到目标,但是当APP采用该种hack方法时,有很大几率不能通过APP Store的审核,这对于一个基于上线的商业APP而言是难以忍受的,所以我们必须寻找另一种方法来获取UIWebView的JSContext而且足够安全易用,因此我们需转移目光。
解决
WebFrameLoadDelegate
在OS X中,WebFrameLoadDelegate负责WebKit与NSWebView的通信,由于NSWebView内部仍然使用WebKit渲染引擎,若要侦听渲染过程中的一系列事件,则必须使用WebFrameLoadDelegate对象:
1、加载过程:
在一个访问一个网页的的整个过程,包括开始加载,加载标题,加载结束等。webkit都会发送相应的消息给WebFrameLoadDelegate 。
webView:didStartProvisionalLoadForFrame:开始加载,在这里获取加载的url
webView:didReceiveTitle:forFrame:获取到网页标题
webView:didFinishLoadForFrame:页面加载完成
2、错误的处理:
加载的过程当中,有可能会发生错误。错误的消息也会发送给WebFrameLoadDelegate 。我们可以在这两个函数里面对错误信息进行处理
webView:didFailProvisionalLoadWithError:forFrame: 这个错误发生在请求数据之前,最常见是发生在无效的URL或者网络断开无法发送请求
webView:didFailLoadWithError:forFrame: 这个错误发生在请求数据之后
可是在iOS中呢?我尝试过,并没有WebFrameLoadDelegate这个对象,看来iOS中的WebKit框架并未提供UIWebView这么多的接口,但是有些人通过WebKit的源码还是发现了一二,他就是Nick Hodapp。
Nick的发现
在iOS中,尽管没有暴露WebFrameLoadDelegate,但是在具体实现上仍会判断WebKit的implement有没有实现这个协议的某些方法,如果实现则仍会执行,而且在webit的WebFrameLoaderClient.mm文件中,
if (implementations->didCreateJavaScriptContextForFrameFunc) {
CallFrameLoadDelegate(implementations->didCreateJavaScriptContextForFrameFunc, webView, @selector(webView:didCreateJavaScriptContext:forFrame:),
script.javaScriptContext(), m_webFrame.get());
}
会判断当前的对象有没有实现webView:didCreateJavaScriptContext:forFrame:
方法,有则执行。该方法会传递三个参数,第一个是与webkit通信的WebView(此WebView并不是UIWebVIew,Nick层做过测试通过获取的WebView并不能遍历到我们需要的UIWebVIew,因此推测,这个WebView是一个UIView的proxy对象,不是UIView类);第二个则是我们想要获取的JSContext;第三个参数是webkit框架中的WebFrame对象,与我们的期望无关。
为了让webkit执行这个函数,我们必须让对象实现这个方法。由于所有的OC对象都继承自NSObject对象,因此我们可以在NSObject对象上实现该方法,这样可以保证该段代码可以在webkit框架中执行。
其次,我们既然获取到了JSContext,但是并不知道JSContext与UIWebVIew的对应关系,我们的ViewController中可能会有多个UIWebView,如何将获取的JSContext与UIWebview对应起来也是一个难题。在此处有一个简单的方法,就是获取所有的UIWebView对象,在每个对象中执行一段js代码,在js上下文设置一个变量做为标记,然后在我们获取的JSContext中判断该变量是否与遍历的UIWebVIew对象中的对象是否相等来获取。这样,我们可以在UIWebView的webViewDidStartLoad和webViewDidFinishLoad之间获取到JSContext,进行oc和js的双向通信。
完善
我们通过上节的阐述,大致明白了Nick的思路,因此可以通过协议和类别来完成这种通信机制,当然采用oc运行时也是可以的。最终oc端接口的代码放在webView:didCreateJavaScriptContext:forFrame:
中,这样js文件只需加载完毕就可执行oc的接口方法;而oc端要访问js的接口则可在webVIewDidFinishLoad中执行,完美解决接口访问时机
的问题。
在js端,由于只有暴露在全局的函数声明
才能够让oc端访问,这就限制了js端的灵活性。我尝试过在js端通过“赋值”完成接口的暴露(window.say = function(){alert("hello world!")};),在oc端无法访问,只有通过普通的函数声明才能解决问题,这可能与JSContext的内存指针引用相关,为了解决此问题,我通过创建一个全局函数来暴露js端的接口对象,通过获取的对象来访问具体的接口方法。
if(isiOS4JSC){
// 将注册的方法透出到window.jscObj的属性上
var ev = eval;
$.JSBridge._JSMethod = method;
// 暴露函数至全局
// jsc只能执行全局函数声明方式定义的函数,不可以将函数指针复制给其他变量执行
ev('function toObjectCExec() {' +
'window.jscObj = window.jscObj ? window.jscObj : {};'+
'window.jscObj["' + methodName + '"] = function (message) {' +
' var ret = $.JSBridge._JSMethod(message);' +
' return JSON.stringify(ret);' +
'};' +
'return jscObj;' +
'}');
}
如此,js端的接口暴露就很容易了。
尾声
我现在仍然相信,目前的iOS hybridAPP的主流通信方式仍然适corava的javascriptWebViewBridge,但是随着jsc引入到iOS7中,本文介绍的使用jsc(嵌入js引擎的方式)来完成oc和js的通信将更为流行,尽管目前apple提供的针对jsc的开发接口文档几乎没有,但是我们通过webkit的源码做一些hack的方式也不是不可以,毕竟只要UIWebView仍然使用webkit进行渲染,这种方式会一直有效,除非apple在代码层面针对hack做过滤,不过这种可能性真的很小。我们有理由憧憬未来在iOS和android下更方便的集成js引擎来完成建议的双向通信。