玩物拍賣直播看播效果優(yōu)化

前言

玩物得志的直播電商起源于19年年中,是一個非常年輕的業(yè)務(wù)了。我們在實際開發(fā)運營過程當中面臨反饋最多的就是直播各個方面的卡頓及延時問題,從而嚴重影響客戶體驗。本文我們簡單敘述下我們在碰到各類卡頓延時場景下,如何優(yōu)化我們的客戶體驗的。

目錄

  • Bad Case
  • 視頻卡頓優(yōu)化
  • 拍賣延時優(yōu)化

Bad Case

視頻卡幀了

卡卡卡……看過直播的都知道卡成幻燈片有多難受??

明明看著是我的出價最高怎么中拍的不是我?

還有十秒,偷塔出了一手價,嘿嘿應(yīng)該撿到漏了??。
居然中拍的不是我??,一定是系統(tǒng)有BUG??

為什么他們的直播比我快?

同樣一件拍賣商品,居然安卓/IOS的倒計時不一致?甚至我拿兩臺一樣的手機放著放著都不一致了???

優(yōu)化三板斧來了


視頻相關(guān)

衡量視頻直播的性能有三個指標:第一個是延遲,第二個是卡頓,第三個就是首屏耗時。那么能不能低延時+少卡頓+高清晰度呢?作為一個成年人,正常的想法肯定是:



那么能不能呢?看看后面的一些基本概念。

聊聊直播那些參數(shù)

gop:
gop是啥?GOP(Group of picture) 關(guān)鍵幀的周期,也就是兩個IDR幀之間的距離。一般我們都想要視頻越流暢且延時越低就好,然而流暢度和延時魚和熊掌不可兼得,gop越大時延時越高但是流暢度會有提升,gop越小延時越小但是會變得卡頓。
拍賣的場景下延時不可以太長,4、5s會明顯感覺出延時,所以寧可降低一些幀率,在不太卡頓的情況下降到更低的延時。找到一個最適宜的gop,根據(jù)我們的經(jīng)驗在2左右比較合適的。
fps:
理論上fps越高,動畫越連續(xù)。比如我們最喜歡的農(nóng)藥的fps就會到60。但是注意一定不要混淆場景:游戲追求高幀率是渲染幀率,其目的是為了盡可能讓 3D 模型渲染出來的運動效果更加接近真實運動軌跡,所以幀率越高越好,但采集幀率不需要這么高,例如手機攝像頭,它采集的目標是真實世界的物體,真實世界的物體本來就是連續(xù)運動的,而不是用一陣陣畫面刷新來模擬的,所以 20FPS 的采集就足以。并且過高的fps會導致系統(tǒng)開銷的上升,讓一些本就已經(jīng)性能落伍的手機負載更高,反而影響了推流的效果。所以目前我們采取了比20略高的fps配置。
清晰度
看起來是一個和卡頓延時不太相關(guān)的參數(shù),但是同樣的,清晰度上升對應(yīng)的碼率也需要配合上升。所以賣貨的直播也不能追求過高的清晰度,否則反而會出現(xiàn)馬賽克造成觀感的下降。下面是某服務(wù)商的一些推薦指標,大家可以參照著進行調(diào)整

檔位 分辨率(Resolution) FPS(FPS) 碼率(Bitrate)
標清 360*640 20 800kbps
高清 540*960 20 1000kbps
超清 720*1280 20 1800kbps

所以看的多了就發(fā)現(xiàn)在硬件條件一定情況下選擇提升哪一個性能指標往往有時候必須做出選擇。
那么要清晰度還是流暢度?



根據(jù)我們的業(yè)務(wù)場景來說可能清晰度來說更重要,畢竟連貨都看不清誰敢買?所以還是在高清及以上的基礎(chǔ)上進行參數(shù)優(yōu)化。
當然這樣也只是一般的一刀切而已,我們的目標應(yīng)該是根據(jù)網(wǎng)絡(luò)和硬件情況動態(tài)設(shè)置推流參數(shù),這樣才能大家好才是真的好啊。

HttpDNS功能的使用

這是一個能正向提速的功能,首先我們了解下不用httpdns可能會出現(xiàn)的問題

  • 域名劫持造成的無法正常訪問業(yè)務(wù)域名,訪問超時或返回錯誤;
  • 域名劫持造成的訪問到舊文件,未更新;
  • 域名劫持造成的訪問后返回涉政、涉黃等敏感、違法頁面;
  • 域名劫持造成的訪問業(yè)務(wù)域名后返回廣告、導航等第三方頁面;
  • 因為DNS多出口,轉(zhuǎn)發(fā)解析等因素,造成的終端訪問過慢。

不考慮域名劫持的問題,我們主要是用httpdns解決多出口的問題,具體是什么一個意思呢?
傳統(tǒng)的 DNS 有很多問題,例如解析慢、更新不及時。因為緩存、轉(zhuǎn)發(fā)、NAT 問題導致客戶端誤會自己所在的位置和運營商,從而影響流量的調(diào)度。
比如你家在西南小鎮(zhèn),用了長城寬帶等類似小公司的寬帶,那邊運營商極有可能根據(jù)播放域名把你轉(zhuǎn)到一個大服務(wù)商比如移動聯(lián)通,并且解析到了最近的移動或者聯(lián)調(diào)的服務(wù)器,這樣就會造成跨服務(wù)器的時延;另外也有情況是運營商的服務(wù)器有緩存,導致沒有訪問最快的服務(wù)器。
但是一些服務(wù)商搭建基于 HTTP 協(xié)議的 DNS 服務(wù)器集群,分布在多個地點和多個運營商。那么我們使用httpdns以后,當客戶端需要 DNS 解析的時候,直接通過 HTTP 協(xié)議進行請求這個服務(wù)器集群,得到就近的地址。把域名替換為IP地址,就可以縮短轉(zhuǎn)發(fā)造成的時延。


出價相關(guān)優(yōu)化

服務(wù)端

  • 縮小同步代碼塊
    拍賣當中最核心的消息就是出價消息,會影響每個用戶對于商品是否要出價的判斷,也會影響到主播對于當前直播間的火熱程度和后續(xù)發(fā)拍的決策。
    我們在運行一段時間業(yè)務(wù)量逐漸增長后后遇到的情景是客戶發(fā)現(xiàn)自己出價總是落后于別人,被別人搶了自己的出價。
    對此我們排查了后端出價的代碼,原因是之前的synchronized同步塊鎖的代碼段太長了,核心需要加鎖的只有商品加價和增加出價記錄這兩塊代碼,但是同步的代碼塊卻包含了和比對當前價格、發(fā)消息等不需要同步的代碼塊,導致鎖的時間加長,在鎖的代碼內(nèi)比對當前價格(redis)這一步會大量失敗。所以對此我們的處理很簡單,縮小同步代碼塊只鎖住最核心的加價邏輯就可以了。
    原始代碼:
public void handleAuctionV1(Long userId, Integer price) {
    //參數(shù)檢查等一系列檢查函數(shù)
    ...;

    //同步代碼塊 tryLockMILLISECONDS(String lockname, Long waitTime, Long lockTime)
   if (lockUtil.tryLockMILLISECONDS(lockKey, 200L, 1000L)) {
        //快速點擊校驗
        if(doubleClickCheck()) {
            return;
        }
        //設(shè)置Redis當前出價
        setRedisNowPrice();
        //添加拍賣記錄
        addAuctionRecord();
        //添加關(guān)注操作
        addFav();
        //分傭操作
        addCps();
        //消息通知
        auctionSuccessNotify();
    }
}

其實在上述代碼中快速點擊校驗以及添加拍賣記錄的操作都是不需要在同步塊中的,尤其是一些比較耗時的方法,保證變量線程安全其他的方法都可在同步塊外操作并且縮短鎖占有的時間。
將非核心代碼移出同步塊后,減少了大量出價失敗的case。

  • 增加心跳數(shù)據(jù)修正
    當然完全依賴消息做出價的更新還是會有問題。雖然我們用的是某在IM方面很有經(jīng)驗的云廠商的服務(wù),但是不可避免的有時候會出現(xiàn)云廠商的服務(wù)過載、或者網(wǎng)絡(luò)的抖動、以及偶爾客戶端的一些BUG導致出出價消息最終丟失了,或者是沒有成功的展示出來。直接導致的后果就是用戶自以為自己是最高的出價了,但是其實已經(jīng)有更高的出價了;或者主播端看不到最新的出價影響拍賣的效率。
    所以要在“推”消息的基礎(chǔ)上做“拉”的補償操作,通過心跳講最新在拍的商品的價格返回,可以在出現(xiàn)推消息異常的情況下,根據(jù)心跳中返回的最高價格及出價人與當前客戶端顯示的信息對比,進行修正。


客戶端

  • 時鐘同步
    早期的版本拍賣的倒計時是由客戶端讀取手機時間自己實現(xiàn)計時器去實現(xiàn)的。顯而易見的問題就是每個用戶讀取自己的手機,在沒有類似后端ntp時間服務(wù)器的機制下,會出現(xiàn)剩余時間的不一致。對于我們想拍賣撿漏的用戶來說,特別喜歡在最后一兩秒“偷塔”,因為時間和后端不一致而出價失敗就會非常懊惱。
    這種邏輯下,截拍時間差=收到開播消息接口的傳輸時間+手機時間和機器時間的誤差,最大情況下我們發(fā)現(xiàn)差值達到1秒。
    所以在提供了客戶端心跳接口的基礎(chǔ)上,接口即用來收集一些實時看播信息,同時也返回給客戶端統(tǒng)一的機器時間,以此時間為準更新前端顯示的時間達到各個端的一致。

總結(jié)

上述一頓三板斧下來總算讓我們的服務(wù)看起來不那么卡了,但是整體來看在監(jiān)控、日志上報和網(wǎng)絡(luò)CDN層面我們還有很多優(yōu)化可以很多的事情可以做。
當然現(xiàn)在各個大廠也在推出RTC超低時延直播等更加低延時的直播技術(shù)(當然一分價錢一分貨需要更多的米),支持千萬級并發(fā)場景下的毫秒級延遲直播能力。在互動直播場景中,用戶送禮物、刷彈幕的動作更加實時反饋到主播端;在電商直播中,寶貝信息、代金券發(fā)放、限量商品搶購都可以更加實時地反饋給主播和買家雙方。
這么一看,直播的優(yōu)化還是星辰大海啊。

參考文檔

深入淺出移動直播技術(shù)之幀率、碼率和分辨率
傳統(tǒng)DNS的問題與HTTPDNS
優(yōu)化視頻卡頓

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 移動直播的興起使得在移動端觀看直播的需求日漸增多,相交于點播而言,直播提出了一個新的要求——實時性,也即要求主播端...
    金山視頻云閱讀 9,155評論 3 21
  • 活法中所說的把愿望滲透到“潛意識”,就是要有一個高目標,并有強烈的愿望要去實現(xiàn),就像書中所說的廢寢忘食,...
    東方美_83fe閱讀 230評論 0 0
  • 文/月暉風止 《陽光小美女 》該電影圍繞著一家人陪伴小女兒奧莉薇去參加比賽的前后經(jīng)過展開的,這里面的主人...
    月暉風止閱讀 467評論 0 4
  • 不知不覺間,又是兩天已過,今天是星期六,很高興還記得是周六。想一想這兩天來,六年級兩個班的教學進度就深感無...
    抬頭望見月_閱讀 139評論 0 1
  • 光線在滂沱后, 在后溫涼里, 出來, 慢慢地等到了夜晚的接過。 開始它是片片地布滿, 而后是只等著美麗地迎接。
    醉心語閱讀 147評論 0 5

友情鏈接更多精彩內(nèi)容