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

Abstract

本申请提供了一种应用程序预测方法、电子设备及存储介质，基于该电子设备的APP使用记录，获得历史APP序列，并按照该间隔时间阈值将历史APP序列划分为多个APP子序列。针对APP子序列中的每个APP，从该APP子序列中选取在该APP之后的预设时长内启动的目标APP，基于目标APP构造该APP的样本，并为每个样本构造相应的标签。进一步，利用样本集及对应的标签训练排序算法模型得到APP预测模型。当检测到APP预测触发事件后，利用APP预测模型预测得到预测APP序列。同一APP对应的正样本中的候选APP之间的关联性较强，即提高了样本的准确率，从而提高了APP预测模型的准确率，进而提高了预测结果的准确率。而且，排序算法模型预测得到的预测APP序列中的各个APP之间具有顺序性。

Description

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

技术领域

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

背景技术

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

为了缩短用户等待应用程序启动的时长，预测用户即将打开的应用程序并预加载该应用程序启动所需的资源(即，启动资源)，但是，相关技术的应用程序预测方案的预测准确率低。

发明内容

有鉴于此，本申请提供了应用程序预测方法、电子设备及存储介质，以解决上述的应用程序预测准确率低的问题，其公开的技术方案如下：

第一方面，本申请提供了一种应用程序预测方法，应用于电子设备，所述方法包括：获取历史应用程序APP序列，所述历史APP序列包括所述电子设备在历史时间段内的APP使用记录信息；将所述历史APP序列，在相邻的两个APP的间隔时长大于预先获得的间隔时间阈值处进行切分，得到多个APP子序列，所述间隔时间阈值表征时序上相邻的两个APP之间间隔的时长；对于任一APP子序列中的任一APP，选取所述任一APP子序列中在所述任一APP之后预设时长内打开的APP，获得与所述任一APP相匹配的目标APP；基于所述目标APP构造所述任一APP对应的样本，并为每个所述样本构造相匹配的标签；基于各个样本及对应的标签，训练排序算法模型得到APP预测模型；在检测到APP预测事件后，基于所述APP预测模型预测与所述APP预测事件相匹配的预测APP序列，所述预测APP序列包括在所述APP预测事件发生后的预设时长内打开的预设数量个APP。可见，利用该方案选取与该任一APP的关联性较强的APP构造该任一APP对应的正样本，从而提高了正样本的准确性，进而提高了训练得到的APP预测模型的准确性，最终提高了APP预测结果的准确性。而且，该方案利用排序算法模型，可以学习到同一APP对应的各个目标APP之间的顺序关系，因此，预测得到的APP序列中的各个APP之间也具有顺序性。

在第一方面的一种可能的实现方式中，获得所述间隔时间阈值的过程包括：将所述历史时间段包含的每个周期划分为多个时间段，针对每个时间段，获得所述时间段内时序上相邻的两个APP的开启时间之间的间隔时长；确定所述时间段内对应的至少两个所述间隔时长的中位数，为所述时间段对应的所述间隔时间阈值。可见，该方案针对历史时间段内的每个周期划分为多个时间段，针对每个时间段计算该时间段对应的间隔时间阈值，不同时间段对应的间隔时间阈值可能不同，从而使间隔时间阈值更符合用户实际使用情况，即提高了间隔时间阈值的准确性，进而使划分得到的同一APP子序内的APP具有较强的关联性，进而提高了同一APP对应的正样本中的候选APP的关联性，即提高了正样本的准确性。

在第一方面的另一种可能的实现方式中，所述方法还包括：在每个所述APP子序列末尾添加一个空APP，得到新APP子序列，所述空APP表征没有APP；

所述对于任一APP子序列中的任一APP，选取所述任一APP子序列中在打开所述任一APP之后预设时长内打开的APP，获得与所述任一APP相匹配的目标APP，包括：对于任一所述新APP子序列中除所述空APP之外的任一APP，从所述任一新APP子序列中，选取排序位于所述任一APP之后，且开启时间与所述任一APP的开启时间之间的时间差小于所述预设时长的所有APP，得到与所述任一APP相匹配的目标APP，其中，所述预设时长为所述间隔时间阈值的N倍，其中，N为大于1的正整数。该方案在每个APP子序列的末尾增加孔APP后，能够使排序算法模型学习到长时间内没有使用APP的实际情况，从而预测出某一APP之后很长时间没有使用APP的情况，进一步提高了APP预测模型的准确性。

在第一方面的又一种可能的实现方式中，所述基于所述目标APP构造所述任一APP对应的样本，包括：选取所述电子设备中使用频率高于频率阈值的多个候选APP；基于所述任一APP对应的所述目标APP，构造所述任一APP对应的正样本；基于所述候选APP中除所述任一APP对应的所述目标APP之外的APP，构造所述任一APP对应的负样本。

在第一方面的再一种可能的实现方式中，所述样本包括正样本和负样本，所述为每个所述样本构造相匹配的标签，包括：将每个负样本对应的标签值设置为第一数值；按照预设标签规则设置各个正样本对应的标签，正样本对应的标签值与所述负样本的标签值不同。

在第一方面的另一种可能的实现方式中，所述按照预设标签规则设置各个正样本对应的标签，包括：将每个正样本的标签设置为第二数值；或者，将包含下一个被打开的APP的正样本对应的标签设置为第三数值，以及，将剩余正样本对应的标签设置为第四数值；或者，将包含下一个被打开的APP的正样本对应的标签设置为第五数值，以及，按照正样本中的目标APP在所述任一APP被打开后的预设时长内的被打开次数，对其他正样本进行排序，并将前预设数量个所述其他正样本的标签设置为第六数值，以及将剩余的其他正样本的标签设置为第七数值；或者，按照各个正样本中的目标APP在所述任一APP被打开后的预设时长内的被打开次数，对所述各个正样本进行排序，并将前预设数量个正样本的标签设置为第八数值，以及，将剩余正样本的标签设置为第九数值。可见，利用该方案提供了多种标签设置方案，可以根据业务需求选择相匹配的标签设置方案，从而使排序算法模型通过样本的标签学习样本之间的顺序，并预测出与标签标记的顺序相匹配的预测APP序列，即提高了APP预测模型的灵活性。

在第一方面的又一种可能的实现方式中，所述第一数值为0。

在第一方面的另一种可能的实现方式中，所述第二数值为1；或者，所述第三数值为2，所述第四数值为1；或者，所述第五数值为3，所述第六数值为2，所述第七数值为1；或者，所述第八数值为2，所述第九数值为1。

在第一方面的再一种可能的实现方式中，每个所述样本包括一个查询APP以及候选APP；所述基于各个样本及对应的标签，训练排序算法模型得到APP预测模型，包括：从各个样本的所述查询APP及所述候选APP中提取查询特征；将所述查询特征输入预设排序算法模型进行预测，得到各个所述查询APP对应的APP序列预测结果；根据各个所述查询APP对应样本的标签及所述APP序列预测结果，获得所述样本对应的损失值，并基于所述损失值调整所述预设排序算法模型的模型参数，直到所述损失值满足预设收敛条件模型训练过程结束，得到所述APP预测模型。

在第一方面的另一种可能的实现方式中，所述在检测到APP预测事件后，基于所述APP预测模型预测与所述APP预测事件相匹配的预测APP序列，包括：解析接收的APP预测事件，确定出与所述APP预测事件相匹配的查询APP；获取所述查询APP的信息，并从所述查询APP的信息中提取查询特征，其中，所述查询APP的信息包括在所述查询APP及对应的历史APP，所述历史APP包括在所述查询APP被打开之前的预设时间段内被打开的APP；将所述查询特征输入所述APP预测模型进行预测，得到所述查询APP对应的所述预测APP序列。

在第一方面的又一种可能的实现方式中，所述方法还包括：从所述预测APP序列中选取至少一个APP，预加载所述至少一个APP对应的启动资源。利用该方案可以智能预加载用户在未来一段时间内可能打开的APP的启动资源，将用户等待APP启动的时间降至零，提高了用户体验。

在第一方面的再一种可能的实现方式中，所述从所述预测APP序列中选取至少一个APP，包括：从所述预测APP序列中，选取在所述APP预测事件被触发之后下一个被打开的APP；或者，从所述预测APP序列中，选取前预设数量个APP。

在第一方面的另一种可能的实现方式中，所述方法还包括：调用悬浮球显示完成预加载的APP的信息，其中，所述悬浮球悬浮于所述电子设备的当前显示界面之上。该方案可以在悬浮球中显示已完成预加载的APP的信息，悬浮球悬浮于当前UI界面之前，用户无需从当前使用APP的UI界面退回到系统桌面，再点击下一个APP图标来启动下一个APP，可以直接操作悬浮球显示的下一个APP的图标来启动下一个APP，简化了用户打开下一个APP的操作，进一步提高了用户体验。

第二方面，本申请还提供了一种电子设备，包括存储器和处理器，所述存储器用于存储所述处理器可执行的指令，所述处理器执行所述指令使得所述电子设备执行如第一方面任一种可能的实现方式所述的应用程序预测方法。

第三方面，本申请还提供了一种计算机可读存储介质，其上存储有计算机程序所述计算机程序被电子设备的处理器运行时，使得所述电子设备执行如第一方面任一种可能的实现方式所述的应用程序预测方法。

第四方面，本申请还提供了一种计算程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行如第一方面任一种可能的实现方式所述的应用程序预测方法。

应当理解的是，本申请中对技术特征、技术方案、有益效果或类似语言的描述并不是暗示在任意的单个实施例中可以实现所有的特点和优点。相反，可以理解的是对于特征或有益效果的描述意味着在至少一个实施例中包括特定的技术特征、技术方案或有益效果。因此，本说明书中对于技术特征、技术方案或有益效果的描述并不一定是指相同的实施例。进而，还可以任何适当的方式组合本实施例中所描述的技术特征、技术方案和有益效果。本领域技术人员将会理解，无需特定实施例的一个或多个特定的技术特征、技术方案或有益效果即可实现实施例。在其他实施例中，还可在没有体现所有实施例的特定实施例中识别出额外的技术特征和有益效果。

附图说明

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

图1是本申请实施例提供的一种电子设备的结构示意图；

图2是本申请实施例提供的一种电子设备的软件架构示意图；

图3是本申请实施例提供的一种在打开应用时触发预测的场景下UI界面跳转示意图；

图4是图3对应的没有预测和预加载的场景下的UI界面跳转示意图；

图5是本申请实施例提供的一种在返回系统桌面时触发预测的场景下UI界面跳转示意图；

图6是图5对应的没有预测和预加载的场景下的UI界面跳转示意图；

图7是本申请实施例提供的一种在解锁屏幕时触发预测的场景下UI界面跳转示意图；

图8是图7对应的没有预测和预加载的场景下的UI界面跳转示意图；

图9是本申请实施例提供的一种应用程序预测方法的流程图；

图10是本申请实施例提供的一种应用程序预测方法的时序图；

图11是本申请实施例提供的构造样本过程的示意图；

图12是本申请实施例提供的设置悬浮窗的UI界面示意图；

图13是本申请实施例提供的一种触发时机下悬浮球展示预测APP的图标的UI示意图；

图14是本申请实施例提供的另一种触发时机下悬浮球展示预测APP的图标的UI示意图；

图15是本申请实施例提供的在悬浮球内展示预测的服务的图标的UI示意图。

具体实施方式

本申请说明书和权利要求书及附图说明中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于限定特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

为了加快应用程序的启动速度，对应用程序进行预加载是一种常用且有效的方法，即，预测出用户可能启动的应用程序，并提前将启动该应用程序所需的资源(即，启动资源)加载至电子设备的系统内存中，即预加载应用程序的启动资源，这样，当用户启动该应用程序时，能够快速启动该应用程序，实现用户“零等待”，即用户无需经历等待应用程序加载的过程。但是，发明人发现相关技术的应用程序预测方法，采用多分类模型预测得到下一个可能启动的APP的概率，进一步根据概率值由大到小的顺序给出前N个的APP序列，但是给出的TopN个APP之间没有顺序关系，都是基于当前预测事件预测得到的下一个可能启动的APP。即，此种预测方案无法预测得到未来一段时间内可能打开的TopN个APP。

为了实现预测未来一段时间内可能打开的TopN个APP序列，本申请提供了一种应用程序预测方法，该方法基于该电子设备的APP使用记录，获得按照启动顺序排序的历史APP序列，并按照该间隔时间阈值将历史APP序列划分为多个APP子序列，APP子序列内部相邻的两个APP之间具有关联性，而不同的APP子序列之间相邻的两个APP之间没有关联。针对APP子序列中的每个APP，从该APP子序列中选取在该APP之后的预设时长内启动的APP作为该APP的目标APP，并基于目标APP构造该APP(即查询APP)的样本，其中，每个样本包括查询APP和一个候选APP，并为每个样本构造相应的标签。进一步，利用样本集及对应的标签训练排序算法模型得到APP预测模型。当检测到APP预测触发事件被触发后，利用APP预测模型预测得到预测APP序列，预测APP序列包括该预测触发事件之后的预设时间段内可能启动的TopN个具有顺序关系的APP。

由上述内容可知，该方案在构造当前APP的样本时，先将历史APP序列从相邻但没有关联性的两个APP间切分开，并基于同一子序列构造APP样本，因此，构造的同一APP对应的正样本中候选APP之间的关联性强，进而使排序算法模型学习到样本中的强关联性，最终利用排序算法模型得到的预测APP序列中的APP也具有强关联性，即提高了APP预测模型的准确度。而且，该方案采用排序算法模型，能够学习到同一个APP对应的正样本中各个候选APP之间的顺序关系，因此，得到的预测APP序列中的各个APP之间具有顺序性。

进一步，提高预测结果的准确度之后，预加载的应用程序被用户打开的概率提高，从而提高了内存的使用率，同时降低了用户打开APP时的功耗。

进一步，根据不同的需求设计不同的标签设置规则，实际使用时，可以根据实际需求选用相匹配的标签设置规则，因此提高了应用程序预测方法的灵活性。

进一步，在预测得到可能启动的TopN个APP之后，对其中的前M个APP进行预加载，即，将这M个APP启动所需的资源提前加载至内存，当用户启动M个APP中任一个APP时，都能直接启动进入该APP的UI界面，实现用户零等待，因为在用户启动该APP之前已经提前完成该APP的加载过程。其中，M为正整数且1≤M≤N。

请参见图1，示出了本申请实施例提供的一种电子设备的结构示意图，该电子设备用于运行本申请提供的应用程序预测方法、应用程序预加载方法。

在一些实施例中，该电子设备可以是手机、平板电脑、、桌面型、膝上型、笔记本电脑、超级移动个人计算机(Ultra-mobile Personal Computer，UMPC)、手持计算机、上网本、个人数字助理(Personal Digital Assistant，PDA)、可穿戴电子设备、智能手表等设备。本申请对电子设备的具体形式不做特殊限定。

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

处理器是电子设备的神经中枢和指挥中心，控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

显示屏用于显示图像，视频、一系列图形用户界面(graphical user interface，GUI)等。

存储器可以用于存储计算机可执行程序代码，该可执行程序代码可以包括操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。该可执行程序代码包括指令，处理器通过运行存储在存储器的指令，从而使电子设备执行各种功能应用以及数据处理。例如，在本申请中，处理器通过运行存储器中存储的指令，使得电子设备执行本申请提供的应用程序预测方法、应用程序预加载方法。

电子设备的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备的软件结构。其中，本申请提供的应用程序预测方法还可以应用于基于其他类型的操作系统的电子设备中，此处不再一一赘述。

图2是本申请实施例的电子设备的软件结构框图。

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

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

应用程序层可以包括一系列应用程序包。

应用程序框架层(Framework)为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架，也可以称为Service层。应用程序框架层包括一些预先定义的函数。

在本申请中，如图2所示，应用程序框架层可以包括数据采集模块、数据保存模块、样本构造模块、模型训练模块、预测模块和系统进程管理模块。

数据采集模块和数据保存模块作为感知模块。数据采集模块用于感知应用程序的运行状态，如应用打开/退出、前后台切换、安装/卸载等事件。

数据保存模块，用于保存用户开启、关闭APP的时间，即APP启动时刻、APP关闭时刻。

样本构造模块、模型训练模块和预测模块组成计算引擎。

样本构造模块，用于基于历史APP序列构造每个APP对应的样本，并为每个样本按照预设标签方案构造标签。

模型训练模块，用于基于构造的全部样本对排序算法模型进行训练，得到APP预测模型。

预测模块，用于检测到APP预测事件被触发后，利用APP预测模型预测与该APP预测事件相匹配的TopN个APP的序列，并向系统进程管理模块传输该预测结果。

其中，APP预测事件的触发时机可以包括如下几种：

(1)当某个APP被打开时，触发APP预测事件；

(2)当从某个APP的界面返回系统桌面时，触发APP预测事件；

(3)当检测到屏幕解锁操作时，触发APP预测事件。

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

在一种场景下，当用户打开该应用程序时，电子设备可以直接展示该应用程序的UI界面。

在另一种场景下，电子设备可以在悬浮球内展示预加载的应用程序的图标。进一步，用户点击悬浮球内展示的图标，可以直接展示该应用程序的UI界面。

系统进程管理模块，用于将TopN个APP中的至少一个APP的启动资源加载至系统内存，这样，当用户打开该APP时，因为在打开该APP之前已经提前完成该APP的资源加载过程，所以用户打开该APP时，能够直接展示该APP的UI界面，实现用户零等待。

实施例一

本实施例将详细介绍，在电子设备无法直观展示智能预加载的应用程序的场景下，应用程序的预测过程以及预加载过程。

首先，结合图3～图8说明在APP预测事件对应的不同触发时机下，UI界面的变化过程。

(1)APP被打开时触发APP预测事件

例如，如图3所示，用户点击微信APP的图标后，展示微信APP的UI界面，与此同时，点击微信APP图标的操作触发APP预测事件。如预测出用户接下来可能会打开视频APP，电子设备的后台智能加载视频APP对应的启动资源，这样，当用户打开视频APP时，即如图3中的(3)图所示的点击视频APP的图标的操作，显示屏直接展示视频APP的UI界面，如图3中的(4)图所示，从而实现智能预加载应用程序，在用户打开该应用程序之前就完成该应用程序的启动资源预加载过程，将用户等待该应用程序启动的时间降至零，提高了用户体验。

此外，在用户点击微信APP的图标之前，电子设备的后台无运行的应用程序，可见，视频APP是在打开微信APP之后后台智能预加载的应用程序。

如图4所示，在没有APP预测及APP预加载的方案中，用户点击视频APP的图标，显示屏显示等待视频APP启动的界面，视频APP的启动资源加载完成后，显示视频APP的UI界面。

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

此外，在一些实施例中，系统后台可以直接预加载用户上一次退出视频APP时对应的页面资源，此种情况下，如图3中的(4)图所示，可以直接展示用户上一次观看的视频对应的播放界面。

在其他实施例中，系统后台预加载某一APP对应的首页的页面资源。预加载APP的页面资源可以根据用户的需求设置，本申请对此不做限定。

(2)返回系统桌面时，触发APP预测事件

如图5中的(1)图所示，当用户关闭正在使用的应用程序返回系统桌面时，触发APP预测事件，预测出用户接下来会打开视频APP，并在系统后台加载视频APP对应的启动资源。如图5中的(2)图所示，当用户点击视频APP图标时，显示屏直接显示该视频APP的UI界面。

与图6所示的不具备APP预测和预加载的情况相比，图5所示的过程，在用户打开视频APP之前，已经预加载了视频APP的启动资源，因此，用户打开视频APP时，能够直接展示该视频APP的UI界面，用户无需等待视频APP加载启动资源。

(3)检测到屏幕解锁操作时，触发APP预测事件

当用户解锁屏幕时(如图7中的(1)图所示的解锁操作)，预测出用户接下来会打开视频APP，并在系统后台智能预加载视频APP的启动资源。如图7中的(2)图所示，当用户点击视频APP的图标时，直接展示视频APP的UI界面，如图7中的(3)图所示。

与图8所示的不具备APP预测和预加载的情况相比，图7所示过程，节省了用户等待视频APP加载启动资源的时间，将用户等待APP启动的时间降至零，提高了用户体验。

由上述内容可知，准确预测出用户在未来一段时间内可能会打开的APP或服务，并提前将开启该APP或服务所需的资源加载至系统内存中，可以使用户开启应用程序时实现零等待。下面先结合图9简单介绍用于预测用户在未来一段时间内可能会打开的APP或服务的应用程序预测方法，如图9所示，该方法可以包括以下步骤：

S100，获取历史时间段内的APP序列，即历史APP序列。

该历史APP序列中包括用户在历史时间段内使用的、且按开启时间的先后顺序排序所有APP。而且，该历史APP序列中的每个APP包括相应的时间信息，如，APP的开启时间和APP的关闭时间。

其中，APP序列中的APP可以包括电子设备中安装的APP，或者，还可以是APP内的某个服务，例如，通行APP中的乘车码服务等，本申请对此不做限定。

S200，根据历史APP序列中各个APP的时间信息，计算得到间隔时间阈值，记为Timedelta。

该间隔时间阈值表征在时间轴上相邻的两个APP的开启时间的平均间隔时长，因此，一个间隔时间阈值内通常只有一个APP。此处的间隔时间阈值可以取一个时间段内所有间隔时间的平均值。

例如，某一时间段内使用了3个APP，如APP1、APP2和APP3，其中，APP1与APP2之间间隔30min，APP2与APP3之间间隔10min，则这一时间段的平均间隔时间为20min。

S300，基于间隔时间阈值，将历史APP序列划分得到多个APP子序列。

例如，APP5和APP6之间间隔30min大于间隔时间阈值20min，则从APP5和APP6之间将APP序列切分开。

S400，在每个APP子序列之后添加null_app，即空APP。

在实际使用场景中，用户可能长时间未使用任何APP，但有APP预测事件触发(如解锁事件)，此种情况下，可以利用null_app表示接下来的预设时长内没有APP打开，这样，能够使机器学习算法(如排序算法)学习到长时间没有使用APP的实际情况，进而能够预测接下来没有APP使用的现实情况。

构造此种情况下的样本。这样在长时间没有使用APP的情况下，输出null_app的预测结果，表示接下来没有APP打开。

在一些实施例中，机器学习排序算法可以采用RankNet、LambdaRank和LambdaMART中的任一种。

S500，针对APP子序列中的任一个非null_app，从该APP子序列中选取该非null_app之后的预设时长内的所有APP，作为该非null_app的目标APP，并基于目标APP构造该非null_app的样本集。

预设时长可以根据实际需求设定，例如，预设时长可为N倍APP时间间隔，即N*Timedelta，其中，N为大于1的正整数。如，Timedelta＝20min，N＝3，则N*Timedelta＝60min，即选取该APP(如APP1)之后一小时内使用的APP作为APP1的目标APP。

每个样本包括一个query app和一个doc app，以及，query app和doc app对应的时间信息及上下文信息。

其中，query app是指当前APP(即，触发APP预测事件的APP或事件)，doc app是候选APP，即在当前APP启动后的预设时长内，可能打开的APP。其中，候选APP可以包括从电子设备安装的APP中选取的使用频率较高的APP、服务，以及，null_app。预测时，从候选APP的集合中预测出query app之后预设时长内可能打开的APP，即预测出的APP是候选APP的子集。

时间信息包括APP开启时间和APP关闭时间。上下文信息包括该APP启动之前的历史时间段内与该APP相关联的APP的信息。

S600，基于预设标签设置方案，为样本集中的每个样本构造标签。

在本申请实施例中，根据不同的业务需求设计有不同的标签设置方案，标签设置方案的具体内容后文将详细介绍。

S700，利用样本集及对应的标签，训练排序算法模型得到APP预测模型。

利用样本集及各样本对应的标签来训练预设的排序算法模型，训练模型的过程是让机器学习算法学习样本集中标签的标注结果与样本特征之间的关联。

S800，当检测到APP预测事件被触发后，利用APP预测模型预测得到预测APP序列。

预测APP序列是指在该APP预测事件之后的预设时长内可能打开的APP序列。其中，预测APP序列中的APP可以包括

下面将结合图10，详细介绍本申请提供的应用程序预测方法的过程，如图10所示，该方法可以包括以下步骤：

S110，数据采集模块感知APP的运行状态，并将APP的时间信息发送至数据保存模块。

当用户打开、退出(即关闭)、前/后台切换、安装、卸载APP时，产生相应的事件，如APP开启事件、APP退出事件、APP切后台事件等，数据采集模块通过感知此类事件感知APP的运行状态。

例如，当感知到某一APP被打开或退出的事件后，记录该APP的开启时间、关闭时间并传递至数据保存模块进行保存。数据保存模块按照时间顺序记录用户使用每个APP的时间信息。

例如，历史APP序列为{APP1、APP2、APP3、……、APPN}，其中，1～N表示APP序列中的APP在时间轴上的排序，即按用户的使用时间先后顺序记录的APP序列。

用户可能在一天内多次使用同一款APP，则该APP在序列中出现多次，即该序列中不同排序位置的APP可能表示同一款APP。例如，用户在一天内的3个不同时间点都打开了微信APP，则微信APP会在这一天的APP序列中出现3次。

S120，样本构造模块从数据保存模块中，获取历史时间段内的APP序列，即历史APP序列。

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

历史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(如退出或切换至后台)的时刻。

S130，样本构造模块根据历史APP序列中同一时间段内的各个APP的时间信息，计算得到该时间段的间隔时间阈值，记为Timedelta。

间隔时间阈值表征时序上相邻的两个APP的开启时间之间间隔的时长。

每个用户使用手机都有自己的行为习惯，而且，每个用户的历史APP序列在时间轴上会呈现周期性规律。如在每天固定时段内使用某几个APP，因此，可以按照用户的使用规律将一天24小时划分为多个时间段，并针对不同的时间段分别计算该时间段对应的间隔时间阈值，从而使获得的间隔时间阈值更符合用户的实际使用情况，即提高了间隔时间阈值的准确性。

其中，时间段的时长可以根据不同用户的实际使用情况设定，本申请对此不做限制。不同时间段的时长可以相同，也可以不同。而且，不同时间段对应的间隔时间阈值可以不同，例如，用户在工作日的非工作时间段(如中午或晚上)内使用APP的数量较多且APP间的间隔时间较短，而在23点～次日7点这段时间内使用的APP较少且APP间的间隔时间较长。

在一些实施例中，针对一个时间段，统计用户在该时间段内使用过的APP，以及各个APP的开启时刻，进一步计算每两个相邻APP的开启时刻之间的间隔时间，最后计算该时间段内的平均间隔时间作为间隔时间阈值。

例如，将一天划分为三个时间段，每个时间段分别为：0点～8点、8点～16点、16点～24点。而且，在0点～8点这一时间段使用了APP1、APP2和APP3三个APP，其中，APP1与APP2的开启时刻间隔10min，APP2与APP3的开启时刻间隔20min，则该时间段对应的平均间隔时间为15min。

在其他实施例中，一个时间段对应的间隔时间阈值，还可以选取该时间段内的多个间隔时间中的中位数，具体的，将某一时间段内每两个相邻APP之间的间隔时间按照由小到大的顺序排序，并选取中间位置的数据作为该时间段对应的间隔时间阈值。选取中位数能够避免间隔时间分布数列中的极大值或极小值的影响，提高了中位数对分布数列的代表性。

在其他实施例中，还可以针对一个周期(如，1天、1周等)计算一个间隔时间阈值，此处对获取间隔时间阈值的具体方式不做限定。

S140，样本构造模块从间隔时间大于间隔时间阈值处，对历史APP序列进行切分得到多个APP子序列。

在时间轴上相邻的两个APP之间是否存在关联取决于这两个APP的启动时刻之间的间隔时长，如果两个APP的间隔时长小于Timedelta，认为这两个APP之间具有强关联性；如果两个APP的间隔时长大于或等于该时间段对应的Timedelta，认为这两个APP之间基本不存在关联性。

例如，用户在使用某购物APP购买了商品后，立刻使用支付宝APP进行结算，此种场景中的购物APP和支付宝APP具有强关联性。又如，用户早上8:30使用了考勤APP，8:00～10:00没有APP使用数据，直到10:00用户使用了微信APP，虽然考勤APP和微信APP在时间轴上相邻，但是这两个APP之间间隔的时间很长，因此认为这两个APP之间没有关联性。

为了避免上述的没有关联的两个APP对机器学习算法准确度的影响，将APP序列从没有关联的两个APP之间切分开。同一APP子序列内，在时间轴上相邻的两个APP之间具有强关联性，而不同APP子序列之间相邻的两个APP之间没有关联性。然后，从当前APP所在APP子序列中选取该当前APP对应的目标APP，目标APP是指用户在当前APP之后的预设时长内使用过的APP。可见，同一APP对应的目标APP之间的关联性较强，以使排序算法模型从样本中学习到这种强关联性，从而提高了排序算法模型的准确率。

例如，Timedelta＝15min，APP1～APP10中相邻两个APP的开启间隔时间均小于15min，而APP10与APP11的开启时刻间隔长是20min，则从APP10和APP11之间切分开，如图11所示，APP1～APP10为子序列1。同理，继续对APP11～APPN进行切分，得到n个子序列，其中，n＜N。

在一些实施例中，依次判断历史APP序列中两个相邻的APP之间的间隔时长是否大于该时间段对应的间隔时间阈值，如果是，则从这两个相邻的APP之间切分成两个APP子序列，直到历史APP序列中的所有APP都判断完。

S150，样本构造模块在每个APP子序列的末尾添加null_app。

如图11所示，在子序列1～n的末尾均添加一个null_app。null_app即空APP，null_app表示没有APP，其中，null_app与其他非null_app的处理过程相同。

前已叙及，每个APP子序列的最后一个APP与下一APP子序列的第一APP之间的间隔时间比较长，表明APP子序列的最后一个APP之后的很长时间没有使用APP。

利用null_app表示没有使用APP，可以使机器学习算法能够学习到长时间内没有使用APP的实际情况，进而该模型能够输出包含null_app的预测结果，即预测出某一APP之后很长时间没有使用APP的情况。

此外，添加null_app后还能够增加样本数量，从而满足机器学习算法(排序算法模型)对训练数据的数量需求。

S160，样本构造模块针对每个添加null_app后的APP子序列中的任一个非null_app，选取开启时刻在该非null_app的开启时刻之后预设时长内的APP构造该非null_app的样本集。

在使用排序算法模型时，样本采用query-doc对形式，即每条样本包括一个queryapp和一个doc app，其中，query app是指查询APP，即APP预测触发事件对应的APP，doc app是候选APP。

前已叙及，null_app表示没有APP，因此，null_app仅作为样本中的候选APP，不能作为样本中的query app。因此，query app是APP子序列中非null_app，doc app包括非null_app和null_app。

同一query app对应的样本集包括正样本和负样本，正样本是打开该query app之后的预设时长内使用过的APP，负样本是打开该query app之后的预设时长内未使用的APP。

在一些实施例中，正样本中的候选APP是从该正样本的query app所在的APP子序列中选取的APP(即，目标APP)。

例如，设定预设时长＝N*Timedelta，因为一个Timedelta内通常只有一个APP，而实际预测时，预测query app之后可能打开的预设数量个APP，因此可以选取APP子序列的N*Timedelta时间跨度内的APP构造正样本。

其中，可以根据实际需求设定N的取值，例如，Timedelta＝10min，预测某一APP之后30min内可能打开的APP，则N的取值为3。又如，预测某一APP之后60min内可能打开的APP，则N的取值为6。其中，预设时长通常小于子序列中第一个APP与最后一个APP之间的间隔时间，如，对于图11所示的子序列1而言，预设时长小于APP1与APP10之间的间隔时间。

例如，图11所示的子序列1中，在APP1之后30min内使用过的APP，即APP1对应的目标APP是：APP2、APP3和APP4，同理，选取APP2之后30min内使用过的APP，即APP2对应的目标APP是：APP3、APP4、APP5、APP6，依次类推，依次选取子序列1中APP3～APP10这10个APP分别对应的目标APP。其中，APP10对应的目标APP是null_app，表示，APP10之后的很长时间都没有使用APP。此处的目标APP用于构造查询APP的正样本。

机器学习算法可以学习大量样本中的特征，如果APP的样本特别少可能无法学习到此类样本的特征，因此，选取电子设备中经常使用的APP作为候选APP。

例如，在一些实施例中，可以从当前电子设备中选取的满足预设条件的M个不同的APP作为候选APP。例如，预设条件可以是使用频率高于预设频率值。如选取电子设备中经常使用的20个APP作为候选APP。预测出的预测APP序列是选取的候选APP的子集。

每个query app对应的doc app序列都是M个候选APP，而且，M个候选APP的排序固定不变。这样，不同query app对应的样本集中的候选APP序列都相同，降低了样本集的复杂度。

其中，query app(如APP1)对应的目标APP是打开该query app之后的预设时长内使用过的APP，可见，目标APP是候选APP的子集。而且，为了方便设置样本集中各样本的标签，候选APP的排序固定不变，例如，每个样本集中M个候选APP的排序都是APP1～APPM。

在一些实施例中，样本集中的各个样本如表1所示：

表1

如表1所示，共有M个候选APP，则每个query app对应的样本集中包括M个样本，如样本集1中M个样本中的query app都是query app1，doc app分别是doc app1～doc appM。而且，doc app1～doc appM中包括与query app1代表的APP相同的APP，例如，query app1和doc app1都代表微信。

S170，样本构造模块按照预设标签规则设置每个样本对应的标签，并发送各个样本及对应的标签。

不同场景下关注的预测指标不同，例如，某些场景下希望未来预设时长内越先打开的APP排序越靠前，而有些场景则希望未来预设时长内打开次数越多的APP排序越靠前等等，为了满足不同场景的需求，可以根据实际场景需求设计不同的标签设置规则。

如表1所示，本申请提供了五种不同的标签设置规则，依次如下：

(1)第一种标签设置规则，即表1中的label1

在一种场景下，关注预测到在未来预设长内打开的所有APP，此种场景下，可以将所有正样本对应的标签都设置为第一数值，如“1”，负样本对应的标签都设置为第二数值，如“0”。

下面以一个示例说明此种标签设置规则，例如，候选APP的数量是6个(即M＝6)，而且，doc app1～doc app6依次为：京东、微信、知乎、百度、支付宝、高德地图。query app1为微信，query app1对应的目标APP在时间轴上的顺序依次为：知乎→京东→百度。

该示例对应的样本集如下所示：

样本1：微信，京东：1(正样本)；

样本2：微信，微信：0(负样本)；

样本3：微信，知乎：1(正样本)；

样本4：微信，百度：1(正样本)；

样本5：微信，支付宝：0(负样本)；

样本6：微信，高德地图：0(负样本)。

(2)第2种标签设置规则，即表1中的label2

在一种场景下，希望预测到未来预设时长内打开的所有APP，且希望明确给出下一个打开的APP，此种场景下，将下一个打开的APP对应的标签设置为第一数值，如“2”，将其他正样本的标签设置为第二数值，如“1”。

仍以query app1为微信，对应的目标APP在时间轴上的顺序依次为：知乎→京东→百度，为例，对应的样本集如下：

样本1：微信，京东：1(正样本)；

样本2：微信，微信：0(负样本)；

样本3：微信，知乎：2(正样本)；

样本4：微信，百度：1(正样本)；

样本5：微信，支付宝：0(负样本)；

样本6：微信，高德地图：0(负样本)。

(3)第三种标签设置规则，即表1中的label3

在一种场景中，希望未来预设时长内打开次数越多的APP排序越靠前，此种场景下，统计未来预设时长内打开的各个APP的次数，按照打开次数由多到少的顺序对各个APP进行排序，并为各APP对应的正样本依次设置标签值。

在一些实施例中，为不同次序的APP对应的正样本分别设置不同的标签值，例如，可以将某一正样本对应的标签值设置为该正样本包含的doc app对应的次序值。

仍以上述示例为例进行说明，各APP按照打开次数排序：百度→京东→知乎，则将<微信，百度>的标签值设置为“1”，<微信，京东>的标签值设置为“2”、<微信，知乎>的标签值设置为“3”，负样本的标签均设置为“0”。

在另一些实施例中，可以将按照打开次数重新排序的各APP按照实际需求划分为至少两个部分，分别为不同部分设置为不同的标签，其中，同一部分对应的标签相同。

例如，将排序在前一半的APP对应的正样本的标签设置为第一数值，如数值“2”，后一半APP对应的正样本的标签设置为第二数值，如数值“1”。

(4)第四种标签设置规则，即表1中的label4

在一种场景中，希望预测出未来预设时长内下一个打开的APP，而且，打开次数越多的APP排序越靠前。此种场景下，将下一个打开的APP对应样本的标签设置为第一数值，如数值“1”。以及，其他的APP按打开次数排序后分为至少两个部分，为不同部分设置互不相同的标签，且每部分的标签不同于下一个打开的APP对应的标签。其中，各个部分对应的标签与上述的第三种标签设置规则相同，此处不再赘述。

(5)第五种标签设置规则，即表1中的label5

在一种场景中，希望预测得到未来预设时长内下一个打开的APP，此种场景下，可以将下一个打开的APP对应正样本的标签设置为第一数值，如“1”，其他正样本和负样本对应的标签均设置为第二数值，如“0”。

以上仅示出了可能存在的五种使用场景对应的标签设置规则，实际应用中，还可以根据实际需求设定相匹配的标签设定方案，此处不再一一详述。

S180，模型训练模块利用样本集及对应的标签，训练排序算法模型得到APP预测模型。

在一些实施例中，可以将样本集划分为训练集和验证集，训练集用于训练模型，验证集用于验证模型的准确性。例如，样本集中的90％为训练集，10％为验证集。

从样本集中各样本的信息中提取查询特征，其中，样本的信息包括样本中queryapp及doc app的APP信息及时间信息。

进一步，将提取的查询特征输入至初始排序算法模型预测得到各样本中queryapp对应的预测APP序列，即得到各个样本对应的预测结果。

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

进一步，验证该排序算法模型在验证集的预测结果是否满足预设收敛条件，如果满足预设收敛条件，则训练过程结束；如果不满足预设收敛条件，则继续调整模型参数，直到满足预设收敛指标，训练过程结束。

S190，数据采集模块检测到APP预测事件被触发后，向预测模块发送该APP预测事件。

APP预测事件的触发条件可以根据实际需求设定，本申请不做特殊限制。

例如，当检测到用户的解锁操作后，触发APP预测事件，或者，当检测到某个APP被打开时，触发APP预测事件，或者，当检测到电子设备从某个APP的界面返回系统桌面时，触发APP预测事件，或者，还可以按预设时间间隔触发APP预测事件，此处不再一一详述。

S1100，预测模块响应该APP预测事件，利用训练得到的APP预测模型预测得到该APP预测事件对应的预测APP序列。

其中，预测APP序列是指在该APP预测事件之后的预设时长内可能打开的前预设数量个APP，如前5个APP，即Top5的APP序列。

预设时长可以根据实际需求设定，例如，10min，30min。不同预测时长对应的样本也不同，因此分别针对不同预测时长训练相应的机器学习算法。

在一些实施例中，预测模块解析APP预测事件获得本次预测事件对应的queryapp，如，query app可以是当前被打开的APP，或解锁事件等。

进一步，从该query app的信息中提取查询特征，并输入至APP预测模型预测得到与该query app相匹配的预测APP序列并输出。

其中，该query app的信息包括查询APP及历史APP对应的APP信息及时间信息。其中，历史APP包括在该查询APP被打开之前的预设时间段内被打开的APP。即，输入至APP预测模型的查询特征包括当前的查询APP及其历史APP的特征。

S1110，系统进程管理模块接收预测模块发送的预测APP序列，并预加载该预测APP序列中至少一个APP对应的资源。

得到预测APP序列后，可以预加载其中的一个或多个APP启动所需的资源。例如，可以只预加载下一个打开的APP的资源；又如，可以预加载多个APP的资源，如预测APP序列中的前N个APP的资源，如N可以实际需求确定，如3或5等。

本申请实施例中对预加载的具体过程以及所加载的资源不做限定，例如，为APP分配相应的硬件资源，并基于该硬件资源加载启动该APP所需的相关数据，如，可以包括进程启动、服务启动、内存分配、文件内容读取、网络数据获取、UI界面渲染等。下面结合一个示例进行说明，当检测到用户点击微信APP的图标时，触发APP预测事件，基于APP预测模型预测得到在点击微信APP后的预设时长内(如，10min、30min)，可能打开的APP序列，如：知乎、百度、淘宝、支付宝、抖音。

例如，系统进程管理模块可以预加载知乎对应的启动资源，如果用户在未来30min内打开知乎，因为知乎的启动资源已经预加载至内存，所以节省了等待启动资源加载的时间，直接展示知乎的UI界面，实现用户零等待。

又如，系统进程管理模块预加载序列中前三个APP，即知乎、百度和淘宝的启动资源。这样，如果用户在未来30min内打开知乎、百度和淘宝中的任一个APP时，都无需等待启动资源加载，直接展示该APP的UI界面。

本实施例提供的应用程序预测方法，将历史APP序列划分为多个子序列，同一子序列内部相邻的两个APP之间具有强关联性，而不同子序列之间相邻的两个APP之间没有关联性。构造样本数据时，选取同一子序列内与查询APP的开启时间间隔预设时长的APP来构造正样本，从而避免了利用与查询APP(触发APP预测事件的APP)没有关联性的APP构造正样本，即提高了正样本的准确性，进而提高了APP预测模型的准确性。而且，该方案采用排序算法模型，可以学习到同一个查询APP对应的正样本中各个目标APP之间的顺序关系，因此，预测得到的预测APP序列中的各个APP之间具有顺序性。

进一步地，在预测得到可能启动的TopN个APP之后，对其中的前I个APP进行预加载，其中，1≤I≤N，即，将这I个APP启动所需的资源提前加载至内存，当用户启动这I个APP中任一个APP时，可以能直接进入该APP的UI界面，实现用户零等待，因为在用户启动该APP之前已经提前完成该APP的加载过程。

实施例二

本实施例将分别介绍在不同的触发时机下，电子设备可以通过悬浮球展示预加载的应用程序的UI变化过程，其中，应用程序的预测及预加载过程与实施例一的过程相同，此处不再赘述。

电子设备具有悬浮球显示功能，如图12所示，用户在设置页面将悬浮球设置为开启模式后，悬浮球程序将常驻内存，即悬浮球程序一直保留在内存中。

此种场景下，可以在悬浮球内显示接下来可能会打开且已完成预加载的应用程序的图标。

如图13所示，为用户打开一应用程序时触发APP预测事件这一触发时机对应的UI界面示意图。

悬浮球设置为开启模式后，悬浮球一直悬浮在当前显示的界面之上，如图13中的(1)图所示，悬浮球在系统桌面之上显示。当用户点击应用程序的图标(如微信APP的图标)后，如图13中的(2)图所示，显示屏显示的UI面会跳转至微信APP的主界面。

与此同时，用户打开微信APP的操作会触发APP预测事件，预测出用户接下来最可能打开视频APP，并在系统后台预加载视频APP的启动资源，如图13中的(2)图所示，在悬浮球内显示视频APP的图标，用户点击悬浮球内的视频APP的图标后，如图13中的(3)图所示，UI界面从微信APP界面跳转至视频APP的预加载页面。同时，用户打开视频APP的操作同样会触发APP预测事件，并在悬浮球内展示预测并预加载的APP的图标，如音乐APP。

如图14所示，示出了返回系统桌面时触发APP预测事件这一触发时机下，电子设备的UI示意图，如图14中的(1)图所示，当从某一应用返回系统桌面时，触发APP预测事件，悬浮球在系统桌面之上显示，因为此时未预测出下一个APP或者未完成预加载过程，所以悬浮球内未显示任何应用的图标。如图14中的(2)图所示，预测出视频APP且完成预加载过程后，在悬浮球内显示视频APP的图标。用户点击悬浮球内的视频APP的图标后，如图14中的(3)图所示，UI界面跳转至视频APP的界面。

此外，在用户解锁时触发APP预测事件的场景下，悬浮球的显示与图13和图14所示的场景相似，此处不再赘述。

在另一种场景下，预测和预加载的对象还可以是应用程序中的某个服务。例如，如图15所示，在用户使用某个应用程序并返回系统桌面后，触发APP预测事件，预测出通行APP中的“乘车码”服务是接下来打开的服务，如图15中的(2)图所示，在悬浮球内展示“乘车码”服务，此时，如果用户点击悬浮球内的“乘车码”服务，UI界面从系统界面跳转至“乘车码”服务的页面，如图15中的(3)图所示。

本实施例提供的应用程序预测方法，可以在悬浮球中显示已完成预加载的APP的信息，悬浮球悬浮于当前UI界面之前，因此，用户可以直接操作悬浮球显示的下一个APP的图标来启动下一个APP，无需从当前使用APP的UI界面退回到系统桌面，再点击下一个APP图标来启动下一个APP。因此，简化了用户打开下一个APP的操作，进一步提高了用户体验。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

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

Claims (15)

1.一种应用程序预测方法，其特征在于，应用于电子设备，所述方法包括：

获取历史APP序列，所述历史APP序列包括所述电子设备在历史时间段内的APP使用记录信息；

将所述历史APP序列，在相邻的两个APP的开启时间的间隔时长大于预先获得的间隔时间阈值处进行切分，得到多个APP子序列，所述间隔时间阈值表征时序上相邻的两个APP之间间隔的时长；

对于任一APP子序列中的任一APP，选取所述任一APP子序列中在所述任一APP之后预设时长内打开的所有APP，获得与所述任一APP相匹配的目标APP；

基于所述目标APP构造所述任一APP对应的样本，并为每个所述样本构造相匹配的标签；

基于各个样本及对应的标签，训练排序算法模型得到APP预测模型；

在检测到APP预测事件后，基于所述APP预测模型预测与所述APP预测事件相匹配的预测APP序列，所述预测APP序列包括在所述APP预测事件发生后的预设时长内打开的预设数量个APP。

2.根据权利要求1所述的方法，其特征在于，获得所述间隔时间阈值的过程，包括：

将所述历史时间段包含的每个周期划分为多个时间段，针对每个时间段，获得所述时间段内时序上相邻的两个APP的开启时间之间的间隔时长；

确定所述时间段内对应的至少两个所述间隔时长的中位数，为所述时间段对应的所述间隔时间阈值。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：在每个所述APP子序列末尾添加一个空APP，得到新APP子序列，所述空APP表征没有APP；

所述对于任一APP子序列中的任一APP，选取所述任一APP子序列中在打开所述任一APP之后预设时长内打开的所有APP，获得与所述任一APP相匹配的目标APP，包括：

对于任一所述新APP子序列中除所述空APP之外的任一APP，从所述任一新APP子序列中，选取排序位于所述任一APP之后，且开启时间与所述任一APP的开启时间之间的时间差小于所述预设时长的所有APP，得到与所述任一APP相匹配的目标APP，其中，所述预设时长为所述间隔时间阈值的N倍，其中，N为大于1的正整数。

4.根据权利要求1所述的方法，其特征在于，所述基于所述目标APP构造所述任一APP对应的样本，包括：

选取所述电子设备中使用频率高于频率阈值的多个APP；

基于所述任一APP对应的所述目标APP，构造所述任一APP对应的正样本；

基于所述多个APP中除所述任一APP对应的所述目标APP之外的APP，构造所述任一APP对应的负样本。

5.根据权利要求1、2、4中任一项所述的方法，其特征在于，所述样本包括正样本和负样本，所述为每个所述样本构造相匹配的标签，包括：

将每个负样本对应的标签值设置为第一数值；

按照预设标签规则设置各个正样本对应的标签，正样本对应的标签值与所述负样本的标签值不同。

6.根据权利要求5所述的方法，其特征在于，所述按照预设标签规则设置各个正样本对应的标签，包括：

将每个正样本的标签设置为第二数值；

或者，

将包含下一个被打开的APP的正样本对应的标签设置为第三数值，以及，将剩余正样本对应的标签设置为第四数值；

或者，

将包含下一个被打开的APP的正样本对应的标签设置为第五数值，以及，按照正样本中的目标APP在所述任一APP被打开后的预设时长内的被打开次数，对其他正样本进行排序，并将前预设数量个所述其他正样本的标签设置为第六数值，以及将剩余的其他正样本的标签设置为第七数值；

或者，

按照各个正样本中的目标APP在所述任一APP被打开后的预设时长内的被打开次数，对所述各个正样本进行排序，并将前预设数量个正样本的标签设置为第八数值，以及，将剩余正样本的标签设置为第九数值。

7.根据权利要求5所述的方法，其特征在于，所述第一数值为0。

8.根据权利要求6所述的方法，其特征在于，所述第二数值为1；

或者，

所述第三数值为2，所述第四数值为1；

或者，

所述第五数值为3，所述第六数值为2，所述第七数值为1；

或者，

所述第八数值为2，所述第九数值为1。

9.根据权利要求1、2、4、6、7、8中任一项所述的方法，其特征在于，每个所述样本包括一个查询APP以及候选APP，所述查询APP是触发APP预测事件的APP，所述候选APP是开启查询APP之后的预设时长内可能开启的APP；

所述基于各个样本及对应的标签，训练排序算法模型得到APP预测模型，包括：

从各个样本的所述查询APP及所述候选APP中提取查询特征；

将所述查询特征输入预设排序算法模型进行预测，得到各个所述查询APP对应的APP序列预测结果；

根据各个所述查询APP对应样本的标签及所述APP序列预测结果，获得所述样本对应的损失值，并基于所述损失值调整所述预设排序算法模型的模型参数，直到所述损失值满足预设收敛条件模型训练过程结束，得到所述APP预测模型。

10.根据权利要求1、2、4、6、7、8中任一项所述的方法，其特征在于，所述在检测到APP预测事件后，基于所述APP预测模型预测与所述APP预测事件相匹配的预测APP序列，包括：

解析接收的APP预测事件，确定出触发所述APP预测事件的查询APP；

获取所述查询APP的信息，并从所述查询APP的信息中提取查询特征，其中，所述查询APP的信息包括在所述查询APP及对应的历史APP，所述历史APP包括在所述查询APP被打开之前的预设时间段内被打开的APP；

将所述查询特征输入所述APP预测模型进行预测，得到所述查询APP对应的所述预测APP序列。

11.根据权利要求1、2、4、6、7、8中任一项所述的方法，其特征在于，所述方法还包括：

从所述预测APP序列中选取至少一个APP，预加载所述至少一个APP对应的启动资源。

12.根据权利要求11所述的方法，其特征在于，所述从所述预测APP序列中选取至少一个APP，包括：

从所述预测APP序列中，选取在所述APP预测事件被触发之后下一个被打开的APP；

或者，

从所述预测APP序列中，选取前预设数量个APP。

13.根据权利要求11所述的方法，其特征在于，所述方法还包括：

调用悬浮球显示完成预加载的APP的信息，其中，所述悬浮球悬浮于所述电子设备的当前显示界面之上。

14.一种电子设备，其特征在于，包括存储器和处理器，所述存储器用于存储所述处理器可执行的指令，所述处理器执行所述指令使得所述电子设备执行如权利要求1-13任一项所述的应用程序预测方法。

15.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被电子设备的处理器运行时，使得所述电子设备执行如权利要求1-13任一项所述的应用程序预测方法。

Images