2）模塊WiFiBroadcastReceive類作為一個廣播接收器，監聽WiFi Direct事件並把結果傳遞給模塊WiFiActivity，通過WifiP2pManager類的行為描述函數來請求可用的節點， 在請求連接成功後獲得組用戶的IP。
3）模塊DeviceList顯示活動的節點和狀態。設備狀態可以分為以下5 種：設備可用（AVAILABLE）、無可用設備（UNAVAILABLE）、設備已邀請（INVITED）、設備已連接（CONNECTED）和設備連接失敗（FAILED）。
4）模塊DeviceDetail顯示被選擇設備的細節，同時進行驅動設備連接、斷開和數據傳輸[10]。
2.1.2 WiFi Direct配對流程
1）創建一個繼承自BroadcastReceiver的WiFi Direct意圖使用的廣播接收器；
2）創建一個WiFi Direct的應用WifiP2p Manager.discoverPeers（）開始掃描設備；
3）獲取掃描到的設備，選擇其中一個設備進行連接配對WifiP2pManager.connect；
4）配對成功，根據WifiP2pInfo.isGroupOwner和WifiP2pInfo.groupOwnerAddress進行連接。整個配對流程如圖3[11]所示。
2.1.3 WiFi Direct數據傳輸
WiFi Direct連接建立後通過socket在客戶端和服務器端之間進行數據的傳輸，步驟如下：
1）創建一個服務器端ServerSocket對象，因為服務器端等待來自指定地址和端口的客戶端的連接，使用accept（）方法阻塞服務器端線程直到連接發生，所以把它建立在一個後台線程裏；
2）創建一個客戶端socket，這個socket對象使用指定地址和端口去連接服務器端設備；
3）通過字節流從客戶端給服務器端發送數據；
4）服務器端可以接受來自客戶端的數據並執行關於數據的任何動作，比如保存數據或者直接顯示到屏幕。
2.2 屏幕采集及編解碼的實現
2.2.1 客戶端采集及編碼
對於Android係統而言，獲取屏幕數據的方法有很多種，在實現效果上會有所差別，主要可分為兩種：第一種是在底層直接讀取framebuffer緩存中的屏幕數據[12]；第二種是調用頂層的Android SDK進行截屏。
第一種方式中，於底層讀取framebuffer裏的屏幕數據，需要額外使用第三方的圖像編碼庫（如ffmpeg等），封裝後以JNI的方式提供給Android應用層調用，係統資源占用相對較高；所以本文選用第二種Android自帶的截屏SDK——Screen Capture完成對屏幕實時內容、寬高信息等的讀取和編碼，然後利用WiFi Direct打包socket發送。
2.2.2 服務器端解碼
服務器端對接收到的已編碼的屏幕數據使用Android核心graphics包提供的Bitmap係列相關接口進行解碼，其中的BitmapFactory類可以從一個指定數據流中，利用decodeResource（）解出（實例化出）Bitmap，然後利用setImageBitmap（）將其顯示在屏幕上。
為了減少本軟件運行時對服務器端係統資源的占用，這裏使用AsyncTask類對解碼線程和UI線程進行包裝[13]，將解碼線程剝離至後台，執行異步任務，把運行結果向UI線程通信。
3 實驗與分析
3.1 係統功能實驗
3.1.1 實驗環境
客戶端 華為手機榮耀3X一部，CPU型號MT6592M，係統版本Android 4.2，WiFi芯片Marvell 8686；
服務器端 海信智能電視LED55XT770G3D一台，係統版本Android海信訂製版2.2（支持WiFi Direct）；
軟件搭載 基於WiFi Direct的多屏融合係統軟件。
3.1.2 實驗內容及結果
1）在智能手機和智能電視上分別啟動軟件，經過設備搜索、配對後，二者通過WiFi Direct建立連接，以手機作為客戶端，以電視作為服務器端。
2）在手機上進行各種常規操作，比如觀看網絡視頻，觀察後台是否同步進行實時的截屏傳輸，電視顯示與手機是否保持一致。
3）逐項對係統各基本功能進行實驗，結果如表1。
3.2 WiFi Direct性能實驗
3.2.1 實驗環境
為了在文中體現性能對比場景的真實性，使用了另一傳統場景即WiFi覆蓋的實驗室內無線局域網環境中的多屏融合係統，與基於WiFi Direct的多屏融合係統作對比實驗，如圖4所示。
局域網WiFi多屏融合係統的實驗環境如下：
客戶端 Cortex A8 Real210開發板，WiFi芯片APM6658，搭載嵌入式Ubuntu2.0.34係統。
服務器端 ThinkPad E40筆記本電腦，搭載Ubuntu13.04係統（客戶端與服務器端均無法使用WiFi Direct，確保對比實驗的準確性）。
網絡環境 TPLINK TLWR842N 300M無線路由器覆蓋的實驗室內局域網（實驗室其他成員約20人正常使用無線路由，即路由帶寬資源占用較多）。
軟件 客戶端采用讀取/dev /fb0屏幕信息再用ffmpeg中第三方庫libavcodec編碼，進而用UDP打包通過WiFi發送的方式；服務器端使用Qt編寫的簡易顯示窗口。
基於WiFi Direct的多屏融合係統實驗環境仍如3.1.1節所示。
3.2.2 實驗內容及結果分析
兩個係統均進行各項常規操作，代碼中內嵌的clock_gettime（）等函數直接計算編解碼耗時；丟包率也通過getruntime（）等函數主動計算；用Ubuntu及Android操作係統均自帶的功能“GPU顯示配置文件”測試播放幀率。
運行時的各項性能參數對比如表2。
從對比測試結果看出，在編解碼耗時基本相當的情況下，基於WiFi Direct的多屏融合係統較之普通的局域網WiFi多屏融合係統在播放幀率上帶來了提升；係統的應用距離，即終端設備之間的傳輸距離增長了約一倍；網絡丟包率下降，使得係統的穩定性得到了很好的改善；同時，多屏融合采用P2P的模式進行，使局域網AP的接入帶寬得到了釋放。
4 結語
本文選用WiFi Direct無線數據傳輸方式，並使用智能終端設備上搭載的Android係統編解碼開發接口，設計並實現了基於WiFi Direct的多屏融合係統。實驗測試表明：在幀率、網絡穩定性和傳輸距離等方麵，本係統相較於當下依賴無線局域網的多屏融合係統具有明顯優勢，尤其是節省了局域網AP的接入帶寬，更適合在智能家居中應用推廣。同時，本文的多屏融合軟件具有較好的兼容性，在4.0及以上內核版本的Android係統均可安裝運行。需要指出的是，雖然用戶可以自主選擇終端進行連接，但暫時無法進行加密，共享數據安全性得不到保障，下一步工作將對這個因素加以考慮作進一步研究。