標籤:排序 不能 系統 phi 合成 android binder 管理者 分享圖片
1. Android顯示系統架構
Android Graphic UI with GPU Hardware Acceleration
https://community.nxp.com/docs/DOC-93612
a. 顯示驅動framebuffer的原理及改進
只有一個FrameBuffer的缺點:
(1)如果App寫入FB的速度慢,LCD映像變化慢
(2)如果App寫FB速度不快不慢,LCD映像會閃爍
因此,在僅使用一個FB的基礎上做出改進,使用多個FB來改進:
(1)DisplayController使用FB0
(2)APP寫FB1
(3)DisplayController使用FB1
(4)APP寫FB0
(5)重複以上步驟
最繪製圖片方面:以前在linux中是對在FB中繪製整個空間的資料,如果需要繪製手機介面,步驟如下:狀態列、導覽列、背景、表徵圖;每個介面都需要上述四個步驟
在Android中引入層的概念:狀態列和導覽列為一層、背景為一層、圖片為一層,最後把繪製好的層合并,合并使用HardwareComposer
HWC稱為硬體合并
驅動支援HWC:每一層對應一個驅動/dev/fbx,APP操作某一層,直接寫對應的FrameBuffer,硬體會自動合并它們(比如我們的4412的fb0~fb4就是對應的LCD)
b. 多任務系統的顯示: 必定有一個顯示管理者
APP不能直接存取LCD驅動程式,有一個稱為SurfaceFlinger(統一操作顯示裝置)的管理者,其功能:
(1)SurfaceFlinger給APP提供buffer,給APP存放介面(這樣APP和SurfaceFlinger之間就不需要傳輸buffer了)
a、SurfaceFlinger通過gralloc模組(HAL)向ashmem(驅動層)申請記憶體
b、得到一個fd,用這個檔案控制代碼描述申請的buffer
c、通過binder把fd傳給APP
d、APP通過mmap(fd)之後直接存取buffer
(2)APP1/APP 2/APP3 把各自的介面發給SurfaceFlinger,它根據層次、大小進行合成顯示;
a、根據各個介面的Z值(高度,相對XY座標理解)決定前後順序,Z值肯定是由WindowManagerService確定
b、把這些排序後的buffer傳給HardwareComposer模組,如果硬體不支援該模組或者層數超過了模組的限制,用軟體GL(graphicLibrary)處理
(3)當HardwareComposer不能處理(無硬體/超過硬體支援最大層數),使用GL來處理
android系統通過libEGL.so來載入硬體GL庫或者軟體GL庫(引腳GL庫可能是對GPU的訪問),除了SurfaceFlinger可以通過libEGL.so來載入GL庫之外,APP也可以libEGL.so庫來使用GL庫
11.1 Android顯示系統架構_framebuffer原理及改進