CN106534322A - 一种用于对底层消息进行直接响应的设备及方法 - Google Patents

Abstract

本发明公开了一种用于对底层消息进行直接响应的设备及方法，所述设备包括：生成单元，用于在本地应用启动后，根据用户输入来生成与本地应用的底层消息相关的响应消息；接口单元，用于通过网络从服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息；监控单元，用于监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，将所述底层消息发送给响应单元；以及响应单元，用于根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。本发明还涉及一种移动终端，包括或用于实现用于对底层消息进行直接响应的设备。

Description

一种用于对底层消息进行直接响应的设备及方法

技术领域

本发明涉及信息处理领域，并且更具体地，涉及一种用于对底层消息进行直接响应的设备、方法以及移动终端。

背景技术

目前，随着诸如手机之类的移动终端的越来越广泛的使用，人们越来越习惯于利用移动终端来实现各种业务的处理。例如，通过移动终端来订购商品、预定火车票、预定飞机票、预定餐馆或建立约车业务等已经成为人们日常生活的一部分。通常，在用户需要通过移动终端进行上述活动时，通常需要运行相应的软件或应用。并且，在相应的软件或应用启动后，需要通过软件或应用的交互界面来输入确认信息或订单信息，从而完成业务确认。例如，在用户利用软件或应用来预定火车票时，通常需要根据服务提供方来动态信息来调整预定测量。在这种情况下，用户利用手动输入方式来进行信息表单提交的情况通常会重复多次。这种重复会让用户对于软件或应用的体验变差。

另一方面，在信息表单所涉及的商品或服务的供应量不足时，信息表单提交的速度往往会觉得用户能否获得商品、服务或提供服务。在用户需要进行大量数据输入的情况下，由于移动终端的尺寸限制，用户通常会出现误操作的情况。大部分的误操作会导致用户之前输入的数据无效，因而必须重新输入。在这种情况下，用户无法获得商品、服务或提供服务的概率变得非常高。

为此，需要提供一种能够准确且快速生成信息表单，从而通过对相关消息进行及时应答来完成业务建立的方式。

发明内容

为了解决上述问题，本发明提供了一种用于对底层消息进行直接响应的设备，所述设备包括：

生成单元，用于在本地应用启动后，根据用户输入来生成与本地应用的底层消息相关的响应消息；

接口单元，用于通过网络从服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息；

监控单元，用于监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，将所述底层消息发送给响应单元；以及

响应单元，用于根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

优选地，所述本地应用能够通过网络与服务器进行数据交互，以实现业务的提交。

优选地，所述响应消息是针对数据请求消息的响应。

优选地，所述底层消息是物理层消息。

优选地，所述数据请求消息是服务器发送的且请求与本地应用建立业务流程的请求消息。

优选地，所述接口单元通过网络从服务器接收指示业务流程成功建立的确认消息。

优选地，还包括处理单元，用于基于所述确认消息启动所述业务流程。

优选地，还包括显示单元，用于显示业务流程成功建立的确认消息或所启动的业务流程的运行过程。

根据本发明的另一方面，提供一种移动终端，包括或用于执行如上所述的用于对底层消息进行直接响应的设备。

根据本发明的另一方面，提供一种用于对底层消息进行直接响应的方法，所述方法包括：

在本地应用启动后，根据用户输入来生成与本地应用的底层消息相关的响应消息；

通过网络从服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息；以及

监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

优选地，所述本地应用能够通过网络与服务器进行数据交互，以实现业务的提交。

优选地，所述响应消息是针对数据请求消息的响应。

优选地，所述底层消息是物理层消息。

优选地，所述数据请求消息是服务器发送的且请求与本地应用建立业务流程的请求消息。

优选地，通过网络从服务器接收指示业务流程成功建立的确认消息。

优选地，还包括基于所述确认消息启动所述业务流程。

优选地，还包括显示业务流程成功建立的确认消息或所启动的业务流程的运行过程。

附图说明

通过参考下面的附图，可以更为完整地理解本发明的示例性实施方式：

图1为根据本发明优选实施方式的通信系统的结构示意图；

图2为根据本发明优选实施方式的用于对底层消息进行直接响应的设备的结构示意图；

图3为现有技术中对请求消息进行响应的示意图；

图4为根据本发明优选实施方式的对底层消息进行直接响应的示意图；以及

图5为根据本发明优选实施方式的用于对底层消息进行直接响应的方法的流程图。

具体实施方式

现在参考附图介绍本发明的示例性实施方式，然而，本发明可以用许多不同的形式来实施，并且不局限于此处描述的实施例，提供这些实施例是为了详尽地且完全地公开本发明，并且向所属技术领域的技术人员充分传达本发明的范围。对于表示在附图中的示例性实施方式中的术语并不是对本发明的限定。在附图中，相同的单元/元件使用相同的附图标记。

除非另有说明，此处使用的术语(包括科技术语)对所属技术领域的技术人员具有通常的理解含义。另外，可以理解的是，以通常使用的词典限定的术语，应当被理解为与其相关领域的语境具有一致的含义，而不应该被理解为理想化的或过于正式的意义。

图1为根据本发明优选实施方式的通信系统100的结构示意图。优选地，通信系统100能够通过网络为多个用户终端提供服务，这种服务例如是提供商品、预定火车票、预定飞机票、预定餐馆或网约车等。在通信系统100中，在用户终端上的本地应用启动后，用户可以根据意愿来输入响应规则，并且由用户终端根据所述响应规则来生成与本地应用的底层消息相关的响应消息。在准备建立业务连接时，用户终端可以通过网络从服务器接收数据请求消息，并且在数据请求消息到达应用层之前的系统底层将所述数据请求消息转换为相应的底层消息。接着，用户终端可以监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，将所述底层消息发送给响应单元。最后，用户终端根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

如图1所示，通信系统100包括：用户终端101-1、101-2…101-N，网络102以及应用服务器103。优选地，用户终端101-1、101-2…101-N可以是任意类型的移动终端、固定终端、或便携式终端，包括移动手机、站、单元、设备、多媒体计算机、多媒体平板、因特网节点、通信器、桌面计算机、膝上型计算机、个人数字助理(PDA)、或其任意组合。

优选地，用户终端101-1、101-2…101-N均可以用于订购商品、预定火车票、预定飞机票、预定餐馆或建立约车业务等。为此，在用户终端101-1、101-2…101-N上可以运行购物应用、订票应用、订餐应用和约车应用。通常，使用用户终端的用户为服务接收方，即用户接收由服务提供方提供的服务。通常，服务提供方还可以提供各种类型的商品。在另一种情况下，部分用户利用移动终端来提供服务。例如，网约车司机通过移动终端与乘客建立联系并且在建立联系后为乘客提供约车服务。部分商户利用移动终端来接收客户的订单并且为客户提供商品或服务。优选地，本地应用能够通过网络与服务器进行数据交互，以实现业务提交、建立业务连接、提供服务或接受服务。

优选地，如上所示，用户终端101-1、101-2…101-N上会运行各种类型的应用。其中，在各种类型的应用中，一部分应用是需要与应用服务器103进行信息交互才能建立业务连接的应用。例如，在约车应用的例子中，当乘客需要使用网约车时，会将请求提交给网约车服务器。随后，网约车服务器会将乘客的请求发布给距离乘客较近的一个或多个网约车提供者。一个或多个网约车提供者中的每一个可以使用用户终端来对乘客的请求进行响应，从而实现业务提交或业务连接。

优选地，在本地应用启动后，用户终端101-1、101-2…101-N可以根据用户输入来生成与本地应用的底层消息相关的响应消息。通常，响应消息是针对数据请求消息的响应。其中，数据请求消息是服务器发送的且请求与本地应用建立业务流程或业务连接的请求消息。通常，当应用服务器102发送数据请求消息给用户终端101-1、101-2…101-N，以等待用户终端101-1、101-2…101-N进行响应时，通常会将经由接口单元接收的数据请求消息从底层开始进行转换，并且最后到达应用层。在这种转换过程中，会将底层消息逐级地进行转换，并且最后转换成应用层消息以通过用户终端101-1、101-2…101-N进行显示。此时，用户可以通过对用户终端101-1、101-2…101-N进行操作来对原始的数据请求消息进行处理，例如选择接受服务、提供服务、不接受服务或不提供服务。

在用户希望接受服务或提供服务时，很可能需要守候并且不间断地使用用户终端101-1、101-2…101-N以防止错过可能的数据请求消息。然而，这种方式使用户的体验变差，并且会让用户的使用难度加大。为此，在用户能够预先确定与数据请求消息相对应的响应消息时，可以通过预先确定的响应消息在底层进行直接响应，以避免用户错失数据请求消息。优选地，这种响应消息例如是，能够提供约车服务、能够提供10箱打印纸等。根据本发明的在底层进行直接响应的方式能够降低用户的操作繁琐度并且能够提高用户使用效率。

优选地，在应用中，用户终端101-1、101-2…101-N可以通过网络102从应用服务器103接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息。通常，应用服务器103在接收到某些用户的服务请求消息后，会根据针对用户的身份认证来确定是否提供服务。当应用服务器103确定为用户提供服务时，会将所述用户的服务请求放置在数据请求消息中进行发布。优选地，当用户终端101-1、101-2…101-N接收到数据请求消息后，会在系统底层将所述数据请求消息转换为相应的底层消息。这种底层消息是在现有的技术方案中会被逐级转换为应用层消息的消息。优选地，底层消息例如是物理层消息。

优选地，用户终端101-1、101-2…101-N监控本地应用的运行，在确定所述系统底层处存在所述底层消息时，对所述底层消息进行响应。通常，在用户通过用户终端101-1、101-2…101-N生成与本地应用的底层消息相关的响应消息之后，用户终端需要确定何时利用响应消息对源自数据请求消息的底层消息进行响应。为此，用户终端101-1、101-2…101-N需要监控本地应用的运行过程，从而能够在本地应用生成了与所述响应消息对应的底层消息时进行及时响应。优选地，用户终端101-1、101-2…101-N在确定系统底层处存在源自数据请求消息的底层消息时，会利用响应消息对所述底层消息进行响应。

优选地，用户终端101-1、101-2…101-N根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。如上所述，在确定所述系统底层处存在所述底层消息时，可以利用预先确定的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。即，不会降所述底层消息逐级转换为应用层消息，而仅是利用响应消息对其进行响应。

优选地，在用户终端101-1、101-2…101-N的响应消息得到应用服务器103的认可后，会建立业务连接或业务流程，并且发送指示业务建立/业务批准/提供服务的确认消息。用户终端101-1、101-2…101-N经由网络102从应用服务器103接收确认消息，并且会将所述确认消息从系统底层逐级转换为应用层确认消息。用户终端101-1、101-2…101-N将所述应用层确认消息呈现给用户，从而提示用户业务连接已经建立。由此可知，用户终端101-1、101-2…101-N不会将数据请求消息转成应用层消息，而会将确认消息转换为应用层消息。

优选地，用户终端101-1、101-2…101-N确定业务连接或业务流程建立后，通过所述业务连接来提供服务、接受服务或启动所述业务流程。此外，用户终端101-1、101-2…101-N还能够显示业务流程成功建立的确认消息或所启动的业务流程的运行过程。

根据本发明的优选实施方式，可以使用黑魔法(BM，Black Magic)为Android应用提供动态扩展和修复能力的技术，如：云修复、云广告、模块解耦、黑科技等。BM由BMAndroidRuntime(运行环境)、BMActivityThread(活动线程)、BlackMagic.apk(安装包)和BMagic文件四部分组成。其中BMAndroidRuntime负责提供核心能力，BMActivityThread负责构建运行环境，BlackMagic.apk负责提供核心接口(BMCore)以及身份认证等管理机制，而最终的功能特性由BMagic文件提供。

优选地，BMAndroidRuntime是专门为BM提供改造Java类和方法的能力(如：钩子Hook)的定制安卓运行环境ART。BMActivityThread用于提供一套判断和启动BM的机制，从而将BlackMagic对第三方应用的性能影响降低到最小，目前所测量的实际延迟仅为1ms。目前采用通过路径快速判断目标应用是否需要BM支持的方式来决定是否对目标应用加载BM文件以进行能力扩展。

BlackMagic.apk是一个非常普通的App，但是必须使用提供商签名，否则无法工作。BlackMagic.apk内部携带基础的BM文件所需要的接口。这种接口是一个API最小集合，即BMCore，用于确保BM对目标应用的内存占用量最低。同时也确保在加载BM文件的时候对目标应用性能影响最小。

BMCore是一个Jar包，用于开发人员开发BM文件时使用。Jar包中提供常用的基本应用程序接口API，使得BM文件能够动态修改Java类和方法以及Hook某些方法。BM文件会由BlackMagic.apk内部集成，便于版本控制和减少BM文件大小。基于BMCore可以开发更多的通用基础库以及扩展库。其中扩展库不是具体功能，而是为实现某些具体功能提供一些必要能力，可以各种模块所共享。

BM文件是实现业务功能的主体，并且每一个BM文件都是由多个BMagic和BMagicKnife组成。其中，一个BMagic可以包括多个BMagicKnif。BMagic是对要进行Hook的类的抽象，并且BMagicKnife是对要进行Hook的方法的一个抽象，因此它们之间是映射关系。某个具体的功能是由多个BMagic通过BMagicKnife获取到信息后以共享的方式实现的。

图2为根据本发明优选实施方式的用于对底层消息进行直接响应的设备200的结构示意图。优选地，在用户终端上的本地应用启动后，用户可以根据意愿来输入响应规则，并且由设备200根据所述响应规则来生成与本地应用的底层消息相关的响应消息。在准备建立业务连接时，设备200可以通过网络从服务器接收数据请求消息，并且在数据请求消息到达应用层之前的系统底层将所述数据请求消息转换为相应的底层消息。接着，设备200可以监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，将所述底层消息发送给响应单元。最后，设备200根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

如图2所示，设备200包括：生成单元201、接口单元202、监控单元203、响应单204、处理单元205以及显示单元206。优选地，在本地应用启动后，生成单元201可以根据用户输入来生成与本地应用的底层消息相关的响应消息。通常，响应消息是针对数据请求消息的响应。其中，数据请求消息是服务器发送的且请求与本地应用建立业务流程或业务连接的请求消息。通常，当应用服务器发送数据请求消息给用户终端，以等待用户终端进行响应时，通常会将经由接口单元接收的数据请求消息从底层开始进行转换，并且最后到达应用层。在这种转换过程中，会将底层消息逐级地进行转换，并且最后转换成应用层消息以通过用户终端进行显示。此时，用户可以通过对用户终端进行操作来对原始的数据请求消息进行处理，例如选择接受服务、提供服务、不接受服务或不提供服务。

在用户希望接受服务或提供服务时，很可能需要守候并且不间断地使用用户终端以防止错过可能的数据请求消息。然而，这种方式使用户的体验变差，并且会让用户的使用难度加大。为此，在用户能够预先确定与数据请求消息相对应的响应消息时，生成单元201可以基于预先确定的响应消息在底层进行直接响应，以避免用户错失数据请求消息。优选地，这种响应消息例如是，能够提供约车服务、能够提供10箱打印纸等。根据本发明的在底层进行直接响应的方式能够降低用户的操作繁琐度并且能够提高用户使用效率。

优选地，在应用中，接口单元202可以通过网络从应用服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息。通常，应用服务器在接收到某些用户的服务请求消息后，会根据针对用户的身份认证来确定是否提供服务。当应用服务器确定为用户提供服务时，会将所述用户的服务请求放置在数据请求消息中进行发布。优选地，当接口单元202接收到数据请求消息后，会在系统底层将所述数据请求消息转换为相应的底层消息。这种底层消息是在现有的技术方案中会被逐级转换为应用层消息的消息。优选地，底层消息例如是物理层消息。

优选地，监控单元203监控本地应用的运行，在确定所述系统底层处存在所述底层消息时，对所述底层消息进行响应。通常，在用户通过生成单元201生成与本地应用的底层消息相关的响应消息之后，用户终端需要确定何时利用响应消息对源自数据请求消息的底层消息进行响应。为此，监控单元203需要监控本地应用的运行过程，从而能够在本地应用生成了与所述响应消息对应的底层消息时进行及时响应。优选地，监控单元203在确定系统底层处存在源自数据请求消息的底层消息时，会利用响应消息对所述底层消息进行响应。

优选地，响应单元204根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。如上所述，在确定所述系统底层处存在所述底层消息时，可以利用预先确定的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。即，不会降所述底层消息逐级转换为应用层消息，而仅是利用响应消息对其进行响应。

优选地，在响应单元204的响应消息得到应用服务器103的认可后，会建立业务连接或业务流程，并且发送指示业务建立/业务批准/提供服务的确认消息。接口单元202经由网络从应用服务器接收确认消息，并且会将所述确认消息从系统底层逐级转换为应用层确认消息。优选地，设备200可以将所述应用层确认消息呈现给用户，从而提示用户业务连接已经建立。由此可知，设备200不会将数据请求消息转成应用层消息，而会将确认消息转换为应用层消息。

优选地，在确定业务连接或业务流程建立后，处理单元205通过所述业务连接来提供服务、接受服务或启动所述业务流程。

优选地，显示单元206能够显示业务流程成功建立的确认消息或所启动的业务流程的运行过程。

优选地，根据本发明的优选实施方式，如上所述的设备200可以被包括在移动终端中，或由移动终端来执行。

图3为现有技术中对请求消息进行响应的示意图。如图3所示，为了清楚起见，仅示出了接口单元、物理层、链路层和应用层，但是所属领域技术人员应当了解的是，还可以包括其他层级结构。在现有技术方案中，当通过接口单元从应用服务器接收到数据请求消息时，将所述数据请求消息转换为相应的底层消息，例如物理层消息。然而，将物理层消息逐级转换为应用层消息(例如，先转换为链路层消息，在转换为应用层消息)。在将底层消息转换为应用层消息后，将应用层消息呈现给用户。当用户利用用户终端对所述应用层消息进行响应后，会将响应消息逐级转换为物理层消息并且经由接口单元发送给应用服务器。

然而，在本发明的实施方式中，用户终端根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。图4为根据本发明优选实施方式的对底层消息进行直接响应的示意图。如图4所示，当通过接口单元从应用服务器接收到数据请求消息时，将所述数据请求消息转换为相应的底层消息，例如物理层消息。接着，在物理层，利用预先确定的响应消息对所述底层消息进行直接响应。这种在底层进行直接响应的方式能够降低用户的操作繁琐度并且能够提高用户使用效率。

图5为根据本发明优选实施方式的用于对底层消息进行直接响应的方法500的流程图。优选地，在用户终端上的本地应用启动后，用户可以根据意愿来输入响应规则，并且方法500根据所述响应规则来生成与本地应用的底层消息相关的响应消息。在准备建立业务连接时，方法500可以通过网络从服务器接收数据请求消息，并且在数据请求消息到达应用层之前的系统底层将所述数据请求消息转换为相应的底层消息。接着，方法500可以监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，将所述底层消息发送给响应单元。最后，方法500根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

如图5所示，方法500从步骤501处开始。优选地，在步骤501，当本地应用启动后，可以根据用户输入来生成与本地应用的底层消息相关的响应消息。通常，响应消息是针对数据请求消息的响应。其中，数据请求消息是服务器发送的且请求与本地应用建立业务流程或业务连接的请求消息。通常，当应用服务器发送数据请求消息给用户终端，以等待用户终端进行响应时，通常会将经由接口单元接收的数据请求消息从底层开始进行转换，并且最后到达应用层。在这种转换过程中，会将底层消息逐级地进行转换，并且最后转换成应用层消息以通过用户终端进行显示。此时，用户可以通过对用户终端进行操作来对原始的数据请求消息进行处理，例如选择接受服务、提供服务、不接受服务或不提供服务。

在用户希望接受服务或提供服务时，很可能需要守候并且不间断地使用用户终端以防止错过可能的数据请求消息。然而，这种方式使用户的体验变差，并且会让用户的使用难度加大。为此，在用户能够预先确定与数据请求消息相对应的响应消息时，方法500可以基于预先确定的响应消息在底层进行直接响应，以避免用户错失数据请求消息。优选地，这种响应消息例如是，能够提供约车服务、能够提供10箱打印纸等。根据本发明的在底层进行直接响应的方式能够降低用户的操作繁琐度并且能够提高用户使用效率。

优选地，在步骤502，可以通过网络从应用服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息。通常，应用服务器在接收到某些用户的服务请求消息后，会根据针对用户的身份认证来确定是否提供服务。当应用服务器确定为用户提供服务时，会将所述用户的服务请求放置在数据请求消息中进行发布。优选地，当接收到数据请求消息后，会在系统底层将所述数据请求消息转换为相应的底层消息。这种底层消息是在现有的技术方案中会被逐级转换为应用层消息的消息。优选地，底层消息例如是物理层消息。

优选地，在步骤503，监控本地应用的运行，在确定所述系统底层处存在所述底层消息时，对所述底层消息进行响应。通常，在生成与本地应用的底层消息相关的响应消息之后，用户终端需要确定何时利用响应消息对源自数据请求消息的底层消息进行响应。为此，方法500需要监控本地应用的运行过程，从而能够在本地应用生成了与所述响应消息对应的底层消息时进行及时响应。优选地，方法500在确定系统底层处存在源自数据请求消息的底层消息时，会利用响应消息对所述底层消息进行响应。

优选地，在步骤503，根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。如上所述，在确定所述系统底层处存在所述底层消息时，可以利用预先确定的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。即，不会降所述底层消息逐级转换为应用层消息，而仅是利用响应消息对其进行响应。

优选地，在响应消息得到应用服务器的认可后，会建立业务连接或业务流程，并且发送指示业务建立/业务批准/提供服务的确认消息。在方法500中还包括，经由网络从应用服务器接收确认消息，并且会将所述确认消息从系统底层逐级转换为应用层确认消息。优选地，方法500可以将所述应用层确认消息呈现给用户，从而提示用户业务连接已经建立。由此可知，方法500不会将数据请求消息转成应用层消息，而会将确认消息转换为应用层消息。优选地，在确定业务连接或业务流程建立后，还包括通过所述业务连接来提供服务、接受服务或启动所述业务流程。优选地，方法500能够显示业务流程成功建立的确认消息或所启动的业务流程的运行过程。

已经通过参考少量实施方式描述了本发明。然而，本领域技术人员所公知的，正如附带的专利权利要求所限定的，除了本发明以上公开的其他的实施例等同地落在本发明的范围内。

通常地，在权利要求中使用的所有术语都根据他们在技术领域的通常含义被解释，除非在其中被另外明确地定义。所有的参考“一个/所述/该[装置、组件等]”都被开放地解释为所述装置、组件等中的至少一个实例，除非另外明确地说明。这里公开的任何方法的步骤都没必要以公开的准确的顺序运行，除非明确地说明。

Claims (10)

1.一种用于对底层消息进行直接响应的设备，所述设备包括：

生成单元，用于在本地应用启动后，根据用户输入来生成与本地应用的底层消息相关的响应消息；

接口单元，用于通过网络从服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息；

监控单元，用于监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，将所述底层消息发送给响应单元；以及

响应单元，用于根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

2.根据权利要求1所述的设备，所述本地应用能够通过网络与服务器进行数据交互，以实现业务的提交。

3.根据权利要求1所述的设备，所述响应消息是针对数据请求消息的响应。

4.根据权利要求1所述的设备，所述底层消息是物理层消息。

5.一种移动终端，包括或用于执行如权利要求1-4中任意一项所述的设备。

6.一种用于对底层消息进行直接响应的方法，所述方法包括：

在本地应用启动后，根据用户输入来生成与本地应用的底层消息相关的响应消息；

通过网络从服务器接收数据请求消息，并且在系统底层将所述数据请求消息转换为相应的底层消息；以及

监控所述本地应用的运行，在确定所述系统底层处存在所述底层消息时，根据所生成的响应消息对所述底层消息进行响应，而不将所述底层消息发送给应用层。

7.根据权利要求6所述的方法，所述本地应用能够通过网络与服务器进行数据交互，以实现业务的提交。

8.根据权利要求6所述的方法，所述响应消息是针对数据请求消息的响应。

9.根据权利要求6所述的方法，所述底层消息是物理层消息。

10.根据权利要求6所述的方法，所述数据请求消息是服务器发送的且请求与本地应用建立业务流程的请求消息。