显示部分的架构图

1. android 显示系统架构图

最上面一层为应用程序，根据数据类型以及应用的不同可以分为几种。

第一种是最普通的应用，如UI界面的显示，这部分通常数据类型为RGB格式，数据无须再经过特殊的处理。该应用可以说遍布各个应用程序，几乎是实时存在的。

第二种是针对大块YUV数据的应用，如camera的preview、视频的播放等。该应用只针对特定的应用程序，开启时通过overlay直接把大块的YUV数据送到kernel显示。

第三种其实和第一种类似，只不过由于应用的需求在显示之前需要对数据进行2D、3D的处理（使用OpenGL、OpenVG、SVG、SKIA），处理之后的流程和普通的显示就没什么差别了。一般在Game、地图、Flash等应用中会用到。

 

应用之下是framework，其中最核心的就是surfaceflinger了，它为所有的应用程序的显示提供服务。由于overlay的接口挂在surfaceflinger里面（虽然2者在功能上不相干），所有使用overlay的AP需要通过surfaceflinger才可以访问overlay；另外，由于surfaceflinger需要使用OpenGL来compose surface，这也就是为什么surfacelfinger会调用EGL wrapper了，EGL wrapper是对Graphics HAL的封装，除了surfaceflinger会调用它来compose surface外，上层的2D、3D应用也会调用它来进行图形处理。

 

再下一层就是HAL了。

首先一个是overlay模块，对上提供control channel和data channel；对下则通过系统调用到kernel中的MDP driver。

再一个是Gralloc模块，注意它是和overlay并列的，它包含2个部分，一部分是为上层提供pmem的接口，另一部分则是对framebuffer进行刷新，这里的framebuffer其实就是UI的数据。由此可见上层有2个通道把显示数据送到kernel中，framebuffer是传统的方式，overlay是android（éclair以后）后增加的。

红色及右边部分是OpenGL的HAL，其中红色部分代表HW solution，高通提供的，这部分是没有源码的；右边的software graphics library是SW solution，android自身的。HW和SW solution可以同时存在也可以只有一个，后面会讲解。

再往下就是kernel中的driver了，最主要的就是fb设备驱动以及MDP4 overlay的驱动，从硬件上看2者是并列的，framebuffer最终也是通过overlay方式送入MDP的。PMEM和KGSL分别对应kernel中pmem的driver（/dev/pmem）和Adreno220的driver。

 

这部分可以参考：Android display架构分析-SW架构分析(1-4)     Android display架构分析(5-8)

 

2.Surfaceflinger在系统中的位置

Android中的图形系统采用Client/Server架构。服务端负责Surface的合成等处理工作，客户端提供接口给上层操作自己的Surface，并向服务端发送消息完成实际处理工作。

服务端 (即SurfaceFlinger)主要由c++代码编写而成。

客户端端代码分为两部分，一部分是由Java提供的供应用使用的api,另一部分则是由c++写成的底层实现。如下图所示：

 

关于surfaceflinger可以参考：Android Display System --- SurfaceFlinger分析