先說這篇是引用轉路文章 出處, 想要研究一下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的支撐體系結構- – 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到6029種VESA格式，解析度從800*600到1920*1200，幀率從30到6012種手持設備格式，解析度從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。android/frameworks/native$ services/surfaceflinger/DisplayDevice.h
class DisplayDevice : public LightRefBase{public: // region in layer-stack space mutable Region dirtyRegion; // region in screen space mutable Region swapRegion; // region in screen space Region undefinedRegion; enum DisplayType { DISPLAY_ID_INVALID = -1, DISPLAY_PRIMARY = HWC_DISPLAY_PRIMARY, DISPLAY_EXTERNAL = HWC_DISPLAY_EXTERNAL, DISPLAY_VIRTUAL = HWC_DISPLAY_VIRTUAL, NUM_BUILTIN_DISPLAY_TYPES = HWC_NUM_PHYSICAL_DISPLAY_TYPES, };再來看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。
class SurfaceFlinger : public BnSurfaceComposer, private IBinder::DeathRecipient, private HWComposer::EventHandler{public: ...... // access must be protected by mStateLock mutable Mutex mStateLock; State mCurrentState; volatile int32_t mTransactionFlags; Condition mTransactionCV; bool mTransactionPending; bool mAnimTransactionPending; Vector< sp > mLayersPendingRemoval; SortedVector< wp > mGraphicBufferProducerList; ... // Can only accessed from the main thread, these members // don't need synchronization State mDrawingState; bool mVisibleRegionsDirty; bool mHwWorkListDirty; bool mAnimCompositionPending; // this may only be written from the main thread with mStateLock held // it may be read from other threads with mStateLock held DefaultKeyedVector< wp, sp > mDisplays; ....}; - 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代碼片段(以下是我看到的程式碼, 似乎已更改過了)
void SurfaceFlinger::init() { ...... // initialize our non-virtual displays for (size_t i=0 ; iisConnected(i) || type==DisplayDevice::DISPLAY_PRIMARY) { // All non-virtual displays are currently considered secure. bool isSecure = true; createBuiltinDisplayLocked(type); wp token = mBuiltinDisplays[i]; sp bq = new BufferQueue(new GraphicBufferAlloc()); sp fbs = new FramebufferSurface(*mHwc, i, bq); sp hw = new DisplayDevice(this, type, allocateHwcDisplayId(type), isSecure, token, fbs, bq, mEGLConfig); if (i > DisplayDevice::DISPLAY_PRIMARY) { // FIXME: currently we don't get blank/unblank requests // for displays other than the main display, so we always // assume a connected display is unblanked. ALOGD("marking display %d as acquired/unblanked", i); hw->acquireScreen(); } mDisplays.add(token, hw); } } ...}由圖4代碼可知：
- 對於非Virtual設備，DisplayDevice的FrameBufferSurface不為空。而且SurfaceTextureClient的構造參數來自於FrameBufferSurface的getBufferQueue函數。
- 如果是Virtual設備，SurfaceTextureClient直接使用了State信息中攜帶的surface變數。
憑著上面這兩點不同，我們可以推測出如圖5所示的DisplayDevice的作用
圖5 DisplayDevice的隔離示意圖由圖5可知，SurfaceFlinger將遍歷系統中所有的DisplayDevice來完成各自的混屏工作。
最後再來看一下SurfaceFlinger中混屏操作的實現，代碼如圖6所示：
圖6 SurfaceFilnger的混屏操作SurfaceFlinger.cppvoid SurfaceFlinger::doComposition() { ATRACE_CALL(); const bool repaintEverything = android_atomic_and(0, &mRepaintEverything); for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) { const sp& hw(mDisplays[dpy]); if (hw->canDraw()) { // transform the dirty region into this screen's coordinate space const Region dirtyRegion(hw->getDirtyRegion(repaintEverything)); // repaint the framebuffer (if needed) doDisplayComposition(hw, dirtyRegion); hw->dirtyRegion.clear(); hw->flip(hw->swapRegion); hw->swapRegion.clear(); } // inform the h/w that we're done compositing hw->compositionComplete(); } postFramebuffer();}2.2 Framework對Miracast的支持
為了徹底解決多顯示設備的問題，Android 4.2乾脆在Framework中新增了一個名為DisplayManagerService的服務，用來統一管理系統中的顯示設備。
DisplayManagerService和系統其它幾個服務都有交互。整體結構如圖7所示。
android/frameworks/base/services/java/com/android/server/display/DisplayManagerService.java
圖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的進化速度非常快，尤其在幾個重要的功能點上。作者在此也希望國內的手機廠商或那些感興趣的移動互聯網廠商能真正投入力量做一些更有深度和價值的研發工作。
