Android圖形顯示子系統概述
Android圖形顯示系統，是Android比較重要的一個子系統，和很多其他子系統的關聯緊密。想象一下，沒有圖形顯示系統的手機是什麼樣子，可能連對講機都不如吧。圖形顯示系統比較複雜，從Android誕生到現在，幾經修改，已經變的越來越龐大了。總的說來，圖形顯示系統可以分爲兩大部分來理解：
- 圖形系統
- 顯示系統
圖形系統
圖形系統也就是圖形支持系統，提供繪圖和圖形處理支持。包括最初的2D繪圖API Skia，後來的3D繪圖API OpenGLES，RenderScript，OpenCV，到最近的Vulkan。也包括圖片解碼庫，jpg，png，gif等。以及它們所需要的各種Driver支持。
但是Android爲了方便大家，我們在做應用開發的時候，並不用大家直接用各種API去繪製界面，也不用直接用解碼庫去解碼。Android已經給大家提供了一個界面繪製機制，有很多widget和view，Android的應用開發者，用現有的widget就能夠繪製出比較酷炫的界面。
Android提供的大多view和widget都是2D的繪圖，2D繪圖比較慢，也發揮不出GPU的作用，因此Android又設計了一套加速系統，硬件加速。其目的就是將2D的繪圖操作轉換爲一個個的3D（Opengl）繪圖，再採用部分更新的方式，只去重繪界面中有更新的部分view，這樣就大大提升界面繪製的速度。
顯示系統
圖形繪製好了後，需要送到LCD顯示屏上，我們才能看到。繪製界面時，我們只關心單個界面，顯示的時候，可能就有多個界面了。做過Android應該開發的都知道，我們需要繼承一個Activity，用Activity呈現我們的界面。Activity的生命週期管理，也就伴隨了窗口的管理。這中間就涉及了兩個Android中兩個主要的服務，AMS（ActivityManagerService）和WMS（WindowManagerService）。View，AMS，WMS可以說是整個上層顯示系統的三駕馬車。
在Android中，一個窗口用一個Surface描述。多個窗口（窗口不一定都是Activity），需要同時顯示，我們就需要將多個窗口進行合併。這就需要顯示系統中重量級的服務SurfaceFlinger，Surfaceflinger控制窗口的合成，將多個窗口合併成一個，再送到LCD。
Surfaceflinger是Native的服務，Surfaceflinger中怎麼去描述一個窗口呢？Surfaceflinger採用圖層的概念，即Layer。SurfaceFlinger合成，就是基於Display HAL的實現，將多個Layer合併。Display HAL，各個廠商的實現就千差萬別了。
Buffer管理
前面討論了怎麼繪製，怎麼顯示。但是，繪製，繪在什麼地方，拿什麼去顯示。答案只能是內存Buffer。Android的系統中，採用GraphicBuffer對buffer進行封裝，而buffer採用ion實現，能在進程間共享。
Surface屬性應用進程，Layer屬於SurfaceFlinger進程。如果只用一個Buffer，那麼兩個進程都有可能同時在用Buffer，這就可能會造成我們看到的屏幕顯示不對，存在撕裂。另外，只用一個Buffer，效率也不高啊，繪製本來就是GPU在繪製，顯示這邊是CPU或者是其他的硬件模塊，一個工作，另外一個不工作，且不浪費。所以Android採用Buffer隊列的方式，即BufferQueue。繪製的是一個Buffer，顯示的是一個buffer，各自處理完後，交換一下Buffer。這樣效率就高很多了。這中間再採用一個生產者-消費者模型，Buffer是載體，Surface應用這邊是Producer，SurfaceFlinger這邊是是Consumer。這樣就更好理解了。
顯示系統的架構
有了前面的描述，是不是對Android的圖形顯示系統有了大概的認識了？沒有關係，我們直接來看架構圖。架構圖來自Androd的官網， https://source.android.com/devices/graphics/ ,
大家可以對照圖再回味一下，前面的描述。有些地方，這個圖並不能很好的體現，不過沒有關係，接下來我們會詳細的介紹各個模塊和流程。
換一種方式來描述Android的顯示系統，架構圖如下：
再和前面Android的圖進行對照，是不是更清楚一些了。
這個圖裏，前面的描述裏有點沒有說到，SurfaceFlinger到OpenGLES，大家是不是覺得有點奇怪。其實是這樣的，SurfaceFlinger合成，有兩種方式，Client和Device。Client就是Client合成完Layer後再將合成後的數據給到HWComposer，HWComposer此時做的工作很少，直接給到Display。Device則是將未合成的Layer，給到硬件合成的設備，合成完後再給到Display。
可能大家還是很迷茫，沒有關係～，我們接下來將參照Android的源碼，逐一爲大家講解。
從應用的角度理解Android
做Android開發，我們都講了太多的架構，也聽了太多的架構。不知道大家有沒有從應用的角度去看過Android的系統？我們先來看Android的整體系統架構。
Android基於Linux內核，我們是不是可以將上層Android理解爲Linux內核的一個應用。這個應用非常龐大，集集了電話，BT，WiFi，音視頻播放，Camera等功能。
基於Linux內核的系統非常的多，比如常用的，Debian系列的Ubuntu，Debian；Redhat系統的RedHat，Fedora等。你可以理解Android自成一個系列。所以，我們也可以基於Linux內核去開發自己的系統。
回到Android，Android在Linux中加了很多驅動，再採用硬件抽象的方式，向上提供接口，這就是我們所說的HAL層。所以我們要增加一個模塊，需要增加Linux驅動，然後實現HAL，以供上層使用。當然，我們也可以基於Android的HAL去開發上層的系統，又可以將基於HAL的系統看成一個應用。據瞭解，FirefoxOS，360OS，YunOS等，基本都是基於Android的HAL的方式去開發的（Oops~如有褻瀆，神靈保佑…）。
基於HAL的Android Framework，分爲Native Framework和JavaFramework。HAL層是C++寫的，按裏說，Native的 Framework應該就夠了，什麼還要去實現Java的Framework呢？Android的應用大多數都是用Java開發，中間還有一個Java虛擬機，和JNI。
其實，這是有歷史原因的。現在Android已經形成了一個很大的生態鏈，但是想想當初，Android系統剛纔發佈，得有開發者呀，沒有開發者的支持，如何能形成生態鏈。所以，Android就採用了這種Java開發方式，大大籠絡了Java開發人員。
再回到我們的顯示子系統，Surfaceflinger基於HAL HWComposer，管理和控制着整個Android的顯示。而上層，則是WMS，AMS，View等系統服務管理和控制着整個Android的顯示。
回到上一章給出的Display架構圖，我們是不是可以直接基於Native的Framework進行應用的開發呢，答案是肯定的。Android也爲此提供了NDK，以便於Android Native應用的開發。
下面，讓我們從一個Native應用開始，揭開Android顯示系統的面紗～