Android 4.2 中Miracast功能的實(shí)現(xiàn)詳解

在前幾年，Google發(fā)布了Android 4.2。雖然它和Android 4.1同屬Jelly Bean系列，但卻添加了很多新的功能。其中，在顯示部分，Android 4.2在Project Butter基礎(chǔ)上再接再厲，新增了對Wi-Fi Display功能的支持。由此也導(dǎo)致整個(gè)顯示架構(gòu)發(fā)生了較大的變化。

本文首先介紹Wi-Fi Display的背景知識，然后再結(jié)合代碼對Android 4.2中Wi-Fi Display的實(shí)現(xiàn)進(jìn)行介紹。

一背景知識介紹

Wi-Fi Display經(jīng)常和Miracast聯(lián)系在一起。實(shí)際上，Miracast是Wi-Fi聯(lián)盟（Wi-Fi Alliance）對支持Wi-Fi Display功能的設(shè)備的認(rèn)證名稱。通過Miracast認(rèn)證的設(shè)備將在最大程度內(nèi)保持對Wi-Fi Display功能的支持和兼容。由此可知，Miracast考察的就是Wi-Fi Display（本文后續(xù)將不再區(qū)分Miracast和Wi-Fi Display）。而Wi-Fi Display的核心功能就是讓設(shè)備之間通過Wi-Fi無線網(wǎng)絡(luò)來分享視音頻數(shù)據(jù)。以一個(gè)簡單的應(yīng)用場景為例：有了Wi-Fi Display后，手機(jī)和電視機(jī)之間可以直接借助Wi-Fi，而無需硬連線（如HDMI）就可將手機(jī)中的視頻投遞到TV上去顯示[①]。以目前智能設(shè)備的發(fā)展趨勢來看，Wi-Fi Display極有可能在較短時(shí)間內(nèi)幫助我們真正實(shí)現(xiàn)多屏互動。

從技術(shù)角度來說，Wi-Fi Display并非另起爐灶，而是充分利用了現(xiàn)有的Wi-Fi技術(shù)。圖1所示為Wi-Fi Display中使用的其他Wi-Fi技術(shù)項(xiàng)。

圖1 Miracast的支撐體系結(jié)構(gòu)

由圖1可知，Miracast依賴的Wi-Fi技術(shù)項(xiàng)[②]有：

Wi-Fi Direct，也就是Wi-Fi P2P。它支持在沒有AP（Access Point）的情況下，兩個(gè)Wi-Fi設(shè)備直連并通信。Wi-Fi Protected Setup：用于幫助用戶自動配置Wi-Fi網(wǎng)絡(luò)、添加Wi-Fi設(shè)備等。11n/WMM/WPA2：其中，11n就是802.11n協(xié)議，它將11a和11g提供的Wi-Fi傳輸速率從56Mbps提升到300甚至600Mbps。WMM是Wi-Fi Multimedia的縮寫，是一種針對實(shí)時(shí)視音頻數(shù)據(jù)的QoS服務(wù)。而WPA2意為Wi-Fi Protected Acess第二版，主要用來給傳輸?shù)臄?shù)據(jù)進(jìn)行加密保護(hù)。

上述的Wi-Fi技術(shù)中，絕大部分功能由硬件廠商實(shí)現(xiàn)。而在Android中，對Miracast來說最重要的是兩個(gè)基礎(chǔ)技術(shù)：

Wi-Fi Direct：該功能由Android中的WifiP2pService來管理和控制。Wi-Fi Multimedia：為了支持Miracast，Android 4.2對MultiMedia系統(tǒng)也進(jìn)行了修改。

下邊我們對Miracast幾個(gè)重要知識點(diǎn)進(jìn)行介紹，首先是拓?fù)浣Y(jié)構(gòu)和視音頻格式方面的內(nèi)容。

Miracast一個(gè)重要功能就是支持Wi-Fi Direct。但它也考慮了無線網(wǎng)絡(luò)環(huán)境中存在AP設(shè)備的情況下，設(shè)備之間的互聯(lián)問題。讀者可參考如圖2所示的四種拓?fù)浣Y(jié)構(gòu)。

圖2 ?Miracast的四種拓?fù)浣Y(jié)構(gòu)

圖2所示內(nèi)容比較簡單，此處就不再詳述。另外，在Wi-Fi Display規(guī)范中，還存在著Source將Video和Audio內(nèi)容分別傳送給不同Render Device的情況。感興趣的讀者可參考Wi-Fi Display技術(shù)規(guī)范。

另外，Miracast對所支持的視音頻格式也進(jìn)行了規(guī)定，如表1所示。

表1? Miracast?視音頻格式支持

分辨率

17種?CEA格式，分辨率從640*480到1920*1080，幀率從24到60

29種VESA格式，分辨率從800*600到1920*1200，幀率從30到60

12種手持設(shè)備格式，分辨率從640*360到960*540，幀率從30到60

視頻

H.264高清

音頻

必選：LPCM 16bits，48kHz采樣率，雙聲道

可選：

LPCM 16bits，44.1kHz采樣率，雙聲道

Advanced Audio coding

Dolby Advanced Codec 3

最后，我們簡單介紹一下Miracast的大體工作流程。Miracast以session為單位來管理兩個(gè)設(shè)備之間的交互的工作，主要步驟包括（按順序）：

Device Discovery：通過Wi-Fi P2P來查找附近的支持Wi-Fi P2P的設(shè)備。Device Selection：當(dāng)設(shè)備A發(fā)現(xiàn)設(shè)備B后，A設(shè)備需要提示用戶。用戶可根據(jù)需要選擇是否和設(shè)備B配對。Connection Setup：Source和Display設(shè)備之間通過Wi-Fi P2P建立連接。根據(jù)Wi-Fi Direct技術(shù)規(guī)范，這個(gè)步驟包括建立一個(gè)Group Owner和一個(gè)Client。此后，這兩個(gè)設(shè)備將建立一個(gè)TCP連接，同時(shí)一個(gè)用于RTSP協(xié)議的端口將被創(chuàng)建用于后續(xù)的Session管理和控制工作。Capability Negotiation：在正式傳輸視音頻數(shù)據(jù)前，Source和Display設(shè)備需要交換一些Miracast參數(shù)信息，例如雙方所支持的視音頻格式等。二者協(xié)商成功后，才能繼續(xù)后面的流程。Session Establishment and streaming：上一步工作完成后，Source和Display設(shè)備將建立一個(gè)Miracast Session。而后就可以開始傳輸視音頻數(shù)據(jù)。Source端的視音頻數(shù)據(jù)將經(jīng)由MPEG2TS編碼后通過RTP協(xié)議傳給Display設(shè)備。Display設(shè)備將解碼收到的數(shù)據(jù)，并最終顯示出來。User Input back channel setup：這是一個(gè)可選步驟。主要用于在傳輸過程中處理用戶發(fā)起的一些控制操作。這些控制數(shù)據(jù)將通過TCP在Source和Display設(shè)備之間傳遞。Payload Control：傳輸過程中，設(shè)備可根據(jù)無線信號的強(qiáng)弱，甚至設(shè)備的電量狀況來動態(tài)調(diào)整傳輸數(shù)據(jù)和格式?？烧{(diào)整的內(nèi)容包括壓縮率，視音頻格式，分辨率等內(nèi)容。Session teardown：停止整個(gè)Session。

通過對上面背景知識的介紹，讀者可以發(fā)現(xiàn)：

Miracast本質(zhì)就是一個(gè)基于Wi-Fi的網(wǎng)絡(luò)應(yīng)用。這個(gè)應(yīng)用包括服務(wù)端和客戶端。服務(wù)端和客戶端必須支持RTP/RTSP等網(wǎng)絡(luò)協(xié)議和相應(yīng)的編解碼技術(shù)。

?

二? Android 4.2 Miracast功能實(shí)現(xiàn)介紹

Miracast的Android實(shí)現(xiàn)涉及到系統(tǒng)的多個(gè)模塊，包括：

MediaPlayerService及相關(guān)模塊：原因很明顯，因?yàn)镸iracast本身就牽扯到RTP/RTSP及相應(yīng)的編解碼技術(shù)。SurfaceFlinger及相關(guān)模塊：SurfaceFlinger的作用是將各層UI數(shù)據(jù)混屏并投遞到顯示設(shè)備中去顯示?，F(xiàn)在，SurfaceFlinger將支持多個(gè)顯示設(shè)備。而支持Miracast的遠(yuǎn)端設(shè)備也做為一個(gè)獨(dú)立的顯示設(shè)備存在于系統(tǒng)中。WindowManagerService及相關(guān)模塊：WindowManagerService用于管理系統(tǒng)中各個(gè)UI層的位置和屬性。由于并非所有的UI層都會通過Miracast投遞到遠(yuǎn)端設(shè)備上。例如手機(jī)中的視頻可投遞到遠(yuǎn)端設(shè)備上去顯示，但假如在播放過程中，突然彈出一個(gè)密碼輸入框（可能是某個(gè)后臺應(yīng)用程序發(fā)起的），則這個(gè)密碼輸入框就不能投遞到遠(yuǎn)端設(shè)備上去顯示。所以，WindowManagerService也需要修改以適應(yīng)Miracast的需要。DisplayManagerService及相關(guān)模塊：DisplayManagerService服務(wù)是Android 4.2新增的，用于管理系統(tǒng)中所有的Display設(shè)備。

由于篇幅原因，本文將重點(diǎn)關(guān)注SurfaceFlinger和DisplayManagerService以及Miracast的動態(tài)工作流程。

2.1? SurfaceFlinger對Miracast的支持

相比前面的版本，Android 4.2中SurfaceFlinger的最大變化就是增加了一個(gè)名為DisplayDevice的抽象層。相關(guān)結(jié)構(gòu)如圖3所示：

圖3 ?SurfaceFlinger家族類圖

由圖3可知：

Surface系統(tǒng)定義了一個(gè)DisplayType的枚舉，其中有代表手機(jī)屏幕的DISPLAY_PRIMARY和代表HDMI等外接設(shè)備的DISPLAY_EXTERNAL。比較有意思的是，作為Wi-Fi Display，它的設(shè)備類型是DISPLAY_VIRTUAL。再來看SurfaceFlinger類，其內(nèi)部有一個(gè)名為mDisplays的變量，它保存了系統(tǒng)中當(dāng)前所有的顯示設(shè)備（DisplayDevice）。另外，SurfaceFlinger通過mCurrentState和mDrawingState來控制顯示層的狀態(tài)。其中，mDrawingState用來控制當(dāng)前正在繪制的顯示層的狀態(tài)，mCurrentState表示當(dāng)前所有顯示層的狀態(tài)。有這兩種State顯示層的原因是不論是Miracast還是HDMI設(shè)備，其在系統(tǒng)中存在的時(shí)間是不確定的。例如用戶可以隨時(shí)選擇連接一個(gè)Miracast顯示設(shè)備。為了不破壞當(dāng)前正在顯示的內(nèi)容，這個(gè)新顯示設(shè)備的一些信息將保存到CurrentState中。等到SurfaceFlinger下次混屏前再集中處理。mCurrentState和mDrawingState的類型都是SurfaceFlinger的內(nèi)部類State。由圖3可知，State首先通過layerSortedByZ變量保存了一個(gè)按Z軸排序的顯示層數(shù)組（在Android中，顯示層的基類是LayerBase），另外還通過displays變量保存了每個(gè)顯示層對應(yīng)的DisplayDeviceState。DisplayDeviceState的作用是保存對應(yīng)顯示層的DisplayDevice的屬性以及一個(gè)ISurfaceTexure接口。這個(gè)接口最終將傳遞給DisplayDevice。DisplayDevice代表顯示設(shè)備，它有兩個(gè)重要的變量，一個(gè)是mFrameBufferSurface和mNativeWindow。mFrameBufferSurace是FrameBufferSurface類型，當(dāng)顯示設(shè)備不屬于VIRTUAL類型的話，則該變量不為空。對于Miracast來說，顯示數(shù)據(jù)是通過網(wǎng)絡(luò)傳遞給真正的顯示設(shè)備的，所有在Source端的SurfaceFlinger來說，就不存在FrameBuffer。故當(dāng)設(shè)備為VIRTUAL時(shí)，其對應(yīng)的mFrameBufferSurface就為空。而ANativeWindow是Android顯示系統(tǒng)的老員工了。該結(jié)構(gòu)體在多媒體的視頻I/O、OpenGL ES等地方用得較多。而在普通的UI繪制中，ISurfaceTexture接口用得較多。不過早在Android 2.3，Google開發(fā)人員就通過函數(shù)指針將ANativeWindow的各項(xiàng)操作和ISurfaceTexture接口統(tǒng)一起來。

作為VIRTUAL的Miracast設(shè)備是如何通過DisplayDevice這一層抽象來加入到Surface系統(tǒng)中來的呢？下面這段代碼對理解DisplayDevice的抽象作用極為重要。如圖4所示。

圖4? SurfaceFlinger代碼片段

由圖4代碼可知：

對于非Virtual設(shè)備，DisplayDevice的FrameBufferSurface不為空。而且SurfaceTextureClient的構(gòu)造參數(shù)來自于FrameBufferSurface的getBufferQueue函數(shù)。如果是Virtual設(shè)備，SurfaceTextureClient直接使用了State信息中攜帶的surface變量。

憑著上面這兩點(diǎn)不同，我們可以推測出如圖5所示的DisplayDevice的作用

圖5? DisplayDevice的隔離示意圖

最后再來看一下SurfaceFlinger中混屏操作的實(shí)現(xiàn)，代碼如圖6所示：

圖6? SurfaceFilnger的混屏操作

由圖5可知，SurfaceFlinger將遍歷系統(tǒng)中所有的DisplayDevice來完成各自的混屏工作。

2.2? Framework對Miracast的支持

為了徹底解決多顯示設(shè)備的問題，Android 4.2干脆在Framework中新增了一個(gè)名為DisplayManagerService的服務(wù)，用來統(tǒng)一管理系統(tǒng)中的顯示設(shè)備。DisplayManagerService和系統(tǒng)其它幾個(gè)服務(wù)都有交互。整體結(jié)構(gòu)如圖7所示。

圖7? DisplayManagerService及相關(guān)類圖

由圖7可知：

DisplayManagerService主要實(shí)現(xiàn)了IDisplayManager接口。這個(gè)接口的大部分函數(shù)都和Wi-Fi Display操作相關(guān)。另外，DisplayManagerService和WindowManagerService交互緊密。因?yàn)閃indowManagerService管理系統(tǒng)所有UI顯示，包括屬性，Z軸位置等等。而且，WindowManagerService是系統(tǒng)內(nèi)部和SurfaceFlinger交互的重要通道。DisplayManagerService通過mDisplayAdapters來和DisplayDevice交互。每一個(gè)DisplayDevice都對應(yīng)有一個(gè)DisplayAdapter。系統(tǒng)定義了四種DisplayAdapter。HeadlessDisplayAdapter和OverlayDisplayAdapter針對的都是Fake設(shè)備。其中OverlayDisplay用于幫助開發(fā)者模擬多屏幕之用。LocalDisplayAdapter代表主屏幕，而WifiDisplayAdapter代表Wi-Fi Display。 2.3? Android中Miracast動態(tài)工作流程介紹

當(dāng)用戶從Settings程序中選擇開啟Miracast并找到匹配的Device后[③]，系統(tǒng)將通過WifiDisplayController的requestConnect函數(shù)向匹配設(shè)備發(fā)起連接。代碼如圖8所示：

圖8? requestConnect函數(shù)實(shí)現(xiàn)

圖8中，最終將調(diào)用connect函數(shù)去連接指定的設(shè)備。connect函數(shù)比較中，其中最重要的是updateConnection函數(shù)，我們抽取其中部分代碼來看，如圖9所示：

圖9? updateConnection函數(shù)片段

在圖8所示的代碼中，系統(tǒng)創(chuàng)建了一個(gè)RemoteDisplay，并在這個(gè)Display上監(jiān)聽（listen）。從注釋中可知，該RemoteDisplay就是和遠(yuǎn)端Device交互的RTP/RTSP通道。而且，一旦有遠(yuǎn)端Device連接上，還會通過onDisplayConnected返回一個(gè)Surface對象。

根據(jù)前面對SurfaceFlinger的介紹，讀者可以猜測出Miracast的重頭好戲就在RemoteDisplay以及它返回的這個(gè)Surface上了。

確實(shí)如此，RemoteDisplay將調(diào)用MediaPlayerService的listenForRemoteDisplay函數(shù)，最終會得到一個(gè)Native的RemoteDisplay對象。相關(guān)類圖如圖10所示。

圖10? RemoteDisplay類圖

由圖10可知，RemoteDisplay有三個(gè)重要成員變量：

mLooper，指向一個(gè)ALooper對象。這表明RemoteDisplay是一個(gè)基于消息派發(fā)和處理的系統(tǒng)。mNetSession指向一個(gè)ANetWorkSession對象。從它的API來看，ANetworkSession提供大部分的網(wǎng)絡(luò)操作。mSource指向一個(gè)WifiDisplaySource對象。它從AHandler派生，故它就是mLooper中消息的處理者。注意，圖中的M1、M3、M5等都是Wi-Fi Display技術(shù)規(guī)范中指定的消息名。

RemoteDisplay構(gòu)造函數(shù)中，WifiDisplaySource的start函數(shù)將被調(diào)用。如此，一個(gè)類型為kWhatStart的消息被加到消息隊(duì)列中。該消息最終被WifiDisplaySource處理，結(jié)果是一個(gè)RTSPServer被創(chuàng)建。代碼如圖11所示：

圖11? kWhatStart消息的處理結(jié)果

以后，客戶端發(fā)送的數(shù)據(jù)都將通過類型為kWhatRTSPNotify的消息加入到系統(tǒng)中來。而這個(gè)消息的處理核心在onReceiveClientData函數(shù)中，它囊括了設(shè)備之間網(wǎng)絡(luò)交互的所有細(xì)節(jié)。其核心代碼如圖12所示：

圖12? onReceiveClientData核心代碼示意

圖12的內(nèi)容較多，建議讀者根據(jù)需要自行研究。

根據(jù)前面的背景知識介紹，設(shè)備之間的交互將由Session來管理。在代碼中，Session的概念由WifiSource的內(nèi)部類PlaybackSession來表示。先來看和其相關(guān)的類圖結(jié)構(gòu)，如圖13所示：

圖13? PlaybackSession及相關(guān)類圖

由圖13可知：

?PlaybackSession及其內(nèi)部類Track都從AHandler派生。故它們的工作也依賴于消息循環(huán)和處理。Track代表視頻流或音頻流。Track內(nèi)部通過mMediaPull變量指向一個(gè)MediaPull對象。而MediaPull對象則保存了一個(gè)MediaSource對象。在PlaybackSession中，此MediaSource的真正類型為SurfaceMediaSource。它表明該Media的源來自Surface。?BufferQueue從ISurfaceTexure中派生，根據(jù)前面對SurfaceFlinger的介紹，它就是SurfaceFlinger代碼示例中代表虛擬設(shè)備的State的surface變量。

當(dāng)雙方設(shè)備準(zhǔn)備就緒后，MediaPull會通過kWhatPull消息處理不斷調(diào)用MediaSource的read函數(shù)。在SurfaceMediaSource實(shí)現(xiàn)的read函數(shù)中，來自SurfaceFlinger的混屏后的數(shù)據(jù)經(jīng)由BufferQueue傳遞到MediaPull中。代碼如圖14所示：

圖14? MediaPull和SurfaceMediaSource的代碼示意

從圖13可知：

左圖中，MediaPull通過kWhatPull消息不斷調(diào)用MediaSource的read函數(shù)。右圖中，SurfaceMediaSource的read函數(shù)由通過mBufferQueue來讀取數(shù)據(jù)。

那么mBufferQueue的數(shù)據(jù)來自什么地方呢？對，正是來自圖4的SurfaceFlinger。

當(dāng)然，PlaybackSession拿到這些數(shù)據(jù)后還需要做編碼，然后才能發(fā)送給遠(yuǎn)端設(shè)備。由于篇幅關(guān)系，本文就不再討論這些問題了。

三總結(jié)

本文對Miracast的背景知識以及Android系統(tǒng)中Miracast的實(shí)現(xiàn)進(jìn)行了一番簡單介紹。從筆者個(gè)人角度來看，有以下幾個(gè)點(diǎn)值得感興趣的讀者注意：

一定要結(jié)合Wi-Fi的相關(guān)協(xié)議去理解Miracast。重點(diǎn)關(guān)注的協(xié)議包括Wi-Fi P2p和WMM。?Android Miracast的實(shí)現(xiàn)中，需要重點(diǎn)理解SurfaceFlinger和RemoteDisplay模塊。這部分的實(shí)現(xiàn)不僅代碼量大，而且類之間，以及線程之間關(guān)系復(fù)雜。其他需要注意的點(diǎn)就是DisplayManagerService及相關(guān)模塊。這部分內(nèi)容在SDK中有相關(guān)API。應(yīng)用開發(fā)者應(yīng)關(guān)注這些新API是否能幫助自己開發(fā)出更有新意的應(yīng)用程序。

另外，Android的進(jìn)化速度非?？?，尤其在幾個(gè)重要的功能點(diǎn)上。作者在此也希望國內(nèi)的手機(jī)廠商或那些感興趣的移動互聯(lián)網(wǎng)廠商能真正投入力量做一些更有深度和價(jià)值的研發(fā)工作。

[①]蘋果公司的Air Play技術(shù)和DLNA技術(shù)也實(shí)現(xiàn)了類似的應(yīng)用場景。對它們感興趣的讀者可參考作者的一篇博文http://blog.csdn.net/innost/article/details/7078539。

[②]其他可選技術(shù)項(xiàng)還有TDLS和WMM Power Save。本文不討論這兩項(xiàng)內(nèi)容

[③]這部分內(nèi)容和WifiP2pService結(jié)合緊密，感興趣的讀者可自行研究。