前面介紹了直播后端系統(tǒng)的原理及優(yōu)化，那么直播推流、播放端是否就沒有可以優(yōu)化的點呢?答案是否定的。客戶端的優(yōu)化對直播秒開、延遲體驗的實現(xiàn)至關重要，這里重點介紹移動終端的情況。

解析優(yōu)化

參見之前介紹的DNS過程，如下圖：

基于可控和容災的需要，移動端代碼一般不會hardcode 推流、播放的服務器IP地址，而選用域名代替。在IP出現(xiàn)宕機或網(wǎng)絡中斷的情況下，還可以通過變更DNS來實現(xiàn)問題IP的剔除。而域名的解析時間需要幾十毫秒至幾秒不等，對于新生成熱度不高的域名，一般的平均解析延遲在300ms，按上圖的各個環(huán)節(jié)只要有一個通路網(wǎng)絡產(chǎn)生波動或者是設備高負載，會增加至秒級。幾十毫秒的情況是ISP NS這一層在熱度足夠高的情況下會對域名的解析進行緩存。如下圖：

按我們上面分析的情況，本省延遲大概是15ms左右，那么域名解析最低也可以做到15ms左右。但由于直播場景的特殊性，推流和播放使用的域名使用的熱度較難達到ISP NS緩存的標準，所以經(jīng)常需要走回Root NS進行查詢的路徑。

那客戶端解析優(yōu)化的原理就出來了：本機緩存域名的解析結(jié)果，對域名進行預解析，每次需要直播推流和播放的時候不再需要再進行DNS過程。此處節(jié)省幾十到幾百毫秒的打開延遲。

播放優(yōu)化

直播播放器的相關技術點有：直播延時、首屏時間(指從開始播放到第一次看到畫面的時間)、音視頻同步、軟解碼、硬解碼。參考如下播放流程：

播放步驟描述：

1、根據(jù)協(xié)議類型(如RTMP、RTP、RTSP、HTTP等)，與服務器建立連接并接收數(shù)據(jù);

2、解析二進制數(shù)據(jù)，從中找到相關流信息;

3、根據(jù)不同的封裝格式(如FLV、TS)解復用(demux);

4、分別得到已編碼的H.264視頻數(shù)據(jù)和AAC音頻數(shù)據(jù);

5、使用硬解碼(對應系統(tǒng)的API)或軟解碼(FFMpeg)來解壓音視頻數(shù)據(jù);

6、經(jīng)過解碼后得到原始的視頻數(shù)據(jù)(YUV)和音頻數(shù)據(jù)(AAC);

7、因為音頻和視頻解碼是分開的，所以我們得把它們同步起來，否則會出現(xiàn)音視頻不同步的現(xiàn)象，比如別人說話會跟口型對不上;

8、最后把同步的音頻數(shù)據(jù)送到耳機或外放，視頻數(shù)據(jù)送到屏幕上顯示;

了解了播放器的播放流程后，我們可以優(yōu)化以下幾點：

首屏時間優(yōu)化

1、從步驟2入手，通過預設解碼器類型，省去探測文件類型時間;

2、從步驟5入手，縮小視頻數(shù)據(jù)探測范圍，同時也意味著減少了需要下載的數(shù)據(jù)量，特別是在網(wǎng)絡不好的時候，減少下載的數(shù)據(jù)量能為啟動播放節(jié)省大量的時間，當檢測到I幀數(shù)據(jù)后就立馬返回并進入解碼環(huán)節(jié)。

延時優(yōu)化

1、視頻緩沖區(qū)或叫視頻緩存策略，該策略原理是當網(wǎng)絡卡頓時增加用戶等待時間來緩存一定量的視頻數(shù)據(jù)，達到后續(xù)平滑觀看的效果，該技術能有效減少卡頓次數(shù)，但是會帶來直播上的內(nèi)容延時，所以該技術主要運用于點播，直播方面已去掉該策略，以此盡可能去掉或縮小內(nèi)容從網(wǎng)絡到屏幕展示過程中的時間;(有利于減少延時)

2、下載數(shù)據(jù)探測池技術，當用戶下載速度不足發(fā)生了卡頓，然后網(wǎng)絡突然又順暢了，服務器上之前滯留的數(shù)據(jù)會加速發(fā)下來，這時為了減少之前卡頓造成的延時，播放器會加速播放探測池的視頻數(shù)據(jù)并丟棄當前加速部分的音頻數(shù)據(jù)，以此來保證當前觀看內(nèi)容延時穩(wěn)定。

推流優(yōu)化

推流步驟說明：很容易看出推流跟播放其實是逆向的，具體流程就不多說了。

優(yōu)化一：適當?shù)腝os(Quality of Service，服務質(zhì)量)策略。推流端會根據(jù)當前上行網(wǎng)絡情況控制音視頻數(shù)據(jù)發(fā)包和編碼，在網(wǎng)絡較差的情況下，音視頻數(shù)據(jù)發(fā)送不出去，造成數(shù)據(jù)滯留在本地，這時，會停掉編碼器防止發(fā)送數(shù)據(jù)進一步滯留，同時會根據(jù)網(wǎng)絡情況選擇合適的策略控制音視頻發(fā)送。比如網(wǎng)絡很差的情況下，推流端會優(yōu)先發(fā)送音頻數(shù)據(jù)，保證用戶能聽到聲音，并在一定間隔內(nèi)發(fā)關鍵幀數(shù)據(jù)，保證用戶在一定時間間隔之后能看到一些畫面的變化。

優(yōu)化二：合理的關鍵幀配置。合理控制關鍵幀發(fā)送間隔(建議2秒或1秒一個)，這樣可以減少后端處理過程，為后端的緩沖區(qū)設置更小創(chuàng)造條件。

軟硬編解選擇

網(wǎng)上有不少關于選擇軟解還是硬解的分析文章，這里也介紹一些經(jīng)驗，但根本問題是，沒有一個通用方案能最優(yōu)適配所有操作系統(tǒng)和機型。

推流編碼： 推薦Andorid4.3(API18)或以上使用硬編，以下版本使用軟編;iOS使用全硬編方案;

播放解碼：Andorid、iOS播放器都使用軟解碼方案，經(jīng)過我們和大量客戶的測試以及總結(jié)，雖然犧牲了功耗，但是在部分細節(jié)方面表現(xiàn)會較優(yōu)，且可控性強，兼容性也強，出錯情況少，推薦使用。

附軟硬編解碼優(yōu)缺點對比：

云端機型及網(wǎng)絡適配

上面分析了很多針對視頻編解碼的參數(shù)，但實際情況最好的編解碼效果是需要根據(jù)機型的適配的，由于iOS的設備類型較少，可以做到每個機型針對性的測試和調(diào)優(yōu)，但是對于Android就非常難做到逐款機型針對性調(diào)優(yōu)，并且每年都會出產(chǎn)不少的新機器，如果代碼中寫死了配置或判斷邏輯將非常不利于維護和迭代。所以我們就誕生了一個想法，這些判斷邏輯或配置是否可以放在云上呢? 這樣就產(chǎn)生了云端機型與網(wǎng)絡適配的技術。

終端在推流、播放前會獲取通過協(xié)議上報當前的機型配置、網(wǎng)絡情況、IP信息。云端會返回一個已最適合的編解碼策略配置：走軟編還是硬編、各項參數(shù)的配置，就近推流服務的IP，就近播放服務的IP。 終端獲取一次即可，不需要每次推流、播放前都去獲取一次。

這樣，在我們不斷的迭代和完善機型編解碼適配庫的同時，所有使用該技術的直播APP都將收益。

總結(jié)

分析很多直播后端、終端的關于低延遲、秒開的優(yōu)化技術，在UCloud直播云上都已有了相關的實踐，都是一些較“靜態(tài)”的技術。實際提供穩(wěn)定、低延遲、流暢的直播服務，是日常中非常大量細致的監(jiān)控、算法和動態(tài)運營的結(jié)果，并不是實現(xiàn)了某些的技術點，就能坐享一套穩(wěn)定的直播服務，只能說是完成了萬里長城的第一道磚。

點擊閱讀：關于直播，所有的技術細節(jié)都在這里了(一)http://m.jxzklqfsx.com/art/201605/511219.htm

點擊閱讀：關于直播，所有的技術細節(jié)都在這里了(二)http://m.jxzklqfsx.com/art/201605/511224.htm

點擊閱讀：關于直播，所有的技術細節(jié)都在這里了(三)http://m.jxzklqfsx.com/art/201605/511465.htm