淺析 Cordova for iOS

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

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

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

1. JS 怎麼跟 Objective-C 通訊
2. Objective-C 怎麼跟 JS 通訊
3. JS 請求 Objective-C，Objective-C 返回結果給 JS，這一來一往是怎麼串起來的

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

JS 怎麼跟 Objective-C 通訊

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

JS 發起請求 cordova.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// 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

1 2 3 4 5 6 7 8 9 10 11 12

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

- (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 端請求方法的格式：

1 2 3 4 5 6

// 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

關鍵代碼以下：

JS 端處理請求 cordova.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

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

1. 根據 service 參數找到對應的插件類
2. 根據 action 參數找到插件類中對應的處理方法，並把 actionArgs 做爲處理方法請求參數的一部分傳給處理方法
3. 處理完成後，把處理結果及 callbackId 返回給 JS 端，JS 端收到後會根據 callbackId 找到回調方法，並把處理結果傳給回調方法

關鍵代碼：

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

// 根據 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 毫秒

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