Android GUI系統之SurfaceFlinger(7) 應用程序的典型繪圖流程

1.1.1 應用程序的典型繪圖流程

我們知道，BufferQueue有最多達32個BufferSlot，這樣設計的目的是什麼？一個可能的原因就是提高圖形渲染速度。因為假如只有兩個buffer，可以想象一下，當應用程序這個生產者的產出效率大於消費者的處理速度時，很快它就會dequeue完所有緩沖區而處於等待狀態，從而導致不必要的麻煩。當然，實際上32只是最大的容量，具體值是可以設置的，大家可以結合後面的ProjectButter小節來理解一下。

前面小節我們已經學習了BufferQueue的內部原理，那麼應用程序又是如何與之配合的呢？

解決這個疑惑的關鍵就是了解應用程序是如何執行繪圖流程的，這也是本節我們敘述的重點。不過大家應該有個心裡准備，應用程序並不會直接使用BufferQueue。和Android系統中很多其它地方一樣，“層層包裹”在這裡同樣是存在的，因而我們要盡量抓住其中的重點，並輔以一定的手段，才能更好更快地從諸多錯綜復雜的類關系中找出問題的答案。

出於以上原因的考慮，我們選取系統的開機動畫這一應用程序，來分析整個圖形繪制的流程。值得一提的是，這個開機動畫的實現符合前面提到的兩個改進的圖形系統中的第一個，即應用程序與SurfaceFlinger都是使用OpenGL ES來完成UI顯示，不過因為它是一個C++程序，所以不需要上層GLSurfaceView的支持。

當一個Android設備上電後，正常情況下它會先後顯示最多4個不一樣的開機畫面，分別是：

l  boot-loader

這顯然是第一個出現的畫面。因為boot-loader只是負責系統後續模塊的加載與啟動，而且要求文件體積很小，所以一般我們只讓它顯示一張靜態的圖片

l  kernel

在進入內核後，同樣會在物理屏幕上有所顯示。和boot-loader一樣，默認情況下它也只是一張靜態圖片

l  android(2個)

Android是系統啟動的最後一個階段，也是最耗時間的一個。它的開機畫面既可以是靜態文字描述、靜態圖片，也可以是動態畫面。通常第一個是文字或者靜態圖片(假如指定路徑下的圖片不存在的話，就顯示文字。關於這方面的資料很多，大家可以自行查閱，我們這裡不作過多敘述)，另外一個則是動畫，如下圖所示：

圖 11?14 原生態Android系統中的開機動畫