Android圖形顯示系統——概述序Android圖形顯示系統的剖分應用級别的顯示系統級别的顯示

android的圖形顯示系統，雖然感覺自己基本了解了，有問題基本都能解決，但要寫時，一是覺得千頭萬緒無從下筆，一是發現還有很多并沒有真正搞懂。開工寫這套體系，也順便查漏補缺下。

圖形顯示系統就像一個報社，它派出記者去采訪，記者寫成文稿後，将記者們交上來的文稿稽核、排版、印刷，最終形成一期又一期報紙。

如上是android圖形顯示系統的一個全貌圖。每個layer對應着一個surface。surface 由每個需要顯示的程序view樹建立（view樹本身對應一個surface，是為主線程ui的surface，遇到surfaceview時挖洞，産生額外的surface），

view樹的底端，實際渲染的view選取一種繪制方式，這可能是widget（系統提供預設實作），webcore（webview走獨立的渲染流程），canvas（使用者在canvas層級上自定義繪制函數）和 opengl（glsurfaceview，獨立的渲染流程，由使用者使用opengl實作渲染。）

surfaceflinger用來建立layer，并且在上層繪制完成後，合成所有需要顯示的layer，送到lcd顯示。其中gralloc是申請圖形記憶體且連接配接fb（framebuffer）的子產品，合成layer時，優先選用hwcomposer，在hwcomposer無法解決時，采用預設的3d合成，也即調opengl标準接口，将各圖層繪制到fb上。

以圖中間那條線為界，顯示系統劃分為上下兩層。

上層為應用級别的顯示，解決如何繪制圖層的問題，主要為java代碼（記者采訪/寫作）。

下層為系統級别的顯示，解決如何将繪制好的圖層送顯的問題（印刷），主要為c/c++代碼。

一些排程的java代碼，如起“排版”作用的windowsmanager，盡管起的作用是系統性的，由于是對外提供api，也歸到上層顯示。

這部分需要做的事情一是對開發者提供一套api，使其能簡易的建立自己的ui界面。二是作一個排版工作，解析布局，管理view的層級。

和ios一樣，google提供的api實際上也是分層級的，不過可能沒有明确說明。

這一層級主要是提供各種控件，如button、textview、image view等。

在開發者希望實作自定義的效果時，重載view的ondraw方法，或者直接用surface擷取canvas，使用canvas的api繪制自定義界面。這個canvas調用的可能是軟體的skia，也可能是硬體加速的hwui。

對于3d遊戲而言，android提供的canvas是不能滿足要求的，這時需要引入3d引擎直接調opengl。android同樣提供了這一套api。

這部分實際上相當于一個ui引擎，主要處理的是ui布局檔案的解析，view層級關系的生成與管理，以及各個view逐級渲染的方法，邏輯極其複雜。

這部分主要解決這些問題：

1、如何申請可以用來送顯的記憶體，如何将其送往lcd？

2、如何提供視窗系統？

3、如何同步合成/顯示多個圖層？

4、如何支援多屏？

相對于提供了各種各樣控件，支援各種渲染體系的上層顯示來說，系統級别的顯示代碼相對單純，性能上基本做到了最好，可複用性也很高。

後續将會先介紹下層顯示，然後再慢慢分析上層顯示。