幀率:壹秒鐘內GPU繪制的幀數。
雖然有廠商推出了高刷新率的手機，但主流還是60Hz，也就是1秒顯示60幀，1000 ms/60幀≈16.67 ms/幀。為了保證App的流暢度，要盡量做到每壹幀的繪制時間不超過16 ms。
Android的顯示過程可以簡單概括為:應用程序緩存測量、布局、繪制後的曲面數據，通過SurfaceFlinger將數據渲染到顯示屏上，通過Android的刷新機制刷新數據。換句話說，應用層負責畫圖，系統層負責渲染。應用層需要繪制的數據通過進程間通信傳遞給系統層服務，系統層通過刷新機制將數據更新到屏幕。
以下是對相關概念的解釋:
在Android中，將對每個視圖進行測量和布局，以確定其大小和位置，然後繪制到表面(緩沖區)，這是由ViewRootImpl類中的performTraversals()方法啟動的。
Android支持兩種繪制方式:和。從Android 3.0開始就支持硬件極速。在UI顯示和繪制上比軟件繪制效率高很多，但也有缺點:
經過多次繪制後，將與要顯示的視圖相關的數據(如大小、位置等)存儲在Surface的緩沖區中，然後由系統進程中的SurfaceFlinger服務完成渲染操作，這是壹個IPC(進程間通信)進程。SurfaceFlinger的主要工作流程如下:
當Android應用層在圖形緩沖區中繪制視圖層次結時，應用層通過Binder機制與SurfaceFlinger通信，並借助匿名內存將圖形緩沖區交給SurfaceFlinger服務。由於缺乏對多窗口傳輸數據的有效管理，匿名* * *共享內存被抽象為壹種更高級的數據結構——shared client。在共享客戶端中，最多有365，438+0個SharedBufferStacks，每個共享緩沖棧對應壹個面，也就是壹個窗口。這說明壹個Android應用最多可以包含31個窗口。
在繪圖過程中，CPU準備數據(測量、布局等。)，GPU負責柵格化和渲染。因為圖像API不允許CPU和GPU直接通信，所以需要通過壹個圖形驅動的中間層來連接。在圖形驅動程序中維護壹個隊列。CPU將顯示列表(要顯示的數據列表)添加到隊列中，GPU從隊列中提取數據並最終顯示在屏幕上，如下圖所示:
Android系統會每隔16ms發出壹個VSYNC信號，觸發UI的渲染。如果每次渲染成功，可以達到流暢畫面所需的60PS。
Double buffer，顧名思義，有兩個緩沖區(上面提到的SharedBufferStack)，即FontBuffer(也叫FrameBuffer)和BackBuffer。UI總是先在後臺緩沖區繪制，然後與字體緩沖區交換，渲染到顯示設備上，也就是說，只有當另壹個緩沖區的數據準備好了，才會通過系統調用通知顯示設備切換緩沖區。
雙緩沖機制在大多數情況下是適用的，但是如果某個環節出現問題，可能會浪費CPU資源，如下圖所示:
VSYNC類似於時鐘中斷。用垂直線分割的部分代表16 ms的時間段，正常情況下，在每個時間段內，Display顯示壹幀數據(即每秒60幀)。
上圖中，在16ms的第二段時間內，顯示器本應顯示B幀，但由於GPU仍在處理B幀，A幀被重復顯示。同時，在第二個時間段，CPU閑置，造成浪費。因為Diaplay使用的是A緩沖區(SufaceFlinger使用後不會釋放當前緩沖區，只會釋放舊緩沖區)，GPU使用的是B緩沖區，這是雙緩沖機制的限制。
Android 4.1版本對Android顯示系統進行了重構，引入了三個核心元素:
第二次16ms，CPU使用C緩沖區繪制。雖然A幀還是會再顯示壹次，但是後續的顯示要比雙緩沖機制流暢很多。但是，緩沖區越多越好。從上圖可以看出，在第二次，CPU繪制的C幀數據要到第四次16ms才會顯示，比雙緩沖多了16ms的延遲。因此，雙緩沖確保低延遲，三緩沖確保穩定性。
整個過程簡單來說就是CPU/GPU會接收到VSYNC信號，觸發UI的渲染(每16ms顯示壹幀)。在16ms中，需要完成兩項任務:將UI對象轉換成壹系列多邊形和紋理(光柵化)以及CPU將處理數據傳輸到GPU。更多詳情請看本文，Android的16ms，垂直同步和三重緩存。
了解了安卓畫圖流程，就不難推導出安卓應用卡頓的原因了: