BeeHive、CTMediator、MGJRouter

1、BeeHive

提供以key为@protocol(协议)，value为class实现协议的键值对，当协议发生改变时候,编译阶段能够及时感知.

BeeHive组件化产生背景：
1)、功能代码之间的依赖复杂(模块与模块之间变成网状结构)，可维护性差；
2)、协同开发过程中，并行开发存在block;
3)、功能界限不清晰，基础功能模块变动，会导致上层业务受到影响；
4)、各团队负责功能模块，在主工程中有耦合代码(其它模块发生改变，主工程也需要改变)；
5)、上层业务出现反向提供功能给底层情况(违反了设计模式的依赖反转原则)；
6)、性能优化分析，随代码增加变得困难；
达到什么样目的：
1)、模块与模块之间直接调用，变成以服务的形式，避免直接依赖，Objective-C以协议的形式对外提供服务,C++通过抽象类；
2)、App生命周期的分发，将耦合在AppDelegate中的逻辑拆分，每个模块以微应用的形式独立存在；
如何接管App生命周期：
1）、在每一个模块中添加自定义生命周期函数，然后在生命周期类中的load方法使用method-swizzing；
2）、BeeHive通过BHAppDelegate实现UIApplicationDelegate协议，将app的生命周期分发到相应模块，从而避免每一个生命周期函数过分臃肿
3）、在通知中心注册，观察生命周期函数发生的变化
模块事件分为：系统事件(app生命周期事件)、通用事件(modSetup、modInit)等、业务自定义事件；
BeeHive提供了三种不同形式：
静态plist：读取配置文件中模块名(必须实现BHModuleProtocol的类名)或者服务(key为protocol，value为class)
动态注册 ：调用load方法在自己的模块注册class
注解：将各个模块名字写入到数据段中(__DATA),程序启动阶段，dyld的callback去读取__DATA段中提供的名字，然后放入到容器
中。

模块管理中心(BHModuleManager)
模块服务管理中心(BHServiceManager)
A模块调用B模块方法：
1)、B模块以协议的形式对外提供服务，通过向模块服务管理中心注册自己的服务
以key为@protocol(协议)，value为具体实现协议的类；
2)、A模块向模块服务管理中心根据协议，创建一个service,这个时候返回的是实现协议的对象;
3)、通过返回的对象，调用协议中申明的服务；
core与模块之间通过事件进行交互,实现插件隔离

2、CTMediator

通过中介模式CTMediator类，作为各个模块的中心，各个模块以CTMediator分类的形式扩展功能，CTMediator分类中提供服务
分类中的函数具体去调用target-action，target和action需要以字符串硬编码的形式，如果模块比较多，提供服务比较多，那么
字符串的硬编码需要时间维护。
去model化思想：如果A模块向B模块传递信息，推荐参数使用基本数据类型，而不是以model形式提供，否则A模块
依赖同一个model,B模块也依赖同一个model，这样模块间还是存在相互依赖，没有达到真正完全耦合。

 

3、MGJRouter

路由中心充当中介者，各个模块依赖路由中心，通过向路由中心注册自己的url和block, 路由中心维护一个字典，其它模块调用的时候
通过以url作为key,调用之前注册的block。
另外非常规参数，通过registerclass forProtocol形式提供，协议作为key，class作为value，这一点有点类似于Beehive

三者以类似Core-plugin的形式存在，一个模块一个plugin,plugin直接依赖core,而core不应该依赖plugin,每一个plugin可以用一个单独的git，使用cocoapods搭建私有库，根据不同的plugin 不同的tag进行引入。

core判断某个模块是否存在，通过NSClassFromString()，根据返回的class是否能够响应某个消息，若能够响应
则发送消息给target
粒度的划分：如何划分组件的粒度,这个是重点，难点；
1、基础组件
2、通用组件
3、业务组件

4、常见模块划分

1、数据上报模块

2、异常数据捕获模块入Bugly,KSCrash,PLCrashReporter

3、性能数据收集模块(APM)

4、第三方渠道模块(登录、支付、分享、发送，推送)

5、声音模块

6、日志模块

7、地图模块

8 等等

 

部分模块图如下：