Android 4.4 Graphic系统详解（1） SurfaceFlinger的启动过程
2015-09-22 10:16
771 查看
init启动SurfaceFlinger
SurfaceFlinger目前的启动方式是做为init进程中的一个Service来启动。
在init中添加如下配置代码：
系统将启动/system/bin/目录下的surfaceflinger bin文件来运行SurfaceFlinger。
关于init.rc的语法问题，我们将有专门的文章展开讨论（TODO）。
我们继续来看下对应的bin文件中的代码，位置在android\frameworks\native\services\surfaceflinger下。
从上面代码中我们看到SF的创建过程主要有四个步骤，我们来逐一分析一下。
其实这个创建过程很简单，无非就是初始化了一些值。从配置中读取了一些值。
需要注意的一点是，SurfaceFlinger实现了三个接口：
BnSurfaceComposer意思是指这个Surface混合的native端，这显然也符合我们对SF功能的认识—-用于Layer的混合处理。
另外，我们会在后面消息的处理一节中单独讲解HWComposer::EventHandler接口的作用。
其实相比SurfaceFlinger的创建，初始化做了更多的工作。
这一过程比较复杂，我们分为几部分来分析：
2.1 EGL初始化
首先SF初始化时，会进行一些EGL的初始化工作。
我们知道EGL是用来管理绘图表面（Drawing surfaces），并且提供了如下的机制
1) 与本地窗口系统进行通信（本地窗口在X-Window下是XDisplay ID，在MS Windows下是Window DC，而在Android平台上EGL是NativeDisplayType）
2) 查找绘图表面可用的类型和配置信息
3) 创建绘图表面
4) 同步OpenGL ES 2.0和其他的渲染API（Open VG、本地窗口系统的绘图命令等）
5) 管理渲染资源，比如材质
eglGetDisplay调用egl_display_t::get_display(dpy)获取（连接）显示设备的句柄。
egl_display_t结构用来存储get_display函数获取的物理显示设备。
这里的EGL_DEFAULT_DISPLAY类型是NativeDisplayType，是一个关联系统物理屏幕的通用数据类型。
每个 EGLDisplay 在使用前都需要通过eglInitialize函数来初始化。初始化 EGLDisplay 的同时，你可以得到系统中 EGL 的实现版本号。
这个整个过程是由平台实现的，我们看不到具体实现代码（libagl里面有一套谷歌的实现，但是非常简单）。
2.2 创建HWComposer
接下来是创建了一个HWComposer，也就是一个负责硬件合成的模块。但是我们也看到上面的注释明确写着，下面可能并没有一个真正的硬件支持。我们来研究下这个HWComposer的创建过程：
2.3 EGL配置
HWC模块创建完成之后，我们继续回到SurfaceFlinger的初始化过程，后面将继续是一些EGL相关的配置：
2.4 display设置
EGL和OpenGL ES的配置设置完毕之后，我们将对display进行设置。
上面这段代码其实涉及到了三个重要的概念，BufferQueue、FrameBufferSurface以及DisplayDevice。
BufferQueue做为Graphic的核心组件，我们在讲解Graphic总体结构时已经有说明，后面会另开专题说明。我们先来看下FrameBufferSurface的实现：
我们使用了BufferQueue来创建了一个FramebufferSurface，显然这个FramebufferSurface是一个消费者。在创建过程我们使用了屏幕的编号和HWC，我们可以猜测这个FBS是和一个屏幕绑定的，而且最终应该也是要通过HWC进行渲染。我们可以理解为这是SF在这个屏幕上使用的帧缓冲区，那么也就是一旦使用SF合成，最后数据应该是合成在了这里面（待验证），然后这里面的数据通过HWC显示在了屏幕上。猜测一下，这个是不是就是抓dump时抓到的那个HWC_FRAMEBUFFER_TARGET？
FBS的创建并没有特别之处，需要留意的是这里设置了MaxBufferCount和MaxAcquiredBufferCount，我们在Graphic总体架构一文中已经提到了设置这两个属性的作用。
DisplayDevice其实是抽象了显示设备，封装了用于渲染的Surface和HWComposer模块等，从而尽可能使得SurfaceFlinger只要和它打交道。来看下他的创建过程：
这段创建同样相当之长，我们目前只关注这里面创建了一个EGLSurface。我们在前面的文章中曾经提到过这个类，这个实际上就是一个供GLES使用的窗口缓冲区，为GLES提供了一个绘制的地方。
在这个EGLSurface里面是一个Surface，本质上下面还是一个BufferQueue。
渲染这个EGLSurface将导致一个buffer出队渲染入队的过程，lock和unlock过程是通过eglSwapBuffers函数来提供的。
2.5 makeCurrent
看完了上面几个重要概念的讲解，我们继续回到SF的init过程中来。
下面是对主屏幕对应的display进行makeCurrent操作:
注意到这里调用的实际上是DisplayDevice类提供的函数，这也某种程度上说明了我们前面提到的DisplayDevice的作用是：封装了用于渲染的Surface和HWComposer模块等，从而尽可能使得SurfaceFlinger只要和它打交道。看下这个makeCurrent函数：
这里获取了当前使用的EGLSurface，一旦发现这个Surface发生了改变，就要重新调用eglMakeCurrent函数来设置，这是因为一个线程同时只能有一个EGLSurface作为current。而关于eglMakeCurrent函数的更详尽的说明，我们将在EGL和GLES的章节中给予说明。
2.6 EventThread的创建
再次回到SF的init过程中来：
这段讲了EventThread的创建和使用。EventThread主要用于VSYNC消息的处理，我们同样会单开一个章节来讲解VSYNC的逻辑。
EventControlThread是用来向真实的VSync硬件发命令的，我们这里暂时不展开。
而一旦硬件不能正常发送VSYNC命令时，我们则通过软件方式模拟，我们可以看到这里把模拟的间隔时间设置为16.6ms左右。
2.7 初始化显示设备
终于到了init函数的最后几句话，首先是初始化显示设备。
我们来看初始化显示设备的逻辑：
其中setTransactionState函数在很多地方都会有调用，作用主要是处理上层的各个命令，并根据flag设置event通知Threadloop进行处理，TODO
而onScreenAcquired同样是一个重要的函数，不仅在这里，在屏幕会唤醒时同样会调用。
这里有几个点比较重要，首先是通知HWC，调用了HWC的acquire函数：
接下来，调用了EventThread的onScreenAcquired函数。
这个函数首先判断如果在之前mUseSoftwareVSync被设置为了true，这里需要改回来。而mUseSoftwareVSync这个值其实是在onScreenReleased被设置为true的（也就是说，在屏幕被灭掉之后，就变为软件的VSync，TODO，在屏幕黑掉之后，还有没有绘制或者显示方面的工作？）。
后面这个广播发送的主要作用是唤醒EventThread线程，并打开VSync事件发送器（可以看下waitForEvent函数）。
接下来的resyncToHardwareVsync函数逻辑比较简单，应该就是开启硬件的VSYNC。
最后是调用了repaintEverything函数，这个函数就是发送invalidate消息，请求屏幕刷新。
2.8 开机动画
回到init的过程上来。
播放开机动画我们会专门讲解，这里不再展开。
向Android的ServiceManager进程注册服务是系统的通用逻辑，不再展开，这里就是注册了一个名叫的SurfaceFlinger的服务而已。
在一系列的准备工作之后，终于到了启动SurfaceFlinger的时候。
而这个过程其实异常简单，SF进入死循环中，一直在等待消息的传来。
这样，我们就完整的分析了SF的启动过程，我们将在下一节继续分析SF对消息的处理过程。
init启动SurfaceFlinger
SurfaceFlinger目前的启动方式是做为init进程中的一个Service来启动。
在init中添加如下配置代码：
[cpp] view plaincopy
# Set this property so surfaceflinger is not started by system_init setprop system_init.startsurfaceflinger 0 service surfaceflinger /system/bin/surfaceflinger class main user system group graphics drmrpc onrestart restart zygote
系统将启动/system/bin/目录下的surfaceflinger bin文件来运行SurfaceFlinger。
关于init.rc的语法问题，我们将有专门的文章展开讨论（TODO）。
SurfaceFlinger启动过程
我们继续来看下对应的bin文件中的代码，位置在android\frameworks\native\services\surfaceflinger下。[cpp] view plaincopy
从上面代码中我们看到SF的创建过程主要有四个步骤，我们来逐一分析一下。
1. 创建SF对象
[cpp] view plaincopy
其实这个创建过程很简单，无非就是初始化了一些值。从配置中读取了一些值。
需要注意的一点是，SurfaceFlinger实现了三个接口：
[cpp] view plaincopy
BnSurfaceComposer意思是指这个Surface混合的native端，这显然也符合我们对SF功能的认识—-用于Layer的混合处理。
另外，我们会在后面消息的处理一节中单独讲解HWComposer::EventHandler接口的作用。
2.初始化
其实相比SurfaceFlinger的创建，初始化做了更多的工作。这一过程比较复杂，我们分为几部分来分析：
2.1 EGL初始化
[cpp] view plaincopy
首先SF初始化时，会进行一些EGL的初始化工作。
我们知道EGL是用来管理绘图表面（Drawing surfaces），并且提供了如下的机制
1) 与本地窗口系统进行通信（本地窗口在X-Window下是XDisplay ID，在MS Windows下是Window DC，而在Android平台上EGL是NativeDisplayType）
2) 查找绘图表面可用的类型和配置信息
3) 创建绘图表面
4) 同步OpenGL ES 2.0和其他的渲染API（Open VG、本地窗口系统的绘图命令等）
5) 管理渲染资源，比如材质
eglGetDisplay调用egl_display_t::get_display(dpy)获取（连接）显示设备的句柄。
egl_display_t结构用来存储get_display函数获取的物理显示设备。
这里的EGL_DEFAULT_DISPLAY类型是NativeDisplayType，是一个关联系统物理屏幕的通用数据类型。
每个 EGLDisplay 在使用前都需要通过eglInitialize函数来初始化。初始化 EGLDisplay 的同时，你可以得到系统中 EGL 的实现版本号。
这个整个过程是由平台实现的，我们看不到具体实现代码（libagl里面有一套谷歌的实现，但是非常简单）。
2.2 创建HWComposer
[cpp] view plaincopy
接下来是创建了一个HWComposer，也就是一个负责硬件合成的模块。但是我们也看到上面的注释明确写着，下面可能并没有一个真正的硬件支持。我们来研究下这个HWComposer的创建过程：
[cpp] view plaincopy
2.3 EGL配置
HWC模块创建完成之后，我们继续回到SurfaceFlinger的初始化过程，后面将继续是一些EGL相关的配置：
[cpp] view plaincopy
2.4 display设置
EGL和OpenGL ES的配置设置完毕之后，我们将对display进行设置。
[cpp] view plaincopy
上面这段代码其实涉及到了三个重要的概念，BufferQueue、FrameBufferSurface以及DisplayDevice。
BufferQueue做为Graphic的核心组件，我们在讲解Graphic总体结构时已经有说明，后面会另开专题说明。我们先来看下FrameBufferSurface的实现：
[cpp] view plaincopy
我们使用了BufferQueue来创建了一个FramebufferSurface，显然这个FramebufferSurface是一个消费者。在创建过程我们使用了屏幕的编号和HWC，我们可以猜测这个FBS是和一个屏幕绑定的，而且最终应该也是要通过HWC进行渲染。我们可以理解为这是SF在这个屏幕上使用的帧缓冲区，那么也就是一旦使用SF合成，最后数据应该是合成在了这里面（待验证），然后这里面的数据通过HWC显示在了屏幕上。猜测一下，这个是不是就是抓dump时抓到的那个HWC_FRAMEBUFFER_TARGET？
FBS的创建并没有特别之处，需要留意的是这里设置了MaxBufferCount和MaxAcquiredBufferCount，我们在Graphic总体架构一文中已经提到了设置这两个属性的作用。
DisplayDevice其实是抽象了显示设备，封装了用于渲染的Surface和HWComposer模块等，从而尽可能使得SurfaceFlinger只要和它打交道。来看下他的创建过程：
[cpp] view plaincopy
这段创建同样相当之长，我们目前只关注这里面创建了一个EGLSurface。我们在前面的文章中曾经提到过这个类，这个实际上就是一个供GLES使用的窗口缓冲区，为GLES提供了一个绘制的地方。
在这个EGLSurface里面是一个Surface，本质上下面还是一个BufferQueue。
渲染这个EGLSurface将导致一个buffer出队渲染入队的过程，lock和unlock过程是通过eglSwapBuffers函数来提供的。
2.5 makeCurrent
看完了上面几个重要概念的讲解，我们继续回到SF的init过程中来。
下面是对主屏幕对应的display进行makeCurrent操作:
[cpp] view plaincopy
注意到这里调用的实际上是DisplayDevice类提供的函数，这也某种程度上说明了我们前面提到的DisplayDevice的作用是：封装了用于渲染的Surface和HWComposer模块等，从而尽可能使得SurfaceFlinger只要和它打交道。看下这个makeCurrent函数：
[cpp] view plaincopy
这里获取了当前使用的EGLSurface，一旦发现这个Surface发生了改变，就要重新调用eglMakeCurrent函数来设置，这是因为一个线程同时只能有一个EGLSurface作为current。而关于eglMakeCurrent函数的更详尽的说明，我们将在EGL和GLES的章节中给予说明。
2.6 EventThread的创建
再次回到SF的init过程中来：
[cpp] view plaincopy
这段讲了EventThread的创建和使用。EventThread主要用于VSYNC消息的处理，我们同样会单开一个章节来讲解VSYNC的逻辑。
EventControlThread是用来向真实的VSync硬件发命令的，我们这里暂时不展开。
而一旦硬件不能正常发送VSYNC命令时，我们则通过软件方式模拟，我们可以看到这里把模拟的间隔时间设置为16.6ms左右。
2.7 初始化显示设备
终于到了init函数的最后几句话，首先是初始化显示设备。
[cpp] view plaincopy
我们来看初始化显示设备的逻辑：
[cpp] view plaincopy
其中setTransactionState函数在很多地方都会有调用，作用主要是处理上层的各个命令，并根据flag设置event通知Threadloop进行处理，TODO
而onScreenAcquired同样是一个重要的函数，不仅在这里，在屏幕会唤醒时同样会调用。
[cpp] view plaincopy
这里有几个点比较重要，首先是通知HWC，调用了HWC的acquire函数：
[cpp] view plaincopy
接下来，调用了EventThread的onScreenAcquired函数。
[cpp] view plaincopy
这个函数首先判断如果在之前mUseSoftwareVSync被设置为了true，这里需要改回来。而mUseSoftwareVSync这个值其实是在onScreenReleased被设置为true的（也就是说，在屏幕被灭掉之后，就变为软件的VSync，TODO，在屏幕黑掉之后，还有没有绘制或者显示方面的工作？）。
后面这个广播发送的主要作用是唤醒EventThread线程，并打开VSync事件发送器（可以看下waitForEvent函数）。
接下来的resyncToHardwareVsync函数逻辑比较简单，应该就是开启硬件的VSYNC。
[cpp] view plaincopy
最后是调用了repaintEverything函数，这个函数就是发送invalidate消息，请求屏幕刷新。
2.8 开机动画
回到init的过程上来。
[cpp] view plaincopy
播放开机动画我们会专门讲解，这里不再展开。
3.注册SF服务
向Android的ServiceManager进程注册服务是系统的通用逻辑，不再展开，这里就是注册了一个名叫的SurfaceFlinger的服务而已。
4.运行程序
在一系列的准备工作之后，终于到了启动SurfaceFlinger的时候。[cpp] view plaincopy
而这个过程其实异常简单，SF进入死循环中，一直在等待消息的传来。
总结
这样，我们就完整的分析了SF的启动过程，我们将在下一节继续分析SF对消息的处理过程。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Android关于PopupWindow控件的使用
- Android 5.x新特性之利用Palette获取图片的主题色
- android 快速开发（二）辅助类的使用：加快开发速度
- Android(Lollipop/5.0) Material Design(六) 使用图像
- Android 倒计时CountDownTimer
- 开发笔记
- android 设置系统的时间
- bug整理
- 在线查看android源代码的3种方式
- 2015Android移动开发应用主流菜单模式
- WebRTC知识分享——WebRTC on Android
- android自定义圆形imageview
- Android设备的显示信息
- Android 一个ListView添加多个Adapter
- “The Android NDK cannot be installed into a path with spaces”的解决方法
- Android开发总结笔记 TableLayout(表格布局) 1-1-4
- 由Android想到的事情
- Android--颜色，动画效果xml所在目录
- Android多屏幕适配方案
- android压力测试命令monkey详解