CN111182526A - 数据更新方法、移动终端以及计算机存储介质 - Google Patents

Abstract

本申请提供了一种数据更新方法、移动终端以及计算机存储介质。该数据更新方法包括：接收服务器发送的目标数据更新信息；获取目标数据的预估更新时长；判断目标数据的预估更新时长是否满足设定要求；若是，自动对目标数据进行更新。上述数据更新方法可以根据更新的目标数据信息自动对目标数据进行更新，从而减少数据更新任务占用用户对移动终端的使用时间。

Description

数据更新方法、移动终端以及计算机存储介质

技术领域

本申请涉及信息技术领域，特别是涉及一种数据更新方法、移动终端以及计算机存储介质。

背景技术

随着信息技术的不断发展，终端设备的功能越来越强大。终端设备能够承载各种各样的数据，从而执行数据满足用户各种各样的需求。为了满足用户不断的需求，数据提供商通常向终端设备推送目标数据的更新信息。

目前，由于目标数据越来越庞杂，目标数据的下载或数据更新时间过长，用户遇上数据更新的情况需要等待很长的时间，导致占用用户大量的使用时间，不利于提高用户体验。

发明内容

本申请提供了一种数据更新方法、移动终端以及计算机存储介质，主要解决的技术问题是如何减少更新任务占用用户对终端设备的使用时间，提高用户体验。

为解决上述技术问题，本申请提供了一种数据更新方法，所述数据更新方法包括：

接收服务器发送的目标数据更新信息；

获取所述目标数据的预估更新时长；

判断所述目标数据的预估更新时长是否满足设定要求；

若是，自动对所述目标数据进行更新。

为解决上述技术问题，本申请还提供了一种移动终端，所述移动终端包括处理器以及与所述处理器耦接的存储器、通信模组；

其中，所述存储器用于存储程序数据，所述处理器用于执行所述程序数据以实现如上述的数据更新方法。

为解决上述技术问题，本申请还提供了一种计算机存储介质，所述计算机存储介质用于存储程序数据，所述程序数据在被处理器执行时，用以实现如上述的数据更新方法。

与现有技术相比，本申请的有益效果是：接收服务器发送的目标数据更新信息；获取目标数据的预估更新时长；判断目标数据的预估更新时长是否满足设定要求；若是，自动对目标数据进行更新。在上述交互过程中，当移动终端接收到目标数据更新信息时，移动终端分析目标数据更新信息，根据目标数据的大小或环境网络下载速度等信息获取目标数据的预估更新时长；移动终端判断目标数据的预估更新时长是否满足设定要求，并根据判断结构自动对目标数据进行更新。在这个过程中，移动终端接收目标数据更新信息，并根据目标数据更新信息自动更新目标数据，不需要用户参与，也不会占用用户对移动终端的使用时间。

附图说明

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

图1是本申请数据更新方法第一实施例的流程示意图；

图2是图1中数据更新系统的结构示意图；

图3是本申请数据更新方法第二实施例的流程示意图；

图4是本申请数据更新方法第三实施例的流程示意图；

图5是本申请数据更新方法第四实施例的流程示意图；

图6是本申请移动终端一实施例的结构示意图；

图7是本申请计算机存储介质一实施例的结构示意图。

具体实施方式

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

本申请提出了一种应用于移动终端的数据更新方法，通过该数据更新方法可以实现移动终端中目标数据的自动更新；例如，通过本实施例的数据更新方法可以实现和用于应用程序中大量目标数据的自动更新。

具体请参见图1和图2，图1是本申请数据更新方法第一实施例的流程示意图，图2是图1中数据更新系统的结构示意图。

本实施例的数据更新方法应用于数据更新系统20，如图2所示，数据更新系统20至少包括移动终端21和服务器22，其中，移动终端21与服务器22建立通信连接。

数据更新系统20中的移动终端21可为智能手机、笔记本、平板电脑或者车载电脑等；进一步地，移动终端21可搭载安卓操作系统或IOS操作系统等。

如图1所示，结合图2的结构示意图，该数据更新方法包括以下步骤：

S11：接收服务器发送的目标数据更新信息。

其中，移动终端21接收服务器22发送的目标数据更新信息，该目标数据更新信息用于更新移动终端21的操作系统或者应用程序。

本申请实施例的执行主体的更新装置可为移动终端21的功能模块。移动终端21可搭载Linux操作系统、IOS操作系统或安卓操作系统等，移动终端21上可安装多个应用程序，在日常生活中，服务器22需要随时提高操作系统或者应用程序的服务质量，此时，服务器22对操作系统或者应用程序进行更新，并将相关更新信息发送给对应的移动终端21。

其中，目标数据更新信息可以包括应用程序的版本信息、新增功能信息、缺陷修复信息或/和界面更新信息等；目标数据更新信息也可以包括操作系统的版本信息、新增功能信息、缺陷修复信息或/和界面更新信息等。

以应用程序更新为例，在IOS系统中，应用程序的更新信息一般在APP store中进行提示，在安卓系统中，应用程序的更新信息一般在安卓应用商城中进行提供。

S12：获取目标数据的预估更新时长。

可选的，在一实施例中，上述步骤S11中的更新信息包含了更新数据所需要下载的数据量。进一步，获取当前的网络下载速率，基于当前的下载速率对数据更新时长进行预估。例如，目标数据的数据量为200M，当前的下载速率为2M/s，那么，预估的时长为200/2＝100s。另外，可以根据实时下载速率的变化对预估的剩余时长进行实时的更新。例如，前述200M的数据量已下载了100M，还剩下200M还未进行下载，此时的下载速率变为1.5M/s，那么将更新剩余的下载时间为100/1.5＝66.7s。

在上述的例子中，下载速率也可以采用与网络制式相匹配的设定速度进行预估。例如，分别为2G、3G、4G、5G、WIFI或热点预先设置一相对应的下载速率，预设的下载速率可以基于历史下载情况来获得，然后判断当前的网络制式，采用当前网络制式相对应的下载速率进行预估。

可选的，在另一实施例中，上述步骤S11中的更新信息包含了预估更新时长，该预估更新时长是服务器获取的多个移动终端更新相应的目标数据时所使用的时长的平均值。例如每一移动终端在更新完一个应用程序之后，将该应用程序的更新时长上传至服务器，服务器基于所有上传的更新时间得到一平均时长作为该应用程序的预估更新时长。当然，在获取平均时长时，也可以将一些不满足要求的时长去掉，例如显然不符合实际的超过设定阈值的时长。

目标数据的预估更新时长为目标数据开始更新到更新结束的时间，其中，预设误差时间可设置为正负5分钟或者其它时间。

S13：判断目标数据的预估更新时长是否满足设定要求。

其中，获取目标数据的预估更新时长后，移动终端21进一步判断目标数据的预估更新时长是否满足设定要求。预设的设定要求可为预估更新时长小于或等于预设时长。具体地，可以设置一规则，例如，预估更新时长小于或等于30分钟的情况下，移动终端对该应用进行自动更新，在预估更新时长大于30分钟的情况下，移动终端需要接收用户的更新指令来进行手动更新。可选的，在自动更新的情况下，还可以设置一条件，即在WIFI模式下，才进行自动更新。

在另一实施例中，设定要求可以是目标数据的更新不影响用户正常使用移动终端。例如，在一应用场景中，用户设置的移动终端的闹铃为7点，并且，用户在闹铃响了之后会操作移动终端进行上网。那么，如果在6点获取了应用程序的更新信息，并且确定其预估的更新时长大于1个小时，那么在用户7点使用移动终端时，该应用程序很有可能还没有更新完成，会影响用户上网，所以，在这种情况下，可以确定该预估更新时长不满足设定要求。

若预估更新时长不满足设定要求，移动终端21不对目标数据进行自动更新，通过内容推送或消息提醒的方式通知用户移动终端21有需要更新的目标数据，并标注预估更新时长，询问是否允许更新对应的目标数据。若预估更新时长满足设定要求，则进入步骤S14。

S14：自动对目标数据进行更新。

其中，当预估更新时长满足设定要求时，移动终端21自动对目标数据进行更新。在更新过程中，移动终端21缓存与用户相关的用户信息和使用记录，并通过后台通知的方式显示剩余的更新数据大小和剩余预估更新时长，以便用户打开移动终端21时，能够第一时间查看更新的进程。

在更新结束后，移动终端21将缓存的用户信息和使用记录重新加载到更新后的操作系统或应用程序中。进一步地，通过内容推送或消息提醒的方式通知用户移动终端21更新完成，并且列举更新内容和对应的功能效果。

进一步地，本实施例的更新任务还可包括下载任务和安装任务。

具体地，移动终端21自动对目标数据进行更新，即移动终端21自动执行目标数据对应的下载任务，从服务器22下载更新数据包；并在下载任务完成后，执行安装任务，以安装更新数据包并覆盖原始版本的操作系统或应用程序；在安装任务完成后，移动终端21删除更新数据包，以清除缓存数据。

或者，移动终端21自动从服务器22中下载更新数据包，并将更新数据包存储在存储区中；在移动终端21被唤醒时，移动终端21弹出安装进程，并通过接收对应的用户指令，确定是否执行安装任务。进一步地，移动终端21在弹出安装进程时，还可以显示更新内容和对应的功能效果，以供用户查看更新内容和更新功能；通过在安装进程中获取用户指令，移动终端21根据用户指令安装更新数据包或者删除更新数据包，以保持原有的操作系统或应用程序。

在本实施例中，移动终端21从服务器22中获取目标数据更新信息，并根据目标数据更新信息判断是否自动更新对应的更新数据。在非用户时间段内，移动终端21可以根据更新的目标数据信息自动对目标数据进行更新，从而减少数据更新任务占用用户对移动终端的使用时间。

基于图1所示的数据更新方法实施例，本申请进一步提出另一实施例的数据更新方法，可参阅图3，图3是本申请数据更新方法第二实施例的流程示意图。

本实施例的数据更新方法应用于上述实施例的数据更新系统20，数据更新系统20的具体结构请参阅上述图2，在此不再赘述。

在上述实施例的数据更新方法步骤11之后，本实施例的数据更新方法包括以下步骤：

S21：获取目标数据的历史使用记录。

其中，在从服务器22获取目标数据后，移动终端21根据目标数据获取预设时间段内的历史使用记录。历史使用记录可包括历史使用次数、历史使用总时长、历史使用时间段等数据。

S22：基于历史使用记录，判断目标数据的总使用频率是否大于第一设定频率阈值。

其中，根据历史使用记录的数据，移动终端21判断目标数据的总使用频率是否大于预设频率阈值，从而将该移动终端21划分为高粘度用户或低粘度用户。具体地，当目标数据的总使用频率大于第一设定频域阈值时，移动终端21划分为高粘度用户；当目标数据的总使用频率小于第一设定频域阈值时，移动终端21划分为低粘度用户。

用户粘度用于表征用户对于品牌或产品的忠诚、信任与良性体验等结合起来形成的依赖程度和再消费期待程度。在本实施例中，使用用户粘度来表征用户对某个应用程序的使用频率，例如，高粘度用户对该应用程序在一定时间内有很高的使用频率；低粘度用户对该应用程序在一定时间内的使用频率较低，甚至低粘度用户在一定时间内没有使用过该应用程序。

本实施例的数据更新方法依据不同用户粘度的用户特性分别对目标数据采取不同的处理方法。进一步地，预设频率阈值可以设置多个，用于区分高粘度用户、中粘度用户和低粘度用户。以游戏应用程序为例，高粘度用户每天都使用该游戏应用程序，并使用较长的时间；中粘度用户在一周的时间内有是使用该游戏应用程序的记录，但次数较少或总使用时间较短；低粘度用户在一个月的时间内才有一到两次使用该游戏应用程序的记录，总使用时间很短。

当移动终端21根据目标数据对应的历史使用记录划分为低粘度用户时，移动终端21不会立即对目标数据进行处理，采取每周或每月提示用户及时更新的方式在移动终端21的界面上显示。当移动终端21根据目标数据对应的历史使用记录划分为中粘度用户时，移动终端21在被唤醒时立即给予用户及时更新，并以弹框状态栏显示，进一步地，当移动终端21通过弹框状态栏接收包含允许更新的用户指令时，进入步骤S23；当移动终端21根据目标数据对应的历史使用记录划分为高粘度用户时，进入步骤S23。

S23：获取目标数据的预估更新时长。

经过上述步骤，移动终端21划分为高粘度用户或得到允许更新的用户指令时，移动终端21根据终端环境数据获取目标数据的预估更新时长。获取目标数据的预估更新时长的具体步骤可参阅下述步骤S231和S232。

S231：获取目标程序的更新数据量以及当前的网络状态。

获取目标数据后，移动终端21根据目标数据获取对应目标程序所需的更新数据量大小和当前的网络状态。其中，网络状态包括移动终端21连接的网络类型，例如，移动终端21使用SIM卡的流量套餐连接移动网络和移动终端21连接无线网络。进一步地，移动终端21获取连接的移动网络或者无线网络在一定时间段内的平均下载速度。

当移动终端21使用移动网络数据时，移动终端21获取当前的套餐流量，并根据目标程序所需的更新数据量大小判断更新后，移动终端21的剩余流量是否大于预设监控流量。若更新后，移动终端21的剩余流量大于预设监控流量，则进入步骤232。若更新后，移动终端21的剩余流量小于预设监控流量，则移动终端21暂停数据更新方法，并自动打开无线网络服务，以连接无线网络；成功连接无线网络后，移动终端21重启数据更新方法，并进入步骤S232。在其它实施例中，移动终端21接收服务器22发送的目标更新信息后，先判断移动终端21是否连接上无线网络，若没有连接无线网络，则自动打开无线网络，搜索并连接附近可连接的无线网络，以确保移动终端21顺利完成更新任务和尽量减少移动终端21的更新成本。

当移动终端21使用无线网络数据时，移动终端21获取连接的无线网络一段时间内的平均下载速度，并检测无线网络的下载情况是否稳定；当连接的无线网络的平均下载速度低于预设的下载速度或者下载情况波动很大时，移动终端21断开该无线网络，搜索并连接附近可连接的其它无线网络，以获取更好的网络下载环境。

进一步地，本实施例的数据更新方法也可以将应用程序进行分类，分为高粘度应用程序和低粘度应用程序。根据不同种类的应用程序，数据更新方法采用不同的数据获取途径，例如，在无线网络和移动网络下，移动终端21都可以进行高粘度应用程序的自动更新，而低粘度应用程序只能在无线网络下更新。

S232：基于更新数据量和网络状态，确定目标数据的预估更新时长。

其中，移动终端21获取更新数据量大小和网络状态后，根据更新数据量和网络状态确定目标数据的预估更新时长。

具体地，根据目标数据的更新数据量大小和当前网络环境的平均下载速度，移动终端21计算得到目标数据的更新时长。移动终端21在计算的更新时长的基础上，还可以累加上1～5分钟的误差时长，以得到目标数据的预估更新时长。

在本实施例中，移动终端21根据目标数据的历史使用记录获取对应的历史使用记录，并通过历史使用记录判断更新目标数据的重要程度，以确保更新重要的目标数据，提高数据更新方法的针对性；对于使用记录较多的目标数据，移动终端21实时获取更新数据量大小和当前的网络状态，从而推测出目标数据的预估更新时长，以提高数据更新方法的实时性和实用性。

基于图1所示的数据更新方法实施例，本申请进一步提出又一实施例的数据更新方法，可参阅图4，图4是本申请数据更新方法第三实施例的流程示意图。

本实施例的数据更新方法应用于上述实施例的数据更新系统20，数据更新系统20的具体结构请参阅上述图2，在此不再赘述。

在上述实施例的数据更新方法步骤13的基础上，本实施例的数据更新方法包括以下步骤：

S31：基于历史使用记录，确定目标数据在多个时间段内的分使用频率。

其中，根据历史使用记录，移动终端21获悉目标数据对应的应用程序被使用的时间段，例如，一天的时间中根据24个小时分为24个时间段，移动终端21获取每个时间段内应用程序或操作系统被使用的记录，从而确定目标数据在多个时间段内的分使用频率。

S32：确定分使用频率大于第二设定频率阈值的时间段为特定时间段。

其中，获取多个分使用频率后，移动终端21将多个分使用频率与第二设定频率阈值作比较，以确定分使用频率大于第二设定频率阈值的时间段为特定时间段。在特定时间段内，目标数据对应的应用程序或操作系统运行的概率很大，数据更新任务应该避开上述特定时间段。

其中，第二设定频率阈值与上述实施例的第一设定频率阈值相同。在其它实施例中，第二设定频率阈值与第一设定频率阈值也可不同，且第二设定频率阈值应大于第一设定频率阈值。

S33：将特定时间段的起始时间作为预估使用时间。

其中，移动终端21将上述特定时间段的起始时间作为应用程序或操作系统的预估使用时间。在其它实施例中，移动终端21也可以将上述特定时间段的中间时间作为应用程序或操作系统的预估使用时间。

得到预估使用时间后，移动终端21可获悉应用程序或操作系统被运行的具体时间。在上述实施例中，数据更新方法在获取应用程序或操作系统的用户粘度时，还可以获取应用程序或操作系统运行的具体时间，在进行目标数据的更新时，优先更新用户即将使用的应用程序或操作系统。

例如，移动终端21设置了在无线网络环境下进行自动更新，当移动终端21进入家里或公司无线网络的覆盖范围时，移动终端21自动连接无线网络，并开始准备进行应用程序或操作系统的更新。进一步地，基于获取的预估使用时间，移动终端21获悉在一个小时或某个应用程序被运行的概率很大，那么移动终端21优先进行该应用程序的更新任务。

进一步地，对于数据更新量较大的应用程序，例如，一些游戏公司开发的大型手机游戏。由于手机游戏更新时，需要玩家退出游戏，因此大型手机游戏的更新一般发生在固定时间，以减少对玩家的影响，例如，某一大型手机游戏的更新时间为凌晨12点至早上9点之间。基于固定的更新时间，移动终端21可以将预估时间设置为固定的更新时间几个小时之后，并将每天固定的更新时间结束后主动检测大型手机游戏是否有更新的目标数据产生；若检测到目标数据，则立即对目标数据进行更新，不需要等待目标数据更新信息的推送，提高数据更新方法的效率。

S34：获取当前时间与目标数据的预估使用时间之间的目标时长。

其中，移动终端21获取当前的时间数据，并根据当前的时间数据获取当前时间与上述步骤获取的预估使用时间之间的目标市场。

上述步骤中获取多个预估使用时间，移动终端21获取当前的时间数据时，同时获取与当前时间最接近的一个预估使用时间，且该预估使用时间应在当前时间之后。

S35：判断目标时长是否大于预估更新时长。

其中，移动终端21判断目标时长是否大于上述实施例获取的预估更新时长。由于更新任务会影响用户使用移动终端21，因此，当移动终端21判断到目标时长大于预估更新时长，则证明更新任务会在用户使用移动终端21之前完成，移动终端21开始自动更新目标数据；当移动终端21判断到目标时长小于预估更新时长，则更新任务可能会持续到用户使用移动终端21的时间，此时移动终端21需要提醒用户，以弹框状态栏的方式询问是否继续更新。

例如，当前时间为7点，基于移动终端21的预估使用时间为8点，但上述步骤S34计算得到的目标时长大于一个小时时，移动终端21需要询问用户需不需要继续更新；若移动终端21根据用户指令选择继续更新，则开始更新目标数据；若移动终端21根据用户指令选择不更新，则进入步骤S36。

S36：暂停目标数据更新，在目标数据使用完之后，再对目标数据进行自动更新。

其中，移动终端21停止目标数据的更新，采用该应用程序或该操作系统的原始版本进行运行。当该应用程序或该操作系统运行完成，移动终端21进行休眠状态时，移动终端21再对目标数据进行自动更新。

在本实施例中，通过获取应用程序或操作系统的分使用频率，确定应用程序或操作系统的预估使用时间；并根据当前时间和预估使用时间获取目标时长，然后将目标时长与预估更新时长做比较，以判断是否继续更新目标数据，从而减少对数据更新任务占用用户对移动终端的使用时间。

基于图1所示的数据更新方法实施例，本申请进一步提出又一实施例的数据更新方法，可参阅图5，图5是本申请移动终端的数据更新方法第四实施例的流程示意图。

本实施例的数据更新方法应用于上述实施例的数据更新系统20，数据更新系统20的具体结构请参阅上述图2，在此不再赘述。

在上述实施例的数据更新方法步骤14的基础上，本实施例的数据更新方法包括以下步骤：

S41：基于总使用频率的大小将多个目标数据进行排序。

其中，当移动终端21接收到多个目标数据更新信息时，移动终端21获取每个目标数据的总使用频率，获取方法请参见上述实施例，在此不再赘述。

移动终端21基于每个目标数据的总使用频率将多个目标数据进行排序。具体地，移动终端21可以将多个目标数据对应的待更新应用程序进行排序，排列的顺序按照总使用频率或者上述实施例所揭示的用户粘度从高到低，在后续进行目标数据更新时，更新任务从用户粘度最大的应用程序开始。

进一步地，移动终端21还可以设置一个数据量的更新阈值，更新阈值的大小可为1G或其数值。当某个应用程序的数据量大于该更新阈值时，在进行顺序排列或更新任务时跳过该应用程序，以提高数据更新方法的效率。

S42：按照排序依次对多个目标数据进行更新。

其中，获取多个应用程序的排序后，移动终端21按照排序对多个目标数据进行更新。具体地，移动终端21先开始排序中第一个应用程序的更新任务，第一个应用程序的更新任务结束后，自动开始第二个应用程序的更新任务，以此类推。

进一步地，基于上述排列顺序，多个应用程序也可以同时进行更新任务。例如，排列顺序中的前三个应用程序同时进行更新任务，当有应用程序完成更新任务后，排列顺序中的第四个应用程序开始更新任务，以此类推。

完成更新任务后，移动终端21还可采集此次更新任务的更新数据，具体请参与以下步骤：

S43：获取本次对目标数据进行更新的实际更新时长。

其中，移动终端21收集本次对目标数据进行更新的实际更新时长，并记录实际更新时长和预估更新时长的差距和差生的可能原因。

S44：将实际更新时长上传至服务器以对预估更新时长进行修正。

其中，移动终端21将上述收集的数据上传至服务器22或保存在本地的存储区，以在后续更新任务中用于对目标数据的预估更新时长进行修正。

在本实施例中，在出现多个目标数据的更新任务时，移动终端21基于总使用频率将多个目标数据进行排序，并根据排序以此进行多个更新任务；进一步地，移动终端21还可收集更新任务的实际数据，基于实际数据，可以对后续的目标数据的预估更新时长进行修正，以提高数据更新方法的准确性。

基于上述数据更新方法的实施例，本申请还提出了一种移动终端，具体请参阅图6，图6是本申请移动终端一实施例的结构示意图。

本实施例的移动终端30包括处理器31，以及与处理器31耦接的存储器32、通信模组33。

其中，存储器32用于存储程序数据，处理器31用于执行该程序数据以实现上述实施例的数据更新方法。其中，通信模组33主要用于与服务器进行无线数据交互，如从服务器下载数据以及向服务器上传数据，该通信模组33具体可以是WIFI通信模组或者蜂窝数据通信模组。

在本实施例中，处理器31还可以称为CPU(Central Processing Unit，中央处理单元)。处理器31可能是一种集成电路芯片，具有信号的处理能力。处理器31还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器31也可以是任何常规的处理器等。

本申请还提供一种计算机存储介质，如图7所示，计算机存储介质400存储有程序数据，程序数据能够被执行以实现如本申请数据更新方法实施例中所述的方法。

本申请数据更新方法实施例中所涉及到的方法，在实现时以软件功能单元的形式存在并作为独立的产品销售或使用时，可以存储在装置中，例如一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

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

接收服务器发送的目标数据更新信息；

获取所述目标数据的预估更新时长；

判断所述目标数据的预估更新时长是否满足设定要求；

若是，自动对所述目标数据进行更新。

2.根据权利要求1所述的数据更新方法，其特征在于，

所述接收服务器发送的目标数据更新信息的步骤之后，还包括：

获取所述目标数据的历史使用记录；

基于所述历史使用记录，判断所述目标数据的总使用频率是否大于第一设定频率阈值；

若是，执行所述获取所述目标数据的预估更新时长的步骤。

3.根据权利要求2所述的数据更新方法，其特征在于，

所述判断所述目标数据的预估更新时长是否满足设定要求的步骤，包括：

获取所述目标数据的预估使用时间；

获取当前时间与所述目标数据的预估使用时间之间的目标时长；

判断所述目标时长是否大于所述预估更新时长。

4.根据权利要求3所述的数据更新方法，其特征在于，

所述获取所述目标数据的预估使用时间的步骤，包括：

基于所述历史使用记录，确定所述目标数据在多个时间段内的分使用频率；

确定分使用频率大于第二设定频率阈值的时间段为特定时间段；

将所述特定时间段的起始时间作为所述预估使用时间。

5.根据权利要求3所述的数据更新方法，其特征在于，

所述更新方法还包括：

在所述目标时长小于所述预估更新时长时，暂停所述目标数据更新，在所述目标数据使用完之后，再对所述目标数据进行自动更新。

6.根据权利要求2所述的数据更新方法，其特征在于，

总使用频率大于第一设定频率阈值、且预估更新时长满足设定要求的目标数据的数量为多个；

所述自动对所述目标数据进行更新的步骤包括：

基于总使用频率的大小将多个目标数据进行排序；

按照排序依次对多个所述目标数据进行更新。

7.根据权利要求1所述的数据更新方法，其特征在于，

所述获取所述目标数据的预估更新时长的步骤，包括：

获取所述目标程序的更新数据量以及当前的网络状态；

基于所述更新数据量和所述网络状态，确定所述目标数据的预估更新时长。

8.根据权利要求1所述的数据更新方法，其特征在于，

所述目标数据的预估更新时长是从所述服务器获取的所有用户终端对所述数据进行更新的时长的平均值；

所述自动对所述目标数据进行更新的步骤之后，还包括：

获取本次对所述目标数据进行更新的实际更新时长；

将所述实际更新时长上传至服务器以对所述预估更新时长进行修正。

9.一种移动终端，其特征在于，所述移动终端包括处理器以及与所述处理器耦接的存储器、通信模组；

其中，所述存储器用于存储程序数据，所述处理器用于执行所述程序数据以实现如权利要求1-8任一项所述的数据更新方法。

10.一种计算机存储介质，其特征在于，所述计算机存储介质用于存储程序数据，所述程序数据在被处理器执行时，用以实现如权利要求1-8任一项所述的数据更新方法。

Images