CN104731654B - 一种针对安卓应用的迁移重构及支持系统 - Google Patents

Abstract

本发明公开了一种针对安卓应用的迁移重构及支持系统，所述系统包含应用重构模块和运行时支撑模块。应用重构模块通过程序分析算法，获取可以转移的计算任务和传感器功能，并通过程序插桩算法，在字节码层次改写这个安卓应用，使得这个应用具有计算任务和传感器功能转移的能力，同时用户也可以在插桩时选择自己希望转移的计算任务；运行时支撑模块被部署到移动设备以及服务器上，使得实际运行时通过应用重构模块处理的安卓应用能够真正地进行计算任务和传感器功能的转移。本发明支持大部分安卓固件，学习难度小，部署成本较低，计算任务和传感器功能的转移过程简单，转移过程对用户透明。可以实现一定程度的降低能耗，提高性能，延伸传感能力的效果。

Description

一种针对安卓应用的迁移重构及支持系统

技术领域

本发明公开了一种针对安卓应用的迁移重构及支持系统，涉及软件工程技术领域。

背景技术

安卓系统是一个开放源代码的移动操作系统平台，近年来它占据了移动设备市场的极大份额，应用开发者发布了数量巨大的安卓应用。由于移动设备的运算能力往往弱于个人计算机，因此部分应用受限于设备性能较差，带给用户不好的用户体验。同时，某些安卓应用使用了移动设备上的一些独有资源，例如传感器，以实现特定的功能，但是移动设备往往无法具备所有的传感器，因此使用了某些特定传感器的应用在部分移动设备上就无法正常工作。这两方面问题都对安卓应用的进一步发展产生了负面作用。

目前传统的解决思路大多考虑第一个问题，即实现计算任务的转移。部分思路要求开发者在编写应用的时刻就遵从一定的模式，使得应用本身具有转移计算任务的能力，但是这种做法对于开发者提出了非常高的要求。部分思路实现了特定的安卓固件，在固件层次实现了计算任务的转移，但是它要求用户刷机以及进行一系列配置工作，对用户提出了非常高的要求。也有部分思路提出通过重构安卓应用，以支持计算任务的转移。以上三种思路都假定计算任务从移动设备转移到服务器上。服务器往往是固定在某个位置，那么移动设备远离服务器后，网络通信质量极易受到影响，对计算任务的转移效果带来了极大的挑战。同时，这些传统解决思路大多没有考虑到移动设备上传感器的相关问题，使用了特定传感器的应用无法在某些设备上运行，影响了用户体验，实现传感器功能的转移也就迫在眉睫。

发明内容

本发明所要解决的技术问题是：针对现有技术的缺陷，提供一种针对安卓应用的迁移重构及支持系统，首先分析安卓应用，对于计算任务的转移，它标识出可以被转移的计算任务，并允许用户指定自己希望转移的计算任务；对于传感器功能的转移，它识别出这个安卓应用中使用了传感器的地方，并对之进行修改，使得本设备可以使用别的设备的传感器来为这个应用服务。

本发明为解决上述技术问题采用以下技术方案：

一种针对安卓应用的迁移重构及支持系统，包括应用重构模块和运行时支撑模块，其中，

所述应用重构模块包括程序分析算法模块、程序插桩算法模块和转移引擎；

所述运行时支撑模块包括服务端支撑平台、客户端支撑平台和IP名服务器，分别部署于服务端设备、客户端设备和PC机上，其中，所述服务端支撑平台包括转移服务引擎、类文件接收模块和注册服务模块；所述客户端支撑平台包括转移控制引擎、类文件发送模块和请求服务模块；所述IP名服务器包括注册服务者模块和提供服务者模块；

原始安卓应用程序经过应用重构模块在字节码层次进行代码插桩并结合转移引擎完成重构，运行时支撑模块将重构后的安卓应用程序中的计算任务和传感器功能在移动设备之间实现转移。

作为本发明的进一步优选方案，在所述程序分析算法模块和程序插桩算法模块中，

程序分析算法模块对于原始安卓应用程序中的计算任务和传感器功能进行分析，判断并决定是否将计算任务和传感器功能转移至其他的移动设备进行处理；

程序插桩算法模块利用程序分析算法的结果进行插桩，对于计算任务，获取所有将要转移的计算任务方法，对所述计算任务方法进行改写，由服务端设备辅助执行所述方法；

对于传感器功能，在所有传感器注册和注销的地方插桩，由用户在使用本地移动设备传感器或使用其他移动设备传感器之间进行选择切换。

作为本发明的进一步优选方案，所述客户端设备上的客户端支撑平台为重构后的安卓应用服务寻找转移服务的提供者，所述服务端设备上的服务端支撑平台提供转移服务，所述PC机上的IP名服务器负责维护服务者列表，并在被询问时刻将服务者列表返回给客户端支撑平台。

作为本发明的进一步优选方案，所述程序分析算法模块搭建在Java/Android程序分析以及变换框架Soot上，利用中间表示语言Jimple实现静态分析。

作为本发明的进一步优选方案，所述转移引擎与服务端设备上的服务端支撑平台通信，交换服务内容，转移引擎将服务端支撑平台提供的服务进一步转交给原始安卓应用，实现计算任务和传感器功能的转移。

作为本发明的进一步优选方案，所述转移引擎对于计算任务采取的方法是：将某个类的对象以及方法签名、方法参数序列化后打包，转交给服务端支撑平台，服务端支撑平台通过Java反射API动态加载类并执行方法，返回结果以及新的对象；

所述转移引擎对于传感器功能采取的方法是：通知服务端支撑平台注册或注销相应的传感器，同时接收服务端支撑平台发送的传感数据。

本发明还提供了一种基于所述针对安卓应用的迁移重构及支持系统的实现方法，所述方法具体步骤包括：

步骤一、服务端设备通过服务端支撑平台向IP名服务器注册；

步骤二、当一个重构后的安卓应用需要获得转移服务时，首先调用自身的转移引擎，转移引擎通知客户端支撑平台，由客户端支撑平台向IP名服务器请求服务者列表，IP名服务器返回当前愿意提供服务的服务端设备的IP地址至客户端设备，由用户从愿意提供服务的设备中选择一个设备；

步骤三、服务端设备同意客户端设备的连接请求后，两者建立连接，进而判断是进行计算任务转移还是传感器功能转移：

301、计算任务转移则将通过客户端支撑平台将类文件发送至服务端支撑平台；

302、传感器功能转移则将当前本地注册的传感器全部通知服务端设备远程注册，本地注销上述传感器，实现传感器的无缝切换，其中，一个传感器仅在本地或远程的一处注册。

本发明采用以上技术方案与现有技术相比，具有以下技术效果：本发明能自动地对一个安卓应用进行分析并重构，允许用户的干预，使得重构后的应用可以在运行时支撑模块的协助下，将自身的计算任务转移到别的设备，将自身的传感数据收集过程转移到别的设备，在上述的转移对用户透明的情况下，降低自身的能耗，在一定条件下提高安卓应用的性能，让用户感觉在使用别的设备的传感器，即实现传感器的“借用”，延伸了设备的能力。

附图说明

图1为本发明实施例提供的安卓应用的计算任务和传感器功能转移的迁移重构及支持的系统的结构图。

图2为本发明实施例提供的程序分析算法模块的流程图。

图3为本发明实施例提供的程序插桩算法模块的流程图。

图4为本发明实施例提供的运行时计算任务和传感器功能转移的实际运行流程图。

具体实施方式

下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

下面结合附图对本发明的技术方案做进一步的详细说明：

本发明将一个安卓应用进行代码插桩，生成一个新的支持计算任务和传感器功能转移的安卓应用，而不改变原始应用的功能。同时，这种技术包含一套运行时支撑模块，被部署在移动设备上，支持重构后的安卓应用，提供在移动设备之间计算任务和传感器功能转移的功能。本技术对于安卓应用的重构是轻量级的，对于计算任务和传感器功能的转移是用户无感知的，使用方式易学。

如图1所示，本发明提供一种针对安卓应用的迁移重构及支持系统，由一套应用重构模块和一套运行时支撑模块构成。对于一个原始应用，首先让它通过应用重构模块的处理。这里又分为程序分析算法模块和程序插桩算法模块。程序分析算法模块会在Soot这个Java/Android程序分析以及变换框架的基础上，对这个原始安卓应用进行分析，获取它是否与传感器相关，是否有部分计算任务可以转移。分析完毕后，即进入程序插桩算法模块，利用之前的分析结果，在这个安卓应用的特定位置进行代码插桩，同时把预先编写好的转移引擎插桩进去，使得原始的安卓应用的插桩结果和转移引擎合起来成为重构后的安卓应用。

运行时支撑模块由服务端支撑平台、客户端支撑平台和IP名服务器组成。三者被部署在不同的地方。服务端支撑平台被部署在愿意接收转移任务的移动设备上，主要是为别的设备提供服务。客户端支撑平台被部署在想使用转移服务的移动设备上，重构后的安卓应用可以与它交互，促成与服务端支撑平台的联系。IP名服务器被部署在一个装有JVM的PC上，它主要负责维护当前的服务者列表。因此，愿意提供服务的设备必须通过服务端支撑平台向IP名服务器注册，这样当客户端设备想要使用服务时，也通过客户端支撑平台向IP名服务器发出请求，获取当前在线的服务者列表，然后客户端用户可以选择一个提供者，接下来客户端设备和服务端设备就可以建立点对点的连接，不再需要IP名服务器的干预。

对于转移计算任务，因为是服务端设备为客户端设备执行特定的方法，因此服务端设备必须具有必要的类文件，因此客户端支撑平台配有一个类文件发送模块，而服务端支撑平台配有类文件接收模块。

服务端设备通过转移服务引擎，把相关数据发送给客户端重构后安卓应用的转移引擎，转移引擎进一步把数据发给原始的安卓应用的少许修改版本，也就是提供了服务。而客户端支撑平台需要控制转移状态，例如是否开启转移等，这需要通过转移控制引擎，它同样是与重构后安卓应用的转移引擎交互完成。

图2描述了程序分析算法模块的工作流程。对于一个原始安卓应用，根据目的是计算任务转移还是传感器功能转移进行不同的处理。对于传感器功能转移，逐个检查所有类中的所有方法，监测这个安卓应用中是否使用了传感器，如果没有使用传感器，也就谈不上传感器功能转移了。否则只要看到使用了传感器，那么本发明系统就能够支持传感器功能的转移。

对于计算任务的转移，首先展开这个安卓应用的所有类，分析这些类以及类中的方法是否与设备相关，与设备相关是指它直接表示硬件，或者表示安卓系统的特性。如果某个类是设备相关的，那么这个类以及类下的所有方法都不可转移。如果某个类本身设备无关，但是其中某些方法是设备相关的，那么设备相关的方法不可转移，但是其它的方法有机会转移。对于所有设备无关的方法，展开它们的方法体，进行Field(域)分析和Parameter(参数)分析。需要得出的是这个方法是否在执行过程中改变了field或者parameter。这部分的分析是由本发明实现的一套静态分析方法完成的。分析完毕后，分析结果中会汇报每个设备无关的方法，它是否改变了field或parameter。然后，用户可以参与进来，选择哪些方法进行转移。一个方法如果既没有修改field也没有修改parameter，那么它可以安全地转移。即使它做出了修改，只要修改不会影响到外部变量，仍然可以转移，其中后者就是用户可以参与的部分。

图3描述了程序插桩算法模块的工作流程。它建立在之前的程序分析算法完成的基础上。如果它没有通过程序分析算法，或者分析结果通知无法进行后续任务（例如某安卓应用试图进行传感器功能转移，但是这个安卓应用根本没有使用传感器），那么直接结束，否则进行下面的插桩步骤。

对于传感器功能的转移，首先插桩入传感器功能的转移引擎，它的独特性在于可以通知服务端设备注册/注销某些传感器，从服务端设备收取传感器数据，并交给特定的处理者处理。它维护了所有当前安卓应用中已注册的传感器、这些传感器生成的传感数据的处理者以及这些传感器是本地收集数据还是远程收集数据。接着，在原始安卓应用的传感器注册/注销部分插桩，一方面更新上面提到的需要维护的数据，另一方面如果开启了转移，则调用转移引擎通知远程服务器来注册。

对于计算任务的转移，首先插桩入计算任务的转移引擎，它的独特性在于可以首先通知客户端支撑平台发送本应用转移所需要用到的类文件，可以把一个类的对象序列化，把欲转移的方法的参数序列化，然后与方法签名打包后发送给服务端支撑平台，服务端支撑平台利用Java反射API加载特定的类，在客户端发过来的对象上执行要求的方法，完毕后把方法结果以及方法执行后的对象发送回转移引擎。接着，在原始安卓应用的将要转移的方法内部的开头进行插桩，主要是为转移引擎提供这些需要的信息，同时当服务端设备执行完毕后，对象可能发生改变，因此必须从转移引擎获取结果以及新的对象，然后插桩Field的更新操作，接着返回结果即可。

插桩完毕后，应用的签名会发生变化，因此需要重新打包。同时，需要提取出那些可能被转移的类，部署在客户端设备上，当计算任务转移时首先把这些类发送给服务端设备。

图4描述了本发明系统的实例运行流程图。首先，服务端设备通过自身的支撑平台向IP名服务器注册，这是转移的基础。接着，一个重构后的安卓应用可能想要获得转移服务，它首先调用自身的转移引擎，转移引擎通知客户端支撑平台。客户端支撑平台知道后，就向IP名服务器请求服务者列表，于是IP名服务器就把当前愿意提供服务的设备的IP地址告诉客户端设备，用户可以选择一个设备。

服务端设备同意客户端设备的连接请求后，两者就建立了连接。接着判断是进行计算任务转移还是传感器功能转移，如果是计算任务转移则必须先通过客户端支撑平台把必要的类文件发送给服务端支撑平台，否则后续的加载类、执行方法都会失败。如果是传感器功能转移则必须先把当前本地注册的传感器全部通知服务端设备远程注册，本地注销这些传感器，以此实现传感器的无缝切换，并保证一个传感器仅在本地或远程的最多一处注册。然后，就可以进行正常的工作，主要依靠重构后安卓应用的转移引擎与服务端支撑平台的转移服务引擎直接交互，而重构后安卓应用的转移引擎直接把服务内容提供给原始安卓应用的少许修改版本。

当用户不再希望进行转移时，转移引擎通知服务端支撑平台不再工作，同时如果是传感器功能转移，那么必须把远程注册的传感器重新在本地注册，并且远程无需再注册这些传感器。然后，安卓应用可以切换回本地执行，但是必要的信息仍然要维护，从而为后续可能的转移提供服务。

上面结合附图对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式，在本领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下做出各种变化。以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容做出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质，在本发明的精神和原则之内，对以上实施例所作的任何简单的修改、等同替换与改进等，均仍属于本发明技术方案的保护范围之内。

Claims (6)

1.一种针对安卓应用的迁移重构及支持系统，其特征在于：包括应用重构模块和运行时支撑模块，其中，

所述应用重构模块包括程序分析算法模块、程序插桩算法模块和转移引擎；

所述运行时支撑模块包括服务端支撑平台、客户端支撑平台和IP名服务器，分别部署于服务端设备、客户端设备和PC机上，其中，所述服务端支撑平台包括转移服务引擎、类文件接收模块和注册服务模块；所述客户端支撑平台包括转移控制引擎、类文件发送模块和请求服务模块；所述IP名服务器包括注册服务者模块和提供服务者模块；

原始安卓应用程序经过应用重构模块在字节码层次进行代码插桩并结合转移引擎完成重构，运行时支撑模块将重构后的安卓应用程序中的计算任务和传感器功能在移动设备之间实现转移；

在所述程序分析算法模块和程序插桩算法模块中，

程序分析算法模块对于原始安卓应用程序中的计算任务和传感器功能进行分析，判断并决定是否将计算任务和传感器功能转移至其他的移动设备进行处理；

程序插桩算法模块利用程序分析算法的结果进行插桩，对于计算任务，获取所有将要转移的计算任务方法，对所述计算任务方法进行改写，由服务端设备辅助执行所述方法；

对于传感器功能，在所有传感器注册和注销的地方插桩，由用户在使用本地移动设备传感器或使用其他移动设备传感器之间进行选择切换。

2.如权利要求1所述的一种针对安卓应用的迁移重构及支持系统，其特征在于：所述客户端设备上的客户端支撑平台为重构后的安卓应用服务寻找转移服务的提供者，所述服务端设备上的服务端支撑平台提供转移服务，所述PC机上的IP名服务器负责维护服务者列表，并在被询问时刻将服务者列表返回给客户端支撑平台。

3.如权利要求2所述的一种针对安卓应用的迁移重构及支持系统，其特征在于：所述程序分析算法模块搭建在Java或Android程序分析以及变换框架Soot上，利用中间表示语言Jimple实现静态分析。

4.如权利要求2所述的一种针对安卓应用的迁移重构及支持系统，其特征在于：所述转移引擎与服务端设备上的服务端支撑平台通信，交换服务内容，转移引擎将服务端支撑平台提供的服务进一步转交给原始安卓应用，实现计算任务和传感器功能的转移。

5.如权利要求4所述的一种针对安卓应用的迁移重构及支持系统，其特征在于：所述转移引擎对于计算任务采取的方法是：将某个类的对象以及方法签名、方法参数序列化后打包，转交给服务端支撑平台，服务端支撑平台通过Java反射API动态加载类并执行方法，返回结果以及新的对象；

所述转移引擎对于传感器功能采取的方法是：通知服务端支撑平台注册或注销相应的传感器，同时接收服务端支撑平台发送的传感数据。

6.一种基于针对安卓应用的迁移重构及支持系统的实现方法，其特征在于，所述方法具体步骤包括：

步骤一、服务端设备通过服务端支撑平台向IP名服务器注册；

步骤二、当一个重构后的安卓应用需要获得转移服务时，首先调用自身的转移引擎，转移引擎通知客户端支撑平台，由客户端支撑平台向IP名服务器请求服务者列表，IP名服务器返回当前愿意提供服务的服务端设备的IP地址至客户端设备，由用户从愿意提供服务的设备中选择一个设备；

步骤三、服务端设备同意客户端设备的连接请求后，两者建立连接，进而判断是进行计算任务转移还是传感器功能转移：

301、计算任务转移则将通过客户端支撑平台将类文件发送至服务端支撑平台；

302、传感器功能转移则将当前本地注册的传感器全部通知服务端设备远程注册，本地注销上述传感器，实现传感器的无缝切换，其中，一个传感器仅在本地或远程的一处注册。