iOS组件化、插件化、模块化之路（一）

前言：公司一年多的小项目，进行项目拆分，要求是每个业务模块都可以单独打包。在开发过程中，如：酒店模块，只修改酒店单元，测试也只测试酒店部分。模块间相互不干扰，就有了，今天组件化之路。

一、组件化的目的。
说是组件化，其实更多的是模块化，对模块之间相互之间不干扰，可以单独打包，测试，且相同模块不同项目之间的移植便利许多。和Android的插件化大同小异，尤其是使用了cocoapods管理。

二、插件化需要使用到哪些技术。
在考虑拆分时候，考虑使用的是类似携程的主项目引用子项目的模式，但是考虑到尝试使用cocoapods 管理未果，还有就是考虑到项目之间的引用比较混乱，就使用了类似百度或者阿里的插件化方案。即将主项目变成壳工程，将其余模块都变成私有pods的形式引用。
这时候我们就会考虑到使用什么技术去让模块间相互调用。git上有各自router ，可以考虑的也有有多，包括ct的，MGJ ,阿里的Been。这个着重谈一下，CTMediator 和MGJRouter.

casatwy是通过CTMediator类实现组件化的，在此类中对外提供明确参数类型的接口，接口内部通过performTarget方法调用服务方组件的Target、Action。由于CTMediator类的调用是通过runtime主动发现服务的，所以服务方对此类是完全解耦的。但如果CTMediator类对外提供的方法都放在此类中，将会对CTMediator造成极大的负担和代码量。解决方法就是对每个服务方组件创建一个CTMediator的Category，并将对服务方的performTarget调用放在对应的Category中，这些Category都属于CTMediator中间件，从而实现了感官上的接口分离。但是实际过程中，还是通过CTMediator 对象，用runtime 创建对应的方法，然后当有这个对应方法时，之间运行实现方法。

蘑菇街的组件化方案，更像是一个中间件，中间件的注册用一个字典来保持，拿到url 将url 逐层拆分，然后将一个block 和url、回调的block 对应保存。当使用open url的时候，运行对应的Block 和回调的block 。

组件化过程中如何管理。
因为MGJRouter 需要一个注册的过程，并且需要知道注册的Url 才能调用。所有需要有一个保存的过程，这个创建一个文档用来保存对应的名称 url 用途，传参数等。另外，项目中使用私有pods 可以很容易的区分版本，只要保存podfile对应的私有pods 的版本号即可。即使私有私有pods 已经上传至服务端。

三、项目的基本架构

每个BU相互独立，但是唯一没有解耦的是，相互的之间的调用需要注册，如果使用的是CTMediator可剩下注册这步，完全解耦。