您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
58同城iOS客户端Hybrid框架探索
 
来源:极客头条 发布于2017-7-26
   次浏览      
 

58同城iOS客户端的Hybrid框架在最初设计和演进的过程中,遇到了许多问题。为此,整个Hybrid框架产生了很大的变化。本文作者将遇到的典型问题进行了总结,并重点介绍58 iOS采用的解决方案,希望能给读者搭建自己的Hybrid框架提供一些参考。

引言

Hybrid App是指同时使用Native与Web的App。Native界面具有良好的用户体验,但是不易动态改变,且开发成本较高。对于变动较大的页面,使用Web来实现是一个比较好的选择,所以,目前很多主流App都采用Native与Web混合的方式搭建。58同城客户端上线不久即采用了Hybrid方式,至今已有六七年。而iOS客户端的Hybrid框架在最初设计和演进的过程中,随着时间推移和业务需求的不断增加,遇到了许多问题。为了解决它们,整个Hybrid框架产生了很大的变化。本文将遇到的典型问题进行了总结,并重点介绍58 iOS采用的解决方案,希望能给读者搭建自己的Hybrid框架一些参考。主要包括以下四个方面:

1. 通讯方式以及通讯框架

58 App最初采用的Web调用Native的通讯方式是AJAX请求,不仅存在内存泄露问题,且Native在回调给Web结果时无法确定回调给哪个Web View。另外,如何搭建一个简单、实用、扩展性好的Hybrid框架是一个重点内容。这些内容将在通讯部分详细介绍。

2. 缓存原理及缓存框架

提升Web页面响应速度的一个有效手段就是使用缓存。58 iOS客户端如何对Web资源进行缓存以及如何搭建Hybrid缓存框架将在缓存部分介绍。

3. 性能

iOS 8推出了WebKit框架,核心是WKWebView,其在性能上要远优于UIWebView,并且提供了一些新的功能,但遗憾的是WKWebView不支持自定义缓存。我们经过调研和测试发现了一些从UIWebView升级到WKWebView的可行解决方案,将在性能部分重点介绍。

4. 耦合

58 iOS客户端最初的Hybrid框架设计过于简单,导致Web载体页渐渐变得十分臃肿,继承关系十分复杂。耦合部分详细介绍了平稳解决载体页耦合问题的方案。

通讯

Hybrid框架首先要考虑的问题就是Web与Native之间的通讯。苹果在iOS 7系统推出了JavaScriptCore.framework框架,通过该框架可以方便地实现JavaScript与Native的通讯工作。但是在58 App最早引入Hybrid时,需要支持iOS 7以下的系统版本,所以58 App并没有使用JavaScriptCore.framework,而是采用了更原始的方式。

传统的通讯方式(如图1所示)中,Native调用JavaScript代码比较简单,直接使用UIWebView提供的接口stringByEvaluatingJavaScriptFromString:就可以实现。而JavaScript调用Native的功能需要通过拦截请求的方式来实现。即JavaScript发送一个特殊的URL请求,该请求并不是真正的网络访问请求,而是调用Native功能的请求,并传递相关的参数。Native端收到请求后进行判断,如果是功能调URL请求则调用Native的相应功能,而不进行网络访问。

 

图1 传统的通讯方式流程

按照上面的思路,在实现Hybrid通讯时,我们需要考虑以下几个问题:

通讯方式

前端能发起请求的方法有很多种,比如使用window.open()方法、AJAX请求、构造iframe等,甚至于使用img标签的src属性也可以发起请求。58 App最早是使用AJAX请求来发起Native调用的,这种方式在最初支撑了58 App中Hybrid很长一段时间,不过却存在两个很严重的缺陷:

一是内存问题:在iOS 8以前,iOS中内嵌Web页都是通过系统提供的UIWebView来实现的。而在UIWebView中,JavaScript在创建XMLHttpRequest对象发起AJAX请求后,会存在内存泄露问题。在实现的应用中,JavaScript与Native的交互操作是很频繁的,使用XMLHttpRequest会引起比较严重的内存问题。

二是拦截方法:UIWebView中的正常URL请求会触发其代理方法,我们可以在其代理方法中进行拦截。但是AJAX请求是一个异步的数据请求,并不会触发UIWebView的代理方法。我们需要自定义App中的NSURLCache或NSURLProcotol对象,在其中可以拦截到URL请求。但是这种方式有两个问题,一个是当收到功能调用请求时,不易确定是哪个Web View对象发起的调用,回调时也无法确定调用哪个Web View的回调方法。为了解决这个问题,58 App的Hybrid框架维护了一个Web View栈,记录所有视图层中的Web View,前端在发起Native调用时,附加一个Web View的唯一标识信息。在Native需要回调JavaScript方法时,通过Web View的唯一标识信息在Web View栈中找到对应的Web View。另一个是对App的框架结构有影响,Hybrid中的一个简单的调用需要放在App的全局对象进行拦截处理,破坏Hybrid框架的内聚性,违反面向对象设计原则。

iframe称作嵌入式框架,和框架网页类似,它可以把一个网页的框架和内容嵌入在现有的网页中。iframe是在现有的网页中增加一个可以单独载入网页的窗口,通过在HTML页面中创建大小为0的iframe,可以达到在用户完全无感知的情况下发起请求的目的。使用iframe发送请求的代码如下:

var iframe = document.createElement("iframe");
//设置iframe加载的页面链接
iframe.src = “ http://127.0.0.1/NativeFunction?parameters=values”;
//向DOM tree中添加iframe元素,以触发请求
document.body.AppendChild(iframe);
//请求触发后,移除iframe
iframe.parentNode.removeChild(iframe);
iframe = null;

iframe是加载一个新的页面,请求会走UIWebView的代理方法,不存在AJAX请求中无法确定Web View的问题。经过调研测试,多次创建和释放iframe不会存在内存泄露的问题。从这两个方面来说,使用iframe是远优于使用AJAX的,比较有名的PhoneGap和WebViewJavascriptBridge底层都是采用的iframe进行通讯的。

iframe是前端调用Native方法的一个非常优秀的方案,但它也存在一些细微的局限性。58 App前端为了提升代码的复用性和方便使用Native的功能,对iframe的通讯方式进行了统一封装,封装的具体实现是——在JavaScript代码中动态地向DOM tree上添加一个大小为0的iframe,在请求发起后立刻将其移除。这个操作的前提是DOM tree已经形成,也就是说在DOM Tree进行之前,这个方案是行不通的。浏览器解析HTML的详细过程为:

1.接受网络数据;

2.将二进制码变成字符;

3.将字符变为Unicode code points;

4.Tokenizer;

5.Tree Constructor;

6.DOM Ready;

7.Window Ready。

Dom Ready事件就是DOM Tree创建完成后触发的。在业务开发过程中,有少量比较特殊的需求,需要在DOM Ready事件之前发起Native功能的调用,而动态添加iframe的方法并不能满足这种需求。为此,我们对其他几种发起请求的方法进行了调查,包括前文提到的AJAX请求、为window.location.href赋值、使用img标签的src属性、调用window.open()方法(各个方式的表现结果如表1所示)。

表1 五种方法效果对比

结果显示,其他几种方式除window.open()与iframe表现基本相同外,都有比较致命的缺陷。AJAX有内存问题,并且无法使用Web View代理拦截请求,window.location.href在连续赋值时只有一次生效,img标签不需要添加到DOM Tree上也可发起请求,但是无法使用Web View代理拦截,并且相同的URL请求只发一次。

对于在DOM Ready之前需要发起Native调用的问题,最终采取的解决方案是尽量避免这种需求。无法避免的进行特殊处理,通过在HTML中添加静态的iframe来解决。

通讯协议

通讯协议是整个Hybrid通讯框架的灵魂,直接影响着Hybrid框架结构和整个Hybrid的扩展性。为了保证尽量高的扩展性,58 App中采用了字典的格式来传递参数。一个完整的Native功能调用的URL如下:

“Hybrid://iframe?parameter={“action”:”changetitle”,”title”:”标题”}

其中“Hybrid”是Native调用的标识,Native端在拦截到请求后判断请求URL的前缀是否为“Hybrid”,如果是则调起Native功能,同时阻止该请求继续进行。Native功能调用的相应参数在parameter后面的JSON数据里,其中“action”字段指明调用哪个Native功能,其余字段是调用该功能需要的参数。因为“action”字段名称的原因,后来把为Web提供的Native功能的处理逻辑称为action处理。

这样制定通讯协议有很强的可扩展性,Native端任意增加新的Hybrid接口,只要为action字段定一个新值,就可以实现,新接口需要的参数完全自定义。但是这种灵活的协议格式存在一个问题,就是开发者很难记住每种调用协议的参数字段,开发过程中需要查看文档来调用Native功能,需要更长的开发时间。为此58 App首先建立了健全的协议文档,将每种调用协议都一一列举,并给出调用示例,方便前端开发者查阅。另外,Native端开发了一套协议数据校验系统,该系统将每种调用协议的参数要求用XML文档表示出来,在收到Native调用协议数据时,动态地解析数据内部是否符合XML文档中的要求,如果不符合则禁止调用Native功能,并提示哪里不符合要求。

框架设计

依照上面的通讯协议,58 App中目前的Hybrid的框架设计如图2所示。其中:

图2 Hybrid框架设计

Native基础服务是Native端已有的一些通用的组件或接口,在Native端各处都在调用,比如埋点系统、统一跳转及全局alert提示框等。这些功能在某些Web页面也会需要使用到。

Native Hybrid框架是整个Hybrid的核心部分,其内部封装了除缓存以外的所有Hybrid相关的功能。Native Hybrid框架可大致分为Web载体、Hybrid处理引擎、Hybrid功能接口三部分。校验系统是前文提到的在开发过程中校验协议数据格式的模块,方便前端开发者在开发过程中快速定位问题。

Web载体包含Web载体页和Web View组件,所有的Hybrid页面使用统一的Web载体页。Web载体页提供了所有Web页面都可能会使用到的功能,而Web View组件为了实现Web View的一些定制需求,对系统的Web View进行了继承,并重写了某些父类方法。

Hybrid处理引擎负责处理Web页面发起事件,是Web View组件的代理对象,也是Web调用Native功能的通讯桥梁。前面提到的判断Web请求是页面载入请求还是Native功能调用请求的逻辑在Hybrid处理引擎中实现。在判定请求为Native功能调用请求后,Hybrid处理引擎根据请求参数中的“action”字段的值对该Native调用请求进行分发,找到对应的Hybrid功能组件,并将参数传递给该组件,由组件进行真正的处理。

Hybrid功能组件部分包含了所有开放给前端调用的功能。这些功能可以分成两类,一类是需要Native基础服务支撑的,另一类是Hybrid框架内部可以处理的。需要Native基础服务支撑的功能,如埋点、统一跳转、Native模块化组件(图片选择、登录等),本身在Native端已经有可用的成熟的组件。这些Hybrid功能组件所做的事是解析Web页传递过来的参数,将参数转换为Native组件可用的数据,并调用相应的Native基础服务,将基础服务返回的数据转换格式回调给Web。另一类Hybrid功能组件通常是比较简单的操作,比如改变Web载体页的标题和导航栏按钮、刷新或者返回等。这些组件通过代理的方式获取载体页和Web View对象,对其进行相应的操作。

再看Web端,前端对Hybrid通讯进行了一层封装,将发送Native调用请求的逻辑统一封装为一个方法,业务层需要调用Native功能时调用这个方法,传入action名称、参数,即可完成调用。当需要回调时,需要先定义一个回调方法,然后在参数中将方法名带上即可。

缓存

Web页面具有实时更新的特点,它为App提供了不依赖发版就能更新的能力。但是每次都请求完整的页面,增加了流量的消耗,并且界面展示依赖网络,需要更长的时间来加载,给用户比较差的体验。所以对一些常用的不需要每次都更新的内容进行缓存是很重要的。另外,Web页面需要用到的某些CSS和JavaScript资源是固定不变的,可以直接内置到App包中。所以,在Hybrid中,缓存是必不可少的功能。要实现Hybrid缓存,需要考虑三个方面的问题,即Hybrid缓存实现原理、缓存策略和Hybrid缓存框架设计。

缓存实现原理

NSURLCache是iOS系统提供的一个类,每个App都存在一个NSURLCache的单例对象,即使开发者没有添加任何有关NSURLCache的代码,系统也会为App创建一个默认的NSURLCache单例对象。几乎App中的所有网络请求都会调用这个单例对象的cachedResponseForRequest:方法。该方法是系统从缓存中获取数据的方法,如果缓存中有数据,通过这个方法将缓存数据返回给请求者即可,不必发送网络请求。通过使用NSURLCache的自定义子类替换默认的全局NSURLCache单例,并重写cachedResponseForRequest:方法,可以截获App内几乎所有的网络请求,并决定是否使用缓存数据。

当没有缓存可用时,我们在cachedResponseForRequest:方法中返回null。这时系统会发起网络请求,拿到请求数据后,系统会调用NSURLCache实例的storeCachedResponse:forRequest:方法,将请求信息和请求得到的数据传入这个方法。App通过重写这个方法就可以达到更新缓存的目的。

58 App目前就是通过替换全局的NSURLCache对象,来实现拦截App内的URL请求。在自定义NSURLCache对象的cachedResponse ForRequest:方法中判断请求的URL是否有对应的缓存,如果有缓存则返回缓存数据,没有则再正常走网络请求。请求完成后在store CachedResponse:forRequest:方法中将请求到的数据按需加入缓存中。

使用替换NSURLCache的方法时需要注意替换NSURLCache单例对象的时机,一定要在整个App发起任何网络请求之前替换。一旦App有了网络请求行为,NSURLCache单例对象就确定了,再去改变是无效的。

缓存策略

Web的大部分内容是多变的,开发者需要根据具体的业务需求制定缓存策略。好的缓存策略可以在很大程度上弥补Web页带来的加载慢和流量耗费大的问题。缓存策略的一般思路是:

1.内置通用的资源和关键页面;

2.按需缓存常用页面;

3.为缓存设置版本号,根据版本号进行使用和升级。

58 App中对一些通用资源和十分重要的Web页面进行了内置,防止App在首次启动时由于网络原因导致某些重要页面无法展示。在缓存使用和升级的策略上,58 App除了设置版本号以外,还针对那些已过期但还可用的缓存数据设置了缓存过期阈值。58 App的详细缓存策略如下:

1.将通用Hybrid资源(CSS、JS文件等)和关键页面(比如业务线大类页)附带版本号内置到App的特定Bundle中;

2.在NSURLCache单例中拦截到请求后,判断该请求是否带有缓存版本号信息,如果没有,说明该页面不使用缓存,走正常网络请求;

3.从缓存库中查找缓存数据,如果有则取出,否则到内置资源中取。如果两者都没有数据,走正常网络请求。并在请求完成后,将结果保存到缓存库中;

4.拿到缓存或内置数据后,将请求中带的版本号v1与取到数据的版本号v2进行对比。如果v1≤v2,返回取到的数据,不再请求网络;如果v1>v2且v1 – v2小于缓存过期阈值,则先返回缓存数据以供使用,然后后台请求新的数据并存入缓存;如果v1>v2且v1 – v2大于缓存过期阈值,走正常网络请求,并在请求完成后,将结果保存到缓存库中。

缓存框架设计

58 App中Hybrid的缓存框架设计如图3所示,其中:

图3 Hybrid缓存框架设计

1. Hybrid内置资源管理

Hybrid内置资源管理模块是单独为Hybrid的内置资源而创建的。Hybrid内置资源单独存放在一个Bundle下,这些内置资源主要包括HTML文件、JavaScript文件、CSS文件和图片。Hybrid内置资源管理模块负责解读这个Bundle,并向上提供读取内置资源的接口,该接口以资源的URL和版本号为参数,按照固定的规则进行转换,查找可用的内置资源。

内置资源中除了这些Web资源外,还单独内置了一份文件,用于保存URL到内置资源文件名和内置资源版本号的映射表。管理模块在收到内置资源请求后,先用URL到这个映射表中查找内置资源版本号,比对版本号,然后再通过映射表中查到的文件名读取相应的内置资源并返回。

2. App缓存库

58 App内有一个独立的缓存库组件,App中需要用到的缓存性质的数据都存放在这个库中,便于缓存的统一管理。缓存库内的缓存数据也有版本号的概念,完全可以满足Hybrid缓存的需求,且使用十分方便。Hybrid的缓存数据都使用App的缓存库来保存。

3. Hybrid缓存管理器

Hybrid缓存管理器是Hybrid缓存相关功能的总入口,负责提供Hybrid缓存数据和升级缓存数据,所有的Hybrid缓存相关的策略都封装在这个模块中。全局的NSURLCache实例在收到Hybrid请求时会调起Hybrid缓存管理器,索取缓存数据。Hybrid缓存管理器先到App的缓存库中查找可用的缓存,如果没有再到内置资源管理模块查找,如果可以查到数据,则返回查到的数据,如果查不到,则返回空。在NSURLCache的storeCachedResponse:forRequest:方法中,会调用Hybrid缓存管理器的缓存升级接口,将请求到的数据传入该接口。新请求到的数据会带有最新的版本号信息。缓存升级接口将新的数据和版本号信息一同存入缓存库中,以便下次使用。

性能

前面分享了58 App中Hybrid的通讯框架和缓存框架,接下来介绍一下遇到的性能方面的问题及解决方案。

AJAX通讯方式的内存泄露问题

前面介绍过在UIWebView中使用AJAX的方式进行Native功能调用,会产生内存泄露问题,《UIWebView Secrets - Part1 - Memory Leaks on Xmlhttprequest》(参考资料1)中给出了一个解决方案,是在UIWebView的代理方法WebViewDidFinishLoad:中添加如下代码:

[[NSUserDefaults standardUserDefaults] setInteger:0 forKey:@"WebKitCacheModelPreferenceKey"];

测试结果显示,这种方法并没有使用iframe的效果好。加上拦截方式的局限性,58 App最终选择的解决方案是使用iframe代替AJAX。

UIWebView内存问题

使用过UIWebView的开发者应该都知道,UIWebView有比较严重的内存问题。苹果在iOS8推出了WebKit框架,其核心是WKWebView,志在取代UIWebView。WKWebView不仅解决了UIWebView的内存问题,且具有更高的稳定性和响应速度,还支持一些新的功能。使用WKWebView代替UIWebView对提升整个Hybrid框架的性能会有很重大的意义。

但是,WKWebView一直存在一个问题,就是WKWebView发出的请求并不走NSURLCache的方法。这就导致我们自定义的缓存系统会整个失效,也无法再用内置资源。经过一段时间的摸索和调研,终于找到了可以实现自定义缓存的方法。主要思想是WKWebView发起的请求可以通过NSURLProtocol来拦截——将自定义的NSURLProtocol子类注册到NSURLProtocol的方式,可以像之前用NSURLCache一样使用缓存或内置数据代替请求结果返回。注册自定义NSURLProtocol的关键代码如下:

[NSURLProtocol registerClass:WBCustomProtocol.class];
Class cls = NSClassFromString(@"WKBrowsing

ContextController");
SEL sel = NSSelectorFromString(@"registerSchemeFo

rCustomProtocol:");
if ([(id)cls respondsToSelector:sel]) {
[(id)cls performSelector:sel withObject:@"http"];

代码中从第二行开始,是为了让WKWebView发起的请求可以被自定义的NSURLProtocol对象拦截而添加的。添加了上面的代码后,就可以在自定义的NSURLProtocol子类的方法中截获到WKWebView的请求和数据下载完成的事件。

以上方案解决了WKWebView无法使用自定义缓存的问题,但是这种方案还存在一些问题,且使用了苹果系统的私有API,不符合官方规定,在App中直接使用有被拒的风险。另外WKWebView还有一些其他问题(详情可参见参考资源6)。

目前,58 App正在准备接入WKWebView,但是没有决定使用这种方案来解决自定义缓存问题。我们正在逐步减少对自定义缓存的依赖程度,在前面几个版本迭代中,已经逐步去除了内置的HTML页面。

页面加载完成事件优化

正常的Web页面加载是比较耗时的,尤其是在网络环境较差的情况下。而Web的页面文件与样式表、JavaScript文件以及图片是分别加载的,很有可能界面元素已经渲染完成,但样式表或JavaScript文件还没有加载完,这时会出现布局混乱和事件不响应的情况,影响用户体验。为了不让用户看到这种情况,一般Native会在加载Web资源的过程中隐藏掉Web View,或用Loading视图遮挡住Web View。等到Web资源加载完成再将Web View展示给用户。系统通过UIWebViewDelegate的WebViewDidFinishLoad:方法告知Native资源加载完成的事件。这个方法在页面用到的所有资源文件全部加载完成后触发。

在实用中发现,一般情况下样式表资源和JavaScript资源的加载速度很快,比较耗时的是图片资源(事实是Native界面也存在图片加载比较慢的情况,一般Native会采用异步加载图片的策略,即先将界面展示给用户,后台下载图片,下载完成后再刷新图片控件)。实际上当HTML、样式表和JavaScript文件加载完成后,整个界面就完全可以展示给用户并允许用户交互了。图片资源加载完成与否并不影响交互。

且这样的逻辑也与Native异步加载图片的体验一致。在WebViewDidFinishLoad:方法中才展示界面的策略会延长加载时间,尤其在图片很大或网络环境较差的情况下,用户可能需要多等待几倍的时间。

基于以上的考虑,58 App的Hybrid框架专门为Web提供了一功能接口,允许Web提前通知Native展示界面。该功能实现起来很简单,只需单独定义一个Hybrid通讯协议,并在Native端相应的处理逻辑即可。前端在开发一些图片资源比较多的页面时,提前调用该接口,可以在很大程度上提升用户体验。

耦合

58 App最初引入Hybrid的时候,业务要简单许多,Native没有现在这么多功能可供Web调用,所以最开始设计的Hybrid通讯框架也比较简单。由于使用AJAX的方式进行通讯,通讯请求的拦截也要在NSURLCache中。当时也没有公用的缓存库组件,Hybrid的缓存功能与内置资源一起写在单独的模块中(最初的Hybrid框架如图4所示)。

图4 旧版Hybrid框架设计图

这个框架在58 App中存在了很长一段时间,运行比较稳定。但是随着业务的不断增加,这个框架暴露出了一些比较严重的问题。

自定义的NSURLCache类中耦合了Hybrid的业务逻辑

由于AJAX方式的通讯请求要在NSURLCache中进行拦截,NSURLCache在收到请求后,不得不先判断是否是Hybrid通讯请求——如果是,则需要将请求转发给Hybrid通讯框架处理。另外,为了解决Native回调Web时无法确定Web View的问题,需要维护一个Web View的Web View栈,App内所有的Web View对象都需要存入到这个栈中。这个栈需要全局存放,但是Web载体页和Hybrid事件分发器都是局部对象,无法保存这个栈。考虑到NSURLCache对象与Hybrid有关联且是单例,最终将这个栈保存在了NSURLCache的属性中,更加重了NSURLCache与Hybrid的耦合。

NSURLCache耦合Hybrid业务逻辑的问题随着iframe的引入迎刃而解,通讯请求的拦截直接转移到了Hybrid事件分发器中。

NSURLCache的职责重新恢复单一,只负责缓存相关的内容。使用iframe的通讯方式,Web在调用Native功能的请求是在UIWebView的代理方法中截获,系统会将相应的Web view通过参数传递过来,不再有无法确定Web view的问题,之前的Web view栈也没有必要再维护了。iframe的引入使得Hybrid的通讯框架和缓存框架完全分离开来,互不干涉。

Web载体页臃肿

最初的Hybrid框架中,action处理的具体实现写在了Web载体页中,这导致Web载体页随着业务的增加变得十分臃肿,内部包含大量的action处理代码。另外,由于一些为Web提供的功能是针对某些特定业务场景的,写在公用载体页中并不合适,所以开始了使用继承的方式派生出各种各样的Web载体页,最终导致App内的View Controller的继承关系十分混乱,继承层次最多时高达九层。

Web载体页耦合action处理的问题是业务逐步累积的结果,当决定要重构的时候,这里的逻辑已经变得十分庞杂。强行将这两部分剥离困难很大,一方面代码太多,工作量大,另一方面逻辑过于复杂,稍有不慎就会引起Bug。解决Web载体页的问题采取的方案分成两部分。

搭建新Hybrid框架,逐步淘汰老的框架。

为了解决Web载体页臃肿的问题,更为了提供对iOS 8 WebKit框架的支持,提升Hybrid性能,58 iOS客户端重新搭建了一套新的Hybrid框架。新Hybrid框架严格按照图2所示的结构进行实现。新增的业务使用新的Hybrid框架,并逐步将老的业务切换到新的框架上来。

在图2的框架中,为了在增加新的Hybrid功能组件时整体框架满足开闭原则,需要解除Hybrid处理引擎对Hybrid功能组件的依赖。这里采用的设计是,处理引擎不主动添加组件,而是提供全局的注册接口,内部保存一份共享的注册表。各个功能组件在load方法中主动向处理引擎中注册action名称、功能组件的类名及方法。处理引擎在运行时动态地查阅注册表,找到action对应的类名和方法,生成功能组件的实例,并调用相应的处理方法。

按照上面的设计,一个Web界面的完整运行流程为:

1.程序开始运行,生成全局的Hybrid共享注册表(action名称到类名及方法名的映射),各个Hybrid功能组件向注册表中注册action名称;

2.需要使用Web页,应用程序生成Web载体页;

3.Web载体页生成Web View实例和Hybrid处理引擎实例,并强持有这两个实例,将处理引擎实例设为Web view实例的代理对象,将自身设为处理引擎的代理对象;

4.Web页发起Native调用请求;

5.处理引擎实例截获Native调用请求,并在共享注册表中查到可以处理本次请求的类名和方法名;

6.处理引擎生成查找到的Hybrid功能组件类的实例,强持有之,并将自身的代理对象设为功能组件的代理对象,调用该实例的处理方法;

7.Hybrid功能组件解析全部的调用参数,处理请求,并通过代理对象将处理结果回调给Web页。

8.Web页生命周期完成,释放Web View实例、Hybrid处理引擎实例、Hybrid引擎实例释放所有的Hybrid功能组件实例。

通过使用组件主动注册和运行时动态查找的方式,固化了新增组件的流程,保证已有代码的完备性,使Hybrid框架在增加新的功能上严格遵守开闭原则。

关于注册表,目前是采用全局共享的方式保存。在最初设计时,还有另一种动态组合注册的方案。该方案不使用共享的注册表,而是每一个Hybrid处理引擎保存一份独立的注册表,在Web载体页生成Hybrid处理引擎的时候,根据业务场景选择部分Hybrid功能组件注册到处理引擎中。这种动态组合的方案对功能组件的组合进行了细化,每个Web载体页对象根据各自的业务场景按需注册组件。动态组合注册的方案考虑的主要问题是:在Hybrid框架中,有许多专用Hybrid功能组件,大部分Web页并不需要使用这些组件,另外58 App被拆分为主App和多个业务线共同维护和开发,有一些Hybrid功能组件是业务线独有的,其他业务线并不需要使用。动态组合注册的方案可以达到隔离业务线的目的,同时不使用全局注册表,在不使用Web页时不占用内存资源,也减小了单张注册表的大小。

现在的Hybrid框架采用全局注册方案,而没有采用动态组合注册的方案,原因是动态组合注册方案需要在生成Web载体页时区分业务场景,Web页的使用方必须提供需要注册的组件信息,而这是比较困难的,也加大了调用方调用Web页的复杂程度。另外,大部分组件是否会被使用都是处于模糊状态,并不能保证使用或者不使用,这种模糊性越大,使用动态组合注册方案的意义也就越小。

最终58 App采用了全局注册的方案,虽然注册表体积较大,但是由于使用散列算法,并不会增加查找的复杂度而影响性能,同时避免了调用方需要区分业务场景的不便,简化了后续的开发成本。

改造原Hybrid框架,防止Web载体页进一步扩大

为了保证业务逻辑的稳定,不能直接淘汰老的Hybrid框架,老业务中会有一部分新的需求需要在老的框架上继续扩展。为了防止老的Web载体页因为这些新需求进一步扩大,决定将原Hybrid通讯框架改装为双向支持的结构。在保持原Web功能接口处理逻辑不变的情况下,支持以组件的方式新增Web功能接口。具体的实现是在Hybrid事件分发器中也添加了与新Hybrid框架的处理引擎相似的逻辑,增加了全局共享注册表,支持组件向其中注册。在分发处理中添加了查找和调用注册组件的逻辑。改造后的Hybrid事件分发器在收到action请求后,先按老的逻辑进行分发,如果分发成功则调用载体页的处理逻辑,如果分发失败,则查找共享注册表,找到可以处理该action的组件进行实例化,并调用相应的处理逻辑。

虽然Web载体页由于继承的关系变得很分散,但是事件分发器一直只有一份,逻辑比较集中。进了这样的改造后,有效扼制了Web载体的进一步扩大,也不再需要使用继承来复用action处理逻辑了。

总结

本文重点介绍了58 App中Hybrid框架在设计和发展过程中遇到的问题及采用的解决方案。目前的Hybrid框架是一个比较简单实用的框架,前端没有对Native提供的功能进行一一封装,这样可以在扩展新action协议时尽量少地改动代码。且封装层次少,执行效率比较高。目前的Hybrid框架依然很友好地支撑着58业务的发展,所以暂时还没引入JavaScriptCore.framework。在未来的发展中,会逐步引入新技术,搭建更好的Hybrid。

   
次浏览       
相关文章

手机软件测试用例设计实践
手机客户端UI测试分析
iPhone消息推送机制实现与探讨
Android手机开发(一)
相关文档

Android_UI官方设计教程
手机开发平台介绍
android拍照及上传功能
Android讲义智能手机开发
相关课程

Android高级移动应用程序
Android系统开发
Android应用开发
手机软件测试