CN106504026A - 一种数据获取方法和装置 - Google Patents

Abstract

本申请提供一种数据获取方法和装置，所述方法包括：接收到用户的应用启动指令时，检测所述应用所在设备是否存储有目标数据；如果有，则读取所述目标数据，基于所述目标数据更新所述应用的界面；所述目标数据为接收到用户的应用启动指令之前，向服务器请求并存储于所述应用所在设备的目标数据。本申请实施例可以保证数据获取的实时性。

Description

一种数据获取方法和装置

技术领域

本申请涉及通信技术领域，尤其涉及一种数据获取方法和装置。

背景技术

移动设备上的大部分应用(Application)，在启动时会通过网络向服务器请求闪屏广告数据并展示给用户。闪屏广告数据需要不定期的更新，该闪屏广告数据需要在客户端做到最大程度的实时、准确的展示给用户。但是在用户启动应用如此短暂的时间内，往往因为网络延迟或者数据量过大等原因造成闪屏广告数据无法返回，用户需要等待一段时间。

发明内容

有鉴于此，为解决相关技术中的问题，本申请提供一种数据获取方法及装置。

根据本申请实施例的第一方面，提供一种数据获取方法，该方法包括步骤：

接收到用户的应用启动指令时，检测所述应用所在设备是否存储有目标数据；

如果有，则读取所述目标数据，基于所述目标数据更新所述应用的界面；所述目标数据为接收到用户的应用启动指令之前，向服务器请求并存储于所述应用所在设备的目标数据。

根据本申请实施例的第二方面，提供一种数据获取装置，包括：

数据请求模块，被配置为在接收到用户的应用启动指令之前，向服务器请求目标数据；

数据存储模块，被配置为存储服务器返回的目标数据；

数据检测模块，被配置为在接收到用户的应用启动指令时，检测数据存储模块是否存储有目标数据；

数据读取更新模块，被配置为如果检测到数据存储模块存储有目标数据，则读取所述目标数据，基于所述目标数据更新所述应用的界面。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请中，并非是在应用启动时才连接网络向服务器请求数据，而是在应用启动之前就向服务器请求并存储数据到应用所在设备，应用接收到用户的启动指令时，可以直接从应用所在设备获取数据，保证了数据获取的实时性。

附图说明

图1a为本申请实施例中一应用环境的网络图。

图1b为闪频广告展示示意图。

图2a为本申请实施例中一种数据获取方法的部分流程图。

图2b为本申请实施例中一种向服务器请求目标数据并存储于应用所在设备的方法的流程图。

图2c为本申请实施例中设置应用被IOS系统唤醒的方法流程图。

图2d为本申请实施例中另一种向服务器请求目标数据并存储于应用所在设备的方法的流程图。

图2e为本申请实施例中另一种数据获取方法的部分流程。

图2f为本申请实施例中一种数据获取方法的流程图。

图3为本申请实施例中一种数据获取装置的框图。

图4为本申请实施例中另一种数据获取装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1a是一种网络示意图。移动设备100通过网络110与服务器120连接，移动设备100具有操作系统。移动设备100上可以安装应用(Application，APP)，比如社交APP(YY、QQ)、音频播放APP(酷我、酷狗)、视频播放APP(暴风影音、腾讯视频)。对于某些APP，用户在启动APP后需要获取一些具有实时性的数据，比如闪屏广告数据，以向用户推广即将上映的电影、新发行的歌曲、某网站优惠活动、节日祝福等，图1b为用户启动手机上某一应用时展现的中秋祝福的闪屏广告数据。但是这类需要实时性的数据现有的处理方式是在用户启动应用后，再通过网络从服务器获得更新的数据，这往往会因为网络延迟或者数据量过大造成用户需要有一段等待的时间，导致数据传输的延迟，影响用户使用应用的体验。

本申请实施例所提供的技术方案可以解决这一技术问题。与传统方法中的打开应用后再连接网络向服务器请求数据的方法不同，本申请采用预先加载的方式，在应用收到用户的启动指令之前，就向服务器请求并存储数据于应用所在设备，在应用收到用户的启动指令时，直接从应用所在设备获取数据，从而提高了数据获取的实时性。接下来对本申请进行详细说明。

如图2a所示，图2a是本申请一示例性实施例示出的一种数据获取方法的部分流程图，可以用在移动设备上，包括以下步骤S201至S202：

在步骤S201中，接收到用户的应用启动指令时，检测所述应用所在设备是否存储有目标数据。

在步骤S202中，如果有，则读取所述目标数据，基于所述目标数据更新所述应用的界面；所述目标数据为接收到用户的应用启动指令之前，向服务器请求并存储于所述应用所在设备的目标数据。

其中，移动设备可以是智能手机、平板电脑、音乐播放器、电子书阅读器或个人数字助理等移动平台，且该移动设备具有操作系统，操作系统可以是Android系统或IOS系统。

在本申请中，目标数据可以是服务器提供的具有实时性的数据，作为一个例子目标数据可以是闪屏广告数据。闪屏广告是指在用户启动应用(比如腾讯新闻APP、天天快报APP)时加载，展示时间固定(比如5秒)，广告可点击，支持定向投放，展示完毕后自动关闭并进入应用主页面的一种广告形式。闪屏广告数据由应用对应的服务器提供，一般一个应用对应一个服务器，如果一个服务器同时为多个应用提供闪屏广告数据，则由服务器区分闪屏广告数据对应的应用。闪屏广告数据还要求一定的实时性，要求用户在打开应用的第一时间就能看到，但是往往会由于网络延迟或者数据量过大造成用户需要有一段等待的时间。本申请提供的实施例可以有效提高数据获取的实时性。

在本申请中，应用向服务器请求目标数据并将所述目标数据存储于应用所在设备的实现方式有多种可能，例如，可以通过将处于休眠状态的应用唤醒，并执行获取和存储数据的过程，此过程可以参考图2b中的步骤S201b至S203b：

在步骤S201b中，所述应用处于休眠状态时，每隔第一预设时间间隔被唤醒后，向服务器发出请求，请求服务器的目标数据。

在步骤S202b中，如果服务器返回目标数据，则所述应用在将收到的目标数据存储于所述应用所在设备后，回到休眠状态。

在步骤S203b中，如果服务器未返回目标数据，则所述应用回到休眠状态。

在一个实施例中，图2b所描述的用来唤醒应用的可以是系统，该系统可以是IOS系统，但并不排除其他类型的操作系统。通过IOS系统唤醒应用的过程可以参考以下描述：

在IOS系统中，Apple(苹果)官方为开发者提供了两个可以在后台更新应用程序界面和内容的API(Application Programming Interface，应用程序编程接口)。其中一个API是后台获取(Background Fetch)，该API允许开发者在一个周期间隔后进行特定的动作，比如获取数据、更新程序界面等等。开发者利用该API为程序配置后台模式，设定获取时间间隔，就可以使应用程序在预设时间间隔到达后被系统唤醒，从而应用可以在后台完成请求和存储数据。

在IOS系统中，利用IOS系统提供的后台获取(Background fetch)技术实现应用被唤醒的操作，可参考图2c，包括以下步骤，S201c至S202c：

在步骤S201c中，利用Background fetch技术预先为程序配置后台模式。具体如下：

打开苹果的IDE X CODE，创建一个新项目；

打开Capabilities页面下的Background Modes选项，并勾选Background fetch选项。

在步骤S202c中，通过对应用的UIApplication实例进行设置完成第一预设时间间隔的设置。一般在应用启动的时候调用以下代码：

[[UIApplication sharedApplication]

setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum]；

通过该接口应用可以设置请求目标数据的最小时间间隔，将此最小时间间隔作为第一时间间隔。第一时间间隔可以根据目标数据的更新频率来确定，如果目标数据更新频率较快，最小时间间隔可以比较小，比如可以是1小时或0.5小时；如果目标数据更新频率较慢，最小时间间隔可以比较大，比如1天或者0.5天。

某些例子中，按照第一预设时间间隔获取目标数据，还可以考虑其他一些前提因素，比如移动设备用电情况、所处网络环境等，可以根据这些因素来确定在第一预设时间间隔到达时是否唤醒应用。如果电量过低或者网络状况不好，就不唤醒应用；如果电量充足或者网络状况良好，就按照第一预设时间间隔进行预设操作。

完成以上两步后，就可以实现唤醒应用的操作，应用被唤醒后，执行获取和存储数据的过程，存储数据结束后，可以通知系统获取结束，以便使应用尽快回到休眠状态，节约资源(步骤S202b)。如果请求数据失败，服务器未返回目标数据(比如服务器未接收到请求或者服务器未返回目标数据或者应用未收到服务器返回的目标数据等)，也可以通知系统获取结束，使应用回到休眠状态(步骤S203b)。作为一个例子，可以在请求数据失败1分钟后使应用回到休眠状态。

某些例子中，所述向服务器请求目标数据并存储于应用所在设备的实现方式还可参考图2d中的步骤S201d至S202d：

在步骤S201d中，与所述应用对应的常驻内存服务，每隔第二预设时间间隔向服务器发出请求，请求服务器的目标数据；所述常驻内存服务在接到用户的应用启动指令之前完成注册。

在步骤S202d中，所述常驻内存服务在收到服务器返回的目标数据后，将收到的目标数据存储于所述应用所在设备。

图2d中的系统可以以Android系统为例，Android系统为开发者提供了服务常驻内存技术，可以通过该技术为应用创建对应的常驻内存服务，这样即使应用的进程退出时，该常驻内存服务仍然处于运行状态，从而可以完成后台更新数据的目的。在应用接收到用户的启动指令之前应用对应的常驻内存服务已被注册，以便提前请求目标数据并存储于应用所在设备。

通过常驻内存服务获取数据，需要每个应用都注册一个常驻内存服务，当常驻内存服务过多时可能造成内存不足、系统运行较慢，因此可以只对重要的应用创建常驻内存服务或者限制常驻内存服务的数量，以保证系统运行流畅。

在注册常驻内存服务时，还需要开发人员设置请求数据的第二预设时间间隔，可以在程序内设置一定时器，循环检查，当第二预设时间间隔到达时，执行请求数据操作。

在本申请中，移动平台所处的网络可以是2G/3G/4G或WiFi，可以允许设定在WiFi下请求并缓存数据，以节省用户流量。

在本申请中，将收到的目标数据存储于应用所在设备，以便应用接收到用户的启动指令时可以从应用所在设备读取数据，提高数据的实时性。为此，需要对存储在应用所在设备的目标数据需要进行管理。在一个实施例中，将目标数据存储于应用所在设备，删除历史目标数据，以减少对设备内存的占用。目标数据还可以有有效期，可以根据目标数据的有效期管理目标数据，对于超过有效期的目标数据就删除不再存储。该有效期由开发人员设定，可以是任意一段时间。作为一个例子，目标数据A有效期为3天，如果在这3天内未检测到新的目标数据B，应用所在设备会一直存储目标数据A，当3天有效期到后应用所在设备删除目标数据A，此时应用所在设备没有任何目标数据；如果3天内检测到新的目标数据B，应用存储目标数据B到应用所在设备，也会将目标数据A删除，此时应用所在设备只存储目标数据B。

如图2e所示为，为本申请实施例示出的另一种网络数据获取方法的部分流程图，在图2a所述的基础上，还包括步骤S203至S204：

在步骤S203中，检测到所述应用所在设备未存储有目标数据，则所述应用向服务器发出请求，请求服务器的目标数据；

在步骤S204中，如果服务器返回目标数据，则读取所述目标数据，基于所述目标数据更新所述应用的界面，并将所述目标数据存储于所述应用所在设备。

在本申请中，如果应用未启动之前向服务器请求目标数据失败(即服务器未返回目标数据)，并且存储于应用所在设备的历史目标数据因为超过有效期而被删除，在应用启动时检测到应用所在设备未存储有目标数据，这时应用会再次向服务器请求目标数据，如果服务器返回目标数据，则读取所述目标数据，更新应用的界面；如果服务器未返回目标数据，则直接进入应用主界面。

下面以应用为例进行说明，该应用可以是手机应用YY，该手机可以是Android系统，处于WiFi环境下，YY对应的服务器提供目标数据A(目标数据A可以是中秋祝福语)。YY在接收到用户的启动指令之前已经完成对应常驻内存的注册，因此能够按照预设时间间隔(比如，可以是5小时)向服务器请求目标数据。如图2f所示，图2f是本申请一实施例的流程图，包括步骤S201f至S210f：

步骤S201f，YY接收到用户的启动指令之前，如果预设时间间隔到达，YY对应的常驻内存服务向服务器请求目标数据。

服务器收到请求后做出反应，转入步骤S202f，根据请求结果决定下一步。如果请求目标数据成功，服务器返回目标数据A，转到步骤S203f，YY存储目标数据A到手机，将历史目标数据删除，然后转到步骤S204f；如果请求不成功，服务器未返回目标数据，直接转到步骤S204f。

步骤S204f，YY接收到用户的启动指令。

检测手机是否有存储有目标数据(步骤S205f)，如果检测到目标数据A，则从读取目标数据A，基于目标数据A更新YY的界面(步骤S206f)；如果请求目标数据失败，检测手机未存储有目标数据，则转到步骤S207f。

步骤S207f，YY再次向服务器请求目标数据。

步骤S208f，判断请求是否成功，如果请求成功，服务器返回目标数据A，则转入步骤S209f，下载目标数据A，基于目标数据A更新YY的界面；如果请求不成功，服务器未返回目标数据，则转入步骤S210f，直接进入YY的主界面。

与前述数据获取方法的实施例相对应，本申请还提供了数据获取装置的实施例。

请参考图3，数据获取装置300包括：

数据请求模块301，被配置为在收到用户的启动指令之前，向服务器请求目标数据；

数据存储模块302，被配置为将服务器返回的目标数据存储于所述应用所在设备；

数据检测模块303，被配置为在接收到用户的应用启动指令时，检测所述应用所在设备是否存储有目标数据；

数据读取更新模块304，被配置为如果检测到所述应用所在设备存储有目标数据，则读取所述目标数据，更新所述应用的界面。

在一个可选的实现方式中，数据请求模块301具体用于：

所述应用处于休眠状态时，每隔第一预设时间间隔被唤醒后，向服务器发出请求，请求服务器的目标数据；或

与所述应用对应的常驻内存服务，每隔第二预设时间间隔向服务器发出请求，请求服务器的目标数据；所述常驻内存服务在接到用户的应用启动指令之前完成注册。

在一个可选的实现方式中，数据请求模块301还用于当检测到数据存储模块未存储有目标数据时，所述应用向服务器发出请求，请求数据。

如图4所示，为本申请根据一示例性实施例示出的另一种获取装置的框图，所述装置在图3所示的实施例的基础上还包括状：

状态检测模块305，被配置为在所述第一预设时间间隔到达且所述应用被唤醒之前，检测所述设备的电量或所处网络的信号强度，检测结果被用于确定是否唤醒所述应用。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (11)

1.一种数据获取方法，其特征在于，所述方法包括步骤：

接收到用户的应用启动指令时，检测所述应用所在设备是否存储有目标数据；

如果有，则读取所述目标数据，基于所述目标数据更新所述应用的界面；所述目标数据为接收到用户的应用启动指令之前，向服务器请求并存储于所述应用所在设备的目标数据。

2.如权利要求1所述的方法，其特征在于，所述目标数据包括闪屏广告数据。

3.如权利要求1所述的方法，其特征在于，向服务器请求目标数据并存储于所述应用所在设备，包括：

所述应用处于休眠状态时，每隔第一预设时间间隔被唤醒后，向服务器发出请求，请求服务器的目标数据；

如果服务器返回目标数据，则所述应用在将收到的目标数据存储于所述应用所在设备后，回到休眠状态；

所述方法还包括，如果服务器未返回目标数据，则所述应用回到休眠状态。

4.如权利要求3所述的方法，其特征在于，所述第一预设时间间隔到达且所述应用被唤醒之前，还包括：

检测所述设备的电量或所处网络的信号强度，并基于所述电量或所述信号强度确定是否唤醒所述应用。

5.如权利要求1所述的方法，其特征在于，向服务器请求目标数据并存储于所述应用所在设备，包括：

与所述应用对应的常驻内存服务，每隔第二预设时间间隔向服务器发出请求，请求服务器的目标数据；所述常驻内存服务在接到用户的应用启动指令之前完成注册；

所述常驻内存服务在收到服务器返回的目标数据后，将收到的目标数据存储于所述应用所在设备。

6.如权利要求1所述的方法，其特征在于，所述方法还包括：

检测到所述应用所在设备未存储有目标数据，则所述应用向服务器发出请求，请求服务器的目标数据；

如果服务器返回目标数据，则读取所述目标数据，基于所述目标数据更新所述应用的界面，并将所述目标数据存储于所述应用所在设备。

7.一种数据获取装置，其特征在于，所述装置包括：

数据请求模块，被配置为在接收到用户的应用启动指令之前，向服务器请求目标数据；

数据存储模块，被配置为存储服务器返回的目标数据；

数据检测模块，被配置为在接收到用户的应用启动指令时，检测数据存储模块是否存储有目标数据；

数据读取更新模块，被配置为如果检测到数据存储模块存储有目标数据，则读取所述目标数据，基于所述目标数据更新所述应用的界面。

8.如权利要求7所述的装置，其特征在于，所述目标数据包括闪屏广告数据。

9.如权利要求7所述的装置，其特征在于，所述数据请求模块具体用于：

所述应用处于休眠状态时，每隔第一预设时间间隔被唤醒后，向服务器发出请求，请求服务器的目标数据；或

与所述应用对应的常驻内存服务，每隔第二预设时间间隔向服务器发出请求，请求服务器的目标数据；所述常驻内存服务在接收到用户的应用启动指令之前完成注册。

10.如权利要求9所述的装置，其特征在于，所述装置还包括：

状态检测模块，被配置为在所述第一预设时间间隔到达且所述应用被唤醒之前，检测所述设备的电量或所处网络的信号强度，检测结果被用于确定是否唤醒所述应用。

11.如权利要求9所述的装置，其特征在于，所述数据请求模块还被配置为当检测到数据存储模块未存储有目标数据时，所述应用向服务器发出请求，请求数据。