刷新方法、刷新装置、刷新设备及存储介质与流程

本发明涉及数据处理技术领域，具体涉及刷新方法、刷新装置、刷新设备及存储介质。

背景技术：

用户界面(userinterface,ui)在人机交互中发挥着重要作用。ui控件(控件为图形用户界面元素)为布置在ui上的控件，其形式可为按钮、输入框、海报区等等。

ui控件可用于向用户展示信息(例如图或文字)。以某一app的客户端为例，客户端每次在开启、或由后台转为前台、或进入新页面时都需要刷新，此时，客户端可通过向服务器的网络接口请求配置信息，服务器则会通过网络接口返回配置信息，其中的配置信息可包括控件信息(例如ui控件的大小、位置、类型等)和展示内容；客户端在接收到配置信息后，会根据控件信息创建ui控件，并使用展示内容渲染创建出的ui控件，从而实现刷新。

ui控件的展示内容是由人工手动控制显示(上线)或消失(下线)。举例来讲，假定需要在1月1日至3日在某网页上展示海报，则需要在1月1日人工配置海报区的控件信息及展示内容a，在客户端请求时将配置信息返回给客户端进行渲染，并在1月3日或1月4日的零点人工手动删除展示内容a或将展示内容a替换为其他展示内容(例如展示内容b)，这样，1月4日后客户端再请求时，则不会再对展示内容a进行显示。

技术实现要素：

有鉴于此，本发明实施例提供刷新方法、刷新装置、刷新设备及存储介质，以实现自动对ui控件的展示内容进行上下线的目的。

为实现上述目的，本发明实施例提供如下技术方案：

一种刷新方法，包括：

获取本地存储的配置数据；其中，所述配置数据至少包括待刷新的用户界面中控件的展示信息；所述展示信息包括所述控件的展示内容和所述展示内容的有效期；

获取当前时刻；

根据所述当前时刻和所述配置数据执行刷新策略；其中，所述刷新策略包括：在满足刷新条件时，刷新所述用户界面；所述刷新条件至少包括：所述当前时刻位于所述展示内容的有效期内；所述刷新所述用户界面至少包括：使用所述展示内容刷新所述控件。

一种刷新方法，包括：

接收客户端发送的配置数据请求；

向所述客户端返回反馈结果；

其中，所述反馈结果包括新配置数据或表征无配置数据更新的无更新指示；所述无更新指示是在配置数据未发生变化时生成的；所述新配置数据被所述客户端接收后存储于客户端的本地；

所述客户端用于获取本地存储的配置数据，根据当前时刻和所述配置数据执行刷新策略；

其中，所述本地存储的配置数据至少包括待刷新的用户界面中控件的展示信息；

所述刷新策略包括：在满足刷新条件时，刷新所述用户界面；所述刷新条件至少包括：当前时刻位于所述展示内容的有效期内；所述刷新所述用户界面至少包括：使用所述展示内容刷新所述控件。

一种刷新装置，包括：

获取单元，用于获取本地存储的配置数据；其中，所述配置数据至少包括待刷新的用户界面中控件的展示信息；所述展示信息包括所述控件的展示内容和所述展示内容的有效期；

执行单元，用于获取当前时刻，并根据所述当前时刻和所述配置数据执行刷新策略；其中，所述刷新策略包括：在满足刷新条件时，刷新所述用户界面；所述刷新条件至少包括：所述当前时刻位于所述展示内容的有效期内；所述刷新所述用户界面至少包括：使用所述展示内容刷新所述控件。

一种刷新装置，包括：

接收单元，用于接收客户端发送的配置数据请求；

反馈单元，用于向所述客户端返回反馈结果；

其中，所述反馈结果包括新配置数据或表征无配置数据更新的无更新指示；所述无更新指示是在配置数据未发生变化时生成的；所述新配置数据被所述客户端接收后存储于客户端的本地；

所述客户端用于获取本地存储的配置数据，根据当前时刻和所述配置数据执行刷新策略；

其中，所述本地存储的配置数据至少包括待刷新的用户界面中控件的展示信息；

所述刷新策略包括：在满足刷新条件时，刷新所述用户界面；所述刷新条件至少包括：当前时刻位于所述展示内容的有效期内；所述刷新所述用户界面至少包括：使用所述展示内容刷新所述控件。

一种刷新设备，至少包括处理器和存储器；所述处理器通过执行所述存储器中存放的程序以及调用其他设备，执行上述的刷新方法。

本发明实施例还提供一种存储介质，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行本发明实施例所提供的任一种刷新方法中的步骤。

可见，在本发明实施例中，为展示内容设置了有效期，在当前时刻位于展示内容的有效期内时，则可使用展示内容刷新ui控件，这样，客户端可自动对ui控件的展示内容进行上下线，从而减少了对人工的依赖。

附图说明

图1为本发明实施例提供的应用场景示意图；

图2a为本发明实施例提供的刷新装置的示例性结构图；

图2b为本发明实施例提供的刷新装置的另一示例性结构图；

图2c为本发明实施例提供的刷新设备的示例性结构图；

图3为本发明实施例提供的获取配置数据的示例性流程图；

图4为本发明实施例提供的刷新方法的示例性流程图；

图5为本发明实施例提供的刷新方法的另一示例性流程图；

图6为本发明实施例提供的刷新方法的又一示例性流程图；

图7为本发明实施例提供的刷新方法的又一示例性流程图；

图8a为本发明实施例提供的用户界面示例图；

图8b为本发明实施例提供的移动控件后的用户界面示例图；

图9为本发明实施例提供的界面刷新所涉及的类的结构示例图。

具体实施方式

本发明实施例提供刷新方法及相关装置(刷新装置、刷新设备、存储介质)，其适用于任何需要上下线展示内容或控件的场景。

本发明的核心思想是：在配置数据中增加有效期，客户端根据有效期自动上下线展示内容或ui控件。

在介绍完核心思想后，下面介绍本发明实施例所涉及的装置。

上述刷新装置可以软件或硬件的形式应用于刷新设备中。具体的，刷新设备可为诸如台式机、移动终端(例如智能手机)、ipad等的终端，也可以是服务器。

当以软件形式应用于刷新设备中时，上述刷新装置可为独立的软件。例如，可为部署在移动终端中的app软件。当然，也可作为大型系统(例如操作系统)的子系统(子组件)，提供刷新服务。

当以硬件形式应用于刷新设备中时，上述刷新装置示例性得可为终端或服务器的控制器/处理器。

图1示出了一种示例性应用场景(客户端-服务器场景)。在该应用场景中包括终端11和服务器12，服务器12上部署有网络接口13。

终端11部署有app软件(刷新装置)作为客户端，而服务器13也包括刷新装置，为便于区分，可将客户端侧的刷新装置称为第一刷新装置，将服务器侧的刷新装置称为第二刷新装置。

下面介绍第一刷新装置和第二刷新装置的内部结构。

第一刷新装置的一种示例性结构如图2a所示，包括：获取单元201和执行单元202，获取单元201用于获取本地存储的配置数据，执行单元202用于获取当前时刻，并根据上述当前时刻执行刷新策略。

其中，上述配置数据至少包括ui控件的展示信息，上述展示信息包括上述ui控件的展示内容和上述展示内容的有效期；

上述刷新策略包括：在满足刷新条件时，刷新当前用户界面；而上述刷新条件至少可包括：当前时刻位于展示内容的有效期内，上述“刷新当前用户界面”至少可包括：使用上述展示内容刷新上述ui控件。

第二刷新装置的一种示例性结构如图2b所示，包括：接收单元203和反馈单元204。

接收单元203可用于接收客户端发送的配置数据请求；反馈单元204可用于向上述客户端返回反馈结果；

其中，上述反馈结果包括新配置数据或表征无配置数据更新的无更新指示，上述无更新指示是在配置数据未发生变化时生成的；上述新配置数据则至少包括ui控件的展示信息。

本文后续将结合刷新方法介绍上述各单元的功能。

图2c示出了上述实施例中刷新设备的一种可能的结构示意图，包括：

总线、处理器1、存储器2、通信接口3、输入设备4和输出设备5。处理器1、存储器2、通信接口3、输入设备4和输出设备5通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器1可以是通用处理器，例如通用中央处理器(cpu)、网络处理器(networkprocessor，简称np)、微处理器等，也可以是特定应用集成电路(application-specificintegratedcircuit，asic)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(dsp)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器2中保存有执行本发明技术方案的程序或脚本，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。脚本则通常以文本(如ascii)保存，只在被调用时进行解释或编译。

更具体的，存储器2可以包括只读存储器(read-onlymemory，rom)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(randomaccessmemory，ram)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。

输入设备4可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、语音输入装置、触摸屏等。

输出设备5可包括允许输出信息给用户的装置，例如显示屏、扬声器等。

通信接口3可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(ran)，无线局域网(wlan)等。

可以理解的是，图2c仅仅示出了刷新设备的简化设计。在实际应用中，刷新设备可以包含任意数量的发射器，接收器，处理器，控制器，存储器，通信接口等，而所有可以实现本发明的服务器/智能终端都在本发明的保护范围之内。

处理器1通过执行存储器2中所存放的程序以及调用其他设备，可实现下述实施例提供的刷新方法。

此外，图2a或图2b所示的各单元的功能，可由前述的处理器1执行存储器2中所存放的程序以及调用其他设备实现。

下面将基于上面所述的本发明涉及的共性方面，对本发明实施例进一步详细说明。

先介绍前述的配置数据如何获取。

图3示出了获取配置数据的一种示例性交互流程，其可包括如下步骤：

300部分：客户端发送配置数据请求；

在一个示例中，客户端可在每次启动时发送配置数据请求。

在其他示例中，客户端还可在由后台到前台，或者，进入下一页面时，发送配置数据请求。

需要说明的是，上述启动、由后台到前台，以及，进入下一页面，都会引发界面刷新。

在一个示例中，上述客户端可为前述提及的第一刷新装置、部署有第一刷新装置的刷新设备(可称为第一刷新设备)或终端11。更具体的，可由前述的获取单元201或第一刷新设备的通信接口执行300部分。

301部分：服务器接收到上述请求后，返回反馈结果。

在一个示例中，上述服务器可为前述提及的第二刷新装置、部署有第二刷新装置的刷新设备(可称为第二刷新设备)或前述的服务器12。更具体的，可由前述的接收单元203或第二刷新设备的通信接口接收上述请求，由反馈单元204或第二刷新设备的通信接口返回反馈结果。

更进一步的，上述反馈结果可由服务器上的网络接口返回，而前述提及的接收单元203和反馈单元204可均为网络接口的组成部分。

上述反馈结果可包括新配置数据或无更新指示，其中，无更新指示是在配置数据未发生变化时生成的，用于表征无配置数据更新。

在一个示例中，无更新指示具体可为“无数据更新”字样，也可为特定的字符、数字、字符串、数字序列等，只要客户端可正确识别其所表征的含义即可。

具体如何确定配置数据有无更新呢？

配置数据发生改动后，服务器会记录一个时间戳(修改时间)。时间戳是指格林威治时间1970年01月01日00时00分00秒(北京时间1970年01月01日08时00分00秒)起至现在的总秒数。通俗的讲，时间戳是一份能够表示一份数据在一个特定时间点已经存在的完整的可验证的数据。

网络接口可比对上次请求时配置数据的时间戳与本次请求时配置数据的时间戳是否相同，若相同，说明无数据更新，则返回上述无更新指示，若不相同，说明配置数据发生了变化，则返回修改后的配置数据(新配置数据)。

为达到返回无更新指示的目的，可修改现有网络接口的数据返回逻辑，从而在配置数据没有发生变化时，返回“无数据指示”。

在本发明其他实施例中，上述反馈结果还可包括服务器当前时间(例如当前时间戳)，上述服务器当前时间可用于客户端校正本地当前时间。

在一个示例中，可在每一次请求的反馈结果上附带服务器当前时间，或者，也可在当天第一次请求的反馈结果上附带服务器当前时间，客户端可将服务器当前时间与本地当前时间的时间差保存下来，使用时间差校正本地的当前时间。

需要说明的是，服务器在一段时间内可能并不会对配置数据进行修改。但在现有方式中，每次请求都会向客户端返回配置数据，这样，在配置数据无更新的情况下，会造成用户流量的浪费。

而本实施例则可在配置数据无更新时，返回无更新指示，节省用户的流量。

302部分：若上述反馈结果包括新配置数据，客户端在本地存储新配置数据以替换之前的配置数据。

当然，若上述反馈结果包含的是无更新指示，则不进行存储操作。

在一个示例中，可将新配置数据缓存在本地。

在本发明其他实施例中，若反馈结果中还包括服务器时间，可将服务器当前时间与本地当前时间的时间差保存下来，之后可使用时间差校正本地的当前时间。

在一个示例中，可由前述的获取单元201或第一刷新设备的处理器或第一刷新设备的存储器执行302部分。

可见，本实施例在配置数据无更新时，返回无更新指示，这样可减少客户端的接口请求返回的数据量，从而不必每次都返回具体数据，只在配置数据发生变化时才返回新配置数据，大大降低了用户的流量损耗，在本地存储配置数据，则为展示内容和ui控件的自动上下线打下了基础。

一般情况下，ui控件会在较长的一段时间内保持有效，而其展示的内容可经常变换，则本文先介绍展示内容刷新，再介绍ui控件的自动上下线。

前已述及，客户端在启动、由后台到前台，以及，进入下一页面时需进行刷新，此时，客户端依据设计策略可发起网络请求，也可不发起网络请求。

下面先介绍客户端发起网络请求时，客户端与服务器如何交互。图4示出的客户端与服务器的一种示例性交互流程，其可包括：

400-401部分与前述的300-301部分相同，在此不作赘述。

402部分：客户端判断是否无数据更新，若否，进入403部分，否则，进入404部分，也即是有数据更新则进入403部分，无数据更新则进入404部分。

客户端可根据反馈结果所包含的内容判断是否无数据更新。

403部分：在本地存储新配置数据以替换之前的配置数据。

可由前述的获取单元201或第一刷新设备的处理器或第一刷新设备的存储器执行402和403部分。

404部分：获取本地存储的配置数据。

上述配置数据可缓存在本地。

配置数据也可称为配置，其包含了整个界面(例如页面)显示所需要的全部数据，为文本文件，可以是xml格式或json格式。

上述配置数据至少可包括ui控件的展示信息。其中，展示信息可包括展示内容和展示内容的有效期。

举例来讲，假定需要在1月1日-3日由控件a展示3张海报图片，则展示信息包括上述3张海报图片以及每张海报图片的控制信息(有效期)。

在具体实现时，可将有效期与展示内容合并在一起。

此外，上述配置数据还可包括ui控件的配置信息，在第一次需要展示ui控件时，该配置信息可用于创建ui控件。

可由前述的获取单元201或第一刷新设备的处理器执行404部分。

405部分：获取当前时刻。

前述提及了可保留时间差，则可使用时间差校正本地的当前时间，得到当前时刻。

或者，若反馈结果中包含服务器当前时间，则可使用服务器当前时间校正本地的当前时间，得到当前时刻。

在一个示例中，可由前述的获取单元201或第一刷新设备的处理器或总线执行405部分。

406部分：执行刷新策略。

具体的，刷新策略可至少包括：在满足刷新条件时，刷新当前用户界面。

需要说明的是，用户界面一般包括至少一个ui控件，则刷新当前用户界面也包含对ui控件的刷新。

展示给用户的ui控件上一般绘制有展示内容，ui控件类似于相框，而展示内容类似于相框所展示的图像或文字等。在展示给用户时，会使用展示内容(图像或文字)刷新ui控件。

因此，在本实施例中，上述刷新条件可包括：当前时刻位于展示内容的有效期内；而上述“刷新当前用户界面”可包括：使用上述展示内容刷新上述ui控件。

在一个示例中，可使用展示内容渲染ui控件。

仍沿用前例，假定需要在1月1日-3日由海报控件a(海报控件也是ui控件的一种)循环展示3张海报图片fig1-3，则本地缓存的配置数据中可包括fig1-3以及每张海报图片的控制信息(有效期)。

假定客户端在1月2日被打开，由于当前时刻位于1月1日-3日之间，则会使用上述3张海报图片渲染控件a。这样，从用户的角度来看，在控件a所在的区域会循环展示3张海报。

而如果客户端在1月4日被打开，由于当前时刻并不位于展示内容的有效期内，则不会循环展示上述3张海报fig1-3。另外，控件a对应的所有展示内容都超期或未进入有效期，控件a也不会再被显示。

可由前述的执行单元202或第一刷新设备的处理器执行406部分。

这样，通过本实施例提供的技术方案，可实现展示内容的自动上下线。并且，在配置数据无更新时，服务器侧会返回无更新指示，大大降低了用户的流量损耗。

而若在刷新时不发起网络请求，则请参见图5，可从上述404部分直接执行。因此，本发明实施例在不发起网络请求时，只要本地存储有配置数据，就可实现刷新界面。

至于不发起网络请求的原因，可能是无网络连接，或者本身策略配置不发起网络请求等。

沿用上述有效期的思想，还可实现ui控件的自动上下线。若要实现ui控件的上下线，可在配置数据中添加ui控件的有效期。ui控件的有效期可作为ui控件的控制信息，由服务器侧配置并返回给客户端。

需要说明的是，对于常驻的ui控件，可不设置其有效期，或者设置长有效期(例如100年)；而对于一些暂时展示的ui控件，则可依实际需要进行有效期的设置。

图6示出的客户端与服务器的一种示例性交互流程，其可包括：

600-605部分与前述的400-405部分相同，在此不作赘述。

606部分：确定当前时刻与ui控件的有效期的关系，若当前时刻位于该有效期内，进入607部分，若当前时刻早于该有效期，进入610部分，若当前时刻晚于有效期，进入609部分。

有效期有开始时间和结束时间，若当前时刻早于开始时间，则认为当前时刻早于有效期，若当前时刻位于开始时间和结束时间之间(或称为进入有效期内)，则认为当前时刻位于有效期内，若当前时刻晚于结束时间，则认为当前时刻晚于有效期(即超期)。

假定需要在2018年1月1日-3日由海报控件a展示海报图片，若客户端在2017年12月31日打开客户端，则早于有效期，若客户端在1月4日打开，可根据当前时刻判断ui控件超过有效期，若客户端在1月1日-3日期间被打开，则认为进入有效期。

需要说明的是，若上述ui控件为新增ui控件，则在607或608部分之前，还会根据ui控件的配置信息创建该ui控件。

举例来讲，假定需要在2018年1月1日-3日由海报控件a展示海报图片。控件a为新增的控件。则客户端在1月1日-3日期间被打开，会创建控件a。

607部分：判断是否有可展示的展示内容，若是，进入608部分，若否，进入610部分；

具体的，当前时刻落入哪一展示内容的有效期，则判定该展示内容可展示。

在其他实施例中，也可判断当前时刻是否落入展示内容的有效期(是，进入608部分，否则，进入610部分)，或者，判断展示内容是否超期(是，进入609部分，否则，进入610部分)。

608部分：使用展示内容刷新上述ui控件。

需要说明的是，在本实施例中，前述的刷新条件可包括：当前时刻位于上述ui控件的有效期内，以及，当前时刻位于展示内容的有效期内。

609部分：移除ui控件。

由于ui控件已经超期，所以可从父布局上移除超期的ui控件。

举例来讲，请参见图8a，控件c包含控件a和控件b，则控件c是控件a和控件b的父布局。若控件a超过有效期，则可将控件a从控件c上移除(请参见图8b)。

610部分：结束。

可由前述的执行单元202或第一刷新设备的处理器执行606-610部分。

需要说明的是，由于针对一个用户界面上不止配置了一个ui控件，因此，针对每一控件(无论其是否已被创建)，都会执行606-610部分。

600-610部分介绍的是客户端发起网络请求时，客户端与服务器如何交互以实现ui控件的自动上下线。

而若在刷新时不发起网络请求，则请参见图7，可从704部分直接往下执行。

在本实施例中，通过有效期的设置，可实现ui控件和展示内容的自动上下线。因此，可提前配置好有效期：例如，1月1日-3日需要由海报控件a展示海报图片，则可提前配置好配置数据(例如在12月30日)，客户端从服务器获取配置数据后，会存储至本地，在1月1日-3日客户端会自动上线ui控件和其展示内容(甚至不需要发起网络请求)，无需再如现有方式一样，需要人工手动发布和删除。

下面，以客户端为例，讲述上述刷新方法实现的具体技术实现，先介绍所涉及的关键词：接口、基类、继承、子类。

接口：泛指实体把自己提供给外界的一种抽象化物(可以为另一实体)，用以由内部操作分离出外部沟通方法，使其能被内部修改而不影响外界其他实体与其交互的方式。在java编程语言中是一个抽象类型，是抽象方法的集合，接口通常以interface来声明，接口可理解为规范；

基类：对于客观世界中既有共性又有差别的两个类别以上的实体是不可能被抽象成一个class类型来描述的，所以，编程者往往采用继承的方法。首先定义一个包含所有实体共性的class类型作为“基类”，然后，从该基类中继承所有信息，再添加新的信息，来构成新的类；

继承：继承性是面向对象程序设计的一个最重要的概念。继承性允许在构成软件系统的层次结构中利用已经存在的类并扩充它们，以支持新的功能。这使得编程者只需要在新类中定义已经存在的类中所没有的成分来建立新类，从而大大提高了软件的可重用性和可维护性；

子类：在构建新类的过程中，新建立的类被称为“子类”或者“派生类”；而被继承的包含相同特征的类称为“父类”或者“基类”。派生类继承了基类的全部成员，并且可以增加基类所没有的数据成员和成员函数，以满足描述新对象的需求。其中，数据成员可理解为属性，成员函数可理解为方法或行为，例如，人作为一类，人的身高和体重是数据成员，其吃饭、睡觉等行为是成员函数。

为实现上述刷新方法，需要在客户端原有的编程基础上进行改动。

主要改动点如下：

第一步，制定协议，约定网络接口返回的控制信息的数据体结构，为每一控件返回的配置增加关键字段starttime和endtime。

控制信息即包含上述关键字段(starttime和endtime)及其具体取值。其中，starttime表征开始时间，endtime表征结束时间(截止时间)，starttime和endtime中的具体取值，确定了具体的有效期。

前述提及，展示内容和ui控件都可有有效期。假定，ui控件a需要在1月1-3日展示3张图片，则一种做法是：

为3张图片分别设置有效期(即控件信息)，但不为ui控件a设置有效期。在需要ui控件a常驻某界面时，可采用上述做法。

还有一种做法是：为3张图片分别设置有效期，并为ui控件a设置有效期。在ui控件a只是暂时出现的情况下，可采用该做法。

此外，还有另一种做法是：为ui控件a设置有效期，但不为3张图片设置有效期。这样，ui控件超过有效期时，会自动下线，也不会再展示图片了。

第二步，定义通用接口(接口名可为ihomecell)，声明需要实现以下方法：

判断ui控件在当前时刻是否位于有效期的方法或判断ui控件是否超过有效期的方法(isexpired方法)；

需要说明的是，这里的“超过”有效期可包含“早于有效期”和“晚于有效期”两种情况；

判断展示内容在当前时刻是否位于有效期的方法(iscontextexpired方法)；

获取控件需要展示的展示内容的方法(getpagebean方法)；

使用展示内容刷新ui控件的方法(updateview方法)。

基于以上两步，协议和通用接口都制定好了，则下一步是：

第三步，实现抽象基类(类名可为blockbaseview)。

该抽象基类采用上述协议和通用规范(通用接口)。

上述抽象基类包含如下方法：

判断展示内容在当前时刻是否位于有效期的方法(也可称为判断展示内容是否超过有效期的方法，“超过有效期”包含“早于有效期”和“晚于有效期”两种情况)；

判断ui控件在当前时刻是否位于有效期的方法(也可称为判断ui控件是否超过有效期的方法，“超过有效期”包含“早于有效期”和“晚于有效期”两种情况)。

具体做法是：保存网络接口返回的控制信息(有效期的开始和截止时间)，那么将当前时间与有效期的时间段比较，如果落在这个时间段内就是在有效期内，否则不在有效期。

同时，抽象基类还定义了获取需展示的展示内容的抽象方法以及绑定展示内容的抽象方法(具体怎么做由每个需要展示的子类自己实现)。

其中，获取需展示的展示内容的抽象方法可获取本地数据并调用接口声明的方法getpagebean拿到每个控件所需展示的展示内容及其有效期。

绑定指的是把实际要渲染的数据绘制到控件上，比如，需要渲染一幅图，那么绑定就是指把这幅图绘制到控件上。或者，需要显示一段文字，那么绑定就是把文字绘制在控件上。

第四步：将原来的控件修改为都遵循这个通用接口的协议，继承抽象基类，并实现绑定展示内容的抽象方法以及获取需要展示的展示内容的抽象方法(这两个方法是新增的)，从而可实现具体的界面刷新工作。

最后，在实际需要刷新处调用该通用接口。

经过上述改动后，实现界面刷新主要涉及的类以及它们之间的结构如图9所示：

一，ihomecell——通用接口。

该接口的主要定义了isexpired方法、iscontextexpired方法、getpagebean方法和updateview方法。

二，blockbaseview(抽象基类)。

blockbaseview作为每个控件的父类，它实现了ihomecell接口，其中展示内容或ui控件是否过期都是在该类里面去实现的。

三，控件(子类)。

根据显示需要，子类可包含图9所示的billview、dynamicview、funcoperaview、rankingview等。

上述子类是真正页面去加载的控件，其继承于blockbaseview，因此具备判断是否过期的能力；

此外子类包含获取展示内容的抽象方法-getpagebean、以及绑定展示内容的抽象方法(刷新视图)的方法——binddata(抽象基类的updateview包含binddata方法)。比如，如果某展示内容过期了，可调用binddata方法去刷新控件。

四，homefragmentactivity：具体使用控件的类(控件的父布局对应的类)。

homefragmentactivity会保存一个ihomecell列表(可称为更新列表)，每添加一个控件(如：billview)就调用addhomecell方法将其加进该队列homecelllist中。

举例来讲，假定1月1-3日需要展示控件a，在1月1日，客户端被打开时，控件a会判断可以上线，调用addhomecell方法将自己加进homecelllist中。

在需要更新控件时候，则homefragmentactivity调用updateallview方法去遍历homecelllist，再去调用每个ihomecell对象的updateview方法，从而实现控件的更新。

从ui控件角度来看，由于控件继承了抽象基类，可以判断是否超期，因此，可由控件获取本地缓存数据并调用接口声明的方法—getpagebean拿到所需展示的展示内容及其有效期，自己判断是否过期，若未过期，调用binddata刷新自身，而在判断过期后，调用removehomecell解除从homecelllist中移除自己。

综上，本发明实施例所提供的技术方案有如下优点：

1.减少接口请求返回的数据量，不必每次都返回配置数据，只在配置数据发生变化时，才返回新配置数据，大大降低用户的流量损耗。

2.在抽象基类中统一实现判断控件及内容是否过期的方法。每个继承该抽象基类的控件只需要实现自身的刷新逻辑即可。

3.通过每次接口请求后，对本地时间进行校准，保证本地时间的一个较高的可信度，因此，可以根据实际策略进行调整，就算没有发起网络请求，也可以进行页面的更新。

下面再次详细介绍前述的第一刷新装置和第二刷新装置。

前已述及，第一刷新装置包括获取单元201和执行单元202，其中：

获取单元201，用于获取本地存储的配置数据；

上述配置数据至少包括待刷新的用户界面中控件的展示信息；所述展示信息包括所述控件的展示内容和所述展示内容的有效期；

执行单元202，至少用于获取当前时刻，并根据当前时刻和上述配置数据执行刷新策略。

上述刷新策略可包括：在满足刷新条件时，刷新上述用户界面；

上述刷新条件可至少包括：上述当前时刻位于展示内容的有效期内；而“刷新上述用户界面”可至少包括：使用上述展示内容刷新上述控件。

在本发明其他实施例中，上述配置数据还可包括控件的配置信息和有效期。所述刷新条件还包括：所述当前时刻位于所述控件的有效期内。

在本发明其他实施例中，若控件为新增控件，则在使用展示内容刷新该控件之前，上述执行单元202所执行的刷新策略还可包括：根据上述配置信息创建控件。

在本发明其他实施例中，上述执行单元202所执行的刷新策略还可包括：在当前时刻超出上述展示内容或上述控件的有效期时，移除该控件。

前述提及，在刷新界面之前，客户端可向服务器发出网络请求，则在本发明其他实施例中，上述获取单元201在获取本地存储的配置数据之前，还可用于：

向服务器发送配置数据请求，以及，接收所述服务器返回的反馈结果。

相应的，第二刷新装置的接收单元203则可用于接收客户端发送的配置数据请求，其反馈单元204则可用于返回反馈结果。

上述反馈结果可包括新配置数据或表征无配置数据更新的无更新指示；

其中，上述无更新指示是所述服务器在配置数据未发生变化时生成的。

进一步的，在返回反馈结果的方面，反馈单元204可具体用于：

比对上次请求的配置数据的修改时间与本次请求的配置数据的修改时间是否相同；

若相同，返回上述无更新指示；

若不相同，返回本次请求的配置数据作为新配置数据。

而在所述反馈结果包括新配置数据时，上述获取单元201还可在本地存储上述新配置数据以替换之前的配置数据。

前述的“获取本地存储的配置数据”，则是在接收到包含无更新指示的反馈结果后，或者，将所述新配置数据存储至本地后执行的。

在本发明其他实施例中，上述反馈结果中还可包括服务器当前时间，执行单元202可使用服务器当前时间校正本地当前时间，得到当前时刻。

本发明实施例还要求保护刷新设备，其至少包括处理器和存储器，该处理器通过执行存储器中存放的程序以及调用其他设备，执行上述的刷新方法。

本发明实施例还要求保护一种存储介质，该存储介质存储有多条指令，所述指令适于处理器进行加载，以执行本发明任一实施例所提供的刷新方法中的步骤。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件单元，或者二者的结合来实施。软件单元可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。