直播间插件化的实践

序言

在直播间开发中,随着业务越来越复杂,以往MVC,或mvvm式的架构不太能满足业务和技术的要求。举例来说,如果产品想进行ABTest,对某些用户整个下掉坐席功能,有什么样的方法可以做到既不影响现有功能又能比较优雅的方式呢。我们在多变复杂的现实环境中,和未来不确定的因素下,又有什么样的架构方案可以比较完美的解决这些问题,就是今天探讨的组件化/变形金刚式开发。

img

插件/组件化是指,一个组件以一种便捷的方式在容器中添加移除查找,配置

对应的api有 addcomponent,removecomponent,getcomponent

组件Component,一个UI或功能的比较完整的模块。如公屏组件,显示用户发言,或进场的信息的模块。

容器Container,是多个组件的集合,用于完成特定产品上的特定功能,如直播间模块,直播间的组件有公屏组件,座位席组件,营收送礼组件,活动条组件。

好处

  1. 统一管理容器,通知模块的生命周期。

比如在直播间模块中,直播间有进入,观看,退出直播间的事件,用户鉴权有登录踢出,这些事件都可以完整的通知到各个组件。

  1. 支持多实例,方便模块内部的组织。

以观看端为例上下滑动就需要支持的多个直播间并存的场景,每个直播间有相同的组件功能。

  1. 统一配置信息

    组件需要用到一下共同的数据,或配置共同的数据,如uid,roomId,roomName

实现步骤

由于涉及到保密性,这里不贴代码,用纯文字或伪代码的形式讲述大致过程。

  1. livingRoomImpl 和 ILivingRoom 对应直播间模块的声明和实现,I开头一般表示protocol,里面的实现
@protocol 组件管理
-(void)添加组件;
-(void)移除组件;
-(id)根据名字找到组件;
-(void)移除所有的组件;
@end  
  1. 组件的共同代理
@protocol 组件的代理
-(instancetype)初始化组件;
-(void)开始添加组件;
-(void)准备移除组件;
-(void)房间号变化;
-(void)用户被踢出;
-(void)用户信息变更;
@end
  1. 组件的共同事件
@protocol 组件信息
-(id)appid
-(id)房间号
-(id)用户id
-(id)房间信息
-(api)组件的api
@end
  1. 各自组件的protocol

如公屏的

@protocol 公屏的protocol
-(bool)发送公屏
@end

另外有营收,坐席等其他组件类似。

注意的点

1.根据protocol找到实例

有一个大前提是需要根据protocol找到对应的实例。

介绍一个比较简单的方法,根据protocol的名字和直播间id把当前实例保存到数据中心,下次需要取得实例的时候就直接取得该实例。GetComponentByProtocol(protocol)

  1. 隐藏实现类细节。仅仅公开出protocol

    有个技巧是使用c函数去创建实例和完成组装如 RegisterPublicScreenComponent()

  2. 直播间配置相关的东西最好在初始化的时候,默认加载。注意初始化之前不要使用模块的方法,这个可以在设计上考虑怎么避免

使用方式

有了之前的基础,假设我们已经有了直播,公屏,坐席,送礼这些模块,现在需要把他们组装起来了。

于是有了以下的代码

[ATH_MIDWARE(ILivingRoom) createLivingRoom]
RegisterVideoComponent()
RegisterPublicScreenComponent()
RegisterSeatMembersCompnent()
RegisterSendGiftComponent()

需要把一个模块去掉,注释掉那个Register即可

如果我们把RegisterVideoComponent注释,就变成了文字直播间了,也同样支持送礼等功能。

后续

推行组件化其实是一个很痛苦的事情,面临着解耦和执行两个大问题。

  1. 解耦是需要分离出职责,找到组件核心的功能,实现并且对外声明必要的api

  2. 执行,前提需要理解整个组件化的核心思想,其中的沟通必不可少。如何定位和防止/提示问题也是考验架构师的能力。

寥寥数语,未能尽兴?有对架构有兴趣的同学可以添加我微信一起聊 haugnbo

你可能感兴趣的:(直播间插件化的实践)