Android 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 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 視音訊格式支援

最後，我們簡單介紹一下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的進化速度非常快，尤其在幾個重要的功能點上。作者在此也希望國內的手機廠商或那些感興趣的移動網際網路廠商能真正投入力量做一些更有深度和價值的研發工作。

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

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