轉自: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篇文章,都寫得很好: