序言
在直播间开发中，随着业务越来越复杂，以往MVC，或mvvm式的架构不太能满足业务和技术的要求。举例来说，如果产品想进行ABTest，对某些用户整个下掉坐席功能，有什么样的方法可以做到既不影响现有功能又能比较优雅的方式呢。我们在多变复杂的现实环境中，和未来不确定的因素下，又有什么样的架构方案可以比较完美的解决这些问题，就是今天探讨的组件化/变形金刚式开发。
img
插件/组件化是指，一个组件以一种便捷的方式在容器中添加，移除，查找,配置
对应的api有 addcomponent，removecomponent，getcomponent
组件Component，一个UI或功能的比较完整的模块。如公屏组件，显示用户发言，或进场的信息的模块。
容器Container，是多个组件的集合，用于完成特定产品上的特定功能，如直播间模块，直播间的组件有公屏组件，座位席组件，营收送礼组件，活动条组件。
好处
- 统一管理容器，通知模块的生命周期。
比如在直播间模块中，直播间有进入，观看，退出直播间的事件，用户鉴权有登录踢出，这些事件都可以完整的通知到各个组件。
- 支持多实例，方便模块内部的组织。
以观看端为例上下滑动就需要支持的多个直播间并存的场景，每个直播间有相同的组件功能。
-
统一配置信息
组件需要用到一下共同的数据，或配置共同的数据，如uid,roomId,roomName
实现步骤
由于涉及到保密性，这里不贴代码，用纯文字或伪代码的形式讲述大致过程。
- livingRoomImpl 和 ILivingRoom 对应直播间模块的声明和实现，
I开头一般表示protocol，里面的实现
@protocol 组件管理
-(void)添加组件;
-(void)移除组件;
-(id)根据名字找到组件;
-(void)移除所有的组件;
@end
- 组件的共同代理
@protocol 组件的代理
-(instancetype)初始化组件;
-(void)开始添加组件;
-(void)准备移除组件;
-(void)房间号变化;
-(void)用户被踢出;
-(void)用户信息变更;
@end
- 组件的共同事件
@protocol 组件信息
-(id)appid
-(id)房间号
-(id)用户id
-(id)房间信息
-(api)组件的api
@end
- 各自组件的protocol
如公屏的
@protocol 公屏的protocol
-(bool)发送公屏
@end
另外有营收，坐席等其他组件类似。
注意的点
1.根据protocol找到实例
有一个大前提是需要根据protocol找到对应的实例。
介绍一个比较简单的方法，根据protocol的名字和直播间id把当前实例保存到数据中心，下次需要取得实例的时候就直接取得该实例。GetComponentByProtocol(protocol)
-
隐藏实现类细节。仅仅公开出protocol
有个技巧是使用c函数去创建实例和完成组装如
RegisterPublicScreenComponent() -
直播间配置相关的东西最好在初始化的时候，默认加载。注意初始化之前不要使用模块的方法，这个可以在设计上考虑怎么避免
使用方式
有了之前的基础，假设我们已经有了直播，公屏，坐席，送礼这些模块，现在需要把他们组装起来了。
于是有了以下的代码
[ATH_MIDWARE(ILivingRoom) createLivingRoom]
RegisterVideoComponent()
RegisterPublicScreenComponent()
RegisterSeatMembersCompnent()
RegisterSendGiftComponent()
需要把一个模块去掉，注释掉那个Register即可
如果我们把RegisterVideoComponent注释，就变成了文字直播间了，也同样支持送礼等功能。
后续
推行组件化其实是一个很痛苦的事情，面临着解耦和执行两个大问题。
-
解耦是需要分离出职责，找到组件核心的功能，实现并且对外声明必要的api
-
执行，前提需要理解整个组件化的核心思想，其中的沟通必不可少。如何定位和防止/提示问题也是考验架构师的能力。
寥寥数语，未能尽兴？有对架构有兴趣的同学可以添加我微信一起聊 haugnbo
网友评论