CN115562967B - 一种应用程序预测方法、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种应用程序预测方法、电子设备及存储介质，包括：获取历史应用程序使用序列；根据多个不同回溯阈值的时间窗和目标应用程序切分历史应用程序使用序列，得到多个子序列，建立序列数据库；从序列数据库中挖掘序列模式；根据序列模式构建序列性特征；在检测到应用程序预测事件被触发的情况下，根据序列性特征对目标时间段内是否会启动目标应用程序进行预测，通过不同时间阈值的时间窗和目标应用程序结合对历史应用程序使用序列进行切分的方式确保用户长时间使用习惯和短时间使用习惯的序列模式都能无遗漏地被挖掘，基于序列模式构造序列性特征，通过序列性特征来实现预测，有效地提高预测结果的准确度。

Description

一种应用程序预测方法、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用程序预测方法、电子设备及存储介质。

背景技术

随着电子设备中安装的应用程序数量增多，应用程序(Application，APP)运行时所需要的资源也越来越多。当用户启动一个应用程序时，电子设备对该应用程序启动所需的资源进行加载，资源加载完毕后进入该应用程序的用户界面，如果应用程序所需的资源较多，则应用程序的资源加载过程耗费较长时间，因此，用户等待该应用程序启动的时间长。尤其是对于一些需要占用较多资源的大型的手机游戏，用户需要等待应用程序启动的时间会更长。

为了缩短用户等待应用程序启动的时长，预测用户在未来一段时间内是否打开某个应用程序，在预测到用户在未来一段时间内会打开该应用程序的情况下，预先加载该应用程序启动时所需的资源（即，启动资源）。但是，相关技术的应用程序预测方案的预测准确率低。

发明内容

本申请提供了一种应用程序预测方法、电子设备及存储介质，可以提高应用程序预测方案的预测准确率。

第一方面，提供了一种应用程序预测方法，包括：获取历史应用程序使用序列；根据多个不同回溯阈值的时间窗和目标应用程序切分历史应用程序使用序列，得到多个子序列，建立序列数据库；从序列数据库中挖掘序列模式；根据序列模式构建序列性特征；在检测到应用程序预测事件被触发的情况下，根据序列性特征对目标时间段内是否会启动目标应用程序进行预测。

上述历史应用程序使用序列包括用户在历史时间段内使用过的所有应用程序，以及每个应用程序对应的时间信息，且按历史应用程序使用序列中还根据每个应用程序对应的时间信息对应用程序进行了先后顺序排序。

上述历史时间段可以根据实际需求选取，例如，最近三个月，或最近两个月，或最近一个月，或最近20天，或最近两周内。

示例性的，假设历史时间段是最近两个月，那么历史应用程序使用序列为用户在最近两个月内每天使用的所有应用程序，且按照每个应用程序对应的时间信息进行先后顺序排序后得到的序列。

上述每个应用程序时间信息可以包括但不限于启动时间、关闭时间、前端运行时长等。

上述按照每个应用程序对应的时间信息进行先后顺序排序具体可以是按每个应用程序的启动时间进行先后顺序排序。

例如，用户某一天上午使用了5个APP，具体的，7:00打开了APP1，7:30打开了APP2，9:00打开了APP3，11:00打开了APP4，11:30打开了APP5，则按照这5个APP的开启时间由早至晚的顺序排列得到的APP序列为{APP1，APP2，APP3，APP4，APP5}。为了方便描述，该APP序列示例仅示出了APP名称，该APP序列还可以包括每个APP的开启时间和关闭时间，其中，开启时间是指用户打开该APP的时刻，关闭时间是指用户关闭该APP(如退出或切换至后台)的时刻。

需要说明的是，用户在历史时间段内可能多次使用同一款应用程序，则该应用程序在上述历史应用程序使用序列中会出现多次。即该历史应用程序使用序列中不同排序位置的应用程序可能是同一款应用程序。例如，用户在历史时间段的3个不同时间点都使用了第一应用程序，则上述第一应用程序在上述历史应用程序使用序列中将出现3次。

上述时间特征可以是各个应用程序的启动时间与目标应用程序的启动时间的时间差。

从序列数据库中挖掘序列模式可以利用已有的序列模式挖掘算法来实现，上述序列模式挖掘算法包括但不限于AprioriAll算法、GSP 算法、FreeSpan算法等。

上述应用程序预测事件的触发条件可以根据实际需求进行设定，本申请不作具体限制。

例如，当检测到用户的解锁操作后，触发应用程序预测事件，或者，当检测到某个应用程序被打开时，触发应用程序预测事件，又或者，当检测到电子设备从某个应用程序的使用界面返回到系统桌面时，触发应用程序预测事件，又或者，当检测到某个应用程序的使用界面切换到另一个应用程序的使用界面时，触发应用程序预测事件，又或者到达预设时间间隔触发应用程序预测事件，此处不再一一详述。

需要说明的是，上述预设时间间隔可以根据实际需求进行设定，本申请不作具体限制。例如，可以设置为30分钟，即电子设备每间隔30分钟触发一次应用程序预测事件，或者设置为。

需要说明的是，上述目标时间段可以根据实际需求进行设定，本申请不作具体限制。例如，目标时间段可以设置为1小时，即根据序列性特征预测未来1小时内是否将启动目标应用程序。

以上可以看出，通过获取按照启动顺序排序的历史应用程序使用序列，并通过不同时间阈值的时间窗和目标应用程序对历史应用程序使用序列进行切分，得到多个应用程序子序列，以此构建序列数据库，使得构建的序列数据库能够将特定应用程序（即目标应用程序）作为分切点，并回溯不同时长的时间窗，确保用户长时间使用习惯和短时间使用习惯的序列模式都能无遗漏地被挖掘，再从序列数据库中挖掘出序列模式，基于序列模式构造序列性特征，在检测到应用程序预测事件被触发的情况下，根据上述序列性特征对目标时间段内是否将启动目标应用程序进行预测，能够更准确地对目标时间段内是否将启动目标应用程序进行预测，有效地提高预测结果的准确度。

在第一方面的一种可能的实现方式中，上述根据多个不同回溯阈值的时间窗和目标应用程序切分上述历史应用程序使用序列，得到多个子序列，建立序列数据库，包括：为上述历史应用程序使用序列添加时间特征；将上述目标应用程序作为锚点，将上述历史应用程序切分为若干个应用程序子序列；根据上述应用程序子序列中的每个应用程序的时间特征和不同回溯阈值的时间窗进行回溯，得到各个回溯阈值的时间窗对应的子序列。

可以理解的是，在将目标应用程序作为锚点，将历史应用程序使用序列切分为多个应用程序子序列后，得到的每个应用程序子序列都是以目标应用程序为结尾的序列，且每个应用层程序子序列只存在一个目标应用程序。换言之，在一个应用程序子序列中只会存在一个目标应用程序，且该目标应用程序是该应用程序子序列中最后一个应用程序。

需要说明的是，回溯阈值可以根据实际需求来设置，利用多少个不同回溯阈值对应的时间窗进行回溯也可以根据实际需求来设置，本申请对此不作具体限制。

例如，上述不同回溯阈值的时间窗可以是1个小时、2个小时、4个小时、6个小时这四个回溯阈值对应的时间窗。即可以分别使用1小时时间窗、2小时时间窗、4小时时间窗以及6小时时间窗进行回溯，得到1小时时间窗对应的子序列、2小时时间窗对应的子序列、4小时时间窗对应的子序列以及6小时时间窗对应的子序列。

为了能够更灵活地挖掘出用户对于应用程序的使用习惯，本申请实施例利用不同回溯阈值的时间窗对用户的历史应用程序使用序列进行回溯，并结合目标应用程序对历史应用程序使用序列进行切分，使得得到的子序列能够从不同时间长度来体现用户的应用程序的使用习惯，且能够更好地将与目标应用程序相关的使用习惯挖掘出来。

在第一方面的一种可能的实现方式中，上述从上述序列数据库中挖掘序列模式，包括：

获取序列数据库中每个序列在不同统计时间段内的出现次数；

根据每个序列在各个统计时间段内的出现次数和各个统计时间段的权重系数计算每个序列的支持度。

根据序列数据库中每个序列的支持度确定出频繁子序列。

各个统计时间段的划分可以根据历史时间段的时长和需求来确定。例如，历史时间段为最近两个月（以一个月30天为例进行说明），则可以将历史时间段划分为3个统计时间段，分别为最近7天内，最近7天至最近30天以及30天以前。假设历史时间段为最近一个月（以一个月30天为例进行说明），则可以将历史时间段划分为最近7天、最近7天至最近15天、最近15天至最近30天内。当然，对于历史时间段为最近两个月的情况，也可以划分出多个不同的统计时间段，例如划分为最近7天、最近7天至最近15天、最近15天至最近30天以及30天前这四个统计时间段。当然，还可以将历史时间段内的每一天确定为一个统计时间段。

每个统计时间段对应的权重系数可以根据经验值来设置，本申请对此不作具体限制。

将支持度大于等于最小支持度的序列筛选出来，筛选出来的序列就是上述频繁子序列，即为序列模式。

通过为不同的统计时间段设置不同的权重系数，将越接近当前时间的统计时间段的权重系数设置的越大，越远离当前时间的统计时间段的权重系数设置的越小，使得挖掘出的序列模式能够关注到用户最近的使用习惯。

在第一方面的一种可能的实现方式中，上述根据上述序列模式构建序列性特征，包括：

确定出不同回溯时间窗中包含当前应用程序的序列模式；

将符合条件的包含上述当前应用程序的序列模式确定为目标序列模式；

根据上述目标序列模式的支持度确定上述当前应用程序的序列性特征。

针对不同回溯时间窗来构建当前应用程序的序列性特征，使得这些序列性特征能够体现出用户长时间使用习惯和短时间使用习惯的特征。

在第一方面的一种可能的实现方式中，上述根据上述目标序列模式的支持度确定上述当前应用程序的序列性特征，包括：

当只存在一个目标序列模式时，则将上述目标序列模式的支持度确定为上述当前应用程序的序列性特征；

当存在多个目标序列模式时，根据上述多个序列模式的支持度计算出预设的统计特征，将预设的统计特征确定为上述当前应用程序的序列性特征；

当不存在目标序列模式时，则将当前应用程序的序列性特征设置为0。

上述预设的统计特征可以包括但不限于最大值、最小值、平均值、总和、标准差等。当然，上述预设的统计特征还可以是方差、中位数等其他统计特征，本申请仅是以预设的统计特征为最大值、最小值、平均值、总和、标准差为例进行说明。

使用统计特征表征序列性特征，能够更全面的反应出当前应用程序的序列性特征。

在第一方面的一种可能的实现方式中，上述在检测到应用程序预测事件被触发的情况下，根据上述序列性特征对目标时间段内是否会启动目标应用程序进行预测，包括：

在检测到应用程序预测事件被触发的情况下，将上述序列性特征输入到应用程序预测模型中，由上述应用程序预测模型根据上述序列性特征进行预测，并输出预测结果。

上述应用程序预测模型可以利用决策树模型来构建，然后利用样本数据对构建出的初始的应用程序预测模型进行训练，以得到应用程序预测模型。

具体地，上述决策树模型可以是GBDT模型、XGboost模型、LightGBM模型等。

利用应用程序预测模型进行预测，能够有效提高预测的准确度和效率。

在第一方面的一种可能的实现方式中，上述在检测到应用程序预测事件被触发的情况下，根据上述序列性特征对目标时间段内是否会启动目标应用程序进行预测，包括：

根据上述序列性特征和时间性特征对目标时间段内是否会启动目标应用程序进行预测。

结合时间性特征和序列性特征来预测目标时间段内是否会启动目标应用程序，能够进一步提高预测的准确度。

在第一方面的一种可能的实现方式中，在检测到应用程序预测事件被触发的情况下，根据上述序列性特征对目标时间段内是否会启动目标应用程序进行预测之后，还包括：

在预测结果为目标时间段内将启动目标应用程序的情况下，预加载目标应用程序的启动资源。

进一步的，提高预测结果的准确度后，目标应用程序在目标时间段内被启动的概率越高，因此在预测到目标时间段内将启动目标应用程序的情况下，预先加载该目标应用程序的启动资源到系统内存中，能够有效地提高用户启动目标应用程序时的响应速度，缩短用户等待目标应用程序启动的时间，提升用户体验。

在第一方面的一种可能的实现方式中，上述历史应用程序使用序列为经过应用清洗后的历史应用程序使用序列。

上述获取历史应用程序使用序列，包括：

获取历史时间段内的历史应用程序使用数据；

对上述历史应用程序使用数据进行应用清洗，得到清洗后的历史应用程序使用数据；

根据清洗后的历史应用程序使用数据中各个应用程序的时间信息进行排序，得到上述历史应用程序使用序列。

在具体应用中，上述对原始历史应用程序使用数据/原始历史应用程序使用序列进行应用清洗可以包括以下两个步骤：

步骤1：对于用户连续打开同一应用程序的情况，合并上述连续打开的应用程序，并连续打开同一应用程序中第一次打开应用程序的启动时间作为该应用程序的时间信息。

需要说明的是，在判断是否为用户连续打开同一应用程序时，可以利用应用程序名和启动时间间隔来判断，即如果相同应用程序名的应用程序在预设时间间隔内重复开启，则可以确定为用户连续打开同一应用程序。

示例性的，假设用户在使用手机时，先打开了APP1，然后从APP1中切出回到桌面，再立即切换回APP1，则可以认为用户连续打开了APP1，此时只保留一条APP1的使用记录，并将第一次打开APP1的时间作为本条使用记录的时间信息。

又示例性的，假设用户在使用手机时，先打开了APP1，然后从APP1中切出回到桌面，接着用户又打开了APP2，浏览了2秒后，又从APP2切回至APP1，此时也可以认为用户连续打开了APP1，此时，只保留一条APP1的使用记录，并将第一次打开APP1的时间作为该使用记录的时间信息。

上述预设时间间隔可以根据使用情况来设置，例如设置为1分钟、又如设置为15秒等，本申请对此不作具体限制。

步骤2：将超级应用从上述原始的历史应用程序使用序列中删除。

需要说明的是，上述超级应用是指在用户使用过的应用程序中该应用程序的使用频率占比大于等于频繁使用占比的应用程序，即上述超级应用程序可以理解为用户会频繁打开的应用程序。上述频繁使用占比可以根据实际需求进行设置，例如设置为50%，即将用户使用的应用程序中使用频率大于等于50%的应用程序确定为超级应用。为了避免此类超级应用对后续序列模式挖掘的影响，就需要将上述超级应用从上述原始的历史应用程序使用序列中删除，这样构建出的序列数据库中包含的各个子序列会更简单明了，不会重复多次出现该超级应用。

使用经过应用清洗的应用程序使用序列，能够减少数据干扰，使得构建出的序列数据中包含的各个子序列更加简单明了，更能够挖掘出用户的使用习惯，提高预测准确度。

第二方面，本申请实施例提供一种电子设备，包括：

数据获取模块，用于获取历史应用程序使用序列；

序列数据库构建模块，用于根据多个不同回溯阈值的时间窗和目标应用程序切分上述历史应用程序使用序列，得到多个子序列，建立序列数据库；

序列模式挖掘模块，用于从上述序列数据库中挖掘序列模式；

特征构造模块，用于根据上述序列模式构建序列性特征；

预测模块，用于在检测到应用程序预测事件被触发的情况下，根据上述序列性特征对目标时间段内是否会启动目标应用程序进行预测。

第三方面，本申请实施例提供一种电子设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面任一项的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面任一项的方法。

第五方面，本申请实施例提供一种芯片系统，该芯片系统包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现如上述第一方面任一项上述的方法。该芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。

第六方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面任一项上述的方法。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请实施例提供的一种手机的硬件结构示意图。

图2是本申请实施例提供的一种手机的软件系统架构的示意图。

图3是在没有应用程序预测和应用程序预加载的场景下的启动应用程序时手机100的UI界面跳转示意图。

图4是通过本申请实施例提供的应用程序预测和应用程序预加载的场景下的手机100的UI界面跳转示意图。

图5是通过本申请实施例提供的应用程序预测和应用程序预加载的场景下的手机100的另一UI界面跳转示意图。

图6是通过本申请实施例提供的应用程序预测和应用程序预加载的场景下的手机100的另一UI界面跳转示意图。

图7是通过本申请实施例提供的应用程序预测和应用程序预加载的场景下的手机100的另一UI界面跳转示意图。

图8是本申请实施例提供的另一种应用程序预测方法的实现流程示意图。

图9是本申请实施例提供的应用程序预测方法中切分历史应用程序使用序列得到多个子序列的过程示意图。

图10是本申请实施例提供的当前应用程序的序列性特征的示例性示意图。

图11是本申请实施例提供的应用程序预测模型的预测过程示意图。

具体实施方式

需要说明的是，本申请实施例的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联物的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，除非另有说明，“多个”是指两个或多于两个，“至少一个”、“一个或多个”是指一个、两个或两个以上。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”特征可以明示或者隐含地包括一个或者更多个该特征。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

为了缩短用户等待如手机游戏等大型应用程序启动的时长，对手机游戏等大型应用程序进行预加载是常用且有效的方法。

上述对应用程序进行预加载是指通过预测出用户在未来一段时间内是否会启动应用程序，在预测到用户在未来一段时间内将启动该应用程序的情况下，提前将启动该应用程序所需要的资源加载至电子设备的系统内存中，即预加载应用程序的启动资源，在预加载应用程序的启动资源后，当用户启动该应用程序时，就能够快速启动该应用程序，用户无需经历等待应用程序加载的过程，缩短用户等待应用程序启动的时长，提升用户体验。

目前对于应用程序预测通常是通过获取电子设备先前活动的应用程序序列，基于对先前活动的应用程序序列的分析来预测该电子设备上的下一个启动的应用程序，并为预测到的下一个启动的应用程序预加载启动资源。

这种方式没有考虑用户使用的应用程序的使用关联性，会使得预测的准确性较低。为了综合用户使用的APP之间的使用关联性来提高应用程序预测的准确性，可以基于序列模式从用户的历史APP使用序列中提取出用户的APP使用关联性，并在预测的时候综合考虑用户最近的行为模式以及用户当前使用的时间上下文信息进行预测，从而来提高预测的准确度。

然而目前这种预测方法的准确度依旧较低，经过试验，通过目前的预测方法进行预测并基于预测结果进行预加载后，预加载精确率高于90%的覆盖人数和平均冷启动率的下降程度均不能达到要求。

为了提高对需要预加载的应用程序（即目标应用程序）在未来一段时间（以下称为目标时间段）内是否启动的预测（即应用程序预测）的准确率，本申请实施例提供了一种应用程序预测方法，该方法基于电子设备的应用程序使用记录，获取按照启动顺序排序的历史应用程序使用序列，并通过不同时间阈值的时间窗和目标应用程序对历史应用程序使用序列进行切分，得到多个应用程序子序列，以此构建序列数据库，使得构建的序列数据库能够将特定应用程序（即目标应用程序）作为分切点，并回溯不同时长的时间窗，确保用户长时间使用习惯和短时间使用习惯的序列模式都能无遗漏地被挖掘。再从序列数据库中挖掘出序列模式，基于序列模式构造序列性特征，在检测到应用程序预测事件被触发的情况下，利用应用程序预测模型根据上述序列性特征和原时间性特征对目标时间段内是否将启动目标应用程序进行预测，将挖掘出的序列模式的特点通过序列性特征的方式输入到应用程序预测模型中，使得应用程序预测模型能够更准确地对目标时间段内是否将启动目标应用程序进行预测，有效地提高预测结果的准确度。

进一步的，提高预测结果的准确度后，目标应用程序在目标时间段内被启动的概率越高，因此在预测到目标时间段内将启动目标应用程序的情况下，预先加载该目标应用程序的启动资源到系统内存中，能够有效地提高用户启动目标应用程序时的响应速度，提升用户体验。

下面将结合附图对本申请实施例提供的应用程序预测方法进行详细阐述，以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。

上述应用程序预测方法的执行主体可以是电子设备，例如可以是手机、可穿戴设备（如智能手表、智能手环、智能眼镜、智能首饰等）、平板电脑、车载设备、增强现实（augmented reality，AR）/虚拟现实（virtual reality，VR）设备、笔记本电脑、超级移动个人计算机（ultra-mobile personal computer，UMPC）、上网本、个人数字助理（personaldigital assistant，PDA）以及其他具有网络连接功能的电子设备。

上述电子设备的示例性实施例包括但不限于搭载iOS®、Android®、Microsoft®、鸿蒙系统（Harmony OS）或者其他操作系统的设备。上述电子设备也可以是其他电子设备，诸如具有触敏表面（例如触控面板）的膝上型计算机（laptop）等，本申请实施例对电子设备的具体类型不做任何限制。

以上述电子设备为手机为例，如图1所示，为本申请实施例提供的一种手机的结构示意图。

图1示出了手机100的结构示意图。手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线11，天线12，移动通信模块150，无线通信模块160，音频模块170，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本发明实施例示意的结构并不构成对手机100的具体限定。在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integratedcircuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K，充电器，闪光灯，摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180K，使处理器110与触摸传感器180K通过I2C总线接口通信，实现手机的触摸功能。

MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。MIPI接口包括摄像头串行接口 (camera serial interface，CSI)，显示屏串行接口 (displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现手机的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现手机的显示功能。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为手机充电，也可以用于手机与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他手机，例如AR设备等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对手机的结构限定。在本申请另一些实施例中，手机也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

手机的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。手机中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在手机上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(lownoise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器modem进行解调。移动通信模块150还可以对经调制解调处理器modem调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器modem可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在手机上的包括无线局域网 (wireless localarea networks，WLAN) (如无线保真 (wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，手机的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得手机可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(globalnavigation satellite system，GLONASS)，北斗卫星导航系统 (beidou navigationsatellite system，BDS)，准天顶卫星系统(quas-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

手机通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体 (active-matrixorganic light emitting diode，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oled，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，手机可以包括1个或N个显示屏194，N为大于1的正整数。

手机的显示屏1 94上可以显示一系列图形用户界面 (graphical userinterface，GUI)，这些GUI都是该手机的主屏幕。一般来说，手机的显示屏194的尺寸是固定的，只能在该手机的显示屏194中显示有限的控件。控件是一种GUI元素，它是一种软件组件，包含在应用程序中，控制着该应用程序处理的所有数据以及关于这些数据的交互操作，用户可以通过直接操作(direct manipulation)来与控件交互，从而对应用程序的有关信息进行读取或者编辑。一般而言，控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行手机的各种功能应用以及数据处理。例如，在本实施例中，处理器110可以通过执行存储在内部存储器121中的指令，生成地理围栏。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储手机使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行手机的各种功能应用以及数据处理。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。手机根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，手机根据压力传感器180A检测所述触摸操作强度。手机也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

陀螺仪传感器180B可以用于确定手机的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定手机围绕三个轴(即，x，y和z轴)的角速度。陀螺仪传感器180B可以用于拍摄防抖。示例性的，当按下快门，陀螺仪传感器180B检测手机抖动的角度，根据角度计算出镜头模组需要补偿的距离，让镜头通过反向运动抵消手机的抖动，实现防抖。陀螺仪传感器180B还可以用于导航，体感游戏场景。

气压传感器180C用于测量气压。在一些实施例中，手机通过气压传感器180C测得的气压值计算海拔高度，辅助定位和导航。

加速度传感器180E可检测手机在各个方向上(一般为三轴)加速度的大小。当手机静止时可检测出重力的大小及方向。还可以用于识别手机姿态，应用于横竖屏切换，计步器等应用。

接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。手机通过发光二极管向外发射红外光。手机使用光电二极管检测来自附近物体的红外反射光。当检测到充分的反射光时，可以确定手机附近有物体。当检测到不充分的反射光时，手机可以确定手机附近没有物体。手机可以利用接近光传感器180G检测用户手持手机贴近耳朵通话，以便自动熄灭屏幕达到省电的目的。接近光传感器180G也可用于皮套模式，口袋模式自动解锁与锁屏。

指纹传感器180H用于采集指纹。手机可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。

触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于手机的表面，与显示屏194所处的位置不同。

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。手机可以接收按键输入，产生与手机的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和手机的接触和分离。手机可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。所述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。手机通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，手机采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在手机中，不能和手机分离。

示例性的，手机100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明手机100的软件结构。图2是本申请实施例的手机100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时（Android runtime）和系统库，以及内核层。

其中，图2仅示出了与本申请实施例提供的应用程序预测方法相关的软件层所包含的模块。

应用程序层可以包括一系列应用程序包。如图2所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，视频，即时聊天，游戏等应用程序。在应用程序运行之前，可以通过本申请实施例提供的应用程序预测方法预测是否会打开视频、游戏等应用，并在预测结果为在目标时间段内将打开视频应用的情况下，预先加载视频应用的启动资源，在预测结果为在目标时间段内将打开游戏应用的情况下，预先加载游戏应用的启动资源。

应用程序框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。应用程序框架层包括一些预先定义的函数。如图2所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，进程管理器，资源管理器，通知管理器等。

在本申请实施例中，在预测应用程序时，应用程序框架层可以为应用程序层提供与应用程序预测功能相关的API，例如数据采集模块、数据保存模块、序列数据库构造模块、序列模式挖掘模块、特征构造模块、预测模块等。

其中，数据采集模块和数据保存模块作为感知模块。数据采集模块用于感知应用程序的运行状态，如应用程序启动、应用程序退出、应用程序前后台切换、应用程序安装、应用程序卸载等事件。数据保存模块能够保存用户启动应用程序的时刻（即应用程序的启动时刻）、用户关闭应用程序的时刻（应用程序的关闭时刻）、应用程序切换到后台的时刻等时刻，并基于此得到历史应用程序使用序列。

序列数据库构建模块、序列模式挖掘模块、特征构造模块、预测模块组成计算引擎。序列数据库构建模块用于根据基于多个不同回溯阈值的时间窗和目标应用程序切分历史应用程序使用序列，得到多个子序列，组成序列数据库。序列模式挖掘模块用于从上述序列数据库中挖掘出序列模式。特征构造模块用于根据序列模式构建序列性特征。预测模块用于在检测到应用程序预测事件被触发的情况下，根据序列性特征和时间性特征预测目标时间段内是否会启动目标应用程序。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

进程管理模块用于在预测模块预测到目标时间段内将启动目标应用程序的情况下，将目标应用程序的启动资源加载至系统内存中，这样，在目标时间段内用户启动目标应用程序时，就不需要等待该目标应用程序的启动资源加载过程，可以直接展示该目标应用程序的UI界面，实现用户“零等待”启动应用程序，提升用户体验。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行目标生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器（surface manager），媒体库（Media Libraries），三维图形处理库（例如：OpenGL ES），2D图形引擎（例如：SGL）等。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

需要说明的是，本申请实施例虽然以Android系统为例进行说明，但是其基本原理同样适用于基于iOS®，Windows或harmony等操作系统的电子设备。

本申请实施例提供的应用程序预测方法可以运行在应用程序框架层，即可以通过应用程序框架层中的各个模块来实现上述应用程序预测方法。

本申请实施例提供的应用程序预测方法，可以适用于对不同的目标应用程序的预测任务。举例来说，本申请实施例提供的应用程序预测方法能够应用在预测未来一段时间内（目标时间段）是否启动手机游戏、预测目标时间段内是否启动视频软件、预测目标时间段内是否启动购物软件等业务场景中。

应用程序预测的过程和预加载过程对于用户来说是无感知的，用户只能感受到无等待启动目标应用程序，因此，本申请实施例将详细介绍，在手机100上无法直观展示对应用程序预测的应用场景下，应用程序的预测过程和预加载过程。

首先，结合图3至图7说明在应用程序预测事件对应不同的触发时机下，手机100的图形用户界面（user interface，UI）界面的变化过程。

在本申请实施例中，当应用程序预测事件被触发时，手机就可以执行本申请实施例提供的应用程序方法对目标时间段内是否将启动目标应用程序进行预测，并在预测结果为将会启动目标应用程序的情况下，预先加载该目标应用程序的启动资源。

首先，为了体现本申请实施例提供的应用程序预测方法的技术效果（即缩短用户等待应用程序启动的时间）。图3示出了在没有应用程序预测和应用程序预加载的场景下的启动应用程序时手机100的UI界面跳转示意图。如图3中的（a）所示，用户点击其他应用程序（例如相机APP）时，手机100的UI界面跳转至如图3中的（b）所示的相机APP的UI界面。而在用户点击浏览器APP时并不会触发应用程序预测事件，因此，电子设备不会目标时间段内是否将启动目标应用程序（视频APP）进行预测，相应地，也不会加载视频APP所需的启动资源。因此，在用户点击视频APP的图标时，手机100的UI界面会显示如图3中的（d）所示的等待视频APP启动的界面，而视频APP的启动资源加载完毕后，手机100的U1界面跳转至如图3中的（e）所示的视频APP的使用界面。

在本申请实施例中，上述应用程序预测事件的触发时机可以包括但不限于以下几种：

1、当某个应用程序被打开时，触发应用程序预测事件。

示例性的，请参阅图4，图4示出了通过本申请实施例提供的应用程序预测和应用程序预加载的场景下的手机100的UI界面跳转示意图。如图4中的（a）所示，用户点击相机APP时，手机100的UI界面跳转至如图4中的（b）所示的相机APP的UI界面，此时将触发应用程序预测事件，即手机会对目标时间段内是否将启动视频APP进行预测，在预测到目标时间内将启动视频APP的情况下，提前加载视频APP的启动资源。在手机预加载完视频APP的启动资源后，在用户点击视频APP的图标时，响应用户点击视频APP图标的点击操作，手机100直接跳转至显示如图4中的（d）所示的视频APP的首页界面。

与图3所示的方案相比，图4所示的打开视频APP的过程，节省了等待视频APP加载的时间，减少了用户等待应用程序启动的时间，提高了用户体验。

2、当检测到屏幕解锁操作时，触发应用程序预测事件。

示例性的，如图5中的（a）所示，当用户解锁屏幕时，触发应用程序预测事件，即手机会对目标时间段内是否将启动视频APP进行预测，在预测到目标时间内将启动视频APP的情况下，提前加载视频APP的启动资源。在手机预加载完视频APP的启动资源后，在用户点击视频APP的图标时，响应于用户点击视频APP图标的点击操作，手机100跳转至显示如图5中的（c）所示的视频APP的首页界面。

3、当从某个应用程序的使用界面切换到另一个应用程序的使用界面时，触发应用程序预测事件。

示例性的，如图6中的（a）所示，当用户从相机APP的使用界面切换到即时聊天APP的使用界面时，触发应用程序预测事件，即手机会对目标时间段内是否将启动视频APP进行预测，在预测到目标时间段内将启动视频APP的情况下，提前加载视频APP的启动资源。在手机预加载完视频APP的启动资源后，在用户点击视频APP的图标时，响应于用户点击视频APP图标的点击操作，手机100跳转至显示如图6中的（c）所示的视频APP的首页界面。

4、当从某个应用程序的使用界面返回到系统桌面时，触发应用程序预测事件。

示例性的，如图7中的（a）所示，当用户关闭当前使用的应用程序（例如相机APP）返回桌面时，触发应用程序预测事件，即手机会对目标时间段内是否将启动视频APP进行预测，在预测到目标时间段内将启动视频APP的情况下，提前加载视频APP的启动资源。在手机预加载完视频APP的启动资源后，在用户点击视频APP的图标时，响应于用户点击视频APP图标的点击操作，手机100跳转至显示如图7中的（c）所示的视频APP的首页界面。

需要说明的是，应用程序预测事件的触发时机可以根据实际需求设置，除上述四种触发时机外，还包括其他触发时机，例如，按照预设时间间隔触发应用程序预测事件等，此处不再一一详述。

在一些实施例中，预加载应用程序的页面资源可以根据用户的需求设置，例如在预加载应用程序的启动资源时，系统后台预加载应用程序对应的首页的页面资源或者预加载上一次退出时应用程对应的页面资源等，本申请对此不作具体限制。

例如，在预加载视频APP的启动资源时，系统后台还可以直接预加载用户上一次退出视频APP时对应的页面资源，此种情况下，当用户点击视频APP的图标时，手机100响应于该点击操作，手机100的UI界面可以展示如图4中的（d）所示的用户上一次观看的视频对应的播放界面。

在本申请一实施例中，在电子设备加载完目标应用程序启动所需的启动资源后，可以不显示任何信息，在用户启动目标应用程序时，用户可以感受到应用“零等待”启动，提升用户体验。

在本申请一实施例中，在电子设备加载完目标应用程序启动所需的启动资源后，可以通过通知提示栏展示目标应用程序的提示信息，这样用户就可以通过点击通知提示栏中提示信息来启动目标应用程序，并在用户点击该提示信息时直接展示该目标应用程序的UI界面。

在另一种应用场景中，在电子设备加载完目标应用程序启动所需的启动资源后，可以通过悬浮球的方式展示目标应用程序的图标，这样用户就可以通过点击该图标来启动目标应用程序，并在用户点击该图标启动目标应用程序时直接展示该目标应用程序的UI界面。

以上结合附图，对本申请实施例提供的应用预测方法所适用的应用场景，应用程序预测事件触发方式等进行了介绍。为了更好地理解本申请实施例提供的应用预测方法，以下结合附图对其具体实现过程进行示例性介绍。

示例性的，如图8所示，为本申请实施例提供的应用程序预测方法的实现流程示意图。需要说明的是，上述应用程序预测方法的执行主体可以是上述电子设备，上述应用程序预测方法具体可以包括以下步骤：

S801：获取历史应用程序使用序列。

在本申请实施例中，上述历史应用程序使用序列包括用户在历史时间段内使用过的所有应用程序，以及每个应用程序对应的时间信息，且按历史应用程序使用序列中还根据每个应用程序对应的时间信息对应用程序进行了先后顺序排序。

历史时间段可以根据实际需求选取，例如，最近三个月，或最近两个月，或最近一个月，或最近20天，或最近两周内。

示例性的，假设历史时间段是最近两个月，那么历史应用程序使用序列为用户在最近两个月内每天使用的所有应用程序，且按照每个应用程序对应的时间信息进行先后顺序排序后得到的序列。

上述每个应用程序时间信息可以包括但不限于启动时间、关闭时间、前端运行时长等。

在本申请实施例中，上述按照每个应用程序对应的时间信息进行先后顺序排序具体可以是按每个应用程序的启动时间进行先后顺序排序。

在具体应用中，当用户打开、关闭、前后台切换、安装、卸载应用程序时，电子设备会产生相应的事件，即当用户打开应用程序时，电子设备会产生APP开启事件；当用户关闭（退出）应用程序时，电子设备会产生APP退出事件；当用户将应用程序切换到后台运行时；电子设备会产生APP切至后台运行事件等。数据采集模块就可以感知（检测）此类事件，并基于此确定应用程序的运行状态。

电子设备在检测到某一APP的开启事件或退出事件时，电子设备可以记录相应的时间，即在检测到APP的开启事件时，记录该APP的启动时间；在检测到APP的关闭事件时，记录该APP的关闭时间。

电子设备可以将记录到的应用程序的相应事件和事件相应的时间（即使用记录）进行保存，这样就可以得到电子设备的应用程序的使用数据。示例性的，电子设备通过数据采集模块感知应用程序的运行状态，并记录应用程序的相关信息，例如应用程序的启动时间、应用程序的关闭时间等，并将这些信息传递给数据保存模块进行保存，数据保存模块就能够按照时间顺序记录用户使用每个应用程序的相关信息，并按照应用程序的启动时间（当然也可以是使用时间（即启动时间到关闭时间之间的时间段）等其他时间信息）的先后顺序对历史时间段内电子设备的应用程序的使用数据进行排序，以得到历史应用程序使用序列。

例如，用户某一天上午使用了5个APP，具体的，7:00打开了APP1，7:30打开了APP2，9:00打开了APP3，11:00打开了APP4，11:30打开了APP5，则按照这5个APP的开启时间由早至晚的顺序排列得到的APP序列为{APP1，APP2，APP3，APP4，APP5}。为了方便描述，该APP序列示例仅示出了APP名称，该APP序列还可以包括每个APP的开启时间和关闭时间，其中，开启时间是指用户打开该APP的时刻，关闭时间是指用户关闭该APP(如退出或切换至后台)的时刻。

需要说明的是，用户在历史时间段内可能多次使用同一款应用程序，则该应用程序在上述历史应用程序使用序列中会出现多次。即该历史应用程序使用序列中不同排序位置的应用程序可能是同一款应用程序。例如，用户在历史时间段的3个不同时间点都使用了第一应用程序，则上述第一应用程序在上述历史应用程序使用序列中将出现3次。

在本申请一实施例中，上述获取到的历史应用程序使用序列可以是经过应用清洗后的历史应用程序使用序列。

在具体应用中，电子设备可以获取电子设备在历史时间段内的应用程序的使用数据（即原始历史应用程序使用数据），并对获取到原始历史应用程序使用数据进行应用清洗，得到清洗后的历史应用程序使用数据，再基于历史应用程序使用数据中应用程序的时间顺序进行先后排序，进而得到清洗后的历史应用程序使用序列。

在具体应用中，电子设备可以获取电子设备的原始历史应用程序使用数据，然后根据应用程序的时间信息进行先后排序，得到原始历史应用程序使用序列，再对原始历史应用程序使用序列进行应用清洗，得到数据清洗后的应用程序使用序列。即，在本申请实施例中，S801中获取到的历史应用程序使用序列可以是经过应用清洗后的历史应用程序使用序列。

在具体应用中，上述对原始历史应用程序使用数据/原始历史应用程序使用序列进行应用清洗可以包括以下两个步骤：

步骤1：对于用户连续打开同一应用程序的情况，合并上述连续打开的应用程序，并连续打开同一应用程序中第一次打开应用程序的启动时间作为该应用程序的时间信息。

需要说明的是，在判断是否为用户连续打开同一应用程序时，可以利用应用程序名和启动时间间隔来判断，即如果相同应用程序名的应用程序在预设时间间隔内重复开启，则可以确定为用户连续打开同一应用程序。

示例性的，假设用户在使用手机时，先打开了APP1，然后从APP1中切出回到桌面，再立即切换回APP1，则可以认为用户连续打开了APP1，此时只保留一条APP1的使用记录，并将第一次打开APP1的时间作为本条使用记录的时间信息。

又示例性的，假设用户在使用手机时，先打开了APP1，然后从APP1中切出回到桌面，接着用户又打开了APP2，浏览了2秒后，又从APP2切回至APP1，此时也可以认为用户连续打开了APP1，此时，只保留一条APP1的使用记录，并将第一次打开APP1的时间作为该使用记录的时间信息。

上述预设时间间隔可以根据使用情况来设置，例如设置为1分钟、又如设置为15秒等，本申请对此不作具体限制。

步骤2：将超级应用从上述原始的历史应用程序使用序列中删除。

需要说明的是，上述超级应用是指在用户使用过的应用程序中该应用程序的使用频率占比大于等于频繁使用占比的应用程序，即上述超级应用程序可以理解为用户会频繁打开的应用程序。上述频繁使用占比可以根据实际需求进行设置，例如设置为50%，即将用户使用的应用程序中使用频率大于等于50%的应用程序确定为超级应用。为了避免此类超级应用对后续序列模式挖掘的影响，就需要将上述超级应用从上述原始的历史应用程序使用序列中删除，这样构建出的序列数据库中包含的各个子序列会更简单明了，不会重复多次出现该超级应用。

需要说明的是，本申请对上述步骤1和上述步骤2的执行顺序不作限制，即电子设备可以先执行步骤1再执行步骤2，也可以先执行步骤2再执行步骤1，还可以同时执行步骤1和步骤2，所形成的不同技术方案均在本申请的保护范围内。

示例性的，假设电子设备获取到的原始历史应用程序使用数据包括以下数据：

1、2022年8月8日8:01:00，启动APP1；

2、2022年8月8日8:14:06，退出APP1；

3、2022年8月8日8:15:05，启动APP2；

4、2022年8月8日8:25:45，退出APP2；

5、2022年8月8日8:30:06，启动APP3；

6、2022年8月8日8:38:06，退出APP3；

7、2022年8月8日9:15:20，启动APP2；

8、2022年8月8日9:50:05，退出APP2；

9、2022年8月8日10:15:00，启动APP2；

10、2022年8月8日10:20:05，退出APP2；

11、2022年8月8日16:15:00，启动APP4；

12、2022年8月8日16:15:00，由APP4切换至桌面，APP4后台运行；

13、2022年8月8日16:15:06，启动APP4；

14、2022年8月8日19:00:00，启动APP2；

15、2022年8月8日19:15:00，退出APP2。

则根据上述原始历史应用程序使用数据可以得到的原始历史应用程序使用序列为：{APP1、APP2、APP3、APP2、APP2、APP4、APP4、APP2}。

假设预设时间间隔为15秒，频繁使用占比为50%，即可以确定出APP2为超级应用（使用频率占比为50%），在进行应用清洗时，应该删除APP2；且用户连续打开APP4，因此数据11、数据12、数据13应该合并为一条数据，因此，对原始历史应用程序使用序列进行应用清洗后得到的历史应用程序使用序列为：{APP1、APP3、APP4}。

S802：根据多个不同回溯阈值的时间窗和目标应用程序切分历史应用程序使用序列，得到多个子序列，建立序列数据库。

在具体应用中，为了能够回溯不同回溯阈值的时间窗，可以为上述历史应用程序使用序列添加时间特征。具体地，上述时间特征可以是各个应用程序的启动时间与目标应用程序的启动时间的时间差。

示例性的，假设历史应用程序使用序列为：{APP1、APP2、APP3、APP4、APP1、APP3、APP5}。其中，APP5为目标应用程序，假设APP5的启动时间为2022年8月8日19:19:00，第一个应用程序APP1的启动时间为2022年8月8日13:19:00，第二个应用程序APP2的启动时间为2022年8月8日15:19:00，第三个应用程序APP3的启动时间为2022年8月8日16:19:00，第四个应用程序APP4的启动时间为2022年8月8日17:19:00，第五个应用程序APP1的启动时间为2022年8月8日18:19:00，第六个应用程序APP3的启动时间为2022年8月8日19:15:00。

按照序列顺序，第一个应用程序APP1的时间特征为6个小时（即2022年8月8日13:19:00与2022年8月8日19:19:00的时间差），第二个应用程序APP2的时间特征为4个小时（即2022年8月8日15:19:00与2022年8月8日19:19:00的时间差），第三个应用程序APP3的时间特征为3个小时（即2022年8月8日16:19:00与2022年8月8日19:19:00的时间差），第四个应用程序APP4的时间特征为2个小时（即2022年8月8日17:19:00与2022年8月8日19:19:00的时间差），第五个应用程序APP1的时间特征为1个小时（即2022年8月8日18:19:00与2022年8月8日19:19:00的时间差），第六个应用程序APP3的时间特征为4分钟（即2022年8月8日19:15:00与2022年8月8日19:19:00的时间差）。

在本申请实施例中，在得到历史应用程序使用序列后，可以先将目标应用程序作为锚点，将历史应用程序使用序列切分为多个应用程序子序列，然后再对每一个应用程序子序列回溯不同回溯阈值的时间窗，得到不同回溯阈值的时间窗对应的子序列，这样就可以得到多个子序列，从而建立序列数据库。

可以理解的是，在将目标应用程序作为锚点，将历史应用程序使用序列切分为多个应用程序子序列后，得到的每个应用程序子序列都是以目标应用程序为结尾的序列，且每个应用层程序子序列只存在一个目标应用程序。换言之，在一个应用程序子序列中只会存在一个目标应用程序，且该目标应用程序是该应用程序子序列中最后一个应用程序。

为了能够更灵活地挖掘出用户对于应用程序的使用习惯，本申请实施例利用不同回溯阈值的时间窗对用户的历史应用程序使用序列进行回溯，并结合目标应用程序对历史应用程序使用序列进行切分，使得得到的子序列能够从不同时间长度来体现用户的应用程序的使用习惯，且能够更好地将与目标应用程序相关的使用习惯挖掘出来。

需要说明的是，回溯阈值可以根据实际需求来设置，利用多少个不同回溯阈值对应的时间窗进行回溯也可以根据实际需求来设置，本申请对此不作具体限制。

例如，上述不同回溯阈值的时间窗可以是1个小时、2个小时、4个小时、6个小时这四个回溯阈值对应的时间窗。即可以分别使用1小时时间窗、2小时时间窗、4小时时间窗以及6小时时间窗进行回溯，得到1小时时间窗对应的子序列、2小时时间窗对应的子序列、4小时时间窗对应的子序列以及6小时时间窗对应的子序列。

示例性的，请参阅图9，图9为本申请实施例提供的应用程序预测方法中切分历史应用程序使用序列得到多个子序列的过程示意图。假设上述历史应用程序使用序列如图9中的（a）所示，假设APP2为目标应用程序，将APP2作为锚点将上述历史应用程序使用序列进行切分，就可以得到如图9中的（b）所示的应用程序子序列1、应用程序子序列2、应用程序子序列3。

对于应用程序子序列1，分别使用回溯阈值为1小时的时间窗、回溯阈值为2小时的时间窗进行回溯，就可以得到如图9中的（c）所示的子序列1（对应1小时的时间窗）、子序列2（对应2小时时间窗）。

对于应用程序子序列2，同样分别使用回溯阈值为1小时的时间窗、回溯阈值为2小时的时间窗进行回溯，就可以得到如图9中的（c）所示的子序列3（对应1小时的时间窗）、子序列4（对应2小时时间窗）。

对于应用程序子序列3，分别使用回溯阈值为1小时的时间窗、回溯阈值为2小时的时间窗进行回溯，就可以得到如图9中的（c）所示的子序列5、子序列6（对应2小时时间窗）。

子序列1、子序列2、子序列3、子序列4、子序列5、子序列6构成上述序列数据库。

S803：从序列数据库中挖掘序列模式。

在具体应用中，序列模式挖掘就是指从序列数据库中寻找频繁子序列作为序列模式的过程，即输入一个序列数据库，输出所有不小于最小支持度的序列的过程，这些输出的序列就是本申请实施例所提及的序列模式。

在具体应用中，从序列数据库中挖掘序列模式可以利用已有的序列模式挖掘算法来实现，上述序列模式挖掘算法包括但不限于AprioriAll算法、GSP 算法、FreeSpan算法等，本申请对此不加以赘述。

在本申请一实施例中，为了使挖掘出的序列模式能够关注到用户最近的使用习惯，上述S803可以包括以下步骤：

获取序列数据库中每个序列在不同统计时间段内的出现次数；

根据每个序列在各个统计时间段内的出现次数和各个统计时间段的权重系数计算每个序列的支持度；

根据序列数据库中每个序列的支持度确定出频繁子序列。

在具体应用中，各个统计时间段的划分可以根据历史时间段的时长和需求来确定。例如，历史时间段为最近两个月（以一个月30天为例进行说明），则可以将历史时间段划分为3个统计时间段，分别为最近7天内，最近7天至最近30天以及30天以前。假设历史时间段为最近一个月（以一个月30天为例进行说明），则可以将历史时间段划分为最近7天、最近7天至最近15天、最近15天至最近30天内。当然，对于历史时间段为最近两个月的情况，也可以划分出多个不同的统计时间段，例如划分为最近7天、最近7天至最近15天、最近15天至最近30天以及30天前这四个统计时间段。当然，还可以将历史时间段内的每一天确定为一个统计时间段，本申请对此不作具体限制。

在具体应用中，每个统计时间段对应的权重系数可以根据经验值来设置，本申请对此不作具体限制。

具体的，为了使得挖掘出的序列模式能够关注到用户最近的使用习惯，在设置统计时间段的权重系数时，将越接近当前时间的统计时间段的权重系数设置的越大，越远离当前时间的统计时间段的权重系数设置的越小。

示例性的，可以对于30天内的统计时间段，可以将权重系数设置为该统计时间段的时间跨度的倒数，将超过30天的统计时间段的权重系数设置为1/30。

又示例性的，假设将历史时间段划分为第一统计时间段、第二统计时间段以及第三统计时间段，则对应于第一统计时间段设置第一权重系数，对应于第二统计时间段设置第二权重系数，对应于第三统计时间段设置第三权重系数。假设第一统计时间段更接近当前时间，其次是第二统计时间段，最远的是第三统计时间段，那么第一权重系数大于第二权重系数，第二权重系数大于第三权重系数。

例如对于最近7天、最近7天至最近30天、30天前这三个统计时间段，可以将最近7天的权重系数设置为1/3.5，将最近7天至最近30天的权重系数设置为1/15，将30天前的权重系数设置为1/30。

在确定某个序列的支持度时，需要统计出该序列在每个统计时间段的出现次数，然后将每个统计时间段的出现次数乘以各个统计时间段对应的权重系数，得到该序列各个统计时间段对应的支持度，再将该序列所有统计时间段的支持度相加就得到了该序列的支持度。

示例性的，假设序列{APP2、APP3、目标APP}在最近7天内出现了7次，在最近7天至最近30天内出现了6次，在30天前出现了9次，假设最近7天的权重系数为1/3.5，将最近7天至最近30天的权重系数为1/15，将30天前的权重系数为1/30，那么序列{APP2、APP3、目标APP}的支持度为2.7（7/3.5+6/15+9/30）。

按照上述方式计算出序列数据库中每个序列的支持度后，就可以根据每个序列的支持度筛选出频繁子序列，即将支持度大于等于最小支持度的序列筛选出来，筛选出来的序列就是上述频繁子序列，即为序列模式。

需要说明的是，上述支持度用于表征某个序列出现的可能性。示例性的，以{APP2、APP3、目标APP}为例，其支持度的含义是用户先使用APP2，再使用APP3之后，打开目标APP的可能性。

S804：根据序列模式构建序列性特征。

在具体应用中，前述步骤中已经提到，本申请实施例中构建序列数据库时是利用不同回溯阈值的时间窗对历史应用程序使用序列进行回溯的，因此在构建序列性特征时，可以针对不同的时间窗挖掘出的序列模式来构建序列性特征。

示例性的，假设序列模式中存在5个序列模式是回溯1个小时对应的子序列，存在6个序列模式是回溯2个小时对应的子序列，有1个序列模式是回溯4个小时对应的子序列，有1个序列模式是回溯6个小时对应的子序列，那么在构建序列性特征时，会针对回溯1个小时的5个序列模式来构建1小时对应的序列性特征，针对2小时的6个序列模式构建序列性特征，针对4小时的1个序列模式构建序列性特征，针对6小时的1个序列模式构建序列性特征。

也就是说，对于当前应用程序，可以构建出多个序列性特征，每个序列性特征对应一个时间窗。

示例性的，请参阅图10，假设在构建序列数据库时使用的是1小时时间窗、2小时时间窗、4小时时间窗以及6小时时间窗进行回溯得到的序列，那么对于当前应用程序，可以构建出1小时时间窗对应的序列性特征、2小时时间窗对应的序列性特征、3小时时间窗对应的序列性特征以及6小时时间窗对应的序列性特征。

在本申请实施例中，上述构建序列性特征时，是指针对当前应用程序构建的序列性特征。上述当前应用程序是指在触发应用程序预测事件时用户正在使用的应用程序，或者指在触发应用程序预测事件时用户最近使用的应用程序。

构建当前应用程序的序列性特征的过程可以是：先确定出不同回溯时间窗中包含当前应用程序的序列模式，再根据包含当前应用程序且符合条件的序列模式的支持度确定出当前应用程序的序列性特征。

示例性的，以当前应用程序为APP5为例，先确定出回溯1小时对应的频繁子序列中包含APP5的序列模式有哪些，然后再根据应用程序使用情况判断包含APP5的序列模式中哪个序列模式符合条件，将符合条件的序列模式（简称为目标序列模式）确定出来，然后根据目标序列模式的支持度设置回溯1小时当前应用程序的序列性特征。接着确定出回溯2小时对应的频繁子序列中包含APP5的序列模式有哪些，再根据应用程序使用情况判断包含APP5的序列模式中哪个序列模式符合条件，将符合条件的序列模式确定为目标序列模式，然后根据目标序列模式的支持度设置回溯2小时当前应用程序的序列性特征。依此类推，直至完成所有回溯时间段的当前应程序的序列性特征的构建。

符合条件的序列模式（即目标序列模式）是指该序列模式在应用程序使用情况中出现。例如，应用程序使用情况为APP6、APP1、APP2、APP3、APP4，则序列模式{APP2，APP3，APP4，目标APP}符合条件，序列模式{APP7，APP3，APP4，目标APP}不符合条件。

应用程序使用情况是指由启动当前应用程序或当前时间为节点，回溯与回溯阈值的时间窗相等的时间段内手机的应用程序使用情况。即当为了确定出1小时内当前应用程序的序列性特征，则应用程序使用情况是最近1小时内手机的应用程序使用情况；当为了确定2小时内当前应用程序的序列性特征，则应用程序使用情况是最近2小时内手机的应用程序使用情况；当为了确定4小时内手机的应用程序的使用情况，则应用程序使用情况是最近4小时内手机的应用程序使用情况，依此类推。

在具体应用中，上述根据符合条件的序列模式的支持度确定出当前应用程序的序列性特征可以是：当只存在一个符合条件的序列模式时，则将该序列模式的支持度确定为当前应用程序的序列性特征；当存在多个符合条件的序列模式时，根据多个序列模式的支持度计算出预设的统计特征，将预设的统计特征确定为当前应用程序的序列性特征；当不存在符合条件的序列模式时，则将当前应用程序的序列性特征设置为0。

上述预设的统计特征可以包括但不限于最大值、最小值、平均值、总和、标准差等。当然，上述预设的统计特征还可以是方差、中位数等其他统计特征，本申请仅是以预设的统计特征为最大值、最小值、平均值、总和、标准差为例进行说明。

具体的，假设回溯1小时对应的频繁子序列中包含了APP5的序列模式有{APP1，APP2，APP4，目标APP}、{APP3，APP4，目标APP}、{APP5，APP2，目标APP}、{APP6，APP4，目标APP}、{APP7，APP4，目标APP}这五个序列模式，假设当前应用程序为APP4。那么回溯1小时包含当前应用程序APP4的序列模式有{APP1，APP2，APP4，目标APP}、{APP3，APP4，目标APP}、{APP6，APP4，目标APP}、{APP7，APP4，目标APP}这四个序列模式。

假设应用程序使用情况为：APP6、APP1、APP2、APP3、APP4，那么符合条件的序列模式就有{APP1，APP2，APP4，目标APP}、{APP3，APP4，目标APP}、{APP6，APP4，目标APP}这三个序列模式。因此APP4的1小时时间窗对应的序列模式特征为{APP1，APP2，APP4，目标APP}对应的支持度（简称为支持度1）、{APP3，APP4，目标APP}对应的支持度（简称为支持度2）以及{APP6，APP4，目标APP}对应的支持度（简称为支持度3）的统计特征值，假设支持度1为2.5、支持度2为3、支持度3为2.6，那么APP4的1小时时间窗对应的序列模式特征为（3、2.5、2.7、8.1，0.21602）。

S805：在检测到应用程序预测事件被触发的情况下，根据序列性特征对目标时间段内是否会启动目标应用程序进行预测。

上述应用程序预测事件的触发条件可以根据实际需求进行设定，本申请不作具体限制。

例如，当检测到用户的解锁操作后，触发应用程序预测事件，或者，当检测到某个应用程序被打开时，触发应用程序预测事件，又或者，当检测到电子设备从某个应用程序的使用界面返回到系统桌面时，触发应用程序预测事件，又或者，当检测到某个应用程序的使用界面切换到另一个应用程序的使用界面时，触发应用程序预测事件，又或者到达预设时间间隔触发应用程序预测事件，此处不再一一详述。

需要说明的是，上述预设时间间隔可以根据实际需求进行设定，本申请不作具体限制。例如，可以设置为30分钟，即电子设备每间隔30分钟触发一次应用程序预测事件，或者设置为。

需要说明的是，上述目标时间段可以根据实际需求进行设定，本申请不作具体限制。例如，目标时间段可以设置为1小时，即根据序列性特征预测未来1小时内是否将启动目标应用程序。

在本申请一实施例中，上述根据序列性特征对目标时间段内是否会启动目标应用程序进行预测可以是利用应用程序预测模型对目标时间内是否会启动目标应用程序进行预测。即在检测到应用程序预测事件被触发的情况下，将序列性特征输入到该应用程序预测模型中，由应用程序预测模型根据该序列性特征进行预测，以输出预测结果，预测结果包括目标时间段内将启动目标应用程序或目标时间段内不会启动目标应用程序。

在本申请一实施例中，为了进一步提高预测的准确性，在进行预测时，还可以根据序列性特征和时间性特征对目标时间段内是否会启动目标应用程序进行预测。

即可以将序列性特征和时间性特征输入到应用程序预测模型的模型中进行预测，并由应用程序预测模型输出预测结果。

需要说明的是，上述时间性特征可以使用已有的关于时间的统计特征。例如，过去一周当前小时目标应用程序的平均使用次数、最近一周工作日当前小时目标应用程序的平均使用次数、最近一周周末当前小时目标应用程序的平均使用次数、最近一周工作日当前时间接下来30分钟内目标应用程序的平均使用次数、最近一周周末当前时间接下来30分钟内目标应用的平均使用次数等，本申请对此不作具体限制。

示例性的，请参阅图11，其中，第一列为用户的应用程序使用情况，以APP5为当前应用程序为例，应用程序预测模型的输入为A-M个时间性特征以及4个序列性特征（分别为1小时时间窗对应的序列性特征1、2小时时间窗对应的序列性特征2、4小时时间窗对应的序列性特征3以及6小时时间窗对应的序列性特征4），输出为预测结果，其中预测结果为0表示目标时间段内不会启动目标应用程序，预测结果为1表示目标时间段内将会启动目标应用程序。

当然应用程序预测模型还可以输出一个值，若输出的值大于判定阈值，则确定预测结果为目标时间段内将会启动目标应用程序，若输出的值不大于判定阈值，则确定预测结果为目标时间段内不会启动目标应用程序。

上述判定阈值可以根据实际需求进行设置，本申请对此不作具体限定。

在具体应用中，上述应用程序预测模型可以利用决策树模型来构建，然后利用样本数据对构建出的初始的应用程序预测模型进行训练，以得到应用程序预测模型。

具体地，上述决策树模型可以是GBDT模型、XGboost模型、LightGBM模型等。本申请实施例LightGBM模型以例进行说明：

首先，基于LightGBM模型构建初始的分类模型，然后利用样本数据中的训练集样本数据对该初始的分类模型进行训练，利用样本数据中的测试集对训练后的分类模型的准确性进行验证，准确性满足要求后，就可以确定模型训练完成，将训练完成的分类模型确定为上述应用程序预测模型。

在一些实施例中，上述样本数据划分为训练集和验证集的划分标准可以根据训练需求进行设置。例如将样本数据中的90%划分为训练集，10%划分为验证集等。

需要说明的是，上述样本数据可以根据上述S801至S804对历史样本使用记录进行处理，得到各个样本的序列性特征和时间性特征。

将训练集中各个样本的序列性特征和时间性特征输入到初始的分类模型中预测，就可以得到各个样本对应的预测结果。

利用损失函数计算每个样本对应的预测结果与该样本中真实结果之间的损失值。如果该损失值大于预设损失阈值，则调整分类模型的模型参数，继续利用调整后的模型对训练集中的样本进行预测，并计算本次预测结果对应的损失值，如果损失值仍大于预设损失阈值，则继续重复上述过程，直到损失值小于或等于预设损失阈值，确定该分类模型在训练集的拟合效果良好。

利用验证集中各个样本的序列性特征和时间性特征输入到训练集训练过的分类模型中预测，就可以得到验证集中各个样本对应的预测结果，验证该分类模型在验证集的预测结果是否满足预设收敛条件，如果满足预设收敛条件，则训练过程结束；如果不满足预设收敛条件，则继续调整模型参数，直到满足预设收敛指标，训练过程结束。

在具体应用中，不同目标应用程序对应的样本数据不同，因此需要分别针对不同的目标应用程序构造样本数据对上述分类模型进行训练，以得到不同目标应用程序对应的应用程序预测模型。

S806：在预测结果为目标时间段内将启动目标应用程序的情况下，预加载目标应用程序的启动资源。

在具体应用中，电子设备可以通过系统进程管理模块来执行预加载目标应用程序的启动资源的操作。

本申请实施例中对目标应用程序的预加载的具体过程以及所加载的资源不作具体限定。例如，预加载的具体过程可以是为目标应用程序分配相应的硬件资源，并基于该硬件资源加载启动该目标应用程序所需的相关数据。上述相关数据可以包括进程启动、服务启动、内存分配、文件内容读取、网络数据获取、UI界面渲染等。

下面结合一个示例进行说明，当检测到用户点击APP2的图标时，触发应用程序预测事件，基于应用程序预测模型预测得到在点击目标时间段内(如，10min、30min)，将可能打开目标应用程序（例如游戏应用）。

此时，电子设备可以通过系统进程管理模块预加载游戏应用对应的启动资源，当用户在未来30min内打开游戏应用时，因为游戏应用的启动资源已经预加载至内存，因此电子设备的显示界面直接显示游戏应用的UI界面，节省了用户等待加载游戏应用的启动资源的时间，提升了启动游戏应用的响应速度，提升用户体验。

以上可以看出，本申请实施例提供的应用程序预测方法，基于电子设备的应用程序使用记录，获取按照启动顺序排序的历史应用程序使用序列，并通过不同时间阈值的时间窗和目标应用程序对历史应用程序使用序列进行切分，得到多个应用程序子序列，以此构建序列数据库，使得构建的序列数据库能够将特定应用程序（即目标应用程序）作为分切点，并回溯不同时长的时间窗，确保用户长时间使用习惯和短时间使用习惯的序列模式都能无遗漏地被挖掘。再从序列数据库中挖掘出序列模式，基于序列模式构造序列性特征，在检测到应用程序预测事件被触发的情况下，利用应用程序预测模型根据上述序列性特征和原时间性特征对目标时间段内是否将启动目标应用程序进行预测，将挖掘出的序列模式的特点通过序列性特征的方式输入到应用程序预测模型中，使得应用程序预测模型能够更准确地对目标时间段内是否将启动目标应用程序进行预测，有效地提高预测结果的准确度。

进一步的，提高预测结果的准确度后，目标应用程序在目标时间段内被启动的概率越高，因此在预测到目标时间段内将启动目标应用程序的情况下，预先加载该目标应用程序的启动资源到系统内存中，能够有效地提高用户启动目标应用程序时的响应速度，缩短用户等待目标应用程序启动的时间，提升用户体验。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

本申请实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

本申请实施例还提供了一种包含指令的芯片系统。当该指令在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线）或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质(例如，DVD)、或者半导体介质（例如，固态硬盘（solid state disk，SSD））等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种应用程序预测方法，其特征在于，包括：

获取历史应用程序使用序列；

根据目标应用程序切分所述历史应用程序使用序列，得到多个应用程序子序列，并对多个所述应用程序子序列回溯第一时间窗，得到第一子序列集合，对多个所述应用程序子序列回溯第二时间窗，得到第二子序列集合，对多个所述应用程序子序列回溯第三时间窗，得到第三子序列集合，对多个所述应用程序子序列回溯第四时间窗，得到第四子序列集合；其中，所述第一时间窗、所述第二时间窗、所述第三时间窗以及所述第四时间窗的回溯时间不同；

根据各个统计时间段的权重系数和每个序列在所述统计时间段内的出现次数，计算每个序列的支持度，并根据每个所述序列的支持度确定出序列模式；其中，接近当前时间的统计时间段的权重系数大于远离当前时间的统计时间段的权重系数；所述序列模式包括从所述第一子序列集合中计算得到的第一序列模式、从所述第二子序列集合中计算得到的第二序列模式、从所述第三子序列集合中计算得到的第三序列模式以及从所述第四子序列集合中计算得到的第四序列模式；

分别构建所述第一序列模式的第一序列性特征，所述第二序列模式的第二序列性特征，所述第三序列模式的第三序列性特征以及所述第四序列模式的第四序列性特征；其中，所述第一序列性特征包括所述第一序列模式中的各个目标序列模式的统计特征；所述第二序列性特征包括所述第二序列模式中的各个目标序列模式的统计特征；所述第三序列性特征包括所述第三序列模式中的各个目标序列模式的统计特征；所述第四序列性特征包括所述第四序列模式中的各个目标序列模式的统计特征；

在检测到应用程序预测事件被触发的情况下，将所述第一序列性特征、所述第二序列性特征、所述第三序列性特征、所述第四序列性特征以及时间性特征输入到预测模型中进行处理，输出目标时间段内是否会启动目标应用程序的预测结果；其中，所述时间性特征为关于时间的统计特征。

2.如权利要求1所述的应用程序预测方法，其特征在于，所述根据目标应用程序切分所述历史应用程序使用序列，得到多个应用程序子序列，并对多个所述应用程序子序列回溯第一时间窗，得到第一子序列集合，对多个所述应用程序子序列回溯第二时间窗，得到第二子序列集合，对多个所述应用程序子序列回溯第三时间窗，得到第三子序列集合，对多个所述应用程序子序列回溯第四时间窗，得到第四子序列集合，包括：

为所述历史应用程序使用序列添加时间特征；

将所述目标应用程序作为锚点，将所述历史应用程序切分为若干个应用程序子序列；

根据所述应用程序子序列中的每个应用程序的时间特征和不同回溯阈值的时间窗进行回溯，得到所述第一子序列集合、所述第二子序列集合、所述第三子序列集合以及所述第四子序列集合。

3.如权利要求1所述的应用程序预测方法，其特征在于，所述根据各个统计时间段的权重系数和每个序列在所述统计时间段内的出现次数，计算每个序列的支持度，并根据每个所述序列的支持度确定出序列模式，包括：

获取每个序列在不同统计时间段内的出现次数；

根据每个序列在各个统计时间段内的出现次数和各个统计时间段的权重系数计算每个序列的支持度；

根据序列数据库中每个序列的支持度和每个序列对应的回溯时间，确定出所述第一序列模式、所述第二序列模式、所述第三序列模式以及所述第四序列模式。

4.如权利要求1所述的应用程序预测方法，其特征在于，所述分别构建所述第一序列模式的第一序列性特征，所述第二序列模式的第二序列性特征，所述第三序列模式的第三序列性特征以及所述第四序列模式的第四序列性特征，包括：

分别确定出所述第一序列模式、所述第二序列模式、所述第三序列模式、所述第四序列模式中包含当前应用程序的序列模式；

将符合条件的包含所述当前应用程序的序列模式确定为目标序列模式；

根据所述目标序列模式的支持度确定所述当前应用程序的序列性特征。

5.如权利要求4所述的应用程序预测方法，其特征在于，所述根据所述目标序列模式的支持度确定所述当前应用程序的序列性特征，包括：

当只存在一个目标序列模式时，则将所述目标序列模式的支持度确定为所述当前应用程序的序列性特征；

当存在多个目标序列模式时，根据所述多个目标序列模式的支持度计算出预设的统计特征，将预设的统计特征确定为所述当前应用程序的序列性特征；

当不存在目标序列模式时，则将当前应用程序的序列性特征设置为0。

6.如权利要求1所述的应用程序预测方法，其特征在于，在检测到应用程序预测事件被触发的情况下，将所述第一序列性特征、所述第二序列性特征、所述第三序列性特征、所述第四序列性特征以及时间性特征输入到预测模型中进行处理，输出目标时间段内是否会启动目标应用程序的预测结果；其中，所述时间性特征为关于时间的统计特征之后，还包括：

在预测结果为目标时间段内将启动目标应用程序的情况下，预加载目标应用程序的启动资源。

7.如权利要求1-6任一项所述的应用程序预测方法，其特征在于，所述历史应用程序使用序列为经过应用清洗后的历史应用程序使用序列。

8.如权利要求7所述的应用程序预测方法，其特征在于，所述获取历史应用程序使用序列，包括：

获取历史时间段内的历史应用程序使用数据；

对所述历史应用程序使用数据进行应用清洗，得到清洗后的历史应用程序使用数据；

根据清洗后的历史应用程序使用数据中各个应用程序的时间信息进行排序，得到所述历史应用程序使用序列。

9.一种电子设备，其特征在于，包括处理器和存储器，所述处理器和存储器耦合，所述存储器用于存储计算机程序，当所述处理器执行所述计算机程序时，使得电子设备执行权利要求1至8中任意一项所述的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机程序，当所述计算机程序在计算机上运行时，使得计算机执行如权利要求1至8任意一项所述的方法的步骤。

11.一种芯片，其特征在于，包括处理器，所述处理器和存储器耦合，所述存储器用于存储计算机程序指令，当所述处理器执行所述计算机程序指令时，使得芯片执行如权利要求1至8中任意一项所述的方法的步骤。