本文是 《直播疑難雜癥排查》系列的第三篇文章，我們來看看直播過程中，最重要的一個性能指標：首開。

1. 首開慢的表現

點擊播放後，需要好幾秒才能顯示播放畫面。

2. 常見首開慢問題排查

2.1 點擊播放後才從服務器取播放地址

播放視頻，第一件事就是要拿到播放地址，大多數直播 App，主播的播放地址是由 App 向服務端發 HTTP GET 請求才能拿到的，因此，什麽時候去 “拿” 這個播放地址，顯得至關重要，常見的做法有如下兩種：

- App 拉取正在視頻列表的時候

- 用戶點擊某個視頻，跳轉到播放界面之後

顯然，後者的用戶體驗明顯會比前者差，因為通過 HTTP GET 請求播放地址的過程，無形增加了首開時間，特別是在弱網下，會更慢。

2.2 DNS 解析慢

不同的播放域名，DNS 解析有快有慢，再加上 DNS 解析服務的緩存策略，在本地沒有該域名緩存的情況下，會逐級向更高級的域名服務器查詢域名，因此，播放域名解析的耗時，會對首開產生不小的影響。

為了有效降低 DNS 解析對首開的影響，我們可以提前完成播放域名->IP 地址的解析，並緩存起來，播放的時候，直接傳入帶 IP 地址的播放地址，從而省去了 DNS 解析的耗時。

如果要支持用 ip 地址播放，是需要修改底層 ffmpeg 源碼的，目前七牛的 PLDroidPlayer 就支持這樣的播放地址：

URL 格式：“protocol://ip/path?domain=xxxx.com”

2.3 播放策略原因

播放首開時間的定義，就是從點擊播放到第一幀畫面顯示出來的耗時，因此，我們需要盡一切可能加快播放進度。

很多側重點播的播放器，為了減少卡頓，會有一些緩沖策略，當緩沖足夠多的數據之後 ，再送入解碼播放。

而為了加快首開效果，需要對播放的緩沖策略做一些調整，如果第一幀還沒有渲染出來的情況下，不要做任何緩沖，直接送入解碼器解碼播放，這樣就可以保證沒有任何因為 “主動” 緩沖帶來的首開延時。

2.4 播放參數配置

所有基於 ffmpeg 的播放器，都會遇到 `avformat_find_stream_info` 這個函數耗時比較久，從而增大了首開時間，該函數主要作用是通過讀取一定字節的碼流數據，來分析碼流的基本信息，如編碼信息、時長、碼率、幀率等等，它由兩個參數來控制其讀取的數據量大小和時長，一個是 probesize，一個是 analyzeduration

減少 probesize 和 analyzeduration 可以有效地減少 `avformat_find_stream_info` 的函數耗時，從而加快首開，但是需要註意的是，設置地太小可能會導致讀取的數據量不足，從而無法解析出碼流信息，導致播放失敗，或者出現只有音頻沒有視頻，只有視頻沒有音頻的問題。

2.5 服務端線路原因

當播放端的優化做到極限後，剩下的首開快慢的決定性因素就是服務端的線路了，服務端的線路主要有哪些方面會影響首開呢？

- 冷熱流

當你去附近的邊緣服務器節點拉取某個流的時候，如果最近沒有任何人從該服務器拉過這個流，那麽這臺服務器就需要逐級向源頭拉流，而且該服務器也沒有任何 GOP 緩存，從而產生比較大的首開延時。

- 邊緣節點的 TTL

同等大小的數據，客戶端距離服務器越近，ttl 越小，那麽傳輸速度也就越快，首開也會越快。

- 服務器的響應速度

影響服務器響應速度的因素，一個是跟服務器的協議層優化有關，另一個就是服務端的負載和性能了，服務器當前負載越大，響應自然越慢。

下面給出一張圖，來直觀的感受一下服務端在加速首開這件事上的關鍵作用：

3. 小結

關於播放首開慢的問題排查大致就介紹道這裏了，有任何疑問歡迎來信 [email protected] 交流，另外，歡迎關註我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。

本文出自 “Jhuster的專欄” 博客，請務必保留此出處http://ticktick.blog.51cto.com/823160/1921748

直播疑難雜癥排查（3）— 首開慢