本文來自于騰訊bugly開發者社區，非經作者同意，請勿轉載，原文地址：http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=1204&extra=page%3D1

2016年應當是直播元年，直播利用百團大戰，QQ 空間也在6.5版本上線了直播功能，從無到有、快速搭建了直播間。“先扛住再優化”，第1個版本和競品相比，我們進入直播間的速度比較慢。根據外網統計在6.5版本的用戶端看到畫面需要4.4s，因此在6.5發布以后，著手啟動了優化工作，目標：觀看直播需要到達秒進體驗（1s內看到畫面）。

先上1張直播間的截圖：

1、優化效果

1）實驗室數據（小米5 WIFI）30次平均進入時間475ms

2）外網運營數據 （6.5版本 對照 6.5.3版本）

從外網運營數據看，觀看成功率提升到99.41%；觀看延時提升到平均2.5s，加快43.5%。用戶進入直播間的時間區間在（0，1] （觀看端0⑴秒內進入成功）的占比提升到19.52%，提升191%。

3）與競品“映客”對照 （左邊空間 VS 右邊映客 小米5 WIFI）

https://v.qq.com/iframe/preview.html?vid=x0306f83wfv&amp

4）總結

1、優化可以拔高速度上限，能使用戶進入直播間的耗時上限提高到 500ms 之內，從（0，1]的占比區間提升，對大量用戶的提升還是比較明顯的。

2、直播是強依賴網絡狀態的產品。如果主播的網絡條件很差，上行丟包嚴重時，觀眾卡在這個時間點進入，由于沒有上行是拉取不到首幀數據的，這類情況會致使統計數據被拉高。這也是整體平均時間未到 1s 之內的緣由。

2、QQ 空間直播的架構

在前期技術選型上，綜合斟酌開發周期，穩定性和質量監控體系，我們選用騰訊云的現有視頻互動直播解決方案，以下是整體的架構圖。

1、 直播房間使用 roomid 做唯1 key。邏輯上分為兩層。音視頻房間，主要負責和騰訊云的流媒體服務器通訊音視頻數據和音視頻房間狀態的保護；消息房間，主要負責和空間的服務器進行交互，包括贊，評，打賞等業務邏輯和消息房間的狀態保護。消息房間通過注冊接口來響應音視頻房間的狀態。這樣設計好處就是，消息房間和音視頻房間是解耦的，各自單獨運行都是允許的；

2、 觀眾端可以通過云 sdk、RTMP 或 HLS 協議3種方式收到主播的推流；觀看場景涵蓋 H5，native 多平臺。

3、 直播浮層設計為獨立進程，主要是斟酌到獨立進程 crash 不影響主進程的穩定性；缺點是和主進程的通訊復雜，進程啟動有部份耗時；

3、耗時分析

我們將觀看直播耗時的各階段拆細分析：

1、 全部觀看直播的流程是串行的，致使整體耗時是每一個步驟的耗時累加。

2、 拉取房間信息，拉取直播參數配置，拉取接口機 IP 是3個網絡要求，耗時存在不穩定性，1般是 300ms，網絡情況不好就會到 1000ms+；

3、 直播進程的生命周期是跟隨 avtivity 的生命周期，activity 燒毀后，進程也隨之燒毀，再打開需要耗時重新創建進程。

4、互動直播 SDK 的上下文是依賴直播進程，新進入也需要重新初始化。

5、 拉取首幀數據是單步驟耗時最久，急需解決。

4、確立方案，各個擊破

根據直播的具體業務來分析，我們確立了以下幾個解決的緯度。

速度優化1般有以下幾個方向來解決問題：

1、 預加載。

2、 緩存。

3、 串行變成并行，減少串行耗時。

4、 對單步驟中的耗時邏輯梳理優化。

根據這些方向，我們做的工作：

1、 預加載進程。

2、 互動直播 SDK 上下文全局單例，并且預先初始化。

3、 并行預拉取接口機 IP，房間信息，預進入互動直播 sdk 房間。

4、 接口機緩存首幀數據，減少 GOP 分片時間，修改播放器邏輯，解析到 I 幀就開始播放。

1）新方案的整體流程圖：

該方案在加速的基礎上，還有其他的優點：

1、對現有的代碼改動最小，保證版本的穩定性，除新增的預拉取邏輯，在原有流程上只需要將之前的異步邏輯改成拉取緩存的邏輯。

2、原有邏輯成為備份邏輯，流程茁壯型得到增強，預拉取失敗還有原有邏輯作為備份“重試”，進房間成功率提高。

2）預拉取流程，詳細介紹

從“預拉取接口機 IP”這個點來詳細介紹如何做預拉取，緩存管理和時序處理：

1、 由于直播進程和主進程是內存隔離。Feeds 轉動停止（開始預拉取）是在主進程觸發。拉取的 wns 要求需要在直播進程。通過 AIDL 跨進程去調用。

2、 接口機 IP 的要求為異步，需要緩存要求的狀態。要求緩存接口機 IP 數據時，預拉取的狀態為成功，直接使用緩存數據。

預拉取的狀態為要求中，等待本次預拉取的結果。

預拉取的狀態為失敗，走之前流程，重新要求接口機 IP。

3、 接口機 IP 需要有時效性的，每次滑動停止都預加載 IP，會造成了要求浪費；并且騰訊云的接口機 IP 有就近接入的特性。為保證負載穩定，如果1直使用緩存的接口機 IP 可能會致使某臺機器負載過量。需要加入時效性的控制。

3）秒開關鍵

仔細的同學肯定發現還有1個最大的耗時點沒有解決——拉取首幀數據過慢。這個步驟耗時下降才是秒開的關鍵。

首幀數據的展現進程，實際上是1個下載，解碼，渲染的進程。

這里簡單插述1下視頻編解碼進程中的1種約定：GOP( Group of Pictures )

為了便于視頻內容的存儲和傳輸，通常需要減少視頻內容的體積，也就是需要將原始的內容元素(圖象和音頻)經過緊縮，緊縮算法也簡稱編碼格式。例如視頻里邊的原始圖象數據會采取 H.264 編碼格式進行緊縮，音頻采樣數據會采取 AAC 編碼格式進行緊縮。 視頻內容經過編碼緊縮后，確切有益于存儲和傳輸; 不過當要觀看播放時，相應地也需要解碼進程。因此編碼和解碼之間，明顯需要約定1種編碼器和解碼器都可以理解的約定。就視頻圖象編碼和解碼而言，這類約定很簡單： 編碼器將多張圖象進行編碼后生產成1段1段的 GOP ( Group of Pictures ) ， 解碼器在播放時則是讀取1段1段的 GOP 進行解碼后讀取畫面再渲染顯示。 GOP ( Group of Pictures ) 是1組連續的畫面，由1張 I 幀和數張 B / P 幀組成，是視頻圖象編碼器和解碼器存取的基本單位，它的排列順序將會1直重復到影象結束。

在云 SDK 中，將幀類型擴大到5種：

• I 幀不需要參考幀。
• P 幀只參考上1幀。
• P_WITHSP 幀可參考上1幀、I 幀、GF 幀、SP 幀，自己不可以被參考。
• SP 幀可參考 I 幀、GF 幀、SP 幀。

• GF 幀可參考 I 幀、GF 幀 。

  1) 標準的 H264 編碼的參照關系，每個 GOP 的第1針是 I 幀，P 幀順次參考上1幀，抗丟包性不強，如果中間有 I 幀或 P 幀丟失，則該 GOP 內后續 P 幀就會解碼失敗。

(1.標準 GOP 組織圖)

2) 在實時直播的場景，為保證流暢性，重寫編碼器邏輯，首個 GOP 包開頭為I幀，后面 GOP 包開頭為 GF 幀，這是利用 GF 幀的傳遞參考關系是跨 GOP，每一個 GF 幀參考上1個 GOP 的 I 幀或 GF 幀。GF 幀體積對照 I 幀要小，后續 GOP 的下載解碼更快速。

(2.SDK 的 GOP 組織圖)

3) 對 GOP 內部的幀組織，也使用 P_WITHSP 幀來代替 P 幀，主要是由于 P_WITHSP 幀（粉紅色表示）的解析可參考上1幀、I 幀、GF 幀、SP 幀，自己不可以被參考。就算上1幀 P_WITHSP 未解碼出來，后1幀 P_WITHSP 的解碼也不受影響，增強了抗丟包性

(3.SDK 的 GOP 幀內部參考關系)

那具體到業務上，通過 wireshark 抓包我們發現。進程主要耗時在首個 GOP 包下行比較慢，需要等待 I 幀（FT 是 0 代表 I 幀）下載終了才開始解碼，如果 I 幀不完全沒法解碼，則需要等待第2個 GOP 包，等待時間加長。

那通過這個現象，為了讓全部進程加快，和 SDK 的同事在1.8.1版本1起做了以下工作：

1、 減小首個 GOP 包的分片大小：將 GOP 的分片由 5s 改成 3s，并且首個 GOP 包只緩存必要的 I 幀，減少首個 GOP 包的體積；（PS：GOP 包的長度和主播端編碼性能也是強相干，GOP 分片太小，編碼性能不高，分片時長的肯定需要綜合斟酌）

2、 首個 GOP 包需要走網絡下載，一樣網絡條件下這部份路徑越短下載越快。GOP 包之前是存在流控服務器上，GOP 包要到達客戶端連接的接口機，還需要鏈接傳輸的耗時。新的版本直接在接口機上緩存當前直播中房間的 GOP 數據，保證在客戶端連上接口機以后，就能夠直接從本機緩存中推流首幀數據，省掉之前的鏈接傳輸耗時。

3、 大部份播放器都是拿到1個完全的 GOP 后才能解碼播放， 改寫播放器邏輯讓播放器拿到第1個關鍵幀（I幀）后就給予顯示。不需要等待全部的 GOP 下載終了才開始解碼。

以上3點做好了以后，效果明顯，全部的拉取首幀的時間由之前的 2140ms 降到平均 300ms，固然完成這些工作其實不是上面敘述的3點那末簡單，中間進程我們也發現1些辣手問題，并推動解決：

如主播上行網絡丟包致使的 GOP 亂序、多臺接口機之間緩存的管理、GOP 分片時長的肯定。

4）延續優化

我們1直沒有放棄“更快更爽”的體驗尋求，在后續的迭代中也延續優化直播的體驗：

1、接口機 IP 競速。

2、合并要求。

3、多碼率。

5、遇到的問題

我們的優化手段是將串行的異步要求改成并行；但是將串行改成并行后，幾個異步要求同時開始，如何保證各個異步回調的時序運行正常，這是1定要解決的問題，也是大家在做優化進程中比較有代表性的問題。

處理這類異步回調時序問題類似于 Promise 模式。我這里在具體業務上使用 LiveVideoPreLoadManager 來統1處理，類圖以下：

• LiveVideoPreLoadManager：負責對外暴露啟動預加載方法和拉取結果數據對象的方法。其主要方法及職責以下。

Compute：注冊監聽器，獲得結果的數據對象，使用監聽器實例來響應對數據對象的處理。
preLoad：啟動異步任務的履行。

• CacheManager：緩存異步任務處理結果和狀態，檢查是不是過期。負責檢測異步任務是不是處理終了、返回和存儲異步任務處理結果。其主要方法及職責以下。

getResult：獲得緩存異步任務的履行結果。
setResult：設置緩存異步任務的履行結果及當前的履行狀態：開始，進程中，結束。
isDone：檢測異步任務是不是履行終了。

• Result：負責表示異步任務處理結果。具體類型由相應的業務決定。

• Task：負責真正履行異步任務。其主要方法及職責以下

run：履行異步任務所代表的進程。

獲得異步任務處理結果的序列圖以下。

采取這類模式，當異步任務同時開始，如拉取房間信息，接口機 IP，房間信息，它們都被封裝在 LiveVideoPreLoadManager 的 Task 要求實例中，而主流程則不必關心這些細節，只需要將之前的要求方式變成 LiveVideoPreLoadManage.compute，并注冊對應的異步回調接口。Compute 內部會通過 CacheManager 的 getResult 方法檢查異步任務處理結果狀態，如果異步任務已履行終了，則該調用會直接返回，類似與同步操作（步驟5，6，7），那末 LiveVideoPreLoadManager 對外暴露的 compute 方法是個同步方法；若異步任務還未履行終了，則會阻塞1直等待異步任務履行終了，再調用 compute 注冊的回調來響應結果，此時 compute 方法是個異步方法（步驟5，4）。也就是說，不管compute方法是1個同步方法還是異步方法，對客戶真個編寫方式都是1樣的。

采取這類 Promise 模式，即對原有流程改動最小，也增強了原有流程的茁壯型，在預拉取失敗的時候，那末原有流程的串行邏輯作為兜底保護。從統計數據也能夠看到，在優化版本以后，版本的觀看端進入房間成功率也有提升。

6、總結

全部的秒開優化版本時間非常緊張，中間肯定還有別的優化空間，統計數據上來看，整體用戶的進入時間還是在 2.5s+，新的迭代版本還在延續優化，大家如果對秒進有甚么好的想法和建議，歡迎交換。也歡迎大家下載新版 QQ 空間獨立版體驗 Qzone 的直播功能，分享生活，留住感動！

更多精彩內容歡迎關注bugly的微信公眾賬號：

騰訊 Bugly是1款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上利用崩潰的情況和解決方案。智能合并功能幫助開發同學把每天上報的數千條 Crash 根據根因合并分類，逐日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布后快速的了解利用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！