Cordova框架的“曲线救国”

前言

《Cordova》框架你们应该都不陌生，它是用来构建JSBridge的一个框架，除了Cordova之外，咱们耳熟能详的还有《WebViewJavascriptBridge》框架也是用来解决这个问题。他们有个共同特色，就是不约而同的使用了URL拦截的方式构建的bridge。然而URL拦截的方式并不安全，可是这两个框架使用起来是安全的，那么以Cordova为例，它是怎么处理这个问题的？仍是说就没有处理？关于这个问题，实际上Cordova框架内部是作了处理的，本篇主要针对Cordova对于URL拦截方式进行通讯作了哪些优化（曲线救国）进行分析。

Cordova在iOS端是怎么通讯的，我以前的文章《iOS 源码解读 -- cordova-ios》讲的很清楚了，在iOS端主要是围绕着一个queue数组进行的，具体怎么进行的本篇不作分析了，具体能够看前面提到的文章了解下。

本篇主要围绕如下三点进行分析为何叫曲线救国：

• 1.js在给native发送假请求的时候作了什么
• 2.实际上js是怎样将各类参数传递给native的
• 3.pokeNative优化了什么

js在给native发送假请求的时候作了什么

真相都在cordova.js里面，做为一个未入门的前端来讲，对于cordova.js只能作一个简要分析，主要是针对上面提到的三点，看代码。

function iOSExec() {
    //删除了一些不在本篇讨论范围内的代码
    var command = [callbackId, service, action, actionArgs];
    commandQueue.push(JSON.stringify(command));
    if (!isInContextOfEvalJs && commandQueue.length == 1) {
        pokeNative();
    }
}
复制代码

在js端调用cordova插件的时候，代码会走进cordova.js里面的这个方法，push()函数实际上就是OC中的addObject:操做，commendQueue为cordova.js内维护的全局数组，commandQueue.push就是像commendQueue数组的最后面添加了一个对象，也就是被转为json格式的command对象。那么实际上在前端连续屡次频繁的调用插件的时候，插件的command信息都会被存储在commandQueue中而不是把每个通讯都要去作一个假请求。经过if (!isInContextOfEvalJs && commandQueue.length == 1)这个判断能够看到若是commandQueue中的调用次数不为一，也就是说可能有多个的时候，是不会执行pokeNatie()的，pokeNative实际为发送假请求的具体实现，后面会讲到。从而也就避免了插件被频繁调用所引发的通讯丢失的状况。

那么问题来了，插件的调用都被存储在了commandQueue中，native端怎么获取。这也是咱们要讨论的第二个问题。

实际上js是怎样将各类参数传递给native的

那么这个问题咱们须要分析下另外一个函数，看代码：

iOSExec.nativeFetchMessages = function() {
    if (failSafeTimerId) {
        clearTimeout(failSafeTimerId);
        failSafeTimerId = 0;
    }
    if (!commandQueue.length) {
        return '';
    }
    var json = '[' + commandQueue.join(',') + ']';
    commandQueue.length = 0;
    return json;
};
复制代码

这是native端收到cordova.js的pokeNative发出的假请求会调用的函数，这个json对象存储的正是commandQueue中的插件调用信息，那么不难看出，实际上Cordova内通讯参数并非在URL上传递，而是JS端告诉Native过来取，大概意思就是我这有好多都取过去吧。实际上只pokeNative()了一次，那么插件调用就都被native端取走了，这样也就避免了快速的频繁的发假请求而致使通讯丢失问题。

pokeNative优化了什么

实际上通过了上面两步，仍是不够安全的，由于有一种状况，那就是当前端的第一次调用恰好结束的时候发生了第二次调用，这个时候已经执行了commandQueue.length = 0;函数，也就是说commandQueue已经被清空了，那么就会执行pokeNative()函数，去发一个假请求给native端，这样就致使了连续的两次假请求发生。实际上这一块cordova.js也是作了处理的，详情在pokeNative()里面，看代码：

function pokeNative() {
    //代码删减部分
    failSafeTimerId = setTimeout(function() {
        if (commandQueue.length) {
            // CB-10106 - flush the queue on bridge change
            if (!handleBridgeChange()) {
                pokeNative();
             }
        }
    }, 50);
}
复制代码

setTimeout()函数在javaScript里面至关于添加了个定时器，也就是在50毫秒以后再执行pokeNative()函数，这样也就是作了一个50毫秒的间隔，从而避免了快速的两次调用。这一块pokeNative()函数内部代码注释也有解释，通讯效率会下降7%，可是毕竟这种状况很少，并且7%也在咱们能接受的范围内。

总结

经过上面的三部分，应该很明显的看到了为了构建这个bridge并保证他的安全性，是下了一番苦工的。基于URL拦截的方式，随着JSCore和WKWebView的新特性的出现也正在被逐渐的取缔，可是Cordova框架不仅仅给咱们提供了一种通讯方式，更多的是它的设计思想，以及对hybrid框架的交互设计理念，若是有一天须要咱们本身来作hybrid框架，我认为除了改变一下通讯方式之外，对于Cordova框架的其余部分都是很值得咱们去学习的。

本文属于原创，转载注明出处。