Multi Offloading：支持多种资源借调的安卓应用平台*

张晨曦，武翔宇，许 畅+

1.南京大学 计算机软件新技术国家重点实验室，南京 210023

2.南京大学 计算机科学与技术系，南京 210023

3.微软（中国）有限公司苏州分公司，江苏 苏州 215000

1 引言

信息时代，移动应用的数量呈现爆发式的增长。截止到2017年5月，在Google Play上发布的Android应用数量已经从2012年的60万增长到现在的280万（https://www.statista.com/statistics/266210/numberof-available-applications-in-the-google-play-store）。同时，市场上智能手机的种类和品牌也越来越多，智能手机换代越来越频繁，智能手机的性能和质量也良莠不齐，这就带来了如下问题：部分移动应用在开发时没有考虑智能手机本身的性能状况和传感器功能的完整性，其中存在大量的复杂计算，很多智能手机可能无法高效处理这些计算任务，使得应用运行效率低下，手机运行速度缓慢，严重的可能会威胁电池寿命。

本文设想了下面两个场景。

场景1某用户正在用智能手机玩一款手机游戏，这个游戏中包含了人工智能（artificial intelligence，AI）相关的计算，AI计算任务往往需要很多的计算资源和很强的计算能力，而智能手机可能无法提供充足的计算资源进行运算，导致游戏运行缓慢，影响体验。这是由于计算任务的复杂导致的问题。

场景2移动应用开发过程中，开发人员往往希望用不同配置和型号的移动设备对应用进行测试，一个有效的方法就是使用模拟器对不同的设备进行模拟，然而当应用涉及传感器数据的使用时，由于模拟器难以搭载传感器的功能，这样的测试往往无法实现。这是由于智能手机传感器功能缺失导致的问题。

为了解决场景1所示的问题，有一种比较成熟的方法是将移动应用内复杂的计算任务卸载，转移到远程服务器上运行，并将得到的结果返回至原应用。这种方法被称为Computation Offloading，可以理解为计算任务的卸载与转移执行。

这种方法也存在着一些问题，比如使用远程的服务器提供计算资源需要手机与服务器保持稳定的连接状态，这一点在复杂的网络环境中难以做到。

也有研究人员给出不同的解决思路，即将计算任务转移到其他移动设备而不是远程服务器以避免Offloading需求出现在不稳定的网络环境中。

在场景2所示的传感器故障或功能缺失这个问题上，现有的工作多数研究智能手机的遥感或者传感器数据共享，很少有工作直接进行传感器功能的借用。

CoseDroid[1]是一个面向局域网并同时支持移动应用计算任务转移执行和移动设备传感器功能借用的框架，其中传感器功能的借用称为Sensing Offloading。在CoseDroid框架中，移动设备成为计算资源和传感器资源的提供者，同时CoseDroid给出了移动应用的插桩方案，解决了移动设备计算能力不足和传感器功能故障的问题。

CoseDroid虽然是由移动设备提供计算资源和传感器资源，但是设备之间建立连接的过程和资源借用的调控仍然需要一个独立的服务器协调和维护，这使得在不同的局域网中需要维护不同的独立服务器，降低了框架的实用性。

一种直观的想法是，移动设备之间不通过独立的服务器，而是通过互相发现的方式建立连接，并且通过这种方式，移动设备间可以建立起一个互连网络，网络中每一个移动设备都可以作为资源的提供者，也可以作为资源的请求者；这种移动应用计算需求和传感器需求的Offloading表明，应用对于屏幕资源的需求，即触控，亦可以进行转移，从而满足远程触控和多屏幕同时控制等使用需求，本文将这种Offloading称为Touch Offloading。

结合上述思考，本文提出了Multi Offloading，一种支持多种资源借调的安卓应用Offloading平台；Multi Offloading面向局域网中的移动设备，搭载Multi-Offloading平台的移动设备可以自动地发现和连接其他设备，形成一个P2P网络，平台上的移动应用具有“借用”其他设备计算资源、传感器资源以及屏幕资源的能力。同时本文根据Multi Offloading的架构设计重新实现和完善了CoseDroid架构中Computation Offloading和Sensing Offloading的插桩方案并基于程序插桩技术给出了触控转移（Touch Offloading）的实现方法。

在实验部分，本文实现了一个“Android应用Offloading体验平台”以说明Multi Offloading平台设计的可行性，选取了开源五子棋和涂鸦跳跃两个移动应用做插桩并展示Computation、Sensing和Touch Offloading的效果，同时选取了3个棋类游戏展示Computation Offloading对应用运行效率的提升。

综合而言，本文有如下两个创新点：

（1）Multi Offloading是一个P2P平台，搭载平台的每个移动设备都可以借出自己的计算、传感器、屏幕资源或者借用其他设备的资源。

（2）进一步拓展了Offloading的概念，将移动设备屏幕作为一种资源，提出屏幕资源的Offloading，即Touch Offloading，并结合已有的Computation Offloading和Sensing Offloading技术，给出了一个支持多种资源借调的安卓应用Offloading平台的设计方案。

本文的组织结构如下：第2章详细说明Multi-Offloading架构设计和平台中设备互连的实现方法；第3章介绍对CoseDroid架构Computation Offloading、Sensing Offloading技术的重新实现与完善，并提出Touch Offloading技术的实现方法；第4章介绍针对Multi Offloading设计实现的一个示例，并选取应用展示Offloading技术的实现效果；第5章介绍本文的相关工作；第6章总结全文并对未来研究方向进行展望。

2 Multi Offloading平台设计

Multi Offloading是一个面向局域网的Android应用Offloading平台。现有工作多数使用一个特定的服务器作为计算资源的提供方，这种方法存在一些问题，归纳如下：

问题1服务器往往与移动设备处于不同的系统环境中，这会导致一些在Android环境中可以被运行的代码被转移到服务器环境中无法运行。

问题2在局域网环境中，特定的服务器需要有固定的IP地址和配置。当局域网环境变化时（比如迁移到另一个局域网），之前网络中的服务器配置可能难以适配到现在的局域网，使得设备需要和服务器重新连接，服务器也需要重新配置。

问题3移动设备的Offloading需求常常会发生变化，比如对于不同的移动应用，可能有不同的计算任务，需要不同的代码片段来执行，预先在服务器中准备好这些代码是极其困难的。

CoseDroid框架解决了问题1和问题3，对于问题2，由于CoseDroid使用了一个独立的名服务器（Name Server）以建立和维护设备之间的连接，当局域网本身发生变化时，需要重新维护和配置名服务器，为框架的实用性带来了问题。

基于对上述问题的思考，本文将Multi Offloading设计为一个以设备发现为连接主导的Offloading平台。在这个平台上，每一个移动设备既可以成为建立互连网络的发起者，也可以成为建立互连网络的响应者。

图1展示了Multi Offloading架构。下面将详细描述Multi Offloading的架构设计和平台上各个设备之间建立连接的过程。

Fig.1 Architecture of Multi Offloading图1 Multi Offloading架构

2.1 Multi Offloading平台架构

Multi Offloading平台由四部分构成：客户端部分（Client Part）、服务器部分（Server Part）、插桩后的移动应用（InstrumentedApp）和连接器（Connector）。

搭载Multi Offloading平台的移动设备通过连接器互相发现并建立TCP连接，形成一个P2P网络。而Multi Offloading内部采用客户端/服务器（Client-Server）架构，客户端部分承载了显示图形界面、开启应用等功能，服务器部分负责处理客户端的请求，并反馈给客户端和需要Offloading的移动应用。

在平台内部，客户端部分、服务器部分、移动应用之间通过广播（Broadcast）互相传递请求和响应；在互连的移动设备之间，客户端部分、服务器部分通过TCP连接发送请求和响应。这样每台移动设备都可以提供资源或请求资源。

这种架构设计解决了之前归纳的3个问题。

对于问题1，在本文的架构中，每个移动设备都可以作为服务器提供资源，设备之间系统环境基本相同，因此不会出现由于系统环境原因导致代码片段无法执行的情况。

对于问题2，移动设备以互相发现的方式建立连接，这就是说移动设备之间可以随时连接、随时断开，这非常符合移动设备网络环境易变动的特点，而且每台移动设备都可以作为服务器，服务器环境不需要静态配置。

对于问题3，本文和CoseDroid一样给平台客户端部分增加了文件发送的功能，请求计算资源的设备会提前准备好需要执行的代码片段，然后在请求服务时发送给服务设备，然后由服务设备动态加载执行该代码片段。

对这3个问题的解决说明本文设计的Multi-Offloading平台可以很好地处理设备互连和计算任务转移的相关问题。下面将说明Multi Offloading如何让设备之间互相发现和连接。

2.2 设备发现与设备互连

局域网中搭载Multi Offloading平台的移动设备之间的发现和互连是由连接器完成的，如图2所示，连接器由四部分组成：搜索管理器（Search Manager）、设备搜索器（Searcher）、连接建立器（Connect Creator）和搜索响应器（Responser）。

Fig.2 Connector components图2 连接器组成

如图2所示，这四部分赋予了移动设备两个可选角色，一个是作为主机的搜索者，另一个是等待主机搜索的响应者，图3和图4完整地展示了设备之间建立连接的流程。

为了实现局域网中设备之间的互相发现，连接器的实现使用了UDP广播的方法。由于UDP本身是不可靠的连接协议，连接器在每次使用UDP广播进行通讯的时候都模拟了类似于TCP连接的“3次握手”协议。图3、图4所示的连接流程可以分为3个阶段，其中前两个阶段都会经历“3次握手”协议。

Fig.3 Device finding图3 设备发现

Fig.4 Device connection and device interconnection图4 设备连接与设备互连

阶段1（设备发现）当一个设备选择作为主机进行搜索时，搜索管理器会通知设备搜索器进行搜索，即向局域网内发出UDP广播，这个广播附带自身编号和搜索器预先设定的广播类型（例如类型“搜索广播”）；此时，选择作为响应者的设备会开启搜索响应器，搜索响应器接收到主机发出的UDP广播并对广播内容进行校验，这是“第一次握手”。

响应设备校验成功后，搜索响应器会发出一个带有校验信息的UDP广播，主机在接收到这个广播后会再次进行校验，这就是“第二次握手”。

主机的设备搜索器校验成功后，会再次发出广播，并通知搜索管理器发现了想要连接的设备，并且获得该设备的IP地址等信息，使得搜索管理器开始第二阶段的连接部分，这是“第三次握手”。

阶段2（设备连接）在确认可以连接的移动设备的IP地址后，主机的搜索管理器会通知连接建立器进行第二轮的UDP广播。此时连接建立器会发出一个携带信息的UDP广播，信息内容即为响应者的IP地址。响应者在接到UDP广播后，会首先校验广播中要连接的IP地址是否为自身的IP地址，如果不是，就忽略广播报文；如果是，就发送回复的UDP报文，完成“第一次握手”。

主机接到回复广播后，校验其IP地址，完成“第二次握手”，随后发送回复广播，广播报文中会携带即将打开的新端口的端口号，并打开新的套接字（Socket）端口，等待响应者连接。

响应者接到回复的UDP广播，进行校验，完成“第三次握手”；获得主机的IP地址和开放端口号，进而与主机建立TCP连接。由于TCP连接本身是可靠连接，因此不需要进行额外校验。这样，通过前两个阶段，主机就可以发现响应主机搜索的设备并建立起稳定连接。

阶段2描述的是两个设备之间的连接过程，第三阶段会建立多设备之间的连接网络。

阶段3（设备互连）主机在与响应设备建立连接后，会将与主机相连的所有设备的IP信息通过TCP连接发送给响应设备；同时主机会将响应设备的IP信息发送给每个与之相连的移动设备，让每个设备都打开新的Socket端口，等待响应设备进行连接。

响应设备接到主机发来的网络中所有设备的IP信息后，会逐一连接每个设备，与每个设备都建立TCP连接。这样就在原来的互连网络中新增了一台移动设备，同时在此互连过程中，响应者也会获得一个唯一标号或标识来确定其在网络中的身份。

注意到，在响应者与其他设备建立连接后，它们在网络中的地位都是一样的，主机和响应者只是不同设备在建立连接时所采用的不同角色，避免了连接网络中单点失效的问题。

在这3个阶段中，两次模拟“3次握手”协议，避免了使用UDP广播可能带来的网络不可靠问题。

3 Offloading技术实现

移动应用一般不具有Offloading自身计算任务和传感器需求的能力，对移动应用进行插桩，使其具备这样的能力，并配合平台中的其他组件一起满足自身Offloading的需求。

插桩（Instrumentation）是分析和处理程序的常用技术，程序员通常可以在程序内部插入一些自己的代码，这些代码可以提供程序运行时的信息，比如程序运行时的堆栈信息、代码覆盖率信息等。同样编程人员也可以对移动应用进行插桩，在应用中插入某些代码，实现特定的程序行为和程序逻辑。

图5展示了一般应用的插桩流程。

Fig.5 Application instrumentation process图5 应用插桩流程

本文针对字节码插桩使用的工具是Soot（http://sable.github.io/soot）。Soot是一个程序分析框架，它一开始是用来对Java程序做静态分析从而进行代码优化，现在也可以用来进行移动应用代码的插桩。Soot可以接收应用的源代码，也可以接收应用的字节码，但是由于很多真实应用没有开源，源码不便获取，因此编程人员在插桩时一般使用的是Soot对字节码的处理能力。

Soot会把Java字节码或者是apk文件转换成一种三地址中间代码，称为Jimple代码；同时Soot也封装了一些使用Java代码编写Jimple代码的接口，从而可以通过编写Jimple代码修改程序行为逻辑，屏蔽了直接对字节码插桩的复杂性。

本文设计实现的Computation Offloading、Sensing Offloading和Touch Offloading技术就是基于应用插桩完成的。

3.1 Computation Offloading技术实现

Computation Offloading技术希望可以将应用中部分涉及复杂计算的任务动态转移到高性能设备上执行，然后返回结果，使应用能够高效地运行。

这里本文结合Multi Offloading架构对CoseDroid的插桩思想进行了重新实现。

CoseDroid实现Computation Offloading技术的核心思想为：对于可转移的方法，记录其签名、所属类名、参数，序列化调用对象；将对象传输至服务设备通过Java反射机制动态加载字节码片段，执行该方法，并将执行结束后的结果和调用对象一同返回；最后将返回对象的每一个域拷贝给原对象。

基于上述目标，本文设计了如图6所示的插桩流程。

Fig.6 Computation Offloading instrumentation process图6 Computation Offloading插桩流程

并不是所有的方法都是可转移的，可转移的方法要求方法执行前后只对调用对象本身的域（Field）造成影响，不会对系统状态和其他程序状态造成影响。对于类C中的方法m（带有引用对象的参数p）是否可转移，本文结合Multi Offloading架构将其总结为表1所示的4个条件（判定结果为“是”则不满足条件）。

流程中插入了预备字节码检测环节，其意义在于，当计算资源的提供设备没有应该执行的字节码片段时，该环节会提醒Multi Offloading平台及时发送所需字节码片段给计算设备；如果请求设备也没有预备应该执行的字节码片段，该环节则会终止Offloading请求，使该方法本地执行，以免产生传输错误，保证了Computation Offloading请求过程的鲁棒性。

Table 1 Conditions of Offloadable methods表1 方法可转移条件

3.2 Sensing Offloading技术实现

Sensing Offloading技术希望某些因为移动设备传感器故障或者功能缺失而不能运行的应用，可以借用其他设备的传感器功能，通过其他设备的传感器获得数据，以维持应用的正常运行。

为了说明Sensing Offloading的插桩方法，这里简介Android应用是如何使用传感器的。Android应用的开发工具Android SDK实现了一个Android传感器框架（Android sensor framework，ASF，https://developer.android.com/guide/topics/sensors/sensors_overview.html），里面包含着使用设备传感器的接口。

Android应用可以通过ASF提供的getSystem-Service方法获得SensorManager类的实例对象，再通过getDefaultSensor获取希望使用的传感器实例（如重力传感器的编号是TYPE_GRAVITY），在获得传感器实例后，Android应用可以通过registerListener和unregisterListener两种方法注册和注销SensorEvent-Listerner接口实现对传感器数据的获取、精度变化的感知等。

CoseDroid提出通过监控registerListener和unregisterListener两种方法获得Android应用传感器的注册/注销信息，并使用改写的SensorEventListener实例替换原应用注册的传感器事件处理器，从而实现传感器的借用。

本文根据上述思想设计了如图7所示的插桩流程。

Fig.7 Sensing Offloading instrumentation process图7 Sensing Offloading插桩流程

经过这两步的插桩，插桩应用在运行时会注册预先写好的一个传感器数据处理器，而这个处理器会从提供传感器服务的设备上获取数据，然后返回给应用，使得插桩应用检测到运行设备具有了所需传感器的功能。

3.3 Touch Offloading技术实现

移动应用对于屏幕资源的需求也可以像其计算需求和传感器需求一样被转移，即触摸控制（Touch）的转移，意义在于实现远程触控，例如以一台设备作为控制板控制多台设备进行同步演示等。本文把这种Offloading称为Touch Offloading。

对于Touch Offloading技术的实现，本文设计了图8所示的插桩流程。

在移动应用中，onTouch方法是其处理触控指示的方法。插桩工具会定位到这个方法，并将其替换为预先编写好的onTouch方法，同时给应用插入的广播接收器会接收触控设备发出的触控信息，即触屏的具体坐标，从而使用MoveEvent类（Android架构中触摸事件类）触发对Offloading设备的触摸操作，完成触控设备对Offloading设备的远程触控。

Fig.8 Touch Offloading instrumentation process图8 Touch Offloading插桩流程

值得关注的是，本文对移动应用的插桩是一种轻量级的插桩，不会影响在没有Offloading平台下移动应用的运行。

因此，在3种Offloading技术的插桩中本文都加入了关于执行模式的判断，如果应用不是由Multi-Offloading平台打开运行的，那么：

被Offloading的方法不会做任何处理，在原设备上执行；应用原来的传感器事件处理器不会被替换，继续获取本机上的传感器数据；管理触控的onTouch方法不会被修改，依然可以触摸设备屏幕对应用进行控制。

当用户正常打开插桩后的Android应用时，应用会如没有被修改过一般正常运行。

4 实验评估

4.1 实验设计与实现

为了说明Multi Offloading平台设计的可行性，开发了一个“Android应用Offloading体验平台”（简称为Offloading体验平台）。图9展示了Offloading体验平台的主界面，可以看到，主界面除了启动应用、建立连接、打开说明和改变计算任务转移目标外，还可以显示设备是否已经互连形成Offloading网络，如果已互连，那么顶端会显示当前设备的编号。

在Offloading体验平台上，本文选取了两个移动应用来展示Offloading技术的实现效果。

对于Computation Offloading的展示，本文选取开源五子棋游戏作为展示应用。在这个五子棋应用中存在一个基于人工智能算法的方法，这个方法用于计算电脑下一步的最佳落子点，这个方法的执行效率影响着整个应用的运行效果，非常适合展示计算任务的转移执行对程序运行效率的影响。

Fig.9 Home screen of Offloading experience platform图9 Offloading体验平台主界面

对于Sensing Offloading和Touch Offloading的展示，本文选择涂鸦跳跃（doodle jump）作为展示应用。涂鸦跳跃是一款利用加速度传感器控制人物保持跳跃并躲避障碍的游戏，这款游戏只使用了加速度传感器，用来展示传感器资源的借用非常合适，它本身还有比较简洁的操作界面，也适合于展示触控转移。

除了验证Multi Offloading平台设计和Computation、Sensing、Touch Offloading插桩技术的可行性，本文还希望探究Computation Offloading后Android应用的运行效率提高的程度，即应用运行时间的减少程度。

本文在开源五子棋应用之外又挑选了Github上两个棋类游戏GoBang（五子棋）和Othello（黑白棋），通过比较这3个游戏Offloading前后连续10步棋的平均时间，观察应用运行时间是否减少和减少的程度。

结合上述实验目的，本文提出3个研究问题。

问题1将Android应用的复杂计算转移给更高性能的设备执行是否可行，相同步骤内应用运行时间是否明显减少。

问题2本文Sensing Offloading的插桩方法是否可以使Android应用正确接收其他设备的传感器数据进而正常运行。

问题3本文Touch Offloading插桩技术是否能够实现触控转移，即在控制者屏幕上进行点击是否能在显示者屏幕上相同位置产生点击事件（转移触控的设备称为控制者，接受控制的设备称为显示者）。

在展示实验结果之前，先说明本文的实验环境，本文使用两台三星Galaxy S5、1台华为P6、1台华为Mate7在1 167 Mb/s的Wifi局域网下进行实验。

4.2 实验结果

4.2.1 Computation Offloading效果展示

对于问题1，本文选用华为P6和华为Mate7两台设备进行实验，根据配置说明，Mate7性能明显高于P6。图10和图11分别展示了在P6设备上运行开源五子棋在Offloading前后1步棋的所需时间。为了更直观地展示实验效果，在插桩时重复多次运行Offloading的方法，在开源五子棋应用的展示中，Offloading的方法被执行了500次，在后面的实验中也会对其他应用Offloading的方法重复执行合适的倍数。

Fig.10 One step time consumption on P6 before Offloading图10 Offloading前P6运行五子棋的1步耗时

实验中五子棋游戏运行正常，未出现游戏崩溃的情况。

Fig.11 One step time consumption on P6 after Offloading图11 Offloading后P6运行五子棋的1步耗时

为了探究应用运行时间的减少，本文对GoBang和Othello做了类似的插桩，比较Offloading前后连续10步棋的平均时间，得到表2。

Table 2 Time consumption of three chess games before and after Offloading表2 3个棋类游戏Offloading前后耗时比较

从表2可以看出，Computation Offloading对Android应用运行时间的减少具有可观的效果。

4.2.2 Sensing Offloading效果展示

对于问题2，本文使用两台三星设备进行实验，其中提供传感器数据的设备称为控制者，接收传感器数据的设备称为显示者。左右摇晃控制者，显示者中由加速度传感器控制的人物跟随控制者进行基本无延迟的左右跳跃；而左右摇晃显示者未对游戏造成任何影响。

图12展示了控制者（左）向左摇，游戏中人物（右）跟随着向左跳跃的情景。说明文中Sensing Offloading的插桩方法能够使Android应用成功借用其他设备的传感器功能。

4.2.3 Touch Offloading效果展示

Fig.12 Sensing Offloading effect图12 Sensing Offloading效果展示

对于问题3，本文同样使用两个三星设备进行实验。为了能够确认控制者上的点击信息输到了显示者，在插入广播接收器时注册了额外的广播信号，使得显示者在接收到控制者的点击信息时，以点击点为中心绘制圆环。这样既可以看到控制者上的点击是否传递给了显示者，又可以判断显示设备接收到的数据是否正确。

实验时，在控制者的控制板上进行随意点击，同时观察显示者屏幕上的圆环位置，结果圆环中心与显示者屏幕的相对位置，与点击点与触控设备屏幕的相对位置基本一致；在控制板上点击显示者涂鸦跳跃游戏界面上的按钮的相对位置，显示者的游戏界面做出和直接点击按钮一样的跳转。图13展示了点击触控设备控制板后，显示设备在同样的相对位置出现圆环的情景。

Fig.13 Touch Offloading effect图13 Touch Offloading效果展示

这说明本文给出的Touch Offloading插桩方法可以有效实现触控转移。

综合上述3个实验结果，可以得出结论，本文设计的Multi Offloading平台架构具有可行性，本文重新实现并完善的Computation Offloading和Sensing Offloading插桩技术，提出的Touch Offloading插桩技术可以使Android应用具有借用其他设备资源的能力，并且Computation Offloading对Android应用的运行时间有可观的减少。

5 相关工作

本文提出的Multi Offloading是一个同时支持Computation Offloading、Sensing Offloading和 Touch Offloading的Android应用Offloading平台，而对于Offloading技术也已经有许多相关研究。

起初关于Offloading的研究主要针对于个人电脑（personal computer，PC）应用，由于服务器的性能明显优于PC的性能，并且部分PC程序逻辑复杂，计算任务重，因此将PC应用繁杂的计算转移到服务器上运行可以明显提升性能。Javaparty[2]和J-Orchestra[3]关注PC上Java应用的远程执行，使用用户标注和程序分析的方法，基于Java的远程方法调用（remote method invocation，RMI）技术，将需要计算的方法所属对象传输至服务器上执行，但因为Android平台不支持RMI技术，所以这两份工作难以直接移植到Android平台。

也有一些对非Android平台的应用Offloading技术的研究工作。Maui[4]就是面向Windows Phone平台的应用和设备的Offloading工作，工作语言和处理对象是C#语言和.NET程序，其工作核心是远程过程调用（remote procedure call，RPC），在运行时决定哪些方法应该转移执行，然后做程序分割；Maui提供了一个编程环境并允许用户标注哪些方法可以被转移执行，并在运行时判断这种方法是否真的可以Offloading。Wang等人[5]的工作面向支持Java的移动设备，这份工作的重点在于面向对象程序中的程序分割，使用静态分析的方法首先建立一个带权值的对象关系图，然后根据这个对象关系图二次建模将其中的对象划分成本地执行的部分和服务器执行的部分，并对划分成服务器部分的对象进行转移执行。Rim等人[6]的工作同样面向运行JVM的移动设备，通过对Java应用的插桩实现方法的Offloading。

在这些针对非Android平台的工作出现的年代，Android平台还没有成熟。现在流行的移动平台是Android平台和iOS平台，由于iOS系统闭源等特点，iOS应用难以分析和处理；相比之下，Android是一个开源系统，存在许多Android应用的分析工具，比如Soot，因此现在大部分工作都集中在Android平台上，尤其是Android应用的Computation Offloading。

Cuckoo[7]提供了一个Android应用Computation Offloading的编程模型，它要求开发者在这个编程模型下开发应用。在Cuckoo的编程模型中，开发人员需要在本地的“服务（Service）”部分定义需要Offloading的方法接口，这个Service是支持RPC的，同时Cuckoo框架会自动在远程服务器生成本地Service中接口的拷贝；在应用开发时，开发人员在本地Service中实现之前定义的方法接口，覆盖远程Service中的接口；进而在应用运行调用这些方法时，会主动请求服务器执行这些方法，完成计算的Offloading。与Cuckoo相似的工作还有Chen等人[8]，但是它不需要开发者在特定的编程模型下开发，而是处理以特定开发模式开发的Android应用，对于每个用户，Chen等人[8]都在云端服务器上部署一个虚拟移动设备，并将计算任务转移到虚拟设备上运行。上述两份工作对Offloading技术的实现主要依靠Android应用的开发模式，而DPartner[9]是通过字节码重写的方式重构一个Android应用，支持不同粒度的计算转移。

在Computation Offloading研究中，也有工作不是进行方法上的Offloading，而是从应用内部线程、服务器资源、能耗等多方面考察Offloading的可行性。CloneCloud[10]和COMET[11]关注于多线程Android应用中线程的Offloading。它们不是方法驱动的Offloading策略，而是线程驱动的策略；COMET没有对应用字节码进行修改，而是修改Dalvik虚拟机，其所有操作都建立在Java内存模型上，并使用分布式共享内存模型，提高了Offloading效率。COSMOS[12]关注云服务器资源的调度和网络连接情况的权衡，ECOS[13]关注Offloading中的隐私安全问题，而Mukherjee等人[14]则先对应用本身Offloading的能耗进行评估，以应用Offloading后的能耗是否减小为基准判断应用是否值得Offloading。

在Sensing Offloading的研究上，文献[15]可以理解为一种Crowd Sensing，它是让中央节点分发若干传感器相关的任务给不同的移动设备，移动设备可以接受任务并完成，也就实现了传感器的合作。Yang等人[15]的关注点在于设备之间的利益问题，而本文的工作侧重于一对一的传感器服务，重点在于如何使得Android应用获得使用其他设备传感器的能力。Rachuri等人[16]考虑的是社交行为中传感器的Offloading，他们认为一直使用本机的传感器记录人的社交行为有很大的开销，于是他们考虑在环境中部署相应的传感器，进而可以使用这些环境中的传感器替代本机的传感器，达到节省开销的目的。Rachuri等人通过实验归纳出一些适宜在环境中部署的传感器，并根据归纳结果提出了一个Sensing Offloading框架，提供了一种编程模式，用于与社交行为有关的Android应用的开发。与本文工作不同的是，本文通过对Android应用进行轻量级的插桩，就可以使应用具有Offloading传感器需求的能力，但是如果希望得到一个可以和环境传感器交互的Android应用，往往需要开发人员依照Metis框架重新开发，很难通过修改应用得到。

在多种Offloading同时支持的研究问题上，Cose-Droid[1]是一个同时支持Computation和Sensing的Android应用Offloading框架，关注计算任务和传感器Offloading后的能耗降低问题；与本文不同的是，CoseDroid在移动设备建立互连时仍然使用了一个名服务器为媒介，设备之间依靠独立的服务器建立连接，同时本文对CoseDroid的Offloading技术做了拓展，提出了Touch Offloading技术。

6 总结与展望

本文给出了一个Android应用Offloading平台的设计与实现方案，Multi Offloading。Multi Offloading同时支持Android应用进行Computation Offloading、Sensing Offloading和 Touch Offloading，搭载 Multi-Offloading的移动设备可以互相发现并建立连接，形成一个P2P网络。

本文重新实现和完善了已有工作的Computation Offloading和Sensing Offloading插桩技术，并提出Touch Offloading的轻量级程序插桩实现方案；使得插装后的Android应用具有触控转移的能力和借用P2P网络中移动设备计算资源、传感器资源的能力。

本文的工作还有继续完善的空间，触控是Android应用进行响应的最基本的输入。除此以外，有些Android应用还会响应手势、摄像机和指纹等输入，实现指纹输入的Offloading有利于实现远程解锁等功能。未来会逐步实现手势、摄像机、指纹的Offloading，扩展Offloading的概念，实现Android应用控制的转移。