導讀：隨着互聯網的發展，愈來愈多人喜歡直播，百度直播也在快速發展中，爲了提高用戶的使用體驗，本文針對百度直播的複雜流程進行了總體梳理，並詳細說明開展的一系列起播優化工做。html

全文4216字，預計閱讀時間 9分鐘。前端

1、背景

百度作直播有兩個目標：ios

一、把現實世界照搬到線上，在線上和在線下有同樣的體驗，直播種類有媒體、諮詢、電商、秀場等；git

二、是對美好想象的一個完美塑造，隨着5G、VR、AI到來，帶給咱們想象的空間，把線下沒有的東西超越這個時空，放到線上，超越線下的想象空間。github

作直播首先要作的就是QOE（Quality of Experience），咱們做爲技術同窗在保證業務目標的同時，也要提高用戶的體驗。後端

直播的體驗有不少：首屏時間、延遲、畫面質量、音畫同步、清晰度、雜音、回聲等。緩存

從QOE角度出發，做爲衡量的標準QOS（Quality of Service）也有不少：推流成功率、推流卡頓流、轉推慢速比、端到端延遲、CDN流暢率、啓播耗時、拉流卡頓率、視頻碼率、轉推慢速比、內存消耗、CPU&GPU消耗等等。這些技術指標統一構成一個總體，做爲衡量直播服務質量的標準。網絡

可是從直播用戶的角度出發，當用戶點開直播後，用戶但願可以立刻看到畫面，也就是直播啓播速度要快；當在沉浸式直播間上下滑動時，用戶也會但願當前屏幕要看到的直播迅速啓播。啓播耗時做爲用戶的首個直播感知，被放到了首要優化的目標。架構

2、現狀

百度直播分中泛服務直播&泛娛樂直播，其中泛服務直播提供了媒體直播、諮詢直播、電商直播等服務，泛娛樂直播提供了秀場、音播、語音房等娛樂直播。框架

其中泛服務直播更爲複雜一些，關於啓播流程有如下幾個特色：

一、流程繁瑣：分爲外部跳轉直播間&沉浸式直播間內跳轉兩套流程，其中流程流轉環節也較多；

二、直播狀態較多：包含了直播中，回放、回放生成中等狀態

三、涉及面廣：涉及百度App多個團隊：直播、播放器、內核、網絡、CDN等

四、行駛汽車換輪子：百度極度重視直播，業務高速迭代，須要給行駛的汽車換輪子。

總結完了泛服務啓播的特色，那麼就要定量的去分析整個啓播的流程，用數據來衡量整個啓播的環節。

3、數據分析

對整個啓播流程進行數據分析，大體將啓播流程分爲三個大階段：**直播業務耗時、播放器耗時、內核耗時。**下圖是大體的劃分：

在實際數據統計中，會對各個環節進行更精細的統計，簡單說一下直播業務的數據統計和內核的數據統計：

直播業務的每一個環節的進行數據量化，精確到每一個步驟耗時，這樣在數據的基礎上進行分析。

之內核爲例：

而後就能夠獲得一份詳盡關於內核的數據的圖表。

從用戶點擊跳轉到直播間或者沉浸式直播間內滑動切換直播間，到最終的直播播放成功，預計會有60多個的點位進行一些列的追蹤分析。詳細的數據表格呈現啓播過程當中每一步驟的耗時，而後針對於耗時多的地方進行優化。

首先在報表裏面佔比最大的是業務場景的耗時，約佔到60%以上，那麼首先解決的就是這塊耗時；
第二塊耗時佔比較大的階段是拉流的耗時；
當比較大的耗時解決後，就須要針對於小的耗時進行鍼對性的優化。

業務場景的優化

百度App的媒體直播和全民的秀場直播融合以後，會在直播間內進行混合分發。從直播跳轉角度來看，直播間的跳轉分爲兩種：一種是外部經過scheme跳轉到直播間，一種是沉浸式直播間內的滑動跳轉；

下面是外部經過scheme跳轉到直播間的簡單流程：

經過scheme跳轉直播間有兩種狀況：

一、無roomID的的狀況，首先須要請求list接口，而後根據list中的roomId來繼續請求當前直播間的相關信息，根據相關的信息進行組件&插件的的安裝以及渲染操做，當頁面渲染完成後，開始建立播放器，setURL，並初始化內核，開始播放直到播放成功回調；

二、有roomID的狀況，那麼會直接請求當前直播間的相關信息，而後執行與步驟1相同的操做。

下面是沉浸式直播間內的滑動跳轉：

相對於外部跳轉，沉浸式直播間內跳轉多了用戶的滑動操做，從滑停開始統計啓播，直到播放成功回調，整個啓播時長預計在1700ms左右，而在整個流程中，整個直播的業務耗時約爲1000ms左右。
外部跳轉：內部跳轉 = 1: N；N要遠遠大於1，這樣看的話，優先優化直播間內跳轉。

定性定量分析後，制定針對的優化方案：

基於頁面卡頓的考慮，總體方案A&B兩種：

A方案是在iphone8及以上的機型上面實施：在用戶滑動開始時開始建立播放器，而且直接調用播放。

方案B是在iphone8如下的機型上面實施：在用戶滑動時開始建立播放器而且準備好資源，在用戶滑停以後銷燬上個直播間，而且開始下個直播間的播放。

A&B方案的實施，使得卡頓率在這iphone8上下的機型都可以表現的不錯，並不會給用戶卡頓帶來劣化的體驗，針對於機型也是通過ABTest不斷測試啓播與卡頓之間的平衡，尋求的一個暫時的平衡點。後面也會針對於卡頓來作不斷的優化來避免對象頻繁的建立與銷燬，來減小CPU的不斷計算，以使方案A所適應的機型不斷擴增。

有了直播間內部跳轉的優化方案以後，那麼外部scheme的跳轉也就顯而易見了：

百度App的組件間通訊方案使用的scheme來通訊，那麼在scheme裏面添加直播的URL，在跳轉進直播頁面時直接經過scheme攜帶的URL來建立播放器，並開始播放直播，與業務邏輯並行執行。

4、DNS預解析

DNS（Domain Name System），它的做用是根據域名查出IP地址，它是HTTP協議的前提，只有將域名正確的解析成IP地址後，後面的流程才能進行。在內核處理直播流的時候，直播DNS耗時八十分位大約在60ms，這塊的耗時也是比較多的。

在百度AppAPP中，防止DNS的劫持，同時也是爲了下降網絡時延，咱們採用了HTTPDNS的方案：

爲了優化直播DNS解析耗時，採用DNS預解析策略，提早緩存對應的IP，能夠減小DNS解析的耗時時間。

在應用冷啓10s、網絡切換、先後臺切換等時機，根據模型判斷是否採起直播DNS預解析方案，模型的判斷標準爲：用戶N天內瀏覽直播時長M、當前網絡狀態、後端控制等等。當模型斷定經過時，會調用HTTPDNS異步發起直播域名的解析得到一個IP列表，對IP分別進行測速，測速後並非直接選用結果最優的那一個，而是在測試結果能夠接受的必定範圍內進行隨機挑選並緩存預解析的結果。避免了大量用戶都彙集到少數節點，致使的節點負載不均衡。

HTTPDNS緩存IP的有效時間是從服務端獲取的，默認300s。當直播流域名解析開始時，查詢緩存，若存在有效IP(緩存時間<300s)直接返回對應IP，並調用HTTPDNS異步發起請求更新。若不存在也會異步發起請求更新，此時會降級到LocalDNS解析。

當網絡變化時(Wifi <-> 4G)，清除當前的緩存IP，並從新發起域名列表內全部域名的預解析。

最終收益：使用HTTPDNS預解析後，直播DNS耗時小於3ms的PV佔總直播PV的90%以上。

5、內核的一些優化

針對於報表裏面耗時較多的階段，進行了一系列針對的優化：

一、首屏強制渲染：主要就是視頻的首幀解碼出來就會強制走渲染流程，不會去作音畫同步；

二、弱網狀況下，啓動低碼率啓播策略；

三、高端機型下加載下個播放器內核，並prepare，當切換直播時進行追幀操做。大概邏輯就是緩衝區延時超過3秒就每隔2秒就丟200ms音頻，直到低於3秒內不丟，若是超過16秒，就會所有丟掉直接重連。

6、直播起播優化

直播起播優化-媒體信息解析模塊的優化

視頻寬高、圖像編碼格式等信息是Android平臺硬件解碼器Mediacodec，IOS平臺硬件解碼器Video ToolBox必備信息，播放內核在配置平臺硬件解碼器以前，須要準備好視頻寬高、圖像編碼格式等信息。

一些封裝格式(例如MP4)會在頭部描述視頻寬高、圖像編碼格式等信息，針對視頻容器不包含上述信息的狀況(例如FLV)，FFMPEG原生流程就循環的下載視頻流，而後經過軟件解碼器解碼視頻，獲取上述信息；

在H.264/AVC視頻編碼標準中，整個系統框架被分爲了兩個層面：視頻編碼層面（VCL）和網絡抽象層面（NAL）。其中，前者負責有效表示視頻數據的內容，然後者則負責格式化數據並提供頭信息，以保證數據適合各類信道和存儲介質上的傳輸。NAL中的SPS，PPS中已經寬高信息，圖像編碼格式的描述，能夠經過解析SPS，PPS獲取必要信息，省去軟解視頻的流程。

7、直播回放(HLS)m3u8預取

直播視頻一般會被編碼成HLS格式保存，咱們稱此爲直播回放，HLS封裝格式的視頻起播80分位爲1250ms，起播速度是反應播放體驗的核心指標，直播回放起播性能顯著差於直播(HTTP-FLV)的510ms。

HLS封裝起播慢的主要緣由是由於須要先下載視頻索引文件(M3U8)，經過解析該索引文件才獲得真正的視頻文件，也就是說相比直播（HTTP-FLV）至少多了一次HTTP的請求。爲了解決這個問題，經過提早預取HLS視頻索引文件（M3U8）到本地sdcard；起播時省去了M3U8下載部分耗時，AB實驗收益：對比命中和未命中預取M3U8實驗組，命中預取收益爲346ms。

參考文獻：

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md

https://tools.ietf.org/html/rfc7858

https://github.com/bilibili/ijkplayer

招聘信息：

百度-直播研發部-泛知識直播組，團隊旨在建設業界一流的直播體驗，技術驅動業務，並在直播場景中不斷的創新，結合 VR&AR&AI 等技術，不斷探索新的玩法。播放內核, 團隊經過不斷提高內核的基礎性能，加強內核能力，完善指標監控，提升服務能力，最終實現更好的用戶體驗和產品質量。

誠邀iOS & Android小夥伴，關注同名公衆號百度Geek說，點擊菜單欄「內推」便可加入搜索架構部，咱們期待你的加入！

如何像百度直播同樣優化用戶體驗（起播篇）