该小节我们初步的了解一下android系统的框架，看看其有那些构成部分。我们知道一个应用程序要去操作LCD，需要把数据写入到framebuffer，如果有多个应用程序对一个framebuffer同时进行操作，那么最终屏幕的显示肯定是乱糟糟的，所以说对于多应用程序，肯定是不能直接访问framebuffer的，应该有一个统一的管理者，由这个管理者处理这些显示数据。
前面的3点之中，我们只讲解了第一点，现在开始讲解剩下的几点。
显示系统框架初探
假设有多个应用程序APP1,APP2,APP3,他们都不能直接访问framebuffer，他们都要通过一个管理者进行访问。这个管理者在android中称为SurfaceFlinger（统一操作显示设备），下面是一个框图，之后围绕这个框图进行讲解：
第一点：APP1,2,3把各自的界面发送给SurfaceFlinger，他根据层次，大小进行叠加合成进行显示。既然每个APP有各自的界面，那么每个APP肯定对应一个或者多个自己的framebuffer，这些数据需要传递给SurfaceFlinger，如果直接cp或者通过scoketpair传递过去，速率是十分缓慢的，那么问题来了，怎么才能更快，更高效的把数据进行传递呢？使用第二点的方法，SurfaceFlinger使用的framebuffer就是APP的buff这样就不用进行数据传递呢，直接使用即可。SurfaceFlinger接收到显示数据的之后，1.根据各个界面的z值（界面的高度：即那个显示在上面，那么显示在下面都是根据Z值而定）决定上下顺序，该值由WindowManagerService确定，2.把这些排序后的buff传给HardWare Comper，让硬件进行合成。
第二点：给APP提供framebuffer,怎么提供呢？在HAL层，存在Gralloc（图片分配模块），在内核中有其对应的驱动，ashmem（匿名内存），framebuffer。其大致过程为，SurfaceFlinger通过Gralloc模块向ashmem申请内存，得到一个文件句柄，通过binder把fd传递给某个app，最后APP在mmap（fd）。这样APP与SurfaceFlinger能访问一块内存。
在上述的情况都是硬件存在HardWare Comper模块的情况下，那么如果没有该模块，或者有的APP层数太多，超过了HardWare Comper模块支持的层数，android又是如何处理的呢？那么只能通过软件（GLLgraphicLibrary：图像库）实现了。说道图像库，我们还能引入GPU，存在其对应的驱动程序以及对驱动进行操作的库，如libGLESV2_xxx.so或者LibGLESV1_cm_xx.so .如果没有GPU还有一些其他的库（纯软件），如LibELES_android（ES-embeded system：嵌入式系统）。无论纯软件，还是通过硬件的，他们都必须支持同样的接口，即openGLES接口，该接口与平台无关，也就是说你在android，wins或者其他的平台，都是相同的。
SurfaceFlinger在使用openGLES接口的时候，还会做一些封装（EGL），实际上通过LibEGL.so加载硬件库LibGLESV1_cm_xx.so，libGLESV2_xxx.so或者加载软件库LibELES_android文件。