导读：百度直播定位成直播SDK，赋能百度厂内APP使用，随着业务规模快速扩大、代码体量膨胀、宿主接入定制诉求强烈，在不影响业务迭代和业务规模扩张的前提下，直播工程架构也在不停优化。
一、背景
百度直播定位成直播SDK, 赋能百度厂内APP使用, 随着业务规模快速扩大、代码体量膨胀, 直播原有工程结构限制了直播的快速发展, 随着垂类APP数量接入, 宿主接入流程中定制困难/配置调试耗时/需要实现的协议多等问题制约了SDK对外的输出, 总结起来就是以下两个大类问题:
- 工程层面问题: 原生工程结构影响开发效率/业务代码耦合严重/宿主绑定的功能宏定义造成SDK差异化输出困难
- 接入流程层面问题: 定制困难/配置调试耗时/协议众多等问题
在不影响业务迭代和业务规模扩张的前提下, 直播团团队有针对性的逐步进行了改造, 实现最终SDK灵活高效的平台化输出。
二、工程层面改造
工程层面改造分为三步走, 首先是工程接入EasyBox, 其次是业务维度组件化多仓库拆分, 在前两步基础上最后完善SDK差异化输出能力, 整体完成了工程架构改造迁移。
1.工程改造
直播最早期工程是基于Xcode原生工程, 多project嵌套连编实现工程构件, 这种方式在弊端太多, 基于手百自研EasyBox工具链, 直播进行了工程化的改造, EasyBox工具链对于工程是标准化的模版式改造
首先是对于liveBoxAPP工程的壳化, 其次对于原有的业务工程标准分层, 直播工程重新划分了逻辑层级:
- 壳工程, 直播SDK编译运行构建环境
- MixTure构建层, 控制SDK差异化构建,通过EasyBox支持变体(variant)组件的实现差异化, 通过link_dependency控制产物SDK的自由组合生成
- 业务层, 直播核心业务
- 基础库层
- 宿主平台库依赖层/三方依赖库
基于以上改造, 使直播工程依赖关系更加清晰, Easybox分层使层级之间的依赖不会裂化, 以上改造只是基于直播原用工程结构的升级改造, 业务仓库本身还是有问题, 因此针对业务仓库做了多仓多组件模版拆分。
2.多仓多组件模版拆分
业务仓库的问题主要是业务耦合严重/权限无隔离, 直播早期仓库管理机制是Monorepo, 随着业务规模膨胀, 团队扩大, 直播按照模版业务唯独拆分了多仓库, 仓库管理升级到Multirepo, easyBox本身也支持Multirepo模式. 直播间业务VC是由一套slotPage框架来管理布局和服务, slotPage简单来说就是把直播间的UI和能力划分为(直播间内)组件/插件/服务, 提供组件的布局管理/事件分发/基础状态管理的一套页面管理机制, 直播针对business层仓库组件进行了模版维度的拆分, 具体分为已下几步:
- Business层拆分出service层, 将通用能力统一下沉到service层仓库组件
- 拆分基础核心直播容器组件, 提供直播间核心能力
- 拆分直播间功能沉淀为通用组件插件池
- 按照模版维度拆分Business层仓库组件, 归属业务模版特有的(直播间内)组件/插件
3. 支持SDK差异化输出
不同宿主对SDK定制需求差异化很大, 因此SDK要灵活支持裁剪, EasyBox虽然能通过变体(variant)和link_dependency能实现差异化构建, 但是对于直播间内小组件功能裁剪定制不太适用, ,因此直播提供小组件编译时注入能力, 直播组件都包含一个注册module, module分发直播核心的Module Event, 在event合适的时机, 注册组件的服务到Pyramid, 采用实现impl和interface分离的方式来实现真正的需要差异化输出组件的编译隔离, 差异化组件横向禁止依赖, impl组件只能依赖interface的接口组件。
基于以上改造, 灵活实现了直播功能小组件的差异化组装构建。
三、接入效率优化
工程层面问题改造完成后, 为了实现能够宿主自动接入/快速调试, 直播团队也做了很多辅助工具, 能够实现业务方自动化接入。
1. 自动化接入平台
由于SDK功能复杂而且可选,上下游依赖众多, 每接入一个宿主涉及众多业务,造成接入成本特别高, 因此直播开发了可视化出包平台, 宿主接入在用接入文档+自主出包平台的方案, 降低接入成本, 以下是流程图：
在接入平台上, 申请SDK接入, 填写相应的信息, 根据直播提供的功能清单选择功能, 审核通过后, 会触发对应的SDK构建, 可以快速获取SDK产物, 根据直播提供的接入文档, 即可实现自动接入。
2.快速源码调试/映射
直播是一个超大工程, 在宿主源码调试按照EasyBox配置方式需要引入直播所有仓库, 配置繁琐且容易出编译问题, 基于EasyBox工具, 直播开发了直播自己的源码调试插件, 可以在支持一键配置直播源码调试到宿主, 并且为了方便调试问题, 扩展了插件能力, 在EasyBox二进制源码映射机制开发了直播自己的小组件力度的映射, 原理图如下:
3.接入协议优化
SDK快速迭代, 对外暴露的协议也比较多, 每个宿主情况各异,每一个协议都实现对于业务接入成本也是很高, 直播提供一系列小组件二进制, 提供通用实现协议实现, 宿主根据自身情况自由引入, 降低接入成本。
四、收益
基于以上几步的改造, 收益比较明显, 主要是效率的提升:
- 借助EasyBox和mgit , 工程复杂度降低, 直播业务同学开发成本降低
- 基于直播差异化构建方案设计，垂类产品功能定制无需侵入直播核心业务，实现灵活可定制, 功能组件自由裁剪
- 借助于自动接入平台, 大大降低沟通对接成本, 实现接入使用SDK的自动化,标准化
- 开发EasyBox源码调试插件, 方便对接同学快速调试
五、结语
直播工程化是站在厂内EasyBox工具链的基础上, 结合直播特定的诉求, 演化成直播自己的工程开发模式, 无论是工程化改造还是接入效率优化,回归本质, 最终目的就是提升开发效率, 助力产品快速迭。
