原標題：淺談Android流暢度

哈哈

講個故事

白

1

流暢度

關于流暢度谷歌官方給出的解釋為：running at a consistent 60 frames per second, without any dropped or delayed frames, or as we like to call it, jank.即以每秒60幀(每幀16.6ms)的速度運行，也就是60fps，并且沒有任何延遲或者掉幀。

因此，關于流暢度的問題，我們先確定了以下三個考量指標。

1、FPS：每秒的幀數。

2、丟幀(SF: Skipped Frame)：在16.6ms完成工作卻因各種原因沒做完，占了后n個16.6ms的時間，相當于丟了n幀。

3、流暢度(SM: SMoothness)：和丟幀相對，在VSync機制中1s內Loop運行的次數。

VSYNC機制

大家應該看到上面提到了16.6ms和VSync，現在來解釋一下VSync機制。

VSync機制： Android系統每隔16ms發出VSYNC信號，觸發對UI進行渲染，VSync是Vertical Synchronization(垂直同步)的縮寫，是一種在PC上很早就廣泛使用的技術，可以簡單的把它認為是一種定時中斷。而在Android 4.1(JB)中已經開始引入VSync機制

上圖所示是VSync機制下的繪制過程。從上圖可以看出，CPU和GPU的處理時間都少于一個VSync的間隔，即16.6ms。如果每個間隔都有繪制的情況下，當前的FPS即為60幀。

當CPU和GPU處理時間都很慢，或因為其他的原因，如在主線程中干活太多，那么就會出現如下圖這樣的狀況。

從上圖可以看到，CPU和GPU的處理時間因為各種原因都大于一個VSync的間隔(16.6ms)，所以在第二個VSync還在處理1區域的繪制時，不可能實現理論上的FPS60，同時也出現了丟幀(SF: Skipped Frame)情況。試想用戶盯著同一張圖看了32ms而不是16ms，當然很容易察覺出卡頓感，哪怕僅僅出現一次掉幀，用戶都會發現動畫不是很順暢。

測試方法

通過以上信息相信大家對VSync機制有一個簡單的了解，也知道了為什么我們測試流暢度要定最開始提到的幾個指標。下面我們來介紹一下測試方法。

gfxinfo

dumpsys是一個在設備上運行的Android工具，可以轉儲有關系統服務狀態的信息。將gfxinfo命令傳遞給dumpsys在logcat中提供了一個輸出，其中包含與記錄階段期間發生的動畫幀相關的性能信息。

> adb shell dumpsys gfxinfo

上面的命令可產出關于幀的多項信息，部分信息如下：

Stats since: 752958278148ns

Total frames rendered: 82189

Janky frames: 35335 (42.99%)

90th percentile: 34ms

95th percentile: 42ms

99th percentile: 69ms

Number Missed Vsync: 4706

Number High input latency: 142

Number Slow UI thread: 17270

Number Slow bitmap uploads: 1542

Number Slow draw: 23342

Total frames rendered: 本次dump搜集的總幀數

Janky frames: 卡幀數量和卡幀比

Number Missed Vsync: 垂直同步失敗的幀

Number High input latency: 處理input時間超時的幀數

Number Slow UI thread: 因UI線程上的工作導致超時的幀數

Number Slow bitmap uploads: 因bitmap的加載耗時的幀數

Number Slow issue draw commands: 因繪制導致耗時的幀數

可以看到其實這個命令給出的結果就很詳細了，我們可以運用此命令來測試我們的app，并計算我們需要的數據。

SurfaceFlinger

SurfaceFlinger 是Android系統的一個服務，用來生成Surface，管理幀緩沖區(按序排放窗口，將其合成一張圖片，即一幀)

測試命令如下：adb shell dumpsys SurfaceFlinger --latency

運行結果部分如下：

這條命令的含義是獲取當前layer(窗口、圖層)的最近128幀的信息(僅保存128幀)共128行。

第一行是設備的刷新周期refresh-period，單位是納秒

剩余的127行，分為3列

第一列： when the app started to draw (開始繪制圖像的瞬時時間)

第二列： the vsync immediately preceding SF submitting the frame to the h/w (VSYNC信令將軟件SF幀傳遞給硬件HW之前的垂直同步時間)

第三列：timestamp immediately after SF submitted that frame to the h/w (SF將幀傳遞給HW的瞬時時間，及完成繪制的瞬時時間)

fps計算：總幀數/刷新總耗時

一些問題

為什么有時候FPS很低，但是我們卻不覺得App卡頓？

有時候FPS很低，我們卻感覺不到卡頓，因為本來就用不到那么高的FPS，比如畫一個動畫只畫了0.5秒就畫完了，那么FPS最高也只有30幀/秒(標準是60幀/每秒)，但這并不代表它是卡頓的，用0.5秒動畫就畫完了，不能為了湊夠60幀/秒，在做個1s的動畫吧。而如果屏幕根本沒有繪制需求，即屏幕顯示的畫面是靜止的，那FPS就為0。因此，是不是用fps來作為指標，我們需要認真想一想，這個跟你測試場景有很大關系。我們可以針對此問題設計合適的測試場景，這樣才能更真實的反應出應用程序的性能。

參考：

https://developer.android.com/training/testing/performance?hl=zh-cn#aggregate返回搜狐，查看更多

責任編輯：

總結

以上是生活随笔為你收集整理的android fps 垂直同步,浅谈Android流畅度的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。