一种数据加载方法及装置与流程

本公开涉及计算机技术领域，具体而言，涉及一种数据加载方法及装置。

背景技术：

一般用户在点击某一链接之后，用户端可以根据用户点击的该链接从服务器获取该链接对应的超文件标记语言(hypertextmarkuplanguage，html)文档，并在对html文档进行解析，获取页面数据，并根据获取的页面数据加载页面；在页面数据加载完成之后，根据解析html文档获取到的统一资源定位符(uniformresourcelocator，url)去服务器获取对应的业务数据，并在接收到服务器返回的业务数据之后，在页面中加载返回的业务数据。

然而这个过程中，由于用户端解析html文档、根据页面数据加载页面、获取业务数据是顺序执行的，且用户端在向服务器发起业务数据获取请求之后，仍需一段时间等待服务器返回业务数据，因此这种方法容易造成业务数据的加载缓慢。

技术实现要素：

本公开实施例至少提供一种数据加载方法及装置。

第一方面，本公开实施例提供了一种数据加载方法，包括：

响应目标链接的点击操作，获取所述目标链接对应的超文件标记语言html文档，并根据所述html文档加载业务模板界面；以及，基于所述目标链接，确定所述目标链接对应的至少一个第一统一资源定位符url，并基于所述至少一个第一url发起数据资源获取请求；

在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据。

一种可能的实施方式中，所述根据所述目标链接，确定所述目标链接对应的至少一个第一url，包括：

根据所述目标链接，查找预先为所述目标链接配置的所述至少一个第一url。

一种可能的实施方式中，所述在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据，包括：

在加载完所述html文档所对应的业务模板界面之后，确定所述html文档对应的第二url；所述第二url属于所述至少一个第一url；

在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，所述在所述业务模板界面加载接收到的所述第二url对应的业务数据，包括：

在基于所述至少一个第一url发起数据资源获取请求后，从缓存到本地的所述数据资源获取请求对应的业务数据中，获取所述第二url对应的业务数据，在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，所述方法还包括：

若检测到缓存到本地的所述第二url对应的业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔，基于所述第二url再次发起数据资源获取请求，并在所述业务模板界面加载接收到的业务数据。

一种可能的实施方式中，所述方法还包括：

所述数据资源获取请求缓存在本地；在接收到所述数据资源获取请求对应的业务数据后，将该数据资源获取请求对应的业务数据缓存在本地；

当检测到接收所述业务数据的时刻与当前时刻之间的时间间隔大于预设时间间隔时，将缓存的所述业务数据、该业务数据对应的数据资源获取请求删除。

第二方面，本公开实施例还提供一种数据加载装置，包括：

处理模块，用于响应目标链接的点击操作，获取所述目标链接对应的超文件标记语言html文档，并根据所述html文档加载业务模板界面；以及，基于所述目标链接，确定所述目标链接对应的至少一个第一统一资源定位符url，并基于所述至少一个第一url发起数据资源获取请求；

加载模块，用于在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据。

一种可能的实施方式中，所述处理模块，在根据所述目标链接，确定所述目标链接对应的至少一个第一url时，用于：

根据所述目标链接，查找预先为所述目标链接配置的所述至少一个第一url。

一种可能的实施方式中，所述加载模块，在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据时，用于：

在加载完所述html文档所对应的业务模板界面之后，确定所述html文档对应的第二url；所述第二url属于所述至少一个第一url；

在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，所述加载模块，在所述业务模板界面加载接收到的所述第二url对应的业务数据时，用于：

在基于所述至少一个第一url发起数据资源获取请求后，从缓存到本地的所述数据资源获取请求对应的业务数据中，获取所述第二url对应的业务数据，在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，所述处理模块，还用于：

若检测到缓存到本地的所述第二url对应的业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔，基于所述第二url再次发起数据资源获取请求，并在所述业务模板界面加载接收到的业务数据。

一种可能的实施方式中，所述处理模块，还用于：

所述数据资源获取请求缓存在本地；在接收到所述数据资源获取请求对应的业务数据后，将该数据资源获取请求对应的业务数据缓存在本地；

当检测到接收所述业务数据的时刻与当前时刻之间的时间间隔大于预设时间间隔时，将缓存的所述业务数据、该业务数据对应的数据资源获取请求删除。

第三方面，本公开实施例还提供一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

第四方面，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

本公开实施例所提供的数据加载方法，在检测到针对目标链接的点击操作之后，从服务器获取与该目标链接对应的html文档，并根据html文档加载业务模板界面，在获取html文档的同时，确定与目标链接对应的url，并根据url发起数据资源获取请求，在加载完业务模板界面之后可以直接根据接收到的业务数据加载业务数据，由于加载业务模板界面与请求业务数据是同步进行的，因此较少了数据加载过程中的等待时间，提高了数据加载的效率。

在本公开实施例一种实施方式下，在业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔时，会将缓存在本地的业务数据删除，并重新发起获取业务数据的请求，从而保证了界面加载的业务数据的实时性。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种数据加载方法的流程图；

图2示出了本公开实施例所提供的一种业务模板页面示意图；

图3示出了本公开实施例所提供的一种数据加载装置的示意图；

图4示出了本公开实施例所提供的一种电子设备的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

通常情况下，用户在点击用户端的链接之后，可以先向服务器发起页面数据加载请求，服务器可以根据该页面数据加载请求，向用户端返回对应的页面数据，一般情况下该页面数据的形式为html文档，用户端在接收到html文档之后，可以根据html文档加载对应的页面，但是该页面中并不包含具体的业务数据，例如，html文档所加载的页面可能包含个人信息，但是仅有姓名、性别、年龄等属性，并不包含具体的属性值；因此，还需要用户端解析html文档以获取url，然后根据url发起数据获取请求，以获取对应的业务数据。

在这个过程中，由于加载页面数据和获取业务数据是顺序执行的，用户端在发起数据获取请求之后，服务器根据接收到的数据获取请求查找并返回对应的业务数据，在这个过程中，从用户点击链接，到用户端发起数据获取请求之间、从服务器接收到数据获取请求到服务器向用户端返回业务数据之间，都需要时间等待，因此这种方法容易造成业务数据的加载缓慢。

基于此，本公开所提供的数据加载方法，在检测到针对目标链接的点击操作之后，从服务器获取与该目标链接对应的html文档，并根据html文档加载业务模板界面，在获取html文档的同时，确定与目标链接对应的url，并根据url发起数据资源获取请求，在加载完业务模板界面之后可以直接根据接收到的业务数据加载业务数据，由于加载业务模板界面与请求业务数据是同步进行的，因此较少了数据加载过程中的等待时间，提高了数据加载的效率。

另外，相关技术中为提高数据加载效率，会采用预加载的方式，预先将当前页面对应的所有链接的业务数据存储在本地，在用户点击当前页面中的任一链接时，直接获取存储在本地的业务数据。这种实现方式中，若用户在当前页面浏览的时间过长，由于缓存在本地的业务数据无法进行更新，这就导致，当用户浏览一段时间之后所点击的链接所加载的数据为预先存储在本地的，数据实时性较差。

在本公开实施例一种实施方式下，在业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔时，会将缓存在本地的业务数据删除，并重新发起获取业务数据的请求，从而保证了界面加载的业务数据的实时性。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

下面将结合本公开中附图，对本公开中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种数据加载方法进行详细介绍，本公开实施例所提供的数据加载方法的执行主体一般为具有显示能力和一定计算能力的电子设备，该电子设备例如可以为智能手机、个人计算机、平板电脑等。

参见图1所示，为本公开实施例提供的数据加载方法的流程图，该方法应用于用户端，包括以下几个步骤：

步骤101、响应目标链接的点击操作，获取所述目标链接对应的超文件标记语言html文档，并根据所述html文档加载业务模板界面；以及，基于所述目标链接，确定所述目标链接对应的至少一个第一统一资源定位符url，并基于所述至少一个第一url发起数据资源获取请求。

步骤102、在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据。

其中，对于目标链接的点击操作包括但不仅限于单击、双击、长按、重按等。在检测到针对目标链接的点击操作之后，可以根据该目标链接，从服务器获取与该目标链接对应的超文本链接html文档，该html文档中包含有该目标链接对应的页面的页面数据。用户端在接收到服务器返回的html文档之后，可以解析该html文档，并根据解析的html文档加载对应的业务模板页面。

在一种可能的实施方式中，每个链接对应的html文档还可以存储在用户端本地，在检测到针对目标链接的点击操作之后，可以从本地查找目标链接对应的html文档。

具体的，用户端可以创建网页视图webview容器，然后基于webview解析html文档，并加载html文档中所包含的页面数据。

业务模板页面中包含有该目标链接对应的属性，但是该业务模板页面中并不包含属性具体的属性值，示例性的，业务模板页面可能如图2所示，该图中展示有属性“姓名”、“性别”、“年龄”，但是每种属性下的属性值属于业务数据，在加载业务模板页面该属性值为空。

在基于目标链接，确定目标链接对应的至少一个第一统一资源定位符url时，可以是根据目标链接，查找预先为目标链接配置的至少一个第一url。具体的，用户端可以解析当前展示的页面的url，然后确定为所述目标链接所配置的至少一个第一url。

需要说明的是，获取目标链接对应的html文档，根据html文档加载业务模板界面，与基于目标链接，确定目标链接对应的至少一个第一统一定位资源费url，基于至少一个第一url发起数据资源获取请求是在用户端并行执行的。

在根据html文档加载完业务模板界面，并接收到数据资源获取请求对应的业务数据之后，在业务模板界面加载业务数据时，具体可以执行为，在加载完html文档所对应的业务模板界面之后，确定html文档对应的第二url，然后在业务模板界面中加载接收到的第二url对应的业务数据。其中，第二url属于第一url中的一个url。

实际应用中，目标链接对应的页面中的业务数据可能有m种，但是在用户点击目标链接之后，需要当前展示在页面中的业务数据可能仅为m种业务数据中的n中，因此，本公开实施例所提供的方法在加载业务数据时，仅加载第二url对应的业务数据。

用户端在基于第一url发起数据资源获取请求之后，可以将发起的数据资源获取请求缓存在本地，若接收到任一数据资源请求所对应的业务数据后，将接收到的该业务数据也缓存到本地。

在一种可能的实施方式中，所述在业务模板页面中加载接收到的第二url对应的业务数据，可以是在基于至少一个第一url发起数据资源获取请求后，从缓存到本地的数据资源获取请求对应的业务数据中，获取第二url对应的业务数据，并在业务模板界面中加载接收到的第二url对应的业务数据。

其中，缓存到本地的数据资源获取请求对应的业务数据包括两种可能的情况，一种可能的情况是，基于第二url发起的数据资源获取请求，且在加载完业务模板页面之前已经接收到第二url对应的业务数据，接收到的业务数据缓存在本地(第一url包括第二url，因此，在基于第一url发起数据资源获取请求包括基于第二url发起数据资源获取请求)；另外一种可能的情况是，基于第二url发起数据资源获取请求，且在加载完业务模板页面之前未接收到第二url对应的业务数据，用户端等待一段时间之后，接收到第二url对应的业务数据并缓存到本地之后，从本地获取。

针对第一种情况，在业务模板界面中加载第二url对应的业务数据时，可以直接从缓存在本地的业务数据中，获取第二url对应的业务数据；针对第二种情况，用户端可以等待服务器返回业务数据，在接收到返回的业务数据之后，在需要在业务模板界面中加载时，再从本地缓存中获取。

在一种可能的实施方式中，用户端在从缓存在本地的业务数据中，获取需要加载到业务模板界面中第二url对应的业务数据时，可以周期性的获取，若本地缓存中存储有第二url对应的业务数据，则直接获取第二url对应的业务数据，并在业务模板界面中加载获取的业务数据；若缓存在本地的业务数据中不包含第二url对应的业务数据，但是本地缓存中存储有基于第二url发起的数据资源获取请求，这种情况下，可以每隔预设时长从本地缓存中检测是否接收到该数据资源获取请求对应的业务数据。

示例性的，若用户端加载业务模板界面所需时间为10ms，发起数据资源获取请求到接收到服务器返回的业务数据所需时间为20ms，若先加载业务模板界面，再发起数据资源获取请求，则用户端接收业务数据所需时间为10ms+20ms＝30ms；而基于本公开所提供的方法，用户端在加载业务模压板界面的同时，发起数据资源获取请求，则用户端在加载完业务模板界面之后，只需再等待10ms即可获取业务数据，用户端接收业务数据所需时间为20ms，因此，本公开所提供的方法可以提高数据加载效率。

实际应用中，webview在加载完业务模板界面之后，可以基于第二url，通过js请求业务数据，但是与此同时，用户端会拦截js请求，然后判断缓存到本地中的数据资源获取请求是否与js请求相匹配，若本地中有与js请求匹配的数据资源获取请求，且本地中缓存有该数据资源获取请求对应的业务数据，则直接将该业务数据作为js请求所对应的业务数据，并在业务模板界面中加载该业务数据；若本地中有与js请求匹配的数据资源获取请求，但本地中并没有缓存该数据资源获取请求对应的业务数据，则用户端可以等待服务器返回该数据资源获取请求对应的业务数据，并在接收到服务器返回的业务数据之后，在业务模板界面中加载接收的业务数据。

本公开另外一种可能的实施方式中，若基于第二url发起数据资源获取请求，且在加载完业务模板页面之前未接收到第二url对应的业务数据，若数据资源获取请求对应的发起时刻与当前时刻之间的时间间隔超过预设时间间隔，则重新基于第二url发起数据资源获取请求。

在另一种可实现的方式中，若检测到缓存到本地的第二url对应的业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔，为保证数据的实时性，则重新基于第二url发起数据资源获取请求，并在业务模板界面加载接收到的业务数据。

综上，在业务模板界面加载的业务数据，可能包括以下几种情况：

情况一、基于第二url已发起数据资源获取请求，且并未接收到服务器基于该数据资源获取请求反馈的业务数据。

情况二、基于第二url已发起数据资源获取请求，且在本地缓存中已存储有该数据资源获取请求对应的业务数据，且该业务数据的接收时刻与当前时刻之间的时间间隔小于或等于预设时间间隔。

情况三、基于第二url已发起数据资源获取请求，在本地缓存中已存储有该数据资源获取请求对应的业务数据，且该业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔。

由于获取业务数据与加载业务模板界面是同步执行的，若业务模板界面的加载时间过程，例如为10s，而获取业务数据所需要的时间为2s，则在业务模板界面加载业务数据时，本地缓存的业务数据为当前时刻之前8s的业务数据，由于数据变化较频繁，因此，在业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔时，可以重新基于第二url发起数据资源获取请求，以重新获取第二url对应的业务数据，进而保证业务数据的实时性。

在一种可能的实施方式中，在接收到任一数据资源请求对应的业务数据后，可以将数据资源获取请求对应的业务数据缓存在本地，而为了提高缓存在本地的业务数据的利用率，可以当接收业务数据的时刻与当前时刻之间的时间间隔大于预设时间间隔时，将缓存的业务数据、该业务数据对应的数据资源获取请求删除。

本公开实施例所提供的数据加载方法，在检测到针对目标链接的点击操作之后，从服务器获取与该目标链接对应的html文档，并根据html文档加载业务模板界面，在获取html文档的同时，确定与目标链接对应的url，并根据url发起数据资源获取请求，在加载完业务模板界面之后可以直接根据接收到的业务数据加载业务数据，由于加载业务模板界面与请求业务数据是同步进行的，因此较少了数据加载过程中的等待时间，提高了数据加载的效率。

在本公开实施例一种实施方式下，在业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔时，会将缓存在本地的业务数据删除，并重新发起获取业务数据的请求，从而保证了界面加载的业务数据的实时性。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与数据加载方法对应的数据加载装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述数据加载方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图3所示，为本公开实施例提供的一种数据加载装置的示意图，所述装置包括：处理模块301、加载模块302；其中，

处理模块301，用于响应目标链接的点击操作，获取所述目标链接对应的超文件标记语言html文档，并根据所述html文档加载业务模板界面；以及，基于所述目标链接，确定所述目标链接对应的至少一个第一统一资源定位符url，并基于所述至少一个第一url发起数据资源获取请求；

加载模块302，用于在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据。

一种可能的实施方式中，所述处理模块301，在根据所述目标链接，确定所述目标链接对应的至少一个第一url时，用于：

根据所述目标链接，查找预先为所述目标链接配置的所述至少一个第一url。

一种可能的实施方式中，所述加载模块302，在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据时，用于：

在加载完所述html文档所对应的业务模板界面之后，确定所述html文档对应的第二url；所述第二url属于所述至少一个第一url；

在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，所述加载模块302，在所述业务模板界面加载接收到的所述第二url对应的业务数据时，用于：

在基于所述至少一个第一url发起数据资源获取请求后，从缓存到本地的所述数据资源获取请求对应的业务数据中，获取所述第二url对应的业务数据，在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，所述处理模块301，还用于：

若检测到缓存到本地的所述第二url对应的业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔，基于所述第二url再次发起数据资源获取请求，并在所述业务模板界面加载接收到的业务数据。

一种可能的实施方式中，所述处理模块301，还用于：

所述数据资源获取请求缓存在本地；在接收到所述数据资源获取请求对应的业务数据后，将该数据资源获取请求对应的业务数据缓存在本地；

当检测到接收所述业务数据的时刻与当前时刻之间的时间间隔大于预设时间间隔时，将缓存的所述业务数据、该业务数据对应的数据资源获取请求删除。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

基于同一技术构思，本申请实施例还提供了一种电子设备。参照图4所示，为本申请实施例提供的电子设备的结构示意图，包括处理器401、存储器402、和总线403。其中，存储器402用于存储执行指令，包括内存4021和外部存储器4022；这里的内存4021也称内存储器，用于暂时存放处理器401中的运算数据，以及与硬盘等外部存储器4022交换的数据，处理器401通过内存4021与外部存储器4022进行数据交换，当电子设备400运行时，处理器401与存储器402之间通过总线403通信，使得处理器401在执行以下指令：

响应目标链接的点击操作，获取所述目标链接对应的超文件标记语言html文档，并根据所述html文档加载业务模板界面；以及，基于所述目标链接，确定所述目标链接对应的至少一个第一统一资源定位符url，并基于所述至少一个第一url发起数据资源获取请求；

在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据。

一种可能的实施方式中，处理器401执行的指令中，所述根据所述目标链接，确定所述目标链接对应的至少一个第一url，包括：

根据所述目标链接，查找预先为所述目标链接配置的所述至少一个第一url。

一种可能的实施方式中，处理器401执行的指令中，所述在根据所述html文档加载完所述业务模板界面，并接收到所述数据资源获取请求对应的业务数据之后，在所述业务模板界面加载所述业务数据，包括：

在加载完所述html文档所对应的业务模板界面之后，确定所述html文档对应的第二url；所述第二url属于所述至少一个第一url；

在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，处理器401执行的指令中，所述在所述业务模板界面加载接收到的所述第二url对应的业务数据，包括：

在基于所述至少一个第一url发起数据资源获取请求后，从缓存到本地的所述数据资源获取请求对应的业务数据中，获取所述第二url对应的业务数据，在所述业务模板界面加载接收到的所述第二url对应的业务数据。

一种可能的实施方式中，处理器401执行的指令中，所述方法还包括：

若检测到缓存到本地的所述第二url对应的业务数据的接收时刻与当前时刻之间的时间间隔大于预设时间间隔，基于所述第二url再次发起数据资源获取请求，并在所述业务模板界面加载接收到的业务数据。

一种可能的实施方式中，处理器401执行的指令中，所述方法还包括：

所述数据资源获取请求缓存在本地；在接收到所述数据资源获取请求对应的业务数据后，将该数据资源获取请求对应的业务数据缓存在本地；

当检测到接收所述业务数据的时刻与当前时刻之间的时间间隔大于预设时间间隔时，将缓存的所述业务数据、该业务数据对应的数据资源获取请求删除。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的数据加载方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例所提供的数据加载方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行上述方法实施例中所述的数据加载方法的步骤，具体可参见上述方法实施例，在此不再赘述。

本公开实施例还提供一种计算机程序，该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(softwaredevelopmentkit，sdk)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。