阅读 1349

写一个易于维护使用方便性能可靠的Hybrid框架(四)—— 框架构建

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

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

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

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

前言

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

那么今天要说的就是如何构建一个WebView的Hybrid框架,并让它独立于项目中,像AFNSD一样存在于你的项目中,也并不会关联你的业务,像支付宝的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:@"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项目的主要构建思路。

三、框架构建

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

框架结构:

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

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

框架类图:

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

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

四、总结

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

敬请期待。

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

关注下面的标签,发现更多相似文章
评论