百度APP流暢度全流程質量監控實踐（一）流暢度現狀分析

時間 2020-04-07

標籤百度 app 流暢流程質量監控實踐現狀分析简体版

原文原文鏈接

本文做者：yanxin1563微信

做者：MQA-sherryshare函數

前言

流暢度測試是客戶端性能測試技術中一個深度領域，因此百度App給你們帶來流暢度全流程質量監控實踐的系列文章。oop

其中包含:性能

系列（一）流暢度現狀分析，學習

系列（二）流暢度指標選取，測試

系列（三）流暢度線上線下監控實踐，優化

系列（四）流暢度競品評測方案。動畫

但願對你們在流暢度性能測試方向的學習和實踐有所幫助。spa

背景

爲何要關注流暢度？APP容易崩潰、網頁新聞打不開等屬於痛點問題，用戶會投訴甚至卸載。通過不斷的優化，提高穩定性、下降白屏率以後，這些痛點問題不那麼痛時，咱們就須要把關注目標集中到用戶的「爽點」上來，影響爽點的典型問題之一就是——卡頓問題。線程

測試同窗經過用戶反饋分析，卡頓在不一樣業務場景下，對用戶體驗都存在影響，且部分狀況用戶情緒較差，但實際上case by case處理時，常由於線下沒法復現、用戶提供線索不足等緣由不了了之，所以須要單獨創建監控指標進行召回。

另外一方面，隨着高性能手機不斷出現，爲了提高用戶交互體驗，設計再也不是簡單的彈框或者加載的交互，動效等較「炫」的交互場景被更多的使用。帶來高級感體驗的同時，在低端機上會不會形成負擔呢？會不會給人不只不「炫」，反而卡的無法用的感受呢？所以，咱們亟需一套好的流暢度監控標準，來掌握高級交互和卡頓之間的平衡

業界流暢度監控方案調研（Android）

1. 基礎流暢度概念介紹

1.1 理想幀率：

60FPS，受限於顯示器的刷新頻率60HZ

1.2 理想幀長：

1/60≈16.6ms

1.3 Vsync機制：

VSync 能夠簡單的認爲是一種定時中斷，系統在每次須要繪製的時候都會發送VSync Pulse 信號，cpu/gpu 收到信號後立刻處理繪製。

2. 業界方案調研

3. 監控實現原理

3.1 統計幀長基於VSYNC：統計幀長、SM、SF：

Choreographer類就是接受系統垂直同步信號（VSync信號），在每次接受VSync信號時順序執行View的Input、Animation、Draw等3個操做，而後等待下一個信號，再次順序執行3個操做。若是第二個信號到來時，Draw操做沒有按時完成，界面將不會更新，顯示的仍是第一幀的內容。這就表示丟幀了，丟幀是形成畫面卡頓的緣由。因此咱們能夠向Choreographer類中加入本身的Callback，經過此Callback的doFrame函數咱們能夠統計一秒內幀繪製的次數（即流暢值SM ）、繪製耗時（兩次doFrame之間耗時，即幀長）、丟幀SF。

3.2 基於Looper：

利用UI線程的Looper打印的日誌匹配獲取幀長。和VSYNC方案相似，只是當UI線程阻塞嚴重時，可能出現數據丟失。（對UI線程的影響也是一個待平衡點）

3.3 堆棧監控：

單開線程按期抓取堆棧，基於Vsync或者Looper機制監控到幀長超過指定閾值時，上傳最近的堆棧。但因爲單開線程實時抓堆棧，會致使應用自己性能退化，不適宜線上長期大面積使用。

3.4 監控注意事項（實測經驗）:

實際測試中發現，APP靜置時，尤爲是網頁靜置時，SM值亦可能出現變低如接近30的狀況，SF值、幀長都可能存在超過理想值的狀況。緣由是用戶雖未對界面進行操做，亦可能在後臺發生下載、屏幕顯示區域以外的動畫等行爲，總體界面展示上表現不出卡頓，但可能會對用戶肉眼感知不到的加載等形成影響。

——不一樣階段、不一樣場景下，相同流暢度指標的絕對值，對用戶實際體驗的反應準確度有所不一樣，所以建議區分場景和階段進行監控。