Android圖形系統

圖形操作可以有兩種方式實現:一是利用通用CPU模擬圖形操作;二是利用GPU專門做圖形操作。前者會增加CPU的負擔,在現在高分辨率已經是普遍現象的時候,讓通用處理器來完成大量的圖形計算已經不現實。Android圖形系統的發展過程也驗證了這一觀點。

爲了達到高效的圖形處理效果,是必須緊密結合軟件和硬件的。這篇文章主要介紹跟Android的圖形子系統。以後可能會對這些主題進行更加深入的探討。

Android圖形系統的軟件構成

下面的示意圖,展示了Android上負責圖形處理的軟件模塊。

一個典型Android應用中各個圖形系統組件的關

GPU:

GPU專門設計用於加速圖形操作。GPU不同於CPU,它的一個設計目的就是高度的並行化,並行化是大部分圖形計算的共同特徵。

Android剛剛問世的時候,GPU還是可選的,最近發佈的版本中,GPU已經是一個必配硬件。如果系統中沒有GPU,系統使用的OpenGL ES就包含了libagl和pixelflinger,通過軟件實現OpenGL ES協議接口,有時也有硬件支持的CopyBit。但是不幸的是,Android通過軟件模擬OpenGL,並不支持OpenGL ES 2.0。現在,Android系統中的不少組件使用了OpenGL ES 2.0,比如HWUI、Renderscript、SurfaceTexture。平板電腦都有很高的分辨率,純軟件的模擬支持並不能保證圖形的填充需求,也就不能爲用戶提供流暢的UI體驗。廠商如果想製造基於ICS或者更高版本Android系統的設備,就必須具有支持OpenGL ES 2.0 的GPU。

Canvas:

畫布是應用程序用來繪製Widget或圖形等元素的地方。Froyo和Gingerbread上,畫布通過Skia來繪製。Honeycomb及以後的版本,HWUI被加入了進來,提供了GPU加速支持。在Ice Cream Sandwich及以後的版本上,HWUI缺省用於圖形的繪製。

Skia:

Skia是一組2D繪圖的API,它完全通過軟件實現。由於性能方面的原因,Skia逐漸被HWUI所替代。

HWUI

HWUI可以使UI組件使用GPU加速。HWUI是在Honeycomb中引入進來的,目的是使交互更加快速,及時響應,流暢。在大分辨率的平板電腦上,通過Skia來繪製動畫,會佔用很高的CPU資源,進而拖慢整個系統。HWUI需要支持OpenGL ES 2.0的GPU,不能通過軟件模擬。

Renderscript

Renderscript同樣也是Honeycomb引入的新的API,它的設計爲了同時解決移植和性能問題。應用程序員用Renderscript(基於C99)編寫代碼,然後一個LLVM的交叉編譯器把它編譯爲機器獨立的bit code,應用程序員再將其打包到apk中。當用戶下載apk時,設備上的編譯器(基於LLVM,位於/system/lib/libbcc.so)將bit code編譯爲目標機器上的指令。

Renderscript在Froyo和Gingerbread上也存在,但是不是公開的API。只有Android的一些wallpaper使用了它。那時它的實現也非常粗糙,功能有限。

Surface:

一個Surface對應一個屏幕外緩衝區,應用程序用來渲染窗口內容。一個遊戲程序,它可能使用OpenGL在Surface上繪製3D對象,一個普通應用程序,它可能使用Skia來繪製Widget或者文本,它也可能使用HWUI庫來啓用GPU加速。從ICS開始,Surface通過一個後端的SurfaceTexture實現,這就意味着Surface對應的不再是一個緩衝區,而是一個紋理(texture)。


Android平臺的圖形棧

SurfaceFlinger:

SurfaceFlinger是一個合成器,它管理來自於不同應用的Surface。比如,可能有許多應用同時存在,與此對應的,存在許多獨立的Surface需要被渲染。SurfaceFlinger決定屏幕上顯示的內容,那些需要被覆蓋,進行裁剪。

SurfaceFlinger使用的是OpenGL ES 1.1標準中的函數。爲什麼呢?如果使用OpenGL ES 2.0,就必須需要支持OpenGL ES 2.0的硬件GPU,這會使系統的啓動更加複雜,也會使模擬器的實現更加困難。

HW Composer:

硬件合成器是Honeycomb引入的一個HAL,SurfaceFlinger使用它,利用硬件資源來加速Surface的合成,比如3D GPU和2D的圖形引擎。

CopyBit:

CopyBit也是一個HAL。它允許使用特殊硬件來加速一些圖形操作,比如複製(blitting)。它設計的初衷是在沒有3D GPU的系統上加速軟件的渲染過程。CopyBit在ICS中被刪除了,因爲GPU已經成爲一個必備硬件,沒有必要專門設計一個加速部件。

Libagl/PixelFlinger:

libagl是一個通過軟件實現了OpenGL ES 1.0和1.1版本API的組件。它使用PixelFlinger來實現OpenGL調用。爲了加速使用PixelFlinger的渲染過程,JIT被引入了進來,稱爲CodeFling。CodeFling生成機器代碼,它急劇加速了許多類型的像素操作。

 

可以看出,Android的圖形系統在不斷的調整,目的是爲了提供更加快速流暢的UI體驗。這就是Android版本中圖形相關代碼變動很大的原因。

轉自:http://developer.mips.com/2012/04/11/learning-about-android-graphics-subsystem/


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章