?導(dǎo)讀：百度直播定位成直播SDK，賦能百度廠內(nèi)APP使用，隨著業(yè)務(wù)規(guī)?？焖贁U大、代碼體量膨脹、宿主接入定制訴求強烈，在不影響業(yè)務(wù)迭代和業(yè)務(wù)規(guī)模擴張的前提下，直播工程架構(gòu)也在不停優(yōu)化。

一、背景

百度直播定位成直播SDK, 賦能百度廠內(nèi)APP使用, 隨著業(yè)務(wù)規(guī)?？焖贁U大、代碼體量膨脹, 直播原有工程結(jié)構(gòu)限制了直播的快速發(fā)展, 隨著垂類APP數(shù)量接入, 宿主接入流程中定制困難/配置調(diào)試耗時/需要實現(xiàn)的協(xié)議多等問題制約了SDK對外的輸出, 總結(jié)起來就是以下兩個大類問題:

• 工程層面問題: 原生工程結(jié)構(gòu)影響開發(fā)效率/業(yè)務(wù)代碼耦合嚴重/宿主綁定的功能宏定義造成SDK差異化輸出困難
• 接入流程層面問題: 定制困難/配置調(diào)試耗時/協(xié)議眾多等問題

在不影響業(yè)務(wù)迭代和業(yè)務(wù)規(guī)模擴張的前提下, 直播團團隊有針對性的逐步進行了改造, 實現(xiàn)最終SDK靈活高效的平臺化輸出。

二、工程層面改造

工程層面改造分為三步走, 首先是工程接入EasyBox, 其次是業(yè)務(wù)維度組件化多倉庫拆分, 在前兩步基礎(chǔ)上最后完善SDK差異化輸出能力, 整體完成了工程架構(gòu)改造遷移。

1.工程改造

直播最早期工程是基于Xcode原生工程, 多project嵌套連編實現(xiàn)工程構(gòu)件, 這種方式在弊端太多, 基于手百自研EasyBox工具鏈, 直播進行了工程化的改造, EasyBox工具鏈對于工程是標準化的模版式改造

首先是對于liveBoxAPP工程的殼化, 其次對于原有的業(yè)務(wù)工程標準分層, 直播工程重新劃分了邏輯層級:

• 殼工程, 直播SDK編譯運行構(gòu)建環(huán)境
• MixTure構(gòu)建層, 控制SDK差異化構(gòu)建,通過EasyBox支持變體(variant)組件的實現(xiàn)差異化, 通過link_dependency控制產(chǎn)物SDK的自由組合生成
• 業(yè)務(wù)層, 直播核心業(yè)務(wù)
• 基礎(chǔ)庫層
• 宿主平臺庫依賴層/三方依賴庫?

基于以上改造, 使直播工程依賴關(guān)系更加清晰, Easybox分層使層級之間的依賴不會裂化, 以上改造只是基于直播原用工程結(jié)構(gòu)的升級改造, 業(yè)務(wù)倉庫本身還是有問題, 因此針對業(yè)務(wù)倉庫做了多倉多組件模版拆分。?

2.多倉多組件模版拆分

業(yè)務(wù)倉庫的問題主要是業(yè)務(wù)耦合嚴重/權(quán)限無隔離, 直播早期倉庫管理機制是Monorepo, 隨著業(yè)務(wù)規(guī)模膨脹, 團隊擴大, 直播按照模版業(yè)務(wù)唯獨拆分了多倉庫, 倉庫管理升級到Multirepo, easyBox本身也支持Multirepo模式. 直播間業(yè)務(wù)VC是由一套slotPage框架來管理布局和服務(wù), slotPage簡單來說就是把直播間的UI和能力劃分為(直播間內(nèi))組件/插件/服務(wù), 提供組件的布局管理/事件分發(fā)/基礎(chǔ)狀態(tài)管理的一套頁面管理機制, 直播針對business層倉庫組件進行了模版維度的拆分, 具體分為已下幾步:

• Business層拆分出service層, 將通用能力統(tǒng)一下沉到service層倉庫組件
• 拆分基礎(chǔ)核心直播容器組件, 提供直播間核心能力
• 拆分直播間功能沉淀為通用組件插件池
• 按照模版維度拆分Business層倉庫組件, 歸屬業(yè)務(wù)模版特有的(直播間內(nèi))組件/插件?

3. 支持SDK差異化輸出

不同宿主對SDK定制需求差異化很大, 因此SDK要靈活支持裁剪, EasyBox雖然能通過變體(variant)和link_dependency能實現(xiàn)差異化構(gòu)建, 但是對于直播間內(nèi)小組件功能裁剪定制不太適用, ,因此直播提供小組件編譯時注入能力, 直播組件都包含一個注冊module, module分發(fā)直播核心的Module Event, 在event合適的時機, 注冊組件的服務(wù)到Pyramid, 采用實現(xiàn)impl和interface分離的方式來實現(xiàn)真正的需要差異化輸出組件的編譯隔離, 差異化組件橫向禁止依賴, impl組件只能依賴interface的接口組件。

?

基于以上改造, 靈活實現(xiàn)了直播功能小組件的差異化組裝構(gòu)建。?

三、接入效率優(yōu)化

工程層面問題改造完成后, 為了實現(xiàn)能夠宿主自動接入/快速調(diào)試, 直播團隊也做了很多輔助工具, 能夠?qū)崿F(xiàn)業(yè)務(wù)方自動化接入。

1. 自動化接入平臺

由于SDK功能復(fù)雜而且可選,上下游依賴眾多, 每接入一個宿主涉及眾多業(yè)務(wù),造成接入成本特別高, 因此直播開發(fā)了可視化出包平臺, 宿主接入在用接入文檔+自主出包平臺的方案, 降低接入成本, 以下是流程圖：

在接入平臺上, 申請SDK接入, 填寫相應(yīng)的信息, 根據(jù)直播提供的功能清單選擇功能, 審核通過后, 會觸發(fā)對應(yīng)的SDK構(gòu)建, 可以快速獲取SDK產(chǎn)物, 根據(jù)直播提供的接入文檔, 即可實現(xiàn)自動接入。

2.快速源碼調(diào)試/映射

直播是一個超大工程, 在宿主源碼調(diào)試按照EasyBox配置方式需要引入直播所有倉庫, 配置繁瑣且容易出編譯問題, 基于EasyBox工具, 直播開發(fā)了直播自己的源碼調(diào)試插件, 可以在支持一鍵配置直播源碼調(diào)試到宿主, 并且為了方便調(diào)試問題, 擴展了插件能力, 在EasyBox二進制源碼映射機制開發(fā)了直播自己的小組件力度的映射, 原理圖如下:

3.接入?yún)f(xié)議優(yōu)化

SDK快速迭代, 對外暴露的協(xié)議也比較多, 每個宿主情況各異,每一個協(xié)議都實現(xiàn)對于業(yè)務(wù)接入成本也是很高, 直播提供一系列小組件二進制, 提供通用實現(xiàn)協(xié)議實現(xiàn), 宿主根據(jù)自身情況自由引入, 降低接入成本。

四、收益

基于以上幾步的改造, 收益比較明顯, 主要是效率的提升:

• 借助EasyBox和mgit , 工程復(fù)雜度降低, 直播業(yè)務(wù)同學開發(fā)成本降低
• 基于直播差異化構(gòu)建方案設(shè)計，垂類產(chǎn)品功能定制無需侵入直播核心業(yè)務(wù)，實現(xiàn)靈活可定制, 功能組件自由裁剪
• 借助于自動接入平臺, 大大降低溝通對接成本, 實現(xiàn)接入使用SDK的自動化,標準化
• 開發(fā)EasyBox源碼調(diào)試插件, 方便對接同學快速調(diào)試?

五、結(jié)語

直播工程化是站在廠內(nèi)EasyBox工具鏈的基礎(chǔ)上, 結(jié)合直播特定的訴求, 演化成直播自己的工程開發(fā)模式, 無論是工程化改造還是接入效率優(yōu)化,回歸本質(zhì), 最終目的就是提升開發(fā)效率, 助力產(chǎn)品快速迭。?