系統層級（SurfaceFlinger）的顯示性能指標

應用層級（Surface）的顯示性能指標

小結

評價顯示性能的各個指標，可以按其在圖像渲染流程中的作用，分為以下兩類：

Step 2：你從哪兒來——這些指標數值是怎麼得到的

第一章的內容僅僅是站在整個圖像繪制流程的高度來簡單分析各個指標的，本章將進一步分析各個指標的基礎數據來源以及具體計算方式。

基礎數據：系統層級（SurfaceFlinger）的合成（上屏）的次數

前面說到，在 Android 系統中，SurfaceFlinger 扮演了系統中所有 Surface 的管理者的角色，當應用程序所對應的 Surface 更新之後，絕大多數的 Surface 都將在 SurfaceFlinger 之中完成了合並的工作之後，最終才會在 Screen 上顯示出來。

當然， SurfaceFlinger 的執行也是由 VSYNC 信號驅動的，這也決定了每秒鐘合成次數的上限就是 60 次。當 SurfaceFlinger 接收到 Surface 更新通知的時候，將會由 SurfaceFlinger::handleMessageRefresh 函數進行處理，其中包含重建可見區域、初始化、合成等步驟。這裡，我們主要關注 SurfaceFlinger::doComposition() 這個方法。

void SurfaceFlinger::handleMessageRefresh() {
  ...
  if (CC_UNLIKELY(mDropMissedFrames && frameMissed)) {
    // Latch buffers, but don't send anything to HWC, then signal another
    // wakeup for the next vsync
    preComposition();
    repaintEverything();
  } else {
    preComposition();
    rebuildLayerStacks();
    setUpHWComposer();
    doDebugFlashRegions();
    doComposition(); //重點關注對象
    postComposition();
  }
  ...
}

在 doComposition 中，完成 Surface 的合成之後，都會調用 DisplayDevice::flip()，它會使用變量 mPageFlipCount 統計我們進行合成的次數，這個變量就是我們統計 FPS 的核心原始數據。mPageFlipCount 記錄了 SurfaceFlinger 一共進行了多少次合成，也可以簡單理解為，SurfaceFlinger 向屏幕提交了多少幀的數據。

void SurfaceFlinger::doComposition() {
  ATRACE_CALL();
  const bool repaintEverything = android_atomic_and(0, &mRepaintEverything);
  for (size_t dpy=0 ; dpy& hw(mDisplays[dpy]);
    if (hw->isDisplayOn()) {
      ...
      hw->flip(hw->swapRegion);//重點關注對象
      ...
    }
    // inform the h/w that we're done compositing
    hw->compositionComplete();
  }
  postFramebuffer();
}

void DisplayDevice::flip(const Region& dirty) const {
  ...
  mPageFlipCount++;
}

不僅如此， Android 還為我們獲取這個基礎數據提供了比較方便的方法。通過執行 adb 命令：service call SurfaceFlinger 1013，我們就可以得出當前的 mPageFlipCount。

C:\Users\xiaosongluo>adb shell
shell@cancro:/ $ su
su
root@cancro:/ # service call SurfaceFlinger 1013
service call SurfaceFlinger 1013
Result: Parcel(00aea4f4    '....')

FPS 的計算方法

根據 FPS 的定義，我們不難逆推得出 FPS 的計算方法：

在 t1 時刻獲取 mPageFlipCount 的數值 v1，在在 t2時刻獲取 mPageFlipCount 的數值 v2，FPS 的計算公式：

FPS = (v2 - v1) / (t2 - t1);

需要注意的是：mPageFlipCount 的原始數據是 16 進制的，一般而言計算之前需要先進行進制轉換。

基礎數據：應用層級（Surface）的繪制過程中每一幀的關鍵時間點（FrameInfo）

請大家先注意 FrameInfo 是由 Android 6.0（具體來講是 Android M Preview） 引入到 HWUI 模塊中的統計功能。 因此，目前來講絕大多數系統上的大多數應用都暫時無法獲取這一基礎數據。不過 This IsTheFuture。

我們再來仔細瞧瞧 Google 給出的顯示性能測試的十全大補丸 《Testing Display Performance : Aggregate frame stats》 。其中，特別值得關注的是 adb shell dumpsys gfxinfo framestats 這一條命令。通過這條命令，我們獲取每一幀繪制過程中每個關鍵節點的耗時情況，從而仔細的分析潛在的性能問題。

不得不說，按照 Google 給出的這種測試方法進行測試得到的顯示性能數據是非常全面的。

這些基礎數據都是記錄在 FrameInfo 之中，由 CanvasContext 在doFrame（）時進行記錄。相關的主要源碼如下：

//源碼：FrameInfo.cpp
#include "FrameInfo.h"
#include 

namespace android {
  namespace uirenderer {
    const std::string FrameInfoNames[] = {
      "Flags",
      "IntendedVsync",
      "Vsync",
      "OldestInputEvent",
      "NewestInputEvent",
      "HandleInputStart",
      "AnimationStart",
      "PerformTraversalsStart",
      "DrawStart",
      "SyncQueued",
      "SyncStart",
      "IssueDrawCommandsStart",
      "SwapBuffers",
      "FrameCompleted",
    };

    void FrameInfo::importUiThreadInfo(int64_t* info) {
      memcpy(mFrameInfo, info, UI_THREAD_FRAME_INFO_SIZE * sizeof(int64_t));
    }
  } /* namespace uirenderer */
} /* namespace android */

Aggregate frame stats 指標的計算方法

首先需要說明的是 Aggregate frame stats 不是一個指標，而是一系列指標集合。我們來看一個具體的 Aggregate frame stats 的例子：

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

以上統計信息的實現可以詳見源碼：GfxMonitorImpl.java

在 Android M 以上的系統上，上述信息的獲取十分方便（事實上也只有這些系統能夠獲取這些信息）。僅需要執行以下命令即可：

adb shell dumpsys gfxinfo 

Jankiness count、Max accumulated frames、Frame rate 指標的計算方法

首先需要說明的是：Jankiness count、Max accumulated frames、Frame rate 與 Aggregate frame stats的基礎數據並不一致，它們的基礎屬於來源於 gfxinfo（Profile data in ms）。

只是在 Android M 中 gfxinfo（Profile data in ms） 的基礎數值來源於 FrameInfo，詳見源碼：FrameInfoVisualizer。但在更早的系統之上， gfxinfo（Profile data in ms） 的數值也可以獲取。

這裡需要特別指出的是， gfxinfo（Profile data in ms）只保存了 Surface 最近渲染的128幀的信息，因此，Jankiness count、Max accumulated frames、Frame rate 也僅僅是針對這 128 幀數據所計算出來的結果,它們的具體含義分別是：

如果你對具體的計算過程感興趣，可以參考詳見源碼：JankTestBase

基礎數據：應用層級（Surface）的繪制過程中每一幀的關鍵時間點（Choreographer）

先說一句有點繞口的話： Choreographer 是依據 Choreographer 繪制的 Surface 在 UI 繪制過程中最為核心的機制。

Choreographer 的工作機制簡單來說就是，使用者首先通過 postCallback 在 Choreographer 中設置的自己回調函數：

那麼，當 Choreographer 接收到 VSYNC 信號時，Choreographer 會調用 doFrame 函數依次對上述借口進行回調，從而進行渲染。

那麼顯然，doFrame 的執行效率（次數、頻率）也就是我們需要的顯示性能數據。而這樣的基礎數據，Choreographer 自身也進行了記錄。如下面代碼中， jitterNanos 記錄了繪制前後兩幀所間隔的時間差， 而 skippedFrames 則記錄了 jitterNanos 這段時間 doFrame 錯過了多少個 VSYNC 信號，即跳過了多少幀。

// Set a limit to warn about skipped frames.
// Skipped frames imply jank.
private static final int SKIPPED_FRAME_WARNING_LIMIT = SystemProperties.getInt("debug.choreographer.skipwarning", 30);

void doFrame(long frameTimeNanos, int frame) {
  ...
  final long jitterNanos = startNanos - frameTimeNanos;
  if (jitterNanos >= mFrameIntervalNanos) {
    final long skippedFrames = jitterNanos / mFrameIntervalNanos;
    if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
      Log.i(TAG, "Skipped " + skippedFrames + " frames! " + "The application may be doing too much work on its main thread.");
    }
    ...
    final long lastFrameOffset = jitterNanos % mFrameIntervalNanos；
    ...
    frameTimeNanos = startNanos - lastFrameOffset;
  }
  ...
}

上述數據的獲取並不是那麼的直接，所以需要一定的手段。方法一共有三種，都不難：

缺點：該方案需要系統授權 “Adb Root” 權限，用於修改系統屬性；對於丟幀信息只能統計分析，無法進行實時處理。
優點：設置完成後，可以獲取系統中所有應用各自的繪制丟幀情況（丟幀發生的時間以及連續丟幀的數量）。

其實，仔細觀察代碼，我們就可以注意到 Choreographer 源碼中本身就有輸出的方案：

if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
  Log.i(TAG, "Skipped " + skippedFrames + " frames! " + "The application may be doing too much work on its main thread.");
}

唯一阻礙我們獲取數值的是：skippedFrames 的數值只有大於 SKIPPED_FRAME_WARNING_LIMIT 才會輸出相關的警告。而 SKIPPED_FRAME_WARNING_LIMIT 的數值可以由系統參數 debug.choreographer.skipwarning 來設定。

注意：初始條件下，系統中不存在 debug.choreographer.skipwarning 參數，因此 SKIPPED_FRAME_WARNING_LIMIT 將取默認值 30。因此，正常情況下，我們能夠看見上訴 Log 出現的機會極少。

因此，如果我們修改（設定）系統屬性 debug.choreographer.skipwarning 為 1，Logcat 中將打印出每一次丟幀的Log。需要說明的是，由於為 SKIPPED_FRAME_WARNING_LIMIT 賦值的代碼段由 Zygote 在系統啟動階段加載，而其他應用都是在拷貝復用 Zygote 中的設定，因此設定系統屬性後需要重啟 Zygote 才能使得上述設定生效。

具體的設置方法如下：

setprop debug.choreographer.skipwarning 1
setprop ctl.restart surfaceflinger; setprop ctl.restart zygote

設定完成以後，我們可以直接通過 Logcat 中的信息得到系統中所有應用的繪制丟幀信息，包括丟幀發生的時間以及連續丟幀的數量。不過由於 Logcat 信息的滯後性，以上信息我們幾乎只能進行在測試完成後進行統計分析，而無法進行實時處理。

缺點：該方案需要將測試代碼與待測應用打包在一起，因此理論上僅能測試自己開發的應用。
優點：可以對丟幀信息進行實時處理

我們先來看看 Choreographer.FrameCallback 的定義。

Implement this interface to receive a callback when a new display frame is being rendered. The callback is invoked on theLooper thread to which the Choreographeris attached.

通過這個接口，我們可以在每一幀被渲染的時候記錄下它開始渲染的時間，這樣在下一幀被處理是，我們不僅可以判斷上一幀在渲染過程中是否出現掉幀，而整個過程都是實時處理的，這為我們可以及時獲取相關的調用棧信息來輔助定位潛在的性能缺陷有極大的幫助。

缺點：該方案需要通過注入程序為指定應用注入測試代碼，因此需要系統為注入程序授權 “應用Root” 權限。
優點：與 Choreographer.FrameCallback 方案一致。

該方案可以簡單理解為通過注入的方式來實現與 Choreographer.FrameCallback 方案一樣的目的。因此，這裡我們主要討論兩者在實現方式上的區別。

顯而易見，我們需要注入的對象是 Choreographer ，因此理論上任何第三方應用都是可以被注入的。但是隨著 Android 系統對”應用Root” 權限管理越來越嚴格，所以該方案可用的范圍越來越小。

SM 指標的計算方法

根據定義，SM 其實類似於 FPS，它被設計為可以衡量應用平均每秒執行 doFrame（） 的次數。我們可以認為它是在衡量 Surface 渲染輪詢的次數。

針對 Logcat 方案，我們只需統計測試過程中目標進程一共掉了多少幀，由於對於絕大多數應用在沒有丟幀的情況下會針對每一次 VSYNC 信號執行一次 doFrame（），而 VSYNC 絕大多數情況下每秒會觸發 60 次，因此我們可以反向計算得出 SM 的數值：

SM = (60* totalSeconds - totalSkippedFrames) / totalSeconds;

針對 Choreographer.FrameCallback 方案 以及 代碼注入方案，我們需要在代碼中自己進行統計輸出（可以是設計成實時的，也可以設計成測試結束後進行統計計算的）。

Skipped frames 指標的計算方法

這個指標的就是指當前應用在丟幀發生時的丟幀幀數。

針對 Logcat 方案， 該數值直接在 Logcat 中輸出，並且帶有時間信息。

04-18 16:31:24.957 I/Choreographer(24164): Skipped 4 frames!  The application may be doing too much work on its main thread.
04-18 16:31:25.009 I/Choreographer(24164): Skipped 2 frames!  The application may be doing too much work on its main thread.

針對 Choreographer.FrameCallback 方案 以及 代碼注入方案，我們可能很方便的通過計算前後兩幀開始渲染的時間差獲得這一數值，同樣方便。同樣與 Logcat 方案 不同的是，它也是可以設計成實時計算的。

小結

通過對各個顯示性能指標的分析，我們可以知道，雖然目前指標眾多，但其實有本質區別的指標確很少：

更為重要的是，我們從上述的分析中知道了各個指標都有著自己的優勢和不足，這也從根本上決定了它們各自有各自的用法。

Step 3：你要到哪兒去——這些指標如何落地來指導優化

其實指標的用法也是多種多樣的，為了方便討論，我們僅從日常監控、缺陷定位以及數據上報三個方面來討論各個顯示性能指標是如何落地的。

日常監控

特別說明：Jankiness count、Max accumulated frames、Frame rate 只統計了128幀的信息（約2~3秒），而且 Jankiness count、Max accumulated frames對於掉幀情況的計算並非是一個准確值，因此這些指標都不太適用於日常監控

舉個栗子，筆者服務的某個產品使用如下的一些指標來監控產品與競品的性能變化情況：

備注：
1. Num of x+ Skipped Frames 代表測試過程中發生連續丟 x 幀（及以上）的次數;
2. 至於為什麼我們選擇關注連續丟 3 幀以及連續丟 6 幀的的次數，在【缺陷定位】部分有相關的分析討論；

缺陷定位

特別說明：
1. FrameInfo 相關指標無法直接進行缺陷定位，但 FrameInfo 當中包含了大量詳盡的繪制基礎數據，對於缺陷定位也有較大幫助；
2. 關於缺陷定位過程中連續掉幀阈值的選取，可參考維基百科中提到幾個重要的幀率數值：
- 12 fps：由於人類眼睛的特殊生理結構，如果所看畫面之幀率高於每秒約10-12幀的時候，就會認為是連貫的
- 24 fps：有聲電影的拍攝及播放幀率均為每秒24幀，對一般人而言已算可接受
- 30 fps：早期的高動態電子游戲，幀率少於每秒30幀的話就會顯得不連貫，這是因為沒有動態模糊使流暢度降低
- 60 fps：在實際體驗中，60幀相對於30幀有著更好的體驗

以上各數據分別對應： 0 幀、1幀、2.5幀、5~6幀。（這就是為啥選擇3/6的原因）

舉個栗子， 筆者的同事萬大師（yuwan）基於上述原理自研了一款性能分析工具。該工具在集成於待測應用之後，可以自動保存如下的性能缺陷信息：

Frame lost：... （連續丟幀數量，一般我們會設定一個阈值，例如 6 幀以上我們才會進行記錄）
User action：...（當前用戶操作）
Stack trace： ...（當前堆棧信息）

有了這個工具之後，我們可以收集應用的各個潛在“卡頓”點，用於進一步的分析和優化。

數據上報

這方面應用，筆者所服務的產品暫時沒有涉及，就不舉例子了。如果各位觀眾感興趣，建議參考 Android ANR 的設計理念。

小結

發現了沒有 Skipped frames 的用處很大有沒有？ 而且通讀全篇，你會發現 Aggregate frame stats、Jankiness count、Max accumulated frames 這些指標都有提供類似的功能。

友情附贈： 現有顯示性能指標對比

本來寫到這裡本文的主要內容就應該結束了。但是如果不對比一下顯示性能指標神馬的，總會讓人覺得缺少了一些什麼。

友情提示：下述內容相對主觀，建議各位讀者依據項目情況自行進行選擇。