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系統中的開機動畫