本文翻译自Android官网的内容:https://source.android.com/devices/graphics
概述
Android framework提供了多种2D和3DGraphics渲染API,这些接口API与厂商的Graphics驱动实现交互,所以有必要对这些API的工作原理和进行深入的了解。此页面介绍了Graphics HAL层,HAL层构建于这些驱动之上。
应用程序开发者可以通过两种方式将一张图片绘制到屏幕:Canvas 或 OpenGL。参考Android Graphics -2 架构概述 关于Android Graphics 组件的详细描述。
android.graphics.Canvas(画布) 是一个2D图形API,并且在开发者中非常流行。在Android中画布操作可以绘制所有的原生的和自定义的View(android.view.Views)。在Android中,硬件加速(hardware-accelerated)Canvas API是一个高端的操作,它使用一个叫做OpenGLRenderer绘制库来进行绘制,这个库可以把画布操作翻译成OpenGL操作,从而使他们可以使用GPU。
自Android 4.0开始,硬件加速Canvas就默认支持了。因此Android4.0以后的设备必须拥有一个支持OpenGL ES 2.0 的硬件GPU。参考https://developer.android.com/guide/topics/graphics/hardware-accel.html ,此链接描述了硬件加速的工作原理以及它和软件绘制的区别。
除了Canvas外,另一个主要方法是使用OpenGL ES直接把内容渲染到surface上。Android提供了android.opengl包,开发者可以用它来调用到他们的GL实现,使用SDK或者NDK提供的native API。
Android开发者可以使用“drawElements Quality Program” 来对OpenGL ES功能进行测试,简称为deqp。
Android Graphics 组件
无论开发者使用哪种接口,所有的内容都会被渲染到“Surface”之上。surface表示一个buffer queue的生产者端,buffer queue通常被SurfaceFlinger消费。Android平台上被创建的每一个窗口都会有一个Surface对应。所有完场渲染的可见Surface都会被SurfaceFlinger合成到display上去显示。
下图是Graphics的核心组件
图1. Surface如何渲染
关于上图的描述如下:
图像流生产者(Image Steam Producers)
一个图像流生产者表示可以产生图像buffer的任何组件。例如包括Open ES,Canvas 2D 和mediaserver vide decoders。
图像流消费者(Image Stream Consumers)
大部分情况下,通常的图像流消费者是SurfaceFlinger,SurfaceFlinger是一个系统服务用于消费当前的可见surface并且将他们合成到display,前提是使用Window Manager提供的参数。SurfaceFlinger是唯一可以修改显示内容的服务。SurfaceFlinger使用OpenGL和硬件合成器来来合成一组surface。
其他的OpenGL ES应用也可以消耗图像流,例如Camera app消耗了camera 预览图像流。非GL应用也可以成为消费者,例如ImageReader 类。
窗口管理器(Window Manager)
控制窗口的Android系统服务,窗口是view的容器。一个窗口总是对应一个surface。这个服务监督窗口的生命周期,输入和焦点事件,屏幕方向,透明度,动画,位置,形变,z-order等等。窗口管理器发送所有的window元数据到SurfaceFlinger,从而SurfaceFlinger可以使用这些数据来合成surface。
硬件合成器(Hardware Composer)
显示子系统的硬件抽象。SurfaceFlinger可以授权一些特定的合成工作到硬件合成器,从而降低OpenGL和GPU的工作负担。SurfaceFlinger仅仅是另一个OpenGL ES客户端。所以例如当SurfaceFlinger积极地将一个或多个buffer合成到第三个时,它使用的是OpenGL ES。这使得在合成时比用GPU进行全部的计算功耗更低。
硬件合成器抽象层负责一半的工作并且是Android图行渲染的中心点。硬件合成器需要支持event,例如VSYNC(另一个时间是HDMI的热插拔事件支持)。
Gralloc
图形内存分配器,用于分配图像生产者请求的内存。详细内容,参考:https://source.android.com/devices/graphics/architecture.html#gralloc_HAL
数据流
下图表述了Android的图形管线:
图2. Android的图形数据流
图形的左侧是渲染器生产的graphics buffer,例如home界面,状态栏,system UI。SurfaceFlinger是排版者,硬件合成器是合成者。
BufferQueue
BufferQueue在Android图形组件之间起到粘合作用。这是一对queue,用于实现从生产者到消费者的恒定循环。一旦生产者交出buffer,SurfaceFlinger就承担起将所有东西合成到display的责任。
下图是BufferQueue的通信过程
图3. BufferQueue通信过程
BufferQueue包含把图像流生产者和图像流消费者绑定到一起的逻辑。一些图像生产者的例子是camera预览,是由camera HAL或者OpenGL ES游戏产生的。一些图像消费者的例子是SurfaceFlinge或者某些显示OpenGL ES 流的app,例如camera aoo显示camera取景器(viewfinder)。
BufferQueue是一个讲buffer池(pool)和一个队列组合在一起的数据结构,并且使用Binder IPC来传递buffer。名词生产者接口,或者说你传给想要生成graphic buffer的人的内容,叫做IGraphicBufferProducer(SurfaceTexture的一部分)。BufferQueue通常用于渲染到Surface、使用GL Consumer来消耗等其他任务。BufferQueue有三种不通的操作模式:
类同步模式(Synchronous-like mode)- BufferQueue默认使用这种模式,在这种模式下,从生产者那里得到的每个buffer都会进入消耗者,不会丢弃任何buffer。如果生产者太快,生产buffer的速度快于排出的速度,那么他将被block,直到buffer空闲。
非阻塞模式(Non-blocking mode)- BufferQueue还可以在非阻塞模式下运行,在这种模式下,它宁愿发生错误也不会等待buffer。在此模式下也不会丢弃任何buffer。这对于避免程序软件中隐藏的死锁有所帮助,这些死锁往往是因为framework中复杂的依赖关系导致的。
放弃模式 (Discard mode)- 最后,BufferQueue可以配置成宁愿放弃老的buffer也不会产生错误或等待。例如,执行一次到texture view的渲染,绘制要尽可能得快,有些buffer可能被丢弃。
同步框架 (Synchronization framework)
因为Android graphics没有明确的并行性,vendor长期以来在自己的驱动中实施隐式的同步策略。使用Android Graphics同步框架后这将不再需要。参考详细的介绍:https://source.android.com/devices/graphics/implement-vsync.html#explicit_synchronization
同步框架明确地描述了不同异步操作之间的依赖关系。此框架提供了一组简单的API,让组件在buffer被释放后发出信号。同时还允许从kernel到userspace或 userspace的进程之间传递同步原语。
举个例子,应用程序可以将需要执行的工作放在GPU中排队,然后GPU开始绘制图像。尽管图像还没有绘制到内存中,buffer的指针仍然可以与一个fence被传到窗口合成器,fence可以表示GPU什么时候完成工作。然后窗口合成器可以提前开始工作,并将工作移交给display controller。一旦GPU完成工作,display controller可以立马进行图像的显示。
同步框架还可以允许实现着在自己的硬件组件中使用同步资源。最后,此框架提供Graphics管线的可视性来帮助调试。