參考文檔：
本文記錄一下關於圖像的深入學習過程，想來工作也有兩年有餘了，期間也寫過不少的自定義View，熟絡的也僅僅是Api的調用以及對應Java層的調用邏輯，對於native層的源碼也是淺嘗輒止，沒有細細研究過，今天抽空看了一下官方文檔，關於圖像這一塊的內容還是蠻多的，這裏就下決心研究一下吧，關於圖像這一塊，涉及的比較多，如SurfaceFlinger，Vsync同步信號，硬件加速等等，希望能堅持把文章寫完吧。
首先這裏先做個總述吧，這裏使用的基本上是官網上的解釋以及圖片，做個知識的搬運工。如果能夠翻牆的同學可以直接在官網看即可，無需查看下面內容。
前言
對於圖像的顯示，日常中經常接觸到的控件就是顯示圖像的一部分，包括TextView，Button，RecyclerView等等所有的控件建立在Canvas上顯示成像，在深入一點的可以使用opengl es來進行繪製。這兩種方式就是Android提供給我們的在可操作層次上的Api。下面對Canvas以及Opengl做個介紹：
- Canvas是一個 2D 圖形 API，Canvas 運算可在 Android 中繪製所有原生和自定義 android.view.View。在 Android 中，Canvas API 通過一個名爲 OpenGLRenderer 的繪製庫實現硬件加速，該繪製庫將 Canvas 運算轉換爲 OpenGL 運算，以便它們可以在 GPU 上執行。從 Android 4.0 開始，硬件加速的 Canvas 默認情況下處於啓用狀態。
- Opengl es爲Opengl的閹割版，由於移動設備跟PC的硬件差異，導致了 Opengl es的出現。開發者渲染圖形的另一個主要方式是使用 OpenGL ES 直接渲染到 Surface。Android 會在 Android.opengl 軟件包中提供 OpenGL ES 接口，開發者可以使用這些接口通過 SDK 或原生 API（在 Android NDK 中提供）來調用其 GL 實現。
Android 圖形組件
無論開發者使用什麼渲染 API，一切內容都會渲染到“Surface”。Surface 表示緩衝隊列中的生產方，而緩衝隊列通常會被 SurfaceFlinger 消耗。在 Android 平臺上創建的每個窗口都由 Surface 提供支持。所有被渲染的可見 Surface 都被 SurfaceFlinger 合成到顯示部分。
下面展示關鍵組件的協同工作內容：
Image Stream Producers
圖像流生產者可以是生成圖形緩衝區以供消耗的任何內容，如 OpenGL ES、Canvas 2D 和 mediaserver 視頻Decoder。
Window Manager
Window Manager控制窗口的 Android 系統服務，它是視圖容器。窗口總是由 Surface 提供支持。該服務會監督生命週期、輸入和聚焦事件、屏幕方向、轉換、動畫、位置、變形、Z-Order 以及窗口的其他許多方面。窗口管理器會將所有窗口元數據發送到 SurfaceFlinger，以便 SurfaceFlinger 可以使用該數據在顯示部分合成 Surface。
Image Stream Consumers
最常見的圖像流消費者就是SurfaceFlinger，系統服務會消費當前可見的Surfaces並且結合WindowManager所提供的信息一起合成展示到顯示中。SurfaceFlinger 是可以修改所顯示部分內容的唯一服務。SurfaceFlinger 使用 OpenGL 和 Hardware Composer 來合成一組 Surface。
Hardware Composer
這裏我也有點懵逼，先原文寫上吧
The hardware abstraction for the display subsystem. SurfaceFlinger can delegate certain composition work to the Hardware Composer to offload work from OpenGL and the GPU. SurfaceFlinger acts as just another OpenGL ES client. So when SurfaceFlinger is actively compositing one buffer or two into a third, for instance, it is using OpenGL ES. This makes compositing lower power than having the GPU conduct all computation.
The Hardware Composer HAL conducts the other half of the work and is the central point for all Android graphics rendering. The Hardware Composer must support events, one of which is VSYNC (another is hotplug for plug-and-playHDMI support).
Hardware Composer翻譯成硬件混合渲染器，是顯示圖像子系統( display subsystem)的硬件抽象實現。SurfaceFlinger 可以將某些合成工作委託給 Hardware Composer，以分擔 OpenGL 和 GPU 上的工作量。因此，在 SurfaceFlinger 將一個或兩個緩衝區合成到第三個緩衝區中的過程中，它會使用 OpenGL ES。這樣使合成的功耗比通過 GPU 執行所有計算更低。
Hardware Composer HAL 則進行另一半的工作，並且是所有 Android 圖形渲染的核心。Hardware Composer 必須支持事件，其中之一是 VSYNC（另一個是支持即插即用 HDMI 的熱插拔）。
** Gralloc **
Gralloc是需要使用圖形內存分配器 (Gralloc) 來分配圖像生產方請求的內存。
數據流
下圖爲Android圖形管道的描述：
左側的對象是生成圖形緩衝區的渲染器，如主屏幕、狀態欄和系統界面。SurfaceFlinger 是合成器，而硬件混合渲染器是製作器。
BufferQueue
BufferQueues 是 Android 圖形組件之間的粘合劑。它們是一對隊列(注意是一對)，可以調解緩衝區從生產方到消耗方的固定週期。一旦生產方移交其緩衝區，SurfaceFlinger 便會負責將所有內容合成到顯示部分(硬件顯示，即手機屏幕)。
BufferQueue 通信過程如下圖：
BufferQueue 包含將圖像流生產方與圖像流消耗方結合在一起的邏輯。
BufferQueue 是將緩衝區池與隊列相結合的數據結構，它使用 Binder IPC 在進程之間傳遞緩衝區。生產方接口爲 IGraphicBufferProducer（SurfaceTexture 的一部分）。BufferQueue 通常用於渲染到 Surface，並且與 GL 消耗方及其他任務一起消耗內容。BufferQueue 可以在三種不同的模式下運行：
類同步模式 - 默認情況下，BufferQueue 在類同步模式下運行，在該模式下，從生產方進入的每個緩衝區都在消耗方那退出。在此模式下不會捨棄任何緩衝區。如果生產方速度太快，創建緩衝區的速度比消耗緩衝區的速度更快，它將阻塞並等待可用的緩衝區。
非阻塞模式 - BufferQueue 還可以在非阻塞模式下運行，在此類情況下，它會生成錯誤，而不是等待緩衝區。在此模式下也不會捨棄緩衝區。這有助於避免可能不瞭解圖形框架的複雜依賴項的應用軟件出現潛在死鎖現象。
捨棄模式 - 最後，BufferQueue 可以配置爲丟棄舊緩衝區，而不是生成錯誤或進行等待。例如，如果對紋理視圖執行 GL 渲染並儘快繪製，則必須丟棄緩衝區。
爲了執行這項工作的大部分環節，SurfaceFlinger 就像另一個 OpenGL ES 客戶端一樣工作。例如，當 SurfaceFlinger 正在積極地將一個緩衝區或兩個緩衝區合成到第三個緩衝區中時，它使用的是 OpenGL ES。
Hardware Composer HAL 執行另一半工作。該 HAL 充當所有 Android 圖形渲染的中心點。
同步框架
同步框架明確描述了系統中不同異步操作之間的依賴關係。框架提供了一個簡單 API，使組件在緩衝區被釋放時發出信號。它還允許在從內核到用戶空間的驅動程序之間以及用戶空間進程本身之間傳遞同步基元。例如，應用可以將要在 GPU 中執行的工作加入隊列。然後，GPU 開始繪製該圖像。儘管圖像尚未被繪製到內存中，但緩衝區指針仍然可以與指示 GPU 工作何時完成的柵欄一起傳遞到窗口合成器。然後，窗口合成器可以提前開始處理，並將工作移交給顯示控制器。通過這種方式，CPU 工作可以提前完成。GPU 完成後，顯示控制器就可以立即顯示圖像。