簡單分析Cordova for iOS

時間 2019-11-11

標籤簡單分析 cordova ios 欄目 Cordova 简体版

原文原文鏈接

一.PhoneGap的簡單介紹java

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

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

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

　　（1）JS 怎麼跟 Objective-C 通訊web

　　（2）Objective-C 怎麼跟 JS 通訊數據庫

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

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

二.JS 怎麼跟 Objective-C 通訊app

1.JS 與 Objetive-C 通訊的關鍵代碼以下：（cordova.js）ide

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";
        }
    }
  ...
}

2.JS 使用了兩種方式來與 Objective-C 通訊

　　XMLHttpRequest 發起請求的方式;

　　經過設置透明的 iframe 的 src 屬性;

下面詳細介紹一下兩種方式是怎麼工做的:

(1)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 類的子類)的方法中：

+ (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

(2)iframe bridge

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

// 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;
    }
    ...
}

(3)Objective-C 怎麼跟 JS 通訊

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

獲取 JS 的請求數據

- (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 端

- (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];
    }
}

(4)怎麼串聯起來

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

// successCallback : 成功回調方法
// failCallback    : 失敗回調方法
// server          : 所要請求的服務名字
// action          : 所要請求的服務具體操做
// actionArgs      : 請求操做所帶的參數
cordova.exec(successCallback, failCallback, service, action, actionArgs);

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

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

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

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

關鍵代碼以下：

unction 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 後，會作如下的處理：

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

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

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

關鍵代碼：

- (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];
}

// 根據 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 收到結果的時間)。每一個真機我作了三組測試，每組連續測試十次，每組測試前我都會把機器重啓，結果以下：