来由
纯粹的无聊，一直在搜索JavaScriptCore和SpiderMonkey的一些信息，却无意中学习了如何在ios的UIWebView中判断其js解析引擎的方法：
if (window.devicePixelRatio) { //If WebKit browser
var st = escape(navigator.javaEnabled.toString());
if (st === 'function%20javaEnabled%28%29%20%7B%20%5Bnative%20code%5D%20%7D') {
document.write('V8 detected');
} else {
document.write('JSC detected');
}
} else {
document.write("Not a WebKit browser");
}
只需上述一串代码，在ios中自然是JavaScriptCore的内核，在安卓下是v8引擎。
在之前的文章objC与js通信实现--WebViewJavascriptBridge中，讲述了cordova的桥接机制－通过UIWebView的stringbyEvaluateJavascriptString方法通信，但是通过这个借口，虽然我们可以采用内置的jsc引擎执行js代码，但是无法进行更细粒度，深入到javascript运行时来执行代码，最直接的表现就是“无法在oc端对执行的js进行错误控制，如异常处理机制”。通过额外引入或链接javascriptCore，可以在c层次与iOS进行通信，效率提高很大。
对比
1，在iOS中通过UIWebView组件的stringByEvaluateJavascriptString:(NSString *)方法来调用。但是这种方式有几个弊端：
1）oc调用js有返回值，属于同步调用；而js调用oc是通过创建iframe并设置src，oc端的UIWebVIew拦截请求，然后再通过stringByEvaluateJavascriptString执行js端的方法，获取js的参数（序列化的json字符串），在oc端进行反序列化，最后调用oc的函数；
2）oc端的stringByEvaluateJavascriptString在执行js代码时会阻塞js端代码的执行；
3）通过1）的流程可看出，通过UIWebView实现的bridge机制性能堪忧，交互蛋疼；
4）通过UIWebView执行js代码段，有几点限制：由于ios并未给予我们通过UIWebView访问javascript运行时的权限，因此即使通过stringByEvaluateJavascriptString执行错误的js代码，我们在oc端仍无法获取错误消息，更无从谈起回调函数；不过，这种方式的好处就是没有涉及到内存管理。
2，目前有三种方案实现oc与js通信，第一种继续使用cordova的通信机制，也就是目前比较流行的UIWebView；第二种采用React Native的通信机制，使用iOS7内置的javascriptCore引擎并在js，oc两层搭建桥接层，并且每层持有2份相同的配置表，每个表中都记录js，oc透出的API，并结合iOS的事件机制完成oc和js的互调；第三种则仍是采用iOS7内置的javascriptCore框架，不同于React Native的是使用jsc提供的通信机制，这套机制类似于android下WebView编码方式，oc端只需实现JSExpose协议，就将实现该协议的对象透到当前的上下文中，如在UIWebView控件中就为改webview对应的上下文，即使h5页面切换，上下文仍是不变，可以理解为一个单例。
3, 综上三种方案，第一种代价最低，而且流程比较完善，而且已经系统化，但是性能是硬伤；第二种则是非常好的借鉴，RN的方式不仅仅适用于javascriptCore，而且也适用于其他引擎如SpiderMonkey，但是如果要采用RN的方案可能需要更多时间来搞清楚具体的实现细节和技巧，难度略大；第三种则是比较而言比较无害而且实现难度并不算大的方案，目前尚妆iOS下只适配iOS7以上的设备，因此我们不需要针对iOS6及以下设备做兼容（引入第三方的javascriptCore），而且通过使用内置的js引擎和oc进行通信，在c／c++层面的效率将会大大提高（相比较UIWebview而言），缺点则是可能目前采用的bridge通信方式需要重新来过，架构重新设计。