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、如何支持多屏？

相对于提供了各种各样控件，支持各种渲染体系的上层显示来说，系统级别的显示代码相对单纯，性能上基本做到了最好，可复用性也很高。

后续将会先介绍下层显示，然后再慢慢分析上层显示。