CN105450718A - 界面更新方法及客户端 - Google Patents

Abstract

本申请提供一种界面更新方法及客户端。方法包括：客户端从服务端获取更新客户端提供的用于展示服务信息的界面所需的服务更新数据；根据服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据；第一服务数据包括：当前界面展现的服务类目对应的服务分组数据，以及当前界面展现在服务类目下的服务视图对应的服务的详情数据；服务类目对应的服务分组数据包括：属于服务类目的服务的标识；根据第二服务数据，形成新界面。本申请技术方案可以简化更新界面的操作，提高更新界面的效率。

Description

界面更新方法及客户端

【技术领域】

本申请涉及互联网技术领域，尤其涉及一种界面更新方法及客户端。

【背景技术】

用户可以在其终端上安装各种应用客户端，不同应用客户端具有不同风格的界面。应用客户端可以提供一界面，并通过界面向用户显示其所提供的服务。应用客户端的界面一般是固定的，可以通过预置于安装包中的布局配置文件来设置。

但是，随着应用客户端可以提供的服务的升级和多样性，固定不变的界面将无法满足服务多样性的需求。面对大规模服务数据的更新、排序、删除和替换等需求，服务端只能通过不断发布应用客户端的升级包，以供用户通过手动下载并安装升级包，进而通过升级包中的布局配置文件来改变应用客户端的界面。这种方式由于需要用户手动下载并安装升级包，操作不便，效率较低。

【发明内容】

本申请的多个方面提供一种界面更新方法及客户端，用以简化更新界面的操作，提高更新界面的效率。

本申请的一方面，提供一种界面更新方法，包括：

客户端从服务端获取更新所述客户端提供的用于展示服务信息的界面所需的服务更新数据；

所述客户端根据所述服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据；所述第一服务数据包括：所述当前界面展现的服务类目对应的服务分组数据，以及所述当前界面展现在所述服务类目下的服务视图对应的服务的详情数据；所述服务类目对应的服务分组数据包括：属于所述服务类目的服务的标识；

所述客户端根据所述第二服务数据，形成所述新界面。

本申请的另一方面，提供一种客户端，包括：

获取模块，用于从服务端获取更新所述客户端提供的用于展示服务信息的界面所需的服务更新数据；

更新模块，用于根据所述服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据；所述第一服务数据包括：所述当前界面展现的服务类目对应的服务分组数据，以及所述当前界面展现在所述服务类目下的服务视图对应的服务的详情数据；所述服务类目对应的服务分组数据包括：属于所述服务类目的服务的标识；

界面模块，用于根据所述第二服务数据，形成所述新界面。

在本申请中，客户端从服务端获取服务更新数据，以对客户端提供的用于展示服务信息的界面进行更新；其中，当前界面展示有至少一个服务类目，并在每个服务类目下展示有具体的服务视图，第一服务数据包括当前界面展示的服务类目对应的服务分组数据，以及当前界面展现在服务类目下的服务视图对应的服务的详情数据，根据所获取的服务更新数据，对形成当前界面使用的第一服务数据进行更新，以获得第二服务数据，根据第二服务数据形成新界面。由此可见，在本申请中，客户端可以自动完成界面更新，不需要用户手动下载并安装升级包，界面更新操作相对简单，有利于提高更新界面的效率。

【附图说明】

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的界面更新方法的流程示意图；

图2为本申请一实施例提供的客户端的当前界面的示意图；

图3为本申请一实施例提供的客户端的新界面的示意图；

图4为本申请一实施例提供的客户端的结构示意图。

【具体实施方式】

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

图1为本申请一实施例提供的界面更新方法的流程示意图。如图1所示，该方法包括：

101、客户端从服务端获取更新客户端提供的用于展示服务信息的界面所需的服务更新数据。

102、客户端根据服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据；其中，第一服务数据包括当前界面展现的服务类目对应的服务分组数据，以及当前界面展现在服务类目下的服务视图对应的服务的详情数据；服务类目对应的服务分组数据包括属于该服务类目的服务的标识。

103、客户端根据第二服务数据，形成新界面。

本实施例提供一种界面更新方法，本实施例提供的方法可以由客户端来执行，该客户端可以是任何可以提供界面且需要进行界面调整的客户端，例如可以是浏览器或应用(Application，APP)客户端。其中，本实施例提供的方法流程具体如下：

服务端存储有需要通过客户端提供的界面向用户展现的服务信息。需要向用户展现的服务信息，会随着服务提供商所提供的服务的变化而变化。例如，若有新的服务出现，则需要展现给用户的服务信息中需要增加新服务的信息；若有某个服务被取消，则需要展现给用户的服务信息中需要删除被取消的服务的信息；若有某个服务进行了升级，则需要展现给用户的服务信息中需要增加由于服务升级所增加的数据。

举例说明，上述服务可以是搜美食服务、看电影服务、新闻服务、买彩票服务、阅读服务、品段子服务、美图服务、公交查询服务或天气查询服务等。

客户端从服务端获取服务更新数据，服务更新数据是指更新客户端提供的用于向用户展现服务信息的界面所需的数据。其中，界面所展现的内容和展现方式等可以决定界面更新所需的数据，即服务更新数据的内容可由界面展现的内容和展现方式等决定。

在本实施例中，为便于更加清晰的向用户展现服务信息，通过对服务进行分类，将相关联的服务归到同一服务类目下。本实施例对服务分类的标准不做限定，也就是说对服务类目的定义以及每个服务类目应该包括的服务均不做限定。

基于对服务分类的思路，客户端提供的界面需要以服务类目+服务视图的方式展现服务信息。在本实施例中，客户端的当前页面展现有服务类目，并在该服务类目下展现有具体的服务视图。当前页面可以展现一个服务类目，也可以展现至少两个服务类目。服务类目下可以展现有一个服务视图，也可以展现有至少两个服务视图。在界面上，具体以服务视图的形式展现服务信息。服务视图上可以展现有服务的图片、运营图片、标题、副标题、背景色以及服务视图对应的服务的访问入口信息，其中，根据服务提供方式的不同，该服务的访问入口信息也有所不同，例如，若该服务时以网页形式提供的，则该访问入口信息可以是跳转至该服务的统一资源定位符(UniformResoureLocator，URL)地址，若该服务是以本地APP或WEBAPP形式提供的，则该访问入口信息可以是相应APP的调用接口信息等。如图2所示，为当前页面展现的一种服务类目以及该服务类目下的服务视图。该服务视图中可以包括跳转至相应服务的访问入口，在图2中，所展现的服务类目为娱乐，该娱乐类目下包括搜美食服务视图、看电影服务视图和买彩票服务视图。当用户点击服务视图时，则跳转至相应的服务，继续以图2为例，如果用户点击搜美食服务视图，则可以跳转至搜美食的服务，具体地，该服务可以以多种方式提供给用户，例如，可以是网页形式，本地APP形式、WEBAPP形式等。值得说明的是，服务视图可以是彩色的，并不限于图2所示的灰色。

基于上述，形成当前界面所使用的第一服务数据包括：当前界面展现的服务类目对应的服务分组数据，以及当前界面展现在该服务类目下的服务视图对应的服务的详情数据。其中，服务类目对应的服务分组数据包括：属于该服务类目的服务的标识。服务的详情数据主要是指生成该服务对应的服务视图所需的一些配置数据，例如服务的图片、运营图片、标题、副标题、跳转URL等。

基于上述第一服务数据，服务更新数据主要是与服务的详情数据和/或服务分组数据相关的更新数据。

客户端在获取服务更新数据后，根据服务更新数据对形成当前界面使用的第一服务数据进行更新，获得第二服务数据。之后，根据第二服务数据形成新的界面。

值得说明的是，第二服务数据也包括：服务分组数据和服务的详情数据，具体来说包括：需要在新界面上展现的服务类目对应的服务分组数据，以及需要在该需要展现的服务类目下展现的服务视图对应的服务的详情数据。

基于上述，客户端具体可以根据第二服务数据包括的服务分组数据，在新界面上展现所述需要展现的服务类目，并根据第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，在所述需要展现的服务类目下展现需要展现的服务视图，进而获得新界面。

进一步，客户端可以通过触发回调方式，以根据第二服务数据包括的服务分组数据，在新界面展现需要展现的服务类目，并根据第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，在需要展现的服务类目下展现需要展现的服务视图。

具体的，客户端可以包括：数据模块和用户界面(UserInterface，UI)模块。数据模块主要用于从服务端获取更新客户端提供的用于展示服务信息的界面所需的服务更新数据，并根据服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据。此处的数据模块相当于后续客户端装置实施例中的获取模块和更新模块，但不限于此。

UI模块可以预先注册一回调函数，该回调函数可以通过回调函数名来标识。数据模块在获得第二服务数据后，可以发送一广播消息，并在广播消息中携带用于标识UI模块预先注册的回调函数的回调函数名；UI模块接收到广播消息后，从广播消息中获取回调函数名，通过该回调函数名所标识的回调函数，主动获取第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，之后根据第二服务数据包括的服务分组数据，在新界面展现需要展现的服务类目，并根据第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，在需要展现的服务类目下展现需要展现的服务视图。

具体的，UI模块可以根据第二服务数据包括的服务分组数据，确定每个服务类目下的服务的详情数据，根据每个服务的详情数据生成服务视图，进一步还可以按照每个服务类目下服务之间的先后顺序来排列服务视图，最终按照排列好的顺序在新界面上展现各服务视图。在图2所示基础上，如图3所示，为新界面上展现一种服务类目以及该服务类目下的服务视图。图3所示服务视图中可以包括跳转到相应服务的访问入口，在图3中，所展现的服务类目为娱乐，该娱乐类目下包括买彩票服务视图、看电影服务视图、阅读服务视图、新闻服务视图、品段子服务视图和美图服务视图。当用户点击服务视图时，则跳转至相应的服务，继续以图3为例，如果用户点击买彩票服务视图，则可以跳转至买彩票的服务，具体地，该服务可以以多种方式提供给用户，例如，可以是网页形式，本地APP形式、WEBAPP形式等。与图2相比，图3所示新界面少展现原来一个服务视图，同时多展现了几个新的服务视图。值得说明的是，服务视图可以是彩色的，并不限于图3所示的灰色。

在本实施例中，客户端从服务端获取服务更新数据，以对客户端提供的用于展示服务信息的界面进行更新；根据所获取的服务更新数据，对形成当前界面使用的第一服务数据进行更新，以获得第二服务数据，根据第二服务数据形成新界面。由此可见，在本实施例中，客户端可以自动完成界面更新，不需要用户手动下载并安装升级包，界面更新操作相对简单，有利于提高更新界面的效率。

另外，本实施例提供的方法不仅简化了界面更新操作，提高了更新界面的效率，而且可以根据服务的升级和多样性等，自定义调整界面布局，优化界面布局方法，增强了客户端跟随服务变化的应变能力，为用户提供更加个性化、定制化的界面布局，有利于提供更加丰富的服务信息。

在实际应用中，服务端可以维护两种类型的数据：一种是服务的详情数据，一种是服务分组数据。

对于每个服务，服务端可以存储该服务的详情数据，这里的详情数据主要是指生成该服务对应的服务视图所需的一些配置数据，一般包括但不限于以下数据：服务的标识(service_id)、服务的图片、运营图片、背景、服务的创建时间、服务的修改(或更新)时间、服务提供的访问入口(即跳转URL)及访问类型(例如是否需要登录)、服务提供商等等。其中，服务的标识可以唯一标识一个服务；服务的图片、背景、运营图片等可以通过徽标(logo)字段进行设置，该徽标字段可以是个Java脚本对象标记(JavaScriptObjectNotation，JSON)值，若配置了关于服务的各种图片，这些图片字段可以是以content://、http://、或assets://等方式标识的图片地址。如下所示为服务端定义服务的详情数据的一种代码示例：

本申请中，客户端提供的界面主要以服务类目+服务类目下的服务视图的格式进行展示。因此，服务端可以对每个服务类目配置一个服务分组数据。对于服务分组数据，服务端定义了一类相关联的服务，这种关联关系是可以根据具体的业务场景灵活控制的。服务分组数据包括但不限于以下数据：服务分组的名称和标识(id)以及服务标识列表，该服务标识列表用于存储属于该服务分组数据对应的服务类目的服务的标识。如下所示为服务端定义服务分组数据的一种代码示例：

基于上述，客户端从服务端获取更新客户端提供的用于展示服务信息的界面所需的服务更新数据的一种方式包括：

客户端向服务端发送同步请求，该同步请求包括：客户端上次获取服务更新数据的时间戳；

服务端根据同步请求中的时间戳，从本地存储的服务分组数据和本地存储的服务的详情数据中，获取修改时间在该时间戳之后的数据作为服务更新数据，并返回给客户端；

客户端接收服务器返回的服务更新数据。

在该实施方式中，要求服务端能够记录服务的详情数据和服务分组数据的修改时间，以便于向客户端准确提供服务更新数据。

另外，在该实施方式中，无论是服务的详情数据还是服务分组数据，均是以增量同步方式进行同步的，即每次同步服务的详情数据和分组服务数据都只获取增量，这样可以很好的节省流量，而且可以确保客户端在网络不稳定的情况下能够成功接收到服务更新数据。

在另一可选实施方式中，考虑到服务分组数据比较简单、数据量较少而且变化可能性较小，所以客户端可以采用全量同步方式，即每次同步服务分组数据获取全部服务分组数据，且可以间隔一定时间请求一次，不用太过频繁的请求服务分组数据，这样可以减轻客户端和服务端的处理负担，节约流量等。在该可选实施方式中，对于服务的详情数据，优选的仍采用增量同步方式，即客户端通过在同步请求中携带上次请求服务更新数据的时间戳，使得服务端返回仅在时间戳之后发生变化的服务的详情数据或详情数据中发生变化的那部分数据。

在一可选实施方式中，当前界面展现的服务类目对应的服务分组数据除了包括属于该服务类目的服务的标识之外，还可以包括：表征属于该服务类目的服务之间的先后顺序的第一顺序信息。

值得说明的是，上述用于表征服务之间的先后顺序的第一顺序信息可以是显式信息，例如该信息可以是类似“根据服务的标识(ID)由大到小或由小到大的顺序”或者“根据服务的上线时间确定的顺序”这样的显式描述。或者，上述用于表征服务之间的先后顺序的第一顺序信息也可以是一种隐式信息，例如可以通过服务分组数据中服务的标识的排列顺序来表征服务之间的先后顺序。

基于上述，服务更新数据包括以下至少一种：

在时间戳之后新增的服务分组数据和属于新增的服务分组数据对应的服务类目的服务的详情数据；

用于表征在时间戳之后被删除的服务分组数据的第一删除标记信息，第一删除标记信息可以包括被删除的服务分组数据的标识和删除标记；

用于表征在时间戳之后被调整的服务分组数据之间的先后顺序的第二顺序信息；

在时间戳之后增加的服务的详情数据和增加的服务所属的服务类目对应的服务分组数据；

用于表征在时间戳之后被删除的服务的详情数据的第二删除标记信息，例如第二删除标记信息可以是被删除的服务的标识；

用于表征在时间戳之后被更新的第一顺序信息的第三顺序信息。

被更新的第一顺序信息表示：属于当前界面展现的服务类目的服务之间的、在时间戳之后经过调整的先后顺序，也就是说，这里的第三顺序信息实际用于表征属于当前界面展现的服务类目的服务之间的、在时间戳之后经过调整的先后顺序。

下面以几种服务更新数据为例，详细说明对形成当前界面使用的第一服务数据进行更新，获得第二服务数据的实施过程。

若服务更新数据包括：在时间戳之后新增的服务分组数据和属于新增的服务分组数据对应的服务类目的服务的详情数据。

则客户端具体可以将上述新增的服务分组数据和属于上述新增的服务分组数据对应的服务类目下的服务的详情数据，添加到第一服务数据中，获得第二服务数据。第二服务数据与第一服务数据相比，增加了一个服务分组数据，并增加了该服务分组数据中各服务的标识所标识的服务(这些服务也就是属于该服务分组对应的服务类目的服务)的详情数据。新界面与当前界面相比，多展现一个服务类目以及在该服务类目下展现的服务视图。

若服务更新数据包括：用于表征在时间戳之后被删除的服务分组数据的第一删除标记信息。

则客户端可以根据第一删除标记信息，从第一服务数据中删除第一删除标记信息所标识的服务分组数据和属于第一删除标记信息所标识的服务分组数据对应的服务类目的服务的详情数据，以获得第二服务数据。其中，属于第一删除标记信息所标识的服务分组数据对应的服务类目的服务，也就是第一删除标记信息所表示的服务分组数据中各服务的标识所标识的服务。第二服务数据与第一服务数据相比，少了一个服务分组数据，以及该服务分组数据中各服务的标识所标识的服务的详情数据。新界面与当前界面相比，少展现了一个服务类目以及该服务类目下的服务视图。

若服务更新数据包括：时间戳之后增加的服务的详情数据和增加的服务所属的服务类目对应的服务分组数据。

则客户端将上述增加的服务的详情数据添加到第一服务数据中，并用上述增加的服务所属的服务类目对应的服务分组数据替换原来的服务分组数据，以获得第二服务数据。第二服务数据与第一服务数据相比，主要增加了一个服务的详情数据，并且该增加的服务所在的服务分组数据发生了变化，即增加了上述增加的服务的标识。新界面与当前界面相比，多展现了一个服务视图。

若服务更新数据包括：用于表征在时间戳之后被删除的服务的详情数据的第二删除标记信息。

则客户端可以根据第二删除标记信息，从第一服务数据中删除第二删除标记信息所标识的服务的详情数据，并将被删除的服务的标识从该服务所属的服务分组数据中删除，以获得第二服务数据。第二服务数据与第一服务数据相比，少了一个服务的详情数据，并且该被删除的服务所在的服务分组数据发生了变化，即删除了该被删除的服务的标识。新界面与当前界面相比，少展现了一个服务视图。

值得说明的是，若服务更新数据同时包括两种或两种以上的更新数据(详见前面列举几种)，则客户端可以将上述对应每种数据的更新过程进行结合，得到完整的更新过程。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

图4为本申请一实施例提供的客户端的结构示意图。如图4所示，该客户端包括：获取模块41、更新模块42和界面模块43。

获取模块41，用于从服务端获取更新客户端提供的用于展示服务信息的界面所需的服务更新数据。

更新模块42，与获取模块41连接，用于根据获取模块41获取的服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据。其中，第一服务数据包括：当前界面展现的服务类目对应的服务分组数据，以及当前界面展现在服务类目下的服务视图对应的服务的详情数据；服务类目对应的服务分组数据包括：属于服务类目的服务的标识。

界面模块43，与更新模块42连接，用于根据更新模块42获得的第二服务数据，形成新界面。

在一可选实施方式中，获取模块41具体可用于：向服务端发送同步请求，并接收服务器返回的服务更新数据；同步请求包括：上次获取服务更新数据的时间戳。其中，服务更新数据是服务端根据时间戳，从本地存储的服务分组数据和服务的详情数据中获取的修改时间在时间戳之后的数据。

在一可选实施方式中，上述服务更新数据可以包括以下至少一种：

在时间戳之后新增的服务分组数据和属于新增的服务分组数据对应的服务类目的服务的详情数据；

用于表征在时间戳之后被删除的服务分组数据的第一删除标记信息；

用于表征在时间戳之后被调整的服务分组数据之间的先后顺序的第二顺序信息；

在时间戳之后增加的服务的详情数据和增加的服务所属的服务类目对应的服务分组数据；

用于表征在时间戳之后被删除的服务的详情数据的第二删除标记信息；

用于表征在时间戳之后被更新的第一顺序信息的第三顺序信息。

这里的第一顺序信息用于表征属于当前界面展现的服务类目的服务之间的先后顺序；被更新的第一顺序信息表示：属于当前界面展现的服务类目的服务之间的、在时间戳之后经过调整的先后顺序，也就是说，第三顺序信息实际用于表征属于当前界面展现的服务类目的服务之间的、在时间戳之后经过调整的先后顺序。

在一可选实施方式中，上述服务视图对应的服务的详情数据包括：服务视图对应的服务的访问入口信息；相应的，服务视图包括跳转至所述服务的访问入口。其中，根据服务提供方式的不同，该服务的访问入口信息也有所不同，例如，若该服务时以网页形式提供的，则该访问入口信息可以是跳转至该服务的URL地址，若该服务是以本地APP或WEBAPP形式提供的，则该访问入口信息可以是相应APP的调用接口信息等。

基于上述各实施方式，第二服务数据包括：需要在新界面上展现的服务类目对应的服务分组数据，以及需要在需要展现的服务类目下展现的服务视图对应的服务的详情数据。

相应的，界面模块43具体可用于：根据第二服务数据包括的服务分组数据，在新界面展现需要展现的服务类目，并根据第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，在需要展现的服务类目下展现需要展现的服务视图。

进一步，客户端可以采用触发回调方式形成新界面。具体的，更新模块42还用于向界面模块43发送广播消息，所述广播消息携带有用于标识界面模块43预先注册的回调函数的回调函数名。界面模块43具体可用于：接收更新模块42发送的广播消息，并通过广播消息携带的回调函数名所标识的所述回调函数，在更新模块42获得第二服务数据后，主动获取第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，之后根据第二服务数据包括的服务分组数据，在新界面展现需要展现的服务类目，并根据第二服务数据包括的服务分组数据和第二服务数据包括的服务的详情数据，在需要展现的服务类目下展现需要展现的服务视图。

本实施例提供的客户端，可以是任何可以提供界面且需要进行界面调整的客户端，例如可以是浏览器或应用(Application，APP)客户端。

本实施例提供的客户端，从服务端获取服务更新数据，以对客户端提供的用于展示服务信息的界面进行更新；根据所获取的服务更新数据，对形成当前界面使用的第一服务数据进行更新，以获得第二服务数据，根据第二服务数据形成新界面。由此可见，本实施例提供的客户端可以自动完成界面更新，不需要用户手动下载并安装升级包，界面更新操作相对简单，有利于提高更新界面的效率。

另外，本实施例提供的客户端不仅简化了界面更新操作，提高了更新界面的效率，而且可以根据服务的升级和多样性等，自定义调整界面布局，优化界面布局方法，使得本实施例的客户端跟随服务变化的应变能力增强了，可以为用户提供更加个性化、定制化的界面布局，有利于提供更加丰富的服务信息。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种界面更新方法，其特征在于，包括：

客户端从服务端获取更新所述客户端提供的用于展示服务信息的界面所需的服务更新数据；

所述客户端根据所述服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据；所述第一服务数据包括：所述当前界面展现的服务类目对应的服务分组数据，以及所述当前界面展现在所述服务类目下的服务视图对应的服务的详情数据；所述服务类目对应的服务分组数据包括：属于所述服务类目的服务的标识；

所述客户端根据所述第二服务数据，形成所述新界面。

2.根据权利要求1所述的方法，其特征在于，所述客户端从服务端获取更新所述客户端提供的用于展示服务信息的界面所需的服务更新数据，包括：

所述客户端向所述服务端发送同步请求，所述同步请求包括：上次获取所述服务更新数据的时间戳；

所述服务端根据所述时间戳，从本地存储的服务分组数据和服务的详情数据中获取修改时间在所述时间戳之后的数据作为所述服务更新数据，并返回给所述客户端；

所述客户端接收所述服务器返回的所述服务更新数据。

3.根据权利要求2所述的方法，其特征在于，所述服务更新数据包括以下至少一种：

在所述时间戳之后新增的服务分组数据和属于所述新增的服务分组数据对应的服务类目的服务的详情数据；

用于表征在所述时间戳之后被删除的服务分组数据的第一删除标记信息；

用于表征在所述时间戳之后被调整的服务分组数据之间的先后顺序的第二顺序信息；

在所述时间戳之后增加的服务的详情数据和所述增加的服务所属的服务类目对应的服务分组数据；

用于表征在所述时间戳之后被删除的服务的详情数据的第二删除标记信息；

用于表征在所述时间戳之后被更新的第一顺序信息的第三顺序信息，所述第一顺序信息用于表征属于所述当前界面展现的服务类目的服务之间的先后顺序。

4.根据权利要求1所述的方法，其特征在于，所述服务视图对应的服务的详情数据包括：所述服务视图对应的服务的访问入口信息；所述服务视图包括跳转至所述服务的访问入口。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述第二服务数据包括：需要在所述新界面上展现的服务类目对应的服务分组数据，以及需要在所述需要展现的服务类目下展现的服务视图对应的服务的详情数据；

所述客户端根据所述第二服务数据，形成所述新界面，包括：

所述客户端根据所述第二服务数据包括的服务分组数据，在所述新界面展现所述需要展现的服务类目，并根据所述第二服务数据包括的服务分组数据和所述第二服务数据包括的服务的详情数据，在所述需要展现的服务类目下展现需要展现的服务视图。

6.根据权利要求5所述的方法，其特征在于，所述客户端根据所述第二服务数据包括的服务分组数据，在所述新界面展现所述需要展现的服务类目，并根据所述第二服务数据包括的服务分组数据和所述第二服务数据包括的服务的详情数据，在所述需要展现的服务类目下展现需要展现的服务视图，包括：

所述客户端采用触发回调方式，以根据所述第二服务数据包括的服务分组数据，在所述新界面展现所述需要展现的服务类目，并根据所述第二服务数据包括的服务分组数据和所述第二服务数据包括的服务的详情数据，在所述需要展现的服务类目下展现需要展现的服务视图。

7.一种客户端，其特征在于，包括：

获取模块，用于从服务端获取更新所述客户端提供的用于展示服务信息的界面所需的服务更新数据；

更新模块，用于根据所述服务更新数据，对形成当前界面使用的第一服务数据进行更新，获得第二服务数据；所述第一服务数据包括：所述当前界面展现的服务类目对应的服务分组数据，以及所述当前界面展现在所述服务类目下的服务视图对应的服务的详情数据；所述服务类目对应的服务分组数据包括：属于所述服务类目的服务的标识；

界面模块，用于根据所述第二服务数据，形成所述新界面。

8.根据权利要求7所述的客户端，其特征在于，所述获取模块具体用于：

向所述服务端发送同步请求，并接收所述服务器返回的所述服务更新数据；所述同步请求包括：上次获取所述服务更新数据的时间戳；

其中，所述服务更新数据是所述服务端根据所述时间戳，从本地存储的服务分组数据和服务的详情数据中获取的修改时间在所述时间戳之后的数据。

9.根据权利要求8所述的客户端，其特征在于，所述服务更新数据包括以下至少一种：

在所述时间戳之后新增的服务分组数据和属于所述新增的服务分组数据对应的服务类目的服务的详情数据；

用于表征在所述时间戳之后被删除的服务分组数据的第一删除标记信息；

用于表征在所述时间戳之后被调整的服务分组数据之间的先后顺序的第二顺序信息；

在所述时间戳之后增加的服务的详情数据和所述增加的服务所属的服务类目对应的服务分组数据；

用于表征在所述时间戳之后被删除的服务的详情数据的第二删除标记信息；

用于表征在所述时间戳之后被更新的第一顺序信息的第三顺序信息，所述第一顺序信息用于表征属于所述当前界面展现的服务类目的服务之间的先后顺序。

10.根据权利要求7所述的客户端，其特征在于，所述服务视图对应的服务的详情数据包括：所述服务视图对应的服务的访问入口信息；所述服务视图包括跳转至所述服务的访问入口。

11.根据权利要求7-10任一项所述的客户端，其特征在于，所述第二服务数据包括：需要在所述新界面上展现的服务类目对应的服务分组数据，以及需要在所述需要展现的服务类目下展现的服务视图对应的服务的详情数据；

所述界面模块具体用于：

根据所述第二服务数据包括的服务分组数据，在所述新界面展现所述需要展现的服务类目，并根据所述第二服务数据包括的服务分组数据和所述第二服务数据包括的服务的详情数据，在所述需要展现的服务类目下展现需要展现的服务视图。

12.根据权利要求11所述的客户端，其特征在于，

所述更新模块还用于：向所述界面模块发送广播消息，所述广播消息携带有用于标识所述界面模块预先注册的回调函数的回调函数名；

所述界面模块具体用于：

接收所述更新模块发送的所述广播消息，并通过所述广播消息携带的回调函数名所标识的所述回调函数，在所述更新模块获得所述第二服务数据后，主动获取所述第二服务数据包括的服务分组数据和所述第二服务数据包括的服务的详情数据，并根据所述第二服务数据包括的服务分组数据，在所述新界面展现所述需要展现的服务类目，并根据所述第二服务数据包括的服务分组数据和所述第二服务数据包括的服务的详情数据，在所述需要展现的服务类目下展现需要展现的服务视图。