專項測試實戰(zhàn) | 如何測試 App 流暢度（基于 FPS 和丟幀率）？
FPS 和丟幀率可以在一定程度上作為 APP 流暢度的一項衡量標準，本文介紹利用 adb shell dumpsys gfxinfo 命令獲取軟件渲染加載過程的數(shù)據(jù)，進行計算從而獲取測試結果。
在此之前，需要先了解屏幕展示繪制過程及 Android 的 VSync 機制
VSync 全稱是 Vertical Synchronization（垂直同步），在 Android 4.1 中引入 Android 系統(tǒng)(同時引入的一個概念是 Triple Buffering)。
學計算機的經常聽到 Buffer 的概念(生活中也碰到過很多)，起到的都是一個類似的作用。用來協(xié)調兩個不同速度的東西工作。
為什么會這樣呢？因為 CPU/GPU 處理和屏幕展示的速度不一樣但是卻使用的是同一塊內存。
怎么解決呢？可以將 CPU/GPU 處理和屏幕展示分開，CPU/GPU 在后臺處理，處理完一幀的數(shù)據(jù)以后才交給屏幕展示(這樣可能導致另外的問題是，如果 CPU/GPU 處理很慢，那么屏幕可能會一直展示某一幀的數(shù)據(jù)，下面主要分析這個問題的處理)。
手機屏幕刷新率：手機硬件每秒刷新屏幕的次數(shù)，單位 HZ。一般是一個固定值，例如 60HZ。
FPS：畫面每秒傳輸幀數(shù)，通俗來講就是指動畫或視頻的畫面數(shù)。單位 HZ。
手機屏幕刷新率是固定的，F(xiàn)PS 則是一直變化的，怎么才能保證能夠運行流暢呢？從幾個例子來看吧。
先解釋圖片代表的意思：最下面黑線代表的是時間，黃色代表屏幕展示，綠色代表 GPU 處理，藍色代表 CPU 處理。Jank 代表的是重復展示上一幀的異常。下面會從屏幕展示的每一幀開始分析：
上圖是沒有引入VSync 機制的處理流程。
Display 展示第0幀數(shù)據(jù)，這時 CPU/GPU 會去處理第1幀的數(shù)據(jù)。
Display 展示第1幀數(shù)據(jù)(此時屏幕顯示是正常的)，這時 CPU/GPU 可能處理其他任務導致很晚才去處理繪制。
因為 CPU/GPU 沒處理好第2幀的數(shù)據(jù)，所以 Display 還是展示第1幀數(shù)據(jù)(此時屏幕顯示是異常的)，CPU/GPU 處理完第2幀沒有處理完的數(shù)據(jù)然后繼續(xù)處理第3幀的數(shù)據(jù)。
…上圖中一個很明顯的問題是，只要一次 CPU/GPU 處理出現(xiàn)異常就可能導致后面的一系列的處理出現(xiàn)異常。
VSync 可以簡單的認為是一種定時中斷，系統(tǒng)在每次需要繪制的時候都會發(fā)送VSync Pulse 信號，CPU/GPU 收到信號后馬上處理繪制。
在4.1以后引入VSync 機制。
在 FPS < 手機屏幕刷新率的情況下，一切運行完美。
VSync 機制下 Double Buffering 時 FPS > 手機屏幕刷新率的情況。
Display 展示第A 幀數(shù)據(jù)，CPU/GPU 收到 VSync Pulse 信號馬上處理B 幀的數(shù)據(jù)，但是由于計算太多，導致沒有在一個 VSync 間隔內處理完。
由于第B 幀數(shù)據(jù)沒有處理好，Display 繼續(xù)展示第A 幀數(shù)據(jù)(此時屏幕顯示是異常的)。由于系統(tǒng)中只存在一塊內存給 CPU/GPU 處理繪制，所以在這個 VSync 間隔內cpu 不處理任何事。
Display 展示第 B 幀數(shù)據(jù)，CPU/GPU 收到 VSync Pulse 信號馬上處理即將展示A 幀的數(shù)據(jù)，由于計算太多，導致沒有在一個 VSync 間隔內處理完。
需要展示的A 幀數(shù)據(jù)沒有處理好，Display 繼續(xù)展示第 B 幀數(shù)據(jù)(此時屏幕顯示是異常的)。由于系統(tǒng)中只存在一塊內存給 CPU/GPU 處理繪制，所以在這個 VSync 間隔內 CPU 不處理任何事。
…
上圖中一個很明顯的問題是，只要出現(xiàn)一次Jank 就會影響下一次的VSync(cpu 不能工作)。
Triple Buffering 的引入。Display 展示第A 幀數(shù)據(jù)，CPU/GPU 收到VSync Pulse 信號馬上處理B 幀的數(shù)據(jù)，但是由于計算太多，導致沒有在一個VSync 間隔內處理完。
由于第B 幀數(shù)據(jù)沒有準備好，Display 繼續(xù)展示第A 幀數(shù)據(jù)(此時屏幕顯示是異常的)。此時雖然B 被gpu 在使用，但是cpu 可以處理Buffer C(因為有3個緩沖)。Display 展示第B 幀數(shù)據(jù)，gpu 繼續(xù)處理上一步驟的C，cpu 則處理A。
后續(xù)過程出錯的情況被降低了…
1.運行命令"adb -s " + deviceName + " shell dumpsys gfxinfo " + packageName 獲取基礎數(shù)據(jù)，我們會獲得很多數(shù)據(jù)，這里截取需要進行分析的部分：
注：如果運行完命令發(fā)現(xiàn)無上圖中的4個參數(shù)，則很可能是手機的“GPU呈現(xiàn)模式分析”未打開；
2.如上圖信息表示了每一幀在安卓系統(tǒng)中的四個階段：Draw: 表示在Java中創(chuàng)建顯示列表部分中，OnDraw()方法占用的時間
Prepare: 準備時間
Process：表示渲染引擎執(zhí)行顯示列表所花的時間，view越多，時間就越長
Execute：表示把一幀數(shù)據(jù)發(fā)送到屏幕上排版顯示實際花費的時間，其實是實際顯示幀數(shù)據(jù)的后臺緩存區(qū)與前臺緩沖區(qū)交換后并將前臺緩沖區(qū)的內容顯示到屏幕上的時間
將上面的四個時間加起來就是繪制一幀所需要的時間，如果超過了16.67就表示掉幀了
Android 定義了流暢度的數(shù)據(jù)標準，以 60FPS 為標準(FPS 為每秒繪制的幀數(shù)),幀數(shù)過小就會出現(xiàn)卡頓感。
每一幀在安卓系統(tǒng)中分4個階段,4個階段的總和超過16.67(1秒60幀,算下來平均1幀的間隔就約是16.67ms)就認為丟幀。
這個定義在 Android6.0 以前是一定的,但是現(xiàn)在已經沒有固定的標準了，因為目前安卓系統(tǒng)有3層緩存機制,加上硬件上的進步,即使超過16.67,也不一定會出現(xiàn)卡頓感。所以這個數(shù)據(jù)在測試時作為一種對比和相對衡量標準，也可根據(jù)需求自定義標準。
通過以上數(shù)據(jù)，就可以獲取到每一幀的時間、總幀數(shù)；從而就可以計算出 jank 數(shù)、vsync 數(shù)，進而就可以得到最終的 FPS 和丟幀率數(shù)據(jù)。
當然，手工計算無疑效率低，出錯率大，所以這里的計算過程最好還是以腳本形式，讓代碼幫我們去計算，具體代碼計算原理與專項自動化過程后續(xù)探討。
