SurfaceFlinger 和 Hardware Composer HAL 通过执行以下四项关键任务来准备用于显示的图形数据缓冲区：
- 接受缓冲区
- 确定合成缓冲区的最有效方法
- 合成缓冲区
- 将缓冲区发送到显示设备
SurfaceFlinger
SurfaceFlinger 接受来自多个来源的数据缓冲区，对它们进行合成，然后发送到显示设备。
当应用进入前台时，WindowManager 服务会向 SurfaceFlinger 请求一个绘图 Surface。SurfaceFlinger 会创建一个其主要组件为 BufferQueue 的层，而 SurfaceFlinger 是其消耗方。生产方端的 Binder 对象通过 WindowManager 传递到应用，然后应用可以开始直接将帧发送到 SurfaceFlinger。
大多数应用在屏幕上一次显示三个层：屏幕顶部的状态栏、底部或侧面的导航栏以及应用界面。有些应用会拥有更多或更少的层（例如，默认主屏幕应用有一个单独的壁纸层，而全屏游戏可能会隐藏状态栏）。每个层都可以单独更新。状态栏和导航栏由系统进程渲染，而应用层由应用渲染，两者之间不进行协调。
设备显示会按一定速率刷新，在手机和平板电脑上通常为 60 fps。如果显示内容在刷新期间更新，则会出现撕裂现象；因此，请务必只在周期之间更新内容。在可以安全更新内容时，系统便会收到来自显示设备的信号。由于历史原因，我们将该信号称为 VSYNC 信号。
刷新率可能会随时间而变化，例如，一些移动设备的帧率范围在 58 fps 到 62 fps 之间，具体要视当前条件而定。对于连接了 HDMI 的电视，刷新率在理论上可以下降到 24 Hz 或 48 Hz，以便与视频相匹配。由于每个刷新周期只能更新屏幕一次，因此以 200 fps 的帧率为显示设备提交缓冲区就是一种资源浪费，因为大多数帧会被舍弃掉。SurfaceFlinger 不会在应用每次提交缓冲区时都执行操作，而是在显示设备准备好接收新的缓冲区时才会唤醒。
当 VSYNC 信号到达时，SurfaceFlinger 会遍历它的层列表，以寻找新的缓冲区。如果找到新的缓冲区，它会获取该缓冲区；否则，它会继续使用以前获取的缓冲区。SurfaceFlinger 必须始终显示内容，因此它会保留一个缓冲区。如果在某个层上没有提交缓冲区，则该层会被忽略。
SurfaceFlinger 在收集可见层的所有缓冲区之后，便会询问 Hardware Composer 应如何进行合成。
Hardware Composer
Hardware Composer HAL (HWC) 用于确定通过可用硬件来合成缓冲区的最有效方法。作为 HAL，其实现是特定于设备的，而且通常由显示设备硬件原始设备制造商 (OEM) 完成。
当您考虑使用叠加平面时，很容易发现这种方法的好处，它会在显示硬件（而不是 GPU）中合成多个缓冲区。例如，假设有一部普通 Android 手机，其屏幕方向为纵向，状态栏在顶部，导航栏在底部，其他区域显示应用内容。每个层的内容都在单独的缓冲区中。您可以使用以下任一方法处理合成：
- 将应用内容渲染到暂存缓冲区中，然后在其上渲染状态栏，再在其上渲染导航栏，最后将暂存缓冲区传送到显示硬件。
- 将三个缓冲区全部传送到显示硬件，并指示它从不同的缓冲区读取屏幕不同部分的数据。
后一种方法可以显著提高效率。
显示处理器功能差异很大。叠加层的数量（无论层是否可以旋转或混合）以及对定位和叠加的限制很难通过 API 表达。为了适应这些选项，HWC 会执行以下计算：
- SurfaceFlinger 向 HWC 提供一个完整的层列表，并询问“您希望如何处理这些层？”
- HWC 的响应方式是将每个层标记为叠加层或 GLES 合成。
- SurfaceFlinger 会处理所有 GLES 合成，将输出缓冲区传送到 HWC，并让 HWC 处理其余部分。
由于硬件供应商可以定制决策代码，因此可以在每台设备上实现最佳性能。
当屏幕上的内容没有变化时，叠加平面的效率可能会低于 GL 合成。当叠加层内容具有透明像素且叠加层混合在一起时，尤其如此。在此类情况下，HWC 可以选择为部分或全部层请求 GLES 合成，并保留合成的缓冲区。如果 SurfaceFlinger 返回来要求合成同一组缓冲区，HWC 可以继续显示先前合成的暂存缓冲区。这可以延长闲置设备的电池续航时间。
运行 Android 4.4 或更高版本的设备通常支持 4 个叠加平面。尝试合成的层数多于叠加层数会导致系统对其中一些层使用 GLES 合成，这意味着应用使用的层数会对能耗和性能产生重大影响。
虚拟显示设备
SurfaceFlinger 支持一个主要显示设备（即内置在手机或平板电脑中的显示屏）、一个外部显示设备（如通过 HDMI 连接的电视）以及一个或多个令合成的输出在系统中可用的虚拟显示设备。虚拟显示设备可用于记录屏幕信息或通过网络发送屏幕信息。
虚拟显示设备可以与主显示设备共享相同的一组层（层堆叠），也可拥有自己的一组层。虚拟显示设备没有 VSYNC，因此主显示设备的 VSYNC 用于为所有显示设备触发合成。
在旧版本的 Android 中，虚拟显示设备总是通过 GLES 合成，而 Hardware Composer 管理的合成仅用于主显示设备。在 Android 4.4 中，Hardware Composer 能够参与虚拟显示设备合成。
正如您所预期的，为虚拟显示设备生成的帧会写入 BufferQueue。
案例研究：screenrecord
screenrecord 命令可让您将屏幕上显示的所有内容作为一个 .mp4 文件记录在磁盘上。为此，我们必须从 SurfaceFlinger 接收合成的帧，将它们写入视频编码器，然后将已编码的视频数据写入一个文件。视频编解码器由单独的进程 (mediaserver) 进行管理，因此我们必须在系统中移动大量图形缓冲区。为了使其更具挑战性，我们尝试以全分辨率录制 60 fps 的视频。高效完成这项工作的关键是 BufferQueue。
MediaCodec 类允许应用以缓冲区中的原始字节形式或通过 Surface 来提供数据。当 screenrecord 请求访问视频编码器时，mediaserver 会创建一个 BufferQueue，将其自身连接到消耗方端，然后将生产方端作为 Surface.传回到 screenrecord。
然后，screenrecord 实用程序要求 SurfaceFlinger 创建一个镜像主显示设备的虚拟显示设备（即，它与主显示设备具有完全相同的层），并指示它将输出发送到来自 mediaserver 的 Surface。在这种情况下，SurfaceFlinger 是缓冲区的生产方，而不是消耗方。
配置完成后，screenrecord 会在编码数据显示时触发。在应用绘制时，其缓冲区会前往 SurfaceFlinger，SurfaceFlinger 将它们合成为单个缓冲区，然后直接发送到 mediaserver 中的视频编码器。screenrecord 进程甚至从未看到过完整的帧。在内部，mediaserver 具有自己的移动缓冲区的方式，这种方式还通过句柄传递数据，从而最大限度地降低开销。
案例研究：模拟辅助显示设备
WindowManager 可以要求 SurfaceFlinger 创建一个可见层，将 SurfaceFlinger 作为其 BufferQueue 消耗方。也可以要求 SurfaceFlinger 创建一个虚拟显示设备，同样以 SurfaceFlinger 作为其 BufferQueue 生产方。
如果将虚拟显示设备连接到可见层，则系统会创建一个闭合循环，其中合成的屏幕显示在窗口中。该窗口现在是合成输出的一部分，因此在下一次刷新时，该窗口中的合成图像也会显示窗口内容。要实际查看该过程，请在设置中启用开发者选项，选择模拟辅助显示设备，然后启用一个窗口。要实际查看辅助显示设备，请使用 screenrecord 捕获启用显示设备的操作，然后逐帧播放。