轉(zhuǎn)自：https://source.android.com/devices/graphics/?hl=zh-cn
圖形
Android 框架提供了各種用于 2D 和 3D 圖形渲染的 API，可與制造商的圖形驅(qū)動(dòng)程序?qū)崿F(xiàn)方法交互，因此啼县，務(wù)必充分了解這些 API 如何在更高的級別工作钾怔。本頁介紹了在其上構(gòu)建這些驅(qū)動(dòng)程序的圖形硬件抽象層 (HAL)。
應(yīng)用開發(fā)者可通過兩種方式將圖像繪制到屏幕上：使用 Canvas 或 OpenGL。有關(guān) Android 圖形組件的詳細(xì)說明，請參閱系統(tǒng)級圖形架構(gòu)。
android.graphics.Canvas是一個(gè) 2D 圖形 API脏榆，并且是在開發(fā)者人群中最流行的圖形 API。Canvas 運(yùn)算會在 Android 中繪制所有原生和自定義android.view.View台谍。在 Android 中须喂，Canvas API 通過一個(gè)名為 OpenGLRenderer 的繪制庫實(shí)現(xiàn)硬件加速，該繪制庫將 Canvas 運(yùn)算轉(zhuǎn)換為 OpenGL 運(yùn)算趁蕊，以便它們可以在 GPU 上執(zhí)行坞生。
從 Android 4.0 開始，硬件加速的 Canvas 默認(rèn)情況下處于啟用狀態(tài)掷伙。因此是己，支持 OpenGL ES 2.0 的硬件 GPU 對于 Android 4.0 及更高版本的設(shè)備來說是強(qiáng)制要求。有關(guān)硬件加速繪制路徑的工作原理及其行為與軟件繪制路徑行為之間的差異的說明任柜，請參閱硬件加速指南卒废。
除了 Canvas，開發(fā)者渲染圖形的另一個(gè)主要方式是使用 OpenGL ES 直接渲染到 Surface宙地。Android 在Android.opengl包中提供了 OpenGL ES 接口摔认，開發(fā)者可以使用這些接口通過 SDK 或Android NDK中提供的原生 API 調(diào)用其 GL 實(shí)現(xiàn)。
Android 實(shí)現(xiàn)人員可以使用drawElements 質(zhì)量計(jì)劃（也稱為 deqp）來測試 OpenGL ES 功能宅粥。
Android 圖形組件
無論開發(fā)者使用什么渲染 API级野，一切內(nèi)容都會渲染到“Surface”。Surface 表示緩沖隊(duì)列中的生產(chǎn)方粹胯，而緩沖隊(duì)列通常會被 SurfaceFlinger 消耗。在 Android 平臺上創(chuàng)建的每個(gè)窗口都由 Surface 提供支持辰企。所有被渲染的可見 Surface 都被 SurfaceFlinger 合成到顯示部分风纠。
下圖顯示了關(guān)鍵組件如何協(xié)同工作：
圖 1.Surface 如何被渲染
主要組件如下所述：
圖像流生產(chǎn)方
圖像流生產(chǎn)方可以是生成圖形緩沖區(qū)以供消耗的任何內(nèi)容。例如 OpenGL ES牢贸、Canvas 2D 和 mediaserver 視頻解碼器竹观。
圖像流消耗方
圖像流的最常見消耗方是 SurfaceFlinger，該系統(tǒng)服務(wù)會消耗當(dāng)前可見的 Surface潜索，并使用窗口管理器中提供的信息將它們合成到顯示部分臭增。SurfaceFlinger 是可以修改顯示部分內(nèi)容的唯一服務(wù)。SurfaceFlinger 使用 OpenGL 和 Hardware Composer 來合成一組 Surface竹习。
其他 OpenGL ES 應(yīng)用也可以消耗圖像流誊抛，例如相機(jī)應(yīng)用會消耗相機(jī)預(yù)覽圖像流。非 GL 應(yīng)用也可以是消耗方整陌，例如 ImageReader 類拗窃。
窗口管理器
控制窗口的 Android 系統(tǒng)服務(wù)瞎领，它是視圖容器。窗口總是由 Surface 提供支持随夸。該服務(wù)會監(jiān)督生命周期九默、輸入和聚焦事件、屏幕方向宾毒、轉(zhuǎn)換驼修、動(dòng)畫、位置诈铛、變形乙各、Z-Order 以及窗口的其他許多方面。窗口管理器會將所有窗口元數(shù)據(jù)發(fā)送到 SurfaceFlinger癌瘾，以便 SurfaceFlinger 可以使用該數(shù)據(jù)在顯示部分合成 Surface觅丰。
硬件混合渲染器
顯示子系統(tǒng)的硬件抽象實(shí)現(xiàn)。SurfaceFlinger 可以將某些合成工作委托給 Hardware Composer妨退，以分擔(dān) OpenGL 和 GPU 上的工作量妇萄。SurfaceFlinger 只是充當(dāng)另一個(gè) OpenGL ES 客戶端。因此咬荷，在 SurfaceFlinger 將一個(gè)或兩個(gè)緩沖區(qū)合成到第三個(gè)緩沖區(qū)中的過程中冠句，它會使用 OpenGL ES。這樣使合成的功耗比通過 GPU 執(zhí)行所有計(jì)算更低幸乒。
Hardware Composer HAL則進(jìn)行另一半的工作懦底，并且是所有 Android 圖形渲染的核心。Hardware Composer 必須支持事件罕扎，其中之一是 VSYNC（另一個(gè)是支持即插即用 HDMI 的熱插拔）聚唐。
Gralloc
需要使用圖形內(nèi)存分配器 (Gralloc) 來分配圖像生產(chǎn)方請求的內(nèi)存。有關(guān)詳情腔召，請參閱Gralloc HAL杆查。
數(shù)據(jù)流
有關(guān) Android 圖形管道的描述，請參見下圖：
圖 2.流經(jīng) Android 的圖形數(shù)據(jù)流
左側(cè)的對象是生成圖形緩沖區(qū)的渲染器亲桦，如主屏幕、狀態(tài)欄和系統(tǒng)界面客峭。SurfaceFlinger 是合成器，而硬件混合渲染器是制作器抡柿。
BufferQueue
BufferQueues 是 Android 圖形組件之間的粘合劑舔琅。它們是一對隊(duì)列，可以調(diào)解緩沖區(qū)從生產(chǎn)方到消耗方的固定周期沙绝。一旦生產(chǎn)方移交其緩沖區(qū)搏明，SurfaceFlinger 便會負(fù)責(zé)將所有內(nèi)容合成到顯示部分鼠锈。
有關(guān) BufferQueue 通信過程，請參見下圖星著。
圖 3.BufferQueue 通信過程
BufferQueue 包含將圖像流生產(chǎn)方與圖像流消耗方結(jié)合在一起的邏輯购笆。圖像生產(chǎn)方的一些示例包括由相機(jī) HAL 或 OpenGL ES 游戲生成的相機(jī)預(yù)覽。圖像消耗方的一些示例包括 SurfaceFlinger 或顯示 OpenGL ES 流的另一個(gè)應(yīng)用虚循，如顯示相機(jī)取景器的相機(jī)應(yīng)用同欠。
BufferQueue 是將緩沖區(qū)池與隊(duì)列相結(jié)合的數(shù)據(jù)結(jié)構(gòu)，它使用 Binder IPC 在進(jìn)程之間傳遞緩沖區(qū)横缔。生產(chǎn)方接口铺遂，或者您傳遞給想要生成圖形緩沖區(qū)的某個(gè)人的內(nèi)容，即是 IGraphicBufferProducer（SurfaceTexture的一部分）茎刚。BufferQueue 通常用于渲染到 Surface襟锐，并且與 GL 消耗方及其他任務(wù)一起消耗內(nèi)容。BufferQueue 可以在三種不同的模式下運(yùn)行：
類同步模式 - 默認(rèn)情況下膛锭，BufferQueue 在類同步模式下運(yùn)行粮坞，在該模式下，從生產(chǎn)方進(jìn)入的每個(gè)緩沖區(qū)都在消耗方那退出初狰。在此模式下不會舍棄任何緩沖區(qū)莫杈。如果生產(chǎn)方速度太快，創(chuàng)建緩沖區(qū)的速度比消耗緩沖區(qū)的速度更快奢入，它將阻塞并等待可用的緩沖區(qū)筝闹。
非阻塞模式 - BufferQueue 還可以在非阻塞模式下運(yùn)行，在此類情況下腥光，它會生成錯(cuò)誤关顷，而不是等待緩沖區(qū)。在此模式下也不會舍棄緩沖區(qū)武福。這有助于避免可能不了解圖形框架的復(fù)雜依賴項(xiàng)的應(yīng)用軟件出現(xiàn)潛在死鎖現(xiàn)象解寝。
舍棄模式 - 最后，BufferQueue 可以配置為丟棄舊緩沖區(qū)艘儒，而不是生成錯(cuò)誤或進(jìn)行等待。例如夫偶，如果對紋理視圖執(zhí)行 GL 渲染并盡快繪制界睁，則必須丟棄緩沖區(qū)。
為了執(zhí)行這項(xiàng)工作的大部分環(huán)節(jié)兵拢，SurfaceFlinger 就像另一個(gè) OpenGL ES 客戶端一樣工作翻斟。例如，當(dāng) SurfaceFlinger 正在積極地將一個(gè)緩沖區(qū)或兩個(gè)緩沖區(qū)合成到第三個(gè)緩沖區(qū)中時(shí)说铃，它使用的是 OpenGL ES嘹履。
Hardware Composer HAL 執(zhí)行另一半工作债热。該 HAL 充當(dāng)所有 Android 圖形渲染的中心點(diǎn)。
同步框架
由于 Android 圖形不提供顯式并行性窒篱，因此供應(yīng)商一直都是在自己的驅(qū)動(dòng)程序中實(shí)現(xiàn)自己的隱式同步。但是墙杯，Android 圖形同步框架不再需要這么做。有關(guān)實(shí)現(xiàn)說明溉旋，請參閱顯式同步部分。
同步框架明確描述了系統(tǒng)中不同異步操作之間的依賴關(guān)系观腊。框架提供了一個(gè)簡單 API恕沫，使組件在緩沖區(qū)被釋放時(shí)發(fā)出信號纱意。它還允許在從內(nèi)核到用戶空間的驅(qū)動(dòng)程序之間以及用戶空間進(jìn)程本身之間傳遞同步基元。
例如偷霉，應(yīng)用可以將要在 GPU 中執(zhí)行的工作加入隊(duì)列。然后叙身，GPU 開始繪制該圖像硫狞。盡管圖像尚未被繪制到內(nèi)存中，但緩沖區(qū)指針仍然可以與指示 GPU 工作何時(shí)完成的柵欄一起傳遞到窗口合成器残吩。然后，窗口合成器可以提前開始處理泣侮，并將工作移交給顯示控制器。通過這種方式隶校，CPU 工作可以提前完成。GPU 完成后深胳，顯示控制器就可以立即顯示圖像。
同步框架還允許實(shí)現(xiàn)人員在自己的硬件組件中利用同步資源稠屠。最后，框架使實(shí)現(xiàn)人員可以查看圖形管道权埠，以幫助進(jìn)行調(diào)試。
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 3.0 License, and code samples are licensed under theApache 2.0 License. For details, see ourSite Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 九月 13, 2017.
