解耦
BeeHive的核心主要有两类对象，一类是Service对象，第二类是Module对象。
Service解除依赖的方法是通过Protocol抽象来完成，在使用service对象的时候通过BHServiceManager来获取实现Protocol的对象，从而完成方法调用，不会依赖具体的对象类型。而对于Module解耦是通过事件来实现的，也可以认为是观察者模式。
Service和Module对象
Service对象实现了某个protocol的对象，使用它需要先通过BHServiceManager进行注册，这种对象的声明周期一般由调用方决定，一般来说比较短可能调用完成就释放了。还有一类是module类型，这种类型对象由BeeHive中的BHModuleManager对象进行管理，module对象也需要在注册之后才能使用，一般来说它的声明周期会长一些，通常还会处理app相关的一些事件，同时也可以自定义事件和处理自定义事件。
BHModuleProtocol定义了所有被管理起来的module需要实现的一些方法，但是都是可选实现。主要是module自己排序相关的level和priority，剩下的主要是BeeHive中定义的一些app生命周期的事件处理方法。
BHServiceProtocol定义了提供服务的对象是否是单例，自定义Service基本上都是继承自它。
而BeeHive中的其他对象，基本上都是为这两种类型的对象服务的：
BHServiceManager
这个类是用来管理service和implemention之间的映射，implemention的初始化也通过它来完成。但是对implemention的缓存是放在BHContext中，这个类的实现也比较简单。
看一下头文件，主要的接口就是为了注册一个service和创建service对象:
@interface BHServiceManager : NSObject
@property (nonatomic, assign) BOOL enableException;
+ (instancetype)sharedManager;
- (void)registerLocalServices;
- (void)registerService:(Protocol *)service implClass:(Class)implClass;
- (id)createService:(Protocol *)service;
- (id)createService:(Protocol *)service withServiceName:(NSString *)serviceName;
- (id)createService:(Protocol *)service withServiceName:(NSString *)serviceName shouldCache:(BOOL)shouldCache;
- (id)getServiceInstanceFromServiceName:(NSString *)serviceName;
- (void)removeServiceWithServiceName:(NSString *)serviceName;
@end
BHModuleManager
所有的module的管理对象，提供了module相关的声明周期方法: 加载，注册，注销以及module自身相关的元数据信息，比如是否已经初始化，module的level和prioirty信息(用来对module进行排序)。除了module还会管理与module相关的事件。整体上看，其实这个对象核心就是处理各种module的事件。
当需要注册一个module的时候会对module进行初始化，同时会生成module相关的元数据信息存放到BHModuleInfos数组中。module对象的维护是存放在BHModules中，并通过module Level和 module Priority 进行排序。然后是注册与module关联的事件，这里的事件默认主要是系统事件，类似前后台的切换，openUrl的事件等。最后一步是如果有必要(通过传入的参数来控制) 触发一些初始化事件，比如setup,init等事件。事件的管理是通过BHSelectorByEvent字典实现的，它存放了event和selector的映射，通过event可以查询selector，再对module进行调用处理。
以下是BHModuleManager内部主要的数据存储的对象，所有的module，事件信息都通过它们进行管理
1)BHModuleInfos里存储了module对应的类型信息，level和priority信息，以及是否初始化信息，它保证全局同类型的module只有一个存在。
2)BHModules里存储了所有的module信息
3)BHModulesByEvent里存储event和module的映射，主要是为了处理事件发生时找到所有对应的module
4)BHSelectorByEvent存储event和selector的映射，通过事件来查找对应的相应函数，进行调用
Module的事件封装以及参数传递
下面说一下module事件的定义以及封装，在处理事件的过程中，参数以及上下文信息如何进行封装和传递的。
它通过枚举定义了所有系统层的事件，比如前后台切换，openUrl，app一些生命周期的事件等等。它本身是通过Int来进行存储的，所以用户可以通过int来定义自己的事件。BHModuleManager会将传入的事件参数封装到BHContext中，并且通过copy的方式传给对应的module。而BHContext本身就存储了各种上下文信息，比如开发环境，config信息等。通过它module可以知道当前所需要的一些环境信息。BHContext本身是单例，对于module而言应该是使用copy之后的对象，避免因为错误的改动导致全局的参数发生变化影响到其他的module。
Service和Module的区别, 为什么同时存在
Service用来创建一些实现了某些功能接口的对象，完成某次调用可能对应的对象就会被释放了，如果调用频率高会缓存到BHContext中。而BHModulesManager管理的对象它可能是存在比较长的时间，比如和App的声明周期一样，像网络库，广告SDK等，它和BHServiceManager管理的对象最大区别就是生命周期不同，它可能会参与到App或者自定义的事件中。对于实现组件化，常驻内存的对象可以考虑封装成BHModule对象，通过BHModuleManager来进行管理，而临时使用的接口，比如一些数据处理对象，日期格式化对象(主要是那些只跟某些特定业务相关的对象,可能退出页面就用不到了)可以通过Service的方式来进行管理。
BHConfig/BHContext/BHWatchDog
BHConfig :对象是配置对象，提供了按照类型进行存取的功能。
BHContext: 它存储了Config对象，开发环境信息，以及自定义事件以及参数，service缓存的对象也存放在这个对象之中。
BHWatchDog: 它是用来监测主线程是否卡顿的对象，发生卡顿会打印日志提示。实现卡顿监测的原理是封装了一个子线程，在子线程中有一个标记位。通过子线程不断的循环在循环中派发一个handler到主线程中，派发到主线程中主要做的事情就是处理标记位，之后通过设置的interval让子线程睡眠对应时间，睡眠interval秒之后再通过标记位来判断主线程是否发生了卡顿。如果发生卡顿，主线程在interval时间内可能来不及处理标记位，然后由此推断出发生了卡顿。为了防止不必要的额外n次派发，在子线程中增加了信号量来控制派发次数，在handler中会增加信号量，每次循环结束会通过dispatch_semaphore_wait判断信号量是否大于0，否则一直处于等待。
BHRouter路由实现
BHRouter: 通过URL的方式实现页面跳转，module的注册，service注册，以及对象方法的调用。url的格式定义了解析的逻辑，所以格式是固定的:
//url - > com.alibaba.beehive://call.service.beehive/pathComponentKey.protocolName.selector/...?params={}(value url encode)
//url - > com.alibaba.beehive://register.beehive/pathComponentKey.protocolName/...?params={}(value url encode)
//url - > com.alibaba.beehive://jump.vc.beehive/pathComponentKey.protocolName.push(modal)/...?params={}(value url encode)#push
在BHRouter中定义了BHRPathComponent对象，它可以理解成封装了某个pathComponentKey的处理逻辑，如果需要使用BHRPathComponent，需要先注册，pathComponentKey和Component的关系会存放到一个字典中，后续在处理url的时候会通过pathComponentKey获取对应的Component进行处理。如果对url的处理逻辑相对简单，没有特别的需求，可以不使用BHRPathComponent。我能想到的复杂点的处理，比如对于页面跳转可能有一些特殊的需求，不仅仅只是首页跳转到某个页，可能是需要支持特定的页面路径，这种需求做成统一处理的逻辑是比较困难的，但是如果通过BHRPathComponent封装起来，url解析那块的逻辑会很清晰，不使用BHRPathComponent封装会导致if else 或者 switch case逻辑很多不好维护，所以这部分算是比较好的设计，最常使用的场景和一些复杂的场景都考虑到了，代码的逻辑也不会很复杂。在调用openUrl的时候，可以传入参数，这部分参数会和url里的query参数合并到一起。
在push一个页面的时候，除了需要动态创建一个vc的对象，还需要把一些参数传给vc，这部分是通过kvc对vc的属性进行赋值，再这之前会对参数进行过滤，会判断是否有对应的property，不存在的会从参数中删除。
BHRouter本身提供了一种更加解耦的调用对象方法以及注册service和model的方式，因为是纯字符串url的方式。成本在于拼接url需要按照特定规则，参数需要序列化成字符串json参数(这部分很难手写出来)。如果需要处理页面跳转，是只能通过BHRouter来处理的。
BeeHive和BHAppDelegate
BeeHive封装了BHServiceManager和BHModuleManager，提供了更加方便调用的注册module以及注册service创建service的接口。BHAppDelegate取代原始的Appdelegate，主要是为了更方便的处理App声明周期相关的各个事件，把事件发送给所有module
reference:
