建站
咨詢
售后
建站咨詢
新聞中心
分布式軟總線讓阿里巴巴商家玩轉多設備直播
作者：潘凌越 2021-10-26 07:59:22
系統(tǒng)
分布式 本文將從技術角度出發(fā)，分享 1688直播供給側是如何基于HarmonyOS的分布式軟總線技術，實現(xiàn)多設備協(xié)同開播，助力1688商家降低開播成本、提高開播能力。
創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比清河網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式清河網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋清河地區(qū)。費用合理售后完善，10多年實體公司更值得信賴。
一、引言
距離HarmonyOS 2正式發(fā)布已經(jīng)過去三個多月了，最新數(shù)據(jù)顯示已有超過1.2億臺設備升級到了HarmonyOS 2操作系統(tǒng)。然而，對于HarmonyOS最核心的技術亮點—— 分布式軟總線 ，許多應用開發(fā)者還不清楚該如何實現(xiàn)，更不清楚該如何與自己的業(yè)務相結合。1688也一直在探索這個問題。
1688是國內(nèi)領先的B2B電商平臺，服務的客戶主要包括工廠老板、淘寶賣家、實體店主、檔口商家等。由于疫情導致線下實體生意的萎縮，越來越多的工廠、檔口老板尋求線上直播帶貨轉型。隨著業(yè)務的發(fā)展，今年1688也孵化了專門面向商家側的App——1688商家版，提供給商家更加專業(yè)的服務，包括直播、洽談、 工作臺等。
圖1 1688商家版直播域場景
1688商家版一直不斷探索在直播域供給側中如何提高商家開播能力、降低商家開播成本，當了解到分布式軟總線的特性后，發(fā)現(xiàn)HarmonyOS的這些能力非常切合1688商家多設備開播訴求，于是他們研發(fā)了這個結合分布式軟總線的多設備開播方案。
本文將從技術角度出發(fā)，分享 1688直播供給側是如何基于HarmonyOS的分布式軟總線技術，實現(xiàn)多設備協(xié)同開播，助力1688商家降低開播成本、提高開播能力。
與通常的手機開播不同，1688直播供給側的多設備開播方案涉及到多設備多屏幕，實現(xiàn)除了錄制主播以外，還可以連接額外的攝像頭專門錄制商品，大屏展示直播的數(shù)據(jù)和預覽，協(xié)播與主播大屏互動等功能。先通過一段視頻了解下該技術產(chǎn)品方案的實現(xiàn)效果：
二、業(yè)務背景
1. 痛點
1688直播的主播大多數(shù)是商家自己，他們對自己的貨品如數(shù)家珍，但卻對電商直播缺乏專業(yè)的開播能力和開播設備。如何在1688商家投入有限資源的前提下，幫助商家降低開播門檻、提高開播質(zhì)量呢?通過線下走訪商家，1688發(fā)現(xiàn)直播商家在開播設備方面主要存在以下三大痛點：
(1)直播缺乏特定功能設備
- 缺乏商品攝像頭，當前攝像頭距離商品遠，主播需要頻繁走近開播設備才能展示商品細節(jié)，影響直播觀感;
- 缺乏互動大屏，手機直播互動屏幕小，主播需要走近開播設備才能看清觀眾留言與觀眾互動，影響直播體驗;
(2)直播設備之間難以協(xié)同
- 開播工具協(xié)同難，主播用到的錄制設備、互動設備和協(xié)播使用的中控設備之間不互通操作困難;
- 主播協(xié)播互動難，通常主播講解商品、協(xié)播上品發(fā)券，由于雙方的設備間缺乏互動只能口播溝通缺乏私密性;
(3)直播設備能力差異大、便攜性差
- 開播設備投入低，1688的很多主播本身是中小商家，直播投入追求性價比，開播設備參差不齊;
- 開播設備便攜差，在工廠車間等復雜場景需要駐播和走播協(xié)同開播，設備難以便攜，缺乏多機位開播能力;
2. 商家需求
現(xiàn)有的設備是否滿足商家 大屏多攝像頭、設備間協(xié)同互動、便攜低門檻 的開播訴求呢?先來對比下它們的特性：
圖2 開播設備選型對比
手機開播，手機分別負責推流、互動，有一定的協(xié)同便攜能力，但是存在屏幕小和攝像頭不可配等問題。
PC開播，具備可配置的攝像頭和大屏，硬件成本不高，但設備大便攜性差而且功能集中在一臺設備缺乏互動性。
直播一體機開播，專門為直播開播定制的設備有大屏功能強，但是硬件門檻較高而且硬件都是燒錄無法定制。
綜上，1688期望提供給商家直播的開播工具需要具備 多設備協(xié)同、大屏互動、連接線路少、硬件可配、高性價比 ，那么，有沒有同時滿足這些優(yōu)點的開播方案呢?
三、方案設計
據(jù)統(tǒng)計當前1688商家版App已經(jīng)有超過30%的主播是HarmonyOS用戶，針對已經(jīng)具備HarmonyOS設備的中小商家，1688提出了基于分布式軟總線的多設備協(xié)同開播方案。
1. 方案概述
主播使用手機開播時，當遇到大屏設備，可以一鍵將直播能力流轉到大屏設備上，這時候主播的手機呈現(xiàn)遙控器狀態(tài)，大屏顯示屏上分別展示實時數(shù)據(jù)看板、實時互動信息和主播講解的采集畫面。如果場景中有商品攝像頭，主播手機也可以喚起商品攝像頭，商品攝像頭會將采集的音視頻數(shù)據(jù)傳輸給大屏設備顯示，最終由大屏設備完成合流推流。協(xié)播可以通過連接大屏設備，從而獲取實時音視頻流播放，實現(xiàn)與主播觀眾的協(xié)同互動。該方案主要有兩大核心技術能力，分別是 直播互動在跨設備上的遷移流轉、音視頻流在多設備上的協(xié)同傳輸。
圖3 基于分布式軟總線的多設備協(xié)同開播方案
2. 方案特點
該方案同時具備上述開播工具的優(yōu)點：
(1)多設備間高效協(xié)同
專門錄制主播講解的攝像頭，專門采集商品畫面的攝像頭，大屏設備展示主播講解畫面合并分發(fā)視頻流，主播手機操控所有開播設備，協(xié)播手機播放視頻流觀看。
(2)大屏互動
大屏設備展示直播數(shù)據(jù)和互動信息，主播手機可以操控大屏互動，協(xié)播手機可以與主播、觀眾大屏互動。
(3)便攜線路少
多設備間在同一局域網(wǎng)內(nèi)完成無線連接。
(4)設備可配
錄制主播和錄制商品的攝像頭可選配置，大屏互動設備可選配置。
(5)高性價比設備
主播、協(xié)播普通HarmonyOS手機，普通顯示器外接HarmonyOS設備，攝像頭根據(jù)清晰度需求可配。
四、技術實現(xiàn)
實現(xiàn)上述產(chǎn)品方案的核心技術能力是 直播互動的遷移流轉 和 音視頻流的協(xié)同 傳輸 ，這兩個技術能力的底層都是基于HarmonyOS的分布式軟總線在我們項目上的拓展封裝。接下來，我先簡單介紹下分布式軟總線。
分布式總線是華為HarmonyOS提出的概念，它的靈感應該來自于計算機系統(tǒng)，在計算機系統(tǒng)里把CPU、輸入、輸出設備等之間傳送信息的公共通路叫總線。而軟總線是通過建立多設備間的虛擬通信連接，完成多設備間無物理線路連接的互聯(lián)互通，從而低時延高帶寬的設備間信息傳輸功能，使得各個設備之間可以通過無線的方式實現(xiàn)高效的數(shù)據(jù)傳輸。
圖4 HarmonyOS分布式軟總線示意圖
從上面的架構圖中，可以看到分布式軟總線封裝了多種通訊協(xié)議，并且將設備的發(fā)現(xiàn)、連接、傳輸統(tǒng)一封裝成對外透明的接口，開發(fā)者只需要通過簡單的調(diào)用就可以實現(xiàn)多設備間的互聯(lián)互通，無需關心聯(lián)通的細節(jié)。
方案中的直播互動正是基于分布式軟總線實現(xiàn)多設備遷移流轉，音視頻流也是通過軟總線通道實現(xiàn)跨設備的傳輸，下面給大家詳細介紹下這兩個技術產(chǎn)品能力的實現(xiàn)。
1. 直播互動的遷移流程
(1)產(chǎn)品功能
圖5 直播互動遷移流轉功能介紹
直播互動在多設備上遷移流轉主要三個功能：
- 直播實時數(shù)據(jù)遷移大屏;
- 主播、協(xié)播互動遷移大屏;
- 主播中臺控制操作大屏
(2)技術方案
圖6 直播互動遷移流轉技術方案
- 主播端App改造原有Android項目，增加HarmonyOS Ability依賴，新增開播控制的FA;
- 大屏端App是原有App上新增了大屏的HAP，包括直播數(shù)據(jù)FA 、實時互動FA;
- 協(xié)播端APP是原有Android項目新增與主播和買家互動的FA;
主播App首先發(fā)現(xiàn)并連接附近大屏，然后將直播數(shù)據(jù)FA和實時互動FA，無縫流轉遷移到大屏設備，主播App跳轉至開播控制FA，主播App通過中臺控制可以操作大屏和協(xié)播App，設備間的互動通過IDL通信實現(xiàn)。需要注意的是，上述三個設備的App都是基于原有項目改造新增的能力，三者為同一個App。
(3)代碼實現(xiàn)
以主播端App喚起大屏端App同時自身跳轉中臺控制為例。
圖7 直播互動遷移流轉代碼實現(xiàn)
1.在LiveControlAbility的中進行流轉設備注冊：
- ContinuationRegisterManager continuationRegisterManager = getContinuationRegisterManager();
- continuationRegisterManager.register(getBundleName(), null, callback, requestCallback);
2.在ContinuationDeviceCallback連接設備回調(diào)成功后調(diào)用connectAbility喚起大屏PA ScreenServiceAbility并傳遞相關參數(shù)：
- private IContinuationDeviceCallback callback = new IContinuationDeviceCallback() {
- @Override
- public void onDeviceConnectDone(String deviceId, String deviceType) {
- selectDeviceId = deviceId;
- if (selectDeviceId != null) {
- connectAa(selectDeviceId);
- continuationRegisterManager.updateConnectStatus(abilityToken,selectDeviceId, DeviceConnectState.CONNECTED.getState(), null);
- }
- }
- }
3.在大屏ScreenServiceAbility的onConnect接收數(shù)據(jù)并拉起大屏FA ScreenPageAbility：
- public IRemoteObject onConnect(Intent intent) {
- clientRole = intent.getStringParam("client_role");
- if ("controller".equals(clientRole)) {
- jumpScreen();
- return new ScreenRemoteForController();
- }
- }
4.ScreenRemoteForController繼承自HarmonyControllerInterfaceSkeletonScreen在OnConnect回調(diào)以后初始化，并且接收從主播App發(fā)送的指令如喚起其他設備，再通過EventHandler進行事件分發(fā)：
- class ScreenRemoteForController extends HarmonyControllerInterfaceSkeleton {
- ScreenRemoteForController() {
- super("IScreenRemoteInterface");
- }
- @Override
- public void sendCommand(String command) throws RemoteException {
- switch (command) {
- case "close":
- MyApplication.getHandler().sendEvent(1);
- default:
- break;
- }
- }
(4)難點和限制
① 跨設備通信
HarmonyOS的設備當前通信方式只支持以IDL的方式，并且IDL是單向通信的，為了實現(xiàn)設備之間雙向通信，我們采取在IDL中的增加回調(diào)的方法，或者采用創(chuàng)建兩個雙向IDL的方式實現(xiàn)設備間的雙通。
② Android與HarmonyOS兼容開發(fā)
當前1688的直播互動功能都是在原有Android項目上進行的HarmonyOS增量開發(fā)。未來，隨著更多基礎庫完成HarmonyOS的遷移適配、HarmonyOS和Android間的更好兼容與通信，1688的直播互動功能將會有更佳的表現(xiàn)。
2. 音視頻流的協(xié)同傳輸
(1) 產(chǎn)品功能
圖8 音視頻流協(xié)同傳輸功能
音視頻流在跨設備上的協(xié)同傳輸主要四個功能：
主播音視頻采集流轉到大屏攝像頭;
喚起商品攝像頭采集商品畫面并流轉大屏設備;
大屏設備合并商品和主播畫面播放并推流;
音視頻流傳輸?shù)絽f(xié)播手機播放觀看;
(2)技術方案
圖9 音視頻流協(xié)同傳輸技術方案
主播App在連接大屏設備后將關閉音視頻采集、預覽功能;
大屏App上新增錄制預覽能力和合流推流能力，同時需要增加編碼將采集到的音視頻流傳輸?shù)絽f(xié)播App上;
商品攝像頭上增加采集音視頻和傳輸?shù)酱笃猎O備的能力;
協(xié)播App去掉之前從云端拉取流的方式，改為本地解碼后播放音視頻流;
主播App 在連接大屏設備后，會喚起大屏設備的攝像頭錄制音視頻并顯示預覽，大屏設備啟動后拉起商品攝像頭，同時對采集的音視頻流編碼，將流傳輸?shù)酱笃猎O備上合流并推流，協(xié)播手機可以獲取大屏音視頻流播放。
(3)代碼實現(xiàn)
我們以商品攝像頭被喚起后采集音視頻傳輸?shù)酱笃炼藶槔?/p>
圖10 音視頻流協(xié)同傳輸代碼實現(xiàn)
1.當商品攝像頭被喚起后，首先初始化SurfaceProvider，并在其surfaceCallback回調(diào)中連接后臺ScreenServiceAbility服務，同時打開攝像頭：
- protected SurfaceOps.Callback surfaceCallback = new SurfaceOps.Callback() {
- @Override
- public void surfaceCreated(SurfaceOps surfaceOps) {
- previewSurface = surfaceOps.getSurface();
- if (CameraUtil.checkPermission(getApplicationContext())) {
- openCamera();
- }
- }
- }
2.啟動的后臺服務ScreenServiceAbility在onConnect時將音視頻數(shù)據(jù)進行傳輸：
- public IRemoteObject onConnect(Intent intent) {
- return new ScreenRemoteFoSlave() {
- @Override
- public void onPcmReady(byte[] pcmData) throws RemoteException {
- mControllerCallback.onPcmReady(pcmData);
- }
- @Override
- public void onYuvData(int type, int length, int seq, byte[] cameraData) throws RemoteException {
- mControllerCallback.onReturnData(type, length, seq, cameraData);
- }
- };
- return null;
- }
3.以商品攝像頭采集的視頻數(shù)據(jù)為例，將YUV數(shù)據(jù)格式編碼后發(fā)送：
- public void YuvCode() {
- fmt.setObjectFormat(Format.MIME, Format.VIDEO_AVC);
- mCodec.registerCodecListener(new Codec.ICodecListener() {
- @Override
- public void onReadBuffer(ByteBuffer byteBuffer, BufferInfo bufferInfo, int trackId) {
- byte[] msg = new byte[bufferInfo.size];
- byteBuffer.clear();
- byteBuffer.get(msg);
- sendEncodedDataToRemote(msg, bufferInfo);
- }
- );
- mCodec.setCodecFormat(fmt);
- mCodec.start();
- }
4.將轉化后的YUV視頻幀數(shù)據(jù)先做切片然后通過ScreenService后臺服務進行發(fā)送：
- private void sendEncodedDataToRemote(byte[] data, BufferInfo bufferInfo) {
- byte[] msgTemp = new byte[bufferInfo.size - position];
- System.arraycopy(data, position, msgTemp, 0, msgTemp.length);
- mScreenServiceProxy.onYuvData(CameraUtil.IRemoteMsg.MSG_TYPE_SLICE_END, bufferInfo.size, 0, data);
- }
5.大屏設備收到商品攝像頭發(fā)送的音視頻數(shù)據(jù)進行解碼后播放：
- private ControllerCallbackStub mControllerCallback = new ControllerCallbackStub("com.alibaba.cameraohos.IControlFaCallback") {
- @Override
- public void onPcmReady(byte[] pcmData) throws RemoteException {
- mPlayRecord.playTransData(pcmData);
- }
- @Override
- public void onReturnData(int type, int length, int seq, byte[] cameraData) throws RemoteException {
- createMyDecoder();
- initMuxer();
- }
- }
(4)難點和限制
① 音視頻流本地編解碼傳輸
有別于傳統(tǒng)的本地編碼推流，本方案里面設備間音視頻流都是在局域網(wǎng)內(nèi)傳輸，由于局域網(wǎng)的帶寬有限，而視頻數(shù)據(jù)較大，1688采用對本地視頻流YUV數(shù)據(jù)進行編解碼，通過切片合流的方式，達到了720P的視頻流傳輸。
② 多設備的組網(wǎng)
出于安全性考慮，HarmonyOS的設備組網(wǎng)需要基于以下前提條件，在同一WiFi、開啟藍牙、暫時只支持登錄相同華為賬號。不過在這個場景中，設備都是服務于同一個直播賬號，登錄相同的華為賬號再進行開播場景也合理。
五、總結和展望
1. 總結
1688的方案具備以下三個特點：
(1) 軟件方案解決硬件限制
利用HarmonyOS分布式軟總線技術，采用軟件方案打破1688直播場景的硬件限制，將應用功能打散到最匹配的硬件設備上，實現(xiàn)硬件資源的互助互補。
(2) 結合場景拓展開播能力
結合1688商家直播的場景特點，基于HarmonyOS的分布式軟總線的特性，解決直播互動、音視頻傳輸?shù)臒o縫流轉，實現(xiàn)大屏互動、多設備開播功能。
(3) 低本高效解決商家痛點
在基本不改變原有1688開播功能的基礎上，軟件層面實現(xiàn)同一個應用在多設備上不同能力表達，硬件層面可根據(jù)商家實力選擇合適設備，開發(fā)成本低，商家投入少。
分布式軟總線是HarmonyOS操作系統(tǒng)獨有的能力，當前只有HarmonyOS的用戶才具備這個能力。
2. 展望
基于1688沉淀的直播互動遷移和音視頻協(xié)同傳輸兩大技術能力，未來1688會在這兩個方向進一步探索。
(1) 多機位多攝像頭開播，豐富直播內(nèi)容
隨著集團Artc逐步適配HarmonyOS并提供更多流處理能力，1688可以提供專業(yè)高清的攝像頭錄制商品，可移動的攝像頭走播工廠，多角度的攝像頭采集直播畫面，進一步提升1688的直播內(nèi)容質(zhì)量。
(2)標準化的中控盒子，降低開播成本
將音視頻流合流分發(fā)、投屏展示、開播控制的能力集中在一個中控設備上，主播只需要擁有該設備就可以實現(xiàn)以上打包的開播能力。
當前的方案主要還是軟件應用的開發(fā)并不涉及硬件的開發(fā)，所以實際使用的時候需要的攝像頭和大屏設備能力都是采用HarmonyOS的手機完成的，但如果該方案能涉及硬件開發(fā)，使用燒錄OpenHarmony的攝像頭和投屏盒子，將進一步降低商家的成本、豐富開播的能力。隨著5G和萬物互聯(lián)時代的發(fā)展，未來前景還是十分廣闊。
參考：
1. 分布式語音照相 ：
https://gitee.com/panthole/harmonyos-codelabs/tree/master/VoiceCamera
2. 跨設備遷移視頻內(nèi)容 ：
https://gitee.com/panthole/harmonyos-codelabs/tree/master/DistributedVideoCodelab
3. HamonyOS視頻解碼能力播放預覽畫面
分享文章：分布式軟總線讓阿里巴巴商家玩轉多設備直播
本文地址：http://www.5511xx.com/article/coeocdo.html
