如何量化Android應用的“卡”

在確定衡量指標之前，我們先來研究壹下Android的UI更新機制。

1、Android如何繪制UI？

關於Android是如何更新UI，相信已經有很多文章介紹其中的步驟以及過程，大體上可以用下圖來展示:

從圖中可以看到無論那條路走下去始終都由SurfaceFlinger來控制最後的更新。

在Android版本更新過程中，發現在Jelly Bean中Google加入了壹個Project Butter，用來解決嚴重影響Android口碑的問題之壹“UI流暢性差”的問題。而Project Butter中主要引入了三個核心元素：VSYNC(垂直同步)、Triple Buffer和Choreographer。

2、從VSYNC開始

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還在處理A區域的繪制時，不可能實現理論上的FPS60，同時也出現了丟幀(SF: Skipped Frame)情況。

為了便於理解，上圖用的是雙Buffer機制的情況，實際上Android 4.1引入了Triple Buffer，所以當雙Buffer不夠用時，Triple Buffer丟幀的情況如下圖所示。

Oh my ladygaga！

這些都把灑家看暈了！那打個比方講得通俗點吧！

VSync機制就像是壹臺轉速固定的發動機(60轉/s)。每壹轉會帶動著去做壹些UI相關的事情，但不是每壹轉都會有工作去做(就像有時在空擋，有時在D檔)。有時候因為各種阻力某壹圈工作量比較重超過了16.6ms，那麽這臺發動機這秒內就不是60轉了，當然也有可能被其他因素影響，比如給油不足(主線程裏幹的活太多)等等，就會出現轉速降低的狀況。我們把這個轉速叫做流暢度。

3、從FPS&丟幀到流暢度(SM: SMoothness)

實際上在很多Android的App中，很少有需要不斷地去繪制的場景，很多時候頁面都是靜態的。也就是會出現這樣的狀況，雖然1s中VSync的60個Loop不是每個都在做繪制的工作，FPS會比較低，但並不代表這個時候程序不流暢(如我將App放著不動，實測FPS為1)。所以FPS較低並不能代表當前App在UI上界面不流暢，而1s內VSync這個Loop運行了多少次更加能說明當前App的流暢程度。所以，下面這2個指標比FPS更能代表當前的App是否處於流暢的狀態。同樣這2個指標更加能夠量化App卡頓的程度：

a）丟幀(SF: Skipped Frame)：如上圖2所示情況應該在16.6ms完成工作卻因各種原因沒做完，占了後n個16.6ms的時間，相當於丟了n幀。

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

和丟幀相對1s內有60個Loop因為某幾次工作時間超過了16.6ms（丟幀），這樣Loop就無法運行60次（理論最大值）。

當流暢度越小的時候說明當前程序越卡頓。

4、數數：如何得到流暢度(SM: SMoothness)

接著上面的結論，如果在這樣的機制下每次Loop運行之前進行通知，記個數就好了。

很幸運我們在新的Android的那壹套機制中找到了壹個畫圖的打雜工Choreographer這個對象。根據Google的官方API文檔描述中，它是用來協調animations、input以及drawing時序的，並且每個Loop***用壹個Choreographer對象。

下圖為Choreographer的定義和結構。

結論

通過如上原理分析可以得出結論：

1. Android 4.1引入了VSync機制後，可以通過其Loop來了解當前App最高繪制能力。

固定每隔16.6ms執行壹次(這個值是壹個靜態變量，會根據系統版本不同而采用不同的值，目前測試版本是16.6ms這樣最高的刷新的幀率就控制在60FPS以內)；