1. 程式人生 > >【移動開發】關於一對一視訊聊天直播技術(七):直播雲 SDK 效能測試模

【移動開發】關於一對一視訊聊天直播技術(七):直播雲 SDK 效能測試模

本篇是《一對一視訊直播技術詳解》系列的最後一篇直播雲 SDK 效能測試模型,SDK 的效能對最終 App 的影響非常大。SDK 版本迭代快速,每次釋出前都要進行系統的測試,測試要有比較一致的行為,要有效能模型作為理論基礎,對 SDK 的效能做量化評估。本文就是來探討影響 SDK 效能的指標並建立相應的效能模型的。

影響視訊質量和大小的重要引數

在進行測試之前我們需要明確幾個對視訊的質量和大小影響最大的引數:幀率、位元速率和解析度。

1)如何制定幀率

一幀就是一副靜止的畫面,連續的幀就形成動畫,如電檢視象等。我們通常說幀數,簡單地說,就是在 1 秒鐘時間裡傳輸的圖片的數,也可以理解為圖形處理器每秒鐘能夠重新整理幾次,通常用 fps(Frames Per Second)表示。每一幀都是靜止的圖象,快速連續地顯示幀便形成了運動的假象。高的幀率可以得到更流暢、更逼真的動畫。每秒鐘幀數 (fps) 愈多,所顯示的動作就會愈流暢。

2)如何制定位元速率

我們首先看視訊編碼的目的,它是為了在有限的頻寬中傳輸儘可能清晰的視訊,我們以每秒 25 幀的影象舉例,25 幀影象中定義了 GOP 組,目前主要是有 I,B,P 幀三種幀格式,I 幀是關鍵幀,你可以想象它就是一幅 JPEG 壓縮影象,而 B,P 幀是依靠 I 幀存在的,如果丟失了 I 幀,B,P 幀是看不到影象的,B,P 幀描述的不是實際的影象畫素內容,而是每個相關畫素的變化量,他們相對於 I 幀資訊量會很小。GOP 組是指一個關鍵幀I幀所在的組的長度,每個 GOP 組只有 1 個 I 幀。

我們再來看,一組畫面的碼流大小跟什麼有關?當視訊編碼的壓縮方式都一樣,清晰度要求都一樣的時候,GOP 組的長度格式決定了碼流的大小,例如:每秒 25 幀畫面,GOP 組長度為 5,那麼幀格式為 IBPBP,那麼 1 秒鐘有 5 個 I 幀,10 個 B 幀,10 個 P 幀,如果 GOP 組長度為 15,幀格式就是 IBBPBBPBBPBBPBB,那麼 1 秒鐘內會有 2 個 I 幀和 16 個 B 幀和 7 個 P 幀,那麼 5 個 I 幀比 2 個 I 幀佔用的資料資訊量大,所以 GOP 組的長度格式也決定了碼流的大小。

3)如何指定解析度

解析度概念視訊解析度是指視訊成像產品所成影象的大小或尺寸。常見的視像解析度有 640×480,1088×720,1920×1088。在成像的兩組數字中,前者為圖片長度,後者為圖片的寬度,兩者相乘得出的是圖片的畫素。

影響 SDK 效能的指標

有了上述的前置知識,我們可以開始準備測試 SDK 的效能了,我們首先分析一下都有哪些指標可以反映 SDK 的效能,分成 Android 和 iOS 兩個平臺:

Android

  • GC :可以通過 GC 日誌記錄,Mirror GC 和 Full GC 的頻次和時間,Full GC * 會造成比較明顯的卡頓,需要評估
  • UI Loop 就是 VSync Loop :反映 SDK 對 App 流暢度的影響,理論上 60 fps 是最流暢的值。
  • Memory :反映 SDK 佔用記憶體的大小
  • CPU Usage :反映 SDK 佔用計算資源的大小

iOS

  • UI Loop :反映 SDK 對 App 流暢度的影響,理論上 60 fps 是最流暢的值。
  • Memory :反映 SDK 佔用記憶體的大小
  • CPU Usage :反映 SDK 佔用計算資源的大小

除了上面的一些系統級別的指標外,下面是直播 SDK 中特有的一些指標,這些指標可以反映出 SDK 的核心競爭力和一些主要的差異,涉及到視訊的清晰度和流暢度,也是可以量化的。

1)影響視訊清晰度的指標

  • 幀率
  • 位元速率
  • 解析度
  • 量化引數(壓縮比)

2)影響視訊流暢度的指標

  • 位元速率
  • 幀率

3)其他重要指標

直播是流量和效能的消耗大戶,有一些指標,直接影響了使用者的感受,也是我們需要重點關注的:

  • 耗電量
  • 發熱(不好量化,大部分情況發熱和耗電量正比,可以使用耗電量暫時替代)

測試計劃

測試過程需要先固化一些測試條件,然後根據不同的測試條件得出測試結果,這裡選擇了兩個現在最常見的條件,是我們通過回訪大量的客戶得出的一些統計數字,可以反映大部分直播應用所處的場景。主要從解析度、視訊處理、位元速率和網路環境幾個維度進行限制。最後分為幾個兩種測試指標:客觀和主觀指標,前者反映了 SDK 對系統的消耗程度,但雖說是客觀指標並不是說對使用者沒有影響、只是說得出的結果使用者感受不明顯。主觀指標則會直接影響終端使用者體驗,但在傳統的測試中反而容易被忽略,因為不好量化,這裡拍磚引玉的提出一些量化的方式,希望引起讀者的思考。

測試條件 A

  • 解析度 480p
  • 無水印,無美顏
  • 位元速率 1 M
  • 網路保證在 0.5 M ~ 2 M

這個條件,反映了大部分低速網路情況下的使用場景,也反映了 SDK 基本的效能情況,可以作為 SDK 基本推流和拉流情況下的基準測試,不引入太多的測試依賴。

測試條件 B

  • 解析度 720p
  • 無水印,有美顏
  • 位元速率 1 M
  • 網路保證在 0.5 M ~ 2 M

這個條件,反映了大部分客戶的使用場景,具有較高的解析度和美顏視訊處理,可以作為 SDK 競品分析的重要依據,測試結果非常接近真實場景。

1)客觀指標測試計劃

  • 客觀影響 App 穩定性和效能的指標:
  • Memory
  • 測試 10 分鐘,記憶體曲線
  • 測試 1 小時,TP99,TP95,TP90,需要歸檔
  • 測試 1 小時,記憶體增量,考察是否有記憶體洩露,需要歸檔
  • 參考值:上次結果
  • CPU
  • 測試 10 分鐘,CPU Usage 曲線
  • 測試 10 分鐘,TP99,TP95,TP90,需要歸檔
  • 參考值:上次結果
  • 位元速率
  • 測試 10 分鐘,TP99,TP95,TP90,重點說明,這裡的位元速率控制需要分開來看,如果網路抖動造成位元速率降低,這樣的點不計入進來,只測試 SDK 位元速率控制,需要歸檔
  • 參考值:1 M(大小都是偏差)
  • 耗電量
  • 測試一小時,記錄程序總耗電量、螢幕顯示耗電量、CPU 耗電量,需要歸檔
  • 參考值:上次結果

2)主觀指標測試計劃

主觀影響 App 使用者的指標:

  • UI Loop App 本身可以達到的最大幀率,不同於視訊幀率,統計他的原因我們的 SDK 可能會影響整個 App 的流暢度,需要跟蹤
  • 測試 10 分鐘,UI Loop 曲線
  • 測試 10 分鐘,UI Loop TP99,TP95,TP90,需要歸檔反覆比較
  • 參考值:60 fps
  • Android GC
  • 測試 1 小時,記錄 Mirror GC 和 Full GC 的頻次,記錄 GC 時長的 TP99,TP95,TP90,需要歸檔反覆比較
  • 參考值:上次結果
  • 幀率(fps)
  • 測試 10 分鐘,TP99,TP95,TP90,需要歸檔反覆比較
  • 參考值:30 fps
  • PSNR 比較視訊清晰度的指標
  • 測試 10 分鐘,需要歸檔反覆比較,這個指標可以使用固定視訊作為輸入。
  • 參考值:上次結果

3)結果顯示

  • 表格顯示具體指標
  • 曲線顯示原始資料和時間軸的資料
  • 熱圖顯示和參考值的偏差
  • 熱圖顯示距離上次歸檔值是改善了還是惡化了

通過這種反覆迭代的自動化的、系統化的測試,我們以職人之心近乎偏執地反覆打磨著 SDK 的效能,只為給終端使用者帶來最好的直播體驗,幫助我們的客戶通過次時代的媒體最大化自己的商業價值,我們希望在您披荊斬棘的路上我們始終相伴。