iOS引入JavaScriptCore引擎框架(二)为何放弃第一种方案UIWebView的JSContext获取上篇中,我们通过简单的kvc获取UIWebVIew的JSContext,但是实际上,apple并未给开发者提供访问UIWebView的方法,虽然通过KVC可达到目标,但是当APP采用该种hack方法时,有很大几率不能通过APP Store的审核,这对于一个基于上线的商业APP而言是难以忍受的,所以我们必须寻找另一种方法来获取UIWebView的JSContext而且足够安全易用,因此我们需转移目光。 解决WebFrameLoadDelegate 在OS X中,WebFrameLoadDelegate负责WebKit与NSWebView的通信,由于NSWebView内部仍然使用WebKit渲染引擎,若要侦听渲染过程中的一系列事件,则必须使用WebFrameLoadDelegate对象:
2、错误的处理:
可是在iOS中呢?我尝试过,并没有WebFrameLoadDelegate这个对象,看来iOS中的WebKit框架并未提供UIWebView这么多的接口,但是有些人通过WebKit的源码还是发现了一二,他就是Nick Hodapp。 Nick的发现在iOS中,尽管没有暴露WebFrameLoadDelegate,但是在具体实现上仍会判断WebKit的implement有没有实现这个协议的某些方法,如果实现则仍会执行,而且在webit的WebFrameLoaderClient.mm文件中,
会判断当前的对象有没有实现 为了让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端接口的代码放在
如此,js端的接口暴露就很容易了。 尾声我现在仍然相信,目前的iOS hybridAPP的主流通信方式仍然适corava的javascriptWebViewBridge,但是随着jsc引入到iOS7中,本文介绍的使用jsc(嵌入js引擎的方式)来完成oc和js的通信将更为流行,尽管目前apple提供的针对jsc的开发接口文档几乎没有,但是我们通过webkit的源码做一些hack的方式也不是不可以,毕竟只要UIWebView仍然使用webkit进行渲染,这种方式会一直有效,除非apple在代码层面针对hack做过滤,不过这种可能性真的很小。我们有理由憧憬未来在iOS和android下更方便的集成js引擎来完成建议的双向通信。 分类: iOS,JavaScript
|
|