基于Android的自适应移动云计算应用框架

王汇彬，赵生慧

随着移动互联网的发展和智能手机的普及，越来越多的应用和软件开始从 PC端向手机端迁移，智能手机已经从最终的通讯工具转变为日常生活中的一个个重要组成部分。虽然智能手机的性能在近年来得到了不断提升，但与PC或工作站相比，所拥有的资源仍然有较大的差距。解决该问题的一种方法是整合移动计算和云计算技术，将计算或存储从移动设备迁移到资源丰富的云计算平台，使得移动设备可以运行计算密集或资源密集的应用。

本文综合考虑计算迁移成本、通信成本、应用复杂度等因素，提出了一种自适应的移动云计算框架，通过权衡迁移成本及效益，应用可被自动分发至云端或本地执行。此外，计算迁移应用Java反射机制设计，可以降低移动云应用开发的复杂度。

1 相关工作

随着移动设备的普及，用户对于在移动设备上运行更大的程序有了更强烈的需求。文献[1]对未来十年移动计算的研究进行了展望，详细描述了移动计算的两个应用场景：“走失的小孩”和“灾难求助”。该文提出未来的移动计算应该在传统的CS架构上增加一个Cloudlet层，移动设备通过一跳高带宽网络连接Cloudlet，Cloudlet类似于一个小数据中心，位于指定区域/位置并通过互联网连接到一个更大的云服务器上。文献[2]综述了现有的移动云计算的研究，给出了移动云计算的三种定义：①移动云计算指的是应用运行在远程具有丰富资源的服务器，而移动设备扮演瘦客户端的角色；②移动设备自身充当云资源的提供者，构成一个 P2P网络；③使用文献[1]提出的Cloudlet概念实现移动云计算。

已有的实现移动云计算的技术主要包括：远程显示、客户机-服务器通信、虚拟机迁移和代码迁移。

①远程显示：移动设备通过远程显示的方式连接上云端，将屏幕渲染的工作交给云端完成。受限的电源、多样的无线信道条件及通信延时是移动云计算中远程显示的挑战。文献[3-4]介绍了解决这些问题的几种方法，如多样化图像编码、减少下行数据、预更新计算屏幕、场景对象缓存等。

②客户机-服务器通信：移动设备和代理设备间通过 RPC、RMI、Socket等方法实现通信，需要预先在参与计算的设备上安装服务。文献[5]提出了mClouds移动云计算框架，支持在一组移动设备上运行资源密集型应用。[6]提出了应用于Android的“Hyrax”，将Hadoop迁移到了Android平台，Hyrax使用一组智能手机集群作为资源的提供者，实现了一个简单的分布式系列多媒体检索和共享的示例应用“HyraxTube”。[7]提出了一个框架用于创建虚拟移动云服务提供者，该框架应用当前区域内的移动设备模拟了一个传统的云服务提供者，解决智能手机资源受限的问题。

③虚拟机迁移：使用该方式实现移动云计算，可以使得程序在迁移时不需要修改，并且提供了一个相对安全的环境，但是通常会带来较大的时间和资源开销。CloneCloud[8]使用虚拟机迁移的方式将应用的部分负载迁移到资源丰富的服务器上运行，应用不需要进行修改。

④代码迁移：文献[9]提出一种应用框架Scavenger，通过代码迁移的方法来分发作业至代理服务器。该框架由两个部分组成：运行在代理服务器上用于接收和执行任务的守护进程和客户端应用所使用的库。客户端库和守护进程均使用Stackless Python编写。

已有的研究更多的关注于如何将计算从资源受限的移动设备迁移至其它资源提供者，但由于受到网络带宽、应用复杂度、待处理数据的大小、云节点和移动设备的性能等因素的影响，将计算从移动设备迁移至云端可能并不是最优的操作。本文提出了一种成本效益模型，对迁移开销进行了分析，由此来决定是否执行迁移操作。此外，本文提出的框架应用模块化设计，应用只需打包成独立的组件即可置于本框架运行，降低了移动云应用开发的复杂度。本文方案与其它方案的对比分析结果如表1所示。

表1 移动云计算框架对比分析

2 系统设计

2.1 自适应移动云计算应用框架设计

本文应用移动云计算技术解决移动设备资源受限的问题，提出一种自适应的移动云计算框架。通过分析计算迁移到云端所带来的开销，决定是否迁移计算。系统采用模块化设计，应用程序被打包成独立的组件，组件可运行于移动设备或云端的Java虚拟机上，应用Java反射机制实现动态调用。框架的总体架构如图1所示。

该框架包含移动客户端和云服务器端两部分。具体结构如下：

（1）移动客户端

移动客户端主要由四个模块组成，如图1所示。移动应用前端（Application Frontend）为用户提供云应用的入口，通过Web服务获取云中提供的应用列表。用户执行某应用时，首先根据成本效益模块（Cost-benefit Module）计算该应用迁移到云中的成本与本地执行的成本，若是在云中执行的成本较低，则调用相应的Web服务将待处理的数据发送至云端，待数据处理完成后获取结果并显示；反之则将云中的代码迁移至本地，交由移动代码执行环境（Mobile Code Execution Environment）执行。

图1 基于成本的自适应移动云计算框架总体架构

（2）云服务器端

云服务器端主要由迁移管理模块（Offloading Manager）、作业调度模块（Job Scheduling Module）、应用库管理模块（App Lib Manager）、移动代码执行环境和云基础设施（Cloud infrastructure）组成。迁移管理模块对外提供迁移接口，获取用户的待处理数据或发送代码至移动设备。应用库管理模块用于管移动云中支持的所有应用。用户提交计算作业后，作业调度模块负责将作业发送至云基础设施（提供计算和存储资源），交由移动代码执行环境执行；应用库管理模块用于管理云中支持的所有应用。

2.2 计算迁移算法

移动应用种类繁多，不同种类的应用具有不同的特征，通常可将应用分成计算密集型、数据密集型、计算数据密集型及 I/O密集型等。本文主要针对计算密集型和数据密集型任务进行讨论。若通过成本效益模型判定应用为计算密集型任务，则本框架会采取“数据迁移”的策略，即将待处理的数据发送至云端进行处理；若应用为数据密集型任务，则借鉴MapReduce中“代码迁移”的策略，将云中的处理代码下载至移动端，计算由移动端完成。

算法伪代码如下：

2.3 成本效益模型

本文提出的成本效益模型用于分析计算迁移到云上的时间成本，主要考虑的参数有：应用的复杂度、移动设备及远程云的相对速度、数据迁移速率、应用代码大小、待处理数据大小及处理结果的数据大小。目标是最小化迁移带来的时间开销。时间开销主要包括待处理数据（代码）的迁移时间和应用的执行时间。

本文测试了不同大小的文件在WLAN环境下的迁移时间，迁移时间主要包括数据在网络上的传输时间 Ttransmit、建立和释放连接的时间Tconnection以及数据读写存储设备 Taccess的时间。测试结果如图2所示。从该图中可以看出，当文件小于 16KB时，迁移时间大致相同，这是由于 Tconnection》Ttransmit+Taccess。而当文件大于 64KB时，迁移速率趋近于平衡，约为1.1MB/S。根据图中数据，本文得出数据迁移开销函数f(x)（单位：毫秒），x为待迁移的数据大小（单位：KB），如式（1）所示。

图2 不同大小文件的迁移时间和迁移速率

应用的执行时间与应用的复杂度有关，应用的复杂度通过应用在远程云上的执行时间衡量，由Tcloud表示；由于移动设备及远程云节点的架构不同，因此不能简单使用 CPU的主频衡量运算速度，本文引入跨平台基准测试软件Geekbench[10]，通过测试得分估算移动设备及远程云节点的速度，设定远程云节点的速度是移动设备的M倍。

计算迁移到远程云中的成本Cremote由式(2)表示：

计算在本地执行的成本Clocal由式(3)表示：

当Cremote＜Clocal时，即满足式(4)时，采用数据迁移策略，反之则采用计算迁移策略。

3 原型系统及实验

本文设计了一个原型系统来验证该框架的可行性，系统基于 Android平台开发，移动客户端和云服务器端使用Web服务进行通信。

在该系统中，云环境基于 OpenStack[10]搭建，包括 10个硬件节点，提供计算和存储服务。本系统使用了6个云虚拟机，其中一个为主控节点，其余5个为从处理节点。云虚拟机均配置双核CPU、4GB内存。本框架中所涉及的应用库使用 Jar包进行封装，存储在云中。移动客户端通过Java反射机制调用Jar包中的代码。客户端根据应用ID获取应用的XML描述，根据应用的描述及成本效益模型选择相应的迁移策略。描述应用的XML文件示例如下：

移动设备提交至云中的作业被分发到相应的云节点（云虚拟机），本系统中云节点的性能相同，负载均衡策略采用经典的 Round-robin算法，以轮叫的方式依次请求调度不同的云节点。

本文选用了两个测试案例：逆矩阵求解（计算密集型任务）和图片灰度转换（数据密集型任务）。逆矩阵求解的 Jar包大小为1KB，输入数据和输出数据的大小均为1KB。图片灰度转换程序的Jar包大小为1.9KB，输出数据的大小约为输入数据的 1/3。测试中使用的移动设备型号为Sumsung Galaxy S4 Mini，GeekBench测试得分为1079，云节点的测试得分为4351。逆矩阵求解和图片灰度转换任务的测试结果分别如图 3、图 4所示。

图3 逆矩阵求解的测试结果

图4 图片灰度转换程序测试结果

从图3中可以看出，当矩阵的阶数大于等于5时，任务从移动设备迁移至云中执行。而在图片灰度转换的测试中，尽管远程云节点的处理速度较快，但待处理的图片在网络上传输所占用的时间远大于计算所节省的时间，因此采用代码迁移的策略。

测试结果表明，本文提出的方案针对不同类型的任务，能够自适应的选择代码迁移或数据迁移策略，且本方案带来的开销较少，达到了预期目标。

5 结论及展望

本文在分析现有的移动云计算框架的基础上，提出了一种自适应的移动云计算框架，通过分析计算迁移到云中的成本，选择相应的迁移策略，在成本和效益间实现了有效的权衡。根据该架构，设计了一个简单的原型系统验证其可行性及性能。系统基于SOA技术和Java反射技术实现，具有较好的扩展性和可集成性。实验结果表明，框架具有较好的自适应性。

本文仅考虑了执行时间一项成本，未来可将移动设备的内存消耗、电能、资费等纳入到成本分析模型中，设计节能型、节约时间型、节约空间型、节约费用型等不同的迁移策略。此外，需要在框架中加入安全和隐私控制模块，如使用非对称加密的方式保护用户数据不被泄露。

[1] Satyanarayanan M. Mobile computing: the next decade[J]. ACM SIGMOBILE Mobile Computing and Communications Review, 2011, 15(2): 2-10.

[2] Fernando N, Loke S W, Rahayu W. Mobile cloud computing: A survey[J]. Future Generation Computer Systems, 2013, 29(1): 84-106.

[3] Simoens P, De Turck F, Dhoedt B, et al. Remote display solutions for mobile cloud computing[J]. IEEE Internet Computing, 2009, 13(5): 46-53.

[4] Lu Y, Li S, Shen H. Virtualized Screen: A Third Element for Cloud—Mobile Convergence[J].MultiMedia, IEEE, 2011, 18(2): 4-11.

[5] Miluzzo E, Cáceres R, Chen Y F. Vision:mClouds-computing on clouds of mobile devices[C].Proceedings of the third ACM workshop on Mobile cloud computing and services. ACM, 2012: 9-14.

[6] Marinelli E E. Hyrax: cloud computing on mobile devices using MapReduce[R]. CARNEGIE-MELLON UNIV PITTSBURGH PA SCHOOL OF COMPUTER SCIENCE, 2009.

[7] Huerta-Canepa G, Lee D. A virtual cloud computing provider for mobile devices[C]. Proceedings of the 1st ACM Workshop on Mobile Cloud Computing &Services: Social Networks and Beyond. ACM, 2010: 6.

[8] Chun B G, Ihm S, Maniatis P, et al. Clonecloud: elastic execution between mobile device and cloud[C].Proceedings of the sixth conference on Computer systems. ACM, 2011: 301-314.

[9] Kristensen M D. Scavenger: Transparent development of efficient cyber foraging applications[C]. Pervasive Computing and Communications (PerCom), 2010 IEEE International Conference on. IEEE, 2010: 217-226.

[10] Schroeder D K. Mac and PC Performance Analysis[D].Big Bend Community College, Washington, 2008.

[11] Pepple K. Deploying OpenStack[M]. O'Reilly Media,Inc., 2011.

[12] Sharifi M, Kafaie S, Kashefi O. A survey and taxonomy of cyber foraging of mobile devices[J].Communications Surveys & Tutorials, IEEE, 2012,14(4): 1232-1243.