组件化—–iOS组件化编程BeeHive

前言

BeeHive是一个抽象的APP框架设计方式,旨在模块化编程,降低项目内部组件间&类间耦合,实现大团队协作开发互不影响&管理业务模块。

本文的学习过程

1.Beehive的原理&作用

2.Beehive的实现原理

3.Beehive的拓展

1.Beehive的原理&作用

主要原理:

通过注册模块&服务,利用Protocol的方式,来实现API开放和被调用,实现了模块间解耦的目的。

感受:

牺牲了开发的工作时间规范了项目的框架,提高了APP的稳定性,扩展性,责任到人的表现更明显,便于项目管控

普通开发情况

直接开发,类和类间,业务和业务间存在直接的关联,耦合度高。 项目较大的时候,开发人员容易受关联而影响工作效率。由于耦合度过高,后期的维护以及隐性的问题较多。

BeeHive的开发框架

Beehive的开发方式,将每个类,组件,业务抽象成一个个的服务。注册到BeeHive管理类,其它使用该服务可直接调用。当服务需要剥离的时候,只要移除代码,管理协议文件即可。

2.Beehive的实现原理

官方的框架图 (Spring框架的Service思想)

框架图的理解

的理解

1.是一组具有一定内聚性代码的组合,职责明确。对外的接口可以是松散的,也可以是集中的。

2.一个模块,有一个modelClass文件,

3.module和service是一个模块之间的不同组成部分,它们之间并没有很强的逻辑关系,moduleClass负责接收各种事件以及事件的处理,而service负责业务的功能实现。比如说,可以在moduleClass生命周期函数注册service。模块之间的通讯需要通过service暴露出来的协议接口来实现。模块间解耦的目的1.各个模块以插件的形式存在。每个都可独立,相互解耦。

2.各个模块具体实现与接口调用分离

3.各个模块也有生命周期,也可以进行管理。

Module的3种注册方式

模块的特点

1.限制住了所有的Module的对象都要是遵守BHModuleProtocol协议的。

2.任何其他地方alloc创建出来,即使创建一个新的Module实例出来,它也并不在BHModuleManager的管理下,是无法接收BHModuleManager分发的系统事件,创建出来是没有任何意义的。

各个模块也有生命周期,也可以进行管理(回顾模块的第三个目的,这个就是模块全部遵守了BHModuleProtocol协议的原因)

BeeHive会给每个模块提供生命周期事件,用于与BeeHive宿主环境进行必要信息交互,感知模块生命周期的变化。

上面BHModuleEventType枚举主要分为三种,一种是系统事件,另外一种是应用事件,最后一种是业务自定义事件。

官方系统事件描述图

使用的时候,怎么用?用来做什么?1.初始化配置

注册服务

BeeHive的核心思想—–服务

1.BeeHive模块调用,2.服务可以能是一个NSObjct的子类,可能是ViewController

注册服务(Protocol)的方式总共有三种,和注册Module是一样一一对应的

使用的时候主要应用两个方法

1.注册服务

2.获取&创建符合协议的服务实例

例如

id<TradeServiceProtocol> obj = [[BeeHive shareInstance] createService:@protocol(TradeServiceProtocol)];

if ([obj isKindOfClass:[UIViewController class]]) {

obj.itemId = @"12313231231";

[self.navigationController pushViewController:(UIViewController *)obj animated:YES];    }

Beehive的其它辅助类

BHConfig这也是一个单例,里面保存了一个config的NSMutableDictionary字典。字典维护了一些动态的环境变量,作为BHContext的补充存在。

BHTimeProfiler就是用来进行计算时间性能方面的Profiler。

BHWatchDog是可以开一个线程,设置好handler,每隔一段时间就执行一个handler。

总结

框架很好地将项目抽象出模块化和服务。

模块能区域性统一管理服务和生命周期逻辑。

多人开发项目的时候,只要按要求暴露协议中的方法就可以,服务复用也很好,业务剥离的时候只要删除代码整理协议的方法就可以。

可以集中查看注册的协议,方便开发者获取需要的服务

优势的地方

没有完全地脱耦合,服务和protocol耦合,牺牲了一点内存和开发者的脑汁,小项目不需要这么绕,太绕了,开发时没有达到共识,会让项目更加混乱,后期维护的难度将被大大地提高。

疑问

目前发现一个service对应一个protocol, 能不能一个protocol有几个service满足?

应该不可以,不然就乱了吧!!!!

3.Beehive的拓展—-蘑菇街MGJRouter

MGJRouter的原理是:  URL-Block

MGJRouter实现图解

类调用其它类的方式

如果使用MGJRouter,项目的框架可以如下图

总结

优势

直接达到解耦的目的,并且在url不存在的情况下,项目不会奔溃。多人开发的时候,可以预定义URL进行交互。URL可以统一管理。简单,明了!容易使用

业务划分更佳清晰,新人接手更容易,可以按组件分配开发任务,有空操作/空模块的性能

项目可维护性更强,提高开发效率。

更好排查问题,某个组件出现问题,直接对组件进行处理。

开发测试过程中,可以只编译自己那部分代码,不需要编译整个项目代码。

劣势

Block方法分散,闭包保存的过程中占用内存

参考的APP框架

发表评论

邮箱地址不会被公开。 必填项已用*标注