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对象：
        一、加载过程：
在一个访问一个网页的的整个过程，包括开始加载，加载标题，加载结束等。webkit都会发送相应的消息给WebFrameLoadDelegate 。

webView:didStartProvisionalLoadForFrame:开始加载，在这里获取加载的url
              webView:didReceiveTitle:forFrame:获取到网页标题
              webView:didFinishLoadForFrame:页面加载完成

        二、错误的处理：
加载的过程中，有可能会发生错误。错误的消息也会发送给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引擎来完成建议的双向通讯。