前言

基于前面的三篇，我们的Hybird框架基本搭建完成了，本篇在《写一个易于维护使用方便性能可靠的Hybrid框架（三）—— 配置插件》的基础上做了一些优化，后续又做了UIWebView的兼容。当下的跨平台方案很多，weex、RN到flutter层出不穷。那么对于WebView的探究是否仍有必要？实际上我们可以探究一下他们的根本，或许就不会有疑惑了。跨平台方案旨在节约成本，快速更新迭代，甚至达到热更新的能力。那么WebView面向的是谁呢，是整个前端开发者，构建web应用目前来看依旧是效率最快、范围最广、热更新能力最强的不二之选。市面上的App几乎都无法逃离WebView，从《支付宝移动端动态化方案实践》可以看出，支付宝也有一套自己的解决方案Nebula 框架，其实不止支付宝，所有的App自始至终都会有一套自己的WebView框架，与前面提到的跨端技术并不冲突，属于并驾齐驱。

那么今天要说的就是如何构建一个WebView的Hybrid框架，并让它独立于项目中，像AFN、SD一样存在于你的项目中，也并不会关联你的业务，像支付宝的Nebula一样，让它成为你项目组件的一部分。

接下来会从下面四个方面进行逐步分析，尽量多点干货。

目录

现状分析
治理方案
框架构建
总结

一、现状分析

前言部分基本阐述了当下为什么要构建WebView框架，就目前来看，每个项目应该都是前端和客户端混合开发，纯原生的项目已经退出历史了。就项目来看，h5构建在客户端内自然少不了要与客户端打交道。相信很多App还停留在使用原始拦截的方式进行JS和Native端的交互，通过定义好的某个协议进行拦截JS请求。这样的方式虽然简单，但缺点太多。

首先从技术层面来看，这样需要做队列控制连续的JS调用，防止通信丢失，这也是一个复杂的工作，而且效率低，其次通过假请求拦截，一旦请求参数拼接过于复杂还会产生一些其他的副作用，例如url过长参数无法被拦截，参数拼接后字符串截取出错等等。

备注一下：url拦截处理参数并非都是使用的这种方式，例如大名鼎鼎的《Cordova》和《WebViewJavaScriptBridge》都是使用的另外一种方式：曲线救国，增加一层JS侧来处理参数调度问题，而非直接拦截参数。

其次我们从业务的层面考虑，当需要通信的需求越来越多，WebView框架内的代码是否也会变得越来越冗余，掺杂的业务是否会变得越来越多，耦合是否越来越高等等。当我们有新的需求进来了是否要继续让WebView框架变得冗余？复用就更不可能了。

相信现在很多App在这一块还停留在上面的例子中，那么怎么解决这些问题？首先我们应该要有个好的通信方案，一个前卫的，先进的通信方案可以比作框架的心脏。

下面我们继续分析一下现在有什么通信方案更适合我们。

二、治理方案

治理方案这一块可以看下我的另一篇文章《写一个易于维护使用方便性能可靠的Hybrid框架（一）—— 思路构建》，主要讲了框架的构建思路，后两篇是对思路进行了延伸和进一步的优化。

目前看来在通信选择这一块有很多，简单阐明一下优缺点：

JS调用客户端：

1.假跳转拦截：也就是上面提到的，这应该是第一个被pass掉的方案，因为它不安全！就目前主流的开源来看，不论是大名鼎鼎的《Cordova》还是《WebViewJavaScriptBridge》都对它做了大量的操作，大量的操作，关于Cordova的操作可以参考我之前的文章《Cordova框架的“曲线救国”》
2.弹窗拦截：UIWebView不支持使用弹窗拦截JS。WKWebView支持confirm()/prompt()弹窗拦截，同步返回。
3.JavaScriptCore框架注入：这是一个异常强大的框架，iOS7开始支持，强大到RN都是依托于此，充满了很多黑魔法。具体它的使用可以参考《深入浅出 JavaScriptCore》，但是遗憾的是只有UIWebView支持它。WKWebView无法通过kvc获取JSContext，所以WK并不支持。
4.Messagehandler注入：addScriptMessageHandler:函数诞生于iOS8，伴随着WKWebView开放给开发者的，所以遗憾的是它只有WKWebView支持，但我把它理解为苹果通信这一块的亲儿子，毕竟苹果爸爸出品。

上面列出了所有的JS打到Native端的通信途径，如果我们必须要选择一个方案来实施，优先选择下面两种：

WKWebView首选Messagehandler注入：

[webView.configuration.userContentController addScriptMessageHandler:self name:@"WKJSBridge"];

- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {
    if ([message.body isKindOfClass:[NSArray class]]) {
        [_webViewhandleFactory handleMsgCommand:message.body];
    }
}

JS侧的调用也会非常简单，通过客户端注入的WKJSBridge就可以构建通信了：

window.webkit.messageHandlers.WKJSBridge.postMessage()

上面的代码就是Messagehandler方式的通信过程了，很简单，从代码中可以很清楚的看到什么是亲儿子的通信，再对比下曲线救国式的通信，对比就灰常明显了。WKJSBridge就是WKWebView注入的JS函数。实际上客户端就做了这么点工作就可以了，message.body可以是任意id类型对象，取决于JS端给客户端传递的是什么类型，demo中传递的是NSArray类型。

UIWebView首选JavaScriptCore框架：

原因JavaScriptCore功能异常强大，可以直接给JS注入一个函数让它调用，也可以直接给JS注入一个OC对象让JS使用，充满黑科技。不论是RN，还是Weex，都是基于此来构建的通信。具体使用可以通过《WKJavaScriptBridge》深入探究一下。

客户端主动调用JS：

1.evaluatingJavaScript:函数：只支持UIWebView，同步回调。
2.evaluateJavaScript:completionHandler:函数：只支持WKWebView，异步回调。

关于客户端回调JS方式毋庸置疑，各自选各自的就可以了。

通信的选择这块就确定了：

WKWebView：Messagehandler注入和evaluateJavaScript:completionHandler:回调。
UIWebView：JavaScriptCore框架注入和evaluatingJavaScript:回调。

那么接下来看一下对于业务过多导致冗余该怎么处理。

这一块前面的文章也有提到，可以看看《写一个易于维护使用方便性能可靠的Hybrid框架（二）—— 插件化》了解一下。插件化构建，让每一个业务功能都成为一个module，一个插件。插件是什么意思，就是独立！！与除了我们Web框架以外其他的类无任何耦合，它只是被框架管理着，静静的在那里工作，删除了项目依旧Build！！插件制作完毕拖到项目可以直接使用。这样就让业务模块完全分离，全部剥离框架，新的需求只需要建立新的模块即可，不需要动Web框架。

截图中的Fetch可以理解为JS的请求要客户端来做这种功能，Device可以理解为JS想要客户端的设备信息功能等等等...那么有新需求无限扩充这种模块就好了。清晰一目了然。细节请下载项目进行查看。关于插件注册看一下我前面的文章配置插件。经过这样的处理，是不是我们的代码就一目了然了，易维护，可拓展，重点是无耦合！！

到这里上面提到的问题就都得到解决了，基于前面的几篇文章Coding了一个Hybrid框架《WKJavaScriptBridge》，目前正在往项目中推广，大家觉得有帮助欢迎Star，有问题欢迎Issue。关于WKWebView的各种坑可以看一下WKWebView这篇文章。下面说一下WKJavaScriptBridge项目的主要构建思路。

三、框架构建

框架地址：https://github.com/GitWangKai/WKJavaScriptBridge

框架结构：

框架的主要特点：兼容了UIWebView&WKWebView，插件化了交互业务模块，当然还有一些其他特性参照《README.md》。

构建原则：解耦，业务分离，低代码浸入，高可拓展，高复用，易集成。

框架类图：

UIWebView和WKWebView兼容，由业务自定义即可，框架不关心传入的是那种类型，皆可处理。

项目构建主要基于上面提到的痛点问题进行了处理，目前为0.0.1版本，后续会继续扩充。具体实现参照源码，如果觉得有帮助，欢迎Star。

四、总结

文末做个总结，目前上面的方案只是为我们项目Hybrid打了个基石，后续还会有很多很多工作需要延伸。至少目前Hybrid在WebView处理这一块的组件已经出炉了。后续会基于此，扩充离线包、JS侧插件化处理、引入Flutter跨端技术、构建小程序框架。接下来我会构建第二个功能：离线包组件。

敬请期待。

如果由任何疑问或者建议欢迎issue，让它变得更好。