CN114579157A - 一种应用更新方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本公开提供了一种应用更新方法、装置、计算机设备及存储介质，其中，该方法包括：获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及目标应用的更新包发布时间信息；基于多个历史使用时间信息，预测目标用户端下一次使用目标应用的预计使用时间信息；基于预计使用时间信息以及目标应用的更新包发布时间信息，确定对目标应用进行更新的更新时间信息。本公开实施例结合各个目标应用的使用规律和更新包发布时间规律，不仅可以减少不必要的更新，而且可以有效地保证目标用户端在使用各个目标应用时都是最新版本的，有利于为用户提供更好的应用服务。

Description

一种应用更新方法、装置、计算机设备及存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种应用更新方法、装置、计算机设备及存储介质。

背景技术

随着计算机技术的发展，终端上的各种应用软件应运而生。为了更加完善应用软件的功能，各种应用软件不断推出新的版本。用户需要将应用软件更新到最新的版本，才能体验更高品质的服务。

在对应用软件进行更新的时候，通常是在统一的时间对多种应用软件进行一次更新，譬如七天或者一个月更新一次。上述按照统一的时间进行更新的方式，一方面，针对使用频率过低的应用软件，容易进行不必要的更新，浪费流量；另一方面，无法保证用户在每次打开应用的时候使用的都是最新版本的应用，无法给用户带来更好的使用效果。

发明内容

本公开实施例至少提供一种应用更新方法、装置、计算机设备及存储介质。

第一方面，本公开实施例提供了一种应用更新方法，包括：

获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息；

基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息；

基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

一种可行的实施方式中，所述历史使用时间信息包括所述目标用户端每次使用所述目标应用时的启动时间；

所述基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息，包括：

对所述启动时间进行聚类，得到至少一个类簇；所述至少一个类簇内的任一启动时间，在该类簇内都存在至少一个与该启动时间的时间差值小于第一设定阈值的其他启动时间；

基于所述至少一个类簇内的各个所述启动时间，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息。

一种可行的实施方式中，在对所述启动时间进行聚类，得到至少一个类簇之后，所述方法还包括：

基于所述至少一个类簇内的各个所述启动时间，判断每个所述类簇内的各个启动时间之间的最大时间差值是否大于第二设定阈值，并确定出所述至少一个类簇中，各个启动时间之间的最大时间差值大于所述第二设定阈值的目标类簇；针对每个所述目标类簇，按照预设调整步长缩小所述第一设定阈值，直至满足以下任一条件：

按照缩小后的所述第一设定阈值对所述启动时间进行聚类后，得到的所述目标类簇内的各个启动时间之间的最大时间差值小于所述第二设定阈值；

缩小后的所述第一设定阈值小于第三设定阈值；所述第三设定阈值为设置的各个启动时间之间的最大时间差值的最小值；

按照缩小后的所述第一设定阈值对所述启动时间进行聚类后，得到的所述目标类簇中的所述启动时间的个数小于第四设定阈值。

一种可行的实施方式中，所述基于所述至少一个类簇内的各个所述启动时间，预测所述目标用户端下一次使用所述目标应用的使用时间，包括：

基于所述至少一个类簇内的各个所述启动时间，确定每个所述类簇分别对应的平均启动时间，并基于每个所述类簇分别对应的所述平均启动时间，确定所述目标用户端下一次使用所述目标应用的预计使用时间信息。

一种可行的实施方式中，所述历史使用时间信息还包括所述目标用户端每次使用所述目标应用的使用时长；用于对所述启动时间进行聚类的所述第一设定阈值是基于所述使用时长确定的。

一种可行的实施方式中，所述目标应用包含多个；所述基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息，包括：

在存在待更新的多个目标应用的情况下，按照预测的多个所述目标应用的预计使用时间信息，确定多个所述目标应用对应的更新优先级；

基于所述预计使用时间信息、所述目标应用的更新包发布时间信息、以及多个所述目标应用对应的更新优先级，确定多个所述目标应用的更新时间。

一种可行的实施方式中，确定对所述目标应用进行更新的更新时间信息之后，所述方法还包括：

在按照确定的所述更新时间对所述目标应用进行更新的过程中，在所述目标用户端不满足应用更新条件导致目标应用更新暂停的情况下，确定所述目标应用的预计使用时间之前预设时长的目标时间；

在所述目标时间达到时，按照预设周期检测所述目标用户端是否重新满足所述应用更新条件；在检测到所述目标用户端重新满足所述应用更新条件的情况下，对所述目标应用进行更新。

第二方面，本公开实施例还提供一种应用更新装置，包括：

获取模块，用于获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息；

预测模块，用于基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息；

第一确定模块，用于基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

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

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

本公开实施例提供的应用更新方法，基于目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，可以预测目标用户端下一次使用目标应用的预计使用时间信息，进而根据预计使用时间信息和更新包发布时间信息，可以确定对目标应用进行更新的更新时间信息。上述过程在考虑目标用户端对各个目标应用的使用规律的基础上，还结合了各个目标应用的更新包发布时间规律，如此，可以针对性地确定对各个目标应用进行更新的更新时间，从而可以在减少不必要的更新的同时(比如对于用户使用时间间隔比较久的情况下，可以避免不必要的频率更新)，还可以在一定程度上保证目标用户端在使用各个目标应用时都是最新版本的，有利于为用户提供更好的应用服务。

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

附图说明

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

图1示出了本公开实施例所提供的一种应用更新方法的流程图；

图2示出了本公开实施例所提供的一种历史使用时间信息的展示示意图；

图3示出了本公开实施例所提供的一种历史使用时间信息的聚类示意图；

图4示出了本公开实施例所提供的另一种历史使用时间信息的聚类示意图；

图5示出了本公开实施例所提供的另一种历史使用时间信息的聚类示意图；

图6示出了本公开实施例所提供的一种应用更新装置的示意图；

图7示出了本公开实施例所提供的一种计算机设备的示意图。

具体实施方式

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

当前对应用软件进行更新的方式比较粗糙，例如，使用频率较高的应用软件，就按照七天一次的更新频率进行更新；使用频率较低的应用软件，就按照一个月一次的更新频率进行更新，并且上述更新过程通常是在统一时间进行更新的。这种采用固定时间进行更新的方式，一方面，针对使用频率过低的应用软件，容易进行不必要的更新，浪费流量；另一方面，无法保证用户在每次打开应用的时候使用的都是最新版本的应用的，无法给用户带来更好的使用效果。

基于此，本公开提供了一种应用更新方法，基于目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，可以预测目标用户端下一次使用目标应用的预计使用时间信息，进而根据预计使用时间信息和更新包发布时间信息，可以确定对目标应用进行更新的更新时间信息。上述过程在考虑目标用户端对各个目标应用的使用规律的基础上，还结合了各个目标应用的更新包发布时间规律，如此，可以针对性地确定对各个目标应用进行更新的更新时间，从而可以在减少不必要的更新的同时(比如对于用户使用时间间隔比较久的情况下，可以避免不必要的频率更新)，还可以在一定程度上保证目标用户端在使用各个目标应用时都是最新版本的，有利于为用户提供更好的应用服务。

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

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

为便于对本实施例进行理解，首先对本公开实施例所公开的一种应用更新方法进行详细介绍，本公开实施例所提供的应用更新方法的执行主体一般为具有一定计算能力的计算机设备。

下面以执行主体为终端设备为例对本公开实施例提供的应用更新方法加以说明。

参见图1所示，为本公开实施例提供的一种应用更新方法的流程图，所述方法包括S101～S103，其中：

S101：获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息。

在本公开实施例中，历史使用时间信息可以包括目标用户端每次使用目标应用的启动时间、目标用户端每次使用目标应用的使用时长等信息。历史使用时间信息可以是通过由目标用户端发送、本实施例的执行主体服务器接收的方式获取到的。在一种方式中，历史使用时间信息具体可以是通过由监听目标用户端上目标应用的活动管理器(ActivityManager)发送、服务器接收的方式获取到的。

其中，活动管理器可以监听安装在目标用户端每次使用目标应用的使用时间信息。在具体实施中，活动管理器还可以获取目标应用的安装包标识信息，例如安装包名称等。活动管理器监听到目标应用的使用时间信息和目标应用的安装包标识信息之后，可以将目标应用的使用时间信息和安装包标识信息发送到服务器中。在一种方式中，活动管理器可以将每次监听到的目标应用的使用时间信息和安装包标识信息实时地发送到服务器对应的数据库中，服务器再从对应的数据库中提取预设历史时间段内的历史使用时间信息。在另一种方式中，为了减少数据传输次数，活动管理器也可以先将监听到的目标应用的使用时间信息和安装包标识信息存储到目标用户端对应的本地数据库中，每隔一段时间之后，活动管理器再将预设历史时间段内的历史使用时间信息发送到服务器中。

这里，可以设置预设历史时间段为例如一周、一个月、一年等。在具体实施中，预设历史时间段可以根据目标应用的功能类型和其他大多数用户的使用情况来设置。例如，针对社交类型的目标应用，目标用户端可能每天都使用其进行社交活动，使用频率较高，如此，可以设置预设历史时间段为以当前时间为时间起点的前一周；针对金融类型的目标应用，目标用户端可能只在月初还款的时候才会使用，使用频率较低，如此，可以设置预设历史时间段为以当前时间为时间起点的前一年等。在具体实施中，还可以设置预设历史时间段为连续的几周或者几个月(例如半年)或者几年等。在其他实施方式中，考虑到在工作日和节假日，目标用户端对目标应用的使用情况有所不同，此时，预设历史时间段还可以分为工作日对应的预设历史时间段以及节假日对应的预设历史时间段。这里对预设历史时间段的设置过程不做具体限定。

如前所述，历史使用时间信息可以包括目标用户端每次使用目标应用的启动时间、以及目标用户端每次使用目标应用的使用时长。目标用户端每次启动目标应用后，使用目标应用的使用时长可以是不相同的。比如，目标用户端经常使用某音乐类型的目标应用，根据上述过程获取到了该目标用户端在某一天中的多个历史使用时间信息，多个历史使用时间信息通过坐标的方式展示出来的时候，如图2所示，在以启动时间为横轴、以使用时长为纵轴的坐标系中，多个历史使用时间信息可以分别对应一个坐标点，每个坐标点的横坐标就是该坐标点对应的启动时间，纵坐标就是该坐标点对应的使用时长。

在本公开实施例中，更新包发布时间信息可以包括更新包发布时间、更新包发布频率(例如每周发布一次)等信息。目标应用的更新包发布时间信息可以是在应用商店、目标应用对应的官方网站等平台获取到的。这里对获取目标应用的更新包发布时间信息的过程不做具体限定。

承接上述步骤，本公开实施例提供的应用更新方法还包括以下步骤：

S102：基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息。

通常情况下，目标用户端的用户可能会在一定时间段内对同一目标应用保持相同的使用习惯，因此，在本公开实施例中，可以根据目标用户端的用户在预设历史时间段内使用目标应用的多个历史使用时间信息，预测目标用户端下一次使用目标应用的预计使用时间信息。其中预计使用时间信息可以包括预计启动时间。

这里，当历史使用时间信息包括目标用户端每次使用目标应用时的启动时间的情况下，在某些情况下，比如目标用户端经常在固定时刻启动目标应用，此时，示例性地，可以将多个启动时间中出现频率最多的目标启动时间，作为目标用户端下一次使用目标应用的预计使用时间信息。例如，在前一周之内，目标用户端有4次在20:00启动某一目标应用，有2次在20:30启动该目标应用，有1次在19:30启动该目标应用，此时可以将20:00作为目标用户端下一次使用目标应用的预计使用时间信息。

在某些情况下，目标用户端经常在一定的时间范围内启动目标应用，例如，经常在9:00～12:00、以及14:00～18:00之间启动某一应用，此时无法将出现频率最多的目标启动时间作为目标用户端下一次使用目标应用的预计使用时间信息。在这种情况下，示例性地，可以先对多个启动时间进行聚类，得到至少一个类簇；至少一个类簇内的任一启动时间，在该类簇内都存在至少一个与该启动时间的时间差值小于第一设定阈值的其他启动时间。

在具体实施中，第一设定阈值可以作为进行聚类的直径(或者说第一设定阈值可以作为进行聚类的半径的2倍)，第一设定阈值可以根据实际情况进行调整，例如可以根据目标应用的功能类型、每次使用目标应用的使用时长等信息来确定。例如，对于音乐、视频等类型的目标应用，单次使用时长比较长，那么可以将第一设定阈值设置为1小时；对于社交、工作等类型的目标应用，单次使用时长可能比较短，那么可以将第一设定阈值设置为10分钟。

在一种实施方式中，历史使用时间信息可以包括目标用户端每次使用目标应用的使用时长；用于对启动时间进行聚类的第一设定阈值是基于使用时长确定的。例如，当每次使用目标应用的使用时长较长，具体如40分钟，那么可以将第一设定阈值设置为1小时。当每次使用目标应用的使用时长较短，具体如2分钟，那么可以将第一设定阈值设置为10分钟。

在根据第一设定阈值确定聚类半径，并根据聚类半径对启动时间进行聚类时，可以得到至少一个由该聚类半径确定出的圆形聚类范围，确定出的多个圆形聚类范围可能存在重叠区域，存在重叠区域的多个圆形聚类范围具有以下特征：存在重叠区域的多个圆形聚类范围内包含的任一启动时间，都存在至少一个与该启动时间的时间差值小于第一设定阈值的其他启动时间。此时，可以将具有上述特征的、存在重叠区域的多个圆形聚类范围内包含的所有启动时间聚为一个类簇。按照上述过程对图2中的多个历史使用时间信息中的启动时间进行聚类后，可以得到如图3所示的多个圆形聚类范围，即左侧存在重叠区域的三个圆形聚类范围、以及右侧存在重叠区域的两个圆形聚类范围。在图3中还存在无法与其他启动时间聚为一类的启动时间，这些无法与其他启动时间聚为一类的启动时间可以直接舍弃掉。图3中左侧存在重叠区域的三个圆形聚类范围内包含的启动时间的集合、以及右侧存在重叠区域的两个圆形聚类范围内包含的启动时间的集合，就是图4所示的两个类簇。

接下来，可以基于至少一个类簇内的各个启动时间，预测目标用户端下一次使用目标应用的预计使用时间信息。

在一种实施方式中，可以对每个类簇内的各个启动时间进行排序，然后根据每个类簇内时间最早的启动时间，确定目标用户端下一次使用目标应用的预计使用时间信息。这种实施方式，确定出的预计使用时间信息的准确性可能较低。因此，在另一种实施方式中，可以基于至少一个类簇内的各个启动时间，确定每个类簇分别对应的平均启动时间，并基于每个类簇分别对应的平均启动时间，确定目标用户端下一次使用目标应用的预计使用时间信息。

当得到的类簇仅有一个的情况下，可以基于该类簇内的各个启动时间，确定该类簇对应的平均启动时间，然后将确定出的平均启动时间，作为目标用户端下一次使用目标应用的预计使用时间信息。

当得到的类簇为多个的情况下，可以先确定出每个类簇分别对应的平均启动时间。然后，在一种方式中，可以再对每个类簇分别对应的平均启动时间进行求平均，得到最终的平均启动时间，并根据最终的平均启动时间，确定目标用户端下一次使用目标应用的预计使用时间信息。在一种方式中，也可以从每个类簇分别对应的平均启动时间中筛选出最早的平均启动时间，并根据最早的平均启动时间，确定目标用户端下一次使用目标应用的预计使用时间信息。

这里需要说明的是，根据至少一个类簇内的各个启动时间，预测目标用户端下一次使用目标应用的使用时间的任何可能的实施方式都可以在本公开实施例要求保护的范围之内。

为了使得预测出的目标用户端下一次使用目标应用的预计使用时间信息更加准确，在一种方式中，可以对上述得到的至少一个类簇进行重新聚类，也就是缩小类簇的聚类半径，使得每个类簇内的启动时间更加紧凑，也就是各个启动时间之间的时间差值更小。

具体地，在一种实施方式中，可以基于至少一个类簇内的各个启动时间，判断每个类簇内的各个启动时间之间的最大时间差值是否大于第二设定阈值，并确定出至少一个类簇中，各个启动时间之间的最大时间差值大于第二设定阈值的目标类簇；针对每个目标类簇，按照预设调整步长缩小第一设定阈值，直至满足以下任一条件：按照缩小后的第一设定阈值对启动时间进行聚类后，得到的目标类簇内的各个启动时间之间的最大时间差值小于第二设定阈值；缩小后的第一设定阈值小于第三设定阈值；第三设定阈值为设置的各个启动时间之间的最大时间差值的最小值；按照缩小后的第一设定阈值对启动时间进行聚类后，得到的目标类簇中的启动时间的个数小于第四设定阈值。

这里，第二设定阈值可以是根据实际情况设置的，例如5个小时，这里可以不做具体限定。针对不同目标应用得到的类型，设置的第二设定阈值可以是不同的。

如果判断出某个类簇内的各个启动时间之间的最大时间差值大于第二设定阈值，可以认为该类簇对应的聚类半径比较大的，导致该类簇内的启动时间跨度比较大，需要对该类簇进行重新聚类。因此，接下来针对每个需要进行重新聚类的目标类簇，可以按照预设调整步长缩小第一设定阈值，也就是预设调整步长缩小聚类半径，直至满足任一截止条件。这里，预设调整步长可以是根据实际情况设置的，可以不做具体限定。

在本公开实施例中，可以包含以下至少三种截止条件，即：(一)按照缩小后的第一设定阈值对启动时间进行聚类后，得到的目标类簇内的各个启动时间之间的最大时间差值小于第二设定阈值；(二)缩小后的第一设定阈值小于第三设定阈值；第三设定阈值为设置的各个启动时间之间的最大时间差值的最小值；其中，第三设定阈值不应过大，也不应过小，例如可以设置为10分钟；(三)按照缩小后的第一设定阈值对启动时间进行聚类后，得到的目标类簇中的启动时间的个数小于第四设定阈值；其中，第四设定阈值可以为小于在第一设定阈值缩小前，原目标类簇中启动时间数量，例如可以为原目标类簇中启动时间数量的70％。

由于每个目标类簇内各个启动时间之间的最大时间差值可能是不相同的，因此，每个目标类簇对应的截止条件可能也是不同的。

按照上述对类簇进行重新聚类方式，对图4所示的两个类簇进行重新聚类后，可以得到如图5所示的重新聚类后的类簇。通过图5可以看出，重新聚类后的类簇中实心圆点所表示的启动时间的个数，比图4中实心圆点所表示的启动时间的个数少。进一步地，根据图5中重新聚类后的类簇内的各个启动时间，可以计算得到每个重新聚类后的类簇对应的平均启动时间，即图5中空心原点所表示的平均启动时间。通过图5可以看出，该目标用户端会在10:30使用这个目标应用，使用时长在35min左右；并且该目标用户端会在13:20使用这个目标应用，使用时长为40min左右。

最后，基于重新聚类后的至少一个类簇内的各个平均启动时间，预测目标用户端下一次使用目标应用的预计使用时间信息。

承接上述步骤，本公开实施例提供的应用更新方法还包括以下步骤：

S103：基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

根据目标应用的更新包发布时间信息，可以在目标用户端下一次使用目标应用之前获取到最新版的目标应用的更新包，并在目标用户端下一次使用目标应用之前，利用最新版的目标应用的更新包对目标应用进行更新。如此，可以保证目标用户端在每次打开应用的时候使用的都是最新版本的应用。

例如，假设目标应用在每周一会发布更新包，但是目标用户端下一次使用目标应用的时间是下周二，那么本周一就可以不用去更新该目标应用，可以在下周一更新该目标应用，不仅可以使得目标用户端在下周二使用的是最新版的目标应用，并且还可以减少不必要的更新，节省流量。

在目标用户端所使用的目标应用包含多个的情况下，在一种实施方式中，还可以在存在待更新的多个目标应用的情况下，按照预测的多个目标应用的预计使用时间信息，确定多个目标应用对应的更新优先级；然后，基于预计使用时间信息、目标应用的更新包发布时间信息、以及多个目标应用对应的更新优先级，确定多个目标应用的更新时间。

其中，待更新的多个目标应用可以是预计使用时间信息比较接近的多个目标应用，例如目标用户端在本周三8:00会使用目标应用A，在本周三12:00会使用目标应用B，在本周三15:00会使用目标应用C进行。

考虑可能会受到网络、电量等条件的限制，为了保证最近需要使用的目标应用能最先更新到最新版本，此时，可以按照预计使用时间信息，确定目标应用A对应的更新优先级大于目标应用B对应的更新优先级，目标应用B对应的更新优先级大于目标应用C对应的更新优先级。

按照多个目标应用对应的更新优先级，以及预计使用时间信息、目标应用的更新包发布时间信息，可以确定多个目标应用的更新时间。其中，确定多个目标应用的更新时间的过程可以参照前述过程，重复之处不再赘述。

在确定对目标应用进行更新的更新时间信息之后，并在按照确定的更新时间对目标应用进行更新的过程中，可能会出现目标用户端不满足应用更新条件导致目标应用更新暂停的情况，这里的应用更新条件可以为网络传输速度达到某一预设值，或目标用户端的电量达到某一预设值等条件。因此，在一种方式中，在目标用户端不满足应用更新条件导致目标应用更新暂停的情况下，可以确定目标应用的预计使用时间之前预设时长的目标时间，例如目标应用的预计使用时间为12:00，预设时长为3个小时，那么在12:00前3个小时的目标时间为9:00。

在目标时间达到时，可以按照预设周期检测目标用户端是否重新满足应用更新条件；在检测到目标用户端重新满足应用更新条件的情况下，对目标应用进行更新。

例如预设周期为半个小时，在上述目标时间为9:00的情况下，可以在达到9:00时，每隔半个小时检测目标用户端是否重新满足应用更新条件。如果不满足，则继续按照该预设周期进行检测；如果满足，则可以对目标应用进行更新。

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

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

参照图6所示，为本公开实施例提供的一种应用更新装置的架构示意图，所述装置包括：获取模块601、预测模块602、第一确定模块603；其中，

获取模块601，用于获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息；

预测模块602，用于基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息；

第一确定模块603，用于基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

一种可行的实施方式中，所述历史使用时间信息包括所述目标用户端每次使用所述目标应用时的启动时间；

预测模块602，具体用于：

对所述启动时间进行聚类，得到至少一个类簇；所述至少一个类簇内的任一启动时间，在该类簇内都存在至少一个与该启动时间的时间差值小于第一设定阈值的其他启动时间；

基于所述至少一个类簇内的各个所述启动时间，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息。

一种可行的实施方式中，所述装置还包括：

调整模块，用于基于所述至少一个类簇内的各个所述启动时间，判断每个所述类簇内的各个启动时间之间的最大时间差值是否大于第二设定阈值，并确定出所述至少一个类簇中，各个启动时间之间的最大时间差值大于所述第二设定阈值的目标类簇；针对每个所述目标类簇，按照预设调整步长缩小所述第一设定阈值，直至满足以下任一条件：

按照缩小后的所述第一设定阈值对所述启动时间进行聚类后，得到的所述目标类簇内的各个启动时间之间的最大时间差值小于所述第二设定阈值；

缩小后的所述第一设定阈值小于第三设定阈值；所述第三设定阈值为设置的各个启动时间之间的最大时间差值的最小值；

按照缩小后的所述第一设定阈值对所述启动时间进行聚类后，得到的所述目标类簇中的所述启动时间的个数小于第四设定阈值。

一种可行的实施方式中，预测模块602，具体用于：

基于所述至少一个类簇内的各个所述启动时间，确定每个所述类簇分别对应的平均启动时间，并基于每个所述类簇分别对应的所述平均启动时间，确定所述目标用户端下一次使用所述目标应用的预计使用时间信息。

一种可行的实施方式中，所述历史使用时间信息还包括所述目标用户端每次使用所述目标应用的使用时长；用于对所述启动时间进行聚类的所述第一设定阈值是基于所述使用时长确定的。

一种可行的实施方式中，所述目标应用包含多个；第一确定模块603，具体用于：

在存在待更新的多个目标应用的情况下，按照预测的多个所述目标应用的预计使用时间信息，确定多个所述目标应用对应的更新优先级；

基于所述预计使用时间信息、所述目标应用的更新包发布时间信息、以及多个所述目标应用对应的更新优先级，确定多个所述目标应用的更新时间。

一种可行的实施方式中，所述装置还包括：

第二确定模块，用于在按照确定的所述更新时间对所述目标应用进行更新的过程中，在所述目标用户端不满足应用更新条件导致目标应用更新暂停的情况下，确定所述目标应用的预计使用时间之前预设时长的目标时间；

检测模块，用于在所述目标时间达到时，按照预设周期检测所述目标用户端是否重新满足所述应用更新条件；在检测到所述目标用户端重新满足所述应用更新条件的情况下，对所述目标应用进行更新。

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

基于同一技术构思，本公开实施例还提供了一种计算机设备。参照图7所示，为本公开实施例提供的计算机设备700的结构示意图，包括处理器701、存储器702、和总线703。其中，存储器702用于存储执行指令，包括内存7021和外部存储器7022；这里的内存7021也称内存储器，用于暂时存放处理器701中的运算数据，以及与硬盘等外部存储器7022交换的数据，处理器701通过内存7021与外部存储器7022进行数据交换，当计算机设备700运行时，处理器701与存储器702之间通过总线703通信，使得处理器701在执行以下指令：

获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息；

基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息；

基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

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

本公开实施例还提供一种计算机程序产品，该计算机产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的应用更新方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

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

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

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

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

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

Claims (10)

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

获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息；

基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息；

基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

2.根据权利要求1所述的方法，其特征在于，所述历史使用时间信息包括所述目标用户端每次使用所述目标应用时的启动时间；

所述基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息，包括：

对所述启动时间进行聚类，得到至少一个类簇；所述至少一个类簇内的任一启动时间，在该类簇内都存在至少一个与该启动时间的时间差值小于第一设定阈值的其他启动时间；

基于所述至少一个类簇内的各个所述启动时间，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息。

3.根据权利要求2所述的方法，其特征在于，在对所述启动时间进行聚类，得到至少一个类簇之后，所述方法还包括：

基于所述至少一个类簇内的各个所述启动时间，判断每个所述类簇内的各个启动时间之间的最大时间差值是否大于第二设定阈值，并确定出所述至少一个类簇中，各个启动时间之间的最大时间差值大于所述第二设定阈值的目标类簇；针对每个所述目标类簇，按照预设调整步长缩小所述第一设定阈值，直至满足以下任一条件：

按照缩小后的所述第一设定阈值对所述启动时间进行聚类后，得到的所述目标类簇内的各个启动时间之间的最大时间差值小于所述第二设定阈值；

缩小后的所述第一设定阈值小于第三设定阈值；所述第三设定阈值为设置的各个启动时间之间的最大时间差值的最小值；

按照缩小后的所述第一设定阈值对所述启动时间进行聚类后，得到的所述目标类簇中的所述启动时间的个数小于第四设定阈值。

4.根据权利要求2所述的方法，其特征在于，所述基于所述至少一个类簇内的各个所述启动时间，预测所述目标用户端下一次使用所述目标应用的使用时间，包括：

基于所述至少一个类簇内的各个所述启动时间，确定每个所述类簇分别对应的平均启动时间，并基于每个所述类簇分别对应的所述平均启动时间，确定所述目标用户端下一次使用所述目标应用的预计使用时间信息。

5.根据权利要求2所述的方法，其特征在于，所述历史使用时间信息还包括所述目标用户端每次使用所述目标应用的使用时长；用于对所述启动时间进行聚类的所述第一设定阈值是基于所述使用时长确定的。

6.根据权利要求1所述的方法，其特征在于，所述目标应用包含多个；所述基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息，包括：

在存在待更新的多个目标应用的情况下，按照预测的多个所述目标应用的预计使用时间信息，确定多个所述目标应用对应的更新优先级；

基于所述预计使用时间信息、所述目标应用的更新包发布时间信息、以及多个所述目标应用对应的更新优先级，确定多个所述目标应用的更新时间。

7.根据权利要求1所述的方法，其特征在于，确定对所述目标应用进行更新的更新时间信息之后，所述方法还包括：

在按照确定的所述更新时间对所述目标应用进行更新的过程中，在所述目标用户端不满足应用更新条件导致目标应用更新暂停的情况下，确定所述目标应用的预计使用时间之前预设时长的目标时间；

在所述目标时间达到时，按照预设周期检测所述目标用户端是否重新满足所述应用更新条件；在检测到所述目标用户端重新满足所述应用更新条件的情况下，对所述目标应用进行更新。

8.一种应用更新装置，其特征在于，包括：

获取模块，用于获取目标用户端在预设历史时间段内使用目标应用的多个历史使用时间信息，以及所述目标应用的更新包发布时间信息；

预测模块，用于基于所述多个历史使用时间信息，预测所述目标用户端下一次使用所述目标应用的预计使用时间信息；

第一确定模块，用于基于所述预计使用时间信息以及所述目标应用的更新包发布时间信息，确定对所述目标应用进行更新的更新时间信息。

9.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至7任一项所述的应用更新方法的步骤。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至7任一项所述的应用更新方法的步骤。

Images