Android Wi-Fi Display（Miracast）介紹

標籤：display   ane   第二版   erb   價值   group   and   分享圖片   動態   

地址：http://blog.csdn.net/innost/article/details/8474683Android Wi-Fi Display（Miracast）介紹

2012年11月中旬，Google發布了Android 4.2。雖然它和Android 4.1同屬Jelly Bean系列，但卻添加了很多新的功能。其中，在顯示部分，Android 4.2在Project Butter基礎上再接再厲，新增了對Wi-Fi Display功能的支援。由此也導致整個顯示架構發生了較大的變化。

本文首先介紹Wi-Fi Display的背景知識，然後再結合代碼對Android 4.2中Wi-Fi Display的實現進行介紹。

一背景知識介紹

Wi-Fi Display經常和Miracast聯絡在一起。實際上，Miracast是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無線網路來分享視音頻資料。以一個簡單的應用情境為例：有了Wi-Fi Display後，手機和電視機之間可以直接藉助Wi-Fi，而無需硬連線（如HDMI）就可將手機中的視頻投遞到TV上去顯示[①]。以目前智慧型裝置的發展趨勢來看，Wi-Fi Display極有可能在較短時間內協助我們真正實現多屏互動。

從技術角度來說，Wi-Fi Display並非另起爐灶，而是充分利用了現有的Wi-Fi技術。圖1所示為Wi-Fi Display中使用的其他Wi-Fi技術項。

圖1 Miracast的支撐體繫結構

由圖1可知，Miracast依賴的Wi-Fi技術項[②]有：

• Wi-Fi Direct，也就是Wi-Fi P2P。它支援在沒有AP（Access Point）的情況下，兩個Wi-Fi裝置直連並通訊。
• Wi-Fi Protected Setup：用於協助使用者自動設定Wi-Fi網路、添加Wi-Fi裝置等。
• 11n/WMM/WPA2：其中，11n就是802.11n協議，它將11a和11g提供的Wi-Fi傳輸速率從56Mbps提升到300甚至600Mbps。WMM是Wi-Fi Multimedia的縮寫，是一種針對即時視音頻資料的QoS服務。而WPA2意為Wi-Fi Protected Acess第二版，主要用來給傳輸的資料進行加密保護。

上述的Wi-Fi技術中，絕大部分功能由硬體廠商實現。而在Android中，對Miracast來說最重要的是兩個基礎技術：

• Wi-Fi Direct：該功能由Android中的WifiP2pService來管理和控制。
• Wi-Fi Multimedia：為了支援Miracast，Android 4.2對MultiMedia系統也進行了修改。

下邊我們對Miracast幾個重要知識點進行介紹，首先是拓撲結構和視音頻格式方面的內容。

Miracast一個重要功能就是支援Wi-Fi Direct。但它也考慮了無線網路環境中存在AP裝置的情況下，裝置之間的互聯問題。讀者可參考2所示的四種拓撲結構。

圖2  Miracast的四種拓撲結構

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

另外，Miracast對所支援的視音頻格式也進行了規定，如表1所示。

表1  Miracast 視音頻格式支援

解析度	17種 CEA格式，解析度從640*480到1920*1080，幀率從24到60 29種VESA格式，解析度從800*600到1920*1200，幀率從30到60 12種手持功能格式，解析度從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為單位來管理兩個裝置之間的互動的工作，主要步驟包括（按順序）：

• Device Discovery：通過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 Negotiation：在正式傳輸視音頻資料前，Source和Display裝置需要交換一些Miracast參數資訊，例如雙方所支援的視音頻格式等。二者協商成功後，才能繼續後面的流程。
• Session Establishment and streaming：上一步工作完成後，Source和Display裝置將建立一個Miracast Session。而後就可以開始傳輸視音頻資料。Source端的視音頻資料將經由MPEG2TS編碼後通過RTP協議傳給Display裝置。Display裝置將解碼收到的資料，並最終顯示出來。
• User Input back channel setup：這是一個可選步驟。主要用於在傳輸過程中處理使用者發起的一些控制操作。這些控制資料將通過TCP在Source和Display裝置之間傳遞。
• Payload Control：傳輸過程中，裝置可根據無線訊號的強弱，甚至裝置的電量狀況來動態調整傳輸資料和格式。可調整的內容包括壓縮率，視音頻格式，解析度等內容。
• Session teardown：停止整個Session。

通過對上面背景知識的介紹，讀者可以發現：

• Miracast本質就是一個基於Wi-Fi的網路應用。這個應用程式套件括服務端和用戶端。
• 服務端和用戶端必須支援RTP/RTSP等網路通訊協定和相應的編解碼技術。

 

二  Android 4.2 Miracast功能實現介紹

Miracast的Android實現涉及到系統的多個模組，包括：

• MediaPlayerService及相關模組：原因很明顯，因為Miracast本身就牽扯到RTP/RTSP及相應的編解碼技術。
• SurfaceFlinger及相關模組：SurfaceFlinger的作用是將各層UI資料混屏並投遞到顯示裝置中去顯示。現在，SurfaceFlinger將支援多個顯示裝置。而支援Miracast的遠端裝置也做為一個獨立的顯示裝置存在於系統中。
• WindowManagerService及相關模組：WindowManagerService用於管理系統中各個UI層的位置和屬性。由於並非所有的UI層都會通過Miracast投遞到遠端裝置上。例如手機中的視頻可投遞到遠端裝置上去顯示，但假如在播放過程中，突然彈出一個密碼輸入框（可能是某個後台應用程式發起的），則這個密碼輸入框就不能投遞到遠端裝置上去顯示。所以，WindowManagerService也需要修改以適應Miracast的需要。
• DisplayManagerService及相關模組：DisplayManagerService服務是Android 4.2新增的，用於管理系統中所有的Display裝置。

由於篇幅原因，本文將重點關注SurfaceFlinger和DisplayManagerService以及Miracast的動態工作流程。

2.1  SurfaceFlinger對Miracast的支援

相比前面的版本，Android 4.2中SurfaceFlinger的最大變化就是增加了一個名為DisplayDevice的抽象層。相關結構3所示：

圖3  SurfaceFlinger家族類圖

由圖3可知：

• Surface系統定義了一個DisplayType的枚舉，其中有代表手機螢幕的DISPLAY_PRIMARY和代表HDMI等外接裝置的DISPLAY_EXTERNAL。比較有意思的是，作為Wi-Fi Display，它的裝置類型是DISPLAY_VIRTUAL。
• 再來看SurfaceFlinger類，其內部有一個名為mDisplays的變數，它儲存了系統中當前所有的顯示裝置（DisplayDevice）。另外，SurfaceFlinger通過mCurrentState和mDrawingState來控制顯示層的狀態。其中，mDrawingState用來控制當前正在繪製的顯示層的狀態，mCurrentState表示當前所有顯示層的狀態。有這兩種State顯示層的原因是不論是Miracast還是HDMI裝置，其在系統中存在的時間是不確定的。例如使用者可以隨時選擇串連一個Miracast顯示裝置。為了不破壞當前正在顯示的內容，這個新顯示裝置的一些資訊將儲存到CurrentState中。等到SurfaceFlinger下次混屏前再集中處理。
• mCurrentState和mDrawingState的類型都是SurfaceFlinger的內部類State。由圖3可知，State首先通過layerSortedByZ變數儲存了一個按Z軸排序的顯示層數組（在Android中，顯示層的基類是LayerBase），另外還通過displays變數儲存了每個顯示層對應的DisplayDeviceState。
• DisplayDeviceState的作用是儲存對應顯示層的DisplayDevice的屬性以及一個ISurfaceTexure介面。這個介面最終將傳遞給DisplayDevice。
• DisplayDevice代表顯示裝置，它有兩個重要的變數，一個是mFrameBufferSurface和mNativeWindow。mFrameBufferSurace是FrameBufferSurface類型，當顯示裝置不屬於VIRTUAL類型的話，則該變數不為空白。對於Miracast來說，顯示資料是通過網路傳遞給真正的顯示裝置的，所有在Source端的SurfaceFlinger來說，就不存在FrameBuffer。故當裝置為VIRTUAL時，其對應的mFrameBufferSurface就為空白。而ANativeWindow是Android顯示系統的老員工了。該結構體在多媒體的視頻I/O、OpenGL ES等地方用得較多。而在普通的UI繪製中，ISurfaceTexture介面用得較多。不過早在Android 2.3，Google開發人員就通過函數指標將ANativeWindow的各項操作和ISurfaceTexture介面統一起來。

作為VIRTUAL的Miracast裝置是如何通過DisplayDevice這一層抽象來加入到Surface系統中來的呢？下面這段代碼對理解DisplayDevice的抽象作用極為重要。4所示。

圖4  SurfaceFlinger程式碼片段

由圖4代碼可知：

• 對於非Virtual裝置，DisplayDevice的FrameBufferSurface不為空白。而且SurfaceTextureClient的構造參數來自於FrameBufferSurface的getBufferQueue函數。
• 如果是Virtual裝置，SurfaceTextureClient直接使用了State資訊中攜帶的surface變數。

憑著上面這兩點不同，我們可以推測出5所示的DisplayDevice的作用

圖5  DisplayDevice的隔離

最後再來看一下SurfaceFlinger中混屏操作的實現，代碼6所示：

圖6  SurfaceFilnger的混屏操作

由圖5可知，SurfaceFlinger將遍曆系統中所有的DisplayDevice來完成各自的混屏工作。

2.2  Framework對Miracast的支援

為了徹底解決多顯示裝置的問題，Android 4.2乾脆在Framework中新增了一個名為DisplayManagerService的服務，用來統一管理系統中的顯示裝置。DisplayManagerService和系統其它幾個服務都有互動。整體結構7所示。

圖7  DisplayManagerService及相關類圖

由圖7可知：

• DisplayManagerService主要實現了IDisplayManager介面。這個介面的大部分函數都和Wi-Fi Display操作相關。
• 另外，DisplayManagerService和WindowManagerService互動緊密。因為WindowManagerService管理系統所有UI顯示，包括屬性，Z軸位置等等。而且，WindowManagerService是系統內部和SurfaceFlinger互動的重要通道。
• DisplayManagerService通過mDisplayAdapters來和DisplayDevice互動。每一個DisplayDevice都對應有一個DisplayAdapter。
• 系統定義了四種DisplayAdapter。HeadlessDisplayAdapter和OverlayDisplayAdapter針對的都是Fake裝置。其中OverlayDisplay用於協助開發人員類比多螢幕之用。LocalDisplayAdapter代表主畫面，而WifiDisplayAdapter代表Wi-Fi Display。

2.3  Android中Miracast動態工作流程介紹

當使用者從Settings程式中選擇開啟Miracast並找到匹配的Device後[③]，系統將通過WifiDisplayController的requestConnect函數向匹配裝置發起串連。代碼8所示：

圖8  requestConnect函數實現

圖8中，最終將調用connect函數去串連指定的裝置。connect函數比較中，其中最重要的是updateConnection函數，我們抽取其中部分代碼來看，9所示：

圖9  updateConnection函數片段

在圖8所示的代碼中，系統建立了一個RemoteDisplay，並在這個Display上監聽（listen）。從注釋中可知，該RemoteDisplay就是和遠端Device互動的RTP/RTSP通道。而且，一旦有遠端Device串連上，還會通過onDisplayConnected返回一個Surface對象。

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

確實如此，RemoteDisplay將調用MediaPlayerService的listenForRemoteDisplay函數，最終會得到一個Native的RemoteDisplay對象。相關類圖10所示。

圖10  RemoteDisplay類圖

由圖10可知，RemoteDisplay有三個重要成員變數：

• mLooper，指向一個ALooper對象。這表明RemoteDisplay是一個基於訊息派發和處理的系統。
• mNetSession指向一個ANetWorkSession對象。從它的API來看，ANetworkSession提供大部分的網路操作。
• mSource指向一個WifiDisplaySource對象。它從AHandler派生，故它就是mLooper中訊息的處理者。注意，圖中的M1、M3、M5等都是Wi-Fi Display技術規範中指定的訊息名。

RemoteDisplay建構函式中，WifiDisplaySource的start函數將被調用。如此，一個類型為kWhatStart的訊息被加到訊息佇列中。該訊息最終被WifiDisplaySource處理，結果是一個RTSPServer被建立。代碼11所示：

圖11  kWhatStart訊息的處理結果

以後，用戶端發送的資料都將通過類型為kWhatRTSPNotify的訊息加入到系統中來。而這個訊息的處理核心在onReceiveClientData函數中，它囊括了裝置之間網路互動的所有細節。其核心代碼12所示：

圖12  onReceiveClientData核心代碼示意

圖12的內容較多，建議讀者根據需要自行研究。

根據前面的背景知識介紹，裝置之間的互動將由Session來管理。在代碼中，Session的概念由WifiSource的內部類PlaybackSession來表示。先來看和其相關的類圖結構，13所示：

圖13  PlaybackSession及相關類圖

由圖13可知：

•  PlaybackSession及其內部類Track都從AHandler派生。故它們的工作也依賴於訊息迴圈和處理。Track代表視頻流或音頻流。
• Track內部通過mMediaPull變數指向一個MediaPull對象。而MediaPull對象則儲存了一個MediaSource對象。在PlaybackSession中，此MediaSource的真正類型為SurfaceMediaSource。它表明該Media的源來自Surface。
•  BufferQueue從ISurfaceTexure中派生，根據前面對SurfaceFlinger的介紹，它就是SurfaceFlinger程式碼範例中代表虛擬設備的State的surface變數。

當雙方裝置準備就緒後，MediaPull會通過kWhatPull訊息處理不斷調用MediaSource的read函數。在SurfaceMediaSource實現的read函數中，來自SurfaceFlinger的混屏後的資料經由BufferQueue傳遞到MediaPull中。代碼14所示：

圖14  MediaPull和SurfaceMediaSource的代碼示意

從圖13可知：

• 左圖中，MediaPull通過kWhatPull訊息不斷調用MediaSource的read函數。
• 右圖中，SurfaceMediaSource的read函數由通過mBufferQueue來讀取資料。

那麼mBufferQueue的資料來自什麼地方呢？對，正是來自圖4的SurfaceFlinger。

當然，PlaybackSession拿到這些資料後還需要做編碼，然後才能發送給遠端裝置。由於篇幅關係，本文就不再討論這些問題了。

三總結

本文對Miracast的背景知識以及Android系統中Miracast的實現進行了一番簡單介紹。從筆者個人角度來看，有以下幾個點值得感興趣的讀者注意：

• 一定要結合Wi-Fi的相關協議去理解Miracast。重點關注的協議包括Wi-Fi P2p和WMM。
•  Android Miracast的實現中，需要重點理解SurfaceFlinger和RemoteDisplay模組。這部分的實現不僅代碼量大，而且類之間，以及線程之間關係複雜。
• 其他需要注意的點就是DisplayManagerService及相關模組。這部分內容在SDK中有相關API。應用開發人員應關注這些新API是否能協助自己開發出更有新意的應用程式。

另外，Android的進化速度非常快，尤其在幾個重要的功能點上。作者在此也希望國內的手機廠商或那些感興趣的移動互連網廠商能真正投入力量做一些更有深度和價值的研發工作。

 

 

[①]蘋果公司的Air Play技術和DLNA技術也實現了類似的應用情境。對它們感興趣的讀者可參考作者的一篇博文http://blog.csdn.net/innost/article/details/7078539。

[②]其他可選技術項還有TDLS和WMM Power Save。本文不討論這兩項內容

[③]這部分內容和WifiP2pService結合緊密，感興趣的讀者可自行研究。

Android Wi-Fi Display（Miracast）介紹