Android Graphic 架构
Android Graphic 架构
这篇文章中,我们会展示android Graphic 的架构.
- Androidframework
我们知道Android framework 提供了两大类graphicrender API.一是用Canvas 类也称2D renderer另外一种是直接用OpenGL 接口, 通常称为3D renderer path app. 下图是用2Drenderer path 的 Graphic stack.
通常这里有两种底层库来支撑2D renderer path app.
- Skia(Libskia.so).Android SW render engine.
- HWUI(libhwui.so)HWUI 是把Canvas 的drawing 操作转换为OpenGL 的操作(OpenGLRenderer).这样就可以用GPU来加速Canvas 的drawing.
- 现在在HUWI 是默认enable的.
- 其通常的调用流程如下:
- 下图是3D renderer path 的Androidapp stack.
Activiy 能直接创建GLSurfaceView并通过调用OpenGL ES 接口android.opengl.*把view 画到surface 上.一般来说其底层库可以是SW 的实现也可以是HW 的实现.当前Android 原生的code 就有SW的实现pixelflinger(只实现了OpenGL ES 1.0 ),Google 要求所有的芯片厂商需要有OpenGL 的HW 实现.其流程简单如下:
2. Android Graphic component
主要有以下compoent:
- Surface
- 在android graphic 系统中,所有的内容都画在”surface”上.对android graphic 系统我们可以看作生产者/消费者模型.对生成者来说,就是产生图像如button,image,video frame 等.而图像的消费者往往是android graphic 的另一个重要compoent --surfaceflinger.我们每创建一个window,就创建了一个surface.
- Surfaceflinger
- Surfaceflinger是一个系统后台服务程序,其主要作用是把所有可见的surface合成到LCD 上.
- Image Stream Producers
- 图像的生成者.如Canvas, OpenGL ES 和video player 等.
- Image Stream Consumers
- 图像的消费者.最主要的消费者是surfaceflinger. OpenGL ES APP 也有可能成为图像的消费者,如camera app 的preview 就是camera sensor 图像输出的消费者.一些非GL 的应用也可能成为图像的消费者,如imageReader 等.
- Window Manager
- Androd的后台servcie,驻留在system server 中.其主要管理android中的window. window 是view的容器并且和surface相关联.一个window 对应一个surface.除此之外,window manager 还管理input 事件的分发,焦点事件的管理,window的z-order,位置,animation等.Window manager 把window的meta 信息发送给surfaceflinger.Surfacefinger 根据这些meta 信息把所有可见的window 合成到LCD 上并显示.
- Gralloc
- Graphic的memroy的分配和管理.
- Hardware Composer
- 其主要完成surface的合成.在andorid 系统中,有两种合成方式.一种是HW,另一种是GPU. HW的合成是比较昂贵的操作, 所以在大多硬件平台上只支持四个layer (surface) 的合成.超过四个layer就需要GPU加入.
- 另外,Hardware composer 另外一个重要的工作是必须支持VSYNC 事件,HDMI 的hotplug plug-and-play事件.
3. Data flow
下图是典型的android 的graphic的pipeline.
我们知道在androidapp 中通常有4个layer.Navigator bar,System UI, background, app views. 在上图中,有一个layer 是由CPU 合成,有3个layer 是由HW composer 合成.
Buffer Queue 在android graphic 中占有重要的地位. 它有一个buffer pool通常只用3个buffer(在app看来这个buffer queue 就是surface.在surfaceflinger看来就是layer).它通过IPCbinder 把图像的生产者和消费者联系了起来.当生产者(app)画好图片后,会通知消费者(Surfaceflinger).消费者(surfaceflinger)会在一定的时间把画好的图片经HWcomposer 或GPU合成后显示在LCD上.BufferQueue有三种工作模式.
- 阻塞模式
- 这是buffer queue的默认工作模式.生产者产生一个frame,消费者用掉一个frame.没有frame被丢失.其缺点是如果生产者画得太快,或者说需要的buffer过多,而其消费者处理太慢,当buffer 的数量(默认最多32个buffer)不够用时,生产者会等待.
- 非阻塞模式
- Buffer queue 可以工作在非阻塞模式.如果出现消费不能dequeue buffer 时, 直接返回一个错误而不是等待到一个可用的buffer为止.这样做的好处是可以避免app死锁或者(ANR问题).
- Discard mode
- BufferQueue 可以工作在discard mode.在这种模式下, 当buffer 不够时, 老的buffer会被discard.
其流程如下:
- 当生产者需要画图像时,首先需要向window(surface) 申请dequeuer 一个buffer.
- 生产者画好图像后,把buffer 返回到buffer queue中,并通知消费者已经有一个图像可以使用.
- 在适当的时候(Vsync-sf),消费者从buffer queue 中获取可用的buffer(已经画好图像),并且处理该图像(合成并显示到LCD)
- 消费这对图像处理完毕,然后把buffer release 到bufferqueue 中.
