objC与js通信实现--WebViewJavascriptBridge

场景

  在移动端开发中，最为流行的开发模式就是hybmid开发，在这种native和h5的杂糅下，既能在某些需求中保证足够的性能，也可以在某些列表详情的需求下采用h5的样式控制来丰富内容。但是在大型产品的开发中，往往前端的职责不仅仅是h5的编写，还包括基本业务逻辑的实现，比如在h5页面中确定当前用户所在的城市（location），我们可以采用html5规范的Geolocation接口，但是更为通俗的做法是调用native的本地接口，因此这种常规的场景就涉及到了js和native层通信的问题，这在手淘开发中经常遇到，手淘提供了中间层windvane（jsBridge）来完成通信，不过由于windvane特殊性并未开源，因此本文着重分析WebViewJavascriptBridge框架（针对iOS）的通信机制。

突破口

  iOS下h5页面承载在webView视图中，webView提供比较特殊的接口是stringByEvaluatingJavaScriptFromString方法，它让js字符串在当前的webview提供的js全局上下文中执行脚本，因此我们通过在objC层调用stringByEvaluatingJavaScriptFromString，执行h5下js得相关函数，以返回值的形式获取js端提供的相关调用函数数组并在webview下的上下文中执行函数数组，最终完成objC->js的通信（调用）。
  js调用objC则有些特殊，不过依然利用stringByEvaluatingJavaScriptFromString方法实现基本通信，并在objC层针对webviewDelegate接口提供的webView:shouldStartLoadWithRequest:navigationType方法进行捕获js层的调用。具体的方法是通过创建一个隐藏的iframe并对其src按照既定的schema格式赋值，并在objC层的webView:shouldStartLoadWithRequest:navigationType判断schema是否正确，如正确，则加载执行相关脚本，否则不执行。

源码分析

objC层调用js层注册函数：

   - (void)sendData:(id)data responseCallback:(WVJBResponseCallback)responseCallback handlerName:(NSString*)handlerName {
     NSMutableDictionary* message = [NSMutableDictionary dictionary];
   
     if (data) {
         message[@"data"] = data;
     }
   
     if (responseCallback) {
         NSString* callbackId = [NSString stringWithFormat:@"objc_cb_%ld", ++_uniqueId];
         self.responseCallbacks[callbackId] = [responseCallback copy];
         message[@"callbackId"] = callbackId;
     }
   
     if (handlerName) {
         message[@"handlerName"] = handlerName;
     }
     [self _queueMessage:message];
   }

  参数data为传递给js层函数的参数，可为NSString、NSDictionary等对象，responseCallback则为objC层的回调，此回调函数执行流程简述为“js层注册函数执行完毕后，会返回带有responseId的消息，最后在objC层取出（回调存储在responseCallbacks字典中）对应的回调（即此处的responseCallback），并执行”，handlerName则为js层定义的函数名称。
  源码中在_queueMessage方法进行逻辑判断：若在h5页面或者js资源并未加载完毕时，在objC层webview中就调用了js函数，则会把相关的操作（存储为Message格式）存储在startupMessageQueue，等待相关资源加载完毕（即在webview的webViewDidFinishLoad生命周期函数中执行存储在startupMessageQueue的命令数组，执行完毕并清空该队列）再调用js层函数；否则若startupMessageQueue队列为空，则直接执行暴露在js端的webViewJavascriptBridge._handleMessageFromObjC函数，获取被调用的函数名和传入参数，以及在objC层sendData:responseCallback:handlerName中设置的回调函数id--callbackId，最终执行js层注册函数，并最终向objC层发送“_doSend({ responseId:callbackResponseId, responseData:responseData })”格式的消息，待objC接收到消息，解析responseId，执行回调函数。

    // 在objC端调用，用作ref
    function _dispatchMessageFromObjC(messageJSON) {
	setTimeout(function _timeoutDispatchMessageFromObjC() {
		var message = JSON.parse(messageJSON)
		var messageHandler
		var responseCallback

        // js调用objC成功后，objC返回带有responseId的消息，在js端执行回调
	if (message.responseId) {
		responseCallback = responseCallbacks[message.responseId]
		if (!responseCallback) { return; }
		responseCallback(message.responseData)
		delete responseCallbacks[message.responseId]
	} else {
                // objC调用js后，构造返回给objC的消息
		if (message.callbackId) {
			var callbackResponseId = message.callbackId

                        // 执行回调成功后，选择性返回给objC
			responseCallback = function(responseData) {
				_doSend({ responseId:callbackResponseId, responseData:responseData })
			}
		}
				
		var handler = WebViewJavascriptBridge._messageHandler
		if (message.handlerName) {
			handler = messageHandlers[message.handlerName]
		}
				
		try {
			handler(message.data, responseCallback)
		} catch(exception) {
			if (typeof console != 'undefined') {
				console.log("WebViewJavascriptBridge: WARNING: javascript handler threw.", message, exception)
			}
		}
	   }
    })

  js触发objC调用是从_doSend函数开始的，主要就是通过给iframe设置schema完成：

    var CUSTOM_PROTOCOL_SCHEME = 'wvjbscheme'
    var QUEUE_HAS_MESSAGE = '__WVJB_QUEUE_MESSAGE__'
    // js调用objC，通过对webview设置schema拦截
    // 拦截成功后，通过在objC端evaluateJs的_fetchQueue()来获取传入的参数
    function _doSend(message, responseCallback) {
	if (responseCallback) {
		var callbackId = 'cb_'+(uniqueId++)+'_'+new Date().getTime()
		responseCallbacks[callbackId] = responseCallback
		message['callbackId'] = callbackId
	}
	sendMessageQueue.push(message)
	messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE
    }

  由此可见，schema的格式为“wvjbscheme://WVJB_QUEUE_MESSAGE”,objC在webview的代理方法中webView:shouldStartLoadWithRequest:navigationType侦听schema格式，进而判断是否执行js的命令。

js层调用objC层注册函数

  正如上节提到，在webView:shouldStartLoadWithRequest:navigationType中侦听schema格式，判断是否消息是否来自js层的函数调用：

    - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:   (UIWebViewNavigationType)navigationType {
      if (webView != _webView) { return YES; }
      NSURL *url = [request URL];
      __strong WVJB_WEBVIEW_DELEGATE_TYPE* strongDelegate = _webViewDelegate;
      if ([_base isCorrectProcotocolScheme:url]) {
          if ([_base isCorrectHost:url]) {
              NSString *messageQueueString = [self _evaluateJavascript:@"WebViewJavascriptBridge._fetchQueue();"];
              [_base flushMessageQueue:messageQueueString];
          } else {
              [_base logUnkownMessage:url];
          }
          return NO;
      } else if (strongDelegate && [strongDelegate respondsToSelector:@selector(webView:shouldStartLoadWithRequest:navigationType:)]) {
          return [strongDelegate webView:webView shouldStartLoadWithRequest:request navigationType:navigationType];
      } else {
          return YES;
      }
    }

  若消息来自于js层，则在webview上下文执行WebViewJavascriptBridge._fetchQueue()函数，该函数的定义为

    function _fetchQueue() {
	var messageQueueString = JSON.stringify(sendMessageQueue)
	sendMessageQueue = []
	return messageQueueString
    }

  _fetchQueue返回js端的调用命令队列messageQueueString，并在objC层执行flushMessageQueue:messageQueueString方法，将调用命令数组序列化，并执行objC层定义的函数，这个调用的过程类似上节中objC调用js层定义的函数，也是当objC层定义的函数执行完后，向js层触发消息，消息格式依然和上节“js向objC发送的消息格式一样，形如{ responseId:callbackResponseId, responseData:responseData }”，当js层接收到消息，执行js层的回调函数。
  因此综上来看，不管objC和js如何通信，最为关键的就是stringByEvaluatingJavaScriptFromString方法，它构建起了objC和js通信的基石，“objC可以直接通过该方法调用js函数，js也可让objC通过该方法获取js的调用队列，从而在objC层执行命令”。

总结

  上文提到的仅仅是大体的通信机制，具体的实现细节仍有很多需要注意，比如如何在js端侦听通信组件的初始化事件、应该在何时在objC层调用js定义的函数、objC发送消息中序列化特殊字符等等，但是通信的机制可以通过本文略知一二。