Android SurfaceView, TextureView, and SurfaceTexture: The Rendering Bridge from BufferQueue Producers to Surface Compositing

While optimizing a video call, the same 720p stream ran at a steady 60 fps on SurfaceView, but switching to TextureView dropped it to 45 fps and added 20 ms of latency. My first instinct was that I was using TextureView wrong, but after three days of digging I found the problem wasn’t in the business layer at all—it was in two completely different compositing paths. This article starts from BufferQueue’s producer–consumer model and unpacks how these three pieces bridge together.

BufferQueue: A Surface Is Essentially a Producer Handle

The core of Android’s graphics stack is not SurfaceView but BufferQueue. It is a producer–consumer queue: producers submit GraphicBuffers, consumers take them for rendering, and the buffers return to the buffer pool when finished.

The Surface an app receives is essentially a Binder proxy to IGraphicBufferProducer. Drawing onto a Surface is really enqueueing buffers into the BufferQueue.

Who the consumer is determines where the content goes. SurfaceFlinger is the most common consumer: it acquires each window’s buffers and hands them to the Hardware Composer (HWC) for compositing to the display. If the app consumes them itself with a SurfaceTexture, the buffers are turned into GL textures and then go through the app’s own drawing pipeline.

Once you understand this, the difference between SurfaceView and TextureView becomes clear: one hands the Surface directly to SurfaceFlinger, and the other hands it to SurfaceTexture and then draws it into the main window.

SurfaceView: Punch-Through Compositing with an Independent Layer

When SurfaceView is initialized, it requests a separate Surface from the system and registers it as an independent Layer in SurfaceFlinger. This layer does not go through the app main window’s EGL rendering; it flows directly from producer to compositor.

So video content on a SurfaceView and the app UI are two parallel pipelines. The main window sits on top, the SurfaceView layer sits below, and the main window punches a transparent “hole” to reveal the lower layer—this is the commonly known punch-through mechanism.

val surfaceView = SurfaceView(context)
surfaceView.holder.addCallback(object : SurfaceHolder.Callback {
    override fun surfaceCreated(holder: SurfaceHolder) {
        player.setSurface(holder.surface) // Surface 直接交给播放器
    }
    override fun surfaceChanged(holder: SurfaceHolder, format: Int, width: Int, height: Int) {}
    override fun surfaceDestroyed(holder: SurfaceHolder) {}
})

An independent layer brings two immediate benefits: the frame rate is controllable and can have its own refresh rate set; and latency is lower because the buffer does not need an extra texture copy inside the main window.

The costs are just as obvious. Because of punch-through, SurfaceView cannot truly participate in the View tree’s drawing transforms. If you rotate the parent View, the main window moves but the lower Surface content does not transform in sync; on early Android versions the content could even spill outside the hole. Putting a SurfaceView inside a scrolling list makes the content lag behind the page scroll—a pitfall many people have hit.

SurfaceTexture: Turning Producer Buffers into GL Textures

SurfaceTexture is the app-side consumer wrapper, holding an IGraphicBufferConsumer internally. It does exactly one thing: it receives buffers from the BufferQueue and binds them, via EGLImage, into OpenGL ES external textures (GL_TEXTURE_EXTERNAL_OES).

val surfaceTexture = SurfaceTexture(texName).apply {
    setOnFrameAvailableListener { onFrameAvailable() }
}
val surface = Surface(surfaceTexture) // 给生产者用，例如 Camera2 或 MediaCodec
cameraDevice.createCaptureSession(listOf(surface), ...)

After a producer writes a new frame, the callback fires and you call updateTexImage() on the GL thread:

override fun onDrawFrame(gl: GL10?) {
    surfaceTexture.updateTexImage() // 把最新 buffer 绑定到当前 OES 纹理
    // 用该纹理绘制
}

Camera preview and video processing mostly take this path. Camera2 has no “just give me a View” API—it only accepts a Surface, and you can hand it either a SurfaceTexture or a SurfaceView’s Surface.

SurfaceTexture itself is not responsible for display; it only turns buffers into textures. Drawing to a GLSurfaceView is one GL rendering path, while drawing to a TextureView is the compositing path described next.

TextureView: Texture Drawing That Routes Back Through the Main Window

TextureView is a typical host for SurfaceTexture. Internally it holds a SurfaceTexture, while externally it behaves like an ordinary View.

The key flow is: the producer writes a buffer to the Surface → SurfaceTexture converts it to an OES texture → during hardware-accelerated drawing, TextureView draws that texture into the main window layer as part of the View → SurfaceFlinger composites everything to the display.

val textureView = TextureView(context)
textureView.surfaceTextureListener = object : TextureView.SurfaceTextureListener {
    override fun onSurfaceTextureAvailable(st: SurfaceTexture, w: Int, h: Int) {
        player.setSurface(Surface(st))
    }
    override fun onSurfaceTextureSizeChanged(st: SurfaceTexture, w: Int, h: Int) {}
    override fun onSurfaceTextureDestroyed(st: SurfaceTexture): Boolean = false
    override fun onSurfaceTextureUpdated(st: SurfaceTexture) {}
}

That extra hop has a visible cost. The step of binding the buffer into a texture via EGLImage is zero-copy on most devices; the real overhead is that the texture still has to be drawn into the main window as part of a View, adding another compositing pass. On the same device I measured an average of 15–25 ms more render latency for TextureView than SurfaceView in a video-call scenario, with higher GPU usage as well.

Its value is UI consistency. TextureView content is part of the View tree, so scaling, rotation, alpha, screenshots, and shared-element transitions all work naturally. If the product requires rounded corners on the video area or gesture-driven zoom, TextureView is the lowest-cost choice.

How to Choose for Camera and Video Rendering

These three components are not on the same level. SurfaceTexture is a data-format converter, while SurfaceView and TextureView are two kinds of display terminals. Choosing between them for camera preview and video rendering is fundamentally a trade-off between low-latency passthrough and UI flexibility.

My deciding criterion is one thing: does the content need to participate in UI transforms?

If you don’t need transforms and want the lowest possible latency, choose SurfaceView. Typical cases are full-screen player pages, camera viewfinders, and game scenes—here the content is independent of the UI layout, so the drawbacks of punch-through are barely felt.

If you need animation, rounded corners, or complex layering, choose TextureView. Typical cases are videos embedded in a feed and camera preview pages with pinch-to-zoom; the extra 15 ms is usually acceptable in these scenarios.

If you need to run filters, beautification, or algorithmic processing on frames, connect Camera2 output directly to a SurfaceTexture, process it, and then draw to a GLSurfaceView or encoder. Don’t first attach a TextureView and then pull frames back out of the View—that needlessly adds an extra trip through main-window compositing.

One more pitfall to watch for: SurfaceTexture is asynchronous multi-buffer by default; single-buffer mode only turns on if you explicitly pass true, and calling updateTexImage too slowly will drop frames. The onFrameAvailable callback is posted to the creating thread—often the main thread—by default, so don’t do heavy work in the callback; move time-consuming processing to a render thread.