轉自:http://itindex.net/detail/50630-cordova-ios-native
很早以前寫了一篇博客，總結cordova插件怎麼調用到原生代碼： cordova調用過程，不過寫得太水，基本沒有提到原理。最近加深了一點理解，重新補充說明一下
js調用native
下面是我們產品中的代碼片段：
datePicker.show(options, function (date) {
var month = date.getMonth() + 1;
callback(null, date.getFullYear() + "-" + month + "-" + date.getDate());
});
cordova插件最終表現出來的都是js接口，並且調用者完全不需要知道自己在調用一個cordova插件
但是在任何cordova js方法內部，最後一定會調用cordova.exec函數：
cordova.exec(successCallback, errorCallback, "DatePicker", "show", []);
然後就進入了關鍵的cordova.exec函數，這是cordova框架的js端的最後一環，就是由它完成對ios native的調用
在exec函數裏，首先會判斷平臺，可能是android，ios或者wp，其他平臺本文省略，如果是ios平臺，cordova會採用以下2種方式的一種，來與ios native code交互
通過iframe
cordova.exec往當前的html中插入一個不可見的iframe，從而向UIWebView請求加載一個特殊的URL，這個URL裏當然就包含了要調用的native plugin的類名，方法名，參數，回調函數等信息
接下來，由於被請求加載URL，於是UIWebViewDelegate的這個方法被調用：
- (BOOL)webView:(UIWebView*)theWebView shouldStartLoadWithRequest:(NSURLRequest*)request navigationType:(UIWebViewNavigationType)navigationType
這裏就進入了native側，從request裏就拿到了js端傳過來的信息，然後調用到native plugin
通過XHR
另一種方式，cordova.exec裏直接發起一個XHR請求，被native側的NSURLProtocol攔截，於是調用到這個native方法：
+ (BOOL)canInitWithRequest:(NSURLRequest*)theRequest
也進入了native側，然後以同樣的方式調用到native plugin
在2種方式中，cordova會優先選擇XHR方式，只有當XHR方式不可用時，纔會使用iframe的方式。不過無論怎麼樣，這2種方法都爲從js到native打開了一條通道，剩下的就是傳遞參數和路由的問題了
native調用js
另一條通道就簡單的多，因爲iOS提供了原生支持，所以不需要想特別的辦法。即通過UIWebView的這個方法：
- (NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script;
看一下cordova框架native側的代碼，我去掉了註釋和無關代碼：
- (void)evalJsHelper:(NSString*)js
{
if (![NSThread isMainThread] || !_commandQueue.currentlyExecuting) {
[self performSelectorOnMainThread:@selector(evalJsHelper2:) withObject:js waitUntilDone:NO];
} else {
[self evalJsHelper2:js];
}
}
- (void)evalJsHelper2:(NSString*)js
{
NSString* commandsJSON = [_viewController.webView stringByEvaluatingJavaScriptFromString:js];
}
可以看到，正是通過UIWebView提供的這個方法完成的，但是，一定執行在main thread
同步和異步的問題
從上面的分析可以發現，從js調用native，2種方式都必定是異步的。而從native回到js，卻是一個同步的方法，而且是跑在主線程裏
調用cordova插件的代碼，對返回值的處理一定要放在回調函數裏，因爲結果是異步返回的。同時，回調函數的執行時間不能太長，否則會阻塞native主線程
參考
本文參考了以下2篇文章，都寫得很好：