详解Android WifiDisplay源码：Source端数据读取流程与SurfaceFlinger交互

本文主要探讨了在Android 4.2及更高版本中，如何在Source端进行数据读取的流程，尤其是在构建和管理WifiDisplay功能时。在多屏互动的背景下，SurfaceFlinger（SF）在系统中的核心作用不可忽视。 首先，加入WifiDisplay后，Android显示系统的运作涉及多个步骤。每个BufferQueue，如BufferQueue1到BufferQueue5，由SF负责管理，这些BufferQueue包含了来自不同应用（App1到App4）的数据。当SF接收到应用数据时，它会逐一取出最新的Buffer，然后对本地显示设备（例如Layer1至Layer4）和远程的WifiDisplay设备进行合成。本地设备直接执行OpenGL绘制并交换Buffer，同时为下一次绘制准备好新的空Buffer；相比之下，远端的WifiDisplay设备只保存已绘制完成的Buffer，并接收后续的空Buffer。 在SF中，主显示设备（Primary）和WifiDisplay设备（widisplay）的创建过程各有特点。主显示设备通常在SF启动初期由sp指针引用创建，包含FramebufferSurface（基于HAL接口实现BufferQueue操作），SurfaceTextureClient（用于本地OpenGL操作），以及DisplayDevice类，该类用于管理多个显示设备。而对于WifiDisplay设备，其BufferQueue的创建不同于常规，它并非直接关联到主显示，而是单独管理和传输数据。 当用户添加一个新的WifiDisplay显示设备时，SF会相应地处理，这包括创建特定于该设备的BufferQueue，并确保数据传输的高效性和一致性。这个过程体现了SF在处理多屏交互时的复杂性和灵活性，尤其是对于Source端数据流的控制和同步。 总结来说，本文深入剖析了Android 4.2及以上版本中，特别是在Source端，如何通过SurfaceFlinger管理和处理数据，以支持Wi-Fi Display的多屏互动功能。理解这个流程对于开发者优化多设备应用性能，确保流畅的用户体验至关重要。