才能保证用户体验的流畅性与一致性。同时，对于流媒体数据来讲，偶尔的丢帧错误又是可以容忍的。为此本发明的技术方案如下:
[0084]请参阅图1，本发明涉及一种应用程序远程操控方法，包括步骤，
[0085]SI)用户通过客户端远程登录服务端与其握手建立通讯；
[0086]S2)用户远程请求开启应用程序；
[0087]S3)判断是否有空闲的安卓计算单元，是则继续步骤，否则结束；
[0088]S4)分配空闲的安卓计算单元给当前用户；
[0089]S5)安卓计算单元加载与对应远程登录用户的用户数据；
[0090]S6)启动对应用户远程请求的应用程序；
[0091]S7)将应用程序运行过程中的画面、音频内容编码为音视频流；
[0092]S8)将音视频流传输至远程用户的客户端；
[0093]S9)客户端展现接收到的音视频流；
[0094]S10)接收远程用户的操作指令；
[0095]Sll)判断操作指令是否为退出应用程序，否则转到步骤S12，是则关闭服务后结束；
[0096]S12)响应用户操作指令，投影用户操作于应用程序上，并返回步骤S7。
[0097]从上述描述可知，本发明的有益效果在于:通过在服务端设置虚拟的安卓计算环境，根据用户远程操作指令启动相应应用程序后，以串流的方式将远程安卓计算环境上运行应用程序的声音、图像传输给用户，并实时将用户对应用程序的操作反馈，从而达到应用程序投影用户端运行的目的。应用程序无需本地下载与安装，即点即用，结合不同的应用环境可实现包括:避免用户客户端下载应用耗费大量流量;客户端无需下载直接试用应用程序;避免恶意应用程序危害用户客户端;避免客户端单机硬件配置带来的应用程序体验差异;更换设备使用应用程序无需同步应用程序存储数据的有益效果。
[0098]发明方案应用示例:
[0099]在用户的手机(客户端)中安装“尝鲜”客户端，用户在展示的应用程序列表中任意选择一款应用，点击“尝鲜”按钮可以看到会先有一个由远程应用程序加载的过程，加载完毕后，云端应用程序完成启动，音视频流数据开始不断传送至本地，用户可像操作本地应用程序一般操作远程应用。
[0100]实施例1
[0101]上述中，所述的步骤S6前还包括，判断用户远程请求开启应用程序是否于安卓计算单元上运行的安卓系统中安装，是则转到步骤S6，否则获取应用程序并安装后转到步骤S6的步骤。
[0102]鉴于配置的安卓计算单元无法预装所有用户所需的应用程序，因此，根据用户远程请求安卓计算单元会判断是否已安装该应用，未有该运用则获取应用安装后呈现给客户端。应用程序的获取安装可从集群内的数据服务端上获取目标应用安装包后进行快速安装而实现。
[0103]实施例2
[0104]上述中，所述步骤S8中，基于UDP协议并加入ACK机制、流量控制及拥塞控制对音视频流进行传输至远程用户。
[0105]众所周知的，UDP与TCP相比，是一种无连接的、面向数据报的协议。因此更加轻量，传输速度也更快。因此本实施例中采用UDP对音视频流进行传输，可较寻常TCP传输更有传输速度的保障，从而确保客户端收到音视频流的流畅性。
[0106]但同时，由于现有的UDP协议应用中并没有TCP协议中的ACK机制以及流量控制(Flow Control)、拥塞控制(Congest1n Control)，因此UDP协议直接应用于本技术时候传输音视频流数据又不够可靠。因此，为了实现稳定的数据传输，本发明在UDP协议基础上增加了入ACK机制、流量控制及拥塞控制。从而提出一套有别于以往UDP传输的可靠UDP传输方案。
[0107]实施例3
[0108]上述中，所述步骤SI具体包括步骤，
[0109]S101)客户端发送握手数据包(handshake包)至服务端；
[0110]S102)服务端收到客户端的握手数据包；
[0111]S103)服务端生成与用户端相对应的同步cookie及密钥；
[0112]S104)服务端向客户端返回握手反馈(handshake response)、同步cookie(syncookie)及密钥(secret key)；
[0113]S105)客户端收到服务端的握手反馈、同步cookie及密钥；
[0114]S106)客户端将收到的同步cookie与握手数据包发送至服务端；
[0115]S107)服务端收到客户端的握手数据包、同步cookie;
[0116]S108)服务端比对收到同步cookie与下发的同步cookie，确认有效性，有效则执行步骤S109;
[0117]S109)服务端与客户端连接成功，建立通讯。
[0118]本实施例提供的是一种类似于tcp的3次握手方式，通过采用本实施例技术，可大幅提高客户端与服务端建立通讯的可靠度。
[0119]实施例4
[0120]上述中，所述步骤S7具体包括步骤，
[0121 ] S701)将音视频流切分为不大于网络最大传输单元(MTU)的数据包；
[0122]S702)对切分的数据包通过递增序号编号；
[0123]所述步骤S8具体包括步骤，
[0124]S801)设定初始拥塞窗口及最大拥塞窗口 ；
[0125]S802)根据当前传输速度将切分的数据包依次发往客户端；
[0126]S803)客户端根据接收数据包的序号连续性判断接收是否完整，是则转到步骤S804及S805;
[0127]S804)对接收的数据包根据序号进行数据重组；
[0128]S805)向服务端发送确认字符(ACK)包而后转到步骤S806、S807;
[0129]S806)增加传输速度，返回步骤S802 ；
[0130]S807)判断是否到达最大拥塞窗口，否则转到步骤S808;
[0131]S808)增加拥塞窗口，返回步骤S802。
[0132]本实施例为确保音视频流稳定、流畅传输至客户端而给出的一种具体实施例技术方案。方案中通过将大数据的音视频流切割数据包方式传送，并结合ACK机制、流量控制、拥塞控制从而在UDP协议传送基础上确保了音视频流传送的流畅性。
[0133]实施例5
[0134]进一步的，上述步骤S803，否则转到步骤S809;
[0135]S809)向服务端发送丢包字符包；
[0136]S810)判断积压数据包是否超过阈值，是则转到步骤S811，否则转回步骤S802;
[0137]S811)降低传输速度，返回步骤S802。
[0138]本实施例中，在拥塞控制上，传统TCP拥塞控制一般采用A頂D原则，即加法增大、乘法减小。当发生超时或丢包时，窗口立即减半，重新进入慢启动阶段。这在传统有线网络可以较好的保证流之间的公平性。而在无线网络中，则不太适用。无线网络有误码率高，传输延迟大的特点，如果采用AMD原则，将会造成传输速度不必要的降低，导致传输性能下降。本实施例中采用的是创新的丢包分析方法，通过判断丢包是由高误码率引起还是网络拥塞引从而对传输速率进行调整，保障音视频流传输的流畅性。
[0139]实施例4、5应用示例:
[0140]结合大量实验得到以下述方式具体应用实施例4、5、方案的效果最佳。
[OH1 ]在数据传输上，对于每一个音视频消息，按MTU(最大传输单元，1480字节)拆分成I个或多个数据包(Data Packet)进行传输;每个数据包通过递增的序列号进行编号，用于在接收端判断接受完整性以及数据重组恢复。接收端每收到4个数据包或者超过20毫秒将发送I个确认字符(ACK)包进行确认。
[0142]而传输过程中的拥塞控制，分慢启动与拥塞避免两个阶段，其中:
[ΟΙ43]慢启动阶段
[0144]设定初始拥塞窗口(CWND-congest1n window)，默认初始拥塞窗口大小设定为16。最大拥塞窗口，鉴于目前每个终端传输带宽最多不超过8Mbps，即IMB/s，平均包大小约400字节(经验值)，因此最大拥塞窗口略大于(lMB/s)/(400B/p)=2621即可。在增加拥塞窗口机制中，采用每收到I个ACK窗口大小加4的方案，综合而言大约需要800个往返延迟(RTT)达到最大拥塞窗口。
[0145]拥塞避免阶段
[0146]测量得到整条链路无缓存队列情况下的最小往返延迟RTTmin，由此可通过公式Expected = CWND/RTTmin计算得到理想的传输速率Expected。进一步的，通过公式Actual =CWND/RTT计算得到实际传输速率Actual。由此，链路队列中积压的数据包个数N可以估算为N=(Expected-Actual)*RTTmin。
[0147]结合大量实践得到，设置门限值(即阈值)thresh= 3时应用效果最佳。由此在判断积压数据包个数N〈thresh时，即判定为丢包是由高误码率引起的；否则判断丢包是由网络拥塞引起的，则需要降低发送速率，一种可选方案为将发送速率调整为之前的1.125倍，则传输速度降至之前的8/9。
[0148]实施例6
[0149]上述中，所述的步骤S7中对画面内容采用H.264编码;对音频内容采用AAC编码。
[0150]实施例6应用示例:
[0151]结合上述方案，当采用本实施例H.264编码画面内容时，鉴于H264协议里定义了三种帧，完整编码的帧叫I帧，参考之前的I帧生成的只包含差异部分编码的帧叫P帧，还有一种参考前后的帧编码的帧叫B帧。I帧包含完整画面，数据量通常比较大，P帧、B帧则相对较小。因此为了提高UDP的传输效率，通过