摘  要： 谷歌眼鏡是由谷歌公司于2012年4月發布的一款“拓展現實”眼鏡，由于其較小的體積、攜帶的方便性和強大、全面的功能使其具備相當廣闊的應用前景。基于谷歌眼鏡的硬件平臺，在安卓系統中開發了一個可以進行雙向實時圖像傳輸的軟件，該軟件借助谷歌眼鏡的攝像頭實時獲取當前時刻佩戴者所觀察到的環境信息并將它們發送到服務器中，服務器對這些信息進行處理之后將有意義的結果返回給谷歌眼鏡進行顯示。其實現的整體思路為接收數據、顯示預覽、發送數據并接收回傳數據、顯示回傳數據。

　　關鍵詞： 谷歌眼鏡；Android應用；視頻通信

0 引言

　　2007年11月，Google與84家硬件制造商、軟件開發商及電信營運商成立開放手持設備聯盟來共同研發改良Android系統，隨后，Google發布了Android的源代碼，從此各個網絡公司相繼推出各類Android應用。Google創造性地將Android系統搭載到一個“眼鏡”上，使Android系統的硬件平臺進一步地拓寬。而針對谷歌眼鏡大多還限于休閑娛樂，對其廣泛的應用背景并沒有深入地發掘。

　　在醫學領域，在大型醫療設備上還沒出現Android應用，而谷歌眼鏡的出現，將拓展其硬件平臺，使移動應用與大型醫療器械結合成為可能。本文在搭載Android系統的谷歌眼鏡上開發一個實時雙向圖像通信的應用軟件，利用TCP網絡傳輸協議，服務器處理谷歌眼鏡捕獲的圖像并回傳處理后的畫面。此應用可以用于手術中幫助醫生分辨病灶部位和動脈等關鍵部位，改變傳統的治療方式，提高醫生的工作效率。

　　對于所依賴的無線局域網絡環境，由于視頻實時傳輸的需求，選用WiFi傳輸方式；對于WiFi傳輸方式而言，連接不穩定和傳輸出錯率高一直為其缺陷，因此采用TCP網絡傳輸協議[1-2]。

　　TCP協議是一個面向連接的可靠的數據傳輸協議。TCP協議在傳輸數據之前要經歷3次握手，每次數據報文傳輸完畢后接收方還會發送一個確認ACK，發送方接收到確認ACK后才會發送下一個數據報[1，3-4]。隨著網絡中端口越來越多，TCP也曾經修改其協議以避免網絡擁塞，如慢啟動、擁塞避免、快速重傳[5-6]等算法。為了提高傳輸效率，TCP協議應用的是GBN協議，它允許發送方傳輸多個分組而不需要等待確認。TCP協議為了應對多客戶端和小封包傳輸等問題設置了諸多參數，如邏輯參數TCP_NODELAY、SO_KEEPALIVE、SO_RESUSEADDR，還有整數參數SO_SNFBUF、SO_SNFBUF等。

1 圖像傳輸系統總體設計框架

　　此圖像傳輸系統的總體設計框架簡單敘述如下：谷歌眼鏡將采集到的一幀圖像數據發送給服務器，服務器端的驗證程序不對數據做任何處理回傳給谷歌眼鏡顯示。算法總體設計框架如圖1所示。

2 移動終端通信應用設計思想

　　此應用的主要功能模塊包括捕獲并預覽、發送數據線程發送一幀JPEG格式的圖像數據和接收數據線程接收并回顯服務器已經處理過的圖像數據3個部分。發送和接收數據利用多線程實現，這樣可以節省時間，提高效率。

　　首先谷歌眼鏡開啟攝像頭，將圖像數據采集到谷歌眼鏡中并利用Android系統中的Surface對象開啟預覽[7]，采集到的圖像數據通過IO流處理后利用TCP協議發送[8]給服務器。同時服務器將接收到的數據回傳給谷歌眼鏡，谷歌眼鏡接收到數據后將數據解壓縮后利用Bitmap對象加載到屏幕上[7]，將服務器返回圖像與預覽圖像放在一起可以直觀地比較所返回的圖像與采集到的圖像在延遲、流暢程度等方面的差異。其主體框架如圖2所示。

　　2.1 谷歌眼鏡與服務器進行連接功能實現

　　初始狀態時電腦和谷歌眼鏡均不知道對方的IP地址，但均在同一個局域網內。因此在服務器程序上定義一個網段（一般為192.168），通常一個網段中會產生256個IP地址，而在其中254個IP地址中，會有一個IP地址為谷歌眼鏡的IP地址。

　　通常的做法是利用循環的原理，在主程序中創建一個IP地址，將此IP地址作為connect函數的參數，若connect函數成功執行則連接成功；若connect函數報錯則換另一個IP地址，如此最多執行254次connect函數，則可連接谷歌眼鏡。但此方法會使程序執行時間比較長，效率比較低。

　　為了縮短連接谷歌眼鏡所需要的時間，本文利用多線程方法來實現對谷歌眼鏡IP地址的查找。首先在主線程中創建254個子線程，然后將網段中的254個IP地址作為參數傳入其子線程的執行函數。此函數的作用就是嘗試對傳入的IP地址進行連接，如果連接失敗則輸出連接失敗，然后子線程結束；如果成功則將谷歌眼鏡的IP地址保存到服務器中，同時谷歌眼鏡也會保存服務器的IP地址，至此連接成功建立。服務器連接谷歌眼鏡框圖如圖3所示。

　　2.2 雙向傳輸數據

　　當谷歌眼鏡與服務器連接后，谷歌眼鏡需要將自己采集到的圖像數據傳送到服務器，服務器的測試程序不對圖像做任何處理，再重新傳回到谷歌眼鏡。

　　開始時谷歌眼鏡捕獲并保存圖像，此部分功能可以由以Android Camera框架為基礎的一些接口函數實現。利用initCamera（）函數初始化谷歌眼鏡的攝像頭，然后調用camera對象中的startPreview方法開始在谷歌眼鏡上預覽以觀察效果[7]。獲取圖像之后將圖像數據存儲在數組之中。

　　谷歌眼鏡得到一幀圖像后將原始YUV格式圖像按大約15∶1的比例壓縮成JPEG格式并存儲在數組之中。在傳輸過程中，因為服務器不知道谷歌眼鏡發送的一幀圖像大小，所以無法分配存儲空間。因而谷歌眼鏡無法直接將數據加載到輸出流中利用Socket（）函數發送出去[8]，需要提前發送一個表示一幀圖像數組長度的整數n，在服務器中建立長度為n的數組用以存儲所接收的數據。因此每傳輸每一幀圖像均需要提前傳輸一個表示數組長度的整數n，可以稱它為“數組帽”。

　　數據傳輸的初始算法為單線程傳輸算法，即在一個線程中實現圖像數據傳輸，谷歌眼鏡先傳送一幀圖像，然后等待服務器接收，服務器接收完畢后再回傳接收到的圖像。因為圖像獲取為連續的，所以一幀幀圖像連續起來，就實現了圖像的實時雙向傳輸。但是在谷歌眼鏡完成傳輸與接收服務器回傳數據之間，谷歌眼鏡處于空閑狀態，相應的服務器也有這樣的空閑狀態，即“傳輸—等待—接收—再傳輸”，這樣就增加了圖像傳輸的時間，降低了傳輸的效率。

　　針對上述方法的缺陷，本文提出一種新的圖像數據傳輸方法，稱為“雙線程算法”。在客戶端主程序中創建2個子線程，子線程A只發送圖像，子線程B只接收圖像。由于同一主程序下的線程是可以并發執行的，因此谷歌眼鏡在利用子線程A發送一幀圖像的同時可以利用子線程B接收服務器返回的一幀圖像，這樣就實現了發送和接收的并發進行，從而消除了等待時間，縮短了圖像傳輸的時間，提高了傳輸效率。

　　根據Android系統的特點，子線程被看成類的實現（對象），并且擁有自己的成員和方法。要實現上文中的雙線程算法，首先需要開啟用于接收數據的子線程B，再創建一個用于傳輸數據的對象C，將要發送的圖像數據復制給子線程A。在此程序中，復制數據的方法被寫在對象C的構造函數中，即當對象C被創建時復制數據的方法已經開始執行。當子線程B得知對象C創建后立即創建發送數據的子線程A，當子線程A得知數據已經被復制到自身的數組成員中時立即將數組加載到輸出流中，利用Socket將流中的數據加上一個“數組帽”后發送到服務器。同時線程B創建用于接收數據的Socket，一旦輸入流中有數據，則進行接收，接收完一幀圖像后利用Bitmap類將其加載到屏幕上，這樣在實際的應用中，工作人員就可以看到經過處理后的醫學圖像。

　　算法在具體實現過程中不可避免地會有一些函數之間的嵌套，其具體的實現過程如圖4所示。

　　2.3 網絡傳輸速率的優化

　　TCP傳輸協議中有一些參數是針對多客戶端情況的，但在此應用中，在一個局域網中僅有一個服務器和一個客戶端，為了提高傳輸速率，TCP協議中的一些參數需要改變。TCP協議默認開啟Nagle算法[9]，但由于Nagle算法導致的不可預測的較高的延遲以及使吞吐量降低的負面影響，需要關閉Nagle算法，即設置TCP_NODELAY為TRUE；在此應用中，僅有一個客戶端并且對實時性有較高的要求，因此要設置SO_KEEPALIVE為TRUE，即一直保持Socket端口打開，防止再次連接；當緩沖區數組長度太小時會引起阻塞，降低傳輸效率，過大又會造成內存浪費，因此可以根據一幀圖像數組長度大小合理設置緩沖區數組長度，提高程序執行速度。

　　攝像頭采集的數據被存儲在數組中，為了提高傳輸的幀率，除了上面的修改TCP中的參數以提高速率，另一個思路就是壓縮圖像數據數組的長度。GZIP算法是Android系統已經成熟應用過的壓縮算法，在一定程度上能夠壓縮數組的長度，提高傳輸速率。

3 算法實際測試

　　經實際測試，此通信軟件可以穩定運行0.5小時以上，并且在300 Mb/s帶寬情況下，平均傳輸速率可以達到895 kb/s，傳輸幀率可以穩定在11 S/s左右，基本能夠滿足設計要求。當算法為單線程時，谷歌眼鏡傳輸的幀率僅在7 S/s左右，算法改為多線程后，圖像數據傳輸的速率有明顯提高，由此說明此多線程算法有更好的執行效率。

4 結論

　　針對以上設備連接和數據傳輸所用的傳統算法的缺陷，此軟件在設計時提出利用多線程的設計思路。對單線程思想中的時間浪費行為進行優化，消除了等待時間，提高了數據傳輸的效率。

　　現階段根據對無線網絡情況下的TCP網絡出現的諸多問題，許多機構也進行了各種優化操作，但還停留在理論階段，還沒實現成熟的應用。由于Android系統的特性并為了應用軟件的可移植性，因此無法去應用那些在理論方面比現在主流的TCP協議更優的TCP改進協議，如TCP Westwood[10-11]等。

　　此通信軟件有可靠的穩定性，并且算法復雜度較小，可以高效地完成數據的傳輸。但由于WiFi網絡的不穩定性，畫面偶爾會出現卡頓現象。若是硬件條件更完善，則其效果會更佳。

參考文獻

　　[1] POSTEL J. RFC 793： Transmission control protocol[Z]. 1981.

　　[2] CERF V. RFC 1120： Internet activities board[Z]. 1990.

　　[3] SOCOLOFSKY T， KALE C. RFC 1180： TCP/IP Tutorial[Z]. 1991.

　　[4] KUROSE J F， ROSS K W. 計算機網絡：自頂向下方法[M].陳鳴，譯.北京：機械工業出版社，2009.

　　[5] ALLMAN M， PAXSON V， STEVENS W. RFC 2581： TCP congestion control[Z]. 1999.

　　[6] LAKSHMAN T V， MADHOW U. The performance of TCP/IP for networks with high bandwidth-delay products and random loss[J]. IEEE/ACM Transactions on Networking， 1997， 5（3）： 336-350.

　　[7] OSTRANDER J. Android UI基礎教程[M].劉文斌，譯.北京：人民郵電出版社，2012.

　　[8] STORIMER J. TCP Socket 編程[M].門佳，譯.北京：人民郵電出版社，2013.

　　[9] NAGLE J. RFC 896： Congestion control in IP/TCP Internetworks[Z]. 1984.

　　[10] CASETTI C， GERLA M， MASCOLO S， et al. TCP Westwood： end-to-end bandwidth estimation for enhanced transport over wireless links[J].  Journal of Wireless Networks， 2002，8（5）：467-479.

　　[11] Chen Jiwei， PAGANINI F， SANADIDI M Y. Fluid-flow analysis of TCP Westwood with RED[J]. Computer Networks，2006，50（9）：1302-1326.