作者|潘佳(林晚)
出品|阿裡巴巴新零售淘系技術部
“瘋狂的”淘寶直播間
今年直播又火了！
2019年雙11淘寶直播帶來近 200億 成交，以天貓雙11交易總額2684億計算，直播已經占總成交額的近 7.45%！
今年的變化
除了以往的手淘和貓客，現在 UC 浏覽器、新浪微網誌、支付寶、優酷、閑魚、飛豬、餓了麼、口碑等等一系列阿裡系 APP 裡也可以觀看直播、購買商品了，可以想象一下這些場景：
- 點了一杯奶茶外賣，在本地生活 APP 裡通過直播能夠看到小哥哥正在制作誰的訂單，我排在第幾号了，線下門店的衛生情況、制作過程、客流量、商品咨詢都可以在直播間裡了解到
- 在支付寶小程式裡，邊看直播邊搶主播發來的密碼紅包
- 在阿裡健康的消費醫療直播間裡，跟今日特約的醫師進行線上咨詢
- 最近在計劃一趟旅行，在飛豬APP裡通過直播看着小姐姐介紹航旅套餐，還有小窗合流的當地風景觀光片
- ...
除了導購直播、客服直播、醫療直播、手藝直播等等，我們還能看到各種風格類型和互動形式的台網關聯直播、秀場直播、晚會直播，以下是今年承接的幾場大型互動晚會：
這些直播無論内容和互動有什麼樣的差別，他們都有一個共同的特征：直播間右上角「淘寶直播」的水印
問個問題，所有這些類型的直播間，都是淘寶直播的開發同學支援的嗎？這需要一個多麼龐大的技術團隊呢？答案是這個團隊其實很缺人，是以他們「勤奮」地做了一件「偷懶」的事情：ALive 開放，讓阿裡經濟體裡需要直播能力的業務能自主接入、自主開發，于是就有了今年百花齊放的直播生态。
ALive演進
ALive 的使命是彙集淘寶直播強大的音視訊處理能力，提供直播、互動、營銷一體化解決方案，實作「生态開放、直播未來」的願景。
時移到2018年7月，當時的淘寶直播還是小作坊模式，所有的業務對接都由淘寶直播技術團隊承接，各團隊都在超負荷工作。随着對接的外部業務越來越多，各類直播間定制化需求越來越高，技術團隊開始構思開放之路，解放一方生産力，賦能二方、三方直播能力。
▶ 分析
直播對于觀衆來講其實就是兩個訴求：觀看直播、參與互動。來看下當時的淘寶直播是如何滿足使用者這兩個訴求的：
整體結構分為兩部分：一個是直播能力，一個是互動通信能力。通過直播能力，觀衆能觀看直播流；通過互動通信能力，觀衆能在直播間裡參與實時互動。
- 直播能力：最簡單的模型就是“兩端加一服”，即推流端、播放端、流媒體伺服器。主播通過推流用戶端進行直播推流，我們提供了PC端推流工具和淘寶主播APP進行ARTP低延時推流，流媒體服務經過轉碼、切片、存儲、分發等，供播放端拉流播放。
- 互動通信能力：主播在中控台建立、管理直播，開播後推送互動，經過業務服務調用和消息下發，端上渲染業務元件。當時的架構，每一個元件都跑在獨立的Weex容器或H5容器裡。
**▶ 問題
**
直播能力主要由淘寶直播音視訊團隊提供，依托阿裡雲建構了完整的音視訊端到端閉環，包括音視訊編解碼、傳輸通道、網絡排程技術，提供超低延時、超高畫質、超大并發通路的音視訊服務。二、三方業務隻需要接入播放器 SDK ，主播使用我們的推流工具，即可支援直播能力。
互動通信能力主要依賴端側的技術架構，從上圖的架構可以看出兩個核心痛點問題：
性能低下：每個元件都是獨立的 Weex/H5 頁面，記憶體占用較高，直播間流媒體播放已經占用了較高的記憶體水位，多個 Weex/H5 疊加後加大了 Crash 風險。同時各元件間互相獨立，資源重複加載，加載性能也較差
效能低下：前端元件由用戶端挖坑位的方式加載 bundle ，開發、調試環境強依賴用戶端，直播環境搭建、消息模拟、資料 Mock 、日志檢視、代碼調試等鍊路都非常複雜，開發效率極其低下
▶ 解法
前端的技術工作大部分都在解決兩個「能」的問題：性能 和 效能。針對上述痛點，技術側需要做兩件事情：一是建構一個 靈活、高效的直播容器，解決性能問題；二是提供一套 直播間元件開發的工程體系，解決效能問題。在性能和效能都得到提升後，将這些能力通過 ALive 開放平台開放給二、三方業務接入，基于這些思考，我們更新了直播架構：
直播容器的核心差別，是由原來每個元件獨立為一個Weex/H5容器，變成隻保留一個Weex容器，通過這個直播容器來動态加載元件。
▶ 技術實作**
1、直播容器
我們設想的靈活、高效的直播容器，應該具有以下幾個特征：
- 統一規範的元件消息協定：包括元件包名、元件行為、業務自定義字段等，統一由 PowerMessage 的固定消息下發
- 支援動态加載：直播間不同于其他詳情頁，互動的發送依賴主播操作，也依賴使用者進入直播間的時機，每個使用者參與到的互動可能都不一樣，是以互動元件的動态加載對首屏性能很關鍵
- 緩存及依賴去重：同一個互動，主播可以多次推送，各個互動依賴的基礎庫（rax-xxx、universal-xxx）也存在較多重複，是以設計合理的緩存和依賴去重機制對性能提升也很重要
- HOC高階元件：直播間裡的業務開發不同于其他獨立的源碼頁面，比如直播間資料擷取、消息和事件監聽、橫豎屏狀态擷取、帶小窗跳轉、直播觀看時長等等都依賴直播間環境或者用戶端API，業務元件都需要這些基礎能力，需要通過HOC來增強業務元件
基于這些特征設定，我們設計的直播容器技術結構如下：
直播容器的核心工作流程包括以下幾點：
- 消息和指令：容器初始化時從Native擷取緩存裡Mtop請求的元件清單，同時消息子產品監聽Native轉發的固定消息。協定解析成标準化指令，交給渲染子產品執行後續操作
- 渲染管理：渲染子產品接收到建立、更新、銷毀元件指令後，傳遞給元件HOC，如果是建立元件指令，則從加載引擎拉取元件bundle
- 加載引擎：rloader維護了元件緩存，當拉取的元件不在緩存内時，會解析依賴，優先從緩存的基礎依賴裡查找基礎元件，如果沒有則combo拼接，最後拉取最小量的元件bundle，并将拉取的bundle加入緩存
- 元件HOC：高階元件除了上述的能力，還提供了API Bridge、全局變量注入、事件分發以及一些監控容錯等機制
2、 ALive工程體系
筆者加入淘寶直播後接手的第一個項目，是由用戶端同學開發的 H5 版本親密度元件，直播間裡的元件開發強依賴用戶端環境，當時的開發調試手段隻能通過 Charles代理本地靜态資源，沒有日志、沒有斷點、沒有 Mock ，開發環境極其惡劣。
引入直播容器後，改善了性能，但是在直播間裡開發元件，需要一個完整的直播間環境和直播容器才能開發調試，沒有配套的工程體系，元件開發依然很低效。我們設想的ALive工程體系，應該包含以下幾個部分：
- ALive def 套件：直播間元件開發腳手架，增強調試能力，包括直播間模拟、調試代理、熱更新、編譯檢測等功能
- 直播間 Debug 工具：基于直播容器開發一個Debug 元件，提供日志調試、容器化 API 調用、資料 Mock、消息 Mock 等功能
- VS Code 插件：直播間 Debug 工具在 PC 端的同等方案，結合模拟器可以獨立在 PC 端開發調試
基于這些訴求，我們設計的 ALive 工程體系技術結構如下：
效果示範：元件代碼熱更新
效果示範：VS Code插件Mock消息
效果示範：VS Code 插件 Mock 直播間資料
▶ 資料表現
業務資料上通過 ALive 開放帶來的外部流量早已超過百萬 DAU ，每一個對接方都蘊含着一個大的垂直市場。
技術資料上直播容器的穩定性較好，元件的渲染時長由于并發請求限制，還存在一定的優化空間。ALive工程體系建設帶來的提效非常明顯，通過團隊日常排期表資料粗略統計，開發效能提升大約在30%左右。
ALive展望
**▶ 業務側：ALive互動市場
今年貓晚直播間裡所有的互動都由優酷側同學通過ALive接入開發，我們看下貓晚同時線上觀看人數的曲線圖：
這張圖裡有個比較有意思的規律：貓晚同時線上人數的每一次峰值，都對應有互動的推送。這裡有兩點思考，第一是我們提供的直播容器其實是跑在刀尖上的，每一次峰值都是一次檢驗，是以對于直播容器除了前面提到的靈活、高效，還有一個更重要的要素，那就是穩定，這個穩定一方面依賴服務提供方，也就是淘寶直播技術團隊的技術保障，另一方面依賴服務調用方嚴格遵循直播間互動接入SLA。第二個思考，優酷側這次開發了這麼多互動元件，能沉澱複用嗎？
嗯，這個問題亞博科技的同學已經給出了答案。今年阿裡88會員節演唱會裡的互動由亞博科技同學通過ALive接入開發，Bingo幸運球玩法效果非常不錯，晚會結束後亞博科技同學主動提出将Bingo玩法沉澱到日常，于是有了後面的連連看、招财貓。招财貓互動在今年的雙11活動期間，為直播間促活停留資料帶來了非常不錯的增長：
基于這些實踐經驗，ALive後續會規劃互動市場，将各方業務開發的互動玩法按照拉新、促活/停留、轉粉、成交、回訪等次元進行分類管理，其他業務可以通過玩法優勢、使用範圍、已接入業務效果等選擇複用元件，也可以為互動團隊提供更多的資料參考，集中精力生産、疊代更優效果的直播互動玩法。
▶ 技術側：小程式直播開放
在我們講開放的時候，經常提到的幾個關鍵詞是輕量、靈活，但我們發現手淘端外業務在直播接入過程中，需要接入播放器SDK和Weex SDK才能滿足直播能力，接入成本依然較高。前端将視角瞄向了小程式體系，期望不依賴SDK來滿足其他APP端内的直播訴求。目前我們已經實作了支付寶端小程式直播（支付寶搜尋淘寶直播即可體驗），目前還有兩件事情需要突破：
- 提供類似于Rax直播容器的小程式直播容器，提供二、三方元件開發能力
- 和支付寶端對接過程中，我們大部分精力在處理播放的問題，比如iOS/Android端播放控制不一緻、H.265播放黑屏等。如果換一個用戶端，是否要重新再對接一遍？
針對第一個問題，已經有可行方案，差別于Rax體系下的元件動态加載，小程式體系下需要預定義好元件使用範圍，通過Page生成服務産出對應的Page Bundle。針對第二個問題，鑒于我們團隊之前自研了基于WebAssembly的Web端播放器，我們一直在探索将該前端方案的播放器遷入小程式體系，實作前端的播放方案，解決播放器SDK版本限制的束縛，這個突破會極大程度地降低直播接入成本。
另一方面我們團隊在嘗試通過H5接入ARTC低延時方案，實作H5端的低延時推拉流方案，如果該方案也能在小程式體系下跑通，意味着二、三方業務将能通過H5/小程式實作推流、拉流、播放，形成web和小程式側的音視訊閉環。技術上進一步降低接入成本、增強通投能力，更輕量、靈活、穩定的ALive開放體系，将給業務帶來更強勁的推力。
最後
▶ 關聯項目
媒體智能：直播、短視訊從生産側到消費側的媒體智能方案。直播互動目前都是傳統互動，互動和流内容是割裂的。直播間裡的AR/AI玩法有機會給使用者留存和觀看時長帶來較大提升，設想在直播間裡搶的紅包雨可能是由主播通過手勢揮灑出來的、李佳琦喊出“Oh My God”的時候自動跳出字幕特效等等，除了玩法增強，媒體智能還能提供更智能化的服務，比如主播展示商品時智能識别，使用者可在流畫面内點選商品直接購買等等，場景非常豐富。團隊自研的媒體智能編輯器 Media AI Studio已經産出原型版本，整體項目旨在通過媒體智能工具鍊和工程化體系建設，将智能玩法開發周期提效成“7+3+1”模式（7天算法開發、3天玩法編寫、1天素材制作，即可上線一個全新玩法）
- Electron多媒體生産端：基于Electron + OBS + MLT的多媒體PC生産端工具，包括直播推流、回放編輯、視訊剪輯等核心能力
- VideoX播放器：PC/H5/Weex/小程式多場景整合的統一播放方案
團隊在多媒體生産端和消費端的各個項目齊頭并進，又都和ALive互相串聯，最終将形成合力建構出豐滿完整的多媒體前端體系。
We are hiring
淘寶直播多媒體團隊火熱招聘。
履歷投遞至：[email protected]
更多技術内容，關注「淘系技術」微信公衆号