Android GDI分析

在Android中所涉及的概念和代碼最多，最繁雜的就是GDI相關的代碼了。但是本質從抽象上來講，這麼多的代碼和框架就干了一件事情：對顯示緩沖區的操作和管理。

GDI主要管理圖形圖像的輸出,從整體方向上來看,GDI可以被認為是一個物理屏幕使用的管理器。因為在實際的產品中，我們需要在物理屏幕上輸出不同的窗口，而每個窗口認為自己獨占屏幕的使用，對所有窗口輸出，應用程序不會關心物理屏幕是否被別的窗口占用，而只是關心自己在本窗口的輸出，至於輸出是否能在屏幕上看見，則需要GDI來管理。

從最上層到最底層的數據流的分析可以看到實際上GDI在上層為GUI提供一個抽象的概念,就好像操作系統中的文件系統所提供文件，目錄等抽象概念一樣，GDI輸出抽象成了文本,畫筆,位圖操作等設備無關的操作,讓應用程序員只需要面對邏輯的設備上下文進行輸出操作,而不要涉及到具體輸出設備,以及輸出邊界的管理。GDI負責將文本、線條、位圖等概念對象映射到具體的物理設備，所以GDI的在大體方向上可以分為以下幾大要素：

畫布

字體

文本輸出

繪畫對象

位圖輸出

Android的GDI系統所涉及到概念太多，加之使用了OpenGL使得Android的層次和代碼很繁雜。但是我們對於Android的GDI系統需要了解的方面不是他的靜態的代碼關系，而是動態的對象關系，在邏輯運行的架構上理解GDI。我們首先還是需要從代碼結構開始我們的理解。

Frameworks/Libs/Surfaceflinger

Frameworks/base/core/jni/android_view_Surface.cpp

Frameworks/base/core/java/android/view/surface.java

Frameworks/base/Graphics：繪圖接口

Frameworks/Libs/Ui

External/Skia

其中External/Skia是一個C++的2D圖形引擎庫，Android的2D繪制系統都是建立在該基礎之上.Skia完成了：文本輸出，位圖，點，線，圖像解碼等功能。

我在這裡給出Android GDI的基本框架示意圖。

對於上面的GDI架構圖我們只是一個大概的了解，我們有太多的問題需要解決，有太多的疑問需要得到答案，我就一直在想，為什麼設計者有提出如此眾多的概念，這個概念的背景是什麼？他要管理什麼，他要抽象什麼？從前面知道，Android的整個設計理念就是無邊界化，他是如何穿透Linux進程這個鴻溝來達到無邊界的？Surface，Canvas， Layer，LayerBase, NativeBuffer，SurfaceFlinger，SurfaceFlingerClient這些到底是一個什麼東西？如何管理，傳遞的是什麼？創建的是什麼？這些都是抽象的概念，繪畫的終極的緩沖區到底是如何管理的？緩沖區到底在哪裡？

     我們還是看看做終極的，最本質的設計概念，在從這些概念出發，來探討這些概念的形成過程，是否有必要去生成寫概念。SurfaceFlinger本質上干什麼的？SurfaceFlinger的確就是這個意義：應用程序通過SurfaceFlinger將自己的“Surface”投擲到屏幕緩沖區。