1 首開時間的定義
首開時間：從點擊播放到第一幀畫面顯示出來的耗時。通常大家說的 “首屏秒開” 指的就是播放器的“首開時間”在 1s 以內。
首開速度是用戶最簡單、最直接的體驗，所以通常是播放器開發中優化的重點。
下面是一個典型的首開速度和用戶感受的關系表：
2 首開時間的影響因子
要優化播放器的首開時間，我們得先了解一下影響播放器首開時間的因素有哪些，下圖簡單展示了播放器向服務器申請播放一個視頻流的全過程。
想優化播放器的首開時間，首先關注一下播放流程中的每個環節，如圖所示，可能的優化點列表如下：
申請資源的播放 URL 地址的時機優化 -> 爭取在用戶點擊播放之前拿到 解析優化 -> 提前完成 DNS 解析有畫面優化播放器，并緩存結果服務器的連接和數據傳輸速度優化 -> 主要是服務器節點與播放器之間的網絡傳輸優化視頻流的媒體信息解析優化 -> 主要是解析提取算法的優化解碼和渲染策略優化 -> GOP 緩存，確保首幀為關鍵幀解碼渲染其他優化手段 -> 測速選線、解碼算法性能等
在這個過程中，每一個環節都有一些影響因子會決定播放器的首開時間，我們下面詳細展開優化思路。
音視頻開發學習地址：//RTMP/NDK/音視頻流媒體高級開發
【文章福利】：小編整理了一些個人覺得比較好的學習書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦！~點擊加入（需要自取）
3 首開優化方法3.1 優化 URL 的獲取時機
如圖是一個播放列表有畫面優化播放器，每個視頻都會對應一個資源的 URL 播放地址，如果在用戶點擊視頻后，APP 再去后臺業務服務器去申請這個 URL 播放地址，無疑增加了一次 HTTP 請求和應答的耗時，特別是網絡不穩定的時候，耗時更加明顯。
因此，這是一個可以在 APP 層進行的優化點：在拉取視頻播放列表的時候，“同時” 把視頻的 URL 播放地址也拉取下來，在用戶點擊視頻后無需再向服務器申請播放地址，即可立即開始播放了。
3.2 優化 DNS 解析時間
視頻資源的 URL 地址，往往是包含域名的，比如：
/video/movie.mp4
播放器在播放前，需要先進行 DNS 解析，把 這個域名解析為一臺服務器的 IP 地址，然后才能通過 TCP 連接上去，發送資源請求。
我們在 17CE 網站上簡單測測這個域名解析的時間：
可以看到，平均 DNS 解析時間在 673ms 左右，但是在很多地區（比如：佛山市電信，北京市電信）解析時間都超過 2s 了，可想而知，在這些地區 DNS 解析緩慢對播放器首開時間是致命的傷害。
為了確保所有地區的視頻播放不過于受 DNS 解析速度的影響，除了為視頻資源的域名購買付費的專業 DNS 解析服務外，播放器層面也可以針對性地做一些優化，如下圖所示：
播放器內部新增一個 DNS 結果緩存模塊
在異步線程定時執行 DNS 解析，并把 “域名 & IP 表” 緩存在內存中
視頻播放時，直接查表，取出域名對應的 IP 地址，送入播放器
注意事項：
一個 APP 的資源域名個數是收斂的，不是無限個，所以可以在 APP 啟動的時候，送入播放器提前去完成 DNS 解析和緩存
未提前配置的域名，在第一次解析的時候，依然會首開慢，但該域名第二次即可從本地緩存中取了
需要注意緩存的 IP 地址的刷新：
DNS 解析有一個 TTL 超時時間，到期前要記得重新解析刷新
監測手機網絡切換事件，比如：WiFi 切換到 4G 后，需要清空緩存
舉個例子：
DNS Cache Map: < , 185.199.108.153:80>
如果要播放 URL： /video/movie.mp4
可直接替換為播放： 185.199.108.153/video/moive.mp4
坑在哪 ？
當我們真的用 ip 地址去播放的時候，會發現服務器會拒絕訪問，例如報如下錯誤：
原因：視頻資源的 CDN 服務商需要知道是 “誰” 在申請這個視頻資源 -> 為了計量和計費，服務商的判斷訪問依據是“域名”，所以直接使用 IP 訪問會遇到上述問題。
怎么解決 ？