iOS引入JavaScriptCore引擎框架

摘要：在中，我们可以引入框架，这样，我们可以层来操作层代码的执行。都会发送相应的消息给。在端，由于只有暴露在全局的函数声明才能够让端访问，这就限制了端的灵活性。我们有理由憧憬未来在和下更方便的集成引擎来完成建议的双向通信。

    我们都知道WebKit是个渲染引擎，简单来说负责页面的布局，绘制以及层的合成，但是WebKit工程中不仅仅有关于渲染相关的逻辑，也集成了默认的javascript引擎－－JavaScriptCore，目前Safari的js引擎也基于JSC构建，不过有一些私有的优化，总体性能相差不大。JSC的执行理念比较符合传统的引擎逻辑，它包括了2部分：解释器和简单方法JIT。解释器比较容易理解，针对某种类型的文件解释执行，在JSC中，它的目标文件是由代码构建的语法树生成的字节码文件，类似于java中的字节码，不过在JSC中字节码的执行是在基于寄存器的虚拟机中而不是基于栈，好处在于可以方便的在ARM架构处理器中使用三地址指令，减少了次数较多的出栈和入栈等指令分派以及耗时的内存IO；JIT在java虚拟机中应用比较多，针对执行较多次的热点方法进行编译为本地方法，执行效率更高，JSC中的JIT同理。
    在iOS7中，我们可以引入JSC框架，这样，我们可以oc层来操作js层代码的执行。另外JSC暴露了许多C层面的接口，我们也可以在底层来构建自定义的js执行环境，操作执行js代码，可控执行可扩展性更强。

    既然有了这么给力的引擎，我们在构建hybrid app时可以使用JSC来代替cordova的webViewJavascriptBridge框架完成简易的接口暴露，未来在oc层逐渐可以将UI组件模块化，并通过JSExport暴露接口，由js层负责调用相应模块的初始化方法完成界面的hybrid化。
  oc端初始化一个js执行上下文JSContext对象很容易， [[JSContext alloc] init]即可，但是在hybrid app中，通过这种方式初始化JSContext与承载页面的UIWebVIew并不是同一个js环境，因此我们需要获取UIWebView对应的JSContext。但是apple官方并未提供相关的方法，不过这边难不倒某些人，有些人发现，通过KVC的方式可获取UIWebView对应的JSContext，方式如下[webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]。一旦获取到对应的JSContext，我们可以做的就有很多了。

// 获取对应的JSContext
JSContext *context=[webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];

// 设置JSContext的错误处理函数
[context setExceptionHandler:^(JSContext *context, JSValue *value) {
    NSLog(@"oc catches the exception: %@", value);
}];

// 组件化某个功能类或UIController   
ShowjoyFad *sf=[ShowjoyFad new];

// 暴露改类至JSContext中，在js层的全局属性中我们可以访问该类，如window.showjoyFad
context[@"showjoyFad"]=sf;
context[@"ViewController"] = self;

// 引用js层定义的函数
JSValue * abc = context[@"abc"];
// 执行
JSValue * ret = [abc callWithArguments:@[@"helloworld"]];
NSLog(@"ret: %@",[ret toString]);

    通过简单的例子可以很明显的看出JSC通信的简洁性，与android的WebView通信类似，native端可以直接讲接口注入到js上下文中，js在何时的时机调用函数。但是这里涉及到一个比较棘手的问题，JSContext的获取实在UIWebView的那个阶段呢？
    我做过一个测试：首先在UIWebView的webViewDidStartLoad阶段创建JSContext并暴露oc端的方法，在加载一级页面时js正常调用oc的方法，而跳转到二级页面中却无法执行oc的方法；而在webViewDidStartLoad阶段由于并未加载完js文件， 因此js层定义的函数在oc端无法执行。
    其次，在webVIewDidFinishLoad阶段创建JSContext并透出oc方法，由于加载js阶段在webVIewDidFinishLoad阶段之前，因此一级页面js无法调用oc方法，但是二级页面同理也是如此，但是由于js代码是在iOS的UI线程执行，因此为了让js可以调用oc方法，可以通过在js设置setTimeout来让任务放到执行队列的末端，先执行oc层的webVIewDidFinishLoad方法，待任务完成后再执行js中的异步代码，通过这种方式可以完成js调用oc方法；反过来，oc层调用js函数没有任何问题，因为在webVIewDidFinishLoad阶段js代码已执行完毕（除了异步代码）。
    为此，可以通过实现一个简易的框架来完成js层和oc层的交互，为了更好的兼容性，只有在webVIewDidFinishLoad阶段创建JSContext。而在js层则有两种方式来监测并执行oc的方法：

          1，在oc层的webVIewDidFinishLoad阶段，暴露oc接口之后，通过JSContext或者UIWebView的stringByEvluateJavascriptString方法构建一个```webViewDidFinishLoad```事件，js端进行侦听并调用
          2，简单的通过setTimeout将js的执行顺序排至队列末端

    通过上述方法，构建了一个简单的JSCBridge，但是缺点也很明显，对oc端接口暴露时机有硬性要求，并且js执行oc端的代码始终是异步，有违我们的初衷。

    上篇中，我们通过简单的kvc获取UIWebVIew的JSContext，但是实际上，apple并未给开发者提供访问UIWebView的方法，虽然通过KVC可达到目标，但是当APP采用该种hack方法时，有很大几率不能通过APP Store的审核，这对于一个基于上线的商业APP而言是难以忍受的，所以我们必须寻找另一种方法来获取UIWebView的JSContext而且足够安全易用，因此我们需转移目光。

    在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。

    在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引擎来完成建议的双向通信。