在2013年的时候,我们就已经实现了类似于http地址进行页面跳转, 那个时候,主要是用继承ViewController和给 UIViewController和UINavigationController写类别实现的.
这样虽然也实现了,但是还是有一些不美观,耦合的比较严重.
最近看了一篇博文,受里面的启发,自己重新实现了相关的VC跳转
上面有很多类目, 我只是针对其中的一个类目进行代码编写的:
以下是摘自上述博文:
跨业务页面调用方案的设计
跨业务页面调用是指，当一个App中存在A业务，B业务等多个业务时，B业务有可能会需要展示A业务的某个页面，A业务也有可能会调用其他业务的某个页面。在小规模的App中，我们直接import其他业务的某个ViewController然后或者push或者present，是不会产生特别大的问题的。但是如果App的规模非常大，涉及业务数量非常多，再这么直接import就会出现问题。
跨业务的页面调用在多业务组成的App中会导致横向依赖。那么像这样的横向依赖，如果不去设法解决，会导致什么样的结果？
当一个需求需要多业务合作开发时，如果直接依赖，会导致某些依赖层上端的业务工程师在前期空转，依赖层下端的工程师任务繁重，而整个需求完成的速度会变慢，影响的是团队开发迭代速度。
当要开辟一个新业务时，如果已有各业务间直接依赖，新业务又依赖某个旧业务，就导致新业务的开发环境搭建困难，因为必须要把所有相关业务都塞入开发环境，新业务才能进行开发。影响的是新业务的响应速度。
当某一个被其他业务依赖的页面有所修改时，比如改名，涉及到的修改面就会特别大。影响的是造成任务量和维护成本都上升的结果。
当然，如果App规模特别小，这三点带来的影响也会特别小，但是在阿里这样大规模的团队中，像天猫／淘宝这样大规模的App，一旦遇上这里面哪怕其中一件事情，就特么很坑爹。
那么应该怎样处理这个问题？
让依赖关系下沉。
怎么让依赖关系下沉？引入Mediator模式。
所谓引入Mediator模式来让依赖关系下沉，实质上就是每次呼唤页面的时候，通过一个中间人来召唤另外一个页面，这样只要每个业务依赖这个中间人就可以了，中间人的角色就可以放在业务层的下面一层，这就是依赖关系下沉。
当A业务需要调用B业务的某个页面的时候，将请求交给Mediater，然后由Mediater通过某种手段获取到B业务页面的实例，交还给A就行了。在具体实现这个机制的过程中，有以下几个问题需要解决：
- 设计一套通用的请求机制，请求机制需要跟业务剥离，使得不同业务的页面请求都能够被Mediater处理
- 设计Mediater根据请求如何获取其他业务的机制，Mediater需要知道如何处理请求，上哪儿去找到需要的页面
这个看起来就非常像我们web开发时候的URL机制，发送一个Get或Post请求，CGI调用脚本把请求分发给某个Controller下的某个Action，然后返回HTML字符串到浏览器去解析。苹果本身也实现了一套跨App调用机制，它也是基于URL机制来运转的，只不过它想要解决的问题是跨App的数据交流和页面调用，我们想要解决的问题是降低各业务的耦合度。
不过我们还不能直接使用苹果原生的这套机制，因为这套机制不能够返回对象实例。而我们希望能够拿到对象实例，这样不光可以做跨业务页面调用，也可以做跨业务的功能调用。另外，我们又希望我们的Mediater也能够跟苹果原生的跨App调用兼容，这样就又能帮业务方省掉一部分开发量。
------摘自完毕
博文地址:
http://casatwy.com/iosying-yong-jia-gou-tan-viewceng-de-zu-zhi-he-diao-yong-fang-an.html
我这边已经实现了一个类似的,剥离了VC之间的耦合关系.
github地址:
https://github.com/xzjxylophone/RXVCMediator