Ragnarok Note

浅谈Android中Surface显示延迟处理

最近在使用GLES在Surface上渲染结果的时候,遇到了一个显示延迟的问题,当渲染时间过长,同时帧率要求比较高的时候,如果不加控制,就会造成显示的延迟,如果界面没有交互,倒是不会看出什么问题,如果是强交互的场景,这种情况下就会造成可感知的用户使用延迟了。处理这种情况的其中一种方式是给渲染的一帧赋予一个时间戳,用于给SurfaceFlinger进行对应的丢帧控制,具体什么原理呢,让我们一步一步来说明一下

Surface是什么?


从原来上讲,Android的 Surface 可以认为是目前图形架构中,作为 BufferQueue 的生产者端,Android会首先把内容渲染到Surface上,填充数据到GraphicBuffer上。而作为消费者端则为系统的SurfaceFlinger ,取出BufferQueue中的GraphicBuffer,并配合vysnc将数据送给HWC合成到屏幕上。

一般来说,Android会把所有可见的View渲染到一个由SurfaceFlinger创建的Surface上,但是这个Surface并不能由开发者直接操作,从App的开发角度来看,大部分情况下我们直接操作的Surface一般会从以下两个地方获取

  • SurfaceView / GLSurfaceView

    这两个组件是结合了Surface跟View的实现,特别的是,这两个view系统为其单独提供一层了Surface,并直接由SurfaceFlinger进行管理合成,因此实际显示在屏幕上的时候,并没有完全从属在当前的View的布局层次上,在布局对应的位置上,只是一个透明的占位符。而GLSurfaceView,则在SurfaceView的基础上提供了EGL的上下文,以便可以直接使用GLES在Surface上绘制内容

  • SurfaceTexture / TextureView

    SurfaceTexture是从Android 3.0+开始提供的组件,提供了一个Surface跟GLES纹理的组合,而TextureView,则是一个SurfaceTexture跟View结合起来的组件。而TextureView跟SurfaceView最大的不同在于,虽然都是可以作为BufferQueue的生产方,但是最后合成的时候,并非由SurfaceFlinger直接合成,而是通过GLES直接合成到App对应的Surface上,在布局层次上是跟当前App的View是在同一个层级,对应的View的刷新逻辑也会影响TextureView。因此,从原理上来说,SurfaceView/GLSurfaceView的渲染效率要比TextureView要高

使用GLES在Surface中显示内容


上面说到,Surface作为BufferQueue的生产方,开发者可以在上面绘制画面,而在SurfaceView/TextureView上,系统都提供了对应的lockCanvas方法,返回一个Canvas对象允许在对应的Surface上绘制内容。除了这个方法以外,我们也可以使用GLES在Surface上绘制内容。

无论是使用GLSurfaceView,还是TextureView,使用GLES在Surface上绘制内容,我们都必须在单独线程进行GLES的上下文初始化(因为GL Context是跟线程绑定的),创建对应的EGLSurface ,一般来说,实现的代码如下(如果用的是GLSurfaceView,下面的初始化逻辑内部已经给你做好了):

mEGLDisplay = EGL14.eglGetDisplay(EGL14.EGL_DEFAULT_DISPLAY)
if (mEGLDisplay === EGL14.EGL_NO_DISPLAY) {
        throw RuntimeException("unable to get EGL14 display")
}
val version = IntArray(2)
if (!EGL14.eglInitialize(mEGLDisplay, version, 0, version, 1)) {
        throw RuntimeException("unable to initialize EGL14")
}

// Configure EGL for recording and OpenGL ES 2.0.
val attribList = intArrayOf(EGL14.EGL_RED_SIZE, 8, 
                            EGL14.EGL_GREEN_SIZE, 8, 
                            EGL14.EGL_BLUE_SIZE, 8, 
                            EGL14.EGL_ALPHA_SIZE, 8,
                            EGL14.EGL_RENDERABLE_TYPE, EGL14.EGL_OPENGL_ES2_BIT,                 
                            EGL_RECORDABLE_ANDROID, 1, 
                            EGL14.EGL_NONE)
val configs = arrayOfNulls<EGLConfig>(1)
val numConfigs = IntArray(1)
EGL14.eglChooseConfig(mEGLDisplay, attribList, 0, configs, 0, configs.size, numConfigs, 0)
checkEglError("eglCreateContext RGB888+recordable ES2")

// Configure context for OpenGL ES 2.0.
val attrib_list = intArrayOf(EGL14.EGL_CONTEXT_CLIENT_VERSION, 2, EGL14.EGL_NONE)
mEGLContext = EGL14.eglCreateContext(mEGLDisplay, configs[0], EGL14.EGL_NO_CONTEXT, attrib_list, 0)
checkEglError("eglCreateContext")

// Create a window surface, and attach it to the Surface we received.
val surfaceAttribs = intArrayOf(EGL14.EGL_NONE)
mEGLSurface = EGL14.eglCreateWindowSurface(mEGLDisplay, configs[0], mSurface, surfaceAttribs, 0)
checkEglError("eglCreateWindowSurface")

EGL14.eglMakeCurrent(mEGLDisplay, mEGLSurface, mEGLSurface, mEGLContext)
checkEglError("eglMakeCurrent")

以上代码摘自这里,并转换成了kotlin

大概流程就是先选择好需要的EGL配置,然后初始化EGLConfig跟EGLContext,最终,调用eglCreatexxxSurface创建一个EGLSurface,这这个例子中调用的是eglCreateWindowSurface,并在函数中传入了SurfaceView/TextureView中的Surface对象

另外,在eglCreateWindowSurface函数中传入的Surface对象,如果不是需要渲染到屏幕上的话,除了直接使用上面的两个Surface对象以外,在很多处理视频特效的应用中,另外一种方式是传入MediaCodec的Surface,也就是这个方法的返回结果

MediaCodec.getInputSurface

然后MediaCodec作为编码器使用,渲染一帧之后结果就直接编码到结果视频中了

  • 这里简单在说明一点,在这种场景下(还有一种是使用GLES渲染camera preview),使用GLES渲染对应MediaCodec编码结果到Input Surface上的时候,使用的纹理类型必须是外部纹理(GL_TEXTURE_EXTERNAL_OES

在上面的初始化代码中,最终结果是创建了一个EGLSurface对象,这个对象最终会链接到Surface中的BufferQueue生产方接口,渲染到该EGLSurface上的新的一帧将会让一个GraphicBuffer离开队列并提供给消费者一方使用,但是,EGL并不会自动给提交当前渲染的一帧,当渲染好之后,需要调用eglSwapBuffers提交当前渲染结果,从而实现BufferQueue的刷新

结合SurfaceFlinger,使用GLES在Surface上渲染,上屏的整理流程大概如下:

Surface -> EGL renderer -> swap buffer -> BufferQueue deque -> SurfaceFlinger -> HWC -> Display

更具体的GraphicBuffer/BufferQueue同步机制,推荐看下这篇文章的分析

Surface渲染上屏时间戳


上面大体分析了Surface原理,以及对应渲染上屏的步骤,但是,直到SurfaceFlinger,到Hareware Composer这一步,我们还有一个关键的问题没有解决:

我们在渲染好一帧之后,如何能够保证这一帧的内容能够及时显示到屏幕上呢?

或者换一个问法:

当我们渲染一帧的时间过长的时候,我们又怎么能够保证在对应的时间点上在屏幕上显示对应的内容呢?

如果没有解决这个问题,那么在游戏渲染,或者在视频播放渲染的时候,就很容易出现音视频不同步的情况。而Android对于这个问题的解决方式就是,让App去告诉SurfaceFlinger某一帧想要在哪个时间点显示到屏幕上,也就是说引入了帧时间戳的概念。当SurfaceFlinger提交到HWC超过这个时间戳的时候,就丢掉这一帧,如果还没达到对应帧的时间戳,就继续显示当前帧

而在实现上,Android提供了一个单独的EGL扩展:eglPresentationTimeANDROID ,在swapBuffer之前调用,提交当前帧的想要的显示时间戳,至于时间戳的具体含义,在不同的场景中可能会有不同的表达,例如:

  • 如果是显示到屏幕上的时候,时间戳就是一个绝对时间值,例如系统的启动时间

  • 如果是视频编码的场景,例如使用MediaCodec的InputSurface来编码视频的时候,这个时候时间戳的含义就是当前视频帧的 pts,事实上,当你想在MediaCodec的InputSurface上渲染完内容之后,如果不调用这个函数控制当前这一帧的pts,除非合成器有额外控制,否则最后编码出来的视频fps将会相当大,具体这里的实现,可以参考下BigFlake这里的代码

btw, 这个扩展对应的Android上层接口定义在这里

因此,通过对 eglPresentationTimeANDROID 的调用,结合BufferQueue,SurfaceFlinger就可以针对上屏的每一帧数据延迟做精确的控制了,假设说,我们设置了某一帧显示时间戳为T,然后提交到BufferQueue中:

  • 当在T-1的时间点,当前队首为这一帧的时候,SurfaceFlinger会继续hold住当前帧,也就是说这个时候显示的还是前一帧的数据

  • 当达到了T时间点,当前队首为这一帧的时候,SurfaceFlinger便直接提交这一帧到Display

  • 当达到了T+1时间点,当前队首为这一帧的时候,因为已经超过了这一帧设置的时间戳T,因此SurfaceFlinger便直接丢弃这一帧,继续处理队列剩余的帧数据

总体来看,在通过帧时间戳控制之后,Android就可以解决Surface的渲染上屏延迟问题,但渲染过长的时候,就势必带来丢帧,因此根本的解决方案,还是得尽量在16ms内,渲染完一帧数据

文笔一般,水平有限,仅做抛砖引玉之用,欢迎更加仔细的讨论!

References