技术宝典 | WebRTC 技术解析之 Android VDM

导读：WebRTC 中的Android VDM（Video Device Manager）技术模块，是指 WebRTC 基于 Android 系统，对视频数据采集、编码、 解码和渲染的管理。当你拿到一部Android 手机，通过网易云信 SDK 进行 RTC 通信时，你是否好奇， Android 系统的 VDM 是如何实现的？WebRTC 又是如何使用 Android VDM 的？本文对 WebRTC 中 Android VDM 的实现进行了分解和梳理。

文｜Iven  网易云信资深音视频客户端开发工程师

01 Android 图形系统介绍

视频是由一幅幅图像组成的序列， 在 Android 系统中， 图像的载体是 Surface。Surface 可以理解为 Android 系统内存中的一段绘图缓冲区。无论开发者使用什么渲染 API，一切内容都会渲染到 Surface 上。Android 的采集、编解码、渲染，都是基于对 Surface 的处理。Surface 表示缓冲区队列中的生产方，而缓冲区队列通常会被 SurfaceFlinger 或显示 OpenGL ES 消耗。在 Android 平台上创建的每个窗口都由 Surface 提供支持。所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到屏幕，最后显示到手机屏幕上。

 Android 图形系统中的生产者和消费者模型 

前面提到，Surface 表示缓冲区队列中的生产方，对应下图的 Producer。BufferQueues 是 Android 图形组件之间的粘合剂，它是一个队列，将可生成图形数据缓冲区的组件（生产方）连接到接收数据以便进行显示或进一步处理的组件（消费方）。一旦生产方移交其缓冲区，消费方便会负责将生产出来的内容进行处理。

图像流生产方可以是生成图形缓冲区以供消耗的任何内容。例如 Canvas 2D 和 mediaserver 视频解码器。图像流的最常见消耗方是 SurfaceFlinger，该系统服务会消耗当前可见的 Surface，并使用窗口管理器中提供的信息将它们合成到屏幕。

整个 Android 图像的数据流管线很长，所以生产者和消费者的角色其实是相对的，同一个模块对应的可能既是生产者，也是消费者。OpenGL ES 既可以作为生产方提供相机采集图像流，也可以作为消费方消耗视频解码器解码出来的图像流。

 Android 图形显示 pipeline 

SurfaceFlinger 是整个 Android 屏幕显示的核心。SurfaceFlinger 进程由 init 进程创建，把系统中所有应用程序的最终绘图结果合并成一张，然后统一显示到物理屏幕上。

一个应用程序在送给 SurfaceFlinger 之前，是多个生产者在同时工作的，也就是有多个 Surface 通过 BufferQueue 向 SurfaceFlinger 输送数据。如下图的 Status Bar、System Bar、Icons/Widgets  等；但无论有多少个生产者，最终都在 SurfaceFlinger 这个消费者这里，合并成一个 Surface。

值得一提的是 SurfaceFlinger 的硬件加速功能，如果所有的合成都交给 SurfaceFlinger 进行处理， 对 GPU 的负担会加重，所以现在大部分手机都支持硬件加速进行合成，也就是 HWComposer。HWComposer 通过专门的硬件加速减轻 GPU 负担，帮助 Surfaceflinger 高效快速地进行 Surface 的合成。