Cordova for iOS

Cordova，對這個名字你們可能比較陌生，你們確定聽過 PhoneGap 這個名字，Cordova 就是 PhoneGap 被 Adobe 收購後所改的名字。

 

Cordova 是一個可讓 JS 與原生代碼(包括 Android 的 java，iOS 的 Objective-C 等)互相通訊的一個庫，而且提供了一系列的插件類，好比 JS 直接操做本地數據庫的插件類。

 

這些插件類都是基於 JS 與 Objective-C 能夠互相通訊的基礎的，這篇文章說說 Cordova 是如何作到 JS 與 Objective-C 互相通訊的，解釋如何互相通訊須要弄清楚下面三個問題：

 

JS 怎麼跟 Objective-C 通訊

Objective-C 怎麼跟 JS 通訊

JS 請求 Objective-C，Objective-C 返回結果給 JS，這一來一往是怎麼串起來的

Cordova 如今最新版本是 2.7.0，本文也是基於 2.7.0 版本進行分析的。

 

JS 怎麼跟 Objective-C 通訊

 

JS 與 Objetive-C 通訊的關鍵代碼以下：(點擊代碼框右上角的文件名連接，可直接跳轉該文件在 github 的地址)

 

JS 發起請求 cordova.js 

 

function iOSExec() {

  ...

  if (!isInContextOfEvalJs && commandQueue.length == 1)  {

      // 若是支持 XMLHttpRequest，則使用 XMLHttpRequest 方式

      if (bridgeMode != jsToNativeModes.IFRAME_NAV) {

            // This prevents sending an XHR when there is already one being sent.

            // This should happen only in rare circumstances (refer to unit tests).

            if (execXhr && execXhr.readyState != 4) {

                execXhr = null;

            }

            // Re-using the XHR improves exec() performance by about 10%.

            execXhr = execXhr || new XMLHttpRequest();

            // Changing this to a GET will make the XHR reach the URIProtocol on 4.2.

            // For some reason it still doesn't work though...

            // Add a timestamp to the query param to prevent caching.

            execXhr.open('HEAD', "/!gap_exec?" + (+new Date()), true);

            if (!vcHeaderValue) {

                vcHeaderValue = /.*\((.*)\)/.exec(navigator.userAgent)[1];

            }

            execXhr.setRequestHeader('vc', vcHeaderValue);

            execXhr.setRequestHeader('rc', ++requestCount);

            if (shouldBundleCommandJson()) {

              // 設置請求的數據

                execXhr.setRequestHeader('cmds', iOSExec.nativeFetchMessages());

            }

            // 發起請求

            execXhr.send(null);

        } else {

          // 若是不支持 XMLHttpRequest，則使用透明 iframe 的方式，設置 iframe 的 src 屬性

            execIframe = execIframe || createExecIframe();

            execIframe.src = "gap://ready";

        }

    }

  ...

}

JS 使用了兩種方式來與 Objective-C 通訊，一種是使用 XMLHttpRequest 發起請求的方式，另外一種則是經過設置透明的 iframe 的 src 屬性，下面詳細介紹一下兩種方式是怎麼工做的：

 

XMLHttpRequest bridge

 

JS 端使用 XMLHttpRequest 發起了一個請求：execXhr.open('HEAD', "/!gap_exec?" + (+new Date()), true); ，請求的地址是 /!gap_exec；並把請求的數據放在了請求的 header 裏面，見這句代碼：execXhr.setRequestHeader('cmds', iOSExec.nativeFetchMessages()); 。

 

而在 Objective-C 端使用一個 NSURLProtocol 的子類來檢查每一個請求，若是地址是 /!gap_exec 的話，則認爲是 Cordova 通訊的請求，直接攔截，攔截後就能夠經過分析請求的數據，分發到不一樣的插件類(CDVPlugin 類的子類)的方法中：

 

UCCDVURLProtocol 攔截請求UCCDVURLProtocol.m 

 

 

+ (BOOL)canInitWithRequest:(NSURLRequest*)theRequest

{

    NSURL* theUrl = [theRequest URL];

    NSString* theScheme = [theUrl scheme];

 

  // 判斷請求是否爲 /!gap_exec

    if ([[theUrl path] isEqualToString:@"/!gap_exec"]) {

        NSString* viewControllerAddressStr = [theRequest valueForHTTPHeaderField:@"vc"];

        if (viewControllerAddressStr == nil) {

            NSLog(@"!cordova request missing vc header");

            return NO;

        }

        long long viewControllerAddress = [viewControllerAddressStr longLongValue];

        // Ensure that the UCCDVViewController has not been dealloc'ed.

        UCCDVViewController* viewController = nil;

        @synchronized(gRegisteredControllers) {

            if (![gRegisteredControllers containsObject:

                  [NSNumber numberWithLongLong:viewControllerAddress]]) {

                return NO;

            }

            viewController = (UCCDVViewController*)(void*)viewControllerAddress;

        }

 

      // 獲取請求的數據

        NSString* queuedCommandsJSON = [theRequest valueForHTTPHeaderField:@"cmds"];

        NSString* requestId = [theRequest valueForHTTPHeaderField:@"rc"];

        if (requestId == nil) {

            NSLog(@"!cordova request missing rc header");

            return NO;

        }

          ...

    }

    ...

}

Cordova 中優先使用這種方式，Cordova.js 中的註釋有說起爲何優先使用 XMLHttpRequest 的方式，及爲何保留第二種 iframe bridge 的通訊方式:

 

// XHR mode does not work on iOS 4.2, so default to IFRAME_NAV for such devices.

// XHR mode’s main advantage is working around a bug in -webkit-scroll, which

// doesn’t exist in 4.X devices anyways

 

iframe bridge

 

在 JS 端建立一個透明的 iframe，設置這個 ifame 的 src 爲自定義的協議，而 ifame 的 src 更改時，UIWebView 會先回調其 delegate 的 webView:shouldStartLoadWithRequest:navigationType: 方法，關鍵代碼以下：

 

UIWebView攔截加載CDVViewController.m 

// UIWebView 加載 URL 前回調的方法，返回 YES，則開始加載此 URL，返回 NO，則忽略此 URL

- (BOOL)webView:(UIWebView*)theWebView

          shouldStartLoadWithRequest:(NSURLRequest*)request

          navigationType:(UIWebViewNavigationType)navigationType

{

    NSURL* url = [request URL];

 

    /*

     * Execute any commands queued with cordova.exec() on the JS side.

     * The part of the URL after gap:// is irrelevant.

     */

    // 判斷是否 Cordova 的請求，對於 JS 代碼中 execIframe.src = "gap://ready" 這句

    if ([[url scheme] isEqualToString:@"gap"]) {

        // 獲取請求的數據，並對數據進行分析、處理

        [_commandQueue fetchCommandsFromJs];

        return NO;

    }

    ...

}

Objective-C 怎麼跟 JS 通訊

 

熟悉 UIWebView 用法的同窗都知道 UIWebView 有一個這樣的方法 stringByEvaluatingJavaScriptFromString:，這個方法可讓一個 UIWebView 對象執行一段 JS 代碼，這樣就能夠達到 Objective-C 跟 JS 通訊的效果，在 Cordova 的代碼中多處用到了這個方法，其中最重要的兩處以下：

 

獲取 JS 的請求數據

獲取 JS 的請求數據CDVCommandQueue.m 

 

- (void)fetchCommandsFromJs

{

    // Grab all the queued commands from the JS side.

    NSString* queuedCommandsJSON = [_viewController.webView

                                      stringByEvaluatingJavaScriptFromString:

                                          @"cordova.require('cordova/exec').nativeFetchMessages()"];

 

    [self enqueCommandBatch:queuedCommandsJSON];

    if ([queuedCommandsJSON length] > 0) {

        CDV_EXEC_LOG(@"Exec: Retrieved new exec messages by request.");

    }

}

把 JS 請求的結果返回給 JS 端

把 JS 請求的結果返回給 JS 端CDVCommandDelegateImpl.m 

 

- (void)evalJs:(NSString*)js scheduledOnRunLoop:(BOOL)scheduledOnRunLoop

{

    js = [NSString stringWithFormat:

                  @"cordova.require('cordova/exec').nativeEvalAndFetch(function(){ %@ })",

                  js];

    if (scheduledOnRunLoop) {

        [self evalJsHelper:js];

    } else {

        [self evalJsHelper2:js];

    }

}

 

- (void)evalJsHelper2:(NSString*)js

{

    CDV_EXEC_LOG(@"Exec: evalling: %@", [js substringToIndex:MIN([js length], 160)]);

    NSString* commandsJSON = [_viewController.webView

                              stringByEvaluatingJavaScriptFromString:js];

    if ([commandsJSON length] > 0) {

        CDV_EXEC_LOG(@"Exec: Retrieved new exec messages by chaining.");

    }

 

    [_commandQueue enqueCommandBatch:commandsJSON];

}

 

- (void)evalJsHelper:(NSString*)js

{

    // Cycle the run-loop before executing the JS.

    // This works around a bug where sometimes alerts() within callbacks can cause

    // dead-lock.

    // If the commandQueue is currently executing, then we know that it is safe to

    // execute the callback immediately.

    // Using    (dispatch_get_main_queue()) does *not* fix deadlocks for some reaon,

    // but performSelectorOnMainThread: does.

    if (![NSThread isMainThread] || !_commandQueue.currentlyExecuting) {

        [self performSelectorOnMainThread:@selector(evalJsHelper2:)

                              withObject:js

                           waitUntilDone:NO];

    } else {

        [self evalJsHelper2:js];

    }

}

怎麼串起來

 

先看一下 Cordova JS 端請求方法的格式：

 

// successCallback : 成功回調方法

// failCallback    : 失敗回調方法

// server          : 所要請求的服務名字

// action          : 所要請求的服務具體操做

// actionArgs      : 請求操做所帶的參數

cordova.exec(successCallback, failCallback, service, action, actionArgs);

傳進來的這五個參數並非直接傳送給原生代碼的，Cordova JS 端會作如下的處理：

 

會爲每一個請求生成一個叫 callbackId 的惟一標識：這個參數需傳給 Objective-C 端，Objective-C 處理完後，會把 callbackId 連同處理結果一塊兒返回給 JS 端

以 callbackId 爲 key，{success:successCallback, fail:failCallback} 爲 value，把這個鍵值對保存在 JS 端的字典裏，successCallback 與 failCallback 這兩個參數不須要傳給 Objective-C 端，Objective-C 返回結果時帶上 callbackId，JS 端就能夠根據 callbackId 找到回調方法

每次 JS 請求，最後發到 Objective-C 的數據包括：callbackId, service, action, actionArgs

關鍵代碼以下：

 

JS 端處理請求cordova.js 

 

function iOSExec() {

    ...

  // 生成一個 callbackId 的惟一標識，並把此標誌與成功、失敗回調方法一塊兒保存在 JS 端

    // Register the callbacks and add the callbackId to the positional

    // arguments if given.

    if (successCallback || failCallback) {

        callbackId = service + cordova.callbackId++;

        cordova.callbacks[callbackId] =

            {success:successCallback, fail:failCallback};

    }

 

    actionArgs = massageArgsJsToNative(actionArgs);

 

  // 把 callbackId，service，action，actionArgs 保持到 commandQueue 中

  // 這四個參數就是最後發給原生代碼的數據

    var command = [callbackId, service, action, actionArgs];

    commandQueue.push(JSON.stringify(command));

    ...

}

 

// 獲取請求的數據，包括 callbackId, service, action, actionArgs

iOSExec.nativeFetchMessages = function() {

    // Each entry in commandQueue is a JSON string already.

    if (!commandQueue.length) {

        return '';

    }

    var json = '[' + commandQueue.join(',') + ']';

    commandQueue.length = 0;

    return json;

};

原生代碼拿到 callbackId、service、action 及 actionArgs 後，會作如下的處理：

 

根據 service 參數找到對應的插件類

根據 action 參數找到插件類中對應的處理方法，並把 actionArgs 做爲處理方法請求參數的一部分傳給處理方法

處理完成後，把處理結果及 callbackId 返回給 JS 端，JS 端收到後會根據 callbackId 找到回調方法，並把處理結果傳給回調方法

關鍵代碼：

 

Objective-C 返回結果給 JS 端CDVCommandDelegateImpl.m 

- (void)sendPluginResult:(CDVPluginResult*)result callbackId:(NSString*)callbackId

{

    CDV_EXEC_LOG(@"Exec(%@): Sending result. Status=%@", callbackId, result.status);

    // This occurs when there is are no win/fail callbacks for the call.

    if ([@"INVALID" isEqualToString : callbackId]) {

        return;

    }

    int status = [result.status intValue];

    BOOL keepCallback = [result.keepCallback boolValue];

    NSString* argumentsAsJSON = [result argumentsAsJSON];

 

  // 將請求的處理結果及 callbackId 經過調用 JS 方法返回給 JS 端

    NSString* js = [NSString stringWithFormat:

                              @"cordova.require('cordova/exec').nativeCallback('%@',%d,%@,%d)",

                              callbackId, status, argumentsAsJSON, keepCallback];

 

    [self evalJsHelper:js];

}

JS 端根據 callbackId 回調cordova.js 

 // 根據 callbackId 及是否成功標識，找到回調方法，並把處理結果傳給回調方法

 callbackFromNative: function(callbackId, success, status, args, keepCallback) {

        var callback = cordova.callbacks[callbackId];

        if (callback) {

            if (success && status == cordova.callbackStatus.OK) {

                callback.success && callback.success.apply(null, args);

            } else if (!success) {

                callback.fail && callback.fail.apply(null, args);

            }

 

            // Clear callback if not expecting any more results

            if (!keepCallback) {

                delete cordova.callbacks[callbackId];

            }

        }

    }

通訊效率

 

Cordova 這套通訊效率並不算低。我使用 iPod Touch 4 與 iPhone 5 進行真機測試：JS 作一次請求，Objective-C 收到請求後不作任何的處理，立刻把請求的數據返回給 JS 端，這樣能大概的測出一來一往的時間(從 JS 發出請求，到 JS 收到結果的時間)。每一個真機我作了三組測試，每組連續測試十次，每組測試前我都會把機器重啓，結果以下：

 

iPod Touch 4(時間單位：毫秒)：

組\序號 第1次 第2次 第3次 第4次 第5次 第6次 第7次 第8次 第9次 第10次 組平均時間

第一組 10 11 8 13 11 9 14 13 9 12 11.0

第二組 33 13 9 13 11 8 14 12 15 37 15.2

第三組 20 19 9 16 11 17 13 9 10 8 13.2

這三十次測試的平均時間是：(11.0 + 15.2 + 13.2) / 3 = 13.13 毫秒

 

iPhone 5(時間單位：毫秒)

組\序號 第1次 第2次 第3次 第4次 第5次 第6次 第7次 第8次 第9次 第10次 組平均時間

第一組 3 3 4 2 3 2 3 2 2 3 2.7

第二組 7 2 2 2 2 3 2 2 2 4 2.8

第三組 6 3 2 3 2 2 2 3 2 2 2.7

這三十次測試的平均時間是：(2.7 + 2.8 + 2.7) / 3 = 2.73 毫秒

 

這通訊的效率雖然比不上原生調原生，可是也是屬於可接受的範圍了。