Android中有几个很重要的概念Surface, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView与SurfaceFlinger。
这篇文章会介绍Android图形架构的基本构成以及它们是如何在程序framework与多媒体系统中运作的。核心关注点是,图形数据的buffer是如何在系统中传递的。如果你曾经好奇过SurfaceView与TextureView的工作方式,或者是想知道Surface与EGLSurface是如何交互的,那么这篇文章将给你解答这些疑问。You’ve come to the right place.
大多数时候,我们都不需要了解这些类的使用原理,但是学习这些它们的工作原理可以为我们提供一种Sense,用来更加高效的工作。所以这里我们学习它们是如何工作的,而不仅仅是它们是如何使用的。
BufferQueue and gralloc
BufferQueue and grallocGraphiccal的核心是BufferQueue,它的角色是连接产生图形数据的生产者与显示数据的消费者。生产者与消费者可以再两个不同的进程,那么数据在系统中进行传递就依赖于BufferQueue。
基础的用法是很直接简单的。生产者获取到一个buffer,制定了宽,高,pixel format与usage flags之后,再放到queue中。消费者获取到buffer,消费数据后,把buffer返回到queue中。
- 生产者:dequeueBuffer() -> queueBuffer()
- 消费者:acquireBuffer() -> releaseBuffer()
目前很多Android设备已经开始支持“Sync framework”。这使得系统可以结合hardware组件对graphic data做异步的操作。例如,生产者再rendering完成之前就开始提交一系列的OpenGL ES的绘制命令并参与到输出排队buffer中。Buffer队列中设置有多道栅栏,用来同步生产者与消费者的工作。这样的一个方法可以减少buffer数据在系统中传递的延迟并提升吞吐量。
队列的一些特性,例如最大支持Hold住的数据量,取决于生产者与消费者的共同作用。
BufferQueue的责任是分配Buffer,而Buffer则用来Hold Data的部分。
gralloc HAL
真正实行buffer allocation的操作是通过gralloc来实现的,里面的alloc()方法会根据buffer的参数:宽高,pixel format与usage flags等,进行操作。
gralloc不仅仅是native heap上分配内存的另外一个方式。通常alloc取决于usage flags,例如
- how often the memory will be accessed from software (CPU)
- how often the memory will be accessed from hardware (GPU)
- whether the memory will be used as an OpenGL ES (“GLES”) texture(质地)
- whether the memory will be used by a video encoder
例如,如果你指定format RGBA8888,并且这个buffer可以从software层进行访问,那么alloc会使用R-G-B-A的顺序创建每一个pixel.如果你指定buffer只会被hardware访问并且会作为GLES texture的组成部分,那么alloc可以使用BGRA的顺序,这样效率更高。
SurfaceFlinger and Hardware Composer
如何把那些数据绘制到屏幕上,需要使用到SurfaceFlinger与Hardware Composer HAL。
SurfaceFlinger的作用是接收来自各处的数据,进行混合编制之后,然后进行显示。
当app作为foreground时,WindowManager Service会请求SurfaceFlinger绘制一个surface。SurfaceFlinger会创建一个”layer” - 它的主要组成部分是BufferQueue。此时SurfaceFlinger扮演了消费者的角色。生产者的数据是通过WindowManager传递到app,WindowManager可以直接发送frames给SurfaceFlinger。其实可以把SurfaceFlinger理解为LayerFlinger。
对于大多数apps来说,在任何时刻,屏幕上会有三个layer。“Status Bar”是在屏幕的最上层,“navigation bar”在屏幕的底部或者侧边,另外一层是app UI layer。一些app可能拥有更多或者更少的layer。例如默认的home app,对于wallpaper有单独设置一层layer,全屏游戏的应用会隐藏status bar的layer。Each layer都可以单独进行更新。Status与Navigation Bar是由系统process进行绘制的。app layer是由app进行绘制的。它们之间是相互独立的。
设备显示屏以固定的频率刷新屏幕,对于手机与平板来说,通常是60fps。刷新的频率有时是不固定的。
当SurfaceFlinger接收到VSYNC刷新信号时,会遍历所有的layers,寻找可以使用的新的buffers。如果找到新的buffer,那么就获取它,否则继续使用前面获取到得buffer。SurfaceFlinger总是需要有内容可以显示,所以它会持续hold住buffer。如果没有新的buffer提交到layer上,这个layer就会被SurfaceFlinger所忽略。
一旦SurfaceFlinger收集到了可见layer的所有buffers,它会请求Hardware composer如何进行composition的操作。
Hardware Composer
Hardware Composer HAL(HWC)是从3.0开始才被引入的。它首要的目的是结合可用的硬件,判断选择最有效的方式用来composite buffers。这部分的功能通常是硬件OEM厂商实现的。
举例说明2种compossite的方式:
- 先画好App的UI,然后把StatusBar与BottomBar的部分绘制到UI之上,最后把这些组合好的buffer送给硬件进行显示。
- 分别传递三部分的Buffer,告诉硬件从不同的屏幕区域读取不同的buffer。 显然第2种方式会更有效率。
因为不同的设备处理能力不一样,每一个layer是否需要旋转,是否有限制的显示位置等等问题。所以HWC的工作方式是这样的:
- SurfaceFlinger提供给HWC一个完整的layer list,并且询问系统:该如何处理这些layers?
- HWC通过把每一个layer标记为”overlay”或者“GLES Composition”来作为应答。
- SurfaceFlinger对那些标记为GLES Composition的layer,传递buffer给HWC,并且让HWC来处理。
Overlay的方式比GLES composition的方式效率要低很多,特别是Overlay的内容为transparent时。
The Need for Triple-Buffering
- Double-buffering
为了避免在显示上出现断层,系统需要是double-buffered: front buffer显示的同时,back buffer正在准备。 假设frame N正在显示,那么为了在下一个VSYNC信号中显示frame N+1,此时frame N+1将被SurfaceFlinger提前获取到。当VSYNC信号到达时,HWC会flip buffer。当app需要绘制frame N+2到buffer时,SurfaceFlinger会遍历每个layer寻找是否有新的buffer,此时没有找到任何新的buffer,因此再下一个VSYNC中再次准备显示frame N+1,过了一点时间之后,app结束了rendering frame N+2并且进入了SurfaceFlinger的队列,可是此时已经太晚了,这种双重buffer的方式效率并不够高。
- Triple-buffering
在VSYNC之前,frame N正在显示,frame N+1已经composited并且准备被显示,frame N+2已经在队列中并且准备好了被SurfaceFlinger获取。当屏幕flip时,buffers可以进行rotate,并且不产生bubble。
Surface and SurfaceHolder
Surface通常作为buffer queue的生产者,同时SurfaceFlinger作为消费者。 用来显示Surface的BufferQueue通常是triple-buffering的,但是buffers却是按需分配的。
Canvas Rendering
曾经一段时间,所有的rendering渲染操作都是在软件层进行的。在今天,你也是可以这样做。在低版本的系统中,在软件层的渲染是通过使用Skia的图像库来实现的。如果你想要绘制一个矩形,调用一个库函数,在buffer中设置恰当的bytes数据。为了确保buffer不会在同一个时刻被两个Clients所更新,或者在显示时被写入,你必须对buffer进行加锁操作。lockCanvas()
方法可以锁住buffer并且返回一个Canvas用来进行绘制。unlockCanvasAndPost()
方法可以解锁buffer并且发送buffer数据给compositor进行组合。
随着时间的推移,带有3D引擎的设备出现了,Android围绕OpenGL ES做了修改与适应。然而,为了兼容旧的API,增加了硬件加速Canvas API。
当你为了访问Canvas而锁住Surface时,CPU渲染器会于BufferQueue的生产者建立连接,指导Surface被销毁时才回断开。大多数其他的生产者(例如GLES)可以与Surface进行断开连接与重新连接,但是Canvas-based的CPU渲染器不可以。这意味着如果你不针对一个Canvas进行加锁的话,是不可以在Surface上使用GLES进行绘制,也不可以给Surface发送来自视频解码器中的数据帧。
生产者从BufferQueue中第一次请求一个buffer时,这个buffer是初始化分配为0的。初始化是非常有必要的,避免在不同进程中出现共享数据的意外错误。当你重用一个buffer时,之前的内容还是处于显示中。如果你重复的调用lockCanvas()
与unlockCanvasAndPost()
却没有绘制任何内容,你将会在前一个frame与渲染的frame中进行循环。
Surface的lock/unlock代码保持了前一个渲染buffer的reference。如果你在锁定Surface的时候指定了一块dirty的区域,它会从之前的buffer中copy一份non-dirty的pixel数据过来。此时buffer将会机会对等的被SurfaceFlinger或者HWC进行处理,但是因为我们仅仅是需要进行读取的操作,所以没有必要进行互斥的访问。
不通过Canvas(non-Canvas)的方式对一个Surface直接进行绘制的主要方式是通过OpenGL ES.这部分的内容会在下面被讲解。
SurfaceHolder
连接Surface与SurfaceView的是SurfaceHolder。最开始的想法是Surface代表了原始的数据buffer,那么SurfaceHolder是app用来追踪Surface的一些上层的信息,例如dimensions与format。Java语言定义好了潜在可能的native的实现接口。虽然有争议部分API是不会再可能被使用到的,可是却一直遗留在Public API中没有移除。
通常来说,对于一个View的任何操作都回触发SurfaceHolder。一些其他的APIs,例如MediaCodec,可以直接操作Surface本身。你也可以从SurfaceHolder中获取到Surface。
获取与设置Surface参数的APIs,例如size和format,都是通过SurfaceHolder来实现的。
EGLSurface and OpenGL ES
OpenGL ES定义了一个API用来渲染图形。为了是得GLES可以在各种平台上工作,它设计成可以和一个库进行结合的方式来工作。这个库知道如何通过操作系统创建与访问窗口。在Android中使用的库叫做EGL。如果你想要绘制textured polygons(多边形,模块),你可以使用GLES的方法。如果你想要把渲染绘制到屏幕上,你可以使用EGL的方法。
在开始使用GLES之前,你需要创建一个GL context。在EGL中,这意味着创建一个EGLContext与一个EGLSurface。GLES的操作是作用在当前的context上的,当前的context保存在当前thread中,这个context是不能传递的。这意味着你必需注意渲染的动作执行在哪个线程,并且在那个线程中的context是哪个。
EGLSurface可以通过EGL(执行pbuffer)来分配一个buffer,或者通过操作系统来做一个窗口的分配。EGL window surface是通过eglCreateWindowSurface()
方法来创建的。这个方法会使用一个window object作为参数,这个window object在android上可以是一个SurfaceView,一个SurfaceTexture,一个surfaceHolder或者是一个Surface,这些对象的内部都拥有一个BufferQuueue。当你执行了那个方法调用之后,EGL创建一个新的EGLSurface对象,并把这个对象与生产者的BufferQuueue的接口建立连接。
EGL并没有提供lock/unlock的方法。你需要列出绘制的命令然后执行eglSwapBuffer()
来提交当前frame。这个方法名本意是描述传统的front-back buffer的swap操作,但是实际上再后续的实现中又可能会有差异。
在同一时刻,只能有一个EGLSurface与Surface进行结合,你只能有一个生产者连接到BufferQueue,但是如果你销毁了EGLSurface,那么就与BufferQueue连接断开,此时可以允许其他组件进行连接。
一个EGLSurface在同一时刻必须只能存在于一个Thread中。但是一个Thread可以切换多个不同的EGLSurface。
讨论到EGLSurface时最通常的误解是认为这只是Surface的某个方面(例如SurfaceHolder).它们实际上是有关联却相互独立的。你可以在ELGSurface上绘制没有被Surface hold住得部分,你也可以使用Surface的时候不要用EGL。EGLSurface只为GLES提供了一个绘制的地方。
SurfaceView and GLSurfaceView
从现在起,我们可以探讨下一些更上层的组件,以及它们是如何与底层的组件进行适配的。
Android app Framework UI是基于hierarchy中的View进行搭建的。大多数的文章都没有涉及到细节的讨论,但是了解UI组件是如何经过一系列复杂的measurement与layout然后适配到一个矩形区域是非常有意义的。当app来到forground的时候,所有可见的view对象都将被SurfaceFlinger渲染到由WindowManager创建的Surface中。Layout与rendering是执行在app的UI Thread的。
无论你又多少的layouts与Views,所有的对象都是被绘制到同一个Buffer中。无论Views是否开启了hardware-accelerated都是一样的。
SurfaceView的参数和其他的View一样,你可以设置position与size。但是讨论到render的时候,SurfaceView的contents是透明的。SurfaceView在View中只是一个透明的占位区域。
当SurfaceView可见时,WindowManager会请求SurfaceFlinger创建一个新的Surface。(这个过程不是同步的,所以需要实现Surface被创建的回调用来获取到信息)。默认情况下,新创建的Surface是在app UI Surface的下层(后面),但是这个默认的Z-ordering可以被override,设置为在app UI的上面(Top表面)。
渲染到Surface上的任何数据都是由SurfaceFlinger进行组合的,而不是由app完成。这就是SurfaceView真正牛B的地方:绘制到SurfaceView上的内容可以由单独的Thread或者Proces进行操作。你可以忽略UI Thread,但是你还是需要保持SurfaceView与Activity的生命周期一致,整个SurfaceView是和app UI还有其他被硬件加速的layer是共同协作的。
请注意,相对于BufferQueue来说,Surface是生产者,而SurfaceFlinger layer是消费者。你可以使用任何合适的方法来更新Surface,只要使得Surface可以作为BufferQueue的生产者。你可以使用Surface提供的Canvas的功能,添加一个EGLSurface并使用GLES进行绘制并且使用MeidaCodec的Video decoder对Surface进行写操作。
GLSurfaceView
GLSurfaceView提供了一些帮助类用来协助管理EGL contexts,线程间的交互,与Activity生命周期的互动。
GLSurfaceView创建一个线程用来渲染与配置EGL context。当Activity暂停时,状态会被自动清除。
在大多数情况下,GLSurfaceView是非常有用的并且可以和GLES进行协作。在某些情形下,使用它是个好的选择。
SurfaceTexture
SurfaceTexture是在Android 3.0才被引入的。和SurfaceView的概念类似(Surface与View的结合体),SurfaceTexture是Surface与GLES texture的结合体。
当你创建一个SurfaceTexture时,你会创建一个BufferQueue,app此时扮演了消费者的角色。当新的buffer被生产者加入队列时,你的app会通过onFrameAvailable()
的回调得到通知。updateTextureImage()
方法会释放前面hold住得buffer,从队列中请求一个新的buffer,并执行一些EGL的方法使得buffer对于GLES来说可以作为一个external texture。
External texture(GL_TEXTURE_EXTERNAL_OES
)与GLES(GL_TEXTURE_2D
)创建的texture并不相同。你必须对你的渲染器做一些不同的配置,同时有些东西是不能修改的。但是最主要的是:你可以把从BufferQueue中获取到的数据直接渲染为textured模型。
你可能好奇我们如何能够确保在buffer中的数据格式是能够被GLES可以识别的。当SurfaceTexture创建了BufferQueue,它会设置消费者的usge flag为GRALLOC_USAGE_HW_TEXTURE
,确保被gralloc创建的任何buffer可以被GLES所使用。
因为SurfaceTexture是需要和EGL context进行交互的,你需要注意从正确的线程中调用SurfaceTexture的方法。
每一个传递的Buffer都不仅仅是buffer本身,还包含了一个timestamp与transformation的信息。
提供transformation的信息是为了提供效率。在某些情况下,对于消费者来说,source data可能是错误的orientation,我们没有在发送数据之前就做方向矫正,而是把数据与它的角度信息一起进行传递。transformation matrix的信息可以在数据被使用的时候与其他transformation信息进行整合,这样能够最大化的减少额外的开销。
timestamp也是很有帮助的。例如,假设你连接到了一个生产者的接口上(通过setPreviewTexture()
连接到Camera的输出接口),如果你想要创建一个Video,你需要为每一帧数据设置当前的timestamp,这个timestamp应该是基于frame被captured来计算的,而不是buffer被接收到得时间。这个timestamp是被camera的代码进行设置的,这样确保了timestamp更加具有连续性。
SurfaceTexture and Surface
如果你仔细查看API文档,你将会发现:对于程序来说,创建一个空白Surface的唯一方式是通过它的构造函数来实现,这个构造函数使用SufaceTexture作为唯一的参数。(在API 11之前,还没有public的surface构造器)。如果你把SurfaceTexture作为Surface与Texture的结合体,只有唯一的构造方法就会成为一个缺点。
其实SurfaceTexture可以称为GLConsumer,这能够更加准确的描述它扮演的角色:作为BufferQueue的owner与comsumer。当你从SurfaceTexture中创建一个Surface时,从SurfaceTexture的BufferQueue的角度来看,你是在创建一个对象用来作为生产者。
TextureView
TextureView是Android 4.0才开始被引入的。它是很复杂的一个View对象,它会组合View与SurfaceTexture。
SurfaceTexture被称为一个GL comsumer,它会消费图形数据的buffer并使得他们作为texture的形式存在。TextureView对SurfaceTexture做了包装,取代了响应回调的职责并负责请求新的buffer。新的buffer会导致TextureView进行invalidate的操作。当请求绘制时,TextureView使用最近接收到得buffer作为它的source data,渲染时不用考虑View的任何状态值。
你可以使用GLES对TextureView进行渲染,就像SurfaceView一样。仅仅是把SurfaceTexture传递到EGL的window创建的方法里面。然而这样做,暴露了一个隐藏的问题。
在前面我们有提到,BufferQueues可以在不同的进程中传递buffers。当使用GLES渲染TextureView的时候,producer与consumer是在同一个进程,并且他们可能会执行在同一个thread。假设我们从UI Thread快速的提交了一连串的buffers。EGL buffer swap的方法会需要从BufferQueue中执行dequeue的操作,他会一直停留直到有一个buffer可用。可是直到consumer请求一个buffer进行渲染之前,不会有任何的buffer可用,而且这件事情也发生在UI Thread。所以这就出现问题了。
解决方案是使得BufferQueue确保总是有一个可用的buffer用来进行dequeue,这样避免buffer swap会被卡住。其中一个方法是当新的buffer进行queued操作时,BufferQueue能够discard前一个queued的buffer,并且确保queue中存在的最少buffer数同时限制加入队列中得最多的buffer个数。(如果你的队列中,有三个buffers,消费者一次请求了所有的三个buffer,那么就没有buffer用来出队了,buffer swap的调用会被卡住或者失败,隐藏我们需要阻止消费者一次请求超过2个buffer。)错失Buffer通常是不希望发生的事情,因此只有在特殊情况下才允许发生,例如生产者与消费者在同一个Process。
SurfaceView or TextureView
SurfaceView与TextureView扮演了相似的角色,但在实现原理上却有着非常大的差异。选择哪个才是最好的需要知道如何进行权衡利弊。
TextureView是View hierarchy中一个普通的成员,它的行为和其他View类似,可以叠加到其他View上也可以被其他View进行重叠覆盖。你可以对它执行任意的transformation,也可以通过简单的API调用获取其中的数据内容。
TextureView的主要缺陷是composition步骤的效率。对于SurfaceView来说,数据内容是由SurfaceFlinger绘制到单独的一个layer上的,完美的实现了层叠。对于TextureView,View的composition是由GLES执行的,同时更新TextureView的数据内容可能会导致其他View组件也出现redraw(如果view是放在TextureView的上面的话)。在View渲染成功之后,app UI layer必须通过SurfaceFlinger与其他layer(StatusBar layer,NavigationBar layer)进行composition。对于一个全屏的视频播放应用,还有那些UI元素全部在video layer上面的应用,SurfaceView提供了更好的性能。
前面有提到过,对于RDM保护的Video只能在上层的layer上呈现。能够播放DRM的Video Player必须使用SurfaceView。
SurfaceView and Activity Lifecycle
当使用SurfaceView的时候,渲染Surface应该使用单独的Thread而不是Main UI Thread。这会带来一些thread与activity生命周期的交互问题。
首先,对于一个拥有SurfaceView的Activity,他们有两个互相依赖的生命周期:
- App onCreate/onResume/onPause
- Surface created/changed/destoryed
当Activity启动时,你会按下面的顺序接收到callback:
- onCreate
- onResume
- surfaceCreated
- surfaceChanged
如果你点击back按钮,你将会收到下面的callback:
- onPause
- surfaceDestoryed(在Surface消失之前就会执行)
如果你点击电源按钮来关闭屏幕,你只会收到onPause()
,没有surfaceDestroyed()
。此时Surface仍然是存活的,渲染操作还可以继续进行。如果你有需要,还可以持续请求获取到Choreographyer的信号。如果你在锁屏的情况下旋转屏幕,然后对设备进行解锁,此时Activity会被重新启动。但是如果没有进行旋转,解锁之后还是能够获取到之前的Surface。
当在SurfaceView里面使用一个单独的渲染线程时有一个问题:这个Thread的生命周期是不是应该和Surface或者Activity进行绑定?答案取决于在屏幕关闭时你想要做的操作。有两个方法:(1)在Activity的start/stop时对Thread做start/stop的操作。(2)在Surface的create/destory时对thread做start/stop的操作。
- 方法(1)是和app的生命周期进行绑定。在onResume()的时候开启渲染线程,在onPause时停止它。这会遇到一点麻烦是:不知道何时创建于配置thread,因为Surface有时存在有时又不在。我们必须等待Surface被创建时候才能做一些线程中的初始化的操作。但是我们还不能简单的把这些操作放到
surfaceCreated()
的回调里面执行,因为如果surface不被重新创建的话,就没有办法触发那些初始化的操作。因此我们不要查询与保存Surface的状态,并且把这些信息传递给渲染thread。请注意,在多核的系统中,线程间传递数据需要小心谨慎,最好的方式是通过Handler message来传递Surface或者SurfaceHolder,而不仅仅是把他们放到thread里面。 - 方法(2)呼声更高,因为Surface与渲染的逻辑是相关联的。在Surface创建之后开启渲染Thread,这样避免了一些线程间通信的问题。Surface created/changed的消息都是先于Thread收到的。我们需要确保屏幕关闭之后,渲染操作会停止,在屏幕点亮之后操作能够恢复。可以通过简单的通知Choreographer来停止触发frame绘制的回调。仅仅只有在渲染thread正在运行,我们的
onReusme
方法才需要恢复那些callback。如果我们基于frame之间的时间做动画的操作,中间省略掉得一些数据是不要紧的。给出明确的pause/resume的消息是个不错的写法。
===== 学习自:http://source.android.com/devices/graphics/architecture.html
转载自 : http://hukai.me/android-deeper-graphics-architecture/