分布式軟總線讓阿里巴巴商家玩轉(zhuǎn)多設(shè)備直播
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
一、引言
距離HarmonyOS 2正式發(fā)布已經(jīng)過去三個多月了，最新數(shù)據(jù)顯示已有超過1.2億臺設(shè)備升級到了HarmonyOS 2操作系統(tǒng)。然而，對于HarmonyOS最核心的技術(shù)亮點—— 分布式軟總線 ，許多應(yīng)用開發(fā)者還不清楚該如何實現(xiàn)，更不清楚該如何與自己的業(yè)務(wù)相結(jié)合。1688也一直在探索這個問題。
1688是國內(nèi)領(lǐng)先的B2B電商平臺，服務(wù)的客戶主要包括工廠老板、淘寶賣家、實體店主、檔口商家等。由于疫情導(dǎo)致線下實體生意的萎縮，越來越多的工廠、檔口老板尋求線上直播帶貨轉(zhuǎn)型。隨著業(yè)務(wù)的發(fā)展，今年1688也孵化了專門面向商家側(cè)的App——1688商家版，提供給商家更加專業(yè)的服務(wù)，包括直播、洽談、 工作臺等。
圖1 1688商家版直播域場景
1688商家版一直不斷探索在直播域供給側(cè)中如何提高商家開播能力、降低商家開播成本，當(dāng)了解到分布式軟總線的特性后，發(fā)現(xiàn)HarmonyOS的這些能力非常切合1688商家多設(shè)備開播訴求，于是他們研發(fā)了這個結(jié)合分布式軟總線的多設(shè)備開播方案。
本文將從技術(shù)角度出發(fā)，分享 1688直播供給側(cè)是如何基于HarmonyOS的分布式軟總線技術(shù)，實現(xiàn)多設(shè)備協(xié)同開播，助力1688商家降低開播成本、提高開播能力。
與通常的手機開播不同，1688直播供給側(cè)的多設(shè)備開播方案涉及到多設(shè)備多屏幕，實現(xiàn)除了錄制主播以外，還可以連接額外的攝像頭專門錄制商品，大屏展示直播的數(shù)據(jù)和預(yù)覽，協(xié)播與主播大屏互動等功能。先通過一段視頻了解下該技術(shù)產(chǎn)品方案的實現(xiàn)效果：
視頻鏈接：https://harmonyos.51cto.com/show/8728
二、業(yè)務(wù)背景
1. 痛點
1688直播的主播大多數(shù)是商家自己，他們對自己的貨品如數(shù)家珍，但卻對電商直播缺乏專業(yè)的開播能力和開播設(shè)備。如何在1688商家投入有限資源的前提下，幫助商家降低開播門檻、提高開播質(zhì)量呢?通過線下走訪商家，1688發(fā)現(xiàn)直播商家在開播設(shè)備方面主要存在以下三大痛點：
(1)直播缺乏特定功能設(shè)備
- 缺乏商品攝像頭，當(dāng)前攝像頭距離商品遠，主播需要頻繁走近開播設(shè)備才能展示商品細節(jié)，影響直播觀感;
- 缺乏互動大屏，手機直播互動屏幕小，主播需要走近開播設(shè)備才能看清觀眾留言與觀眾互動，影響直播體驗;
(2)直播設(shè)備之間難以協(xié)同
- 開播工具協(xié)同難，主播用到的錄制設(shè)備、互動設(shè)備和協(xié)播使用的中控設(shè)備之間不互通操作困難;
- 主播協(xié)播互動難，通常主播講解商品、協(xié)播上品發(fā)券，由于雙方的設(shè)備間缺乏互動只能口播溝通缺乏私密性;
(3)直播設(shè)備能力差異大、便攜性差
- 開播設(shè)備投入低，1688的很多主播本身是中小商家，直播投入追求性價比，開播設(shè)備參差不齊;
- 開播設(shè)備便攜差，在工廠車間等復(fù)雜場景需要駐播和走播協(xié)同開播，設(shè)備難以便攜，缺乏多機位開播能力;
2. 商家需求
現(xiàn)有的設(shè)備是否滿足商家 大屏多攝像頭、設(shè)備間協(xié)同互動、便攜低門檻 的開播訴求呢?先來對比下它們的特性：
圖2 開播設(shè)備選型對比
手機開播，手機分別負責(zé)推流、互動，有一定的協(xié)同便攜能力，但是存在屏幕小和攝像頭不可配等問題。
PC開播，具備可配置的攝像頭和大屏，硬件成本不高，但設(shè)備大便攜性差而且功能集中在一臺設(shè)備缺乏互動性。
直播一體機開播，專門為直播開播定制的設(shè)備有大屏功能強，但是硬件門檻較高而且硬件都是燒錄無法定制。
綜上，1688期望提供給商家直播的開播工具需要具備 多設(shè)備協(xié)同、大屏互動、連接線路少、硬件可配、高性價比 ，那么，有沒有同時滿足這些優(yōu)點的開播方案呢?
三、方案設(shè)計
據(jù)統(tǒng)計當(dāng)前1688商家版App已經(jīng)有超過30%的主播是HarmonyOS用戶，針對已經(jīng)具備HarmonyOS設(shè)備的中小商家，1688提出了基于分布式軟總線的多設(shè)備協(xié)同開播方案。
1. 方案概述
主播使用手機開播時，當(dāng)遇到大屏設(shè)備，可以一鍵將直播能力流轉(zhuǎn)到大屏設(shè)備上，這時候主播的手機呈現(xiàn)遙控器狀態(tài)，大屏顯示屏上分別展示實時數(shù)據(jù)看板、實時互動信息和主播講解的采集畫面。如果場景中有商品攝像頭，主播手機也可以喚起商品攝像頭，商品攝像頭會將采集的音視頻數(shù)據(jù)傳輸給大屏設(shè)備顯示，最終由大屏設(shè)備完成合流推流。協(xié)播可以通過連接大屏設(shè)備，從而獲取實時音視頻流播放，實現(xiàn)與主播觀眾的協(xié)同互動。該方案主要有兩大核心技術(shù)能力，分別是 直播互動在跨設(shè)備上的遷移流轉(zhuǎn)、音視頻流在多設(shè)備上的協(xié)同傳輸。
圖3 基于分布式軟總線的多設(shè)備協(xié)同開播方案
2. 方案特點
該方案同時具備上述開播工具的優(yōu)點：
(1)多設(shè)備間高效協(xié)同
專門錄制主播講解的攝像頭，專門采集商品畫面的攝像頭，大屏設(shè)備展示主播講解畫面合并分發(fā)視頻流，主播手機操控所有開播設(shè)備，協(xié)播手機播放視頻流觀看。
(2)大屏互動
大屏設(shè)備展示直播數(shù)據(jù)和互動信息，主播手機可以操控大屏互動，協(xié)播手機可以與主播、觀眾大屏互動。
(3)便攜線路少
多設(shè)備間在同一局域網(wǎng)內(nèi)完成無線連接。
(4)設(shè)備可配
錄制主播和錄制商品的攝像頭可選配置，大屏互動設(shè)備可選配置。
(5)高性價比設(shè)備
主播、協(xié)播普通HarmonyOS手機，普通顯示器外接HarmonyOS設(shè)備，攝像頭根據(jù)清晰度需求可配。
四、技術(shù)實現(xiàn)
實現(xiàn)上述產(chǎn)品方案的核心技術(shù)能力是 直播互動的遷移流轉(zhuǎn) 和 音視頻流的協(xié)同 傳輸 ，這兩個技術(shù)能力的底層都是基于HarmonyOS的分布式軟總線在我們項目上的拓展封裝。接下來，我先簡單介紹下分布式軟總線。
分布式總線是華為HarmonyOS提出的概念，它的靈感應(yīng)該來自于計算機系統(tǒng)，在計算機系統(tǒng)里把CPU、輸入、輸出設(shè)備等之間傳送信息的公共通路叫總線。而軟總線是通過建立多設(shè)備間的虛擬通信連接，完成多設(shè)備間無物理線路連接的互聯(lián)互通，從而低時延高帶寬的設(shè)備間信息傳輸功能，使得各個設(shè)備之間可以通過無線的方式實現(xiàn)高效的數(shù)據(jù)傳輸。
圖4 HarmonyOS分布式軟總線示意圖
從上面的架構(gòu)圖中，可以看到分布式軟總線封裝了多種通訊協(xié)議，并且將設(shè)備的發(fā)現(xiàn)、連接、傳輸統(tǒng)一封裝成對外透明的接口，開發(fā)者只需要通過簡單的調(diào)用就可以實現(xiàn)多設(shè)備間的互聯(lián)互通，無需關(guān)心聯(lián)通的細節(jié)。
方案中的直播互動正是基于分布式軟總線實現(xiàn)多設(shè)備遷移流轉(zhuǎn)，音視頻流也是通過軟總線通道實現(xiàn)跨設(shè)備的傳輸，下面給大家詳細介紹下這兩個技術(shù)產(chǎn)品能力的實現(xiàn)。
1. 直播互動的遷移流程
(1)產(chǎn)品功能
圖5 直播互動遷移流轉(zhuǎn)功能介紹
直播互動在多設(shè)備上遷移流轉(zhuǎn)主要三個功能：
- 直播實時數(shù)據(jù)遷移大屏;
- 主播、協(xié)播互動遷移大屏;
- 主播中臺控制操作大屏
(2)技術(shù)方案
圖6 直播互動遷移流轉(zhuǎn)技術(shù)方案
- 主播端App改造原有Android項目，增加HarmonyOS Ability依賴，新增開播控制的FA;
- 大屏端App是原有App上新增了大屏的HAP，包括直播數(shù)據(jù)FA 、實時互動FA;
- 協(xié)播端APP是原有Android項目新增與主播和買家互動的FA;
主播App首先發(fā)現(xiàn)并連接附近大屏，然后將直播數(shù)據(jù)FA和實時互動FA，無縫流轉(zhuǎn)遷移到大屏設(shè)備，主播App跳轉(zhuǎn)至開播控制FA，主播App通過中臺控制可以操作大屏和協(xié)播App，設(shè)備間的互動通過IDL通信實現(xiàn)。需要注意的是，上述三個設(shè)備的App都是基于原有項目改造新增的能力，三者為同一個App。
(3)代碼實現(xiàn)
以主播端App喚起大屏端App同時自身跳轉(zhuǎn)中臺控制為例。
圖7 直播互動遷移流轉(zhuǎn)代碼實現(xiàn)
1.在LiveControlAbility的中進行流轉(zhuǎn)設(shè)備注冊：
- ContinuationRegisterManager continuationRegisterManager = getContinuationRegisterManager();
- continuationRegisterManager.register(getBundleName(), null, callback, requestCallback);
2.在ContinuationDeviceCallback連接設(shè)備回調(diào)成功后調(diào)用connectAbility喚起大屏PA ScreenServiceAbility并傳遞相關(guān)參數(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ā)送的指令如喚起其他設(shè)備，再通過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)難點和限制
① 跨設(shè)備通信
HarmonyOS的設(shè)備當(dāng)前通信方式只支持以IDL的方式，并且IDL是單向通信的，為了實現(xiàn)設(shè)備之間雙向通信，我們采取在IDL中的增加回調(diào)的方法，或者采用創(chuàng)建兩個雙向IDL的方式實現(xiàn)設(shè)備間的雙通。
② Android與HarmonyOS兼容開發(fā)
當(dāng)前1688的直播互動功能都是在原有Android項目上進行的HarmonyOS增量開發(fā)。未來，隨著更多基礎(chǔ)庫完成HarmonyOS的遷移適配、HarmonyOS和Android間的更好兼容與通信，1688的直播互動功能將會有更佳的表現(xiàn)。
2. 音視頻流的協(xié)同傳輸
(1) 產(chǎn)品功能
圖8 音視頻流協(xié)同傳輸功能
音視頻流在跨設(shè)備上的協(xié)同傳輸主要四個功能：
主播音視頻采集流轉(zhuǎn)到大屏攝像頭;
喚起商品攝像頭采集商品畫面并流轉(zhuǎn)大屏設(shè)備;
大屏設(shè)備合并商品和主播畫面播放并推流;
音視頻流傳輸?shù)絽f(xié)播手機播放觀看;
(2)技術(shù)方案
圖9 音視頻流協(xié)同傳輸技術(shù)方案
主播App在連接大屏設(shè)備后將關(guān)閉音視頻采集、預(yù)覽功能;
大屏App上新增錄制預(yù)覽能力和合流推流能力，同時需要增加編碼將采集到的音視頻流傳輸?shù)絽f(xié)播App上;
商品攝像頭上增加采集音視頻和傳輸?shù)酱笃猎O(shè)備的能力;
協(xié)播App去掉之前從云端拉取流的方式，改為本地解碼后播放音視頻流;
主播App 在連接大屏設(shè)備后，會喚起大屏設(shè)備的攝像頭錄制音視頻并顯示預(yù)覽，大屏設(shè)備啟動后拉起商品攝像頭，同時對采集的音視頻流編碼，將流傳輸?shù)酱笃猎O(shè)備上合流并推流，協(xié)播手機可以獲取大屏音視頻流播放。
(3)代碼實現(xiàn)
我們以商品攝像頭被喚起后采集音視頻傳輸?shù)酱笃炼藶槔?/p>
圖10 音視頻流協(xié)同傳輸代碼實現(xiàn)
1.當(dāng)商品攝像頭被喚起后，首先初始化SurfaceProvider，并在其surfaceCallback回調(diào)中連接后臺ScreenServiceAbility服務(wù)，同時打開攝像頭：
- protected SurfaceOps.Callback surfaceCallback = new SurfaceOps.Callback() {
- @Override
- public void surfaceCreated(SurfaceOps surfaceOps) {
- previewSurface = surfaceOps.getSurface();
- if (CameraUtil.checkPermission(getApplicationContext())) {
- openCamera();
- }
- }
- }
2.啟動的后臺服務(wù)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.將轉(zhuǎn)化后的YUV視頻幀數(shù)據(jù)先做切片然后通過ScreenService后臺服務(wù)進行發(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.大屏設(shè)備收到商品攝像頭發(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)的本地編碼推流，本方案里面設(shè)備間音視頻流都是在局域網(wǎng)內(nèi)傳輸，由于局域網(wǎng)的帶寬有限，而視頻數(shù)據(jù)較大，1688采用對本地視頻流YUV數(shù)據(jù)進行編解碼，通過切片合流的方式，達到了720P的視頻流傳輸。
② 多設(shè)備的組網(wǎng)
出于安全性考慮，HarmonyOS的設(shè)備組網(wǎng)需要基于以下前提條件，在同一WiFi、開啟藍牙、暫時只支持登錄相同華為賬號。不過在這個場景中，設(shè)備都是服務(wù)于同一個直播賬號，登錄相同的華為賬號再進行開播場景也合理。
五、總結(jié)和展望
1. 總結(jié)
1688的方案具備以下三個特點：
(1) 軟件方案解決硬件限制
利用HarmonyOS分布式軟總線技術(shù)，采用軟件方案打破1688直播場景的硬件限制，將應(yīng)用功能打散到最匹配的硬件設(shè)備上，實現(xiàn)硬件資源的互助互補。
(2) 結(jié)合場景拓展開播能力
結(jié)合1688商家直播的場景特點，基于HarmonyOS的分布式軟總線的特性，解決直播互動、音視頻傳輸?shù)臒o縫流轉(zhuǎn)，實現(xiàn)大屏互動、多設(shè)備開播功能。
(3) 低本高效解決商家痛點
在基本不改變原有1688開播功能的基礎(chǔ)上，軟件層面實現(xiàn)同一個應(yīng)用在多設(shè)備上不同能力表達，硬件層面可根據(jù)商家實力選擇合適設(shè)備，開發(fā)成本低，商家投入少。
分布式軟總線是HarmonyOS操作系統(tǒng)獨有的能力，當(dāng)前只有HarmonyOS的用戶才具備這個能力。
2. 展望
基于1688沉淀的直播互動遷移和音視頻協(xié)同傳輸兩大技術(shù)能力，未來1688會在這兩個方向進一步探索。
(1) 多機位多攝像頭開播，豐富直播內(nèi)容
隨著集團Artc逐步適配HarmonyOS并提供更多流處理能力，1688可以提供專業(yè)高清的攝像頭錄制商品，可移動的攝像頭走播工廠，多角度的攝像頭采集直播畫面，進一步提升1688的直播內(nèi)容質(zhì)量。
(2)標(biāo)準(zhǔn)化的中控盒子，降低開播成本
將音視頻流合流分發(fā)、投屏展示、開播控制的能力集中在一個中控設(shè)備上，主播只需要擁有該設(shè)備就可以實現(xiàn)以上打包的開播能力。
當(dāng)前的方案主要還是軟件應(yīng)用的開發(fā)并不涉及硬件的開發(fā)，所以實際使用的時候需要的攝像頭和大屏設(shè)備能力都是采用HarmonyOS的手機完成的，但如果該方案能涉及硬件開發(fā)，使用燒錄OpenHarmony的攝像頭和投屏盒子，將進一步降低商家的成本、豐富開播的能力。隨著5G和萬物互聯(lián)時代的發(fā)展，未來前景還是十分廣闊。
參考：
1. 分布式語音照相 ：
https://gitee.com/panthole/harmonyos-codelabs/tree/master/VoiceCamera
2. 跨設(shè)備遷移視頻內(nèi)容 ：
https://gitee.com/panthole/harmonyos-codelabs/tree/master/DistributedVideoCodelab
3. HamonyOS視頻解碼能力播放預(yù)覽畫面 ：
https://gitee.com/panthole/harmonyos-codelabs/tree/master/CodecDemo
51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)
