你我学习网
一、背景
前段时间对我们自己的App做了结构上的重构，抛弃了之前简单的MVC开发模式，原因是随着App的业务线越来越多，单个页面的功能越来越复杂，MVC开发模式导致整个Controller-layer的代码越来越多。本文将分享重构中的Router模块。
使用路由模式可以解决我们项目中页面与页面之间的耦合(因为我们App是视图生命周期作为驱动，所以这里说是页面，实际是控制器层)，因为一个页面功能太多就会引入过多的类，往往会造成import过多，不好管理。而且iOS中执行界面跳转的时候，很容易产生模块间的耦合。
iOS执行界面跳转的时候，代码如下：
[firstViewController.navigationController pushViewController:destinationViewController];
如果在firstViewController里面直接引入头文件就会导致模块间的耦合。我们这里就需要路由模块去解决类似的问题。我们的设计是每个模块都有自己的路由管理，路由主要职责应该有：
管理模块内部跳转。
声明模块的对外接口
声明模块的依赖
二、模块间的跳转
这种设计是松耦合的，我们搜寻的模块可以随时被相同功能的模块替换，这样我们就实现了两个模块的解耦。
目前路由的设计限于以下几种：
字符串标识对应界面，例如URL Router
利用Object-C特性，直接调用目的模块的方法
用protocol来和某个界面进行匹配
三、URL Router
目前绝大多数的路由是由字符串来打开某个页面，代码大概如下：
//注册某个页面在路由的url地址
[URLRouter registURL:@“Desination” handler:^(NSDictionary * userDic){
};
//使用路由
[URLRouter openURL:@“app://***Module/Destionation”];传递一串参数URL就可以进行页面间的跳转，这种方案可以再运行时随时更改路由规则，指向不同的页面，也可以支持多级页面跳转。这种方案有极大的灵活性。
而且此种方案最容易跨平台实现的，iOS, Android,PC都可以按照URL来进行路由。
iOS中可以通过URL Scheme进行进程间的通信，同App外面打开App中的某个页面，此方案可以完美兼容URL Router。
当然这种方案缺点也是很明显的：
第一、基于URL的设计只适合与UI界面，功能性的模块是不能采用这种方案的，所以这种方案只适用于视图驱动的模块。
第二、这种方案维护比较困难，要维护一大批的字符串，还要维护传参。
第三、安全性不高，因为只有在运行时才能检查出错误，类似于swift早期中selector用字符串寻找的问题。
四、Protocol Router
这是我们采用的路由模式，代码如下：
id<***ServiceProtocol> service = [[ProtocolRouter shareInstance] findService:@protocol(***service)];
这种设计方案安全性比较高，在编译阶段就可以检测出问题，更适合于swift的设计思想，任何模块都可以使用，包括功能模块，不仅仅局限于UI模块。此种方案就会缺少相应的动态性，不过可以做一层URL Router的Adapter层专门用于动态性的需求。
基于Protocol的设计方案不会引起耦合，我们可以轻易替换掉相同功能的目的模块，这种方案也适用于各种解耦，例如Appdelegate的解耦。
以上就是我们在程序中实行组件化的一步，随着App容量的增大，组件化是必不可少的一步，它可以让我们的App更规范，模块的重用性更高。
