34b4b2d75215d50ca4b621f9147001e8
iOS VIPER 架构实践(三):面向接口的路由设计

路由是实现模块间解耦的一个有效工具。如果要进行组件化开发,路由是必不可少的一部分。目前iOS上绝大部分的路由工具都是基于URL匹配的,优缺点都很明显。这篇文章里将会给出一个更加原生和安全的设计,这个设计的特点是:

  • 路由时用protocol寻找模块
  • 可以对模块进行固定的依赖注入和运行时依赖注入
  • 支持不同模块间进行接口适配和转发,因此无需和某个固定的protocol关联
  • 充分解耦的同时,增加类型安全
  • 支持移除已执行的路由
  • 封装UIKit界面跳转方法,可以一键跳转和移除
  • 支持storyboard,支持其他任意模块
  • 可以检测界面跳转时的大部分错误

如果你想要一个能够充分解耦、类型安全、有依赖注入功能的路由器,那这个就是目前所能找到的最佳方案。

这个路由工具是为了实践VIPER模式而设计的,目的是为VIPER提供依赖注入功能,不过它也可以用于MVC、MVP、MVVM,没有任何限制。

工具和Demo地址:ZIKRouter

目录

  • Router的作用
    • 路由缺失时的情况
    • 寻找模块
    • 声明依赖和接口
    • Builder和依赖注入
  • 现有的Router
    • URL Router
      • 优点
        • 极高的动态性
        • 统一多端路由规则
        • 适配URL scheme
      • 缺点
        • 不适合通用模块
        • 安全性差
        • 维护困难
    • Protocol Router
      • 优点
        • 安全性好,维护简单
        • 适用于所有模块
        • 优雅地声明依赖
      • 缺点
        • 动态性有限
        • 需要额外适配URL Scheme
      • Protocol是否会导致耦合?
        • 业务设计的互相关联
        • Required InterfaceProvided Interface
    • Target-Action
      • 优点
      • 缺点
    • UIStoryboardSegue
    • 总结
  • ZIKRouter的特性
    • 离散式管理
    • 自由定义路由参数
    • 移除已执行的路由
    • 通过protocol获取对应模块
      • Protocol作为匹配标识
      • 多对一匹配
    • 依赖注入和依赖声明
      • 固定依赖和运行时依赖
      • 直接在头文件中声明
    • 使用泛型指明特定router
    • 类型安全
      • 传入正确的protocol
      • 泛型的协变和逆变
    • 用Adapter兼容接口
      • Provided模块添加Required Interface
      • 用中介者转发接口
    • 封装UIKit跳转和移除方法
      • 封装iOS的路由方法
      • 识别adaptative类型的路由
      • 支持自定义路由
      • 关于extension里的跳转方法
    • 支持storyboard
    • AOP
    • 路由错误检查
    • 支持任意模块
    • 性能
  • 项目地址和Demo

Router的作用

首先,我们需要梳理清楚,为什么我们需要Router,Router能带来什么好处,解决什么问题?我们需要一个什么样的Router?

路由缺失时的情况

没有路由时,界面跳转的代码就很容易产生模块间耦合。

iOS中执行界面跳转时,用的是UIViewController上提供的跳转方法:

  • [sourceViewController.navigationController pushViewController:destinationViewController animated:YES];
  • [sourceViewController presentViewController:destinationViewController animated:YES completion:nil];

如果是直接导入destinationViewController的头文件进行引用,就会导致和destinationViewController模块产生耦合。类似的,一个模块引用另一个模块时也会产生这样的耦合。因此我们需要一个方式来获取destinationViewController,但又不能对其产生直接引用。

这时候就需要路由提供的"寻找模块"的功能。以某种动态的方式获取目的模块。

那么路由是怎么解决模块耦合的呢?在上一篇VIPER讲解里,路由有这几个主要职责:

  • 寻找指定模块,执行具体的路由操作
  • 声明模块的依赖
  • 声明模块的对外接口
  • 对模块内各部分进行依赖注入

通过这几个功能,就能实现模块间的完全解耦。

寻找模块

路由最重要的功能就是给出一种寻找某个指定模块的方案。这个方案是松耦合的,获取到的模块在另一端可以随时被另一个相同功能的模块替换,从而实现两个模块之间的解耦。

寻找模块的实现方式其实只有有限的几种:

  • 用一个字符串identifier来标识某个对应的界面(URL Router、UIStoryboardSegue)
  • 利用Objective-C的runtime特性,直接调用目的模块的方法(CTMediator)
  • 用一个protocol来和某个界面进行匹配(蘑菇街的第二种路由和阿里的BeeHive),这样就可以更安全的对目的模块进行传参

这几种方案的优劣将在之后逐一细说。

声明依赖和接口

一个模块A有时候需要使用其他模块的功能,例如最通用的log功能,不同的app有不同的log模块,如果模块A对通用性要求很高,log方法就不能在模块A里写死,而是应该通过外部调用。这时这个模块A就依赖于一个log模块了。App在使用模块A的时候,需要知道它的依赖,从而在使用模块A之前,对其注入依赖。

当通过cocoapods这样的包管理工具来配置不同模块间的依赖时,一般模块之间是强耦合的,模块是一一对应的,当需要替换一个模块时会很麻烦,容易牵一发而动全身。如果是一个单一功能模块,的确需要依赖其他特定的各种库时,那这样做没有问题。但是如果是一个业务模块中引用了另一个业务模块,就应该尽量避免互相耦合。因为不同的业务模块一般是由不同的人负责,应该避免出现一个业务模块的简单修改(例如调整了方法或者属性的名字)导致引用了它的业务模块也必须修改的情况。

这时候,业务模块就需要在代码里声明自己需要依赖的模块,让app在使用时提供这些模块,从而充分解耦。

示例代码:

  • @protocol ZIKLoginServiceInput <NSObject>
  • - (void)loginWithAccount:(NSString *)account
  • password:(NSString *)password
  • success:(void(^_Nullable)(void))successHandler
  • error:(void(^_Nullable)(void))errorHandler;
  • @end
  • @interface ZIKNoteListViewController ()
  • //笔记界面需要登录后才能查看,因此在头文件中声明,让外部在使用的时候设置此属性
  • @property (nonatomic, strong) id<ZIKLoginServiceInput> loginService;
  • @end

这个声明依赖的工作其实是模块的Builder的职责。一个界面模块大部分情况下都不止有一个UIViewController,也有其他一些Manager或者Service,而这些角色都是有各自的依赖的,都统一由模块的Builder声明,再在Builder内部设置依赖。不过在上一篇文章的VIPER讲解里,我们把Builder的职责也放到了Router里,让每个模块单独提供一个自己的Router。因此在这里,Router是一个离散的设计,而不是一个单例Router掌管所有的路由。这样的好处就是每个模块可以充分定制和控制自己的路由过程。

可以声明依赖,也就可以同时声明模块的对外接口。这两者很相似,所以不再重复说明。

Builder和依赖注入

执行路由的同时用Builder进行模块构建,构建的时候就对模块内各个角色进行依赖注入。当你调用某个模块的时候,需要的不是某个简单的具体类,而是一个构建完毕的模块中的某个具体类。在使用这个模块前,模块需要做一些初始化的操作,比如VIPER里设置各个角色之间的依赖关系,就是一个初始化操作。因此使用路由去获取某个模块中的类,必定需要通过模块的Builder进行。很多路由工具都缺失了这部分功能。

你可以把依赖注入简单地看成对目的模块传参。在进行界面跳转和使用某个模块时,经常需要设置目的模块的一些参数,例如设置delegate回调。这时候就必须调用一些目的模块的方法,或者传递一些对象。由于每个模块需要的参数都不一样,目前大部分Router都是使用字典包裹参数进行传递。但其实还有更好、更安全的方案,下面将会进行详解。

你也可以把Router、Builder和Dependency Injector分开,不过如果Router是一个离散型的设计,那么都交给各自的Router去做也很合理,同时能够减少代码量,也能够提供细粒度的AOP。

现有的Router

梳理完了路由的职责,现在来比较一下现有的各种Router方案。关于各个方案的具体实现细节我就不再展开看,可以参考这篇详解的文章:iOS 组件化 —— 路由设计思路分析

URL Router

目前绝大多数的Router都是用一串URL来表示需要打开的某个界面,代码上看来大概是这样:

  • //注册某个URL,和路由处理进行匹配保存
  • [URLRouter registerURL:@"settings" handler:^(NSDictionary *userInfo) {
  • UIViewController *sourceViewController = userInfo[@"sourceViewController"];
  • //获取其他参数
  • id param = userInfo[@"param"];
  • //获取需要的界面
  • UIViewController *settingViewController = [[SettingViewController alloc] init];
  • [sourceViewController.navigationController pushViewController: settingViewController animated:YES];
  • }];
  • //调用路由
  • [URLRouter openURL:@"myapp://noteList/settings?debug=true" userInfo:params completion:^(NSDictionary *info) {
  • }];

传递一串URL就能打开noteList界面的settings界面,用字典包裹需要传递的参数,有时候还会把UIKit的push、present等方法进行简单封装,提供给调用者。

这种方式的优点和缺点都很突出。

优点

极高的动态性

这是动态性最高的方案,甚至可以在运行时随时修改路由规则,指向不同的界面。也可以很轻松地支持多级页面的跳转。

如果你的app是电商类app,需要经常做活动,app内的跳转规则经常变动,那么就很适合使用URL的方案。

统一多端路由规则

URL的方案是最容易跨平台实现的,iOS、Andorid、web、PC都按照URL来进行路由时,也就可以统一管理多端的路由规则,降低多端各自维护和修改的成本,让不懂技术的运营人员也可以简单快速地修改路由。

和上一条一样,这也是一个和业务强相关的优点。如果你有统一多端的业务需求,使用URL也很合适。

适配URL scheme

iOS中的URL scheme可以跨进程通信,从app外打开app内的某个指定页面。当app内的页面都能使用URL打开时,也就直接兼容了URL scheme,无需再做额外的工作。

缺点

不适合通用模块

URL Router的设计只适合UI模块,不适合其他功能性模块的组件。功能性模块的调用并不需要如此强的动态特性,除非是有模块热更新的需求,否则一个模块的调用在一个版本里应该总是稳定不变的,即便要进行模块间解耦,也不应该用这种方式。

安全性差

字符串匹配的方式无法进行编译时检查,当页面配置出错时,只能在运行时才能发现。如果某个开发人员不小心在字符串里加了一个空格,编译时也无法发现。你可以用宏定义来减少这种出错的几率。

维护困难

没有高效地声明接口的方式,只能从文档里查找,编写时必须仔细对照字符串及其参数类型。

传参通过字典来进行,参数类型无法保证,而且也无法准确地知道所调用的接口需要哪些参数。当目的模块进行了接口升级,修改了参数类型和数量,那所有用到的地方都要一一修改,并且没有编译器的帮助,你无法知道是否遗漏了某些地方。这将会给维护和重构带来极大的成本。

针对这个问题,蘑菇街的选择是用另一个Router,用protocol来获取目的模块,再进行调用,增加安全性。

Protocol Router

这个方案也很容易理解。把之前的字符串匹配改成了protocol匹配,就能获取到一个实现了某个protocol的对象。

开源方案里只看到了BeeHive实现了这样的方式:

  • id<ZIKLoginServiceInput> loginService = [[BeeHive shareInstance] createService:@protocol(ZIKLoginServiceInput)];

优点

安全性好,维护简单

再对这个对象调用protocol中的方法,就十分安全了。在重构和修改时,有了编译器的类型检查,效率更高。

适用于所有模块

Protocol更加符合OC和Swift原生的设计思想,任何模块都可以使用,而不局限于UI模块。

优雅地声明依赖

模块A需要用到登录模块,但是它要怎么才能声明这种依赖关系呢?如果使用Protocol Router,那就只需要在头文件里定义一个属性:

  • @property (nonatomic, string) id<ZIKLoginServiceInput> *loginService;

如果这个依赖是必需依赖,而不是一个可选依赖,那就添加到初始化参数里:

  • @interface ModuleA ()
  • - (instancetype)initWithLoginService:(id<ZIKLoginServiceInput>)loginService;
  • @end

问题是,如果这样的依赖很多,那么初始化方法就会变得很长。因此更好的做法是由Builder进行固定的依赖注入,再提供给外部。目前BeeHive并没有提供依赖注入的功能。

缺点

动态性有限

你可以维护一份protocol和模块的对照表,使用动态的protocol来尝试动态地更改路由规则,也可以在Protocol Router之上封装一层URL Router专门用于动态性的需求。

需要额外适配URL Scheme

使用了Protocol Router就需要再额外处理URL Scheme了。不过这样也是正常的,解析URL Scheme本来就应该放到另一个单独的模块里。

Protocol是否会导致耦合?

很多谈到这种方案的文章都会指出,和URL Router相比,Protocol Router会导致调用者引用目的模块的protocol,因此会产生"耦合"。我认为这是对"解耦"的错误理解。

要想避免耦合,首先要弄清楚,我们需要什么程度的解耦。我的定义是:模块A调用了模块B,模块B的接口或者实现在做出简单的修改时,或者模块B被替换为相同功能的模块C时,模块A不需要进行任何修改。这时候就可以认为模块A和模块B是解耦的。

业务设计的互相关联

有些时候,表达出两个模块之间的关联是有意义的。

当一个界面A需要展示一个登录界面时,它可能需要向登录界面传递一个"提示语"参数,用于在登录界面显示一串提示。这时候,界面A在调用登录界面时,是要求登录界面能够显示这个自定义提示语的,在业务设计中就存在两个模块间的强关联性。这时候,URL Router和Protocol Router没有任何区别,包括下面将要提到的Target-Action路由方式,都存在耦合,但是Protocol Router通过简单地改善,是可以把这部分耦合去除的。

URL Router:

  • [URLRouter openURL:@"login" userInfo:@{@"message":@"请登录查看笔记详情"}];

Protocol Router:

  • @protocol LoginViewInput <NSObject>
  • @property (nonatomic, copy) NSString *message;
  • @end
  • //获取登录界面进行设置
  • UIViewController<LoginViewInput> *loginViewController = [ProtocolRouter destinationForProtocol:@protocol(LoginViewInput)];
  • loginViewController.message = @"请登录查看笔记详情";

由于字典传参的原因,URL Router只不过是把这种接口上的关联隐藏到了字典key里,它在参数字典里使用@"message"时,就是在隐式地使用LoginViewInput的接口。

这种业务设计上导致的模块之间互相关联是不可避免的,也是不需要去隐藏的。隐藏了反而会引来麻烦。如果登录界面的属性名字变了,从NSString *message改成了NSString *notifyString,那么URL Router在register的时候也必须修改传参时的代码。如果register是由登录界面自己执行和处理的,而不是由App Context来处理的,那么此时参数key是固定为@"notifyString"的,那就会要求所有调用者的传参key也修改为notifyString,这种修改如果缺少编译器的帮助会很危险,目前是用宏来减少这种修改导致的工作量。而Protocol Router在修改时就能充分利用编译器进行检查,能够保证100%安全。

因此,URL Router并不能做到解耦,只是隐藏了接口关联而已。一旦遇到了需要修改或者重构的情况,麻烦就出现了,在替换宏的时候,你还必须仔细检查有没有哪里有直接使用字符串的key。只是简单地修改名字还是可控的,如果是需要增加参数呢?这时候就根本无法检查哪里遗漏了参数传递了。这就是字典传参的坏处。

关于这部分的讨论,也可以参考Peak大佬的文章:iOS组件化方案

Protocol Router在这种情况下也需要作出修改,但是它能帮助你安全高效地进行重构。而且只要稍加改进,也可以完全无需修改。解决方法就是把Protocol分离为Required InterfaceProvided Interface

Required InterfaceProvided Interface

模块的接口其实是有Required InterfaceProvided Interface的区别的。Required Interface就是调用者需要用到的接口,Provided Interface就是实际的被调用者提供的接口。

在UML的组件图中,就很明确地表现出了这两者的概念。下图中的半圆就是Required Interface,框外的圆圈就是Provided Interface

组件图

那么如何实施Required InterfaceProvided Interface?上一篇文章里已经讨论过,应该由App Context在一个adapter里进行接口适配,从而使得调用者可以继续在内部使用Required Interface,adapter负责把Required Interface和修改后的Provided Interface进行适配。

示例代码:

  • @protocol ModuleARequiredLoginViewInput <NSObject>
  • @property (nonatomic, copy) NSString *message;
  • @end
  • //Module A中的调用代码
  • UIViewController<ModuleARequiredLoginViewInput> *loginViewController = [ZIKViewRouterToView(LoginViewInput) makeDestination];
  • loginViewController.message = @"请登录查看笔记详情";
  • //Login Module Provided Interface
  • @protocol ProvidedLoginViewInput <NSObject>
  • @property (nonatomic, copy) NSString *notifyString;
  • @end
  • //App Context 中的 Adapter,用Objective-C的category或者Swift的extension进行接口适配
  • @interface LoginViewController (ModuleAAdapte) <ModuleARequiredLoginViewInput>
  • @property (nonatomic, copy) NSString *message;
  • @end
  • @implementation LoginViewController (ModuleAAdapte)
  • - (void)setMessage:(NSString *)message {
  • self.notifyString = message;
  • }
  • - (NSString *)message {
  • return self.notifyString;
  • }
  • @end

用category、extension、NSProxy等技术兼容新旧接口,工作全部由模块的使用和装配者App Context完成。如果LoginViewController已经有了自己的message属性,这时候就说明新的登录模块是不可兼容的,必须有某一方做出修改。当然,接口适配能做的事情是有限的,例如一个接口从同步变成了异步,那么这时候两个模块也是不能兼容的。

因此,如果模块需要进行解耦,那么它的接口在设计的时候就应该十分仔细,尽量不要在参数中引入太多其他的模块依赖。

只有存在Required InterfaceProvided Interface概念的设计,才能做到彻底的解耦。目前的路由方案都缺失了这一部分。

Target-Action

CTMediator的方案,把对模块的调用封装到Target-Action中,利用了Objective-C的runtime特性,省略了Target-Action的注册和绑定工作,直接通过CTMediator中介者调用目的模块的方法。

  • @implementation CTMediator (CTMediatorModuleAActions)
  • - (UIViewController *)CTMediator_viewControllerForDetail
  • {
  • UIViewController *viewController = [self performTarget:kCTMediatorTargetA
  • action:kCTMediatorActionNativFetchDetailViewController
  • params:@{@"key":@"value"}
  • shouldCacheTarget:NO
  • ];
  • if ([viewController isKindOfClass:[UIViewController class]]) {
  • // view controller 交付出去之后,可以由外界选择是push还是present
  • return viewController;
  • } else {
  • // 这里处理异常场景,具体如何处理取决于产品
  • return [[UIViewController alloc] init];
  • }
  • }
  • @end

-performTarget:action:params:shouldCacheTarget:方法通过NSClassFromString,获取目的模块提供的Target类,再调用Target提供的Action,实现了方法调用:

  • @implementation CTMediator
  • - (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget
  • {
  • NSString *targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
  • NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
  • Class targetClass;
  • NSObject *target = self.cachedTarget[targetClassString];
  • if (target == nil) {
  • targetClass = NSClassFromString(targetClassString);
  • target = [[targetClass alloc] init];
  • }
  • SEL action = NSSelectorFromString(actionString);
  • if (target == nil) {
  • // 这里是处理无响应请求的地方之一,这个demo做得比较简单,如果没有可以响应的target,就直接return了。实际开发过程中是可以事先给一个固定的target专门用于在这个时候顶上,然后处理这种请求的
  • return nil;
  • }
  • if (shouldCacheTarget) {
  • self.cachedTarget[targetClassString] = target;
  • }
  • if ([target respondsToSelector:action]) {
  • return [self safePerformAction:action target:target params:params];
  • } else {
  • // 有可能target是Swift对象
  • actionString = [NSString stringWithFormat:@"Action_%@WithParams:", actionName];
  • action = NSSelectorFromString(actionString);
  • if ([target respondsToSelector:action]) {
  • return [self safePerformAction:action target:target params:params];
  • } else {
  • // 这里是处理无响应请求的地方,如果无响应,则尝试调用对应target的notFound方法统一处理
  • SEL action = NSSelectorFromString(@"notFound:");
  • if ([target respondsToSelector:action]) {
  • return [self safePerformAction:action target:target params:params];
  • } else {
  • // 这里也是处理无响应请求的地方,在notFound都没有的时候,这个demo是直接return了。实际开发过程中,可以用前面提到的固定的target顶上的。
  • [self.cachedTarget removeObjectForKey:targetClassString];
  • return nil;
  • }
  • }
  • }
  • }
  • @end

优点

  • 实现简洁,整个实现的代码量很少
  • 省略了路由注册的步骤,可以减少一部分内存消耗和时间消耗,但是也略微降低了调用时的性能
  • 使用场景不局限于界面模块,所有模块都可以通过中介者调用

缺点

  • 在调用action时使用字典传参,无法保证类型安全,维护困难
  • 直接使用runtime互相调用,难以明确地区分Required InterfaceProvided Interface,因此其实无法实现完全解耦。和URL Router一样,在目的模块变化时,调用模块也必须做出修改
  • 过于依赖runtime特性,和Swift的类型安全设计是不兼容的,也无法跨平台多端实现

UIStoryboardSegue

苹果的storyboard其实也有一套路由API,只不过它的局限性很大。在这里简单介绍一下:

  • @implementation SourceViewController
  • - (void)showLoginViewController {
  • //调用在storyboard中定义好的segue identifier
  • [self performSegueWithIdentifier:@"presentLoginViewController" sender:nil];
  • }
  • //perform segue时的回调
  • - (BOOL)shouldPerformSegueWithIdentifier:(NSString *)identifier sender:(nullable id)sender {
  • return YES;
  • }
  • //配置目的界面
  • - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
  • //用[segue destinationViewController]获取目的界面,再对目的界面进行传参
  • }
  • @end

UIStoryboardSegue是和storyboard一起使用的,storyboard中定义好了一些界面跳转的参数,比如转场方式(push、present等),在执行路由前,执行路由的UIViewController会收到回调,让调用者配置目的界面的参数。

在storyboard中连接segue,其实是跳转到一个已经配置好界面的view controller,也就是和View相关的参数,都已经做好了依赖注入。但是自定义的依赖,却还是需要在代码中注入,所以又给了我们一个-prepareForSegue:sender:回调。

我不建议使用segue,因为它会导致强耦合。但是我们可以借鉴UIStoryboardSegue的sourceViewController、destinationViewController、封装跳转逻辑到segue子类、对页面执行依赖注入等设计。

总结

总结了几个路由工具之后,我的结论是:路由的选择还是以业务需求为先。当对动态性要求极高、或者需要多平台统一路由,则选择URL Router,其他情况下,我更倾向于使用Protocol Router。和Peak大大的结论一致。

Protocol Router目前并没有一个成熟的开源方案。因此我造了个轮子,增加了上面提到的一些需求。

ZIKRouter的特性

离散式管理

每个模块都对应一个或者多个router子类,在子类中管理各自的路由过程,包括对象的生成、模块的初始化、路由状态管理、AOP等。路由时,需要使用对应的router子类,而不是一个单例router掌管所有的路由。如果想要避免引用子类带来的耦合,可以用protocol动态获取router子类,或者用父类+泛型在调用者中代替子类。

采用离散式的设计的原因是想让各个模块对路由拥有充分的控制权。

一个router子类的简单实现如下:

```
@interface ZIKLoginViewRouter : ZIKViewRouter
@end

@implementation ZIKLoginViewRouter
//app启动时,注册对应的模块和Router
//不使用+load和+initialize方法,因为在Swift中已经不适用

  • (void)registerRoutableDestination {
    [self registerView:[ZIKLoginViewController class]];
    [self registerViewProtocol:ZIKRoutableProtocol(ZIKLoginViewProtocol)];
    }
    //执行路由时,返回对应的viewController或者UIView
  • (id)destinationWithConfiguration:(ZIKViewRouteConfiguration *)configuration {
    UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
    ZIKLoginViewController *destination = [sb instantiateViewControllerWithIdentifier:@"ZIKLoginViewController"];
    return destination;
    }
    //检查来自storyboard的界面是否需要让外界进行
top Created with Sketch.