一种信息处理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种信息处理方法及装置。

背景技术：

在互联网时代，随着终端的普及，各类应用的数量也大大增加，给人们的日常生活和工作带来了便利。所述终端包括但不限于：手机、个人计算机、平板电脑、智能手表、车载台，等等。

一般地，应用的客户端搭载于终端上，而服务端搭载于该应用的服务器或终端上。在终端上安装应用的客户端后，该客户端一般会包含有配置信息，而在使用该客户端的过程中，该客户端可能经常需要从服务端获取更新的配置信息或其他配置信息(为了便于描述，所述更新的配置信息、所述其他配置信息可以统称为：配置信息的更新信息)，以实现对客户端的更新和功能升级。

例如，对于某种信息卡片应用，该信息卡片应用的客户端的配置信息，以及该配置信息的更新信息包括但不限于：界面模板、全局应用设置信息、场景引擎规则、菜单信息，等等。

在现有技术中，客户端可以采用定时时钟方案，从服务端获取配置信息的更新信息。具体的，客户端可以启动一个定时线程，定时调用服务端提供的、用于更新配置信息的接口，以请求查询是否有该配置信息的更新信息，则服务端接收到请求后，当查询到有更新信息时，将该更新信息返回给客户端。

但是，在采用现有技术的情况下，客户端启动后，所述定时线程会一直占用客户端部分资源，客户端的负担较大。

技术实现要素：

本申请实施例提供一种信息处理方法及装置，用以解决现有技术中的客户端获取配置信息的更新信息的方法，导致客户端的负担较大的问题。

本申请实施例提供的一种信息处理方法，包括：

根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求；

将所述服务请求发送给所述服务端。

本申请实施例提供的一种信息处理装置，包括：

生成模块，用于根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求；

发送模块，用于将所述服务请求发送给所述服务端。

本申请实施例提供另一种信息处理方法及装置，用以解决现有技术中的客户端获取配置信息的更新信息的方法，导致客户端的负担较大的问题。

本申请实施例提供的另一种信息处理方法，包括：

接收客户端发送的服务请求，其中，所述服务请求包括所述客户端针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息；

根据所述服务请求中包含的所述状态信息，确定并向所述客户端返回更新指示信息，所述更新指示信息用于指示所述配置信息的更新信息。

本申请实施例提供的另一种信息处理装置，包括：

接收模块，用于接收客户端发送的服务请求，其中，所述服务请求包括所述客户端针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息；

返回模块，用于根据所述服务请求中包含的所述状态信息，确定并向所述客户端返回更新指示信息，所述更新指示信息用于指示所述配置信息的更新信 息。

本申请实施例提供一种终端，包括：

存储器，用于存储处理器可执行指令；

处理器，耦合到所述存储器，用于读取所述存储器存储的可执行指令，作为响应，执行如下操作：根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求；将所述服务请求发送给所述服务端。

本申请实施例提供另一种终端，包括：

存储器，用于存储处理器可执行指令；

处理器，耦合到所述存储器，用于读取所述存储器存储的可执行指令，作为响应，执行如下操作：接收客户端发送的服务请求，其中，所述服务请求包括所述客户端针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息；根据所述服务请求中包含的所述状态信息，确定并向所述客户端返回更新指示信息，所述更新指示信息用于指示所述配置信息的更新信息。

本申请实施例通过上述至少一种技术方案，客户端可以利用已有的任一服务接口获取配置信息的更新信息，而不需要为了获取该更新信息单独维护一个定时线程，因此，可以减轻客户端的负担。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的信息处理方法的过程；

图2为本申请实施例提供的，在一种实际应用场景下，客户端上的代理单元的实现方式和工作方式；

图3为本申请实施例提供的另一种信息处理方法的过程；

图4为本申请实施例提供的，在一种实际应用场景下，实施所述信息处理方法时，客户端和服务端的交互示意图；

图5为本申请实施例提供的，在一种实际应用场景下，适用于实施所述信息处理方法的系统结构示意图；

图6为本申请实施例提供的对应于图1的信息处理装置结构示意图；

图7为本申请实施例提供的对应于图3的信息处理装置结构示意图；

图8为本申请实施例提供的对应于图1的终端示意图；

图9为本申请实施例提供的对应于图3的终端示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，对于任一应用，该应用的服务端可以为该应用的客户端提供不止一项服务。

例如，对于即时通讯应用，服务端提供的服务包括但不限于：查询通讯消息、传输通讯消息、查询指定通讯账号的公开信息、传输文件，等等。

又例如，对于视频应用，服务端提供的服务包括但不限于：视频点播、视频直播、视频离线下载，等等。

服务端可以预先针对每项服务，向客户端提供用于获取该项服务的服务接口，相应的，客户端可以生成针对该服务接口的接口调用请求，并通过该服务接口发送给服务端，则服务端通过该服务接口对应的接口实现单元，对该接口调用请求进行处理，进而可以向客户端返回该项服务。可以看到，各项服务对 应的服务接口是已经存在的，且有相应的服务进程为服务接口提供资源支持。

在本申请实施例中，利用这些已经存在的服务接口和对应的服务进程，不仅可以获得对应的服务，还可以处理一些额外的事务，从而可以不用为所述额外的事务单独提供接口和进程，这样的话，不仅可以减轻服务端和客户端的负担，也可以减少额外的网络调用，其中，所述额外的事务至少可以包括客户端获取自身上的配置信息的更新信息。本申请实施例主要基于这种情况进行详细说明。

图1为本申请实施例提供的信息处理方法的过程，所述信息处理方法的执行主体可以是：应用的客户端，或者，搭载有所述客户端的终端。其中，所述终端包括但不限于：个人计算机、手机、平板电脑、智能手表、车载移动台等。所述的执行主体并不构成对本申请的限定，为了便于描述，图1对应的各实施例均以执行主体是客户端为例进行说明。

图1中的过程具体可以包括以下步骤：

S101：根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求。

在本申请实施例中，客户端当接收到服务获取指令时，生成针对服务端提供的至少一个服务接口的接口调用请求。所述服务获取指令可以是：用于指示客户端从服务端，获取服务端提供的任一项服务的指令。

本申请实施例对“接收服务获取指令”这一动作的触发因素并不做限定，在实际应用中，这一动作可以由用户对客户端的操作触发，也可以由客户端根据预设业务逻辑自动触发。

例如，用户在使用即时通讯应用时，可能会在应用界面编辑一条通讯消息，并点击“发送”按钮，将该条通讯消息发送给另一位用户。在该例中，可以认为，该“发送”按钮被按下后，客户端即接收到一条服务获取指令，该条服务获取指令用于指示客户端从服务端提供的“传输通讯消息”这项服务对应的服 务接口获取服务。

在本申请实施例中，所述接口调用请求可以包含所述至少一个服务接口的接口函数，以及所述接口函数的调用参数，其中，调用参数可以是由服务获取指令指定的，也可以是用户在客户端上实时地输入的。

在本申请实施例中，除了要获取接口调用请求对应的服务以外，同时还可以获取客户端上的配置信息的更新信息，因此，可以不直接向服务端发送接口调用请求，而是对针对服务接口和/或接口调用请求进行特定处理，以加入获取该更新信息所需要的额外的信息(也即，客户端上的配置信息的状态信息)，进而将特定处理后生成的请求发送给服务端。在本申请实施例中，所述特定处理至少可以包括两种，下面对这两种分别进行说明。

第一种，可以预先对客户端上用于生成接口调用请求的服务接口单元进行修改，以加入包含所述状态信息的处理逻辑，这样的话，通过修改后的服务接口单元，可以生成包含有所述状态信息的接口调用请求，并发送给服务端。第一种处理方法不用改变客户端上各单元的结构。

第二种，也即步骤S101对应的处理方法。具体的，可以预先在客户端上增加代理单元，则客户端可以将生成的接口调用请求传递给代理单元，由代理单元执行步骤S101，进而可以将生成的、包含所述状态信息的服务请求发送给服务端。第二种处理方法实现成本较低，对客户端和服务端上已有的接口影响较小。

在实际应用中，可以根据应用场景的具体情况，在以上两种处理方法中选择更适用的方法。本申请实施例主要是基于上述的第二种处理方法进行说明的。

进一步的，为了便于理解，下面对所述配置信息进行说明。

安装应用的客户端后，该客户端一般会包含有配置信息，而在使用该客户端的过程中，该客户端可能经常需要从服务端获取更新的配置信息或其他配置信息(为了便于描述，所述更新的配置信息、所述其他配置信息可以统称为： 配置信息的更新信息)，以实现对客户端的更新和功能升级。

需要说明的是，本申请实施例对所述配置信息和所述配置信息的更新信息的格式、文件类型、具体内容并不做限定。在实际应用中，所述配置信息和所述配置信息的更新信息可以是：界面模板、全局应用设置信息、场景引擎规则、菜单信息、追加内容下载包、应用补丁，等等。

S102：将所述服务请求发送给所述服务端。

在本申请实施例中，可以通过步骤S101中提到的所述的至少一个服务接口，也可以通过服务端提供的其他服务接口，将服务请求发送给所述服务端。

在本申请实施例中，服务端在接收到服务信息后，可以根据服务信息中包含的所述状态信息，向客户端返回更新指示信息，以便于客户端根据更新指示信息，获取配置信息的更新信息。

所述更新指示信息可以用于指示是否有配置信息的更新信息，以及有哪些更新信息，等等。例如，所述更新指示信息可以是所述配置信息的更新信息，可以是所述配置信息的更新信息的标识，也可以是所述配置信息的更新信息的下载地址，等等。

在本申请实施例中，对于客户端根据更新指示信息，获取配置信息的更新信息这一步骤，可以有多种实施方式。

例如，当更新信息的数据量较少时，可以将更新信息携带在更新指示信息中，则客户端可以从更新指示信息中直接获取到更新信息，这样的话，可以降低客户端与服务端之间的消息交互次数，节省网络资源。

又例如，当更新信息的数据量较多时，可以将更新信息的标识携带在更新指示信息，后续客户端可以根据更新信息的标识，在网络空闲时或是其他指定时刻从服务端下载更新信息，这样的话，可以提高获取更新信息的成功率，也可以减轻客户端的负担。

通过上述方法，客户端可以利用已有的任一服务接口获取配置信息的更新信息，而不需要为了获取该更新信息单独维护一个定时线程，因此，可以减轻 客户端的负担，其中，所述负担包括对处理器资源、内存资源、电量资源等资源的消耗。

不仅如此，由于上述方法可以将查询以及获取配置信息的更新信息这一动作的触发时机，融入到客户端与服务端提供的任一服务接口的交互过程中，因此，没有增加额外的针对服务端的网络调用，而且也可以比较及时地获取更新信息，而不用像在现有技术中需要等待定时线程触发获取更新信息。

例如，用户使用客户端上的即时通讯应用发送即时通讯消息(向服务端请求获取“传输通讯消息”这项服务)时，可以触发客户端向服务端发送服务请求，服务端成功响应该服务请求后，客户端不仅可以获取到服务端提供的“传输通讯消息”这项服务，还可以获得配置信息的更新信息。

需要说明的是，以上只是用“传输通讯消息”这项服务举例说明，在实际应用中，客户端在获取任一项服务的过程中，也可以通过上述方法，获得配置信息的更新信息，或者，完成其他额外的事务。

为了便于理解，下面对图1中的步骤进一步地详细说明。

在本申请实施例中，服务请求中包含的所述状态信息可以是：可用于让服务端确定客户端上的配置信息是否存在更新信息的任意信息。在实际应用中，该状态信息可以是该配置信息的最新更新时间，也可以是该配置信息的标识，等等。以所述配置信息是界面模板为例进行说明。

假定客户端上的配置信息包括两个界面模板，名称分别为“界面模板1”、“界面模板2”，其中，客户端下载到这两个界面模板的时间是2014年1月1日。该配置信息的状态信息可以是“界面模板1”和“界面模板2”，服务端根据该状态信息可以查询自身上是否保存有客户端上没有的界面模板；类似的，该配置信息的状态信息也可以是时间2014年1月1日，服务端根据该时间可以查询服务端在该时间以后更新的界面模板，也即，客户端上没有的界面模板。进而服务端生成并客户端返回更新指示信息，该更新指示信息可以是所述更新的界面模板，或所述更新的界面模板的名称，等等。

在本申请实施例中，状态信息可以以不同的方式包含在服务请求中。

例如，状态信息通过所述服务请求的预定字段进行保存，包含在所述服务请求中，或者，可以将状态信息写入文件或消息中，由服务请求携带写入了状态信息的文件或消息。前一种方案实现成本较小，后一种方案可以对状态信息的文件或消息进一步地加密等操作，以提高信息安全性，可以根据实际应用场景，选择更适用的方案。在本申请实施例中，主要是基于前一种方案进行说明的。

在本申请实施例中，步骤S101中的接口调用请求可以包含所述至少一个服务接口的接口函数，以及所述接口函数的调用参数。

对于步骤S101，根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求，具体可以包括：确定所述接口调用请求对应的代理实现类，其中，所述代理实现类是根据所述接口函数和所述预定字段生成的；根据所述代理实现类、所述接口函数的调用参数和所述状态信息，生成包含所述状态信息的服务请求。需要说明的是，本申请实施例对所述预定字段的名称、字节数等信息并不做限定。

在本申请实施例中，不同的接口调用请求可以对应于不同的代理实现类，通过代理实现类可以在客户端上的原有接口的功能的基础上修改或扩展，且不影响原有接口的逻辑。

服务请求用于向服务端请求获取：该接口函数对应的服务，以及客户端上的配置信息的更新信息。本申请实施例对生成代理实现类的生成方式并不做限定，可以是客户端上预设的代理单元生成的，也可以是由客户端上已有任一单元生成的。

服务请求可以是一个请求；也可以是由至少两个子请求组成的请求，其中，某个子请求可以用于请求获取该服务，另一个子请求可以用于请求获取该更新信息，等等。对于后一种情况，在将服务请求发送给服务端的过程中，将该服 务请求包含的至少两个子请求同时发送给服务端，也可以按照预定发送顺序，将至少两个子请求分别发送给服务端，本申请实施例对所述预定发送顺序并不做限定。

进一步的，根据所述代理实现类、所述接口函数的调用参数和所述状态信息，生成包含所述状态信息的服务请求，具体可以包括：根据所述代理实现类，对所述接口函数的调用参数进行转换，生成服务参数；获取所述状态信息，并通过所述预定字段保存所述状态信息；根据所述代理实现类、所述服务参数和保存了所述状态信息的所述预定字段，生成包含所述状态信息的服务请求。

所述转换过程中涉及的操作包括但不限于：映射操作、封装操作、参数修改操作、权限修改操作、等等。本申请实施例对客户端上负责管理、维护以及使用所述预定字段的单元并不做限定，可以由代理单元负责，也可以由其他单元负责。

在实际应用中，当客户端上预设有代理单元时，可以由该代理单元实现步骤S101，这样的话，便于客户端管理各接口调用请求的发送过程。需要说明的是，本申请实施例对于所述代理单元的实现方式并不做限定。为了便于理解，下面对在一种实际应用场景下，可以采用的代理单元的实现方式，以及代理单元的工作方式举例进行说明。

代理单元在客户端上运行，假定在服务端提供的某服务接口中定义有两个接口函数，如下所示：

如图2所示，代理单元的实现方式和工作方式具体可以包括以下步骤(各所述步骤的执行主体可以为该代理单元)：

S201：构造工厂类，其中，所述工厂类中包含用于创建代理实现类的函数。

调用代码举例说明：

TPSClient client＝TPSClient.getTpsClient()；

ItemQueryService service＝

Client.getService(“com.yunos.item.service.ItemQueryService”,ItemQueryServ ice.class)；

List<ItemEntity>list＝service.queryTopItemList()；

所述工厂类可以为TPSClient，所述函数可以为TPSClient.getTpsClient()。

S202：根据所述函数，为服务接口创建对应的代理实现类。

所述服务接口可以为ItemQueryService，创建的该代理实现类也即为针对该服务接口的接口调用请求对应的代理实现类。

S203：根据接收到的接口调用请求，在所述代理实现类中，构造请求对象，其中所述请求对象用于传递与针对服务接口的接口调用请求相关的信息。

继续调用代码举例说明：

Request req＝new Request()；

req.setServiceName(service)；

req.setMethod(method.getName())；

req.setParameters(GsonUtil.toJson(args))；

其中，所述请求对象可以是req，所述相关的信息可以是调用参数、接口 函数等。

S204：将接口调用请求包含的调用参数进行转换后，保存在所述请求对象中。

具体的，可以将调用参数转换为超文本传输协议(HyperText Transfer Protocol，http)请求参数，其中，parameters中是对调用参数转换生成的json字符串。

S205：获取客户端上的配置信息的状态信息。

以所述状态信息为配置信息的最新更新时间为例进行说明，可以将最新更新时间通过预定字段(如gmtFlag字段)进行保存和传递。另外，若客户端并未记录状态信息，则后续可以向服务端发送默认值，如0。

S206：根据代理实现类、请求参数和状态信息，生成包含该状态信息的服务请求。

S207：将服务请求通过服务接口，发送给服务端。

服务端通过服务接口接收到服务请求后，一方面可以根据所述服务请求，解析出接口调用请求，进而通过该服务接口的实现单元为客户端返回对应的服务；另一方面，可以根据服务请求包含的状态信息，确定更新指示信息并返回给客户端，以便于客户端根据该更新指示信息获取配置信息的更新信息。

因此，对于步骤S102，在将所述服务请求发送给所述服务端，还可以执行如下步骤：接收所述服务端根据所述服务请求中包含的所述状态信息，返回的更新指示信息；根据所述更新指示信息，获取所述配置信息的更新信息。

例如，在状态信息是配置信息的最新更新时间的情况下，服务端接收到包含配置信息的最新更新时间(为了便于描述，称为：客户端更新时间)的服务请求后，可以将客户端更新时间，与服务端保存的配置信息的最新更新时间(为了便于描述，称为：服务端更新时间)进行比较。若服务端更新时间大于客户端更新时间，则可以表示服务端保存有客户端尚未获得的更新信息，进而服务端可以将该更新信息或该更新信息的标识作为更新指示信息，返回给客户端； 若服务端更新时间不大于客户端更新时间，则可以表示服务端未保存有客户端尚未获得的更新信息，也即，客户端上的配置信息已是最新，当前无需更新，在这种情况下，服务端向客户端返回的更新指示信息也可以用于告知客户端无需更新配置信息。

在本申请实施例中，所述更新指示信息可以包括：所述配置信息的更新信息的标识，或者，所述配置信息的更新信息；等等。

当所述更新指示信息包括所述配置信息的更新信息的标识时，根据所述更新指示信息，获取所述配置信息的更新信息，具体可以包括：根据所述配置信息的更新信息的标识，从所述服务端获取所述配置信息的更新信息。

当所述更新指示信息包括所述配置信息的更新信息时，根据所述更新指示信息，获取所述配置信息的更新信息，具体可以包括：从所述更新指示信息中，获取所述配置信息的更新信息。

以上是从客户端角度，说明的本申请实施例提供的信息处理方法，基于同样的思路，本申请实施例还提供了对应于图1的另一种信息处理方法，所述另一种信息处理方法是从服务端角度进行说明的，如图3所示。

图3为本申请实施例提供的另一种信息处理方法的过程，所述另一种信息处理方法的执行主体可以是：应用的服务端，或者搭载有所述服务端的终端或服务器。所述的执行主体并不构成对本申请的限定，为了便于描述，图3对应的各实施例均以执行主体是所述服务端为例进行说明。

图3中的过程具体可以包括以下步骤：

S301：接收客户端发送的服务请求，其中，所述服务请求包括所述客户端针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息。

S302：根据所述服务请求中包含的所述状态信息，确定并向所述客户端返回更新指示信息，所述更新指示信息用于指示所述配置信息的更新信息。

在本申请实施例中，服务端接收到服务请求后，一方面可以由接收服务请 求的服务接口对应的服务接口实现单元返回对应的服务；另一方面，可以由服务请求包含的状态信息，确定更新指示信息，或者，该服务接口也可以将该状态信息传递给服务端上预设的消息处理单元，由于该消息处理单元根据该状态信息，确定更新指示信息并返回给客户端，以便于客户端根据该更新指示信息，获取配置信息的更新信息。

通过上述方法，客户端可以利用服务端提供的任一服务接口，获取配置信息的更新信息，而不需要为了获取该更新信息单独维护一个定时线程，因此，可以减轻客户端的负担，也可以减少服务端与客户端之间的交互。

为了便于理解，下面对图3中的步骤进一步地详细说明。

在本申请实施例中，在服务端上预设有消息处理单元时，对于步骤S302，根据所述服务请求中包含的所述状态信息，确定更新指示信息，具体可以包括：所述服务请求中包含的所述状态信息传递给所述服务端上预设的消息处理单元，以便于所述消息处理单元根据所述状态信息，确定更新指示信息。

需要说明的是，本申请实施例对“将所述状态信息传递给所述服务端上预设的消息处理单元”所采用的传递方式并不做限定。在实际应用场景下，服务接口获得该状态信息后，可以构造一个包含该状态信息的消息，并将该消息发送给消息处理单元。进一步的，该消息可以以异步方式发送给消息处理单元，在这种情况下，所述消息处理单元具体可以是异步消息处理单元。

服务接口除了可以将状态信息发送给消息处理单元以外，还可以将诸如客户端的标识等相关信息发送给消息处理单元，以便于消息处理单元可以将生成的更新指示信息正确地返回给客户端。下面对更新指示信息的确定方法进一步地说明。

前面已经提到，所述状态信息可以包括：所述客户端上的配置信息的最新更新时间，或者，所述客户端上的配置信息的标识。

则当所述状态信息包括所述客户端上的配置信息的最新更新时间时，可以按照如下方法，根据所述状态信息，确定更新指示信息：当确定所述服务端上 的配置信息的最新更新时间大于所述客户端上的配置信息的最新更新时间时，确定所述服务端在所述客户端上的配置信息的最新更新时间之后，更新的所述配置信息的更新信息；根据所述更新信息生成更新指示信息，其中，所述更新指示信息中包含所述更新信息的标识或所述更新信息；

类似的，当所述状态信息包括所述客户端上的配置信息的标识时，可以按照如下方法，根据所述状态信息，确定更新指示信息：当确定所述服务端上存在对应的标识与所述客户端上的配置信息的标识不相同的配置信息时，将确定出的配置信息作为所述客户端上的配置信息的更新信息；根据所述更新信息生成更新指示信息，其中，所述更新指示信息中包含所述更新信息的标识或所述更新信息。

在本申请实施例中，服务接口和/或消息处理单元可以通过长连接推送(Push)消息通道，将更新指示信息返回给客户端，其中，所述长连接Push消息通道可以只由一个应用使用，也可以由多个应用公用。进一步的，当更新指示信息中包含更新信息的标识、且未包含该更新信息时，则客户端尚未直接获取到更新信息，客户端可以在接收到更新指示信息后，再根据更新信息的标识，通过该长连接Push消息通道，或者，其他的通道，从服务端获取更新信息。

当客户端通过所述其他的通道获取更新信息时，可以降低长连接Push消息通道的信息传送负担，防止自己长时间占用长连接Push消息通道，而且，客户端和服务端还可以针对所述其他的消息通道，实现指定的安全机制，以提高客户端获取更新信息的可靠性。

以上为分别从客户端角度和服务端角度，对本申请实施例提供的信息处理方法的说明。为了便于理解，本申请实施例还提供了在一种实际应用场景下，实施所述信息处理方法时，客户端和服务端的交互示意图，如图4所示，所述交互具体可以包括以下步骤：

S401：客户端接收服务获取指令。

S402：客户端根据所述服务获取指令，生成针对服务端提供的至少一个服务接口的接口调用请求。

S403：客户端将接口调用请求传递给客户端上预设的代理单元。

S404：代理单元获取客户端上的配置信息的状态信息。

S405：代理单元根据接口调用请求和状态信息，生成包含该状态信息的服务请求。

S406：代理单元通过服务接口，将服务请求发送给服务端。

S407：服务接口通过对应的服务接口实现单元对服务请求进行处理，以向客户端返回对应的服务。

S408：服务接口将服务请求包含的该状态信息，通过异步消息发送给服务端上的异步消息处理单元。

S409：异步消息处理单元当确定服务端更新时间大于该状态信息中包含的客户端更新时间时，确定服务端在客户端更新时间后更新的配置信息的更新信息的标识，作为更新指示信息。

S410：异步消息处理单元将更新指示信息通过长连接Push通道返回给客户端。

S411：客户端根据更新指示信息中的更新信息的标识，从服务端获取配置客户端上的配置信息的更新信息。

进一步的，本申请实施例还提供了在一种实际应用场景下，适用于实施所述信息处理方法的系统结构示意图，如图5所示。

在图5中，客户端和服务端上分别包含有若干个单元，需要说明的是，图5只是一种举例说明的系统结构示意图，在实际应用中，图5中的各单元也可以进行合并和/或分拆，本申请实施例并不做限定。

在图5中，公共请求代理单元和公共返回代理单元可以构成本申请实施例中所述的代理单元，系统的工作过程如下：

服务接口调用单元在接收到服务获取指令后，将对应的接口函数和调用参 数传递给公共请求代理单元；

公共请求代理单元根据该接口函数、该调用参数，以及客户端上的配置信息的状态信息，生成服务请求；

公共请求代理单元将服务请求通过对应的服务接口，发送给服务端；服务接口通过服务接口实现单元，对服务请求进行处理，并向客户端返回对应的服务；

服务接口根据服务请求包含的状态信息，生成包含有该状态信息的消息，并以异步方式将该消息传递给异步消息处理单元；

异步消息处理单元根据接收到的该消息，当确定服务端上存在配置信息的更新信息时，将该更新消息的标识作为更新指示信息，通过长连接Push消息通道，发送给客户端；

客户端通过Push消息接收单元接收到更新指示信息，根据更新消息的标识，通过配置信息查询接口调用单元与服务端的配置信息查询接口实现单元，获取到配置信息的更新信息；

配置信息查询接口调用单元将配置信息的更新信息传递给公共返回代理单元，以便于客户端更新配置信息。其中，公共返回代理单元可以用于记录配置信息的状态信息。

针对本申请实施例提供的信息处理方法，基于同样的思路，本申请实施例还提供相应的信息处理装置，如图6、图7所示。

图6为本申请实施例提供的对应与图1的信息处理装置结构示意图，具体包括：

生成模块601，用于根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求；

发送模块602，用于将所述服务请求发送给所述服务端。

通过上述装置，客户端可以利用已有的任一服务接口获取配置信息的更新 信息，而不需要为了获取该更新信息单独维护一个定时线程，因此，可以减轻客户端的负担。

所述状态信息包括：所述客户端上的配置信息的最新更新时间，或者，所述客户端上的配置信息的标识。

所述状态信息通过所述服务请求的预定字段进行保存，包含在所述服务请求中。

所述接口调用请求包含所述至少一个服务接口的接口函数，以及所述接口函数的调用参数；

所述生成模块601具体用于：确定所述接口调用请求对应的代理实现类，其中，所述代理实现类是根据所述接口函数和所述预定字段生成的；根据所述代理实现类、所述接口函数的调用参数和所述状态信息，生成包含所述状态信息的服务请求。

所述生成模块601具体用于：根据所述代理实现类，对所述接口函数的调用参数进行转换，生成服务参数；获取所述状态信息，并通过所述预定字段保存所述状态信息；根据所述代理实现类、所述服务参数和保存了所述状态信息的所述预定字段，生成包含所述状态信息的服务请求。

所述装置还可以包括：

获取模块603，用于在所述发送模块601将所述服务请求发送给所述服务端之后，接收所述服务端根据所述服务请求中包含的所述状态信息，返回的更新指示信息；根据所述更新指示信息，获取所述配置信息的更新信息。

所述更新指示信息包括：所述配置信息的更新信息的标识，或者，所述配置信息的更新信息；

当所述更新指示信息包括所述配置信息的更新信息的标识时，所述发送模块具体用于：根据所述配置信息的更新信息的标识，从所述服务端获取所述配置信息的更新信息；

当所述更新指示信息包括所述配置信息的更新信息时，所述发送模块具体 用于：从所述更新指示信息中，获取所述配置信息的更新信息。

具体的上述如图6所示的装置可以位于客户端上。

图7为本申请实施例提供的对应于图3的信息处理装置结构示意图，具体包括：

接收模块701，用于接收客户端发送的服务请求，其中，所述服务请求包括所述客户端针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息；

返回模块702，用于根据所述服务请求中包含的所述状态信息，确定并向所述客户端返回更新指示信息，所述更新指示信息用于指示所述配置信息的更新信息。

通过上述装置，客户端可以利用已有的任一服务接口获取配置信息的更新信息，而不需要为了获取该更新信息单独维护一个定时线程，因此，可以减轻客户端的负担。

所述返回模块702具体用于：将所述服务请求中包含的所述状态信息传递给所述服务端上预设的消息处理单元，以便于所述消息处理单元根据所述状态信息，确定更新指示信息。

所述状态信息包括：所述客户端上的配置信息的最新更新时间，或者，所述客户端上的配置信息的标识；

当所述状态信息包括所述客户端上的配置信息的最新更新时间时，所述返回模块702按照如下方法，根据所述状态信息，确定更新指示信息：

当确定所述服务端上的配置信息的最新更新时间大于所述客户端上的配置信息的最新更新时间时，确定所述服务端在所述客户端上的配置信息的最新更新时间之后，更新的所述配置信息的更新信息；根据所述更新信息生成更新指示信息，其中，所述更新指示信息中包含所述更新信息的标识或所述更新信息；

当所述状态信息包括所述客户端上的配置信息的标识时，所述返回模块 702按照如下方法，根据所述状态信息，确定更新指示信息：

当确定所述服务端上存在对应的标识与所述客户端上的配置信息的标识不相同的配置信息时，将确定出的配置信息作为所述客户端上的配置信息的更新信息；根据所述更新信息生成更新指示信息，其中，所述更新指示信息中包含所述更新信息的标识或所述更新信息。

具体的上述如图7所示的装置可以位于服务端上。

基于同样的思路，本申请实施例还提供相应的终端，如图8、图9所示。

图8为本申请实施例提供的对应于图1的终端示意图，具体包括：

存储器801，用于存储处理器可执行指令；

处理器802，耦合到所述存储器，用于读取所述存储器存储的可执行指令，作为响应，执行如下操作：根据客户端上生成的、针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息，生成包含所述状态信息的服务请求；将所述服务请求发送给所述服务端。

图9为本申请实施例提供的对应于图3的终端示意图，具体包括：

存储器901，用于存储处理器可执行指令；

处理器902，耦合到所述存储器，用于读取所述存储器存储的可执行指令，作为响应，执行如下操作：接收客户端发送的服务请求，其中，所述服务请求包括所述客户端针对服务端提供的至少一个服务接口的接口调用请求，以及所述客户端上的配置信息的状态信息；根据所述服务请求中包含的所述状态信息，确定并向所述客户端返回更新指示信息，所述更新指示信息用于指示所述配置信息的更新信息。

需要说明的是，在实际应用中，图9中的终端可以作为服务器使用。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读 存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。