UIWebView时代，因为原生与Web端只能做到单向交互，WebViewJavascriptBridge框架便大显身手，其两端双向交互受到很多人的追捧和喜爱，更因其小巧、实现简单而成为了原生嵌入Web页面时的第一选择。
来到如今的WKWebView时代，其本身已经足够完善了，通过配置WKWebView的属性和实现WKWebView的代理方法，我们已经能够轻松掌控原生和Web端的双向交互了。在使用WKWebView的工程中，WebViewJavascriptBridge框架已经没有引入的必要了...
虽说现在的WKWebView强大到足以取缔WebViewJavascriptBridge框架，但是对优秀开源代码的学习，本身能让我们汲取到编程的养分和精髓。WebViewJavascriptBridge框架支持iOS、macOS双平台，它同时也支持UIWebView和WKWebView两个控件。
框架很小，总共才包含8个文件、4个实现文件。
下面是我通过阅读WebViewJavascriptBridge源码并站在UIWebView的视角而整理出来的框架原理流程图（图比较大建议查看原图哦）：
两端Bridge初始化流程图：
两端互相调用流程图：
这里只说一下要点，细节的阐述，有兴趣的朋友可以自己去看源码。（阅读源码时配合我这里的流程图，相信你会找到共鸣的声音！）：
- 原生和Web端的双向交互（互相调用对方的接口）本质上还是一种单向交互
- 这种单向交互都是通过UIWebView的stringByEvaluatingJavaScriptFromString方法实现的
- 原生调用Web端接口时，最后会直接调用stringByEvaluatingJavaScriptFromString方法完成
- Web端调用原生的接口时，会先把调用信息（接口名、实参、可能存在的回调id）存到Web端数组中，然后修改iframe的src属性，引起UIWebView的代理方法shouldStartLoadWithRequest执行，最后还是会通过stringByEvaluatingJavaScriptFromString方法取回Web端的调用信息，经解析执行原生端相应的接口代码
另注意：
原生和Web端的交互本质上并不是函数或方法之间的直接调用，而是双方之间在传递JSON格式的数据结构经序列化后的字符串（双方以JSON格式通信）。这个字符串中包含了要调用的接口名handlerName、传给接口的实参data、以及可能存在的回调callbackId。通信的另外一方接收到JSON字符串后反序列化解析数据，然后执行handlerName指定的接口代码
所以，你可以看到真正掌控一切的是stringByEvaluatingJavaScriptFromString方法。它强大到你无法想象，任何JS代码都可以通过它透传给Web端执行，它也可以从Web端带回JS函数执行后的返回结果，甚至连WebViewJavascriptBridge框架的Web端bridge的初始化JS代码都是通过它注入到Web端执行的...
最后说一下WebViewJavascriptBridge框架对WKWebView控件的处理。总体流程和对UIWebView是一样的。区别只有两点：
- 拦截URL的代理方法不是同一个，因为它们的代理方法不一样
- 那个神通广大的方法名不一样，WKWebView中叫 evaluateJavaScript
