前段时间对我们自己的 App 做了结构上的重构,抛弃了之前的简单的 MVC 开发模式,原因是随着 App 的业务线越来越多,单个页面的功能越来越复杂,MVC 开发模式就导致整个 Controller-layer 的代码越来越多,这次仅讲一下重构中的 Router 模块。
使用路由模式可以解决我们项目中页面与页面之间的耦合(因为我们 App 是视图生命周期作为驱动,所以这里说是页面,实际是控制器层),因为一个页面功能太多就会引入过多的类。往往造成 import 过多,不好管理。而且 iOS 中执行界面跳转的时候,很容易产生模块间的耦合。
iOS 执行界面跳转的时候,代码如下:
如果在 firstViewController 里面直接引入头文件就会导致模块间的耦合。我们这里就需要路由模块去解决类似的问题。我们的设计是每个模块都有自己的路由管理,路由主要职责应该有:
管理模块内部跳转。
声明模块的对外接口
声明模块的依赖
模块间的跳转
这种设计是松耦合的,我们搜寻的模块可以随时被相同功能的模块替换,这样我们就实现了两个模块的解耦。
目前路由的设计限于以下几种:
字符串标识对应界面,例如URL Router
利用Object-C特性,直接调用目的模块的方法
用protocol来和某个界面进行匹配
URL Router
目前绝大多数的路由是由字符串来打开某个页面,代码大概如下:
1
2
3
4
5 | //注册某个页面在路由的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
这种路由也是我们采用的路由模式,代码如下:
这种设计方案安全性比较高,在编译阶段就可以检测出问题,更适合于 swift 的设计思想,任何模块都可以使用,包括功能模块,不仅仅局限于 UI 模块。此种方案就会缺少相应的动态性,不过可以做一层 URL Router 的 Adapter 层专门用于动态性的需求。
基于 Protocol 的设计方案不会引起耦合,我们可以轻易替换掉相同功能的目的模块,这种方案也适用于各种解耦,例如 Appdelegate 的解耦。
以上就是我们在程序中实行组件化的一步,随着 App 容量的增大,组件化是必不可少的一步,它可以让我们的 App 更规范,模块的重用性更高。
本文转载自宜信技术学院网站。
原文链接:http://college.creditease.cn/detail/200
评论