原文：https://source.android.com/devices/graphics/index.html

Android框架提供了各種2D/3D圖形渲染API,負(fù)責(zé)與廠商實(shí)現(xiàn)的圖形驅(qū)動(dòng)來交互，因此深入理解這些API如何在更高層次上工作非常重要。本頁介紹了圖形硬件抽象層。

應(yīng)用開發(fā)者有兩種方法來繪圖：Canvas，OPENGL。請(qǐng)參考 圖形架構(gòu) 詳細(xì)了解android圖形組件。

android.graphics.Canvas 是最流行的2D圖形API。Canvas操作 在Android中繪制所有的原生和定制的View對(duì)象（ android.view.View）。在Android中，繪圖庫OpenGL 負(fù)責(zé) CanvasAPI的硬件加速，將Canvas 操作轉(zhuǎn)換為OpenGL操作以便在GPU上執(zhí)行。

從Android4.0開始，Canvas的硬件加速是默認(rèn)打開的，這導(dǎo)致GPU硬件必須支持OpenGL ES2.0。Hardware Accerleration Guide enter link description here 解釋了硬件加速繪圖路徑的工作原理，以及軟件繪圖路徑的區(qū)別。

對(duì)于Canvas，開發(fā)者 渲染圖形的另外一種主要方法是 使用OpenGL ES直接渲染 surface 實(shí)例。在android.opengl包中，android提供了OpenGL ES接口，開發(fā)者可以用來調(diào)用他們自己SDK 的GL實(shí)現(xiàn),或者AndroidNDK提供的本地API。

Android 可以使用deqp（drawElements Quality Program）來實(shí)測(cè)OpenGL ES功能。

圖形組件

不管開發(fā)者使用何種渲染API，最終所有的東東渲染到某個(gè)“surface”上。surface 代表了生產(chǎn)者側(cè)的一個(gè)buffer queue，通常其消費(fèi)者是SurfaceFlinger。Android平臺(tái)上所有的窗口，背后都有一個(gè)surface。所有可見的surface，由SurfaceFlinger合成到顯示上。

下圖展示了關(guān)鍵的圖形組件：

Figure 1. How surfaces are rendered

下面介紹了主要圖形組件

生產(chǎn)者（Image Stream Producers）

只要能夠產(chǎn)生圖形緩沖以供消費(fèi)的東東都可以稱為 生產(chǎn)者，例如：OpenGL ES，Canvas 2D, 媒體服務(wù)中的視頻解碼器。

消費(fèi)者（Image Stream Consumers）

圖像流的最常見的消費(fèi)者是SurfaceFlinger。該系統(tǒng)服務(wù)器負(fù)責(zé)消費(fèi)當(dāng)前可見的surfaces。SurfaceFlinger是唯一的可以修改顯示內(nèi)容的服務(wù)，使用OpenGL和硬件合成器，根據(jù)WindowsManager提供的信息，將這些surfaces合成到顯示上。

其他OpenGL ES應(yīng)用也可以消費(fèi)圖像流，例如，camera應(yīng)用消費(fèi)camera預(yù)覽圖像流。非OpenGL應(yīng)用也可能hi消費(fèi)者，例如，ImageRader Class。

窗口管理器（Window Manager）

該系統(tǒng)服務(wù)負(fù)責(zé)控制窗口，而窗口是views的容器。一個(gè)windows后面總是存在一個(gè)surface。WM服務(wù)監(jiān)視 生命周期、輸入和焦點(diǎn)事件、屏幕方向、透明度、動(dòng)畫、位置、變形、z-order以及window的其他很多方面。WM 將所有的窗口的元數(shù)據(jù)發(fā)送到SurfaceFlinger，以便SurfaceFlinger使用這些數(shù)據(jù)來合成顯示。

硬件合成器（Hardware Composer ）

硬件合成器是顯示子系統(tǒng)的硬件抽象。SurfaceFlinger可以將某些合成操作委托給硬件合成器，以降低OpenGL和GPU的負(fù)載。執(zhí)行這種工作時(shí)，SurfaceFlinger表現(xiàn)得如同另外一種OpenGL ES客戶端。因此當(dāng)SurfaceFlinger 合成一塊或者兩塊緩沖區(qū)到第三塊緩沖區(qū)時(shí)，舉例來說，他將使用OpenGL ES。 與全程使用GPU來完成所有計(jì)算相比，硬件合成器做合成工作耗能更低。（WHY？）

硬件合成器HAL 執(zhí)行另一半工作。該HAL是所有Android圖形渲染的中心。硬件合成器必須支持事件，其中之一是VSYNC，以及熱插拔（hotplug）事件（用以支持HDMI即插即用）。

Gralloc

Gralloc是專用的圖形內(nèi)存分配器，用于向生產(chǎn)者分配內(nèi)存。詳情請(qǐng)見 Gralloc HAL。

Data Flow

下圖描繪了Android圖形管線：

左側(cè)的對(duì)象就是生產(chǎn)圖形緩沖的渲染器，如主屏、狀態(tài)條和系統(tǒng)UI。SurfaceFlinger是排序器（合成師），而硬件合成器HC 是合成器。

BufferQueue

BufferQueue 是Android圖形組件間的膠合劑。These are a pair of queues that mediate the constant cycle of buffers from the producer to the consumer. 一對(duì)隊(duì)列負(fù)責(zé)調(diào)和生產(chǎn)者到消費(fèi)者之間的常數(shù)周期的多個(gè)緩沖區(qū)。一旦生產(chǎn)者交出了緩沖區(qū)，SurfaceFlinger將負(fù)責(zé)合成所有的一切到顯示上。

下圖展示了BufferQueue通信過程：

BufferQueue將生產(chǎn)者和消費(fèi)者結(jié)合在一起。一些例子中，某些生產(chǎn)者是相機(jī)預(yù)覽，由camera HAL或者OpenGL ES游戲產(chǎn)生。另外一些例子中，消費(fèi)者是SurfaceFlinger 或者顯示OpenGL ES流的其他應(yīng)用，例如cameraAPP 顯示 camera viewfinder。

BufferQueue數(shù)據(jù)結(jié)構(gòu)中，包含了一個(gè)緩沖區(qū)池、一個(gè)隊(duì)列，并使用Binder在進(jìn)程間傳遞緩沖區(qū)。生產(chǎn)者接口IGraphicBufferProducer  是SurfaceTexture的一部分，你可以傳遞給希望產(chǎn)生圖形緩沖區(qū)的接收者。BufferQueue經(jīng)常用于：渲染到一個(gè)surface上，然后使用一個(gè)GL consumer來配合其他任務(wù)來消費(fèi) 。

BufferQueue有是那種不同的操作模式：

1. 同步模式（Synchronous-like Mode）。默認(rèn)模式，每個(gè)緩沖區(qū) 在生產(chǎn)者中 引入（分配），然后在消費(fèi)者中 離場(chǎng)（回收）。該模式中，沒有緩沖區(qū)被丟棄。如果生產(chǎn)者過快了，創(chuàng)建緩沖區(qū)的速度快于被消耗的速度，生產(chǎn)者必須阻塞以等待空閑緩沖區(qū)。


2. 非阻塞模式（Non-blocking Mode）。在該模式中，同樣不會(huì)丟棄緩沖區(qū)，但如果生產(chǎn)者過快，將產(chǎn)生一個(gè)錯(cuò)誤而不是阻塞。這對(duì)避免應(yīng)用軟件中潛在的死鎖非常有用，因?yàn)閼?yīng)用可能不太了解圖形框架復(fù)雜的依賴關(guān)系。


3. 丟棄模式（Discard Mode）。過快是，緩沖區(qū)被丟棄，沒錯(cuò)誤也不阻塞。For instance, if conducting GL rendering to a texture view and drawing as quickly as possible, buffers must be dropped.

執(zhí)行大部分這種工作時(shí)，SurfaceFlinger表現(xiàn)得如同另外一種OpenGL ES客戶端。因此當(dāng)SurfaceFlinger 合成一塊或者兩塊緩沖區(qū)到第三塊緩沖區(qū)時(shí)，舉例來說，他將使用OpenGL ES。

硬件合成器HAL 執(zhí)行（剩下）另一半工作。該HAL是所有Android圖形渲染的中心。

Synchronization framework

既然Android圖形框架提供不了顯式并行，供應(yīng)商 在他們自己的驅(qū)動(dòng)中實(shí)現(xiàn)了自己的隱式同步。因此Android圖形同步框架就不需要了。  Explicit synchronization 這一節(jié)有實(shí)現(xiàn)要求。

The synchronization framework explicitly describes dependencies between different asynchronous operations in the system. The framework provides a simple API that lets components signal when buffers are released. It also allows synchronization primitives to be passed between drivers from the kernel to userspace and between userspace processes themselves.

同步框架顯式描述了 系統(tǒng)中不同異步操作間的依賴關(guān)系。框架提供了一個(gè)簡單的API，當(dāng)緩沖區(qū)釋放時(shí) 讓組件發(fā)送一個(gè)信號(hào)；它也容許同步原語在驅(qū)動(dòng)間傳遞（從內(nèi)核到用戶空間），以及在用戶進(jìn)程間傳遞。

For example, an application may queue up work to be carried out in the GPU. The GPU then starts drawing that image. Although the image hasn’t been drawn into memory yet, the buffer pointer can still be passed to the window compositor along with a fence that indicates when the GPU work will be finished. The window compositor may then start processing ahead of time and hand off the work to the display controller. In this manner, the CPU work can be done ahead of time. Once the GPU finishes, the display controller can immediately display the image.

例如，一個(gè)應(yīng)用可能將工作排隊(duì)到GPU上。GPU稍后執(zhí)行繪圖。盡管圖像還沒有被繪制到內(nèi)存中，緩沖區(qū)指針就已經(jīng)可以被傳遞到window 排序器中，伴隨一個(gè)指示GPU工作完成的屏障（fence）。windows排序器 可能開始提前處理，將工作交付給顯示控制器。按照這種方式，CPU的工作可以提前完成；一旦GPU的工作完成，顯示控制器可以馬上顯示圖像。

同步框架也容許實(shí)現(xiàn)者影響他們自己的硬件組件中的同步資源。最后，為調(diào)試之用，框架提供了可視化到圖形管線的功能。