Hybrid治理(UIWebView&WKWebView)

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

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

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

目录

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

一、现状分析

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

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

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

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

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

二、治理方案

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

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

JS调用客户端：

• 1.假跳转拦截：也就是上面提到的，这应该是第一个被pass掉的方案，因为它不安全！就目前主流的开源来看，不论是大名鼎鼎的 Cordova 还是 WebViewJavaScriptBridge 都对它做了大量的操作，大量的操作...
• 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:@"SHRMWKJSBridge"];
复制代码

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

复制代码

以上代码摘自 SHRMJavaScriptBridge 。Messagehandler的具体使用不在本篇范围，具体使用可以参照SHRMJavaScriptBridge框架。

从代码中可以很清楚的看到亲儿子的通信， SHRMWKJSBridge 就是WKWebView注入的JS函数。实际上客户端就做了这么点工作就可以了， message.body 可以是任意id类型对象，取决于JS端给客户端传递的是什么类型，demo中传递的是 NSArray 类型。

• UIWebView首选JavaScriptCore框架：

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

客户端主动调用JS：

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

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

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

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

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

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

截图来源于 SHRMJavaScriptBridge 项目。

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

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

三、框架构建

框架地址： github.com/GitWangKai/…

框架结构：

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

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

框架类图：

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

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

四、总结

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

敬请期待。

最后再次奉上 Demo 地址，如果对你有帮助，star鼓励下谢谢。如果由任何疑问或者建议欢迎issue，让它变得更好。