CN115016855B

CN115016855B - 应用预加载的方法、设备和存储介质

Info

Publication number: CN115016855B
Application number: CN202111360046.0A
Authority: CN
Inventors: 陈贵龙; 赵杰
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-11-17
Filing date: 2021-11-17
Publication date: 2023-05-09
Anticipated expiration: 2041-11-17
Also published as: CN115016855A

Abstract

本申请提供一种应用预加载的方法、设备和存储介质，方法包括，检测到预测触发事件时，确定备选应用和备选应用对应的第一预测分值；根据当前应用和备选应用的相似度，以及当前应用的互吸互斥信息，调整备选应用的第一预测分值，得到备选应用的第二预测分值；按第二预测分值由高至低选取至少一个备选应用作为预加载应用；将预加载应用加载至电子设备的运行内存。本方案根据应用间的相似度和应用的互吸互斥信息来预测预加载应用，提高了预测结果的准确性。

Description

应用预加载的方法、设备和存储介质

技术领域

本申请涉及预加载技术领域，尤其涉及一种应用预加载的方法、设备和存储介质。

背景技术

目前的电子设备在用户执行了打开某应用的操作后，需要花费一定时间将该应用的相关资源加载到运行内存中，因此用户在打开应用后需要等待一段时间才能使用应用，体验较差。

一些电子设备可以预测用户可能使用的应用并预先加载这些应用，但准确性较差，预测的应用往往和用户实际使用的应用不一致。

发明内容

本申请提供了一种应用预加载的方法、设备和存储介质，目的在于预测用户可能使用的应用并预加载这些应用，从而改善用户的使用体验。

为了实现上述目的，本申请提供了以下技术方案：

本申请提供一种应用预加载的方法，适用于电子设备，所述方法包括：

检测到预测触发事件时，确定备选应用和所述备选应用对应的第一预测分值；

根据当前应用和所述备选应用的相似度，以及所述当前应用的互吸互斥信息，调整所述备选应用的第一预测分值，得到所述备选应用的第二预测分值；

按第二预测分值由高至低选取至少一个所述备选应用作为预加载应用；

将所述预加载应用加载至电子设备的运行内存。

可选的，预测触发事件可以由感知层检测，感知层在检测到预测触发事件时向计算引擎发送预测触发指令，以触发计算引擎确定备选应用和所述备选应用对应的第一预测分值。前述步骤的具体实施方式可以参见图8所示的实施例的步骤S801b至S803b。

可选的，调整第一预测分值，以及根据调整后得到的第二预测分值确定预加载应用的步骤均可以由计算引擎执行，前述步骤的具体实施方式可以参见图8所示实施例的步骤S804b至S806b。

可选的，计算引擎可以在确定出预加载应用后将预加载应用通知系统进程管理器，使得系统进程管理器将所述预加载应用加载至电子设备的运行内存，前述步骤的具体实施方式可以参见步骤S807b和S808b。

本实施例根据应用间的相似度和应用的互吸互斥信息来预测预加载应用，提高了预测结果的准确性。

在一些可选的实施例中，电子设备在确定当前应用和所述备选应用的相似度时，可以根据所述当前应用的嵌入向量和所述备选应用的嵌入向量计算得到当前应用和备选应用的相似度。

上述实施例的具体实施方式可以参见图8对应的实施例的步骤S804b。

在一些可选的实施例中，所述预测触发事件包括，打开应用事件，返回桌面事件，解锁屏幕事件和应用事件。也就是说，电子设备可以在用户打开应用，返回桌面，解锁屏幕或者在应用内执行特定操作时预测预加载应用。

在一些可选的实施例中，所述根据当前应用和所述备选应用的相似度，以及所述当前应用的互吸互斥信息，调整所述备选应用的第一预测分值，得到所述备选应用的第二预测分值，包括：

当所述当前应用为互吸类时，根据所述当前应用和所述备选应用的相似度，上调和所述当前应用属于同一小类的所述备选应用的第一预测分值，得到所述备选应用的第二预测分值；

当所述当前应用为互斥类时，根据所述当前应用和所述备选应用的相似度，下调和所述当前应用属于同一小类的所述备选应用的第一预测分值，得到所述备选应用的第二预测分值。

本实施例的有益效果在于，根据当前应用的互吸互斥信息和具体的使用场景确定当前应用是互吸类还是互斥类，从而对应的上调或下调其他同类应用的预测分值，使得预测结果更符合用户的使用习惯，提高预测结果的准确性。

在一些可选的实施例中，还包括：

利用悬浮球显示所述预加载应用。

示例性的，电子设备可以在悬浮球中显示预加载应用的图标，名称等信息。该步骤的具体实施方式可以参见实施例二。

本实施例的有益效果在于，通过在悬浮球内展示预加载应用，引导用户更方便快捷地在不同应用之间切换，改善用户的使用体验。

本申请第二方面提供一种应用预加载的方法，适用于电子设备和服务器，所述方法包括：

所述电子设备向所述服务器发送用户数据和应用使用数据；

所述服务器根据所述用户数据和所述应用使用数据生成所述电子设备的应用的嵌入向量；

所述服务器将所述电子设备的应用的嵌入向量和预设的所述电子设备的应用的互吸互斥信息发送给所述电子设备；

所述电子设备根据所述嵌入向量和所述互吸互斥信息执行本申请第一方面任意一项所提供的应用预加载的方法。

在一些可选的实施例中，所述服务器根据所述用户数据和所述应用使用数据生成所述电子设备的应用的嵌入向量，包括：

所述服务器根据所述应用使用数据生成应用序列；

所述服务器根据所述用户数据确定所述电子设备的用户所属的用户群组；

所述服务器利用所述用户群组内的所述应用序列训练语言模型，获得所述电子设备的应用的嵌入向量。

可选的，上述步骤的具体实施方式可以参见图8所示的实施例的步骤S803a至S805a。

本实施例的效果在于，将多个用户划分为不同的用户群组，并针对不同用户群组分别训练得到嵌入向量，可以使应用的嵌入向量更符合不同群体用户的使用习惯，提高后续预测预加载应用的准确性。

在一些可选的实施例中，所述用户数据包括用户的年龄和职业。

在一些可选的实施例中，所述服务器根据所述应用使用数据生成应用序列，包括：

所述服务器按时间顺序检测所述应用使用数据中每一个应用是否满足第一截止条件和第二截止条件，所述第一截止条件为一个应用的使用时长大于使用时长阈值，所述第二截止条件为一个应用和后一个应用的间隔时长大于间隔时长阈值；

所述服务器根据满足所述第一截止条件的应用和满足所述第二截止条件的应用，将所述应用使用数据中记录的应用划分为多个应用序列。

上述生成应用序列的过程可以参见图8所示的实施例的步骤S804a。

在一些可选的实施例中，所述服务器利用所述用户群组内的所述应用序列训练语言模型，获得所述电子设备的应用的嵌入向量，包括：

所述服务器将所述应用序列中每一个应用均替换为对应的标识码，获得标识码序列，出现次数小于预设的次数阈值的应用对应的标识码相同；

所述服务器利用所述标识码序列训练语言模型，获得所述电子设备的应用的嵌入向量。

本实施例的有益效果在于，出现次数较少的应用难以通过训练获得对应的嵌入向量，通过为出现次数较少的应用配置相同的标识码，可以避免出现次数较少的应用对训练语言模型的过程造成干扰，改善训练效果。

在一些可选的实施例中，所述服务器利用所述标识码序列训练语言模型，获得所述电子设备的应用的嵌入向量之前，还包括：

所述服务器删除包含的标识码的数量小于预设的数量阈值的所述标识码序列。

本实施例的有益效果在于，删除包含的标识码数量过少的标识码序列，可以避免这些标识码数量过少的标识码序列干扰语言模型的训练过程，提高训练的效率。

本申请第三方面还提供一种电子设备，包括：一个或多个处理器、存储器；

所述存储器用于存储一个或多个程序；

所述一个或多个处理器用于执行一个或多个程序，使得电子设备执行如本申请第一方面和第二方面任意一项所提供的应用预加载的方法。

本申请还提供一种计算机存储介质，用于存储计算机程序，所述计算机程序被执行时，具体用于实现如本申请第一方面和第二方面任意一项所提供的应用预加载的方法。

本申请实施例一种应用预加载的方法、设备和存储介质，方法包括，检测到预测触发事件时，确定备选应用和备选应用对应的第一预测分值；根据当前应用和备选应用的相似度，以及当前应用的互吸互斥信息，调整备选应用的第一预测分值，得到备选应用的第二预测分值；按第二预测分值由高至低选取至少一个备选应用作为预加载应用；将预加载应用加载至电子设备的运行内存。本方案根据应用间的相似度和应用的互吸互斥信息来预测预加载应用，提高了预测结果的准确性。

附图说明

图1为本申请实施例公开的一种电子设备的结构示意图；

图2为本申请实施例公开一种电子设备的软件架构示意图；

图3为本申请实施例公开的一种开启应用的用户界面示意图；

图4a为本申请实施例公开的第一种应用预加载的用户界面示意图；

图4b为本申请实施例公开的第二种应用预加载的用户界面示意图；

图4c为本申请实施例公开的第三种应用预加载的用户界面示意图；

图5a为本申请实施例公开的第四种应用预加载的用户界面示意图；

图5b为本申请实施例公开的第五种应用预加载的用户界面示意图；

图6为本申请实施例公开的一种实现应用预加载的软件架构示意图；

图7为本申请实施例公开的一种获得向量信息的方法的流程图；

图8为本申请实施例公开的一种应用预加载的方法的信令交互示意图；

图9a为本申请实施例公开的一种应用序列的示意图；

图9b为本申请实施例公开的另一种应用序列的示意图；

图10为本申请实施例公开的一种应用预加载的方法的流程图；

图11a为本申请实施例公开的第六种应用预加载的用户界面示意图；

图11b为本申请实施例公开的第七种应用预加载的用户界面示意图；

图12为本申请实施例公开的第八种应用预加载的用户界面示意图。

具体实施方式

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

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

本申请实施例提供一种电子设备100，其具体可以是手机，平板电脑等设备。

如图1所示，电子设备100可以包括：处理器110，外部存储器120，内部存储器(也称“内存”)121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identificationmodule，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)等。

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

以上是以电子设备100为例对本申请实施例作出的具体说明。应该理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件.软件.或硬件和软件的组合中实现。

本申请实施例提供的电子设备可以是用户设备(user equipment，UE)，例如可以为移动终端(例如用户手机)、平板电脑、桌面型、膝上型笔记本电脑、手持计算机、上网本、个人数字助理(personal digital assistant，PDA)等设备。

另外，在上述部件之上，运行有操作系统。例如苹果公司所开发的iOS操作系统，谷歌公司所开发的Android开源操作系统，微软公司所开发的Windows操作系统，以及系统等。在该操作系统上可以安装运行应用程序。

电子设备100的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

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

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

应用程序层可以包括一系列应用程序包。如图2所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图2所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，系统进程管理器，通知管理器，预测模块等。其中预测模块又包括感知层和计算引擎。

感知层可以检测到应用层发生的任意事件，例如返回桌面事件，打开应用事件等。在本实施例中，感知层可以在检测到特定的预测触发事件后触发计算引擎进行应用预测。

计算引擎用于预测接下来一段时间内可能被打开的应用，并将预测结果告知系统进程管理器和应用层，以便系统进程管理器和应用层执行对应的操作。

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

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

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

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

当用户打开电子设备100的一个应用时，电子设备100需要花费较长的开启时间将该应用的相关资源，例如图像资源等加载到电子设备的运行内存(又称Random AccessMemory，RAM)中，在加载完相关资源之后，电子设备才能运行该应用，显示屏才会显示该应用的界面。

以图3为例，用户在图3的(1)所示的界面中点击视频应用后，电子设备100需要先加载视频应用的相关资源，在加载资源的这段时间内，电子设备100显示如图3的(2)所示的载入界面，在完成相关资源的加载之后，电子设备100才会显示如图3的(3)所示的视频应用的界面。可见，在图3所示的场景中，从用户完成打开应用的操作，到电子设备显示要打开的应用的界面需要等待一定时间，因此用户的使用体验较差。

为了解决上述问题，电子设备100提供了应用预加载的功能。应用预加载，是指电子设备100预测用户将要打开的应用，从而在用户打开应用之前就将应用的资源加载到运行内存中，这样在用户实际执行打开应用的操作时，电子设备100就不需要再耗费时间来加载资源，而是直接基于预先加载到运行内存的资源运行应用并显示对应的界面。

实施例一

下面结合图4a至图4c对具有应用预加载功能的电子设备100的用户界面进行说明。

在一些可选的实施例中，电子设备100可以在检测到解除锁定的事件时预测用户在解锁后可能打开的应用。

如图4a的(1)所示，在电子设备100处于锁屏状态时，用户可以通过滑动解锁来解除锁定状态，完成滑动解锁后，电子设备100即显示如图4b的(2)所示的桌面。

可以理解的，在其他可选的实施例中，用户还可以通过其他的操作来解除锁定状态，如图4b的(1)所示的滑动解锁仅仅是一种示例性的解锁方式，本实施例对具体的解锁方式不做限定。

在用户执行解锁操作时，电子设备100检测到解锁事件，开始预测用户解锁后可能打开的应用，并将预测出的可能打开的应用预先加载到运行内存(又称Random AccessMemory，RAM)中。这些电子设备100预测的用户可能打开的应用可以称为预加载应用。示例性的，预加载应用可以包括微信应用。

请参见图4a的(2)，在完成解锁后，用户点击桌面上微信应用的图标以打开微信应用。由于电子设备100已经在用户解锁时将微信应用预先加载到RAM中，因此在用户点击微信应用的图标后，电子设备100可以立即显示如图4a的(3)所示的微信应用内的界面。

在一些可选的实施例中，电子设备100可以在用户打开一个应用时预测用户在该应用之后可能打开的其他应用。

请参见图4b的(1)，当用户打开电子设备100上的一个应用，例如微信应用时，电子设备100检测到打开应用的事件。响应于该事件，电子设备100在后台进行应用预测，确定出多个预加载应用，同时响应用户的操作，显示图4b的(2)所示的微信应用内界面。

在用户使用微信应用期间，电子设备100将这些预测出的预加载应用加载到电子设备100的RAM中。示例性的，预加载应用可以包括视频应用。

请参见图4b的(3)，用户在停止使用微信应用后，从桌面打开视频应用，由于视频应用已经预加载到运行内存中，因此在用户执行了打开视频应用的操作后，电子设备能够立即显示如图4b的(4)所示的视频应用的界面。

在一些可选的实施例中，电子设备100也可以在用户返回桌面时预测用户可能打开的应用。

请参见图4c的(1)，在用户返回电子设备100的桌面时，电子设备100检测到返回桌面的事件，然后进行应用预测，确定出若干个预加载应用。在显示桌面期间，电子设备100将这些预加载应用加载到运行内存中。示例性的，预加载应用可以包括视频应用。

如图4c的(2)所示，当用户从桌面打开视频应用时，由于视频应用已经预加载到RAM中，电子设备100可以很快地开始运行视频应用并显示如图4c的(3)所示的视频应用的界面。

本实施例提供的应用预加载的方法，可以根据应用内发生的事件而预加载不同的应用。

请参见图5a的(1)，用户打开淘宝应用时，电子设备100响应于用户打开淘宝应用的事件，预测预加载应用。此时用户还未在淘宝应用中提交订单，电子设备100确定淘宝应用的大类为互吸类。淘宝应用属于互吸类，表示用户在使用淘宝应用时有较大的可能切换至其他和淘宝应用属于同一小类的应用，也就是切换至其他购物类应用。

因此，电子设备100将属于购物类应用的天猫应用预测为预加载应用，并在显示如图5a的(2)所示的界面时，将天猫应用加载至RAM中。

当用户从淘宝应用退出至图5a的(3)所示的界面并打开天猫应用时，由于天猫应用已经预先加载至RAM中，所以电子设备100可以立即开启天猫应用，显示如图5a的(4)所示的天猫应用内的界面。

请参见图5b的(1)，用户打开淘宝应用时，电子设备100预测预加载应用，然后在显示如图5b的(2)所示的淘宝应用内的界面时将预测出的应用加载至RAM中。

在打开淘宝应用后，请参见图5b的(3)，用户在淘宝应用内选择完商品并提交订单。电子设备100响应于提交订单的事件，再次预测预加载应用。

用户提交订单时，电子设备100将淘宝应用所属的大类确定为互斥类。淘宝应用属于互斥类，表示用户在退出淘宝应用之后不太可能使用其他和淘宝应用同样属于购物类的应用。所以在用户提交订单时，电子设备100预测的预加载应用中不包括天猫应用。

用户提交订单后退出淘宝应用，相应的电子设备100显示如图5b的(4)所示的界面，此时电子设备100预加载的应用中不包括天猫应用，所以在用户执行了打开天猫应用的操作后，电子设备100需要响应将天猫应用加载至RAM中，因此电子设备100会显示如图5b的(5)所示的加载界面，在加载完成后，电子设备100才能显示如图5b的(6)所示的天猫应用的界面。

结合图5a和图5b可以看出，本实施例中，在用户打开淘宝应用时，电子设备100确定淘宝应用为互吸类，此时电子设备100在预测预加载应用时会将和淘宝应用同属于购物类的其他应用(如天猫应用)确定为预加载应用；当用户在淘宝应用内提交订单时，电子设备根据提交订单这一事件，确定淘宝应用属于互斥类，此时电子设备100预测预加载应用时就不会将同属于购物类的其他应用确定为预加载应用。

在一些实施例中，电子设备100的应用预加载功能，可以基于如图6所示的软件架构实现。

如图6所示，电子设备的软件层可以包括应用层，应用框架层，类库层和系统内核层。其中应用层包括桌面，视频打卡软件等多种应用，系统内核层包括显示驱动，应用框架层包括系统进程管理器，计算引擎和感知层，其中计算引擎包括算法模块和预测模块，感知层包括数据保存模块和数据采集模块。

数据采集模块用于采集电子设备100中的数据，包括但不限于应用使用数据和用户数据等，其中应用使用数据主要是包括反映电子设备100中应用的使用情况的数据，例如每个应用在什么时刻打开，什么时刻退出等，用户数据则包括和电子设备100的用户相关的数据，例如用户的职业，年龄等。

在一些可选的实施例中，数据采集模块可以通过如下方式获得用户数据：在用户首次使用电子设备100时，数据采集模块在显示屏上显示用于采集用户数据的界面，并提示用户输入职业、年龄等用户数据。

在另一些可选的实施例中，用户数据也可以不通过数据采集模块采集，而是由服务器利用特定的算法分析得到。示例性的，服务器可以根据每个用户的应用使用数据分析得到用户的职业和年龄，然后将用户的职业和年龄发送给电子设备100。

数据保存模块用于保存数据采集模块采集到的数据，还用于保存服务器向电子设备100发送的数据，后者可以包括预测信息，向量信息和互吸互斥信息。其中，向量信息可以包括多个嵌入向量(又称embedding向量)以及嵌入向量对应的应用的名称(或者其他能够表示特定应用的信息)，互吸互斥信息可以包括应用的名称，应用的大类切换事件，发生大类切换事件前应用的大类以及发生大类切换事件后应用的大类。大类可以包括互吸类，互斥类和其他类三种。

向量信息的获得方式可以参见图7。电子设备将数据采集模块采集到的应用使用数据发送给服务器的云端数据库，在云端数据库收集到多个电子设备的应用使用数据后，服务器利用这些应用使用数据训练语言模型，从而获得向量信息，然后将向量信息反馈给电子设备。

在一些可选的实施例中，应用的互吸互斥信息可以人工在服务器中设置，然后由服务器下发给电子设备。

本实施例中，每一个应用都对应有一个嵌入向量，不同应用的嵌入向量可以相同也可以不同。示例性的，对于使用频率较高的应用可以每个应用对应唯一的一个嵌入向量，使用频率过低的应用则通常会多个应用对应同一个嵌入向量。

应用的互吸互斥信息可以采用多种形式保存在电子设备的内部存储器中，本实施例对具体的保存形式不做限定。

示例性的，应用的大类切换事件以及发生大类切换事件前后所属的大类可以采用标签的形式存储。

在一些可选的实施例中，预测信息，向量信息和互吸互斥信息均可以由服务器下发给电子设备100，并由服务器定期更新，具体的更新周期可以根据实际需要设定，本实施例对此不做限定。示例性的，服务器可以每隔一个月生成一次新的向量信息，然后将新的向量信息下发给电子设备以替换原有的向量信息。

或者，服务器也可以不定期更新上述向量信息。示例性的，服务器可以定期将最近一段时间内各应用的使用频率，和更早的时间段各应用的使用频率比对，若两者差别不大，则服务器可以不更新向量信息；若两者差别较大，比如发现近期出现了使用频率较高的若干款新应用，或者若干款旧应用的使用频率明显升高或降低，则更新向量信息。

在一些可选的实施例中，对向量信息的更新可以通过服务器主动向电子设备100推送的方式实现。

在图6所示的软件架构中，感知层可以感知到应用层发生的事件，当感知层感知到应用层发生预测触发事件时，感知层向计算引擎发送预测触发指令，以触发计算引擎开始预测预加载应用。

预测触发事件包括预先指定的至少一种发生在应用层的事件，预测触发事件可以在电子设备100出厂时预先设定，也可以在使用期间由电子设备100的用户设置，还可以由电子设备100根据服务器的反馈而设定，本实施例对预测触发事件的具体范围不做限定。

示例性的，电子设备100可以将如下事件确定为预测触发事件：打开应用，返回桌面，解锁屏幕和应用事件等。其中，应用事件又可以包括，购物类应用的提交订单事件，打车类应用的约车成功的事件等应用内发生的事件。

收到上述数据后，计算引擎的算法模块基于其中的预测信息确定M个备选应用，其中M为预先设定的正整数。M可以根据电子设备100的运行内存的空间和电子设备100已安装的应用数量设定，本实施例对M的具体数值不做限定。示例性的，M可以设定为10。

算法模块可以基于统计方法或机器学习模型确定M个备选应用。

统计方法，主要是指，针对不同用户群体，分时段地统计该用户群体内各用户使用电子设备上安装的各个应用的频率和时长，然后将当前时段内当前用户高频使用的若干个应用确定为备选应用。示例性的，若需要预测M个备选应用，则基于统计方法，可以将各个应用在当前时段内被对应用户群体的使用频率由高到低排序，选取其中前M个应用作为备选应用。

当算法模块基于统计方法确定备选应用时，上述预测信息可以包括电子设备100上安装的每一个应用在最近一段时间(例如最近一周内)的使用频率，常用的时间段等信息。

当算法模块基于统计方法确定备选应用时，这些备选应用的使用频率可以视为这些备选应用的第一预测分值。

在本实施例中，应用预测模块可以采用任意一种统计方法来预测得到多个备选应用，本实施例对具体的统计方法不做限定。

当算法模块基于机器学习模型确定备选应用时，上述预测信息可以包括各个应用的特征向量以及服务器训练得到的应用预测模型。

在一些可选的实施例中，服务器可以预先收集一定时间内(如最近几个月内)多个用户使用不同应用的情况，包括但不限于应用的属性，使用时长，在什么时候使用，使用频率等信息，基于这些汇总到的信息确定每个应用的特征向量，并利用这些特征向量训练初始的机器学习模型，由此获得的一个应用预测模型。

由此，算法模块可以调用应用预测模型，对电子设备100上安装的各个应用的特征向量进行预算，从而得电子设备当前安装的各个应用的使用概率，最后就可以按使用概率从高到低选取前M个应用作为备选应用。

若算法模块基于机器学习模型确定备选应用，则上述预测信息可以是电子设备100安装的各个应用的特征向量。

对基于机器学习模型预测得到的各个备选应用，这些备选应用的使用概率可以视为这些备选应用的第一预测分值。

在本实施例中，算法模块可以基于任意一种机器学习模型来预测得到多个备选应用，本实施例对具体使用的机器学习模型不做限定。

在算法模块确定出M个备选应用后，预测模块根据感知层提供的备选应用的嵌入向量和当前的类型，以及当前应用的嵌入向量和当前的类型，在M个备选应用中确定出N个预加载应用。

示例性的，预测模块根据上述应用的嵌入向量和当前的类型调整M个备选应用的第一预测分值，得到M个备选应用的第二预测分值，然后根据第二预测分值从高到低地选取N个应用作为预加载应用。

N为预设的正整数。在一些可选的实施例中，N可以根据电子设备100的运行内存的存储空间来设定。例如，若运行内存最多可以存储6个应用运行时的资源，则N可以设定为5。

基于上述电子设备和软件架构，本实施例公开一种应用预加载的方法，请参见图8，该方法可以包括如下步骤：

S801a，感知层采集应用使用数据和用户数据。

在一些可选的实施例中，应用使用数据可以包括各个应用的开启时刻和关闭时刻，用户数据可以包括用户的职业和年龄等数据。

步骤S801a的一种可选的实施方式是，每当感知层感知到应用层发生打开一个应用的事件时，数据采集模块可以采集当前的时刻和被打开的应用的名称，由此获得该应用的一个打开时刻；同理，当感知层感知到应用层发生关闭一个应用的事件时，数据采集模块采集当前的时刻和被关闭的应用的名称，由此获得该应用的一个关闭时刻。

在一些可选的实施例中，感知层也可以在感知到应用层的解锁屏幕或返回桌面的事件时采集应用使用数据，本实施例对此不做限定。

示例性的，感知层在T0时刻感知到打开微信应用的事件，在T1时刻感知到关闭微信应用的事件，数据采集模块通过采集上述时刻信息，就可以获得微信应用在T0时刻打开，在T1时刻关闭的信息。

用户数据可以在用户首次使用电子设备时提示用户输入，或者，可以在用户在其他应用中输入相应信息后，从其他应用获取。

在一些实施例中，采集到的应用使用数据可以存储在数据保存模块。

S802a，感知层向服务器发送应用使用数据和用户数据。

在一些可选的实施例中，感知层可以实时地向服务器发送应用使用数据，也就是说，每次采集到一个应用的打开时刻或者关闭时刻，就将该信息发送给服务器。

在另一些可选的实施例中，感知层可以周期性的向服务器发送应用使用数据。例如，每经过一周，感知层将过去一周内采集到的应用使用数据发送给服务器。

由于用户数据在短时间内一般不会发生变化，感知层可以以较低的频率向服务器发送用户数据，例如，每经过一个月感知层才向服务器发送一次用户数据。

需要说明的是，步骤S801a和步骤S802a是以一个电子设备为例说明电子设备和服务器的数据交互。在具体实施时，服务器可以从多个电子设备接收多个用户的应用使用数据和用户数据，进一步可以理解的，后续步骤中服务器所用的应用使用数据和用户数据，包括多个电子设备上报的应用使用数据和用户数据。

S803a，服务器根据应用使用数据生成应用序列。

服务器可以通过多种方式生成应用序列，本实施例对生成应用序列的具体实施方式不做限定。

示例性的，针对每一个电子设备，服务器获得该电子设备上报的应用使用数据后，可以通过如下方式生成应用序列：

服务器选取一定时间段内的应用使用数据，例如选取最近一天内的应用使用数据，将这些应用使用数据中最早使用的那个应用视为起始应用，然后从起始应用开始按打开时间从早到晚逐一判断其中每一个应用是否满足预设的第一截止条件和第二截止条件。

在一些可选的实施例中，服务器可以先判断一个应用是否满足第一截止条件，若这个应用不满足第一截止条件，再判断这个应用是否满足第二截止条件。

第一截止条件，是指，一个应用的使用时长大于预设的使用时长阈值。

应用的使用时长可以用该应用的打开时刻，和打开时刻之后的首个关闭时刻作差得到。

第二截止条件，是指，一个应用和后一个应用的间隔时长大于预设的间隔时长阈值。

两个应用的间隔时长，是指，前一个应用的关闭时刻到后一个应用的打开时刻所经过的时长。例如，用户在T1时刻关闭微信应用，在T2时刻打开抖音应用，则微信应用和抖音应用的间隔时长就是T2-T1。

若判断出一个应用满足第一截止条件，则服务器将当前的起始应用、这个满足第一截止调节的应用以及两者之间的所有应用确定为一个应用序列，然后将这个满足第一截止条件的应用视为起始应用，重复前述过程，直至最后一个应用为止。

若判断出一个应用满足第二截止条件，则服务器在满足第二截止条件的应用和它的后一个应用之间添加一个截断应用，将当前的起始应用、截断应用以及两者之间的所有应用确定为一个应用序列，然后将截断应用视为起始应用，重复前述过程，直至最后一个应用为止。

若判断至最后一个应用，可以直接将当前的起始应用、最后一个应用以及两者之间的所有应用确定为一个应用序列。

其中，当将截断应用视为起始应用时，不判断截断应用是否满足第一截止调节和第二截止条件，而是直接从截断应用的后一个应用开始判断。

需要说明的是，截断应用仅仅是本实施例中为生成应用序列而添加的一个标签，并不对应于电子设备上实际安装的应用程序。

截断应用可以表示用户在对应的时间段内未使用电子设备100上安装的任意应用。

使用时长阈值可以人工指定，也可以根据如下方法确定：

选取一定时间内(例如最近一周内)多个电子设备的应用的使用时长，对其中大于设定阈值(例如10分钟)的使用时长由高到低排序，然后将其中第X位(例如第25位)的使用时长确定为使用时长阈值。

间隔时长阈值可以人工指定，也可以根据如下方法确定：

选取一定时间内(例如最近一周内)多个电子设备的间隔时长，对其中大于设定阈值(例如10分钟)的间隔时长由高到低排序，然后将其中第X位(例如第25位)的间隔时长确定为间隔时长阈值。

下面结合一个例子对上述生成应用序列的方式进行说明：

请参见图9a，假设一个电子设备上报的一天内的应用使用数据包括8个应用，按使用时间从早到晚依次记为应用1至应用8，服务器将应用1视为起始应用，由起始应用开始逐一判断每个应用是否满足第一截止条件或第二截止条件，在判断出应用4的使用时长大于使用时长阈值(即满足第一截止条件)后，将当前的起始应用(即应用1)至应用4的所有应用确定为一个应用序列。

随后，服务器将应用4视为起始应用，继续上述判断，直至判断到应用8，然后将应用4至应用8也确定为一个应用序列，由此获得应用1至应用4构成的应用序列1，以及应用4至应用8构成的应用序列2。

请参见图9b，假设一个电子设备上报的一天内的应用使用数据包括8个应用，按使用时间从早到晚依次记为应用1至应用8，服务器将应用1视为起始应用，由起始应用开始逐一判断每个应用是否满足第一截止条件或第二截止条件，在判断出应用4满足第二截止条件后，服务器在应用4和应用5之间添加截断应用，将当前的起始应用(即应用1)至截断应用的所有应用确定为应用序列3。

随后，服务器从应用5开始重复上述判断，直至判断至最后一个应用8，然后将应用4和应用5之间的截断应用至应用8的所有应用确定为应用序列4。

S804a，服务器根据用户数据划分用户群组，利用应用序列生成每个用户群组的群组语料库。

根据用户数据的不同，具体的划分用户群组的方式可以有多种，本实施例对此不做限定。

示例性的，在本实施例中，若用户数据包括用户的年龄和职业，则可以按下述表1的方式划分出多个用户群组：

表1

	小于18岁	18岁至65岁	大于65岁
				教师	群组1	群组2	群组3
程序员	群组4	群组5	群组6
				公务员	……	……	……

其中小于18岁的用户无职业，因此将所有小于18岁的用户统一划分为群组1。

服务器可以通过多种方式生成群组语料库，本实施例对具体的生成方式不做限定。示例性的，服务器可以按如下方式生成每一个用户群组的群组语料库：

针对一个用户群组，服务器确定出基于该用户群组的用户的应用使用数据而产生的每一个应用序列，将确定出的这些应用序列中的应用去重后为其中每一个应用分配一个对应的标识码(也可以称为应用ID)，再将每个应用序列中的应用替换为对应的标识码，由此获得的多个标识码序列构成的集合，就是这个用户群组对应的群组语料库。

可选的，在分配标识码时，可以为出现次数较少的应用分配相同的标识码，例如，在该用户群组的所有应用序列中，应用1和应用2的出现次数均少于预设的次数阈值(例如5次)，则应用1和应用2可以共用一个标识码。

这样做的好处在于，防止出现次数较少的应用对训练语言模型的过程造成干扰。

进一步可选的，为了改善训练效果，可以删除群组语料库中包含的标识码少于预设的数量阈值(例如少于3个)的标识码序列。

步骤S804a为可选的步骤。在一些可选的实施例中，服务器也可以不划分用户群组，而是直接将获得的所有应用序列作为一个语料库来训练语言模型。

不同用户群组的用户往往具有不同的使用习惯，通过划分用户群组，可以让生成的嵌入向量更能反映用户真实的使用习惯，从而提高后续预测出的预加载应用的准确性。

S805a，服务器用群组语料库训练语言模型，获得群组语料库中应用的嵌入向量。

步骤S805a中服务器训练的可以是任意一种语言模型，本实施例对具体的语言模型不做限定。示例性的，步骤S805a中的语言模型可以是词向量(又称word2vec)模型。

通过训练获得的应用的嵌入向量的维度可以根据需要预先设定，例如可以设定为8或16。

对于一个群组语料库，通过训练语言模型可以获得该群组语料库中每一个标识码对应的嵌入向量，然后基于标识码和应用的对应关系，就可以确定每个应用对应的嵌入向量。

需要说明的是，在训练语言模型时，每一个群组语料库均被独立的用于训练语言模型，不同群组语料库互不干扰。同一个应用在不同群组语料库中可以对应不同的嵌入向量。

示例性的，在利用表1中群组1的群组语料库中，经过训练获得的微信应用对应的嵌入向量可以是向量1，而在利用表1中群组2的群组语料库中，微信应用对应的嵌入向量可以是不同于向量1的向量2。

在一些可选的实施例中，训练语言模型已获得应用的嵌入向量的步骤，也可以由电子设备100来执行。相对的，由服务器执行该步骤的好处在于，避免提高电子设备的功耗，从而在不提高电子设备的功耗的前提下提高预测预加载应用的准确度。

S806a，服务器向感知层发送向量信息和互吸互斥信息。

在一些可选的实施例中，服务器可以将每一个用户群组对应的向量信息和互吸互斥信息均发送给电子设备的感知层。

在另一些可选的实施例中，对于一个电子设备，服务器可以只向这个电子设备的感知层发送这个电子设备的用户所属用户群组的向量信息和互吸互斥信息。

一个用户群组对应的向量信息，包括这个用户群组的群组语料库中出现过的每一个应用的名称和对应的嵌入向量。一个用户群组对应的互吸互斥信息，包括这个用户群组的群组语料库中出现过的每一个应用的名称和对应的互吸互斥信息。

每个应用的互吸互斥信息可以人工在服务器中配置，再由服务器下发给各个电子设备。

S807a，感知层保存向量信息和互吸互斥信息。

感知层收到的向量信息和互吸互斥信息可以由感知层的数据保存模块存储。

互吸互斥信息的保存方式请参见图6对应的实施例，此处不再赘述。

本实施例对向量信息的具体保存方式不做限定。示例性的，向量信息可以采用表格的形式存储，当有不同用户群组的向量信息，每一个用户群组的向量信息可以单独用一个表格来存储。

示例性的，向量信息可以用如下表2的形式存储：

表2

应用名称	嵌入向量
		微信	向量1
支付宝	向量2
		……	……

需要说明的是，上述步骤S801a至S807a为本实施例中服务器为电子设备提供向量信息的过程，如图6对应的实施例所述，该过程可以由服务器定期执行(例如每个月执行一次)或者不定期执行。

S801b，感知层检测到应用层的预测触发事件。

请参见图4a至图5b，上述预测触发事件可以是打开应用的事件，返回桌面的事件，解锁屏幕的事件，还可以是应用层的应用内部发生的特定事件，例如购物应用的提交订单事件，打车应用的约车成功事件等，本实施例对预测触发事件的具体范围不做限定。

S802b，感知层向计算引擎发送预测触发指令。

在一些可选的实施例中，预测触发指令可以向量信息，当前应用的大类，以及电子设备100安装的每个应用的小类。

其中，应用的小类包含打车类、购物类和游戏类等类型。电子设备100可以在安装一个应用时，从该应用的安装渠道(例如应用市场)获取该应用所属的小类。

感知层向计算引擎发送的向量信息，可以包括电子设备100当前已安装的每一个应用的名称以及这些应用在电子设备100的用户所属用户群组中对应的嵌入向量。

示例性的，感知层可以以表2的形式将向量信息发给计算引擎。

步骤S802b中应用当前的类型，可以包括电子设备100目前安装的每一个应用所属的小类，以及当前应用的大类。

其中，当前应用的大类由感知层根据当前应用的互吸互斥信息和预测触发事件来确定。示例性的，确定当前应用的大类的方式可以是：

判断当前应用的互吸互斥信息中是否包含大类切换事件。如果当前应用的互吸互斥信息中未包含大类切换事件，则当前应用的大类就是其互吸互斥信息中记录的大类。

如果当前应用的互吸互斥信息中包含大类切换事件，判断预测触发事件是否为当前应用的互吸互斥信息中的大类切换事件。

如果预测触发事件是当前应用的互吸互斥信息中的大类切换事件，就将当前应用的互吸互斥信息中发生大类切换事件后应用的大类确定为当前应用的大类。

如果预测触发事件不是当前应用的互吸互斥信息中的大类切换事件，就将当前应用的互吸互斥信息中发生大类切换事件前应用的大类确定为当前应用的大类。

当前应用由感知层根据检测到的预测触发事件确定。

示例性的，若预测触发事件为返回桌面事件，则可以将桌面视为当前应用；若预测触发事件为打开应用事件，则可以将被打开的应用视为当前应用，例如，预测触发事件为用户打开微信应用的事件，则当前应用为微信应用；若预测触发事件为某个应用内发生的特定事件，可以将该应用视为当前应用，例如，预测触发事件为用户在淘宝应用内提交订单的事件，可以将淘宝应用视为当前应用。

S803b，计算引擎根据预测信息确定备选应用。

计算引擎确定备选应用的方式可以参见图6对应的实施例，此处不再赘述。

S804b，计算引擎根据当前应用和备选应用的嵌入向量确定当前应用和备选应用的相似度。

在步骤S804b中，计算引擎可以分别计算每一个备选应用的嵌入向量和当前应用的嵌入向量的相似度。两个向量的相似度可以采用多种算法计算，本实施例对具体的算法不做限定。

示例性的，假设当前应用的嵌入向量为X(x1，x2……x8)，备选应用的嵌入向量为Y(y1，y2……y8)，计算引擎可以按如下公式计算当前应用和这个备选应用的相似度Sim：

S805b，计算引擎根据相似度和应用的类型调整备选应用的第一预测分值，得到第二预测分值。

在步骤S805b中，计算引擎可以通过多种方式调整备选应用的第一预测分值，本实施例对具体的调整方式不做限定。

示例性的，请参见图10，步骤S805b可以按如下方式实施：

首先识别当前应用的大类，若当前应用的大类为其他类，则确定调整方式为分值不变，此时在根据相似度确定第二预测分值时，直接将每个备选应用的第一预测分值确定为第二预测分值，结束本步骤。也就是说，在当前应用的大类既不是互吸类也不是互斥类时，可以不调整备选应用的第一预测分值。

若当前应用的大类是互吸类，则分别判断每一个备选应用和当前应用是否相同小类。例如，假设当前应用为打车类应用，则分别判断每一个备选应用是否也属于打车类应用。对其中和当前应用不是相同小类的备选应用，保持分值不变，对其中和当前应用是相同小类的备选应用，确定调整方式为正向预测。

对于按正向预测的方式调整的备选应用，在根据相似度确定第二预测分值时，可以根据当前应用和备选应用的相似度，将该备选应用的第一预测分值上调，得到对应的第二预测分值。

本实施例对具体的上调方法不做限定。示例性的，若一个备选应用和当前应用属于同一小类，例如都属于打车类，则可以按如下公式上调该备选应用的第一预测分值：

Score2＝Score1×(1+Sim)

其中Score1表示该备选应用的第一预测分值，Sim表示该备选应用和当前应用的相似度，Score2表示该备选应用的第二预测分值。

若当前应用的大类是互斥类，则分别判断每一个备选应用和当前应用是否相同小类。例如，假设当前应用为购物类应用，则分别判断每一个备选应用是否也属于购物类应用。对其中和当前应用不是相同小类的备选应用，保持分值不变，对其中和当前应用是相同小类的备选应用，确定调整方式为负向预测。

对于按负向预测的方式调整的备选应用，在根据相似度确定第二预测分值时，可以根据当前应用和备选应用的相似度，将备选应用的第一预测分值下调，得到对应的第二预测分值。

本实施例对具体的下调方法不做限定。示例性的，若一个备选应用和当前应用属于同一小类，例如都属于打车类，则可以按如下公式下调该备选应用的第一预测分值：

Score2＝Score1×(1-Sim)

S806b，计算引擎根据备选应用的第二预测分值在备选应用中确定N个预加载应用。

在步骤S806b中，计算引擎可以根据第二预测分值的高低选取预加载应用。

示例性的，计算引擎可以按第二预测分值从高至低的选取N个备选应用作为预加载应用。

S807b，计算引擎将N个预加载应用告知系统进程管理器。

S808b，系统进程管理器将N个预加载应用预加载至运行内存中。

步骤S801b至步骤S808b可以视为本实施例提供的应用预加载的方法中电子设备100确定预加载应用并将其加载至RAM的过程，在电子设备运行期间，只要电子设备100检测到预测触发事件，就可以执行这一过程。

本实施例具有如下的有益效果：

每次确定预加载应用时，本实施例在基于统计方法或机器学习模型确定出的第一预测分值的基础上，基于应用的相似度和类型对第一预测分值进行调整，根据调整得到的第二预测分值确定预加载应用，提高了电子设备预测预加载应用的准确性。

最后，结合一个具体的例子对本实施例提供的应用预加载的方法进行说明。

假设电子设备100的用户属于表1所示的群组2，电子设备100上安装的应用包括：淘宝，天猫，微信，支付宝和XX游戏。

在T0时刻，用户点击桌面上淘宝的应用图标，打开淘宝应用。

在用户点击之后，感知层检测到打开淘宝应用这一预测触发事件，由于预测触发事件为打开淘宝应用，感知层将淘宝确定为当前应用，然后，感知层向计算引擎发送淘宝，天猫，微信，支付宝和XX游戏的预测信息，这些应用在群组2中对应的嵌入向量，以及这些应用的所属类型。

所属类型中，其中淘宝和天猫的小类为购物类，微信的小类为社交类，支付宝的小类为支付类，XX游戏的小类为游戏类。

数据保存模块中记录的淘宝的大类切换事件为提交订单事件，由于本次的预测触发事件不为淘宝的大类切换事件，感知层将淘宝的大类确定为其发生大类切换事件前的大类，也就是互吸类。

计算引擎获得上述信息后，通过统计方法或者机器学习模型确定出天猫，微信，支付宝和XX游戏这四个应用的第一预测分值，在本示例中，每次预测最多可以确定5个备选应用，于是计算引擎将这四个应用均确定为备选应用，开始调整备选应用的第一预测分值。

由于淘宝应用的大类为互吸类，天猫，微信，支付宝和XX游戏四个备选应用中只有天猫和淘宝属于同一小类，所以，将天猫的第一预测分值上调，获得天猫的第二预测分值，其他应用的第二预测分值则和第一预测分值相等。

调整结束后，按第二预测分值由高到低依次是支付宝，天猫，微信，XX游戏，预加载应用的数量N为3，所以选取其中前3个应用作为预加载应用，计算引擎通知系统进程管理器将支付宝，天猫，微信预加载到运行内存中。

可选的，计算引擎还可以通知应用层第二预测分值最高的预加载应用为支付宝，应用层收到上述通知后，在悬浮球中显示支付宝的应用图标。

用户使用淘宝应用一段时间后，在T1时刻完成商品的选取并提交了购物订单。在用户完成提交订单的操作之后，感知层检测到提交订单这一预测触发事件，所以再次向计算引擎发送淘宝，天猫，微信，支付宝和XX游戏的预测信息，这些应用在群组2中对应的嵌入向量，以及这些应用的所属类型。

第二次发送时，由于预测触发事件为淘宝的大类切换事件(即提交订单事件)，所以感知层确定淘宝的大类为发生大类切换事件后的大类，也就是互斥类。

由于第二次预测时，淘宝应用的大类为互斥类，天猫，微信，支付宝和XX游戏四个备选应用中只有天猫和淘宝属于同一小类，所以，计算引擎在确定出这四个备选应用的第一预测分值之后，将天猫的第一预测分值下调，获得第二次预测时天猫的第二预测分值，其他应用的第二预测分值则和第一预测分值相等。

调整结束后，按第二预测分值由高到低依次是支付宝，微信，XX游戏，天猫，预加载应用的数量N为3，所以选取其中前3个应用作为预加载应用，计算引擎通知系统进程管理器将支付宝，天猫，微信预加载到运行内存中。

实施例二

在一些实施例中，在用户打开悬浮球功能后，电子设备100可以通过悬浮球的形式来展示预加载应用。

请参见图11a，用户可以在图11a的(1)所示的界面执行打开悬浮球的操作，从而开启电子设备100的悬浮球功能。悬浮球功能开启后，悬浮球就可以常驻显示在电子设备100的显示屏上。

请参见图11a的(2)，在悬浮球功能开启后，电子设备100响应于用户操作，从设置悬浮球的界面返回桌面并打开聊天应用。电子设备100检测到打开聊天应用的事件后，开始预测，从而确定出若干个预加载应用，示例性的，其中可以包括视频应用。

可以理解的，本实施例中电子设备也可以在检测到返回桌面、解锁屏幕和应用事件时开始预测需要预加载的应用，并在悬浮球中显示预加载应用。如图11a所示的在检测到打开应用的事件时进行预测仅仅是预测触发事件的一个示例。

在电子设备100显示图11a的(3)所示的聊天应用的界面时，将预加载应用加载到运行内存中，同时在悬浮球中显示一个预加载应用的图标。示例性的，电子设备100可以在悬浮球中显示图11a的(3)所示的视频应用的图标。

用户可以通过点击悬浮球中显示的预加载应用的图标跳转到对应的预加载应用。仍以图11a的(3)为例，用户在使用聊天应用期间，点击图11a的(3)的悬浮球中视频应用的图标，电子设备100响应该操作，打开预加载的视频应用，显示图11a的(4)所示的视频应用的界面。

在用户打开视频应用时，电子设备100检测到打开视频应用的事件，再次开始预测预加载应用，然后将此次确定的预加载应用的图标显示在悬浮球中。示例性的，用户打开视频应用时电子设备100预测出的预加载应用可以是短信应用，因此，电子设备100在显示如图11a的(4)所示视频应用的界面时，可以在悬浮球中显示短信应用的图标。

在悬浮球内显示预加载应用的图标，仅是通过悬浮球显示预加载应用的一种实施方式。在一些可选的实施例中，电子设备100还可以在悬浮球内显示预加载应用的其他信息，本实施例对悬浮球内显示的信息不做限定。

示例性的，电子设备100可以在悬浮球内显示预加载应用的图标和名称。以图11b的(1)为例，电子设备确定出视频应用需要预加载后，可以在悬浮球内显示视频应用的图标和名称。

示例性的，电子设备100可以在悬浮球内显示预加载应用的图标，名称和应用内的文字。以图11b的(2)为例，电子设备确定出视频应用需要预加载后，可以在悬浮球内显示视频应用的图标，名称，以及视频应用最近一次播放的一个视频的标题。

本实施例中，电子设备获取向量信息和应用的互斥互吸信息，以及根据这些信息确定预加载应用并加载的过程，均和实施例一中图6所示的过程一致，不再赘述。

进一步的，在本实施例中计算引擎确定出N个预加载应用后，可以将预加载应用的名称发送给应用层。

可选的，由于悬浮球中一般仅展示一个预加载应用，计算引擎可以将N个预加载应用中第二预测分值最高的预加载应用的名称发送给应用层。

收到预加载应用的名称后，应用层可以通过悬浮球来展示对应的预加载应用，具体的展示方式请参见图11a和图11b此处不再赘述。

和实施例一相同的，在实施例二中，电子设备100同样可以根据应用是否发生的特定事件而预测不同的预加载应用。例如，在淘宝应用发生提交订单事件之前和发生提交订单事件之后，电子设备100预测的预加载应用可能不同。

请参见图12的(1)，当用户打开桌面上的淘宝应用时，电子设备100响应于用户打开淘宝应用的事件，预测预加载应用，此时由于用户还未提交订单，电子设备100确定淘宝应用属于互吸类，预测的预加载应用包括天猫应用。

在电子设备100显示如图12的(2)所示的淘宝应用内的界面时，电子设备100将预测出的预加载应用加载至RAM，同时在悬浮球内显示预加载应用的名称，例如在悬浮球内显示“天猫”字样。

用户在淘宝应用内完成商品的挑选后进入图12的(3)所示的提交订单的界面，然后点击“提交订单”按钮。

用户点击“提交订单”按钮后，电子设备100检测到淘宝应用内提交订单的事件，再次开始预测预加载应用，此时由于用户已经提交订单，电子设备100确定淘宝应用属于互斥类，因此预测的预加载应用不包含同样属于购物类的天猫应用，示例性的，用户提交订单时，电子设备100预测的预加载应用可以是短信应用。

提交订单成功后，电子设备100显示如图12的(4)所示的订单提交成功的界面，并在悬浮球内显示提交订单时预测的预加载应用的名称，例如显示“短信”字样。

本实施例具有如下的有益效果：

电子设备在悬浮球内展示预加载应用，可以使用户更方便快捷地在不同应用之间切换，改善用户的使用体验。

本申请实施例还提供一种电子设备，包括：一个或多个处理器、存储器；

存储器用于存储一个或多个程序；

一个或多个处理器用于执行一个或多个程序，使得电子设备执行本申请任一实施例提供的应用预加载的方法。

本申请实施例还提供一种计算机存储介质，用于存储计算机程序，计算机程序被执行时，具体用于实现本申请任一实施例提供的应用预加载的方法。

本申请实施例还提供一种计算机程序产品，包括多条可执行的计算机指令，该产品的计算机指令被执行时，具体用于实现本申请任一实施例提供的应用预加载的方法。

Claims

1.一种应用预加载的方法，其特征在于，适用于电子设备，所述方法包括：

根据当前应用和所述备选应用的相似度，以及所述预测触发事件是否为所述当前应用的互吸互斥信息所指示的大类切换事件，调整所述备选应用的第一预测分值，得到所述备选应用的第二预测分值；其中，所述互吸互斥信息包括应用的名称，应用的大类切换事件，发生大类切换事件前应用的大类以及发生大类切换事件后应用的大类；所述大类包括互吸类、互斥类和其他类；所述大类切换事件为所述当前应用运行期间响应用户操作而触发的事件；

将所述预加载应用加载至电子设备的运行内存。

2.根据权利要求1所述的方法，其特征在于，当前应用和所述备选应用的相似度，根据所述当前应用的嵌入向量和所述备选应用的嵌入向量计算得到。

3.根据权利要求1所述的方法，其特征在于，所述预测触发事件包括，打开应用事件，返回桌面事件，解锁屏幕事件和应用事件。

4.根据权利要求1至3任意一项所述的方法，其特征在于，所述根据当前应用和所述备选应用的相似度，以及所述预测触发事件是否为所述当前应用的互吸互斥信息所指示的大类切换事件，调整所述备选应用的第一预测分值，得到所述备选应用的第二预测分值，包括：

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

利用悬浮球显示所述预加载应用。

6.一种应用预加载的方法，其特征在于，适用于电子设备和服务器，所述方法包括：

所述电子设备向所述服务器发送用户数据和应用使用数据；

所述电子设备根据所述嵌入向量和所述互吸互斥信息执行如权利要求1至5任意一项所述的应用预加载的方法。

7.根据权利要求6所述的方法，其特征在于，所述服务器根据所述用户数据和所述应用使用数据生成所述电子设备的应用的嵌入向量，包括：

所述服务器根据所述应用使用数据生成应用序列；

8.根据权利要求7所述的方法，其特征在于，所述用户数据包括用户的年龄和职业。

9.根据权利要求7或8所述的方法，其特征在于，所述服务器根据所述应用使用数据生成应用序列，包括：

10.根据权利要求9所述的方法，其特征在于，所述服务器利用所述用户群组内的所述应用序列训练语言模型，获得所述电子设备的应用的嵌入向量，包括：

11.根据权利要求10所述的方法，其特征在于，所述服务器利用所述标识码序列训练语言模型，获得所述电子设备的应用的嵌入向量之前，还包括：

12.一种电子设备，其特征在于，包括：一个或多个处理器、存储器；

所述存储器用于存储一个或多个程序；

所述一个或多个处理器用于执行一个或多个程序，使得电子设备执行如权利要求1至11任意一项所述的应用预加载的方法。

13.一种计算机存储介质，其特征在于，用于存储计算机程序，所述计算机程序被执行时，具体用于实现如权利要求1至11任意一项所述的应用预加载的方法。