《写一个易于维护使用方便性能可靠的Hybrid框架（一）—— 思路构建》

《写一个易于维护使用方便性能可靠的Hybrid框架（二）—— 插件化》

《写一个易于维护使用方便性能可靠的Hybrid框架（三）—— 配置插件》

《写一个易于维护使用方便性能可靠的Hybrid框架（四）—— 框架构建》

前言

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

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

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

目录

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

1、现状分析

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

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

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

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

相信如今不少App在这一块还停留在上面的例子中，那么怎么解决这些问题？首先咱们应该要有个好的通讯方案，一个前卫的，先进的通讯方案能够比做框架的心脏。安全

下面咱们继续分析一下如今有什么通讯方案更适合咱们。weex

2、治理方案

治理方案这一块能够看下个人另外一篇文章《写一个易于维护使用方便性能可靠的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:@"SHRMWKJSBridge"];
复制代码

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

复制代码

JS侧的调用也会很是简单，经过客户端注入的SHRMWKJSBridge就能够构建通讯了：

window.webkit.messageHandlers.SHRMWKJSBridge.postMessage()
复制代码

上面的代码就是Messagehandler方式的通讯过程了，很简单，从代码中能够很清楚的看到什么是亲儿子的通讯，再对比下曲线救国式的通讯，对比就灰常明显了。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框架。

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

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

3、框架构建

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

框架结构：

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

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

框架类图：

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

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

4、总结

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

敬请期待。

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