1、无线传屏技术 Android 下的 Miracast 实现 AirPlay AirPlay 是苹果开发的一致无线技术， 可以通过 Wi-FiI 将 iPhone、 iPad、 iPodTouch 等 iOS设备上的包括图片、音频、视频通过无线的方式传输到支持 AirPlay 设备。 AirPlay 具备 DLNA 所没有的镜像功能（ AirPlay 镜像），可将 iPhone 或 iPad 上的画面无线传输到电视上，即设备显示的是什么，电视屏幕显示的就是什么，而不仅限于图片和视频，你可以拿着 iPad 来当做方向盘，看着大屏玩游戏。 AirPlay 镜像最牛的地方是可以实现双屏游戏，让你的游戏
2、有更多的交互，比如电视里显示的是游戏画面，而 iPad 上显示的是比赛的路线图。 目前， AirPlay 只适用于认证过的苹果设备，主要是苹果自己的设备，包括 iPad、 iPhone、Apple TV等， 和 一些苹果授权的合作伙伴的设备，如向 Pioneer和 Sony提供技术授权的音响。 DLNA DLNA： Digital Living Network Alliance，是索尼、英特尔、微软等发起的一套 PC、移动设备、消费电器之间互联互通的协议，其宗旨是“随时随地享受音乐 、照片和视频”。 DLNA 与 AirPlay 功能比较类似，协议也大体相同，他们都可以让你手机中的媒体内容投放
3、到电视屏幕上。不同的是手机上的 DLNA 并没有类似 Apple TV 的 AirPlay 镜像功能，也没有 Apple TV 所支持的双屏体游戏体验。目前 DLNA 更多只是能将手机的照片和视频投送到大屏幕中。 另外，在线视频也可以用 DLNA 模式推送到客厅电视上显示，安卓系统部分播放器就具备 DLNA 功能，目前支持无线推送的视频客户端有：腾讯视频、搜狐视频、 PPTV 视频 。前提是你有能支持 DLNA 的电视或电视盒。 DLNA 是 基于文件的，媒体文件可能有各种各样的编码格式，播放器这端必须能够处理这么多种编码格式，通常为了比较好的播放体验， DLNA 会先缓存一小段时间。 Mir
4、acast Miracast 是由 Wi-Fi 联盟与 2012 年所制定，以 Wi-Fi 直连为基础的无线显示标准。支持此标准的设备可通过无线方式分享视频画面，例如手机壳通过 Miracast 将影片或照片直接在电视或其它装置播放而无需受到连接线缆长度的影响。 与 DLNA 不同的是， Miracast 也有类似于 AirPlay 的镜像功能，可以将手机中屏幕内容直接投放到高清电视屏幕里， 这样你也可以通过电视屏幕来玩游戏了。 Android4.2 版本以后系统标配此功能（在设置或显示菜单中可以找到，应用名称诸如： Wlan display、 Wifi display、 Miracast、
5、Allshare cast、 Mirroring screen、无线显示等，只是各厂家命名不同而已）。可以将手机屏幕通过无线显示接收器将画面无线传输到其它较大屏幕上，画面传输延迟 150ms 以下。 Miracast 是实时的，它可以实时传输源端（ Source）的输出，源端任何屏幕的操作都会被传输到接收（ Sink）端。如果源端 是播放媒体文件，源端负责先对媒体文件解码，然后再编码为 H.264 格式，接收端只需要做 H.264 的解码就可以了。相对 DLNA， Miracast 对于 WiFi通路的要求要更高一些。 Android 下的 Miracast 实现 实际上， Miracast
6、是 Wi-Fi 联盟（ Wi-Fi Alliance）对支持 Wi-Fi Display 功能的设备的认证名称。通过 Miracast 认证的设备将在最大程度内保持对 Wi-Fi Display 功能的支持和兼容。 由此可知， Miracast考察的就是 Wi-Fi Display（本文后续将不再区分 Miracast和 Wi-Fi Display）。而 Wi-Fi Display 的核心功能就是让设备之间通过 Wi-Fi 无线网络来分享视音频数据。 图 1所示为 Wi-Fi Display 中使用的其它 Wi-Fi 技术项。 图 1 Miracast 的支撑体系结构 Wi-Fi Direct
7、：即 Wi-Fi P2P，支持在没有 AP（ Access Point）的情况下，两个 Wi-Fi设备直连并通信。 Wi-Fi Protect Setup：用于帮助用户自动配置 Wi-Fi 网络、添加 Wi-Fi 设备等。 11n/WMM/WPA2：其中 11n 指 802.11n 协议； WMM 即 Wi-Fi MultiMedia，是一种针对实时视音频数据的 QoS 服务；而 WPA2 即 Wi-Fi Protected Access 第二版，主要用来给传输的数据进行加密保护。 上述技术展，绝大部分功能由硬件厂商实现，而在 Android 中，对 Miracast 来说最重要的是两个基础技
8、术：一是 Wi-Fi Direct，该功能由 Android 中的 WifiP2pService 来管理和控制；一是 Wi-Fi MultiMedia，为了支持 Miracast， Android 4.2 对 MultiMedia 系统也进行了修改。 Miracast 的拓扑结构如图 2 所示，所支持的视音频格式如表 1。 图 2 Miracast 的四种拓扑结构 Wi-Fi Miracast Wi-Fi Direct Wi-Fi Protect Setup 11n/WMM/WPA2 分辨率 17 种 CEA 格式，分辨率从 640x480 到 1920x1080，帧率从 24 到 60 29
9、 种 VESA 格式，分辨率从 800x600 到 1920x1080，帧率从 30 到 60 12 种手持设备格式，分辨率从 640x360 到 960x540，帧率从 30 到 60 视频 H.264 高清 音频 必选： LPCM 16bits， 48kHz 采样率，双声道 可选： LPCM 16bits， 44.1kHz 采样率，双声道 Advanced Audio coding Dolby Advanced Codec 3 表 1 Miracast 视音频格式支持 Miracast 以 session 为单位来管理两个设备之间的交互工作，主要步骤包括 （按顺序） ： Device Di
10、scovery：通过 Wi-Fi P2P 来查找附近支持 Wi-Fi P2P 的设备。 Device Selection：当设备 A 发现设备 B 后， A 设备需要提示用户。用户可根据需要选择是否和设备 B 配对。 Connection Setup： Source 和 Display 设备之间通过 Wi-Fi P2P 建立连接。根据 Wi-Fi Direct 技术规范，这个步骤包括建立一个 Group Owner 和一个 Client。此后，这两个设备将建立一个 TCP 连接，同时一个用于 RTSP 协议的端口将被创建用于后续的 Session 管理和控制工作。 Capability Neg
11、otiation：在正式传输视音频数据前， Source 和 Display 设备需要交换一些 Miracast 参数信息， 如双方所支持的视音频格式，二者协商成功后，才能继续后面的流程。 Session Establishment and Streaming：上一步工作完成后， Source 和 Display 设备将建立一个 Miracast Session，而后就可以开始传输视音频数据。 Source 端的视音频数据将经由MPEG2TS编码后通过 RTP协议传给 Display设备， Display设备将解码收到的数据并显示 出来。 User Input back channel set
12、up：这是一个可选步骤，主要用于在传输过程中处理用户发起的一些控制操作，这些控制数据通过 TCP 在 Source 和 Display 设备之间传递。 Payload Control： 传输过程中，设备可根据无线信号的强弱，甚至设备的电量状况来动态调整传输数据和格式。可调整的内容包括压缩率，视音频格式，分辨率等内容 。 Session teardown：停止整个 Session。 综上所述 ， Miracast 本质上就是一个包括服务端和客户端的基于 Wi-Fi 的网络应用，服务端和客户端必须支持 RTP/RTSP 等网络协议和相应的编解码技术。 Miracast 的 Android 实现涉及
13、到系统的多个模块，包括： MediaPlayerService 及相关模块：因为 Miracast 本身就涉及到 RTP/RTSP 及相应的编解码技术。 SurfaceFlinger 及相关模块： SurfaceFlinger 的作用是将各层 UI 数据混屏并投递到显示设备中去显示。现在， SurfaceFlinger 支持多个显示设备，而支持 Miracast 的远端设备也作为一个独立的显示设备存在于系统中。 WindowManagerService 及相关模块： WindowManagerService 用于管理系统中各个UI 层的位置和属性。由于并非所有的 UI 层都会通过 Miraca
14、st 投递到远端设备上 ， 例如手机中的视频可投递到远端设备上去显示，但假如在播放过程中，突然弹出一个密码输入框（可能是某个后台应用程序发起的），则这个密码输入框就不能投递到远端设备上去显示。所以，WindowManagerService 也需要修改以适应 Miracast 的需要。 DisplayManagerService 及相关模块： DisplayManagerService 服务是 Android 4.2 新增的，用于管理系统中所有的 Display 设备。 1. SurfaceFlinger 对 Miracast 的支持 相比前面的版本， Android 4.2 中 Surface
15、Flinger 的最大变化就是增加了一个名为DisplayDevice 的抽象层。相关结构如图 3 所示 。 图 3 SurfaceFlinger 家族类图 Surface 系统定义了一个 DisplayType 的枚举，其中有代表手机屏幕的DISPLAY_PRIMARY和代表 HDMI 等外接设备的 DISPLAY_EXTERNAL。比较有意思的是，作为 Wi-Fi Display，它的设备类型是 DISPLAY_VIRTUAL。 SurfaceFlinger 类，其内部有一个名为 mDisplays 的变量，它保存了系统中当前所有的显示设备（ DisplayDevice）。另外， Surf
16、aceFlinger 通过 mCurrentState 和 mDrawingState 来控制显示层的状态。其中， mDrawingState 用来控制当前正在绘制的显示层的状态，mCurrentState 表示当前所有显示层的状态。有这两种 State 显示层的原因是不论是 Miracast还是 HDMI 设备，其在系统中存在的时间是不确定的。例如用户可以随时选择连接一个Miracast 显示设备。为了不破坏当前正在显示的内容，这个新显示设备的一些信息将保存到CurrentState 中。等到 SurfaceFlinger 下次混屏前再集中处理。 mCurrentState 和 mDrawi
17、ngState 的类型都是 SurfaceFlinger 的内部类 State。由图 3可知， State 首先通过 layerSortedByZ 变量保存了一个按 Z 轴排序的显示层数组（在 Android中，显示层的基类是 LayerBase），另外还通过 displays 变量保存了每个显示层对应的DisplayDeviceState。 DisplayDeviceState 的作用是保存对应显示层的 DisplayDevice 的属性以及一个ISurfaceTexure 接口。这个接口最终将传递给 DisplayDevice。 DisplayDevice 代表显示设备，它有两个重要的变量
18、，一个是 mFrameBufferSurface和 mNativeWindow。 mFrameBufferSurace 是 FrameBufferSurface 类型，当显示设备不属于VIRTUAL 类型的话，则该变量不为空。对于 Miracast 来说，显示数据是通过网络传递给真正的显示设备的，所有在 Source 端的 SurfaceFlinger 来说，就不存在 FrameBuffer。故当设备为 VIRTUAL 时，其对应的 mFrameBufferSurface 就为空。而 ANativeWindow 是 Android显示系统的老员工了。该结构体在多媒体的视频 I/O、 OpenG
19、L ES 等地方用得较多。而在普通的 UI 绘制中， ISurfaceTexture 接口用得较多。不过早在 Android 2.3， Google 开发人员就通过函数指针将 ANativeWindow 的各项操作和 ISurfaceTexture 接口统一起来。 作为 VIRTUAL 的 Miracast 设备是如何通过 DisplayDevice这一层抽象来加入到 Surface系统中来的呢？下面这段代码对理解 DisplayDevice 的抽象作用极为重要。如图 4 所示。 图 4 SurfaceFlinger 代码片段 由 上图代码可知： 对于非 Virtual 设备， Display
20、Device 的 FrameBufferSurface 不为空。而且SurfaceTextureClient 的构造参数来自于 FrameBufferSurface 的 getBufferQueue 函数 。 如果是 Virtual 设备， SurfaceTextureClient 直接使用了 State 信息中携带的 surface变量。 据此，可以推测出如图 5 所示的 DisplayDevice 的作用。 图 5 DisplayDevice 的隔离示意图 然后再来看看 SurfaceFlinger 中混屏操作的实现，代码如图 6 所示。 图 6 SurfaceFlinger 的混屏操作
21、由上可知， SurfaceFlinger 将遍历系统中所有的 DisplayDevice 来完成各自的混屏工作。 2. Framework 对 Miracast 的支持 为了彻底解决多显示设备的问题， Android 4.2 在 Framework 中新增了一个名为DisplayManagerService 的服务，用来统一管理系统中的显示设备。 DisplayManagerService 和系统其它几个服务都有交互。整体结构如图 7 所示 。 图 7 DisplayManagerService 及相关类图 DisplayManagerService 主要实现了 IDisplayManager
22、 接口。这个接口的大部分函数都和 Wi-Fi Display 操作相关。 DisplayManagerService 和 WindowManagerService 交互紧密。因为WindowManagerService 管理系统所有 UI 显示，包括属性， Z 轴位置等等。而且，WindowManagerService 是系统内部和 SurfaceFlinger 交互的重要通道。 DisplayManagerService 通过 mDisplayAdapters 来和 DisplayDevice 交互。每一个DisplayDevice 都对应有一个 DisplayAdapter。 系统定义了四
23、种 DisplayAdapter。 HeadlessDisplayAdapter 和 OverlayDisplayAdapter针对的都是 Fake 设备。其中 OverlayDisplay 用于帮助开发者模拟多屏幕之用。LocalDisplayAdapter 代表主屏幕，而 WifiDisplayAdapter 代表 Wi-Fi Display。 3. Android 中 Miracast 动态工作流程介绍 当用户从 Settings 程序中选择开启 Miracast 并找到匹配的 Device 后，系统将通过WifiDisplayController 的 requestConnect 函数
24、向匹配设备发起连接。代码如 下 所示： Public void requestConnect(String address) for(WifiP2pDevice device:mAvailableWifiDisplayPeers) if(device.deviceAddress.equals(address) connect(device); 连接指定设备的 connect 函数中，最重要的是 updateConnection 函数，我们抽取其中部分代码来看，如图 8 所示： 图 8 updateConnection 函数片段 在上述代码中，系统创建了一个 RemoteDisplay，并在此
25、Display 上监听 (listen)。从注释中可知，该 RemoteDisplay就是和远端 Device 交互的 RTP/RTSP 通道，而且，一旦有远端 Device连接上，还会通过 onDisplayConnected 返回一个 Surface 对象。 根据前面对 SurfaceFlinger 的介绍，读者可以猜测出 Miracast 的重头好戏就在RemoteDisplay 以及它返回的这个 Surface 上了。确实如此， RemoteDisplay 将调用MediaPlayerService 的 listenForRemoteDisplay 函数，最终会得到一个 Native的
26、 RemoteDisplay对象。相关类图如图 9所示 ，由图 9可知， RemoteDisplay 有三个重要成员变量： mLooper：指向一个 ALooper 对象。这表明 RemoteDisplay 是一个基于消息派发和处理的系统。 mNetSession：指向一个 ANetWorkSession 对象。 ANetWorkSession 提供大部分的网络操作。 mSource：指向一个 WifiDisplaySource 对象。它从 AHandler 派生，是 mLooper 中消息的处理者。注意，图中的 M1、 M3、 M5等都是 Wi-Fi Display 技术规范中指定的消息名。
27、 图 9 RemoteDisplay 类图 RemoteDisplay 构造函数中， WifiDisplaySource 的 start 函数将被调用。如此，一个类型为 kWhatStart 的消息被加到消息队列中。 该消息最终被 WifiDisplaySource 处理，结果是一个 RTSPServer 被创建。 代码如下所示： If (err = OK) If (inet_aton(iface.c_str(), err = mNetSession-createRTSPServer(mInterfaceAddr, port, notify, else err = -EINVAL; 之后，客户
28、端发送的数据都将 通过 类型为 kWhatRTSPNotify 的消息加入到系统中来。而这个消息的处理核心在 onReceiveClientData 函数中，它囊括了设备之间网络交互的所有细节。其核心代码 如图 10 所示。 图 10 onReceiveClientData 核心代码 根据前面的背景知识介绍，设备之间的交互将由 Session 来管理。在代码中， Session 的概念由 WifiSource 的内部类 PlaybackSession 来表示。先来看和其相关的类图结构，如图 11所示 ： 图 11 PlaybackSession 及相关类图 PlaybackSession 及其
29、内部类 Track 都从 AHandler 派生。故它们的工作也依赖于消息循环和处理。 Track 代表视频流或音频流。 Track 内部通过 mMediaPull 变量指向一个 MediaPull 对象。而 MediaPull 对象则保存了一个 MediaSource 对象。在 PlaybackSession 中，此 MediaSource 的真正类型为SurfaceMediaSource。它表明该 Media 的源来自 Surface。 BufferQueue 从 ISurfaceTexure 中派生，根据前面对 SurfaceFlinger 的介绍，它就是SurfaceFlinger 代
30、码示例中代表虚拟设备的 State 的 surface变量。 当双方设备准备就绪后， MediaPull 会通过 kWhatPull 消息处理不断调用 MediaSource的 read 函数。在 SurfaceMediaSource 实现的 read 函数中，来自 SurfaceFlinger 的混屏后的数据经由 BufferQueue 传递到 MediaPull 中。代码如图 12 所示： 图 12 MediaPull 和 SurfaceMediaSource 的代码示意 从上图可知， MediaPull 通过 kWhatPull 消息不断调用 MediaSource 的 read 函数；SurfaceMediaSource 的 read 函数通过 mBufferQueue 来读取数据。那么， mBufferQueue 的数据来自哪里呢？对，正是来自图 4 的 SurfaceFlinger。 然后， PlaybackSession 拿到这些数据后做编码，发送给远端设备。
