WKWebViewJavascriptBridge 简介

WKWebViewJavascriptBridge - 优雅的 iOS 与 JS 交互层框架（Swift）

WKWebViewJavascriptBridge 能为你做什么?

你可以通过使用 WKWebViewJavascriptBridge 书写几行代码实现混合模块，而无需关心底层的 iOS 与 JS 消息传递实现。

其实在阅读 WebViewJavascriptBridge 源码时就发现其为了兼容 Mac OS X 的 WebView 与 iOS 中的 UIWebView 和 WKWebView 三个组件而被迫沿用拦截 Request 的方式实现 iOS 与 JS 之间的消息传递。

当时就在想目前所处的时间节点正式 WKWebView 的时代，应该针对 WKWebView 来独立封装一个 Bridge 层级的框架，但是由于种种原因（主要是懒，笑）一直没有付诸实践。

直到发现了 UIWebView 跨域访问漏洞 之后，才下定决心写 WKWebViewJavascriptBridge 框架。

至于为什么要用 Swift 作为 WKWebViewJavascriptBridge 的实现语言？主要是因为 Swift 3.2 - 4.0 的迁徙变化已经比较小了，可以认为 Swift 逐步趋于稳定（好吧，我承认就是因为最近看 Swift 比较多，想提高自己的 Swift 水平）。

众所周知，WKWebView 比 UIWebView 加载网页的速度更快，效率更高，且没有太多的内存开销。

在当前时间节点，大多数 iOS App 都是基于 iOS 9.0+ 的，这是一个 WKWebView 的时代。

iOS 平台跨域访问漏洞成因是由于 UIWebView 默认开启了WebKitAllowUniversalAccessFromFileURLs 和 WebKitAllowFileAccessFromFileURLs 选项。

相比之下，WKWebView 默认 allowFileAccessFromFileURLs 和 allowUniversalAccessFromFileURLs 选项为 false。

关于更多 UIWebView 跨域访问漏洞，点击这里了解更多。

Swift 的支持：Swift 3.2 ~ 4 的支持。
高性能：消息传递性能高于传统实现方式（拦截 Requests）。
高速：无需考虑 Alert Box 安全超时。
轻量：框架除去自动生成的 .h 仅有 3 个文件。
非侵入性：无需改写 webView 的继承基类（这里假设当前时间节点下大部分 iOS App 已经完成了从 UIWebView 到 WKWebView 的迁徙，反正早晚要做这件事不是吗？）。

关于 WKWebViewJavascriptBridge 对于 Objective-C 的支持，我有以下看法（适用于所有 Swift 框架）：

项目初期，欢迎 PR！

补充~ 我建了一个技术交流微信群，想在里面认识更多的朋友！如果各位同学对文章有什么疑问或者工作之中遇到一些小问题都可以在群里找到我或者其他群友交流讨论，期待你的加入哟~

Emmmmm..由于微信群人数过百导致不可以扫码入群，所以请扫描上面的二维码关注公众号进群。