Android 框架提供了各種用於 2D 和 3D 的圖形渲染 API,它們與圖形驅動程式的製造商實作進行交互,因此深入了解這些 API 如何在更高層級上運作非常重要。本頁介紹了這些驅動程式所基於的圖形硬體抽象層 (HAL)。在繼續本部分之前,請先熟悉以下術語:
Canvas
(API元素)Surface
物件的合成。 Canvas
具有用於點陣圖、直線、圓形、矩形、文字等的標準電腦繪圖的方法,並且綁定到位圖或表面。畫布是在螢幕上繪製 2D 物件的最簡單、最容易的方法。基底類別是Canvas
。android.graphics.drawable
的子類別。有關可繪製物件和其他資源的更多信息,請參閱資源。android.opengl
和javax.microedition.khronos.opengles
套件公開 OpenGL ES 功能。Surface
(API 元素)Surface
物件的大小。使用SurfaceView
類別而不是直接使用Surface
類別。SurfaceView
(API元素)View
對象,它包裝了用於繪圖的Surface
對象,並公開了動態指定其大小和格式的方法。表面視圖提供了一種獨立於 UI 執行緒進行繪製的方法,用於資源密集型操作(例如遊戲或相機預覽),但它會因此使用額外的記憶體。表面視圖支援畫布和 OpenGL ES 圖形。 SurfaceView
物件的基底類別是SurfaceView
。R.style
中列出並以Theme_
開頭。View
(API 元素)View
類別是活動或對話方塊畫面的大多數版面配置元件(例如文字方塊和視窗)的基底類別。 View
物件接收來自其父物件(請參閱ViewGroup
)的呼叫以繪製自身,並通知其父物件有關其首選大小和位置,這可能不受父物件的尊重。有關詳細信息,請參閱View
。ViewGroup
(API 元素)widget
包中,但擴展了ViewGroup
類別。android.widget
包中。Window
(API 元素)Window
抽象類別派生的對象,它指定通用視窗的元素,例如外觀、標題列文字以及選單的位置和內容。對話框和活動使用Window
類別的實作來呈現Window
物件。您不需要在應用程式中實作Window
類別或使用視窗。應用程式開發人員透過三種方式將影像繪製到螢幕上:使用Canvas 、 OpenGL ES或Vulkan 。
Android圖形元件
無論開發人員使用什麼渲染 API,所有內容都會渲染到表面上。 Surface 表示通常由 SurfaceFlinger 消耗的緩衝區佇列的生產者端。在 Android 平台上建立的每個視窗都有一個表面支援。渲染的所有可見表面均由 SurfaceFlinger 合成到顯示器上。
下圖顯示了關鍵組件如何協同工作:
主要組成部分說明如下:
影像流生產者
影像流產生器可以是任何產生圖形緩衝區以供使用的東西。範例包括 OpenGL ES、Canvas 2D 和媒體伺服器視訊解碼器。
影像流消費者
影像流最常見的使用者是 SurfaceFlinger,該系統服務使用目前可見的表面並使用視窗管理器提供的資訊將它們合成到顯示器上。 SurfaceFlinger 是唯一可以修改顯示內容的服務。 SurfaceFlinger 使用 OpenGL 和 Hardware Composer 來組成一組表面。
其他 OpenGL ES 應用程式也可以使用影像串流,例如使用相機預覽影像流的相機應用程式。非 GL 應用程式也可以是消費者,例如 ImageReader 類別。
硬體作曲家
顯示子系統的硬體抽象化。 SurfaceFlinger 可以將某些合成工作委託給 Hardware Composer,以卸載 OpenGL 和 GPU 的工作。 SurfaceFlinger 充當另一個 OpenGL ES 用戶端。因此,例如,當 SurfaceFlinger 主動將一個或兩個緩衝區合成到第三個緩衝區時,它正在使用 OpenGL ES。這使得合成比讓 GPU 執行所有運算的功耗更低。
Hardware Composer HAL執行另一半工作,是所有 Android 圖形渲染的中心點。 Hardware Composer 必須支援事件,其中之一是 VSYNC(另一個是用於即插即用 HDMI 支援的熱插拔)。
格拉洛克
需要圖形記憶體分配器 (Gralloc) 來分配影像產生器請求的記憶體。有關詳細信息,請參閱Gralloc HAL 。
資料流
請參考下圖了解 Android 圖形管道的描述:
左側的物件是產生圖形緩衝區的渲染器,例如主畫面、狀態列和系統 UI。 SurfaceFlinger 是合成器,Hardware Composer 是合成器。
緩衝佇列
BufferQueues 提供了 Android 圖形組件之間的黏合劑。這是一對隊列,負責協調從生產者到消費者的緩衝區恆定循環。一旦生產者交出緩衝區,SurfaceFlinger 就負責將所有內容合成到顯示器上。
BufferQueue通訊流程見下圖。
BufferQueue 包含將圖像流生產者和圖像流消費者連結在一起的邏輯。影像產生器的一些範例是由相機 HAL 或 OpenGL ES 遊戲產生的相機預覽。影像使用者的一些範例是 SurfaceFlinger 或其他顯示 OpenGL ES 串流的應用程序,例如顯示相機取景器的相機應用程式。
BufferQueue是一種將緩衝池與佇列結合的資料結構,並使用Binder IPC在進程之間傳遞緩衝區。生產者接口,或您傳遞給想要產生圖形緩衝區的人的接口,是 IGraphicBufferProducer ( SurfaceTexture的一部分)。 BufferQueue 通常用於渲染 Surface 並使用 GL Consumer 進行消費等任務。
BufferQueue 可以以三種不同的模式運作:
類別同步模式- BufferQueue 預設以類別同步模式運行,其中來自生產者的每個緩衝區都會從消費者處出去。在此模式下不會丟棄任何緩衝區。如果生產者速度太快且創建緩衝區的速度比耗盡緩衝區的速度快,它將阻塞並等待空閒緩衝區。
非阻塞模式- BufferQueue 也可以在非阻塞模式下運行,在這些情況下它會產生錯誤而不是等待緩衝區。在這種模式下也不會丟棄任何緩衝區。這對於避免可能不理解圖形框架的複雜依賴性的應用程式軟體中潛在的死鎖很有用。
丟棄模式- 最後,BufferQueue 可以配置為丟棄舊緩衝區,而不是產生錯誤或等待。例如,如果對紋理視圖進行 GL 渲染並儘快繪製,則必須刪除緩衝區。
為了執行大部分工作,SurfaceFlinger 充當另一個 OpenGL ES 用戶端。因此,例如,當 SurfaceFlinger 主動將一個或兩個緩衝區合成到第三個緩衝區時,它正在使用 OpenGL ES。
Hardware Composer HAL 執行另一半工作。該 HAL 充當所有 Android 圖形渲染的中心點。