Android显示系统（10）- SurfaceFlinger内部结构

Android显示系统（01）- 架构分析
Android显示系统（02）- OpenGL ES - 概述
Android显示系统（03）- OpenGL ES - GLSurfaceView的使用
Android显示系统（04）- OpenGL ES - Shader绘制三角形
Android显示系统（05）- OpenGL ES - Shader绘制三角形（使用glsl文件）
Android显示系统（06）- OpenGL ES - VBO和EBO和VAO
Android显示系统（07）- OpenGL ES - 纹理Texture
Android显示系统（08）- OpenGL ES - 图片拉伸
Android显示系统（09）- SurfaceFlinger的使用
Android显示系统（10）- SurfaceFlinger内部结构
Android显示系统（11）- 向SurfaceFlinger申请Surface
Android显示系统（12）- 向SurfaceFlinger申请Buffer
Android显示系统（13）- 向SurfaceFlinger提交Buffer

一、前言：

之前讲述了native层如何使用SurfaceFlinger，我们只是看到了简单的API调用，从本文开始，我们逐步进行SurfaceFlinger内部结构的分析。话不多说，莱茨狗~

二、类图：

2.1、总体架构：

先看下SurfaceFlinger的关键成员和我们BootAnimation侧关键成员如何对应起来，这不是严格的UML类图，但是这么画我觉着很容易理解，就先这么画了。

可以看出：

• SurfaceFlinger侧会为BootAnimation创建一个Client，其实，SF会为每个APP都创建一个Client；
• SurfaceFlinger侧有一个BufferQueueLayer（Layer的子类）对应APP侧的SurfaceControl，允许有一个APP有多个Layer，同时，SF会生成多个SurfaceControl；
• BufferQueueLayer是一个buffer队列，队列有一个消费者mConsumer和一个生产者mProducer；
• APP侧的SurfaceControl当中有一个Surface；
• Surface当中又有一个数组mSlots表示64个buffer，对应SF当中其实也有这么一个数组，如果数组来管理这些buffer，这个是比较复杂的流程，后面单独写一篇文章介绍；

2.2、代理关系：

上面看到好多类似于SurfaceCompser的字眼，到底啥关系呢？我给你画个图：

熟悉Binder机制的朋友都应该能看懂，Bpxxxx一般就是代理类，Bnxxxx一般就是本地类，这样APP侧调用mClient就像调用Client一模一样的，底层Binder帮你处理了。一种RPC的思想。</