组件化-BeeHive

解耦

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中的其他对象,基本上都是为这两种类型的对象服务的:

beehive-arch.png

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:

http://liumh.com/2018/10/11/beehive-analysis/

推荐阅读更多精彩内容