Android 图形系统（Graphics）

最近开发遇到问题，ImageView设置visibility未显示。这时View已经post到主线程显示，并且父view可以正常显示。怀疑是系统显示问题于是对显示系统进行了学习梳理。

本文将从三个方面介绍Android 图形系统。

一、图形系统简介

1.1 Android 绘制基础

1. 系统绘制的是什么？
   图形缓冲区，也叫Buffer 。应用层的View树最终会转换成Buffer，置于BufferQueue中被绘制。
2. 绘制的位置在哪里？
   应用端会把一切内容渲染到surface上，最终显示到LCD/OLED显示屏

3. 如何把图像绘制到屏幕？
   

   绘制任务由应用发起，通过跨进程方式把Buffer传到FW层，由FW层中的SurfaceFlinger服务调用Linux 硬件驱动最终绘制到硬件屏幕上。
   

1.2 Android 图形引擎

图形系统提供绘图和图形处理支持。
Android 框架提供了各种用于 2D 和 3D 图形渲染的 API、图片解码库，以及各种Driver支持。
• 绘图API：2D引擎 Skia，3D引擎 OpenGL ES，RenderScript，OpenCV和Vulkan。
• 图片解码库：jpg，png，gif等。

应用开发者可通过三种方式将图像绘制到屏幕:
• Canvas : 2D图形API，Android View树实际的绘制者。
• OpenGL ES : 嵌入式设备的OpenGL 三维图形API子集。
• Vulkan :跨平台的2D和3D绘图引擎,Android 7.0后支持，NDK。

1.3 图形系统架构

整个图形系统架构是一个生产者和消费者模式，五层依次介绍：

1. Image Stream Producers :
   • view每次执行lockCanvas->draw->unlockCanvas，会存入一帧数据进入BufferQueue中
2. Native Framework:
   • Buffer的生成和BufferQueue数据跨进程传递
3. WindowManager:
   • 计算窗口大小，位置等，同时也会将相应的参数设置给SurfaceFlinger，比如Window的z-order和大小等。
4. Image stream consumers :
   • SurfaceFlinger，消耗当前可见的 Surface，作为Layer的管理着，同是也是BufferQueue的消费者，当每个Layer的生产者绘制完一帧时，会通知SurfaceFlinger。
5. HAL:
   • Gralloc: 图形内存分配器,分配图像生产方请求的内存
   • Hardware Composer:硬件混合渲染器,合成SurfaceFlinger里面的Layer，并显示

二、图形组件与绘制流程

2.1 2D/3D绘图流程

2D rendering path

2D绘制：Canvas api / view 的子类 (button ,list)/自定义view

3D rendering path

3D绘制：应用直接使用OpenGL 接口绘制图形(PixelFlinger对应的是openGl 1.0 ，GUP driver 对应的是2.0和3.0)

所有情况下的绘图都渲染到一个包含 GraphicBuffer的Surface上，当一块 Surface 显示在屏幕上时，就是用户所看到的窗口。

2.2 Canvas/ Skia/ hwui/ OpenGL ES

• Canvas：画布，2D图形API，Android View树实际的渲染者。
• Skia绘制：Android4.0之前默认使用，主线程通过CPU完成绘图指令操作，在复杂场景下单帧容易超过16ms导致卡顿。

• hwui硬件加速绘制：使用GUP绘制, Android4.0及以后默认开启硬件加速渲染。5.0以后把渲染拆分成了两个线程：主线程负责记录渲染指令，渲染线程负责通过OpenGL ES完成渲染，两个线程并发执行。

注意：并非所有 2D 绘制操作都支持硬件加速，可能会影响部分自定义视图或绘制调用。详情见：Android硬件加速
• OpenGL ES ： OpenGL 三维图形 API 的子集，针对手机、PDA和游戏主机等嵌入式设备而设计。在异步线程直接通过OpenGL ES进行渲染，一般适用于游戏、视频播放等独立场景

2.3 图形组件WMS

WindowManagerService（WMS）窗口管理服务，管理系统中所有的窗口。
• 管理window （view的容器）
• Window与surface对应，一块显示区域。添加一个window，就是 WMS 为其分配一块 Surface 的过程。

• WindowManager为 SurfaceFlinger 提供窗口元数据（window metadata）
Android setContentView就是将View设置到widow上。
WMS角色在整个流程的位置：
这里有一个wm命令可以看到window的信息：对手机分辨率、像素密度、显示区域进行设置的命令

2.4 Surface与相关的view

Google 在Android source官网提示：

“ What every developer should know about surfaces, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger, and Vulkan.”

这里就对这些控件进行简单介绍：

Surface

Surface : Handle onto a raw buffer that is being managed by the screen compositor.
Surface 对应一块屏幕缓冲区。生产者是： SurfaceTexture、MediaRecorder 等，消费者是： OpenGL、MediaPlayer 或 CameraDevice等。每个window对应一个Surface。Canvas或OpenGL ES等最终都渲染到Surface上。
• Flutter在Android平台上也是直接渲染到Surface。例如：一个Activity/Dialog都是一个Surface，它承载了上层的图形数据，与SurfaceFlinger侧的Layer相对应。

屏幕上的每一帧图像都是多个surface合成后的结果：

Canvas rendering：

Canvas（画布）实现由 Skia 图形库提供。为了确保两个客户端不会同时更新某个缓冲区，使用以下命令处理画布锁：

SurfaceView和SurfaceHolder

SurfaceView

使用双缓冲机制，有自己的 surface，View只是一个透明的占位符，Surface可以在后台线程中绘制。双缓冲机制提高渲染效率，独立线程
绘制，提升流畅性。适合一些场景：需要界面迅速更新、UI绘制时间长、对帧率要求较高的情况。

SurfaceHolder

提供访问和控制Surface 相关的方法 。通过SurfaceView的getHolder()函数可以获取SurfaceHolder对象，Surface 就在SurfaceHolder对象内。
addCallback(SurfaceHolder.Callbackcallback) /Canvas lockCanvas() /unlockCanvasAndPost(Canvascanvas)

SurfaceTexture/ GLSurfaceView/ TextureView

SurfaceTexture： Surface 和 OpenGL ES (GLES) 纹理（Texture）的组合。将图像流转为 OpenGL 外部纹理。
TextureView：持有 SurfaceTexture，将图像处理为 OpenGL 纹理更新到 HardwareLayer。
GLSurfaceView：加入 EGL 管理，自带 GL 上下文和 GL 渲染线程
这些View通常涉及到Android音视频相关，需要高效的渲染能力。如下面的SurfaceTexture在camera中的应用。

GraphicBuffer / BufferQueue

GraphicBuffer

简称Buffer, 一个Buffer包含一帧图像，Buffer由gralloc分配和回收。Buffer 属性包含：width, height, format, usage等

BufferQueue

BufferQueue 的引入是为了解决显示和性能问题。
• Surface属于APP进程，Layer属于系统进程，如果它们之间只用一个Buffer，会存在显示和性能问题。
• 一些Buffer用于绘制，一些Buffer用于显示，双方处理完之后，交换一下Buffer，提高效率。
• BufferQueue中包含多个Buffer对象。

Android图形系统包含了两对生产者和消费者模型，它们都通过BufferQueue进行连接：
1.Canvas和OpenGL ES生产图形数据，SurfaceFlinger消费图形数据。
2.SurfaceFlinger合成所有图层的图形数据，Display显示合成结果。

SurfaceFlinger

code：frameworks/native/services/surfaceflinger
• Surface表示APP进程的一个窗口，承载了窗口的图形数据。
• SurfaceFlinger是系统进程合成所有窗口的系统服务，负责合成所有Surface提供的图形数据，然后送显到屏幕。
• SurfaceFlinger既是上层应用的消费者，又是Display的生产者，起到了承上启下的作用。
数据流：

合成示意图：

SurfaceFlinger的启动流程：
Surface Flinger 服务由init进程启动，一个高优先级的本地守护进程。SurfaceFlinger启动流程

Android系统的启动流程：
可以看到SurfaceFlinger的启动是和Zygote进程启动位于同一流程中。

SurfaceFlinger API

Vsync机制

在介绍Vsync机制之前先介绍两个重要概念：

屏幕刷新率：屏幕每秒钟可以刷新多少次。60HZ刷新率，16.7ms刷新一次。（120HZ/8.3ms），硬件指标。
GPU 绘制帧率：GPU 每秒能够合成绘制多少帧。

软件层触发 View 绘制的时机是随机的，当下一次屏幕刷新时，屏幕从 Frame Buffer 中拿到的数据还是“帧1”的数据，导致“丢帧”。

每隔 16ms 硬件层发出 vsync 信号，应用层接收到此信号后会触发UI 的渲染流程，同时 vsync 信号也会触发 SurfaceFlinger 读取Buffer 中的数据，进行合成显示到屏幕上。

总结：Vsync机制将 CPU 和 GPU 的开始时间与屏幕刷新强行拖拽到同一起跑线

三、Graphics问题总结

Android提供的Graphics流程相对比较复杂对其进行具象后的流程如下两张图所示：