Android framework 為2D 和 3D 提供了各種各樣的圖形渲染 APIs 來與設備制造商的圖形驅動實現交互，因此對于那些 API 在上層如何工作有一個好的理解非常重要。這一頁介紹驅動基于其構建的圖形硬件抽象層 (HAL)。

應用程序開發者以兩種方式將圖像繪制到屏幕上：通過 Canvas 或 OpenGL。參考 系統級圖形架構 來了解 Android 圖形組件的詳細描述。

android.graphics.Canvas 是一個 2D 圖形 API，且是開發者中最流行的圖形 API。Canvas 操作在 Android 中繪制所有的 stock 和 custom android.view.Views。在 Android 中，Canvas APIs 的硬件加速通過稱為 OpenGLRenderer 的繪圖庫來完成，它將 Canvas 操作轉換為 OpenGL 操作，以使它們可以在 GPU 上執行。

自 Android 4.0 開始，硬件加速的 Canvas 是默認開啟的。因此，對于 Android 4.0 及更新的設備，支持 OpenGL ES 2.0 的應該 GPU 是必須的。參考 硬件加速指南 來了解硬件加速繪制路徑如何工作，以及它與軟件繪制路徑之間在行為上的不同。

除了 Canvas，開發者渲染圖形的另外一個主要方式是使用 OpenGL ES 直接渲染到一個 surface。Android 在 android.opengl 包中提供了 OpenGL ES 接口，開發者可以使用 SDK 或
Android NDK 中提供的本地層 APIs 來調用他們的 GL 實現。

Android 實現者可以使用 drawElements Quality Program，也稱為 deqp 測試 OpenGL ES 功能。

Android 圖形組件

無論開發者使用什么渲染 API，所有的東西都是在一個 "surface" 上渲染的。surface 表示一個 buffer queue 的生產者端，而 buffer queue 常常由 SurfaceFlinger 消費。Android 平臺上創建的每個窗口都是由一個 surface 支持的。所有可見的 surfaces 渲染由 SurfaceFlinger 組合到顯示設備上。

下面的圖展示了關鍵組件如何一起工作：

ape_fwk_graphics.png

圖 1. surfaces 如何渲染

主要的組件在下面描述：

圖像流生產者

圖像流生產者可以是為消費生產圖形 buffers 的任何東西。例子包括 OpenGL ES，Canvas 2D，和 mediaserver 視頻解碼器。

圖像流消費者

最常見的圖形流消費者是 SurfaceFlinger，消費當前可見的 surfaces 并使用
Window Manager 提供的信息將它們組合到顯示設備上的系統服務。SurfaceFlinger 是僅有的可以修改顯示設備內容的服務。SurfaceFlinger 使用 OpenGL 和 Hardware Composer 組合一組 surfaces。

其它的 OpenGL ES 應用也可以消費圖像流，比如 camera 應用消費一個 camera 預覽圖像流。非 GL 應用也可以是消費者，比如 ImageReader 類。

Window Manager

控制窗口的 Android 系統服務，窗口是 views 的容器。一個窗口總是由一個 surface 支持的。這個服務監督生命周期，輸入和焦點事件，屏幕分辨率，過渡，動畫，位置，轉換，z-order，和一個窗口的許多其它方面。Window Manager 發送所有的 window metadata 給 SurfaceFlinger，以使 SurfaceFlinger 可以使用那些數據在顯示設備上組合 surface。

Hardware Composer

顯示子系統的硬件抽象。SurfaceFlinger 將某些組合工作委托給 Hardware Composer，來從 OpenGL 和 GPU 卸載工作。SurfaceFlinger 只是扮演了另一個 OpenGL 客戶端的角色。因此當 SurfaceFlinger 正在活躍地組合一個 buffer 或兩個到第三個時，比如，它正在使用 OpenGL ES。相對于讓 GPU 主導所有的計算，這使組合工作的功耗更低。

Hardware Composer HAL 執行另一半工作，且是所有 Android 圖形渲染的中心點。Hardware Composer 必須支持事件，其中一個是 VSYNC（另一個是 plug-and-playHDMI 支持的 hotplug）。

Gralloc

圖形內存分配器 (Gralloc) 用來分配圖像生產者請求的內存。更多詳情，請參考 Gralloc HAL。

數據流

參看下圖來獲得 Android 圖形流水線的描述：

圖 2. Android 中的圖形數據流

左邊的對象是渲染器生產圖形 buffers，比如 home screen，狀態欄，system UI。SurfaceFlinger 是制圖者，Hardware Composer 是合成器。

BufferQueue

BufferQueues 提供了 Android 圖形組件之間的膠水。有一對隊列中轉從生產者到消費者的固定的循環緩沖區。一旦生產者切換了它們的 buffers，SurfaceFlinger 負責將所有的東西合成到顯示設備上。

參考下面的圖來了解 BufferQueue 的通信過程。

圖 3. BufferQueue 的通信過程

BufferQueue 包含了將圖像流生產者和圖像流消費者綁在一起的邏輯。圖像生產者的一些例子是 camera 生產 camera 預覽或 OpenGL ES 游戲。圖像消費者的一些例子是 SurfaceFlinger 或顯示 OpenGL ES 流的另一個應用，比如 camera 應用顯示 camera viewfinder。

BufferQueue 是結合 buffer 池和一個隊列，并使用 Binder IPC 在進程間傳遞 buffers 的數據結構。生產者接口，或傳遞給想要生成圖形緩沖區的人的東西，是 IGraphicBufferProducer ( SurfaceTexture 的一部分)。BufferQueue 常常被用于渲染到一個 Surface，并用一個 GL Consumer 消費及其他任務。BufferQueue 可以三種模式操作：

同步式模式 - BufferQueue 默認以同步式模式操作，在這種模式下每個來自于生產者的 buffer 出去到消費者。這種模式下沒有 buffer 會被丟棄。且如果生產者太快，創建 buffers 的速度比消費的速度快，它將阻塞并等待釋放 buffers。

非阻塞模式 - BufferQueue也可以以非阻塞模式操作，這種模式中在那些情況下它產生一個 error 而不是等待一個 buffer。這種模式下沒有 buffer 會被丟棄。這對在那些可能不理解圖形框架的復雜依賴的應用中避免潛在的死鎖很有用。

丟棄模式 - 最后，BufferQueue 可以被配置為丟棄舊的 buffers 而不是產生 errors 或等待。比如，如果執行 GL 渲染到一個 texture view 并繪制的盡可能塊，buffers 必須被丟棄。

為了執行這些中的大部分工作，SurfaceFlinger 只是扮演了另一個 OpenGL 客戶端的角色。因此當 SurfaceFlinger 正在活躍地組合一個 buffer 或兩個到第三個時，比如，它正在使用 OpenGL ES。

Hardware Composer HAL 執行另一半工作，且是所有 Android 圖形渲染的中心點。

同步框架

由于 Android 圖形沒有提供顯式的并行，廠商一直在自己的驅動程序中實現自己的隱式同步。在 Android 圖形同步框架下不需要了。參考 Explicit synchronization 一節了解實現指導。

同步框架顯式地描述系統中不同異步操作間的依賴?？蚣芴峁┝艘粋€簡單的 API 讓組件在 buffers 釋放時發送信號。它也允許同步原語在驅動間從內核到用戶空間及用戶空間進程本身間進行傳遞。

例如，應用程序可以排隊在 GPU 中執行的工作。然后 GPU 開始繪制那幅圖。盡管圖像還沒有被畫進內存，buffer 指針依然可以伴隨著指示何時 GPU
工作將結束的柵欄傳遞給 window 合成器。然后 window 合成器可以提前開始處理，并將工作移交給顯示控制器。通過這種方式，GPU 的工作可以提前結束。一旦 GPU 結束，顯示控制器可以立即顯示圖像。

同步框架也允許實現者在它們自己的硬件組件中利用同步資源。最后，框架提供對圖形管道的可見性，以幫助調試。

原文

總結

以上是生活随笔為你收集整理的Android 图形系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。