在Android最繁杂的就是GDI 相关的代码了。这么多的代码和框架就干了一件事情：对显示缓冲区的操作和管理。
GDI主要管理图形图像的输出,从整体方向上来看,GDI 可以被认为是一个物理屏幕使用的管理器。输出是否能在屏幕上看见，则需要GDI来管理。
GDI在上层为GUI提供一个抽象的概念,GDI输出抽象成了文本,画笔,位图操作等设备无关的操作,GDI 负责将文本、线条、位图等概念对象映射到具体的物理设备，所以GDI 的在大体方向上可以分为以下几大要素：
画布
字体
文本输出
绘画对象
位图输出
Android的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 的基本框架示意图。
Android 的整个设计理念就是无边界化，他是如何穿透Linux 进程这个鸿沟来达到无边界的？Surface，Canvas， Layer，LayerBase, NativeBuffer，SurfaceFlinger，SurfaceFlingerClient 这些到底是一个什么东西？如何管理，传递的是什么？创建的是什么？这些都是抽象的概念，绘画的终极的缓冲区到底是如何管理的？缓冲区到底在哪里？SurfaceFlinger 本质上干什么的？SurfaceFlinger 的确就是这个意义：应用程序通过SurfaceFlinger
将自己的“Surface”投掷到屏幕缓冲区。