1、-_版权声明：本文为博主原创文章，未经博主允许不得转载。目录 (?)-1. 1 WiFiDisplay 简介1. 2 WiFiDisplay 重要规范及标准2. WiFi 联盟定义了 Miracast 支持的视音频格式标准2. 主要模块介绍1. 1 WiFiP2P1. 11 WiFiP2P 简介2. 12 Android 中 WiFiP2P 2. Android 下实现详述1. 32 DisplayManagerService 及相关1. WiFiDisplay 应用场景及相关产品1. 2 相关应用产品1. DLNA 技术和 AirPlay 技术1. 2 AirPlay 技术1 WiFiDis
2、play 简介1.1WiFiDisplay 概述WiFiDisplay(WFD)是 WiFi 联盟在已有技术的基础上，为了加速视/音频的传输分享而提出来的一个新概念。WiFi 联盟对此成立了一个认证项目：Miracast- 用来认证一个设备是否支持 WiFiDisplay 功能。下图是 WiFiDisplay 功能的技术支撑体系，实际上最重要的部分就是 WiFi Direct：也就是两个设备无需 AP(AccessPoint)的情况下直接相连，这就奠定了两个带 WiFi 功能的设备能够随时传递高质/高清视频的前提。另外，其他深蓝色的技术是必须支持的：11n：即 802.11n 协议，支持最高传
3、输速度 540Mbit/s；WMM：即 WiFi Multimedia 的简称，主要针对不同的数据内容保证其传输的稳定和质量；WPA2：是 WiFi 联盟对于采用 802.11i 协议并采用更为复杂加密算法的认证项目；-_WiFi ProtectedSteup：也是一个 WiFi 联盟的一个认证项目：简化用户安装无线局域网和对安全性能的配置工作；WiFi Direct：表示设备可以实现直接互联，无需 AP 的参与；WiFi Miracast：即为是否可以实现 wifi-display 功能的认证项目。图 1 WiFiDisplay 技术支撑架构另外，WiFi 联盟还描述了 WiFiDispla
4、y 的简化工作模型( 图 2)。在这个工作模型中，Miracast 定义传输视/音频数据的一方为 source 端；接受数据并重新呈现的为 sink 端。从图中可以看到，source 端要有数据内容的存储和下载/生成能力；对数据进行编码能力。而 sink 端则需要对数据的解码能力；对视/音频进行再度呈现的能力。而 Miracast 则是定义了这两个设备之间，怎样保持会话；可以传输数据的格式标准；会话控制等内容。-_图 2 WiFiDisplay 的工作模型1.2 WiFiDisplay 重要规范及标准WiFi 联盟定义了 Miracast 支持的视/音频格式标准：-_图 3 Miracast
5、支持的显示、视频、音频格式标准同时，Miracast 也规范了设备连接后进行协商(图 4)、建立会话的流程(图 5)。详细描述了设备在建立物理连接后，通过标准步骤来完成 WiFi Display 的会话建立，然后开始数据传输。关于各个标准步骤的详细信息，请见 Miracast 官方解释。图 4 Miracast 定义的设备协商标准过程-_图 5 Miracast 定义的显示会话建立过程标准2 主要模块介绍由于 WFD 功能主要涉及 wifiP2P 功能和 display 功能，现对 Android 中涉及的两个模块wifiP2pService 和 SurfaceFlinger 做一些介绍。2.
6、1 WiFiP2P2.1.1 WiFiP2P 简介WiFiP2P 是 WiFi 联盟提出的一项重要技术规范，它定义了两个 wifi 设备如何在没有路由的情形下连接并通信。根据定义，支持 WiFiP2P 的设备需要扮演 P2P GroupOwner 或 P2P Client 角色来形成一个 P2P Group：-_图 6 WiFiP2P 工作组模型其中 P2P Group Owner 的设备需要发挥传统路由的功能：控制 WiFiP2P 工作组，使能设备通信等；P2PClient 设备则需要连接上 P2P Group Owner 设备来形成一个工作组来通信。在以上的工作模型基础上，WiFiP2P
7、细化了以下技术项：图 7 WiFiP2P 定义的 P2PDiscovery 规范在 P2P Discovery 规范中，定义了发现设备(Device Discovery )并构建工作组(GroupFormation )的细节。其中发现设备规定设备首先进入扫描阶段(ScanPhase)，去发送 Probe Request 帧；然后进入寻找阶段(Find Phase)，在这个阶段中设备会在SearchState 和 Listen State 中切换：两个阶段分别是发送 Probe Request 帧、监听 ProbeRequest 帧并发送 Probe Response帧。当找到附近的 P2P 设
8、备后，就可以来构建一个工作组：包括决定谁是 Group Owner 的协商(GONegotiation )和设备交换安全配置信息(Provisioning)，用于 Client 设备利用安全配置信息连接 GO。-_另外，WiFiP2P 还定义了 GroupOperation 技术项，具体描述了和工作组交互的场景和流程：P2P Device Join GO(Group Owner)P2P Device Join GC(Group Client)GC invite P2P DeviceGO invite P2P Device 2.12 Android 中 WiFiP2P Android 中关于 W
9、iFiP2P 模块主要涉及以下几个部分：图 8 Android 中 WiFiP2P 涉及模块WiFiP2PSettings 是用来和用户交互的部分，主要是提供 UI 给用户选择打开/开闭 WiFiP2P 功能、呈现搜寻到的 P2P 设备给用户等；WiFiP2PSettings 实现的功能调用的是 WiFiP2PManager 中的接口；WiFiP2PManager 最终会与 WiFiP2PService 交互，它们依靠 Android 的 Binder 机制来实现进程间的通信，WiFiP2PService 则是用来管理 Android 中 WiFiP2P 功能的核心模块：图 9 Android
10、 中 WiFiP2P 涉及模块-_在 WiFiP2PService 类中有一个内部类 P2pStateMachine(状态机)用来管理 WiFiP2P 的不同状态然后执行不同的操作；另外WiFiP2PService 还会创建一个 WifiMonitor 对象用于接收来自 wpa_supplicant 的消息并根据接收到的消息给P2pStateMachine 传值来推动状态机的工作。从图中可以看到，WiFiP2PService 或 WifiMonitor 交互的是 WiFiNative.Java 中的接口，这里面的都是一些 native 函数；这是因为 wap_supplicant 进程是 C
11、语言实现， Android 是通过 JNI 机制调用android_net_wifi_Wifi.cpp 里面的本地接口，这些本地接口来最终和 wpa_supplicant 交互(wifi.c 里面是对发送到wpa_supplicant 里面消息的封装 )。wpa_supplicant 是一个开源项目，实现了 WiFi 联盟规范中的众多功能，详见官方文档。下图是 wpa_supplicant 及与下层部件的一个草图：图 10 wpa_supplicant 及底层部件草图2.2 SurfaceFlinger总所周知，SurfaceFlinger 是 Android 中对图形画面进行管理并交由 Fr
12、ameBuffer 实际显示的重要模块，它需要收集系统中所有应用程序绘制的图像数据，然后集中处理后显示到物理屏幕上。下图是 Android 下图形显示的一个简略框图：-_图 11 Android 显示系统简略框图上图描述的是使用 OpenGL ES 图形开发规范下的情况。首先，每个应用程序在自己的窗口上进行绘图，这里的窗口(Window-2)实际上对应的是一些缓冲区；然后 SurfaceFlinger 则会对这些缓冲区进行统一管理；最后每一帧的图形数据会被送到FrameBuffer 上并实际显示在设备上。对于上层应用来说，Window-2 在 Android 中的实现为 SurfaceText
13、ureClient 类。由于是在 OpenGL ES 的开发框架下，SurfaceTextureClient 实际上是继承自 ANativeWindow 同时在本地实现了一些接口(参见 EGL 知识)：图 12 上层应用的 window 实现hook_dequeueBuffer()和 hook_queueBuffer()是框架定义中需要实现的本地函数，上层应用作图时需要从缓冲队列得到缓冲区；作图完成后需要把缓冲区送还给缓冲队列。具体情形如下：-_图 13 本地窗口和缓冲队列交互图如上图，本地窗口实际上是从 BufferQueue 来得到缓冲区；画图后再将缓冲区入列到缓冲队列。而 BufferQueue 是在应用程序创建 Surface(在 SurfaceFlinger 端对应 Layer)的时候生成的，本地窗口通过返回的 ISurface 对象得到 ISurfaceTexture 对象来最终和 BufferQueue 交互。对于 SurfaceFlinger 侧的本地窗口 Window-1(图 11)来说，SurfaceTextureClient 也是作为本地窗口的功能。不过在SurfaceFlinger 端通过标准的 OpenGL ES 接口进行请求缓冲区操作和入列缓冲区操作的对象就不一样了；而且在入列缓冲区后所进行的操作也不一样：
