渲染同步优化：SurfaceView/TextureView/GLSurfaceView选型、EGL上下文共享、帧同步机制
渲染同步，说白了就是让画面不卡、不撕裂、不掉帧。很多开发者觉得这玩意儿玄乎，其实没那么复杂。我做了这么多年音视频，踩过的坑不少，今天就把这些经验掰开了揉碎了讲给你听。
一、三大渲染容器的选型博弈
Android 上做视频渲染，绕不开三个家伙：SurfaceView、TextureView、GLSurfaceView。很多人问我选哪个好，我的回答永远是——看场景。
1. SurfaceView：老牌劲旅，性能王者
SurfaceView 有独立的 Surface，说白了就是它自己开了一个独立的绘图层。这个层在 WindowManager 的管理下，可以跑到单独的线程里渲染。
核心优势：
- 独立的渲染线程，不阻塞 UI 主线程
- 支持硬件叠加层（Hardware Overlay），功耗低
- 视频播放场景下延迟最低
我在项目中遇到过一个问题：用 SurfaceView 播放 4K 视频，UI 上有个弹窗，结果弹窗出现时视频画面闪了一下。为什么？因为 SurfaceView 的 Z-order 是独立的，它和普通 View 不在同一个图层上。解决方案是调用 setZOrderOnTop(true) 或者用 setZOrderMediaOverlay 来调整层级。
注意：SurfaceView 不支持动画、平移、缩放等 View 变换。如果你需要做这些操作，别选它。
2. TextureView：灵活但耗电
TextureView 是一个完整的 View，它把 SurfaceTexture 封装在内部。你可以像操作普通 View 一样操作它——加动画、做变换、设透明度，都没问题。
但是，有得必有失。TextureView 每次渲染都要走 GPU 合成，说白了就是多了一道工序。我测试过，同样播放 1080p 视频，TextureView 的功耗比 SurfaceView 高出 15%-20%。
我的建议：如果你的视频需要做转场动画、画中画、或者需要和 UI 元素紧密交互，用 TextureView。否则，老老实实用 SurfaceView。
3. GLSurfaceView：OpenGL 的专属舞台
GLSurfaceView 是 SurfaceView 的 OpenGL 版本。它自带 EGL 环境、自带渲染线程、自带帧循环。你只需要实现 Renderer 接口，剩下的它帮你搞定。
嗯，这里要注意：GLSurfaceView 的渲染线程是它内部管理的，你没法直接控制。如果你需要精细控制 EGL 上下文，或者需要多个 Surface 共享上下文，那 GLSurfaceView 就不太够用了。
| 特性 | SurfaceView | TextureView | GLSurfaceView |
|---|---|---|---|
| 独立渲染线程 | 是 | 否（走主线程） | 是 |
| 支持 View 变换 | 否 | 是 | 否 |
| 硬件叠加层 | 支持 | 不支持 | 支持 |
| EGL 上下文控制 | 需手动 | 需手动 | 自动 |
| 适用场景 | 视频播放、相机预览 | 动画、画中画 | 游戏、特效 |
二、EGL 上下文共享：多线程渲染的基石
你想想看，如果两个线程都要渲染到同一个 Surface 上，怎么办？或者一个线程解码视频，另一个线程渲染画面，怎么共享纹理？答案就是 EGL 上下文共享。
EGL 上下文说白了就是一个状态机，它记录了 OpenGL 的所有状态——纹理、缓冲区、着色器等等。默认情况下，每个上下文是独立的，互不干扰。但我们可以通过 eglCreateContext 的 EGL_CONTEXT_CLIENT_VERSION 属性，传入一个已有的上下文作为共享对象。
// 创建第一个上下文
EGLContext sharedContext = eglCreateContext(display, config, EGL_NO_CONTEXT, attribList);
// 创建第二个上下文，共享第一个上下文的资源
EGLContext workerContext = eglCreateContext(display, config, sharedContext, attribList);我曾经在一个直播项目中遇到一个问题：解码线程和渲染线程各有一个 EGL 上下文，解码线程生成纹理后，渲染线程拿不到。折腾了两天，最后发现是共享上下文没配好。记住：共享上下文必须在同一个 EGLDisplay 下，而且 config 必须兼容。
上下文共享的核心价值：
- 纹理共享：解码线程生成的 YUV 纹理，渲染线程可以直接用
- 缓冲区共享：多个线程可以操作同一个 FrameBuffer
- 减少内存：纹理数据只存一份，多个上下文共用
三、帧同步机制：别让画面撕裂
帧同步，说白了就是让 GPU 在正确的时间点把画面刷到屏幕上。Android 的帧同步主要靠两个东西：Choreographer 和 BufferQueue。
1. Choreographer：VSync 的守护者
Choreographer 会监听硬件的 VSync 信号。每 16.6ms（60fps）或者 8.3ms（120fps），它会回调 doFrame 方法。你在这个回调里做的所有 UI 操作，都会在下一个 VSync 时被渲染到屏幕上。
我建议你在做视频渲染时，不要自己搞循环。用 Choreographer 的 postFrameCallback 来驱动渲染，这样天然和 VSync 对齐，不会出现掉帧或者撕裂。
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
// 在这里做渲染
renderFrame();
// 继续注册下一帧
Choreographer.getInstance().postFrameCallback(this);
}
});2. BufferQueue：生产者-消费者的经典模型
SurfaceView 和 TextureView 内部都有一个 BufferQueue。生产者（你的渲染线程）往队列里放帧，消费者（SurfaceFlinger）从队列里取帧去合成。如果生产者太快，队列满了，就会丢帧。如果消费者太快，队列空了，就会卡顿。
我曾经遇到一个诡异的问题：视频播放时偶尔出现画面停顿，但音频是正常的。排查了很久，发现是 BufferQueue 的 setBufferCount 设置得太小，导致生产者经常被阻塞。后来把缓冲区数量从 2 改成 4，问题就解决了。
经验之谈：BufferQueue 的缓冲区数量建议设置为 3-4 个。太少容易阻塞，太多会增加延迟。视频播放场景下，3 个缓冲区是比较平衡的选择。
四、SVG 知识体系图
五、实战中的避坑指南
讲了这么多理论，最后分享几个我踩过的坑，希望能帮你少走弯路。
我曾经犯过的错：
- 在 TextureView 的
onSurfaceTextureAvailable回调里直接开渲染线程，结果 SurfaceTexture 还没准备好，导致黑屏。解决方案：等onSurfaceTextureUpdated回调后再开始渲染。 - 多个 EGL 上下文共享纹理时，忘记调用
glFinish()，导致纹理数据还没写完就被另一个线程读取了。记住：共享上下文之间需要显式同步。 - 用 Choreographer 驱动渲染时，回调里做了耗时操作，导致下一帧的 VSync 信号被错过。解决办法：渲染逻辑单独放一个线程，Choreographer 只负责触发。
渲染同步这事儿，说白了就是管理好三个东西：渲染容器、EGL 上下文、帧同步信号。选对容器、配好共享、对齐 VSync，你的视频渲染就能丝滑流畅。嗯，今天就聊到这儿，希望这些经验对你有用。