本发明涉及移动计算及Android应用开发技术领域，特别是涉及一种基于客户端微服务的APP自动协同方法。
背景技术：
用户通过APP可以随时随地访问远程云服务，移动服务生态系统在人们的日常生活中发挥着越来越重要的作用。起初，APP开发商都专注于实现特定功能，出现了大量单一服务的APP并呈现明显的功能“碎片化”特征。随着用户需求更加复杂多样化，单一APP无法满足用户需求，APP开发商逐渐将多个服务集成到他们的APP中。微服务是一种软件架构模式，可以将应用拆解为多个微服务，实现微服务间的彼此独立。现在许多移动端应用采用该架构模式。然而，微服务间无法交互，用户需要在不同的微服务间切换并重复输入服务参数。因此，提供一种基于客户端微服务的APP自动协同方法，以简化用户操作，减少流量消耗，提升用户体验。
在解决移动终端的APP协同问题方面，已有许多相关成果。使用IFTTT时，用户需要创建所需的流程，包括触发器频道和动作频道，若触发器频道满足触发条件，则自动执行动作频道的动作(Macuser,2013,4(9):4-9.)。MashDroid由一个动态APP组合模型和一个数据驱动的APP推荐机制组成，对APP和APP描述进行抽象，使用语义分析、过滤和排序算法发现最有可能使用的APP(IEEE International Conference on Web Services,2015:725-730.)。虽然IFTTT支持许多APP，但需要服务提供方开放接口合作授权，且仅支持两个APP间的协同，用户只能在有限的条件下实现连锁反应；MashDroid基于豌豆荚的应用内搜索技术，即对APP也有准入门槛。
随着用户需求的复杂多样化，用户往往安装了多个APP在自己的移动设备上，当需要完成某个任务时，往往花费较多时间和网络流量在选择合适的APP以及通过多次点击操作进入所需服务上，同时由于不同服务不交互导致用户需要手动进行大量操作。而目前已存在的技术方案不支持多于两个的APP协同，并且使用已有方法实现协同需要很大的努力。因此需要对现有的APP协同方法进行改进，以减轻用户负担，减少网络流量的消耗，方便用户选择合适的服务，改善用户体验。
技术实现要素：
为克服现有技术的不足，针对用户在使用集成有多个微服务的APP时操作过程繁琐这一问题，本发明提供了一种基于客户端微服务的APP自动协同方法，通过对APP客户端根据服务粒度进行拆解，并封装为客户端微服务，用户只需简单的点击选择即可定制微服务流，实现APP中特定微服务自动启动及服务参数自动注入，即通过微服务方式的APP自动协同满足用户日趋复杂的需求。
本发明的目的是通过以下技术方案实现的。
本发明的基于客户端微服务的APP自动协同方法，包括以下步骤：
步骤一，微服务抽象
(1)APP客户端根据服务粒度拆解为一定数量的微服务：Android APP客户端的每个UI对应一个Activity组件，提取同时具有enabled和exported属性的Activity，使用自动化测试工具Monkey，通过定义点击事件对初步提取出的Activity进行测试，挑选微服务的首个UI，得到微服务的静态任务，作为入口点类entry_cls；根据服务粒度，对成功启动的Activity进行分析筛选，确定微服务集合；
(2)微服务映射为规范化接口：使用Dump View Hierarchy for UI automator工具，对微服务的入口点类entry_cls进行分析，获取item的语义、语法格式及控件信息；借助静态分析工具FlowDroid，将其source和sink设置为与APP存储有关的API，获取item对应控件的动作action的存储信息；将抽象的微服务信息封装为JSON对象部署到服务端，以RESTful API的形式对外提供规范化接口；
步骤二，微服务流定制支持
根据步骤一所抽象的APP的微服务集合，与用户设备中的APP取交集，即获取用户设备所支持的APP微服务列表，用户按照个人需求从微服务列表中选取部分微服务，定制成微服务流；
步骤三，微服务参数获取
利用监控器持续监听用户设备产生的事件，并对感兴趣的事件进行处理，包括微服务流何时触发、微服务流当前执行情况及协同过程中重复利用的服务参数；通过调用服务端公开的规范化接口，即获取每个微服务的抽象信息；此处，利用微服务切换说明协同方法，用<MS1,MS2,data>进行表示，即微服务MS1和MS2间通过data交互；
根据抽象信息中item的action描述，生成实际可执行代码，包括借助辅助服务、adb(Android Debug Bridge)命令对存储及节点进行操作，抓取微服务的各个item对应的参数实例，作为微服务切换的data交由数据中转站处理；数据中转站根据构建的语义关系库对微服务切换中的两个微服务的各个item的语义进行匹配，再按照统一的语法格式暂存；
步骤四，微服务自动启动及参数注入
在每个微服务执行结束时，判断是否还有下一个微服务要执行，若判断为微服务流未结束，则获取服务端所封装的微服务中的entry_cls信息作为入口点类加载微服务启动；使用Intent和ClassLoader机制将入口点类调起，即运行APP内部的微服务；同时数据中转站根据微服务切换的MS2中各个item的语法格式处理data为所需的服务参数实例，发送给执行器；执行器根据MS2的入口点类，将其加载到用户设备的前台；执行器根据MS2中各个item的action的不同，采用不同的方式对所有item进行注入操作。
步骤一(2)中对于部分item，利用静态分析工具FlowDroid无法找到它的存储，使用Android提供的辅助服务及adb命令，找到item对应的辅助服务节点，结合“Input”命令对item对应的控件进行操作，作为item的action信息。
与现有技术相比，本发明根据用户日趋复杂的多样化需求，提出了一种基于客户端微服务的APP自动协同方法，通过分析APP内部的微服务，将其抽象并封装为规范化接口，以便实现微服务自动启动及参数获取和注入，简化了用户的繁琐操作。预期的有益效果包括：
(1)用户可以直接在使用前通过简单的点击选择操作定制微服务流，即可在执行过程中直接跳转到APP的某一所需微服务中，改变了以前手动多次点击才能进入各个微服务的操作，这也在一定程度上减少了网络流量的消耗。
(2)本发明的自动协同合理使用了服务参数间的相关关系，通过语义匹配对参数进行重用，打破了APP间及微服务间的交互障碍，减少了用户的记忆负担，同时也减少了用户输入参数的操作。
(3)不同于其他移动端服务组合方法，本发明不需要对APP做任何修改，降低了第三方APP的接入门槛
附图说明
图1为APP拆解为微服务的示意图；
图2为具有规范化接口的微服务示例图；
图3为微服务流定制页面示意图；
图4为APP对应的微服务列表示意图；
图5为参数注入实现图；
图6为细粒度APP自动协同方法概述图；
图7为基于微服务的APP自动协同实验效果图。
具体实施方式
下面结合附图对本发明作进一步的描述。
本发明的基于客户端微服务的APP自动协同方法，具体涉及APP客户端拆解为细粒度APP并按照用户定制流程自动协同。将APP根据服务粒度拆解为客户端微服务，在用户已定制微服务流的基础上，利用语义匹配对服务参数进行重用，自动启动APP的某一微服务并注入所需服务参数。该方法包括以下步骤：
第一步：微服务抽象
集成多个服务的APP，现大多采用微服务架构模式开发。针对用户的细粒度需求，即只需要其中部分微服务，本发明从逆向角度分析微服务架构的APP，根据服务粒度将APP客户端拆解为多个微服务。同时，为使自动协同可以只关注微服务所提供的功能，以统一的方式进行操作，我们制定了规范化接口，将拆解的微服务信息进行封装。每个微服务都有其入口点类及多个必需的item等，因此可被形式化表示为name、APP_name、entry_cls、operation、items、URL，分别表示微服务的名称、所属APP的名称、入口点类、操作、item集合、资源定位符。其中，items中的每个item都可由三元组<semantics,syntax,action>进行表示，分别为语义、语法、动作。
目前存在的APP客户端是一个完整的应用，除开放API外，不支持外部调用其内部微服务。为了支持协同，本发明提取出虽然APP开发者未提供API，但可隐式调用的、有意义的微服务，并映射为规范化接口，使多个微服务可以以统一的方式进行交互。例如，附图1所示的APP1和APP2根据服务粒度分别可以微服务化为4个、3个微服务，用户选择其中两个微服务，标记为flow MSx(x＝1,2)。
(1)APP客户端根据服务粒度抽象拆解为一定数量的微服务：Android APP客户端的每个UI对应一个Activity组件，本发明提取同时具有enabled和exported属性的Activity，它们可以从其外部被其他APP调用执行。使用自动化测试工具Monkey，通过定义点击事件对初步提取出的Activity进行测试，挑选微服务的首个UI，得到微服务的静态任务，作为入口点类entry_cls。根据服务粒度，对成功启动的Activity进行分析筛选，确定本发明所支持的微服务集合。
(2)微服务映射为规范化接口：微服务是基于事件驱动的，事件执行过程中会涉及一些必要的参数，由微服务的items进行表示。本发明使用Dump View Hierarchy for UI automator工具，对微服务的entry_cls进行分析，获取每个item的语义、语法格式及控件信息。借助静态分析工具FlowDroid，将其source和sink设置为与APP存储有关的API，即可获取item对应控件的存储信息，作为item的action信息的抽象。但对于部分item，利用FlowDroid无法找出它的存储，本发明结合使用Android提供的辅助服务及adb(Android Debug Bridge)命令，找到item对应的辅助服务节点，结合“Input”命令对item对应的控件进行操作，作为item的action信息。将抽象的微服务信息封装为JSON对象部署到服务端，以RESTful API的形式对外提供规范化接口。附图2提供了一个示例。
第二步：微服务流定制支持
根据步骤一所抽象的APP的微服务集合，与用户设备中的APP取交集，即可获取用户设备所支持的APP微服务列表，用户按照个人需求从微服务列表中选取部分微服务，定制成微服务流。
本发明最终是为用户服务的，因此，需要给用户提供一个客户端APP以支持基于微服务的APP自动协同。附图3是本发明的APP客户端的启动页面截图，首先是对所提供的功能、使用方法及注意事项的简洁描述；微服务是依赖于APP的，中间部分是支持的APP列表，点击每个APP可看到所抽象出的微服务列表，如附图4所示；下方提供了几个按钮，以对定制的微服务流进行查看。用户按需点击微服务即可自动添加到当前微服务流中。特别地，本发明会保存用户已定制的微服务流，并展示最近一次定制的微服务流，方便用户重复使用微服务流。
微服务切换是本发明协同的核心，可表示为<MS1,MS2,data>，即两个微服务MS1与MS2间通过data交互，包括两个过程，即微服务参数获取、微服务自动启动及参数注入。
第三步：微服务参数获取
当用户在移动终端解锁的情况下，一定会处于某个APP的特定Activity中，即使是处于桌面也是如此。由于自动协同是整个移动设备运行中的一部分，所以需要对设备前台运行情况进行监控，采用Service组件来实现。监控器在获取用户许可后，即可判断当前是否需要进行自动协同。在此过程中，利用监控器需要将持续监听用户设备产生的事件，并对感兴趣的事件进行处理，包括微服务流何时触发、微服务流当前执行情况及协同过程中重复利用的服务参数。通过调用服务端公开的规范化接口，即可获取每个微服务的抽象信息。本发明利用微服务切换说明协同方法，用<MS1,MS2,data>进行表示，即微服务MS1和MS2间通过data交互。
当用户从微服务回退到桌面时，我们认为微服务执行结束，根据抽象信息中item的action描述，生成实际可执行代码，包括借助辅助服务、adb命令对存储及节点进行操作，抓取微服务的各个item对应的参数实例，作为微服务切换的data交由数据中转站处理。数据中转站根据构建的语义关系库对微服务切换中的两个微服务的各个item的语义进行匹配，再按照统一的语法格式暂存。语义关系库中包括对各个item的语义标注及其相互关系，本发明考虑了相同关系(same as)和包含关系(kind of)，优先相同关系。
第四步：微服务自动启动及参数注入
微服务流是微服务执行顺序的描述，本发明在每个微服务执行结束时，都会判断是否还有下一个微服务要执行，若判断为微服务流未结束，则获取服务端所封装的微服务中的entry_cls信息作为入口点类加载微服务启动。由于入口点类同时具有enabled和exported属性，使用Intent和ClassLoader机制将入口点类调起，即可运行APP内部的微服务；同时数据中转站根据微服务切换的MS2中各个item的语法格式处理data为所需的服务参数实例，发送给执行器。执行器根据MS2的入口点类，将其加载到用户设备的前台。执行器根据MS2中各个item的action的不同，采用不同的方式对所有item进行注入操作。可根据附图5所述的算法1对MS2的各个item执行相应的动作，完成可重用服务参数的自动注入。其中，算法1的第1行为变量初始化操作，2～16行对MS2的所有所需item循环执行注入操作，3～5行是对被注入item对应的参数实例的处理，6～10行对adb类型的action进行注入操作，11～15行对存储类型的action进行注入操作。。
本发明的基于客户端微服务的APP自动协同方法的整体概述如附图6所示。下面通过实验展示基于客户端微服务的APP自动协同方法的效果。
假设用户身处北京，想要去南京进行为期5天的旅行。他需要从微服务库中依次选择出美团APP的机票预订微服务(flow MS1)、金色世纪旅行APP的火车票预订(flow MS2)、酒店预订(flow MS3)、同程旅游APP的酒店预订(flow MS4)及美团的美团旅行浏览微服务(flow MS5)，在第一次出现微服务参数的文本框中输入可重用item的参数实例，如附图7(a)所示，输入机票预订的出发地、目的地、出发日期、返程日期，即可查询从北京到南京的往返机票信息，驱动基于微服务的APP自动协同执行。当flow MS1执行结束后，系统会自动启动flow MS2并注入可重用的参数实例到flow MS2中，即出发站点、到达站点和出发日期，用户只需要确认这些参数实例的正确性即可获取服务，如附图7(b)所示。该过程反复执行直到整个微服务流执行结束。整个按自定义微服务流运行的APP自动协同的效果如附图7所示，图中参数重用效果明显。在我们的原型系统的帮助下，用户不需要手动进行微服务间切换及频繁的参数输入。
因此，由于功能碎片化和集成多个服务导致的繁琐操作，通过本发明所提供的基于客户端微服务的APP自动协同方法得到了进一步改善。
尽管上面结合附图对本发明的功能及工作过程进行了描述，但本发明并不局限于上述的具体功能和工作过程，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可以做出很多形式，这些均属于本发明的保护之内。