一步步构建 iOS 路由

接上一篇移动端路由层设计
为啥要说iOS路由呢?
路由层其实在逻辑上的设计都是一样的,关于对界面跳转的实现部分却与Android平台和iOS平台上的导航机制有着非常紧密的关系,Android操作系统有着天然的架构优势,Intent机制可以协助应用间的交互与通讯,是对调用组件和数据传递的描述,本身这种机制就解除了代码逻辑和界面之间的依赖关系,只有数据依赖。而iOS的界面导航和转场机制则大部分依赖UI组件各自的实现,所以如何解决这个问题,iOS端路由的实现则比较有代表性。
其实说白一点,路由层解决的核心问题就是原来界面或者组件之间相互调用都必须相互依赖,需要导入目标的头文件、需要清楚目标对象的逻辑,而现在全部都通过路由中转,只依赖路由,或者依靠一些消息传递机制连路由都不依赖。其次,路由的核心逻辑就是目标匹配,对于外部调用的情况来说,URL如何匹配Handler是最为重要的,匹配就必然用到正则表达式。了解这些关键点以后就有了设计的目的性,let‘s do it~

设计类图:

1124274-e05a8d382f2841e5

RouteClassMap.png

这里面有如下几个类:

  1. WLRRouteRequest,路由层的请求,无论是跨应用的外部调用还是内部调用,最后都形成一个路由请求,该请求包含了URL上的queryparameters和路径参数,还有内部调用时直接传入的原生参数,还有请求发起者对目标预留的回调block
  2. WLRRouteHandler,路由层的handler处理,handler接收一个WLRRouteRequest对象,来完成是否是界面跳转,还是组件加载,还是内部逻辑
  3. WLRRouter,路由核心对象,内部持有注册的Handler,比方说负责界面跳转的Handler,负责组件加载的Handler,负责API的Handler等等,路由的作用就是将外部调用传入的URL或者是内部调用传入的target,在内部匹配上对应的handler,然后调用生命周期方法,完成处理过程,当然,图中还有route的中间件,实际上是预留AOP的口子,方面后期扩展
  4. WLRRouteMatcher,用以处理外部调用的URL是否能与预设的正则表达式匹配,在WLRRouter中,每一次注册一个handler,都会用一个URL匹配的表达式生成一个WLRRouteMatcher
  5. WLRRegularExpression,继承NSRegularExpression,用以匹配URL,WLRRouteMatcher内部有一个WLRRegularExpression对象,WLRRouteMatcher接受一个URL,会使用WLRRegularExpression生成一个WLRMatchResult对象,来确定是否匹配成功,如果匹配成果则将URL上的路径参数给取出来
  6. WLRMatchResult,用以描述WLRRegularExpression的匹配结果,包含路径参数

工作流程:

  1. App启动实例化WLRRouter对象
  2. 实例化WLRRouteHandler对象
  3. WLRRouter对象挂载WLRRouteHandler实例与URL的表达式相对应,WLRRouter内部生成一个WLRRouteMatcher对象,与URL的表达式相对应
  4. 外部调用的URL和callback传入WLRRouter对象
  5. WLRRouter对象遍历内部持有的URL的匹配表达式,并找到每一个WLRRouteMatcher对象,将URL传入看是否能返回WLRRouteRequest对象
  6. 将WLRRouteRequest对象传入对应的WLRRouteHandler对象
  7. WLRRouteHandler对象根据WLRRouteRequest寻找到TargetViewController和SourceViewController,在生命周期函数里,完成参数传递与视图转场

WLRRouteRequest:

了解了以上,我们从WLRRouteRequest入手。
其实WLRRouteRequest跟NSURLRequest差不多,不过WLRRouteRequest继承NSObject,实现NSCopying协议,大概如下:

NSURLRequest其实应该是个值类型的对象,所以实现拷贝协议,该对象的实现部分没有什么可讲的,对照源代码查阅即可。

WLRRouteHandler

当WLRRouter对象完成了URL的匹配生成Request,并寻找到Handler的时候,首先会调用- (BOOL)shouldHandleWithRequest:(WLRRouteRequest *)request;,来确定handler是否愿意处理,如果愿意,则调用-(BOOL)transitionWithRequest:(WLRRouteRequest *)request error:(NSError *__autoreleasing *)error;,内部则通过便利方法获取targetViewController与SourceViewController,然后进行转场,核心方法的实现为:

这里根据SourceController的类型进行判断,其实request对象的信息足够可以判断目标视图应该如何打开,从本质上来讲,URL的匹配表达式是跟业务强关联的也是跟UI交互逻辑强关联的,transitionWithRequest方法实现里,你大可以继承一下,然后重写转场过程,甚至你可以在这自己设置iOS7自定义的转场,提供动画控制器和实现转场协议的对象,进而可以整体的控制Appp内部的实现。

WLRRegularExpression

该类继承NSRegularExpression

该对象主要的功能是将一个URL传入查看是否匹配,并且将表达式上声明的路径参数从URL上取下来。
比说,我们设置的URL匹配的表达式是: login/:phone([0-9]+),那AppScheme://user/login/138** 这样的URL应该是匹配,并且将138的手机号取出来,对应到phone上,这个过程必须用到正则表达式的分组提取子串的功能,:phone是约定好的提取子串的值对应的key的名字,其实这个url的正则表达式应该是: /login/([0-9]+)$,那么WLRRegularExpression对象需要知道需要提取所有子串的key还有将URL匹配的表达式转换为真正的正则表达式。

在Matcher对象匹配一个URL的时候

核心代码总共80多行,源码大家可以详阅

WLRRouteMatcher

属性有如下:

初始化方法:

匹配方法:

WLRRouter

在实现部分,有三个属性:

在Route挂在Handler和回调的block的时候:

接下来完善handle方法:

以上我们可以看到,Route将匹配的逻辑单独封装到WLRRouteMatcher对象中,将匹配后的结果生成WLRRouteRequest实例以携带足够完整的数据,同时将真正处理视图控制器的转场或者是组件的加载或者是未来可能拓展的handle业务封装到WLRRouteHandler实例中,匹配逻辑对应的处理逻辑干净分离,匹配逻辑可单独塑造业务匹配,处理逻辑可以通过继承扩展或者冲洗WLRRouteHandler的生命周期函数来更好的处理回调业务。如果WLRRouteHandler不能提供足够多的扩展性,则可以使用block回调最大限度的进行扩展。
以上,就是路由部分的整体实现。

转场的扩展

在WLRRouteHandler中,其实我们可以单独控制路由经过的页面跳转的转场。

这样的生命周期函数是不是很像UIViewControllerContextTransitioning转场上下文的协议的设定?- (nullable __kindof UIViewController *)viewControllerForKey:(UITransitionContextViewControllerKey)key;方法使上下文提供目标控制器和源控制器,其实在handler中你完全可以自定义一个子类,在transitionWithRequest方法里,设置遵守UIViewControllerTransitioningDelegate的代理,然后在此提供遵守 UIViewControllerAnimatedTransitioning的动画控制器,然后自定义转场上下文,实现自定义UI转场,而对应的匹配逻辑是与此无关的,我们就可以在路由曾控制全局的页面转场效果。对自定义转场不太熟悉的同学请移步我之前的文章:
ContainerViewController的ViewController 转场

路由的安全

有两个方面可以去做

  1. WLRRouteHandler实例中, -(BOOL)shouldHandleWithRequest:(WLRRouteRequest *)request中可以检测request中的参数,比方说效验source或者是效验业务参数完整等
  2. WLRRouter实例中handleURL方法,将在随后的WLRRoute的0.0.2版本中加入中间件的支持,就是在找到handler之前,将按照中间件注册的顺序回调中间件,而我们可以在中间件中实现风控业务、认证机制、加密验签等等

    路由的效率

    目前我们实现的路由是一个同步阻塞型的,在处理并发的时候可能会出现一些问题,或者是在注册比较多的route表达式以后,遍历和匹配的过程会损耗性能,比较好的实现方式是,将Route修改成异步非阻塞型的,但是API全部要换成异步API,起步我们先把同步型的搞定,随后慢慢提供异步版本的路由~

    路由的使用

    在大部分App实践MVVM架构或者更为复杂的VIPER架构的时候,除了迫切需要一个比较解耦的消息传递机制,如何更好的剥离目标实体的获取和配合UIKit这一层的转场逻辑是一项比较复杂的挑战,路由实际上是充当MVVM的ViewModel中比较解耦的目标获取逻辑和VIPER中Router层,P与V的调用全部靠Router转发。
    在实施以组件化为目的的工程化改造中,如何抽离单独业务为组件,比较好的管理业务与业务之间的依赖,就必须使用一个入侵比较小的Route,WLRRoute入侵的地方在于WLRRouteHandler的transitionWithRequest逻辑中,通过一个UIViewController的扩展,给 targetViewController.wlr_request = request;设置了WLRRouteRequest对象给目标业务,但虽然如此,你依旧可以重写WLRRouteHandler的transitionWithRequest方法,来构建你自己参数传递方式,这一点完全取决于你如何更好的使得业务无感知而使用路由。

最后附上代码地址:
喜欢的来个星吧…
https://github.com/Neojoke/WLRRoute

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部