CN115576621B - 一种应用程序加载方法及电子设备 - Google Patents

Abstract

本申请实施例提供一种应用程序加载方法及电子设备，涉及电子设备领域。将至少一个应用程序加载到虚拟屏上，至少一个应用程序在加载到虚拟屏后，显示屏不显示该至少一个应用程序的界面。在第一时刻接收到该至少一个应用程序中第一应用程序的通知消息。在第二时刻接收到用户启动该第一应用程序的操作，将第一应用程序从虚拟屏切换至显示屏，在显示屏上显示第一应用程序的界面，并显示第一应用程序在虚拟屏上时接收到的通知消息。这样，既缩短了第一应用程序的启动时间，又避免了第一应用程序通知消息的显示时间早于第一应用程序启动时间，实现了用户不感知第一应用程序提前预加载的效果。

Description

一种应用程序加载方法及电子设备

技术领域

本申请涉及电子设备领域，尤其涉及一种应用程序加载方法及电子设备。

背景技术

随着智能手机不断发展，性能不断升级，功能也不断丰富，人们使用智能手机的频率越来越高。一般智能手机通过内部安装的各种应用程序(application，APP)来实现丰富的功能。例如，用户可以通过智能手机上安装的有声书类APP收听有声小说或播客等。又例如，用户可以通过智能手机上安装的导航类APP进行出行导航、查看实时路况等。

目前市场上的智能手机在冷启动应用程序的时候，通常会对该应用程序进行加载，加载完成之后才能显示用户期望的可操作的界面。用户需要等待应用程序加载完成才能对其界面进行操作。一些应用程序加载时长需要数秒，游戏类应用程序加载时长更是长达15秒-30秒，影响用户的体验。

发明内容

本申请实施例提供一种应用程序加载方法及电子设备，实现了应用程序预加载，能够提高应用程序的启动速度，减少用户等待时长；并且实现用户不感知应用程序提前预加载的效果。

为达到上述目的，本申请的实施例采用如下技术方案：

第一方面，提供了一种应用程序加载方法，应用于电子设备，电子设备包括显示屏和虚拟屏，该电子设备安装有多个应用程序，该方法包括：将至少一个应用程序加载到虚拟屏上，至少一个应用程序在加载到虚拟屏后，显示屏不显示该至少一个应用程序的界面。其中，至少一个应用程序包括第一应用程序。在第一时刻接收到第一应用程序的通知消息；即当第一应用程序在虚拟屏上时接收到通知消息。在第二时刻接收到用户启动第一应用程序的操作，将第一应用程序从虚拟屏切换至显示屏，在显示屏上显示第一应用程序的界面，并显示通知消息，通知消息的通知时间为第三时刻。其中，第二时刻晚于第一时刻，第三时刻晚于或等于第二时刻。

在该方法中，第一应用程序提前预加载至虚拟屏，当用户启动第一应用程序时，第一应用程序的界面直接从虚拟屏移至显示屏，缩短了第一应用程序的启动时间。并且，当第一应用程序在虚拟屏上时，缓存接收到的第一应用程序的通知消息，不显示该通知消息，以避免在后台的第一应用程序的信息错误的被用户看到。当用户启动第一应用程序后，再将缓存的第一应用程序的通知消息进行显示，并且第一应用程序的通知消息的通知时间修改为当前时间。这样避免了应用程序通知消息的显示时间早于应用程序启动时间的问题，实现了用户不感知第一应用程序提前预加载的效果。

结合第一方面，在一种实现方式中，在显示屏显示第一应用程序的界面包括：在显示屏显示第一应用程序的窗口启动动效；第一应用程序的窗口启动动效是根据第一应用程序的窗口快照生成的，第一应用程序的窗口快照是第一应用程序的界面加载至虚拟屏时截取并保存的。

这样，实现了第一应用程序启动效果与热启动效果一致。

结合第一方面，在一种实现方式中，在第二时刻接收到用户启动所述第一应用程序的操作之后，在最近任务列表中添加第一应用程序的窗口快照；在第二时刻之前，最近任务列表中不包括第一应用程序的窗口快照。

在该方法中，用户启动第一应用程序前，最近任务列表中不显示第一应用程序的窗口快照，实现用户不感知第一应用程序已预加载。用户启动第一应用程序后，最近任务列表中显示第一应用程序的窗口快照，实现用户正常使用第一应用程序。

结合第一方面，在一种实现方式中，第一应用程序的界面是第一应用程序的主界面或登录界面。

结合第一方面，在一种实现方式中，停止缓存在第二时刻之后接收到的第一应用程序的通知消息。也就是说，在用户启动第一应用程序之后，第一应用程序的窗口通知正常显示。

结合第一方面，在一种实现方式中，在第一时刻接收到第一应用程序的通知消息之后，在第二时刻接收到用户启动所述第一应用程序的操作之前，缓存第一应用程序的通知消息，此时，第一应用程序的通知消息的通知时间为第一时刻；在第二时刻接收到用户启动第一应用程序的操作之后，将第一应用程序的通知消息的通知时间修改为第三时刻并显示第一应用程序的通知消息，第三时刻为当前时刻。

结合第一方面，在一种实现方式中，在第二时刻接收到用户启动所述第一应用程序的操作之后，取消对第一应用程序的声音的管控，允许播放第一应用程序的声音。

当第一应用程序在虚拟屏上时，不允许第一应用程序播放声音，以避免在后台的第一应用程序的声音错误的被用户听到。当用户启动第一应用程序后，允许第一应用程序播放声音，实现用户正常使用第一应用程序。

结合第一方面，在一种实现方式中，在第二时刻接收到用户启动所述第一应用程序的操作之后，停止拦截和保存第一应用程序接收或发送的广播消息。

结合第一方面，在一种实现方式中，在第二时刻接收到用户启动所述第一应用程序的操作之后，去除第一应用程序的预加载标签；预加载标签用于表示应用程序的界面在虚拟屏上。

结合第一方面，在一种实现方式中，接收到用户启动第一应用程序的操作包括：接收到用户在显示屏上对第一应用程序的应用图标的点击操作；或者，接收到用户启动第二应用程序的操作；第二应用程序启动第一应用程序。

结合第一方面，在一种实现方式中，显示屏为电子设备的物理屏幕，显示屏用于显示应用程序的界面；虚拟屏为电子设备的模拟屏幕，虚拟屏上的界面不对用户显示。

结合第一方面，在一种实现方式中，虚拟屏的显示尺寸和分辨率与显示屏相同。

第二方面，提供了一种电子设备，该电子设备具有实现上述第一方面所述的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第三方面，提供了一种电子设备，包括：处理器和存储器；该存储器用于存储计算机执行指令，当该电子设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该电子设备执行如上述第一方面中任一项所述的方法。

第四方面，提供了一种电子设备，包括：处理器；所述处理器用于与存储器耦合，并读取存储器中的指令之后，根据所述指令执行如上述第一方面中任一项所述的方法。

第五方面，提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面中任一项所述的方法。

第六方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面中任一项所述的方法。

第七方面，提供了一种装置(例如，该装置可以是芯片系统)，该装置包括处理器，用于支持电子设备实现上述第一方面中所涉及的功能。在一种可能的设计中，该装置还包括存储器，该存储器，用于保存电子设备必要的程序指令和数据。该装置是芯片系统时，可以由芯片构成，也可以包含芯片和其他分立器件。

其中，第二方面至第七方面中任一种实现方式所带来的技术效果可参见第一方面中不同实现方式所带来的技术效果，此处不再赘述。

附图说明

图1为一种应用程序启动的界面示意图；

图2为一种应用程序启动的界面示意图；

图3为一种应用程序启动的界面示意图；

图4为一种应用程序启动的界面示意图；

图5为一种应用程序启动的界面示意图；

图6为一种应用程序启动的界面示意图；

图7为本申请实施例提供的一种应用程序加载方法所适用的场景示意图；

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

图9为本申请实施例提供的一种系统架构的组成示意图；

图10为本申请实施例提供的一种建立三方特征库的流程图；

图11为本申请实施例提供的另一种建立三方特征库的流程图；

图12为本申请实施例提供的一种应用程序加载画面中预期界面的关键特征的示意图；

图13为本申请实施例提供的另一种建立三方特征库的流程图；

图14为本申请实施例提供的一种加载Activity的流程示意图；

图15为本申请实施例提供的已预加载的应用程序在前台启动的流程示意图；

图16为本申请实施例提供的应用程序加载方法中广播消息处理流程示意图；

图17为本申请实施例提供的应用程序加载方法中通知消息处理流程示意图；

图18A为本申请实施例提供的应用程序加载方法的一种界面实例示意图；

图18B为本申请实施例提供的应用程序加载方法的一种界面实例示意图；

图19为本申请实施例提供的一种电子设备架构图。

具体实施方式

在本申请实施例的描述中，以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请以下各实施例中，“至少一个”、“一个或多个”是指一个或两个以上(包含两个)。术语“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。术语“连接”包括直接连接和间接连接，除非另外说明。“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。

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

通常用户在使用智能手机上安装的应用程序时，需要先通过触摸点击的方式打开手机上的应用程序。在手机接收到用户打开应用程序的操作时，手机需要对应用程序进行加载，当手机将应用程序加载完成之后，用户才能够使用该应用程序。

例如，当用户需要打开智能手机上安装的视频类应用程序，如，“XX视频”应用程序时。如图1所述，用户可以通过点击智能手机桌面中的“XX视频”应用程序的图标101，以打开该“XX”视频。当智能手机接收到用户对“XX视频”应用程序的图标101的点击操作时，智能手机便可以加载启动该“XX视频”应用程序。智能手机加载该“XX视频”应用程序的过程中，如图2所示，智能手机的显示界面中会显示“XX视频”的启动页202(如，开屏广告页，或者图中所示的包含应用程序的图标的页面等)。当智能手机将“XX视频”应用程序加载完成之后，如图3所示，智能手机显示的界面可以从“XX视频”应用程序的启动页202跳转到“XX视频”应用程序的应用页面303(如，该应用的首页)。从而用户可以通过点击“XX视频”的应用页面内的相关内容以观看相关视频内容。例如，如图3所示，智能手机显示的“XX视频”应用程序的应用页面中包括《电影1》、《电视剧2》、《音乐剧3》、《动漫4》等视频内容对应的封面。用户可以通过点击这些封面以使智能手机播放相应的视频内容。例如，当用户点击《电影1》的封面时，智能手机接收到用户的上述操作，便能够播放《电影1》的视频内容以供用户观看。

又例如，当用户需要打开智能手机上安装的游戏类应用程序，如，“XX游戏”应用程序时。如图4所示，用户可以通过点击智能手机桌面中的“XX游戏”应用程序的图标401，以打开“XX游戏”应用程序。当智能手机接收到用户对“XX游戏”应用程序的图标401的点击操作时，手机便可以加载启动该“XX游戏”应用程序。智能手机加载该“XX游戏”应用程序的过程中，如图5所示，智能手机的显示界面中会显示“XX游戏”的启动页502(如，开屏广告页，或者图中所示的包含应用程序的图标的页面等)。当智能手机将“XX游戏”应用程序加载完成之后，如图6所示，智能手机显示的界面可以从“XX游戏”应用程序的启动页502跳转到“XX视频”应用程序的应用页面603(如，该游戏的登陆界面)。从而用户可以通过该登陆界面登陆游戏账号并进入游戏界面。

由以上可以看到，当用户打开智能手机上安装的应用程序时，手机需要加载一定的时长。如，加载该应用程序经过至少一个启动画面之后才能够进入到用户能够进行操作的应用界面(即用户期望的可操作界面)。尤其，当用户打开的应用程序占用资源较多时加载时长会更长。如此，会影响用户在启动应用程序时的使用体验。

为解决上述问题，本申请实施例提供了一种应用程序加载方法，该方法可以应用于电子设备启动应用程序的场景中。

在本申请实施例中，该应用程序加载方法可以包括，在用户使用电子设备的过程中，电子设备可以按照预设的规则来预测用户可能会打开的应用程序，然后将该应用程序预加载到虚拟屏，以使该应用程序能够在虚拟屏中预加载到用户期望的可操作界面(即应用程序启动后进入的能够被用户操作的界面)，之后，在用户启动应用程序时，若该应用程序已经预加载在虚拟屏中，则电子设备可以将该应用程序从虚拟屏中移到主屏(或称为显示屏，即电子设备正常显示画面的实际屏幕，其显示的画面用户可见)中进行显示，以供用户使用该应用程序。

其中，虚拟屏为电子设备的模拟屏幕，是非实体的，具有与电子设备的实际屏幕相同的功能，但是模拟屏幕上的画面不对用户显示。可选地，虚拟屏可以与显示屏相对应，如虚拟屏与显示屏设置相同的分辨率、尺寸等。

例如，电子设备可以按照预设的规则预测用户可能会打开的应用程序，如电子设备预测用户未来一段时间内可能会打开“XX游戏”应用程序，此时电子设备便会采用该应用程序加载方法对“XX游戏”应用程序进行预加载。例如，如图7所示，可以将“XX游戏”应用程序加载到虚拟屏上，以使该应用程序能够在虚拟屏上加载到用户期望的可操作界面701(如图中所示的账号登陆界面)。之后，当用户通过点击“XX游戏”应用程序的图标702以准备启动该“XX游戏”应用程序时，电子设备便可以直接将预加载到虚拟屏上的“XX游戏”应用程序的可操作界面701切换显示在主屏上(如账号登录界面)。

通过该方法，电子设备可以对用户的操作行为进行预测，以在用户启动某个应用程序之前，先对该应用程序进行预加载。从而当用户想要启动相应的应用程序时，电子设备能够直接将相应的应用程序的可操作界面显示在主屏上，从而减小用户启动相应用程序的感知时间(启动应用程序的感知时间，即从用户对应用程序进行启动操作到电子设备主屏显示该应用程序的可操作界面所经历的时间)。如此，能够提高用户启动应用程序时的流畅体验，提高电子设备在用户启动应用程序时的响应速度。

以下，将结合附图对本申请实施例提供的应用程序加载方法进行说明。

在本申请实施例中，上述电子设备可以是手机、平板电脑、手持计算机，PC，蜂窝电话，个人数字助理(personal digital assistant，PDA)，可穿戴式设备(如：智能手表、智能手环)，智能家居设备(如：电视机)，车机(如：车载电脑)，智慧屏，游戏机，智能投影仪，智能电视盒，以及增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备等。本申请实施例对于电子设备的具体设备形态不作特殊限制。

在本申请实施例中，上述电子设备是可以运行操作系统，安装应用程序的电子设备。可选地，电子设备运行的操作系统可以是系统，/>系统，/>系统等。

示例地，以电子设备为手机为例，图8示出了本申请实施例提供的一种电子设备的结构示意图。也即，示例性的，图8所示的电子设备可以是手机。

如图8所示，电子设备可以包括：射频(radio frequency，RF)电路810、存储器820、输入单元830、显示单元840、传感器850、音频电路860、无线保真(wireless fidelity，WiFi)模块870、处理器880、电源890以及蓝牙模块8100等部件。本领域技术人员可以理解，图8中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图8对电子设备的部分构成部件进行具体的介绍：

存储器820可用于存储软件程序以及模块，处理器880通过运行存储在存储器820的软件程序以及模块，从而执行电子设备的各种功能应用以及数据处理。存储器820可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)、引导装载程序(boot loader)等；存储数据区可存储根据电子设备的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器820可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元830可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。具体地，输入单元830可包括触控面板831以及其他输入设备832。触控面板831，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板831上或在触控面板831附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板831可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器880，并能接收处理器880发来的命令并加以执行。具体地，其他输入设备832可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。在本申请实施例中，用户可以通过触控面板831、鼠标或键盘来输入通过电脑的系统打开模拟器中的文件的操作。

显示单元840可用于显示由用户输入的信息或提供给用户的信息以及电子设备的各种菜单。显示单元840可包括显示面板(如显示屏)841，可选的，可以采用液晶显示器(liquid crystal display，LCD)、有机发光二极管(organic light-emitting diode，OLED)等形式来配置显示面板841。进一步的，触控面板831可覆盖显示面板841，当触控面板831检测到在其上或附近的触摸操作后，传送给处理器880以确定触摸事件的类型，随后处理器880根据触摸事件的类型在显示面板841上提供相应的视觉输出。虽然在图8中，触控面板831与显示面板841是作为两个独立的部件来实现电子设备的输入和输入功能，但是在某些实施例中，可以将触控面板831与显示面板841集成而实现电子设备的输入和输出功能。

处理器880是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器820内的软件程序或模块，以及调用存储在存储器820内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。可选的，处理器880可包括一个或多个处理单元；优选的，处理器880可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器880中。

音频电路860可以包括扬声器861和传声器862。通过扬声器861能够播放音频数据，而传声器862则可以用于将声音信号转换为音频数据。

当然，可以理解的，上述图8所示仅仅为终端的设备形态为手机时的示例性说明。若终端是平板电脑，手持计算机，PC，PDA，可穿戴式设备(如：智能手表、智能手环)，智能家居设备(如：电视机)，车机(如：车载电脑)，智慧屏，游戏机，以及AR/VR设备等其他设备形态时，终端的结构中可以包括比图8中所示更少的结构，也可以包括比图8中所示更多的结构，在此不作限制。

以下实施例中的方法均可以在具有上述硬件结构的电子设备中实现。下面将结合附图对本申请实施例进行举例说明。

在本申请实施例中，电子设备可以根据用户的应用程序使用习惯和/或预设的预测规则对应用程序预测和预加载。

示例地，在本申请实施例中，电子设备为了实现上述提供应用程序预加载的方法，可以采用如图9所示的系统架构。如图9所示，该电子设备的系统架构可以包括应用层、系统框架层(framework层)、本地框架(native)以及硬件层。其中，应用层可用于部署能够在电子设备上运行的一个或多个应用程序，例如本申请实施例中，应用层中可以部署有“XX游戏”应用程序，“XX视频”应用程序等。系统框架层中可以部署有实时系统(如称为第一系统)、非实时系统(如称为第二系统)以及三方特征库等。本地框架可以部署采集系统和性能雷达。硬件层可以包括CPU以及存储器等硬件，其中存储器可以包括随机存取存储器(random access memory，RAM)和外部存储器等。

通过非实时系统能够处理对实时性要求不高的操作，即能够在独立进程中进行处理的操作。从而避免所有功能均在系统进程上运行，而造成负荷过高产生卡顿的问题。可选地，非实时系统中可以包括用于校验和构造对相应应用程序进行预加载时所需的参数的预加载模块，用于创建和管理预加载应用程序所需的虚拟屏相关参数的虚拟屏管理模块，用于维护预设的配置参数(如默认预加载时长等参数)的配置管理模块，用于决策是否对某个应用进行预加载的决策模块，用于对当前电子设备所处场景进行识别的场景识别模块，用于对电子设备的负载进行监控的负载监控模块，用于对电子设备中安装的应用程序的相关属性(如应用程序的启动方式、要启动的进程、要启动的界面等启动参数，应用程序的加载特征等)进行管理的应用管理模块等。

通过实时系统能够处理和应用程序运行状态、进程强相关的操作、对实时性要求比较高的操作(例如，预测需要预加载的应用程序、执行应用程序的预加载等操作)，以及与进程管理服务(Activity manager service，AMS)、窗口管理服务(Window managerservice，WMS)、包管理服务(package manger service，PMS)等系统服务强相关的操作。该实时系统可以运行在系统进程(system server)中。可选地，基于上述实时系统可实现的功能，实时系统中可以包括用于对显示窗口进行管理的窗口管理模块，对预加载之后的应用程序的相关消息进行代理的代理模块，用于预测需要进行预加载的应用程序的预测模块，用于对预加载后的应用程序所使用资源进行管控的资源管控模块，用于执行应用程序预加载的预加载管理模块等，用于维护和测试应用程序预加载功能的维测模块等。

作为一种示例，基于如图9所示的系统架构。可以预先建立包括多个应用程序的相关属性特征的三方特征库。该三方特征库中可以包括各应用程序对应的应用类型(如游戏、即时通讯、视频、支付、新闻等应用类型)、应用程序加载所耗系统资源(如CPU负载、内存占用以及耗电量等)、应用程序加载到预期界面(即可操作界面)所耗时间(即应用程序加载时长)等。可选地，可以在云服务器中建立相应的特征库，然后通过云推的方式同步到电子设备的三方特征库中。

示例地，三方特征库中的应用类型可以通过对主流应用程序筛查扫描来采集。

例如，如图10所示，可以先选取主流应用市场中排名前N(即Top N)的应用程序，根据每个应用程序的功能定义(即该应用程序在应用市场中的分类标签)来对相应应用程序的应用类型进行第一次筛选确认。然后，还可以扫描每个应用程序的属性文件(如Manifest文件)，根据属性文件中的参数对相应应用程序的应用类型进行第二次筛选确认。从而确定出选取的N个应用程序分别对应的应用类型。可选地，还可以在第二次筛选确认每个应用程序的应用类型之后，再对每个应用程序进行人工复查(或称为人工校验)以确定出选取的N个应用程序分别对应的应用类型。从而，便可以得到主流的N个应用程序各自的应用类型。之后，可以将得到的N个应用程序各自的应用类型上传到云服务器(即云端)，然后再由云服务器将N个应用程序各自的应用类型同步到电子设备的三方特征库中。可选地，非实时系统中的应用管理模块可以根据电子设备已安装的应用程序，从三方特征库中匹配出各已安装的应用程序对应的应用类型。

示例地，三方特征库中的应用程序加载时长可以通过对主流应用程序的加载画面进行识别来采集。

例如，如图11所示，可以先选取主流应用市场中排名前N(即Top N)的应用程序，然后分别对各个应用程序的加载画面中的预期界面(即加载结束画面)中的关键特征进行定义(通常可以将预期界面中不易随应用程序更新而改变的特征作为关键特征，如账号登录控件、页面选择控件等)。之后，可分别对每个应用程序依次进行冷启动，并对相应应用程序冷启动时的加载画面进行视频录制(录制帧率可以为24帧、60帧等低帧率，也可以是120帧、240帧等高帧率)。然后可对录制的加载画面视频中的每一帧进行识别(可按照从视频的中间帧依次向时间轴两端识别的方式识别每一帧，也可以从第一帧依次识别每一帧，此处不做限制)，当识别到对应应用程序定义的加载结束画面中的关键特征时，便可以以该帧对应的视频时长作为对应应用程序的加载时长。如，以应用程序为“XX游戏”应用程序为例，如图12所示，可以定义该应用程序的加载画面中的预期界面中的关键特征为账号登录控件1201和适龄提示标识1202。则可以对该应用程序进行冷启动，并对该应用程序冷启动时的加载画面进行录制。然后对录制的加载画面中的每一帧进行识别。当识别到如图12所示的账号登录控件1201和适龄提示标识1202时，则可确定出包含该账号登录控件1201和适龄提示标识1202的一帧为预期界面，从而可以以该帧对应的视频时长作为该“XX游戏”应用程序的加载时长。当然，在本申请的其他可能的实施方式中，还可以通过其他方式来采集确定应用程序的加载时长，此处不做限制。

可选地，在对定义的关键特征进行识别确定出加载时长之后，还可以对该应用程序的加载时长进行人工校验。并且针对每个应用程序可以重复多次上述方式以得到相对准确的加载时长。

当得到选取的N个应用程序中分别对应的加载时长之后，可以将得到的N个应用程序各自的加载时长上传到云服务器(即云端)，然后再由云服务器将N个应用程序各自的加载时长同步到电子设备的三方特征库中。可选地，非实时系统中的应用管理模块可以根据电子设备已安装的应用程序，从三方特征库中匹配出各已安装的应用程序对应的加载时长。

示例地，三方特征库中的应用程序加载所耗系统资源可以通过对主流应用程序的加载负载进行获取得到。

例如，如图13所示，可以先选取主流应用市场中排名前N(即Top N)的应用程序，然后分别对每个应用程序依次进行冷启动。在应用程序启动过程中，可以周期性的获取电子设备的CPU负载。然后获取对应应用程序启动后相应进程的进程控制符(processidentifier，PID)，从而获取该应用程序对应的进程的内存占用等负载信息。从而便可得到主流N个应用程序各自的CPU负载、内存占用等加载所耗系统资源。可选地，可以针对每个应用程序重复多次上述方式以得到更加准确的稳定的加载所耗系统资源数据，此处不做限制。之后，可以将得到的N个应用程序各自的加载所耗系统资源上传到云服务器(即云端)，然后再由云服务器将N个应用程序各自的加载所耗系统资源同步到电子设备的三方特征库中。可选地，非实时系统中的应用管理模块可以根据电子设备已安装的应用程序，从三方特征库中匹配出各已安装的应用程序对应的加载所耗系统资源。

在本申请实施例中，基于上述如图9所示的系统架构。电子设备可以通过实时系统中的预测模块对用户在未来一段时间可能会打开的应用程序进行预测。例如，预测模块可以通过高频规律学习模型、上下文规律学习模型等，将输入的应用程序日志转化为规律集作为可能会被用户启动的应用程序的筛选条件，再结合当前场景等特征，通过FP-TREE和序列模式挖掘(PrefixSpan、CM-SPADE等)算法推算出下一个或者下一段时间内用户可能使用的应用程序。

示例地，预测模块可以进行高频行为规律学习，形成用户行为画像。例如，通过高频行为规律学习，得到用户离家时间、到公司时间等，以及得到用户离家后会经常打开哪些应用程序(如导航类应用程序、打车类应用程序等)，到公司后会经常打开哪些应用程序(如打卡应用程序、邮箱类应用程序等)。从而预测模块可以在识别到用户处于离家的场景或到公司的场景时，将学习得到的对应应用程序预测为用户可能会打开的应用程序。可选地，可以周期性的对用户未来可能会打开的应用程序进行预测(可以预测未来一段时间内(如一小时)可能会打开的应用程序)。最终得到的预测结果可以为预测到的要启动的应用程序(即预加载的应用程序)的包名和该应用程序可能会启动的时间段(即可能被用户使用的时间段)。然后可以将预测结果，如预加载的应用程序的包名和其对应的可能被用户使用的时间段发送给预加载模块，以便于预加载模块根据预测结果对相应的应用程序进行预加载启动。

例如，预测模块可以预测未来一小时内可能被用户使用的应用程序为应用程序1和应用程序2，并且，应用程序1可能被用户使用的时间段为早上九点到九点十分，应用程序2可能被用户使用的时间段为早上九点半到十点。此时，预测模块可以将预测出的应用程序1的包名以及对应的可能被用户使用的早上九点到九点十分的时间段，以及将预测出的应用程序2的包名以及对应的可能被用户使用的早上九点半到十点的时间段，发送给预加载模块。

示例地，预测模块还可以进行上下文行为规律学习，以形成用户行为画像。例如，通过上下文行为规律学习，可以得到用户在打开某个应用程序之后经常性会再打开另一应用程序(如用户在打开会议应用程序时，还会再打开录音应用程序等)的上下文习惯。从而预测模块在识别到用户打开了第一应用程序时，便能够将学习得到的上下文习惯中与第一应用程序关联的第二应用程序预测为用户可能会打开的应用程序。

可选地，当预测模块预测到用户可能会打开的应用程序，且预测准确率达到阈值时，预测模块可以主动通知预加载模块对相应的应用程序进行预加载。

或者，预测模块可以为预加载模块提供查询接口，以供预加载模块查询预测到的用户可能会打开的应用程序。从而便于预加载模块对相应的应用程序进行预加载准备。

在一些可能的实施方式中，如图9所示的软件系统还可以包括人工智能(artificial intelligence，AI)模块，以通过人工智能模块对用户在未来一段时间可能打开的应用程序进行预测，从而提高预测应用程序的准确率。可选地，在本申请的其他一些实施例中，还可以只包括AI模块，不包括预测模块，此处不做限制。AI模块预测出的预测结果内容与预测模块可以相同，也包括预测出的未来一段时间内可能被用户使用的应用程序以及对应的可能被用户使用的时间段。

当预加载模块获取到需要预加载的应用程序之后，决策模块可以先根据电子设备当前所处场景，电子设备当前的负载以及要预加载的相应应用程序对应的应用类型、加载时长、加载所耗系统资源等进行综合决策以决定是否需要对相应的应用程序进行预加载。示例地，上述系统架构中的负载监控模块可以实时监控或周期性监控电子设备当前的CPU负载、内存占用以及电量信息等。场景识别模块可以通过注册、回调、广播等现有java或android机制来实时识别或周期性识别电子设备当前的使用场景。如，识别当前电子设备是否充电、是否灭屏、是否被远程控制、是否为首次启动、是否为连续启动、是否为分屏状态、是否设置有多屏、是否为投屏状态、是否进行了用户切换等。而根据前述，应用管理模块中管理有已安装的各应用程序对应的应用类型、加载时长、加载所耗系统资源等。从而决策模块可以分别从负载监控模块、场景识别模块以及应用管理模块获取上述信息，然后根据电子设备当前的负载情况，以及加载相应应用所需时长和所耗系统资源的情况来判断当前电子设备是否满足预加载相应应用程序的条件，然后决策模块还可以根据电子设备当前的场景对是否要预加载相应应用程序进行综合判断。例如，当场景为灭屏时可以不对应用程序进行预加载。又例如，当场景为分屏、多屏或投屏时，则很难确定用户是否需要向往常一样打开某些应用程序，因此此时也可以不对应用程序进行预加载。

当决策模块确定需要对某个应用程序进行预加载时，基于上述如图9所示的系统架构。决策模块可以通知非实时系统的预加载模块对该应用程序进行预加载。从而，预加载模块可以从虚拟屏管理模块获取相应的虚拟屏参数，然后将虚拟屏参数以及要预加载的应用程序的信息传递给实时系统的预加载管理模块。然后，预加载管理模块便可以根据虚拟屏参数以及要预加载的应用程序的信息将相应的应用程序预加载到虚拟屏上。其中，当预加载模块获取虚拟屏参数时，若虚拟屏管理模块中未创建虚拟屏，则虚拟屏管理模块可以先创建虚拟屏，然后再向预加载模块返回相应的虚拟屏参数。需要说明的是，虚拟屏一般与主屏的参数一致，从而使预加载到虚拟屏的应用程序切换显示到主屏时能够适配主屏。

可选地，当相应的应用程序预加载到虚拟屏之后，实时系统中的窗口管理模块可以对虚拟屏中预加载的应用程序的所有窗口显示进行维护，将其代理。例如，使预加载的应用程序的Toast弹窗、Notify通知、游戏助手弹窗等推迟生效。从而避免预加载到虚拟屏的应用程序的弹窗、通知等显示到主屏影响用户正常使用正在使用的应用程序。

可选地，当相应的应用程序预加载到虚拟屏之后，实时系统中的代理模块还可以对虚拟屏中预加载的应用程序启动后接收和发送的广播、其与外界应用的binder通信、其监听的闹钟函数(alarm)消息等消息进行代理，将对应消息缓存起来，当用户对相应应用程序进行了启动操作，应用程序切到主屏显示时，再将还具备时效的消息重新发送或接收。

在本申请实施例中，可以通过资源管控模块对预加载到虚拟屏的应用程序的资源进行管控。例如，可以管控预加载到虚拟屏的应用程序的音频资源，使其输出的音频信息不被电子设备输出，从而避免影响用户正常使用正在使用的应用程序。又例如，可以控制电子设备只绘制预加载到虚拟屏的应用程序的显示画面但不进行渲染，从而减少电子设备的渲染合成压力，避免卡顿。又例如，当预加载到虚拟屏的应用程序为多个时，资源管控模块还可以将预加载的应用程序中会被用户打开的概率降低了的应用程序进行冷冻转储，从而进一步控制电子设备的CPU负载和内存占用。

可选地，当用户对预加载的应用程序中的某个进行了启动操作(如，点击了相应应用程序的图标)，或者其他应用程序调用了预加载的应用程序中的某个时，电子设备便可以将相应的应用程序的显示界面从虚拟屏切换显示到主屏。

例如，当用户点击了相应应用程序的图标时，系统进程可以通知预加载管理模块启动相应的应用程序。从而预加载管理模块可以对相应应用程序是否已经预加载到虚拟屏进行判断，若已经预加载到虚拟屏了，则预加载管理模块可以通知资源管控模块解除对相应应用程序的资源管控，通知窗口管理模块解除对相应应用程序的窗口管理，以及通知代理模块解除对相应应用程序的消息的代理管理。并且，预加载管理模块可以将对应的应用程序从虚拟屏转移到主屏(即当前用于显示画面的屏幕)。

下面结合附图，以电子设备是手机为例，对本申请实施例中的技术方案进行详细介绍。

手机可以预测出一个或多个预加载的应用程序，并将其中的一个或多个加载到虚拟屏上。手机对应用程序进行预加载；即在后台启动该应用程序，并绘制该应用程序的可操作界面(即应用程序启动后进入的能够被用户操作的界面)，比如，主界面、登录界面，将绘制好的可操作界面加载至虚拟屏。在一种示例中，虚拟屏是一个模拟屏幕(比如是一个显示实例(display))，虚拟屏上的界面不对用户显示。显示屏是物理屏幕。虚拟屏与显示屏对应，即虚拟屏与显示屏的尺寸、分辨率均相同。该预加载的应用程序在前台启动时，可以直接将虚拟屏上保存的可操作界面加载至主屏(显示屏)进行显示。当用户启动该应用程序时，由于该应用程序在后台已经启动完成，手机将可操作界面从虚拟屏移至主屏进行显示即可；用户不需要等待应用程序启动过程，就可以对应用程序的界面进行操作。这样就缩短了用户启动应用程序的等待时间，提高了用户体验。

手机预加载应用程序后，会对该已预加载的应用程序进行资源管控。在一种实现方式中，将该应用程序的进程加入后台分组。通常，系统会对应用程序的进程提供多种分组。例如，后台分组(THREAD_GROUP_BACKGROUND)、前台分组(THREAD_GROUP_FOREGROUND)等分组，其中前台分组的优先级高于后台分组。将该已预加载的应用程序的进程加入后台分组，以便系统根据后台进程的策略对该应用程序的进程进行处理。在一种实现方式中，修改该应用程序的进程对应的adj值，以控制该应用程序的进程的优先级。其中，adj值用于标识进程的优先级，adj值越高则优先级越低，相应的进程越容易被系统内存清理掉。示例性的，adj值从小到大分别为：native进程(-1000)，系统进程(-900)，常驻进程(-800)，前台应用(0)，最近到前台显示的应用(50)，可见应用(100)，A Service(500)，可感知进程(700)，BService(800)，无用进程(950)。资源管控模块可以在检测到进程的adj值更新时(如Activity切换、绑定服务、解绑服务以及用户界面便可见等场景下对应进程的adj值会更新)，判断更新adj值的进程是否为预加载到虚拟屏的应用程序的进程，若是则更新该进程的adj值为可感知进程对应的值(比如700)。这样，既不会因该进程的优先级太高，导致占用系统资源；又不会因该进程的优先级太低，而被系统清理掉。在一种实现方式中，禁止将该应用程序的进程绑定到处理器大核上。在一种实现方式中，禁止处理器提频。这样，避免了已预加载的应用程序对手机性能的影响。手机还暂停该已预加载的应用程序与其他应用程序的交互；比如，托管(代理)该已预加载的应用程序发送或接收的广播消息、告警消息(alarm)、Binder等消息。这样，避免了已预加载的应用程序对其他应用程序的影响。手机还隐藏已预加载的应用程序相关的，引起用户感知的窗口、显示信息或声音等；比如，将已预加载的应用程序主界面上的弹窗加载至虚拟屏，缓存已预加载的应用程序的窗口相关的通知，关闭已预加载的应用程序发出的声音等。这样，避免了已预加载的应用程序在后台的运行被用户感知。

本申请实施例提供的应用程序加载方法，当已预加载的应用程序在前台启动，将该应用程序的可操作界面从虚拟屏移至主屏；恢复该已预加载的应用程序与其他应用程序的交互；取消隐藏已预加载的应用程序相关的窗口、显示信息或声音等。这样，该应用程序就可以在前台正常运行。

应用程序的每个界面分别对应一个活动(Activity)，加载应用程序的一个界面即加载该界面对应的Activity。示例性的，上述将该应用程序的可操作界面从虚拟屏移至主屏，即将可操作界面对应的Activity从虚拟屏移至主屏，也就是说，将可操作界面对应的Activity加载至主屏。示例性的，AMS用于管理Activity；比如，确定Activity加载至哪个屏幕(主屏或虚拟屏)。在一种实现方式中，AMS接收到启动Activity的指令后，根据启动Activity的场景确定Activity加载至哪个屏幕。

以加载第一应用的界面为例，启动Activity的场景可以包括：

场景一、预加载第一应用，将第一应用的界面加载至虚拟屏。

示例性的，手机按照预设规则预测用户可能启动的应用程序包括第一应用，对第一应用进行预加载。

在一种实现方式中，非实时系统的决策模块根据预设规则确定对第一应用进行预加载。

示例性的，决策模块确定为第一应用设置预加载标签；预加载标签用于表示应用程序是预加载的应用程序，该应用程序的界面加载至虚拟屏。如果第一应用退出预加载；比如第一应用在前台启动，比如第一应用的进程被杀；则取消第一应用的预加载标签。

决策模块还通知非实时系统的预加载模块对第一应用进行预加载。预加载模块确定将第一应用的界面一加载至虚拟屏；比如，界面一为第一应用的主界面，界面一对应活动1(Activity1)。预加载模块通知AMS启动Activity1。AMS接收到非实时系统的预加载模块发送的启动Activity1的指令，则确定启动Activity1至虚拟屏。AMS通知实时系统的预加载管理模块将Activity1启动至虚拟屏。在该场景，启动第一应用的Activity1的调用者(callerApp)是非实时系统。

场景二、已预加载的第一应用进行应用内界面切换，将切换后的界面加载至虚拟屏。

示例性的，在场景一中，第一应用已经进行预加载，第一应用设置了预加载标签，第一应用的界面一加载至虚拟屏。在一些示例中，已预加载的应用会进行应用内界面切换。比如，根据第一应用预设的启动策略，第一应用启动后，自动由界面一(比如，主界面)切换为界面二(比如，登录界面)。

在一种实现方式中，第一应用的界面一加载至虚拟屏之后，第一应用通知AMS启动Activity2；Activity2是第一应用的界面二对应的Activity。AMS接收到第一应用发送的启动Activity2的指令，根据第一应用的预加载标签确定第一应用是已预加载的应用程序，即确定启动Activity的调用者的界面在虚拟屏上，则确定启动Activity2至虚拟屏。AMS通知实时系统的预加载管理模块将Activity2启动至虚拟屏。在该场景，启动第一应用的Activity2的调用者(callerApp)是第一应用；第一应用是已预加载的应用程序，即启动Activity的调用者的界面在虚拟屏上。其中，预加载标签(flag)用于表示该应用程序为预加载到虚拟屏的应用程序，即表示该应用程序的界面在虚拟屏上。例如，预加载标签为默认值(如0)时表示应用程序不是预加载到虚拟屏的应用程序，预加载标签为指定值(如1)时表示应用程序是预加载到虚拟屏的应用程序。示例性的，应用程序的界面加载至虚拟屏时，将该应用程序的预加载标签(flag)设置为1。

场景三、第二应用是已预加载的应用程序，第二应用启动第一应用，将第一应用的界面加载至虚拟屏。

一个应用程序运行时可以启动另一个应用程序。比如，聊天应用运行时，聊天应用可以启动(拉起)视频应用；比如，购物应用运行时，购物应用可以启动(拉起)支付应用。

示例性的，手机按照预设规则预测用户可能启动的应用程序包括第二应用，对第二应用进行预加载。第二应用设置预加载标签，第二应用的可操作界面(比如桌面或登录界面)加载至虚拟屏；即第二应用为已预加载的应用程序。

在第二应用在后台运行过程中，第二应用启动(拉起)第一应用。在一种实现方式中，第二应用通知AMS启动第一应用的界面。AMS接收到第二应用发送的启动Activity的指令，根据第二应用的预加载标签确定第二应用是已预加载的应用程序，即确定启动Activity的调用者的界面在虚拟屏上，则确定启动第一应用的Activity至虚拟屏。AMS通知实时系统的预加载管理模块将第一应用的Activity启动至虚拟屏。在该场景，启动第一应用的Activity的调用者(callerApp)是第二应用，第二应用是已预加载的应用，即启动Activity的调用者的界面在虚拟屏上。

场景四、第二应用不是已预加载的应用程序，第二应用启动第一应用，将第一应用的界面加载至主屏。

第二应用运行时，第二应用可以启动第一应用。在一种示例中，第二应用不是已预加载的应用程序；比如，第二应用在前台运行，第二应用的界面加载在主屏。在一种实现方式中，第二应用通知AMS启动第一应用的界面。AMS接收到第二应用发送的启动Activity的指令，确定第二应用不存在预加载标签，确定第二应用不是已预加载的应用程序(即启动Activity的调用者的界面不在虚拟屏上)，则确定启动第一应用的Activity至主屏。

在一种示例中，第一应用已预加载，即第一应用为已预加载的应用程序(待启动Activity在虚拟屏上)。比如，AMS根据第一应用的预加载标签确定第一应用的界面在虚拟屏。AMS通知预加载管理模块将虚拟屏上保存的第一应用的最新界面(比如桌面或登录界面)移至主屏。

在另一种示例中，第一应用未进行预加载(待启动Activity不在虚拟屏上)。比如，AMS确定第一应用不存在预加载标签。AMS按照现有技术中常规的冷启动流程启动第一应用。比如，AMS将第一应用的启动界面加载至主屏。

场景五、接收到用户启动第一应用的第一操作，将第一应用的界面加载至主屏。

当用户需要使用第一应用时，可以通过执行第一操作启动第一应用。比如，第一操作包括点击手机桌面上第一应用的应用图标。手机的桌面应用接收到用户在屏幕上点击第一应用的应用图标的操作，确定启动第一应用。启动第一应用Activity的调用者(callerApp)是桌面应用，桌面应用不是预加载的应用程序，即启动Activity的调用者的界面不在虚拟屏上。在一种实现方式中，桌面应用通知AMS启动第一应用的界面。

在一种示例中，第一应用已预加载，即第一应用为已预加载的应用程序(待启动Activity在虚拟屏上)。比如，AMS根据第一应用的预加载标签确定第一应用的界面在虚拟屏。AMS通知预加载管理模块将虚拟屏上保存的第一应用的最新界面(比如桌面或登录界面)移至主屏。

在另一种示例中，第一应用未进行预加载(待启动Activity不在虚拟屏上)。比如，AMS确定第一应用不存在预加载标签。AMS按照现有技术中常规的冷启动流程启动第一应用。比如，AMS将第一应用的启动界面加载至主屏。

在一些实施例中，请参考图14，其示出各个场景中加载第一应用的Activity的流程示意图。如图14所示，手机上启动一个Activity。判断该待启动Activity对应的第一应用是否存在预加载标签，并确定启动Activity的调用者(callerApp)。

如果确定第一应用存在预加载标签，并且启动Activity的调用者(callerApp)为非实时系统，则确定是预加载第一应用的场景(上述场景一)。获取并保存虚拟屏标识，将该Activity加载至该虚拟屏。

如果确定第一应用不存在预加载标签，或者启动Activity的调用者(callerApp)不是非实时系统；判断启动Activity的调用者(callerApp)是否为已预加载的应用程序，即判断启动Activity的调用者的界面是否在虚拟屏上。在一种实现方式中，如果确定调用者存在预加载标签，则确定调用者是已预加载的应用程序。

如果确定启动Activity的调用者是已预加载的应用程序，则确定是已预加载的第一应用进行应用内界面切换(上述场景二)或已预加载的其他应用程序启动第一应用(上述场景三)。将该Activity加载至保存的虚拟屏上。

如果确定启动Activity的调用者不是已预加载的应用程序，则确定是其他应用程序启动第一应用(上述场景四)或用户启动第一应用(上述场景五)。判断待启动Activity是否在虚拟屏上；比如，待启动Activity对应的第一应用已预加载，确定第一应用存在预加载标签，则确定待启动Activity在虚拟屏上。

如果确定待启动Activity在虚拟屏上，即第一应用已预加载，则将保存在虚拟屏上的第一应用对应的Activity移至主屏；即上述实施例所述当已预加载的应用程序在前台启动，将应用程序的可操作界面从虚拟屏移至主屏。进一步的，取消第一应用的预加载标签。

如果确定待启动Activity不在虚拟屏上，即第一应用未进行预加载，则可以按照本领域技术人员可获得的冷启动流程启动Activity。

如前述实施例所述，本申请实施例提供的应用程序加载方法，当已预加载的应用程序在前台启动，将该应用程序的可操作界面从虚拟屏移至主屏后；恢复该已预加载的应用程序与其他应用程序的交互；取消隐藏已预加载的应用程序相关的窗口、显示信息或声音等；以使得第一应用在前台正常运行。

下面结合附图，对已预加载的应用程序在前台启动的流程进行详细介绍。示例性的，以在前台启动第一应用为例。在一种场景中，如上述场景四，在前台运行的第二应用启动(拉起)第一应用。第一应用为已预加载的应用程序，即第一应用的界面已加载至虚拟屏。在前台启动第一应用，即已预加载的应用程序在前台启动。在另一种场景中，如上述场景五，手机接收到用户启动第一应用的第一操作。第一应用为已预加载的应用程序，即第一应用的界面已加载至虚拟屏。在前台启动第一应用，即已预加载的应用程序在前台启动。

示例性，以用户在手机桌面上点击第一应用的应用图标，启动第一应用为例，对本申请实施例提供的应用程序加载方法进行详细介绍。如图15所示，本申请实施例提供的应用程序加载方法可以包括：

S1401、桌面应用接收到用户在手机显示屏上对第一应用的应用图标的点击操作。

在一种示例中，手机的桌面应用接收到用户在手机显示屏上对第一应用的应用图标的点击操作，响应于该点击操作，桌面应用通知AMS启动第一应用的界面。

S1402、桌面应用向AMS发送启动应用程序通知。

启动应用程序通知中包括第一应用的包名。

S1403、AMS接收到启动应用程序通知，向桌面应用发送暂停指示，并向预加载管理模块发送启动界面指示消息。

一方面，AMS向桌面应用发送暂停指示，暂停指示用于指示桌面应用暂停接收用户在手机显示屏上的点击操作。

一方面，AMS向预加载管理模块发送启动界面指示消息，启动界面指示消息用于通知预加载管理模块启动第一应用的Activity。在一种实现方式中，启动界面指示消息包括第一应用的包名。示例性的，参考图14，AMS接收到桌面应用的启动应用程序通知，确定启动第一应用的Activity的调用者是桌面应用，不是非实时系统；并确定桌面应用不存在预加载标签，即确定启动第一应用的Activity的调用者不是已预加载的应用程序。进一步的，根据第一应用存在预加载标签，确定待启动Activity(第一应用的Activity)在虚拟屏上。AMS确定是已预加载的应用程序(第一应用)在前台启动。AMS向预加载管理模块发送启动界面指示消息，即通知预加载管理模块启动第一应用对应的活动(Activity)。在一种实现方式中，第一应用预加载时保存了第一应用与预加载至虚拟屏的Activity之间的对应关系。AMS可以根据第一应用的包名获取对应的已预加载至虚拟屏的Activity的标识。

S1404、桌面应用接收到暂停指示，暂停接收用户在手机显示屏上的点击操作。

比如，桌面应用接收到暂停指示，暂停(比如，暂停0.1ms)接收用户在手机显示屏上的点击操作。这样，避免了多个点击操作并发，引起处理失败。

S1405、预加载管理模块接收启动界面指示消息，确定启动第一应用的界面。

预加载管理模块根据启动界面指示消息获取第一应用的包名；确定启动第一应用的Activity。

可选的，预加载管理模块根据第一应用的包名判断第一应用是否已预加载。在一种实现方式中，预加载管理模块如果确定第一应用存在预加载标签，则确定该应用程序已预加载，即第一应用的Activity在虚拟屏。

S1406、预加载管理模块向资源管控模块发送解除管控消息。

解除管控消息用于通知取消对第一应用对应的进程进行资源管控；其中，解除管控消息包括第一应用的包名。

S1407、资源管控模块接收解除管控消息，取消对第一应用对应的进程进行资源管控。

资源管控模块接收解除管控消息，根据解除管控消息获取第一应用的包名，取消对第一应用对应的进程进行资源管控。

在一种实现方式中，将第一应用的进程加入前台分组。这样，系统可以根据前台进程的策略对第一应用的进程进行资源(比如CPU资源、内存资源等)分配。

在一种实现方式中，取消对第一应用的进程的adj值的管控。即按照系统策略(比如安卓原生策略)分配第一应用的进程的adj值。

在一种实现方式中，不再禁止将该应用程序的进程绑定到处理器大核上。

在一种实现方式中，不再禁止处理器提频。

S1408、预加载管理模块向窗口启动模块发送启动动效指示消息。

可选的，预加载管理模块向窗口启动模块发送启动动效指示消息。启动动效指示消息用于指示窗口启动模块显示第一应用的窗口启动动效；其中包括第一应用的包名。

S1409、窗口启动模块接收启动动效指示消息，显示第一应用的窗口启动动效。

在一种实现方式中，第一应用预加载至虚拟屏时，截取并保存第一应用的窗口快照。该第一应用的窗口界面是用户的可操作性界面，比如主界面、登录界面。

窗口启动模块接收到启动动效指示消息，根据启动动效指示消息获取第一应用的包名，根据第一应用的包名获取第一应用的Activity预加载至虚拟屏时保存的第一应用的窗口快照，并根据第一应用的窗口快照制作窗口启动动效。在一种示例中，该窗口启动动效为第一应用热启动时的窗口启动动效；比如，窗口大小从小变大。

S1410、预加载管理模块向代理模块发送第一解除代理指示消息。

第一解除代理指示消息用于指示代理模块解除对广播消息的代理(托管)；其中包括第一应用的包名。

S1411、代理模块接收到第一解除代理指示消息，解除对第一应用的广播消息进行代理。

在第一应用的Activity预加载至虚拟屏期间，第一应用接收的广播消息和发送的广播消息被拦截并托管到代理模块。代理模块保存了第一应用的Activity在虚拟屏上时，第一应用接收和发送的广播消息。一种实现方式中，代理模块接收到第一解除代理指示消息，根据第一解除代理指示消息获取第一应用的包名；并获取第一应用的Activity在虚拟屏上时第一应用接收和发送的广播消息。代理模块根据预设的代理规则对保存的广播消息进行处理(丢弃或发送给应用程序)。代理规则包括，根据广播消息类型、时效性等丢弃或保留广播消息。

示例性的，代理模块保存了第一应用的广播接收队列和广播发送队列；其中，广播接收队列包括第一应用的Activity在虚拟屏上时第一应用接收的广播消息，广播发送队列包括第一应用的Activity在虚拟屏上时第一应用发送的广播消息。代理模块接收到第一解除代理指示消息后，获取保存的第一应用的广播接收队列和广播发送队列。如图16所示，代理模块依次从广播接收队列中获取一条广播消息，根据配置的代理规则对该广播消息进行处理。如果该广播消息有效，则发送给第一应用；如果该广播消息已失效，则丢弃。如果广播接收队列中不存在广播消息，依次从广播发送队列中获取一条广播消息。根据配置的代理规则对广播消息进行处理。如果该广播消息有效，则发送给对应的应用程序；如果该广播消息已失效，则丢弃。

代理模块接收到第一解除代理指示消息，停止对第一应用的广播消息进行代理；即停止拦截并托管第一应用接收的广播消息和发送的广播消息。

S1412、预加载管理模块通知第一应用将第一应用的活动(Activity)从虚拟屏移至主屏。

S1413、第一应用将预加载至虚拟屏的活动(Activity)移至主屏，并去除预加载标签。

在一种实现方式中，第一应用获取虚拟屏标识。并根据第一应用的包名从虚拟屏获取对应的Activity，对该Activity进行绘制渲染，并移至主屏。

进一步的，第一应用去除保存的预加载标签。比如，将预加载标签设置为0。

S1414、预加载管理模块向窗口管理模块发送第二解除代理指示消息。

第二解除代理指示消息用于指示窗口管理模块解除对通知消息的代理；其中包括第一应用的包名。

S1415、窗口管理模块接收到第二解除代理指示消息，解除对第一应用的通知消息的代理。

在第一应用的Activity预加载至虚拟屏期间，在第一时刻接收到第一应用的通知消息，第一应用的通知消息被缓存，不进行显示。在第二时刻，用户启动第一应用。如图17所示，窗口管理模块接收到第二解除代理指示消息，在第三时刻，根据第一应用的包名获取缓存的第一应用对应的通知消息，将该通知消息的通知时间修改为当前时刻(第三时刻)，并显示该通知消息。

示例性的，第一应用为“XX游戏”，“XX游戏”在第一时间(比如，13时08分24秒)被预加载。在第一时刻(比如，13时09分15秒)，“XX游戏”产生通知消息“今晚8点发布新地图”。该通知消息被窗口管理模块缓存，不进行显示。示例性的，如图18A所示，在13时09分19秒，手机显示通知消息窗口，通知消息窗口中显示的通知消息列表包括“聊天”应用、“导航”应用和“音乐”应用的通知消息，不包括“XX游戏”的通知消息“今晚8点发布新地图”。窗口管理模块接收到第二解除代理指示消息，根据第一应用的包名获取保存的第一应用的通知消息，将第一应用的通知消息的消息时间修改为当前时刻。在一种实现方式中，窗口管理模块管理通知消息队列，通知消息队列中按照消息时间从先到后的顺序保存应用程序的通知消息。窗口管理模块接收到第二解除代理指示消息后，将第一应用的通知消息移至当前通知消息队列的尾部。

示例性的，在第二时刻(比如，13时10分17秒)，“XX游戏”在前台启动。在第三时刻，窗口管理模块接收到第二解除代理指示消息，将“XX游戏”的通知消息“今晚8点发布新地图”的消息时间修改为第三时刻。其中，第三时刻晚于或等于第二时刻；以第三时刻等于第二时刻为例，将“XX游戏”的通知消息“今晚8点发布新地图”的消息时间修改为13时10分17秒。在第四时刻(比如，13时13分20秒)，手机接收到用户查看通知消息列表的操作，显示通知消息列表。通知消息列表中包括“XX游戏”的通知消息“今晚8点发布新地图”，显示的该通知消息的时间为第三时刻。示例性的，如图18B所示，在13时13分20秒，手机显示通知消息窗口，通知消息窗口中显示的通知消息列表包括“XX游戏”的通知消息“今晚8点发布新地图”，显示的该通知消息的消息时间为“3分钟前”。

窗口管理模块接收到第二解除代理指示消息，停止对第一应用的通知消息进行代理；即停止缓存第一应用的通知消息。

需要说明的是，本申请实施例并不限定上述预加载管理模块分别向资源管控模块、窗口启动模块、代理模块、第一应用和窗口管理模块发送消息的先后顺序。即不限制上述S1406、S1408、S1410、S1412和S1414执行的先后顺序。

S1416、桌面应用向AMS发送显示应用程序界面通知。

在一种实现方式中，桌面应用在S1404接收到暂停指示后，向AMS发送显示应用程序界面通知，其中包括第一应用的包名。

在一种实现方式中，桌面应用在S1404接收到暂停指示后，暂停接收用户在手机显示屏上的点击操作。经过预设时长，结束暂停接收用户在手机显示屏上的点击操作之后，即恢复接收用户在手机显示屏上的点击操作之后，向AMS发送显示应用程序界面通知，其中包括第一应用的包名。

S1417、AMS向预加载管理模块发送显示应用界面指示消息。

AMS接收到显示应用程序界面通知，获取第一应用的包名；并向预加载管理模块发送显示应用界面指示消息。显示应用界面指示消息用于通知预加载管理模块显示第一应用的界面。在一种实现方式中，显示应用界面指示消息包括第一应用的包名。

S1418、预加载管理模块向最近任务管理模块发送恢复显示指示消息。

恢复显示指示消息用于指示在最近任务列表中恢复显示第一应用的窗口快照。在一种实现方式中，恢复显示指示消息包括第一应用的包名。

S1419、最近任务管理模块接收到恢复显示指示消息，在最近任务列表中恢复显示第一应用的窗口快照。

在一种实现方式中，最近任务管理模块接收到恢复显示指示消息，获取第一应用的包名，将第一应用的窗口快照移动至最近任务列表的头部或末尾(表示最近的一个)。允许在最近任务列表中显示第一应用的窗口快照。

S1420、AMS向第一应用发送显示界面指示消息。

AMS接收到显示应用程序界面通知，获取第一应用的包名；并向第一应用发送显示界面指示消息。

需要说明的是，本申请并不限制S1417与S1420执行的先后顺序。即AMS可以先向预加载管理模块发送显示应用界面指示消息，再向第一应用发送显示界面指示消息；或者先向第一应用发送显示界面指示消息，再向预加载管理模块发送显示应用界面指示消息；或者二者同时发送。

S1421、第一应用接收到显示界面指示消息，将主屏上的第一应用的活动(Activity)显示在显示屏上。

S1422、第一应用取消对声音的管控，允许播放声音。

本申请实施例提供的应用程序加载方法，当第一应用在前台启动时，如果第一应用是已预加载的应用程序，将保存在虚拟屏上的第一应用的可操作界面移至主屏；缩短了第一应用的启动时间。并且，当第一应用在前台启动时，恢复第一应用与其他应用程序的消息交互；取消隐藏第一应用相关的窗口、显示信息及声音等。这样，第一应用就可以在前台正常运行。

可以理解的是，本申请实施例提供的电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

本申请实施例可以根据上述方法示例对上述电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在一种示例中，请参考图19，其示出了上述实施例中所涉及的电子设备的一种可能的结构示意图。该电子设备1500包括：处理单元1510、存储单元1520和显示单元1530。

其中，处理单元1510，用于对电子设备1500的动作进行控制管理。存储单元1520用于保存电子设备1500的程序代码和数据。处理单元1510调用存储单元1520存储的程序代码，以执行以上方法实施例中的各个步骤。例如，将应用程序的界面从虚拟屏移动至主屏。例如，恢复已预加载的应用程序与其他应用程序的交互；取消隐藏已预加载的应用程序相关的窗口、显示信息或声音等。

显示单元1530用于显示电子设备1500的界面。例如，显示第一应用的界面。

当然，上述电子设备1500中的单元模块包括但不限于上述处理单元1510、存储单元1520和显示单元1530。比如，电子设备1500中还可以包括通信单元1540。通信单元1540用于支持电子设备1500与其他设备进行通信。

其中，处理单元1510可以是处理器或控制器，例如可以是中央处理器(centralprocessing unit，CPU)，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(fieldprogrammable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。存储单元1520可以是存储器。显示单元1530可以是显示屏等。通信单元1540可以包括移动通信单元和/或无线通信单元。

例如，处理单元1510为处理器(如图8所示的处理器880)，存储单元1520可以为存储器(如图8所示的存储器820)，显示单元1530可以为显示屏(如图8所示的显示单元840)。通信单元1540可以包括移动通信单元(如图8所示的RF电路810)和无线通信单元(如图8所示的WiFi模块870)。本申请实施例所提供的电子设备1500可以为图8所示的电子设备。其中，上述处理器、存储器、显示屏、移动通信单元、无线通信单元等可以连接在一起，例如通过总线连接。处理器调用存储器存储的程序代码，以执行以上方法实施例中的各个步骤。

本申请实施例还提供一种芯片系统，该芯片系统包括至少一个处理器和至少一个接口电路。处理器和接口电路可通过线路互联。例如，接口电路可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路可用于向其它装置(例如处理器)发送信号。示例性的，接口电路可读取存储器中存储的指令，并将该指令发送给处理器。当所述指令被处理器执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当所述计算机指令在上述电子设备上运行时，使得该电子设备执行上述方法实施例中手机执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例中手机执行的各个功能或者步骤。

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

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

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

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

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

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

Claims (14)

1.一种应用程序加载方法，其特征在于，应用于电子设备，所述电子设备包括显示屏和虚拟屏，所述电子设备安装有多个应用程序，所述方法包括：

将至少一个应用程序加载到所述虚拟屏上，所述至少一个应用程序在加载到所述虚拟屏后，所述显示屏不显示所述至少一个应用程序的界面，所述至少一个应用程序包括第一应用程序；

在第一时刻接收到所述第一应用程序的通知消息；

在第二时刻接收到用户启动所述第一应用程序的操作；

将所述第一应用程序从所述虚拟屏切换至所述显示屏，在所述显示屏上显示所述第一应用程序的窗口启动动效，并显示所述通知消息，所述通知消息的通知时间为第三时刻；所述第二时刻晚于所述第一时刻，所述第三时刻晚于或等于所述第二时刻。

2.根据权利要求1所述的方法，其特征在于，所述第一应用程序的窗口启动动效是根据所述第一应用程序的窗口快照生成的，所述第一应用程序的窗口快照是所述第一应用程序的界面加载至所述虚拟屏时截取并保存的。

3.根据权利要求2所述的方法，其特征在于，在第二时刻接收到用户启动所述第一应用程序的操作之后，所述方法还包括：

在最近任务列表中添加所述第一应用程序的窗口快照；在所述第二时刻之前，所述最近任务列表中不包括所述第一应用程序的窗口快照。

4.根据权利要求1-3任意一项所述的方法，其特征在于，所述第一应用程序的界面是所述第一应用程序的主界面或登录界面。

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

停止缓存在所述第二时刻之后接收到的所述第一应用程序的通知消息。

6.根据权利要求1-5任意一项所述的方法，其特征在于，

在第一时刻接收到所述第一应用程序的通知消息之后，在第二时刻接收到用户启动所述第一应用程序的操作之前，所述方法还包括：

缓存所述第一应用程序的通知消息，所述第一应用程序的通知消息的通知时间为所述第一时刻；

在第二时刻接收到用户启动所述第一应用程序的操作之后，所述方法还包括：

将所述第一应用程序的通知消息的通知时间修改为第三时刻，所述第三时刻为当前时刻。

7.根据权利要求1所述的方法，其特征在于，在第二时刻接收到用户启动所述第一应用程序的操作之后，所述方法还包括：

取消对所述第一应用程序的声音的管控，允许播放所述第一应用程序的声音。

8.根据权利要求1所述的方法，其特征在于，在第二时刻接收到用户启动所述第一应用程序的操作之后，所述方法还包括：

停止拦截和保存所述第一应用程序接收或发送的广播消息。

9.根据权利要求1-8任意一项所述的方法，其特征在于，在第二时刻接收到用户启动所述第一应用程序的操作之后，所述方法还包括：

去除所述第一应用程序的预加载标签；所述预加载标签用于表示应用程序的界面在虚拟屏上。

10.根据权利要求1-9任意一项所述的方法，其特征在于，所述接收到用户启动所述第一应用程序的操作包括：

接收到用户在所述显示屏上对所述第一应用程序的应用图标的点击操作；或者，

接收到用户启动第二应用程序的操作；所述第二应用程序启动所述第一应用程序。

11.根据权利要求1-10任意一项所述的方法，其特征在于，所述显示屏为所述电子设备的物理屏幕，所述显示屏用于显示应用程序的界面；所述虚拟屏为所述电子设备的模拟屏幕，所述虚拟屏上的界面不对用户显示。

12.根据权利要求11所述的方法，其特征在于，所述虚拟屏的显示尺寸和分辨率与所述显示屏相同。

13.一种电子设备，其特征在于，所述电子设备包括：处理器、存储器和显示屏；所述处理器与所述存储器和所述显示屏耦合；所述存储器用于存储计算机程序代码；所述计算机程序代码包括计算机指令，当所述处理器执行上述计算机指令时，使得所述电子设备执行如权利要求1-12任意一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-12任意一项所述的方法。