4. 移动端渲染基础

移动端音视频应用绕不开一个核心问题：解码后的视频帧，最终如何高效地显示到屏幕上。Android 与 iOS 各自提供了不同的渲染承载对象和图形 API，选错一层，可能带来额外拷贝、掉帧、功耗升高甚至画面撕裂。本节先厘清各方案的定位与数据通路，再给出可落地的选型依据。

一、Android 侧：SurfaceView 与 TextureView 的本质差异

Android 上承载视频画面的两个主要 View 是 SurfaceView 和 TextureView，它们的差别不在“能不能显示”，而在“画面合成发生在哪一层”。

SurfaceView 拥有一个独立于应用窗口的 Surface，由系统合成器（SurfaceFlinger）单独合成。它不参与 View 树的绘制流程，因此渲染路径短、延迟低、功耗小，非常适合全屏播放、直播预览、摄像头取景等场景。代价是：它本质上是“挖洞”显示，无法像普通 View 一样自由做透明度、旋转、圆角裁剪等变换；在旧版本上还有层级（Z-order）问题，容易被其他 View 遮挡。

TextureView 则把画面作为纹理（Texture）参与 View 树的硬件加速合成，因此可以像普通 View 一样做平移、缩放、旋转、透明度、圆角等变换，布局灵活。代价是它需要额外的纹理拷贝与合成步骤，内存占用和功耗更高，且必须在硬件加速窗口中使用，渲染延迟通常略高于 SurfaceView。

一句话判断：要低延迟、低功耗、全屏或固定布局，选 SurfaceView；要灵活变换、嵌入复杂 UI、做动画，选 TextureView。

二、图形 API：OpenGL ES 与 Metal

无论用哪种 View 承载，真正执行绘制的是图形 API。Android 上主流是 OpenGL ES（2.0/3.0/3.1），它跨平台、生态成熟，配合 EGL 管理上下文与 Surface 的绑定。iOS 上则是 Metal，它更贴近硬件、开销更低、支持更现代的 GPU 特性，是苹果主推的图形与计算 API。

在 Android 上，SurfaceView 与 TextureView 都可以通过 EGL 创建上下文并绑定到其 Surface 上渲染。典型流程是：创建 EGLDisplay → 选择 EGLConfig → 创建 EGLContext → 创建 EGLSurface 并绑定到 View 的 Surface → 在渲染线程中执行绘制 → 调用 eglSwapBuffers 提交。TextureView 还需要通过 SurfaceTexture 接收画面，再在 onSurfaceTextureAvailable 回调中拿到可用的 Surface。

// Android 侧 EGL 绑定 SurfaceView 的关键步骤（示意）
eglDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);
eglInitialize(eglDisplay, &major, &minor);
eglChooseConfig(eglDisplay, attribs, &config, 1, &numConfigs);
eglContext = eglCreateContext(eglDisplay, config, EGL_NO_CONTEXT, ctxAttribs);
eglSurface = eglCreateWindowSurface(eglDisplay, config, nativeWindow, NULL);
eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglContext);
// ... 绘制 ...
eglSwapBuffers(eglDisplay, eglSurface);

iOS 上使用 Metal 时，通常通过 CAMetalLayer 承载可绘制纹理，从 MTLDevice 创建命令队列，每帧获取 CAMetalDrawable，编码渲染命令后提交。相比 OpenGL ES，Metal 的驱动开销更低，多线程命令编码更友好。

三、跨平台渲染方案选型

当应用需要同时覆盖 Android 与 iOS，直接写两套原生渲染代码成本高。常见跨平台方案有三类：

• 自研抽象层：定义统一的渲染接口（如 IRenderer），Android 用 OpenGL ES 实现，iOS 用 Metal 实现，上层业务只调用接口。灵活但工作量大。
• 跨平台图形库：如 Skia、bgfx、Filament 等，屏蔽底层 API 差异，适合复杂 2D/3D 渲染，但包体和学习成本较高。
• Flutter/React Native 等框架内置渲染：由框架统一管理渲染管线，开发者不直接接触 GPU API，适合 UI 为主、对极致性能要求不高的场景。

选型时建议按以下维度权衡：延迟要求、功耗预算、是否需要复杂变换、团队技术栈、包体大小、维护成本。例如直播连麦场景，延迟敏感，Android 优先 SurfaceView + OpenGL ES，iOS 用 Metal + CAMetalLayer；而短视频编辑预览需要频繁变换和滤镜，TextureView 或跨平台图形库更合适。

四、实践中的关键判断点

在实际工程中，除了选型，还要关注几个容易踩坑的点。第一，渲染线程与 UI 线程分离：无论 SurfaceView 还是 TextureView，都应在独立线程中执行 EGL/Metal 绘制，避免阻塞主线程导致卡顿。第二，Surface 生命周期管理：SurfaceView 的 Surface 可能因页面切换被销毁重建，TextureView 也有 onSurfaceTextureDestroyed 回调，必须正确释放和重建 EGLSurface，否则会出现黑屏或崩溃。第三，分辨率与缩放：视频帧尺寸与 View 尺寸不一致时，需在顶点着色器或矩阵中做等比缩放，避免拉伸变形。第四，帧同步：解码输出与渲染节奏要匹配，必要时用时间戳做丢帧或等待，防止画面抖动。

理解这些承载对象与图形 API 的差异，是后续实现视频渲染、滤镜、美颜、多路合成等功能的基础。选型没有绝对优劣，只有是否匹配当前场景的延迟、功耗与开发成本约束。