摘 要：谷歌眼镜是由谷歌公司于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.