一、 背景
百度直播定位成直播SDK, 賦能百度廠內APP使用, 隨著業務規?？焖贁U大、代碼體量膨脹, 直播原有工程結構限制了直播的快速發展, 隨著垂類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工具鏈的基礎上, 結合直播特定的訴求, 演化成直播自己的工程開發模式, 無論是工程化改造還是接入效率優化,回歸本質, 最終目的就是提升開發效率, 助力產品快速迭。
END
