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

1.本技术涉及电子设备领域，尤其涉及一种应用程序加载方法及电子设备。


背景技术：

2.随着智能手机的不断发展，性能不断升级，功能也不断丰富，人们使用智能手机的频率越来越高。一般智能手机通过内部安装的各种应用程序(application，app)来实现丰富的功能。例如，用户可以通过智能手机上安装的有声书类app收听有声小说或播客等。又例如，用户可以通过智能手机上安装的导航类app进行出行导航、查看实时路况等。
3.目前市场上的智能手机在冷启动应用程序的时候都会等待一段时间，等智能手机将该应用程序加载完成之后才能显示到用户期望的可操作的界面。其中游戏类应用程序的启动等待时间更是长达15-30秒，影响用户的体验。


技术实现要素：

4.本技术提供一种应用程序加载方法及电子设备，解决了用户打开常用应用程序时需要等待应用程序加载的问题。
5.为了达到上述目的，本技术采用如下技术方案：
6.第一方面，本技术提供一种应用程序加载方法，其特征在于，应用于电子设备，电子设备包括显示屏和虚拟屏，电子设备安装有多个应用程序，方法包括：预测出一个或多个预加载应用程序；对一个或多个预加载应用程序进行校验，将校验通过的预加载应用程序添加到预加载准备队列，校验通过的预加载应用程序中包括第一应用程序；将预加载准备队列中的第一应用程序加载到虚拟屏上；在虚拟屏上运行第一应用程序到第一应用程序的第一界面，第一应用程序在加载到虚拟屏后，显示屏不显示第一应用程序的第一界面；在用户启动第一应用程序时，将第一应用程序从虚拟屏切换至显示屏，并在显示屏上显示第一界面。
7.采用上述技术方案，电子设备可以对用户的操作行为进行预测，以在用户启动某个应用程序之前，先对该应用程序进行预加载。从而当用户想要启动相应的应用程序时，电子设备能够直接将相应的应用程序的可操作界面显示在主屏上，从而减小用户启动相应用程序的感知时间(启动应用程序的感知时间，即从用户对应用程序进行启动操作到电子设备主屏显示该应用程序的可操作界面所经历的时间)。如此，能够提高用户启动应用程序时的流畅体验，提高电子设备在用户启动应用程序时的响应速度。
8.在一种可能的实现方式中，显示屏为电子设备的实际屏幕，显示屏显示的画面用户可见，虚拟屏为电子设备的模拟屏幕，虚拟屏显示的画面用户不可见。
9.其中，对于应用程序的加载而言，虚拟屏和显示屏没有区别，应用程序均能够通过系统的启动进程正常的加载到虚拟屏和显示屏上。只是虚拟屏为模拟屏幕其上的画面用户不可见。
10.在另一种可能的实现方式中，虚拟屏与显示屏对应。
11.示例地，虚拟屏和显示屏对应可以是：分辨率、尺寸等一致。
12.在另一种可能的实现方式中，第一界面为登陆界面和/或主界面。
13.即，第一界面可以是应用程序冷启动后，在无用户操作的情况下应用程序最终停留的界面。
14.在另一种可能的实现方式中，对所述一个或多个预加载应用程序进行校验，将校验通过的预加载应用程序添加到预加载准备队列，包括：对预加载应用程序分别进行入参合法性校验；遍历预加载应用程序中入参合法性校验通过的应用程序，以确定出准备预加载的应用程序；将准备预加载的应用程序添加到预加载准备队列中。
15.如此，能够先对预测出的需要预加载的应用程序进行合法性校验以及进行筛选。然后对校验通过的应用程序进行判断从而确定出可以预加载的准备预加载的应用程序，以将这些应用程序加载到虚拟屏上，从而避免将所有需要预加载的应用程序均加载到虚拟屏上导致加载的应用程序较多影响电子设备正常使用。
16.在另一种可能的实现方式中，遍历预加载应用程序中入参合法性校验通过的应用程序，以确定出准备预加载的应用程序，包括：对于每一个入参合法性校验通过的预加载应用程序，在满足以下条件时，确定该入参合法性校验通过的预加载应用程序为准备预加载的应用程序；上述条件包括：确定该入参合法性校验通过的预加载应用程序已安装；和/或，确定该入参合法性校验通过的预加载应用程序不在预加载准备队列中；和/或，确定当前正在预加载的应用程序的数量以及准备预加载的应用程序的数量未超过预设数量；和/或，确定该入参合法性校验通过的预加载应用程序不是正在预加载的应用程序、不是已经预加载完成的应用程序、也不是已经运行在前台的应用程序。
17.如此，能够依次对校验通过的应用程序进行判断，当确定可以将其预加载时，将对应的应用程序加入到队列中以等待加载到虚拟屏。例如，能够避免将未安装的应用程序、已处于预加载准备队列中的应用程序、已经正在预加载的应用程序、已经预加载完成的应用程序以及已经运行在前台的应用程序等不需要预加载的应用程序加载到虚拟屏上。
18.在另一种可能的实现方式中，将准备预加载的应用程序添加到预加载准备队列中，包括：判断准备预加载的应用程序的及时性，其中及时性用于表征准备预加载的应用程序的预加载紧急程度，及时性包括紧急和非紧急；当准备预加载的应用程序的及时性为紧急时，添加准备预加载的应用程序到预加载准备队列中的队首；当准备预加载的应用程序的及时性为非紧急时，添加准备预加载的应用程序到预加载准备队列中的队尾。
19.如此，能够将相对紧急的应用程序放置在队首以便于后续提前将相对紧急的应用程序加载到虚拟屏上。
20.在另一种可能的实现方式中，判断准备预加载的应用程序的及时性，包括：判断当前时间到达准备预加载的应用程序对应的被使用时间段所需时间是否小于或等于预设时间阈值；若是，则确定准备预加载的应用程序的及时性为紧急；若否，则确定准备预加载的应用程序的及时性为非紧急。
21.如此，将被使用时间段与当前时间比较接近的应用程序作为及时性为紧急的应用程序，能够避免因未及时加载该应用程序，而导致其加载到虚拟屏时当前时间已超过其被使用时间段造成的无效预加载。
22.在另一种可能的实现方式中，预测出一个或多个预加载应用程序时还预测出所述
预加载应用程序对应的被使用时间段，对预加载应用程序分别进行入参合法性校验，包括：分别判断当前时间是否已经晚于预加载应用程序对应的被使用时间段的末端时刻；若否，则预加载应用程序入参合法性校验通过；若是，则预加载应用程序入参合法性校验不通过。
23.如此，能够筛选出已经过了被使用时间段的应用程序，这些应用程序加载到虚拟屏后短期内已不会再被用户启动，因此能够避免将这些应用程序加载到虚拟屏而造成无效加载。
24.在另一种可能的实现方式中，将第一应用程序加载到虚拟屏上，包括：获取预加载准备队列中的第一应用程序；获取虚拟屏参数以及第一应用程序的启动参数，虚拟屏参数用于标识虚拟屏；根据虚拟屏参数和启动参数启动第一应用程序到虚拟屏上。
25.如此，能够根据预加载准备队列依次将各准备预加载的应用程序加载到虚拟屏。
26.在另一种可能的实现方式中，预先存储有已安装的各应用程序分别对应的加载所需时长；在获取虚拟屏参数以及第一应用程序的启动参数之前，方法还包括：获取第一应用程序对应的加载所需时长；根据当前时间和加载所需时长，确定第一应用程序从当前时间开始预加载对应的预加载完成时的时间；确定预加载完成时的时间未超过第一应用程序对应的被使用时间段。
27.如此，能够判断出该应用程序加载到虚拟屏完成时是否已经超出其被使用时间段，从而避免将加载完成时已超过被使用时间段的应用程序加载到虚拟屏造成无效预加载。
28.在另一种可能的实现方式中，预先存储有已安装的各应用程序分别对应的加载时所耗系统资源；在获取虚拟屏参数以及第一应用程序的启动参数之前，方法还包括：获取第一应用程序对应的加载时所耗系统资源；根据当前电子设备的系统资源和加载时所耗系统资源，确定当前电子设备的系统资源支持加载第一应用程序。
29.如此，能够判断出该应用程序被加载到虚拟屏时，电子设备的系统资源是否能够支持。从而避免系统资源无法支持时加载该应用程序到虚拟屏到至电子设备卡顿。
30.在另一种可能的实现方式中，在获取虚拟屏参数以及第一应用程序的启动参数之前，方法还包括：确定当前没有正在预加载的应用程序。
31.如此，能够避免当前存在正在预加载的应用程序时加载该应用程序导致加载冲突。
32.在另一种可能的实现方式中，在根据虚拟屏参数和启动参数启动第一应用程序到虚拟屏上之前，方法还包括：确定虚拟屏参数标识的虚拟屏存在。
33.如此，能够避免虚拟屏意外关闭或注销时将该应用程序向虚拟屏加载而出错。
34.在另一种可能的实现方式中，在根据虚拟屏参数和启动参数启动第一应用程序到虚拟屏上之前，方法还包括：确定虚拟屏参数标识的虚拟屏上的应用程序数量未达到阈值。
35.如此，能够避免加载到虚拟屏上的应用程序过多导致系统压力过大，造成电子设备卡顿。
36.在另一种可能的实现方式中，在获取虚拟屏参数以及第一应用程序的启动参数之后，方法还包括：将第一应用程序从预加载准备队列中移除。
37.如此，能够避免电子设备重复将该应用程序向虚拟屏加载。
38.在另一种可能的实现方式中，第一应用程序为预加载准备队列中位于队首的一个
应用程序。
39.如此，能够利用预加载准备队列中应用程序的排序来决定各应用程序被预加载的先后，从而便于将相对紧急的应用程序提前加载到虚拟屏。
40.在另一种可能的实现方式中，电子设备包括预加载模块、决策模块、进程管理服务以及预加载管理模块；对一个或多个预加载应用程序进行校验，将校验通过的预加载应用程序添加到预加载准备队列，包括：预加载模块对需要预加载的应用程序分别进行入参合法性校验；对于每一个入参合法性校验通过的所述预加载应用程序，在预加载模块确定入参合法性校验通过的预加载应用程序为准备预加载的应用程序时，将入参合法性校验通过的预加载应用程序添加到预加载准备队列中，发送第一消息到消息队列；将第一应用程序加载到虚拟屏上，包括：决策模块获取消息队列中的一条第一消息；决策模块获取预加载准备队列中的第一应用程序；决策模块获取虚拟屏参数以及第一应用程序的启动参数，虚拟屏参数用于标识虚拟屏；决策模块向进程管理服务发送启动第一应用程序的请求，请求包括启动参数和虚拟屏参数；进程管理服务根据启动参数和虚拟屏参数启动第一应用程序到虚拟屏上。
41.如此，通过消息队列的形式触发决策模块对相应应用程序加载到虚拟屏上，能够实现多线程处理，提高处理效率。
42.在另一种可能的实现方式中，在进程管理服务根据启动参数和虚拟屏参数启动第一应用程序到虚拟屏上之前，方法还包括：进程管理服务向预加载管理模块发送上述请求；预加载管理模块根据虚拟屏参数确定虚拟屏存在；预加载管理模块确定虚拟屏参数标识的虚拟屏上的应用程序数量未达到阈值；预加载管理模块向进程管理服务发送确定启动第一应用程序的指示。
43.如此，能够通过预加载管理模块对将应用程序加载到虚拟屏上时的加载环境进行判断，从而提高应用程序加载到虚拟屏上的成功率。
44.在另一种可能的实现方式中，电子设备还包括应用管理模块和负载监控模块，所述应用管理模块预先存储有已安装的各应用程序分别对应的加载时所耗系统资源，所述负载监控模块用于周期性或实时检测所述电子设备的系统资源；在决策模块获取虚拟屏参数以及第一应用程序的启动参数之前，方法还包括：决策模块从应用管理模块获取第一应用程序对应的加载时所耗系统资源，以及从负载监控模块获取当前电子设备的系统资源；决策模块根据当前电子设备的系统资源和加载时所耗系统资源，确定当前电子设备的系统资源支持加载第一应用程序。
45.如此，能够在当前系统资源支持加载该应用程序时再将该应用程序加载到虚拟屏上，从而避免加载应用程序到虚拟屏时由于系统资源不支持而导致电子设备卡顿。
46.在另一种可能的实现方式中，方法还包括：决策模块根据当前电子设备的系统资源和加载时所耗系统资源，确定当前电子设备的系统资源不支持加载第一应用程序；决策模块向消息队列发送第一消息，并重新获取消息队列中的一条第一消息。
47.如此，能够在决策模块重新循环以加载新的应用程序时保证消息队列中的消息数量与预加载准备队列中应用程序数量一致，从而避免预加载准备队列中的应用程序被漏加载。
48.在另一种可能的实现方式中，消息队列中的第一消息的数量与预加载准备队列中
的准备预加载的应用程序数量对应。
49.如此，能够避免因决策模块根据消息队列中的消息来触发应用程序的加载而导致预加载准备队列中的应用程序被漏加载。
50.第二方面，本技术实施例提供一种电子设备，包括：处理器，用于存储该处理器可执行指令的存储器。该处理器被配置为执行上述指令时，使得该电子设备实现如第一方面或第一方面的可能的实现方式中任一项所述的应用程序加载方法。
51.第三方面，本技术实施例提供一种计算机可读存储介质，其上存储有计算机程序指令。当计算机程序指令被电子设备执行时，使得电子设备实现如第一方面或第一方面的可能的实现方式中任一项所述的应用程序加载方法。
52.第四方面，本技术实施例提供一种计算机程序产品，包括计算机可读代码，当所述计算机可读代码在电子设备中运行时，使得电子设备实现如第一方面或第一方面的可能的实现方式中任一项所述的应用程序加载方法。
53.应当理解的是，上述第二方面至第四方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
54.图1为现有技术提供的一种应用程序启动的界面示意图；
55.图2为现有技术提供的另一种应用程序启动的界面示意图；
56.图3为现有技术提供的另一种应用程序启动的界面示意图；
57.图4为现有技术提供的另一种应用程序启动的界面示意图；
58.图5为现有技术提供的另一种应用程序启动的界面示意图；
59.图6为现有技术提供的另一种应用程序启动的界面示意图；
60.图7为本技术实施例提供的一种应用程序加载方法应用时的场景示意图；
61.图8为本技术实施例提供的一种电子设备的结构示意图；
62.图9为本技术实施例提供的一种系统架构的组成示意图；
63.图10为本技术实施例提供的一种建立三方特征库的流程图；
64.图11为本技术实施例提供的另一种建立三方特征库的流程图；
65.图12为本技术实施例提供的一种应用程序加载画面中预期界面的关键特征的示意图；
66.图13为本技术实施例提供的另一种建立三方特征库的流程图；
67.图14为本技术实施例提供的一种用户行为画像的示意图；
68.图15为本技术实施例提供的一种应用程序加载方法中启动预加载进程的流程示意图；
69.图16为本技术实施例提供的一种预加载准备队列的示意图；
70.图17为本技术实施例提供的一种插入应用程序3到预加载准备队列的示意图；
71.图18为本技术实施例提供的另一种插入应用程序3到预加载准备队列的示意图；
72.图19为本技术实施例提供的一种消息队列的示意图；
73.图20为本技术实施例提供的一种应用程序加载方法的流程示意图。
具体实施方式
74.通常用户在使用智能手机上安装的应用程序时，需要先通过触摸点击的方式打开手机上的应用程序。在手机接收到用户打开应用程序的操作时，手机需要对应用程序进行加载，当手机将应用程序加载完成之后，用户才能够使用该应用程序。
75.例如，当用户需要打开智能手机上安装的视频类应用程序，如，“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》的视频内容以供用户观看。
76.又例如，当用户需要打开智能手机上安装的游戏类应用程序，如，“xx游戏”应用程序时。如图4所示，用户可以通过点击智能手机桌面中的“xx游戏”应用程序的图标401，以打开“xx游戏”应用程序。当智能手机接收到用户对“xx游戏”应用程序的图标401的点击操作时，手机便可以加载启动该“xx游戏”应用程序。智能手机加载该“xx游戏”应用程序的过程中，如图5所示，智能手机的显示界面中会显示“xx游戏”的启动页502(如，开屏广告页，或者图中所示的包含应用程序的图标的页面等)。当智能手机将“xx游戏”应用程序加载完成之后，如图6所示，智能手机显示的界面可以从“xx游戏”应用程序的启动页502跳转到“xx游戏”应用程序的应用页面603(如，该游戏的登陆界面)。从而用户可以通过该登陆界面登陆游戏账号并进入游戏界面。
77.由以上可以看到，当用户打开智能手机上安装的应用程序时，手机需要加载一定的时长。如，加载该应用程序经过至少一个启动画面之后才能够进入到用户能够进行操作的应用界面(即用户期望的可操作界面)。尤其，当用户打开的应用程序占用资源较多时加载时长会更长。如此，会影响用户在启动应用程序时的使用体验。
78.为解决上述问题，本技术实施例提供了一种应用程序加载方法，该方法可以应用于电子设备启动应用程序的场景中。
79.在本技术实施例中，该应用程序加载方法可以包括，在用户使用电子设备的过程中，电子设备可以按照预设的规则来预测用户可能会打开的应用程序，然后将该应用程序预加载到虚拟屏，以使该应用程序能够在虚拟屏中预加载到用户期望的可操作界面(即应用程序启动后进入的能够被用户操作的界面)，之后，在用户启动应用程序时，若该应用程序已经预加载在虚拟屏中，则电子设备可以将该应用程序从虚拟屏中移到主屏(或称为显示屏，即电子设备正常显示画面的实际屏幕，其显示的画面用户可见)中进行显示，以供用户使用该应用程序。
80.可选地，应用程序在虚拟屏中预加载(或称为运行)到的用户期望的可操作界面
(可称为第一界面)，可以是应用程序冷启动后无用户操作时最后停留的界面，例如，当应用程序为游戏应用程序时，该第一界面可以是图6中所示的登陆界面。又例如，当应用程序为视频应用程序时，该第一界面可以是图3中的应用主界面(或称为应用首页)等，此处不做限制。其中，应用程序冷启动是指应用程序在没有进程和没有任务栈的情况下启动。
81.其中，虚拟屏为电子设备的模拟屏幕，是非实体的，具有与电子设备的实际屏幕相同的功能，但是其显示的画面用户不可见。可选地，虚拟屏可以与显示屏相对应，如虚拟屏与显示屏设置相同的分辨率、尺寸等。如此，电子设备中可以包括两个屏幕id，如id1和id2。相应地，电子设备可以根据屏幕id对应的屏幕下的内容是否被实际显示出来(即输出显示信号)来判断屏幕id对应的屏幕为显示屏还是虚拟屏。例如，id1对应的屏幕下的内容被实际显示出来了，而id2对应的屏幕下的内容没有被实际显示，则可确定id1对应的屏幕为显示屏，id2对应的屏幕为虚拟屏。
82.例如，电子设备可以按照预设的规则预测用户可能会打开的应用程序，如电子设备预测用户未来一段时间内可能会打开“xx游戏”应用程序，此时电子设备便会采用该应用程序加载方法对“xx游戏”应用程序进行预加载。例如，如图7中的a所示，可以将“xx游戏”应用程序加载到虚拟屏上，以使该应用程序能够在虚拟屏上加载到用户期望的可操作界面701(如图中所示的账号登陆界面)。之后，如图7中的b所示，当用户通过点击“xx游戏”应用程序的图标702以准备启动该“xx游戏”应用程序时，如图7中的c所示，电子设备便可以直接将预加载到虚拟屏上的“xx游戏”应用程序的可操作界面701切换显示在主屏上(如账号登录界面)。
83.通过该方法，电子设备可以对用户的操作行为进行预测，以在用户启动某个应用程序之前，先对该应用程序进行预加载。从而当用户想要启动相应的应用程序时，电子设备能够直接将相应的应用程序的可操作界面显示在主屏上，从而减小用户启动相应用程序的感知时间(启动应用程序的感知时间，即从用户对应用程序进行启动操作到电子设备主屏显示该应用程序的可操作界面所经历的时间)。如此，能够提高用户启动应用程序时的流畅体验，提高电子设备在用户启动应用程序时的响应速度。
84.以下，将结合附图对本技术实施例提供的应用程序加载方法进行说明。
85.在本技术实施例中，上述电子设备可以是手机、平板电脑、手持计算机，pc，蜂窝电话，个人数字助理(personal digital assistant，pda)，可穿戴式设备(如：智能手表、智能手环)，智能家居设备(如：电视机)，车机(如：车载电脑)，智慧屏，游戏机，智能投影仪，智能电视盒，以及增强现实(augmented reality，ar)/虚拟现实(virtual reality，vr)设备等。本技术实施例对于电子设备的具体设备形态不作特殊限制。
86.在本技术实施例中，上述电子设备是可以运行操作系统，安装应用程序的电子设备。可选地，电子设备运行的操作系统可以是系统，系统，系统等。
87.示例地，以电子设备为手机为例，图8示出了本技术实施例提供的一种电子设备的结构示意图。也即，示例性的，图8所示的电子设备可以是手机。
88.如图8所示，电子设备可以包括：射频(radio frequency，rf)电路810、存储器820、输入单元830、显示单元840、传感器850、音频电路860、无线保真(wireless fidelity，wifi)模块870、处理器880、电源890以及蓝牙模块8100等部件。本领域技术人员可以理解，图8中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部
件，或者组合某些部件，或者不同的部件布置。
89.下面结合图8对电子设备的部分构成部件进行具体的介绍：
90.存储器820可用于存储软件程序以及模块，处理器880通过运行存储在存储器820的软件程序以及模块，从而执行电子设备的各种功能应用以及数据处理。存储器820可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)、引导装载程序(boot loader)等；存储数据区可存储根据电子设备的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器820可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
91.输入单元830可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。具体地，输入单元830可包括触控面板831以及其他输入设备832。触控面板831，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板831上或在触控面板831附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板831可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器880，并能接收处理器880发来的命令并加以执行。具体地，其他输入设备832可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。在本技术实施例中，用户可以通过触控面板831、鼠标或键盘来输入通过电脑的系统打开模拟器中的文件的操作。
92.显示单元840可用于显示由用户输入的信息或提供给用户的信息以及电子设备的各种菜单。显示单元840可包括显示面板(如显示屏)841，可选的，可以采用液晶显示器(liquid crystal display，lcd)、有机发光二极管(organic light-emitting diode，oled)等形式来配置显示面板841。进一步的，触控面板831可覆盖显示面板841，当触控面板831检测到在其上或附近的触摸操作后，传送给处理器880以确定触摸事件的类型，随后处理器880根据触摸事件的类型在显示面板841上提供相应的视觉输出。虽然在图8中，触控面板831与显示面板841是作为两个独立的部件来实现电子设备的输入和输入功能，但是在某些实施例中，可以将触控面板831与显示面板841集成而实现电子设备的输入和输出功能。
93.处理器880是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器820内的软件程序或模块，以及调用存储在存储器820内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。可选的，处理器880可包括一个或多个处理单元；优选的，处理器880可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器880中。
94.音频电路860可以包括扬声器861和传声器862。通过扬声器861能够播放音频数据，而传声器862则可以用于将声音信号转换为音频数据。
95.当然，可以理解的，上述图8所示仅仅为终端的设备形态为手机时的示例性说明。若终端是平板电脑，手持计算机，pc，pda，可穿戴式设备(如：智能手表、智能手环)，智能家居设备(如：电视机)，车机(如：车载电脑)，智慧屏，游戏机，以及ar/vr设备等其他设备形态
时，终端的结构中可以包括比图8中所示更少的结构，也可以包括比图8中所示更多的结构，在此不作限制。
96.以下实施例中的方法均可以在具有上述硬件结构的电子设备中实现。下面将结合附图对本技术实施例进行举例说明。
97.在本技术实施例中，电子设备可以根据用户的应用程序使用习惯和/或预设的预测规则对应用程序预测和预加载。
98.示例地，在本技术实施例中，电子设备为了实现上述提供应用程序预加载的方法，可以采用如图9所示的系统架构。如图9所示，该电子设备的系统架构可以包括应用层、系统框架层(framework层)、本地框架(native)以及硬件层。其中，应用层可用于部署能够在电子设备上运行的一个或多个应用程序，例如本技术实施例中，应用层中可以部署有“xx游戏”应用程序，“xx视频”应用程序等。系统框架层中可以部署有实时系统(如称为第一系统)、非实时系统(如称为第二系统)以及三方特征库等。本地框架可以部署采集系统和性能雷达。硬件层可以包括cpu以及存储器等硬件，其中存储器可以包括随机存取存储器(random access memory，ram)和外部存储器等。
99.通过非实时系统能够处理对实时性要求不高的操作，即能够在独立进程中进行处理的操作。从而避免所有功能均在系统进程上运行，而造成负荷过高产生卡顿的问题。可选地，非实时系统中可以包括用于校验和构造对相应应用程序进行预加载时所需的参数的预加载模块，用于创建和管理预加载应用程序所需的虚拟屏相关参数的虚拟屏管理模块，用于维护预设的配置参数(如默认预加载时长等参数)的配置管理模块，用于决策是否对某个应用进行预加载的决策模块，用于对当前电子设备所处场景进行识别的场景识别模块，用于对电子设备的负载进行监控的负载监控模块，用于对电子设备中安装的应用程序的相关属性(如应用程序的启动方式、要启动的进程、要启动的界面等启动参数，应用程序的加载特征等)进行管理的应用管理模块等。
100.通过实时系统能够处理和应用程序运行状态、进程强相关的操作、对实时性要求比较高的操作(例如，预测需要预加载的应用程序、执行应用程序的预加载等操作)，以及与进程管理服务(activitymanagerservice，ams)、窗口管理服务(windowmanagerservice，wms)、包管理服务(packagemangerservice，pms)等系统服务强相关的操作。该实时系统可以运行在系统进程(system server)中。可选地，基于上述实时系统可实现的功能，实时系统中可以包括用于对显示窗口进行管理的窗口管理模块，对预加载之后的应用程序的相关消息进行代理的代理模块，用于预测需要进行预加载的应用程序的预测模块，用于对预加载后的应用程序所使用资源进行管控的资源管控模块，用于执行应用程序预加载的预加载管理模块等，用于维护和测试应用程序预加载功能的维测模块等。
101.作为一种示例，基于如图9所示的系统架构。可以预先建立包括多个应用程序的相关属性特征的三方特征库。该三方特征库中可以包括各应用程序对应的应用类型(如游戏、即时通讯、邮箱、运动健康、导航、股票、闹钟日历、音乐、视频、购物、银行、相机、浏览器、输入法、直播、新闻、教育、支付收款、新闻等应用类型)、应用程序加载所耗系统资源(如cpu负载、内存占用以及耗电量等)、应用程序加载到预期界面(即可操作界面)所耗时间(即应用程序加载时长)等。可选地，可以在云服务器中建立相应的特征库，然后通过云推的方式同步到电子设备的三方特征库中。
102.示例地，三方特征库中的应用类型可以通过对主流应用程序筛查扫描来采集。
103.例如，如图10所示，可以先选取主流应用市场中排名前n(即top n)的应用程序，根据每个应用程序的功能定义(即该应用程序在应用市场中的分类标签)来对相应应用程序的应用类型进行第一次筛选确认。然后，还可以扫描每个应用程序的属性文件(如manifest文件)，根据属性文件中的参数对相应应用程序的应用类型进行第二次筛选确认。从而确定出选取的n个应用程序分别对应的应用类型。可选地，还可以在第二次筛选确认每个应用程序的应用类型之后，再对每个应用程序进行人工复查(或称为人工校验)以确定出选取的n个应用程序分别对应的应用类型。从而，便可以得到主流的n个应用程序各自的应用类型。之后，可以将得到的n个应用程序各自的应用类型上传到云服务器(即云端)，然后再由云服务器将n个应用程序各自的应用类型同步到电子设备的三方特征库中。可选地，非实时系统中的应用管理模块可以根据电子设备已安装的应用程序，从三方特征库中匹配出各已安装的应用程序对应的应用类型。
104.示例地，三方特征库中的应用程序加载时长可以通过对主流应用程序的加载画面进行识别来采集。
105.例如，如图11所示，可以先选取主流应用市场中排名前n(即top n)的应用程序，然后分别对各个应用程序的加载画面中的预期界面(即加载结束画面)中的关键特征进行定义(通常可以将预期界面中不易随应用程序更新而改变的特征作为关键特征，如账号登录控件、页面选择控件等)。之后，可分别对每个应用程序依次进行冷启动，并对相应应用程序冷启动时的加载画面进行视频录制(录制帧率可以为24帧、60帧等低帧率，也可以是120帧、240帧等高帧率)。然后可对录制的加载画面视频中的每一帧进行识别(可按照从视频的中间帧依次向时间轴两端识别的方式识别每一帧，也可以从第一帧依次识别每一帧，此处不做限制)，当识别到对应应用程序定义的加载结束画面中的关键特征时，便可以以该帧对应的视频时长作为对应应用程序的加载时长。如，以应用程序为“xx游戏”应用程序为例，如图12所示，可以定义该应用程序的加载画面中的预期界面中的关键特征为账号登录控件1201和适龄提示标识1202。则可以对该应用程序进行冷启动，并对该应用程序冷启动时的加载画面进行录制。然后对录制的加载画面中的每一帧进行识别。当识别到如图12所示的账号登录控件1201和适龄提示标识1202时，则可确定出包含该账号登录控件1201和适龄提示标识1202的一帧为预期界面，从而可以以该帧对应的视频时长作为该“xx游戏”应用程序的加载时长。当然，在本技术的其他可能的实施方式中，还可以通过其他方式来采集确定应用程序的加载时长，此处不做限制。
106.可选地，在对定义的关键特征进行识别确定出加载时长之后，还可以对该应用程序的加载时长进行人工校验。并且针对每个应用程序可以重复多次上述方式以得到相对准确的加载时长。
107.当得到选取的n个应用程序中分别对应的加载时长之后，可以将得到的n个应用程序各自的加载时长上传到云服务器(即云端)，然后再由云服务器将n个应用程序各自的加载时长同步到电子设备的三方特征库中。可选地，非实时系统中的应用管理模块可以根据电子设备已安装的应用程序，从三方特征库中匹配出各已安装的应用程序对应的加载时长。
108.示例地，三方特征库中的应用程序加载所耗系统资源可以通过对主流应用程序的
加载负载进行获取得到。
109.例如，如图13所示，可以先选取主流应用市场中排名前n(即top n)的应用程序，然后分别对每个应用程序依次进行冷启动。在应用程序启动过程中，可以周期性的获取电子设备的cpu负载。然后获取对应应用程序启动后相应进程的进程控制符(process identifier，pid)，从而获取该应用程序对应的进程的内存占用等负载信息。从而便可得到主流n个应用程序各自的cpu负载、内存占用等加载所耗系统资源。可选地，可以针对每个应用程序重复多次上述方式以得到更加准确的稳定的加载所耗系统资源数据，此处不做限制。之后，可以将得到的n个应用程序各自的加载所耗系统资源上传到云服务器(即云端)，然后再由云服务器将n个应用程序各自的加载所耗系统资源同步到电子设备的三方特征库中。可选地，非实时系统中的应用管理模块可以根据电子设备已安装的应用程序，从三方特征库中匹配出各已安装的应用程序对应的加载所耗系统资源。
110.在本技术实施例中，基于上述如图9所示的系统架构。电子设备可以通过实时系统中的预测模块对用户在未来一段时间可能会打开的应用程序进行预测。例如，预测模块可以通过高频规律学习模型、上下文规律学习模型等，将输入的应用程序日志转化为规律集作为可能会被用户启动的应用程序的筛选条件，再结合当前场景等特征，通过fp-tree和序列模式挖掘(prefixspan、cm-spade等)算法推算出下一个或者下一段时间内用户可能使用的应用程序。
111.示例地，预测模块可以进行高频行为规律学习，形成用户行为画像。例如，如图14所示，通过高频行为规律学习，得到用户闹钟时间(如七点)，离家时间(如七点三十分)、到公司时间(如八点三十分)等。以及用户起床时间(如七点)，晨间常用应用如天气应用程序，通勤模式(如自驾)，上午常用应用(即高频规律)如公司打卡应用程序，中午应用为视频应用程序等。得到用户离家后会经常打开哪些应用程序(如导航类应用程序、打车类应用程序等)，到公司后会经常打开哪些应用程序(如打卡应用程序、邮箱类应用程序等)。从而预测模块可以在识别到用户处于离家的场景或到公司的场景时，将学习得到的对应应用程序预测为用户可能会打开的应用程序。可选地，可以周期性的对用户未来可能会打开的应用程序进行预测(可以预测未来一段时间内(如一小时)可能会打开的应用程序)。最终得到的预测结果可以为预测到的要启动的应用程序(即预加载的应用程序)的包名和该应用程序可能会启动的时间段(即可能被用户使用的时间段)。然后可以将预测结果，如预加载的应用程序的包名和其对应的可能被用户使用的时间段发送给预加载模块，以便于预加载模块根据预测结果对相应的应用程序进行预加载启动。
112.例如，预测模块可以预测未来一小时内可能被用户使用的应用程序为应用程序1和应用程序2，并且，应用程序1可能被用户使用的时间段为早上九点到九点十分，应用程序2可能被用户使用的时间段为早上九点半到十点。此时，预测模块可以将预测出的应用程序1的包名以及对应的可能被用户使用的早上九点到九点十分的时间段，以及将预测出的应用程序2的包名以及对应的可能被用户使用的早上九点半到十点的时间段，发送给预加载模块。
113.示例地，预测模块还可以进行上下文行为规律学习，以形成用户行为画像。例如，如图14所示，通过上下文行为规律学习，可以得到用户离公司时间(如九点三十分)，用户到家时间(如十点)，用户入睡时间(如十一点)，用户上午上下文规律应用为打开视频会议后，
会打开录音。用户夜间上下文规律应用为打开聊天后，会打开游戏等用户在打开某个应用程序之后经常性会再打开另一应用程序(如用户在打开会议应用程序时，还会再打开录音应用程序等)的上下文习惯。从而预测模块在识别到用户打开了应用程序1时，便能够将学习得到的上下文习惯中与应用程序1关联的应用程序2预测为用户可能会打开的应用程序。
114.可选地，当预测模块预测到用户可能会打开的应用程序，且预测准确率达到阈值时，预测模块可以主动通知预加载模块对相应的应用程序进行预加载。
115.或者，预测模块可以为预加载模块提供查询接口，以供预加载模块查询预测到的用户可能会打开的应用程序。从而便于预加载模块对相应的应用程序进行预加载准备。
116.在一些可能的实施方式中，如图9所示的软件系统还可以包括人工智能(artificial intelligence，ai)模块，以通过人工智能模块对用户在未来一段时间可能打开的应用程序进行预测，从而提高预测应用程序的准确率。可选地，在本技术的其他一些实施例中，还可以只包括ai模块，不包括预测模块，此处不做限制。ai模块预测出的预测结果内容与预测模块可以相同，也包括预测出的未来一段时间内可能被用户使用的应用程序以及对应的可能被用户使用的时间段。
117.当预加载模块获取到需要预加载的应用程序之后，决策模块可以先根据电子设备当前所处场景，电子设备当前的负载以及要预加载的相应应用程序对应的应用类型、加载时长、加载所耗系统资源等进行综合决策以决定是否需要对相应的应用程序进行预加载。示例地，上述系统架构中的负载监控模块可以实时监控或周期性监控电子设备当前的cpu负载、内存占用以及电量信息等。场景识别模块可以通过注册、回调、广播等现有java或android机制来实时识别或周期性识别电子设备当前的使用场景。如，识别当前电子设备是否充电、是否灭屏、是否被远程控制、是否为首次启动、是否为连续启动、是否为分屏状态、是否设置有多屏、是否为投屏状态、是否进行了用户切换、是否返回桌面以及是否卸载应用等。而根据前述，应用管理模块中管理有已安装的各应用程序对应的应用类型、加载时长、加载所耗系统资源等。从而决策模块可以分别从负载监控模块、场景识别模块以及应用管理模块获取上述信息，然后根据电子设备当前的负载情况，以及加载相应应用所需时长和所耗系统资源的情况来判断当前电子设备是否满足预加载相应应用程序的条件，然后决策模块还可以根据电子设备当前的场景对是否要预加载相应应用程序进行综合判断。例如，当场景为灭屏时可以不对应用程序进行预加载。又例如，当场景为分屏、多屏或投屏时，则很难确定用户是否需要向往常一样打开某些应用程序，因此此时也可以不对应用程序进行预加载。
118.当决策模块确定需要对某个应用程序进行预加载时，基于上述如图9所示的系统架构。决策模块可以通知非实时系统的预加载模块对该应用程序进行预加载。从而，预加载模块可以从虚拟屏管理模块获取相应的虚拟屏参数，然后将虚拟屏参数以及要预加载的应用程序的信息传递给实时系统的预加载管理模块。然后，预加载管理模块便可以根据虚拟屏参数以及要预加载的应用程序的信息将相应的应用程序预加载到虚拟屏上。其中，当预加载模块获取虚拟屏参数时，若虚拟屏管理模块中未创建虚拟屏，则虚拟屏管理模块可以先创建虚拟屏，然后再向预加载模块返回相应的虚拟屏参数。需要说明的是，虚拟屏一般与主屏的参数一致，从而使预加载到虚拟屏的应用程序切换显示到主屏时能够适配主屏。
119.可选地，当相应的应用程序预加载到虚拟屏之后，实时系统中的窗口管理模块可
以对虚拟屏中预加载的应用程序的所有窗口显示进行维护，将其代理。例如，使预加载的应用程序的toast弹窗、notify通知、游戏助手弹窗等推迟生效。从而避免预加载到虚拟屏的应用程序的弹窗、通知等显示到主屏影响用户正常使用正在使用的应用程序。
120.可选地，当相应的应用程序预加载到虚拟屏之后，实时系统中的代理模块还可以对虚拟屏中预加载的应用程序启动后接收和发送的广播、其与外界应用的binder通信、其监听的闹钟函数(alarm)消息等消息进行代理，将对应消息缓存起来，当用户对相应应用程序进行了启动操作，应用程序切到主屏显示时，再将还具备时效的消息重新发送或接收。
121.在本技术实施例中，可以通过资源管控模块对预加载到虚拟屏的应用程序的资源进行管控。例如，可以管控预加载到虚拟屏的应用程序的音频资源，使其输出的音频信息不被电子设备输出，从而避免影响用户正常使用正在使用的应用程序。又例如，可以控制电子设备只绘制预加载到虚拟屏的应用程序的显示画面但不进行渲染，从而减少电子设备的渲染合成压力，避免卡顿。又例如，当预加载到虚拟屏的应用程序为多个时，资源管控模块还可以将预加载的应用程序中会被用户打开的概率降低了的应用程序进行冷冻转储，从而进一步控制电子设备的cpu负载和内存占用。
122.可选地，当用户对预加载的应用程序中的某个进行了启动操作(如，点击了相应应用程序的图标)，或者其他应用程序调用了预加载的应用程序中的某个时，电子设备便可以将相应的应用程序的显示界面从虚拟屏切换显示到主屏。
123.例如，当用户点击了相应应用程序的图标时，系统进程可以通知预加载管理模块启动相应的应用程序。从而预加载管理模块可以对相应应用程序是否已经预加载到虚拟屏进行判断，若已经预加载到虚拟屏了，则预加载管理模块可以通知资源管控模块解除对相应应用程序的资源管控，通知窗口管理模块解除对相应应用程序的窗口管理，以及通知代理模块解除对相应应用程序的消息的代理管理。并且，预加载管理模块可以将对应的应用程序从虚拟屏转移到主屏(即当前用于显示画面的屏幕)。
124.基于前述实施例，结合如图9所示的系统架构，电子设备可以对需要预加载的应用程序启动预加载进程，以使需要预加载的应用程序能够在虚拟屏中启动。例如，图15示出了本技术实施例提供的一种应用程序加载方法中启动预加载进程的流程示意图。如图15所示，该启动预加载进程的方式可以包括以下s1501-s1527。
125.当预测模块和/或ai模块预测出需要预加载的应用程序时，可以通知预加载模块对相应应用程序进行预加载。例如，以预测模块为例(以下均以此为例)，可以执行以下s1501。
126.s1501、预测模块预测出需要预加载的应用程序，将预测结果，如，需要预加载的应用程序的包名以及该应用程序对应的可能被用户使用的时间段(或称为预加载应用程序的使用时间段)发送给预加载模块。
127.其中，预测模块可以周期性的对记录的用户行为进行学习，以得到用户行为画像，并将用户行为画像存储起来。从而可根据用户行为画像预测出未来一段时间(如一小时等)内用户可能会使用的应用程序，进而将这些预测出的用户未来一段时间可能使用的应用程序及其对应的可能被使用的时间段作为预测结果。即，将预测出的用户未来一段时间可能使用的应用程序作为需要预加载的应用程序。
128.通常，预测模块预测出的需要预加载的应用程序包括多个，当然在一些其他可能
的实施方式中，某一时刻预测模块也可以仅预测出一个需要预加载的应用程序，此处不做限制。
129.需要说明的是预测模块将预测结果发送给预加载模块可以是预加载模块获取时预测模块向预加载模块发送，也可以是预测模块主动发送此处不做限制。例如，预测模块预测出未来一段时间(如一小时)内用户可能使用的应用程序之后，可以主动将这些应用程序的包名以及对应的可能被用户使用的时间段发送给预加载模块。又例如，在电子设备检测到前台应用发生变化且前台应用为launcher从而确定当前电子设备已退回桌面时，或者检测到电子设备触发了屏幕解锁事件(如监听到系统的action_user_present事件的广播)时，又或者检测到电子设备进入多任务窗口时，预加载模块可以主动从预测模块获取未来一段时间(如一小时)内预测出的用户可能使用的应用程序的包名和对应的可能被使用的时间段。示例地，预加载模块从预测模块获取预测结果可以是：预加载模块向预测模块发送获取请求，预测模块接收到请求后向预加载模块发送相应的应用程序包名和对应的可能被使用的时间段。或者，预测模块为预加载模块提供查询接口，从而预加载模块通过查询接口查询相应的应用程序包名和对应的可能被使用的时间段。
130.示例地，预测模块在8点50分可以预测出未来一小时内用户可能使用的应用程序包括9点至9点15分可能被使用的应用程序1，9点10分至9点20分可能被使用的应用程序2以及9点15分至9点20分可能被使用的应用程序3。因此，预测模块在8点50分时可以将上述应用程序1的包名以及其对应的被使用时间段(9点至9点15分)，应用程序2的包名以及其对应的被使用时间段(9点10分至9点20分)，应用程序3的包名以及其对应的被使用的时间段(9点15分至9点20分)作为预测结果发送给预加载模块。从而便于预加载模块后续根据该预测结果对相应应用程序进行预加载处理。
131.相应地，预加载模块可执行如下s1502。
132.s15402、预加载模块对需要预加载的多个应用程序分别进行入参合法性校验。
133.通常，预测模块和/或ai模块在预测出需要预加载的应用程序时，还会预测该需要预加载的应用程序可能被用户使用的时间段。因此，预加载模块对需要预加载的应用程序进行的入参合法性校验，可以包括对应用程序可能被用户使用的时间段进行校验。如，校验当前时间是否已经超过对应需要预加载的应用程序可能被用户使用的时间段，当未超过时则校验通过。从而，能够避免预加载模块在当前时间已经超过可能被用户使用的时间段时对相应应用程序进行预加载，进而减少对不再需要预加载的应用程序进行预加载的情况。
134.例如，基于前述s1501中的示例，当预测模块发送的预测结果包括应用程序1的包名以及其对应的被使用时间段(9点至9点15分)，应用程序2的包名以及其对应的被使用时间段(9点10分至9点20分)，应用程序3的包名以及其对应的被使用的时间段(9点15分至9点20分)时。预加载模块可以根据当前时间，分别对应用程序1、应用程序2以及应用程序3的被使用时间段进行校验。即当前时间未超过9点至9点15分的时间段时则应用程序1校验通过，当前时间未超过9点10分至9点20分的时间段时则应用程序2校验通过，当前时间未超过9点15分至9点20分的时间段时则应用程序3校验通过。
135.一般预测模块和/或ai模块向预加载模块发送的预测结果可以通过特定格式的消息(如字符串)的方式进行发送。因此，预加载模块进行的入参合法性校验还可以是预测模块发送的消息的大小以及信息格式是否满足预设进行校验。例如，当消息的大小大于预设
值时，或者消息的信息格式与预设的信息格式不一致时，校验不通过。从而减小遭受外部应用发送消息进行的恶意攻击的几率，避免外部应用试图通过本技术实施例的方式预加载指定应用程序的情况。
136.当然，在一些可能的实施方式中，预加载模块可以分别对预测模块发送的消息的大小、信息格式一致性以及预测模块预测的需要预加载的应用程序可能被用户使用的时间段进行校验，当这些参数均校验通过时才确定入参合法性校验通过。
137.当预加载模块对预测模块预测出的需要预加载的各应用程序均进行了入参合法性校验之后，预加载模块可以根据如下s1503-s1508来遍历校验通过的各需要预加载的应用程序。
138.s1503、预加载模块获取校验通过的各需要预加载的应用程序中的一个(例如s1501中示例的应用程序1等)。
139.需要说明的是，由于是遍历所有校验通过的需要预加载的应用程序，因此每次获取的一个应用程序均为之前未获取的一个。
140.通常获取的是相应需要预加载的应用程序的包名和其对应的使用时间段。
141.示例地，可以从校验通过的需要预加载的应用程序中随机获取一个应用程序。也可以从校验通过的需要预加载的应用程序中按照各应用程序对应的使用时间段的先后顺序优先获取使用时间段靠前的一个应用程序，此处不做限制。
142.s1504、预加载模块判断当前正在预加载的应用程序以及准备预加载的应用程序是否超过预设数量。
143.需要说明的是，准备预加载的应用程序可以是预加载模块根据s1503-s1508对应用程序进行校验判断之后确定可以被预加载的应用程序，也即准备预加载的应用程序是被确定可以预加载且准备进行预加载的应用程序。当前正在预加载的应用程序可以是ams正在向虚拟屏上进行加载的应用程序。
144.其中，预设数量可以根据电子设备的负载能力等进行设置。当超过预设数量时，预加载模块则可以等待一定时长后再重新执行该步骤，当不超过预设数量时，则可以执行后续步骤。从而避免当前准备预加载的应用程序数量过多导致电子设备卡顿或系统堵塞。
145.需要说明的是，在本技术实施例中，可以设置一个预加载准备队列(如preload ready list)，可将所有准备预加载的应用程序排列在该队列中。例如，如图16所示，当应用程序1和应用程序2均为准备预加载的应用程序时，则可以将应用程序1和应用程序2排列在预加载准备队列中，以便后续按照该队列的顺序从队首依次对准备预加载的应用程序进行预加载。
146.相应地，预加载模块可以通过查询该预加载准备队列中的应用程序的数量，来确定当前准备预加载的应用程序的数量。
147.可选地，在本技术实施例中还可以设置一个正在预加载队列(如preloading map)，可将所有正在预加载的应用程序添加在该队列中。
148.还可以设置一个完成预加载队列(如，preloaded map)，可将所有已经预加载完成的应用程序添加到该队列中。其中，已经预加载完成的应用程序可以是已经加载到虚拟屏上的应用程序。
149.s1505、预加载模块向应用管理模块请求校验该应用程序，(即s1503获取的各需要
预加载的应用程序中的一个)是否安装。
150.相应地，应用管理模块可以向预加载模块返回该应用程序是否安装的校验结果。
151.示例地，预加载模块可以向应用管理模块发送请求校验是否安装的消息，该消息可以包括该应用程序的包名。应用管理模块可以匹配接收到的包名是否在应用管理模块存储的已安装应用列表中，若能够匹配到，则应用管理模块可以向预加载模块返回指示该应用程序已安装的校验结果。从而，当该应用程序安装时，预加载模块再执行后续步骤，若该应用程序未安装，则预加载模块可以不再处理该应用程序，而重新执行s1503获取另一个需要预加载的应用程序。
152.s1506、预加载模块判断该应用程序是否为正在预加载、或已经预加载完成、或已经运行在前台中的任一种。
153.示例地，在本技术实施例中，若设置有前述示例中的正在预加载队列(如preloading map)，以及完成预加载队列(如，preloaded map)。此时，预加载模块可以根据该应用程序的包名，在上述两个队列中分别进行查询以判断该应用程序是否正在预加载或已经预加载完成。预加载模块还可以通过前台进程来判断该应用程序是否已经运行在前台。从而当该应用程序正在预加载或已经预加载完成或已经运行在前台时，预加载模块可以不再对其进行处理，而是重新执行s1503获取另一个需要预加载的应用程序。而当该应用程序没有正在预加载且没有预加载完成且没有运行在前台时，预加载模块则可以执行后续步骤。
154.s1507、预加载模块判断该应用程序是否为准备预加载的应用程序。
155.示例地，当设置有预加载准备队列时，预加载模块可以根据该应用程序的包名在预加载准备队列中进行查询，以确定该应用程序是否在预加载准备队列中，从而确定其是否为准备预加载的应用程序。从而当该应用程序为准备预加载的应用程序时，预加载模块可以不再对其进行处理，而是重新执行s1503获取另一个需要预加载的应用程序。而当该应用程序不是准备预加载的应用程序时，预加载模块则可以执行后续步骤。
156.需要说明的是，在本技术实施例中对于s1504-s1507的执行顺序不做限制。
157.s1508、预加载模块根据该应用程序的及时性，将该应用程序设置在准备预加载的应用程序的队列中。
158.示例地，当设置有预加载准备队列时，可以根据该应用程序对应的使用时间段确定其及时性，然后将其插入到预加载准备队列中的队首、队中或队尾。示例地，若当前时间即将到达该应用程序对应的使用时间段(如当前时间到达使用时间段所需时间小于或等于预设时间阈值时)，则可确定该应用程序的预加载相对紧急(即及时性为紧急)，此时可将该应用程序插入到预加载准备队列中的队首。其他情况则可将该应用程序插入到预加载准备队列中的队尾，以便后续按照队列顺序对所有准备预加载的应用程序进行预加载。例如，可以设置预设时间阈值为10分钟，基于图16所示的预加载准备队列，若该应用程序为应用程序3，且对应的使用时间段为9点15分到9点20分，而当前时间为9点10分，与使用时间段相差5分钟，小于预设时间阈值，因此可确定该应用程序的及时性为紧急。如图17所示，可将该应用程序(即应用程序3)插入到预加载准备队列的队首。或者，若当前时间为8点50分，则与使用时间段相差25分钟，大于预设时间阈值，因此可确定该应用程序的及时性为非紧急。如图18所示，可将该应用程序(即应用程序3)插入到预加载准备队列的队尾。
159.可选地，在本技术实施例的其他一些实施方式中，预测模块还可以在预测结果中根据应用程序对应的使用时间段确定出其及时性(紧急或非紧急)后，对该应用程序的及时性进行标记，如，在预测结果中加入对应应用程序的及时性标识，后续可将该标识随包名和时间段一同发送给预加载模块。从而，预加载模块可直接根据及时性标识确定对应应用程序的及时性。
160.当预加载模块将一个应用程序设置到准备预加载的应用程序的队列中之后，预加载模块便可以通过系统进程发送msg_preload_app消息(或称为第一消息)到消息队列，以便决策模块从消息队列中按照消息时序接收到msg_preload_app消息时进行后续步骤。即，如图19所示，随着预加载模块遍历预测出的需要预加载的各应用程序，其发送的msg_preload_app消息通常为多个，消息队列中会包括按照时间顺序排列的多个msg_preload_app消息，如消息1、消息2、消息3等，决策模块可以根据msg_preload_app消息的发送时间从消息队列中由队首依次对该消息进行接收和处理。例如，当决策模块每次从消息队列中接收和处理一条msg_preload_app消息时，便会执行如下s1509-s1517。可选地，消息队列中的消息数量和准备预加载的应用程序的数量(如预加载准备队列中的应用程序数量)对应(即相同)。从而保证决策模块和预加载模块多进程处理时，决策模块能够对所有准备预加载的应用程序进行处理而不遗漏。
161.可选地，消息队列可以设置在系统进程中缓存在内存。或者，在如图9所示的系统架构中还可以设置一个消息模块用来创建和管理该消息队列，此处不做限制。
162.s1509、决策模块获取准备预加载的应用程序的队列中位于队首的应用程序(例如图17中所示的应用程序3，或如图18所示的应用程序1)。以准备预加载的应用程序的队列中位于队首的应用程序为第一应用程序为例，则上述应用程序可以是第一应用程序。
163.通常，决策模块获取的是应用程序的包名和其对应的使用时间段。示例地，当设置有预加载准备队列时，决策模块可以从预加载准备队列中获取位于队首的应用程序。
164.可选地，决策模块还可以根据其他顺序或者随机从准备预加载的应用程序的队列中获取一个应用程序(例如，队列中的第一应用程序)，此处不做限制。
165.s1510、决策模块对该应用程序(即决策模块获取的队首的应用程序)进行合法校验。
166.例如，考虑到准备预加载的应用程序在队列中等待被决策模块处理时存在排队等待时间，决策模块获取了该应用程序之后，可以根据当前时间对该应用程序对应的使用时间段进行校验，若当前时间已经超过使用时间段则校验不通过，若未超过使用时间段，则校验通过。从而，避免准备预加载的应用程序因等待被决策模块处理而导致使用时间段已过，却被预加载的情况。
167.可选地，决策模块还可以从应用管理模块获取该应用程序加载所需时长，然后当当前时间加上加载所需时长未超过该应用程序使用时间段时，校验通过。即当该应用程序从当前时间预加载完成后若未超过使用时间段则可执行后续步骤，以便对其预加载，否则说明预加载完成后时间会超过该应用程序使用时间段，为无效预加载，因此验证不通过不再对其处理。
168.s1511、决策模块判断该应用程序的重要性。
169.其中，该应用程序为用户未来一段时间大概率要使用，或马上就要使用的应用程
序等时，可认为该应用程序为重要应用程序。可选地，预测模块还可以在预测结果中根据应用程序的使用时间段以及使用场景和预测概率等，通过重要性标识的方式对应用程序的重要性进行标识，并随包名和使用时间段等一同发送给预加载模块，从而使预加载模块将应用程序添加到准备预加载的应用程序的队列中时，队列中的应用程序能够携带重要性标识。进而决策模块可以在获取队首的应用程序时获取到该应用程序的重要性标识，以根据重要性标识确定该应用程序的重要性。
170.当决策模块确定该应用程序的重要性为非重要时，可执行以下s1512-s1514。
171.s1512、决策模块从应用管理模块获取该应用程序加载时所耗系统资源。
172.其中，基于前述关于应用管理模块的说明，应用管理模块会预先存储有各已安装应用程序对应的加载所需时长、加载时所耗系统资源等。
173.相应地，在决策模块获取该应用程序加载时所耗系统资源时，应用管理模块可以向决策模块返回该应用程序加载时所耗系统资源。
174.例如，决策模块可以向应用管理模块发送获取加载时所耗系统资源的请求，并携带该应用程序的包名。由于应用管理模块从三方特征库中已匹配出了各已安装的应用程序对应的加载所耗系统资源，所以应用管理模块可以根据包名查找相应应用程序对应的加载所耗系统资源并返回给决策模块。
175.s1513、决策模块从负载监控模块获取当前电子设备的系统资源。
176.需要说明的是，基于前述关于负载监控模块的说明，负载监控模块可周期性或实时的检测电子设备的系统资源，从而便于在决策模块获取电子设备当前的系统资源时向决策模块返回当前电子设备的系统资源。
177.例如，决策模块可以向负载监控模块发送获取系统资源的请求。
178.相应地，负载监控模块可以向决策模块返回当前电子设备的系统资源。
179.s1514、决策模块根据当前电子设备的系统资源以及该应用程序加载时所耗系统资源，确定当前系统资源是否支持预加载该应用程序(即当前的系统资源是否够应用程序加载时消耗，若够则支持预加载该应用程序)，若支持则执行后续步骤，若不支持则延迟预设时长后发送msg_preload_app消息到消息队列，然后决策模块可以重新从消息队列中获取一条消息以便后续决策模块根据消息队列中的消息重新开始执行s1509及后续步骤。从而避免在系统资源不支持预加载该应用程序时对其进行预加载导致系统卡顿。
180.其中，由于决策模块延迟一定时长后发送消息到消息队列并重新对预加载准备队列中的一个应用程序进行预加载，因此预加载准备队列中的应用程序数量并没有因有应用程序被加载到虚拟屏而减少。所以此处决策模块发送消息到消息队列能够保证消息队列中的消息与预加载准备队列中的应用程序数量一致。
181.若当前系统资源支持预加载该应用程序，则可执行后续步骤。
182.示例地，根据当前电子设备的系统资源以及该应用程序加载时所耗系统资源，确定当前系统资源是否支持预加载该应用程序可以是：当系统资源为cpu负载时，判断当前负载和加载所耗负载之和是否大于预设阈值1，若大于，则确定当前系统资源不支持加载该应用程序，否则可确定当前系统资源支持加载该应用程序。当系统资源为内存占用时，判断当前内存占用减去加载所耗内存占用的值是否小于预设阈值2，若小于，则确定当前系统资源不支持加载该应用程序，否则可确定当前系统资源支持加载该应用程序。
183.需要说明的是，当决策模块确定应用程序的重要性为重要时，决策模块可以不考虑当前系统资源是否支持预加载该应用程序。即，不执行上述s1512-s1514。
184.s1515、决策模块从应用管理模块获取上次预加载的应用程序预加载所需时长(即加载所需时长，或称为加载时长)。
185.其中，基于前述关于应用管理模块的说明，应用管理模块会预先存储有各已安装应用程序对应的加载所需时长、加载时所耗系统资源等。
186.相应地，在决策模块获取该应用程序预加载所需时长(即加载所需时长)时，应用管理模块可以向决策模块返回该应用程序加载所需时长。
187.例如，决策模块可以向应用管理模块发送获取加载所需时长的请求，并携带上次预加载的应用程序的包名(可从预加载模块获取上次预加载的应用程序的包名)。由于应用管理模块从三方特征库中已匹配出了各已安装的应用程序对应的加载所需时长，所以应用管理模块可以根据包名查找相应应用程序对应的加载所需时长并返回给决策模块。
188.s1516、决策模块根据当前时间、上次预加载的应用程序加载所需时长以及上次预加载的应用程序开始预加载时的时间(可选地，预加载模块中可记录上次预加载的应用程序的包名及开始预加载的时间，从而决策模块可从预加载模块中获取上次预加载的应用程序开始预加载时的时间)，确定上次预加载的应用程序是否正在加载(即确定当前是否存在正在预加载的应用程序)，若没有正在预加载则执行后续步骤，若正在加载则延迟预设时长后发送msg_preload_app消息到消息队列，然后决策模块可以重新从消息队列中获取一条消息以便后续决策模块根据消息队列中的消息重新开始执行s1509及后续步骤。从而避免因对该应用程序进行预加载而影响正在预加载的应用程序。
189.其中，由于决策模块延迟一定时长后发送消息到消息队列并重新对预加载准备队列中的一个应用程序进行预加载，因此预加载准备队列中的应用程序数量并没有因有应用程序被加载到虚拟屏而减少。所以此处决策模块发送消息到消息队列能够保证消息队列中的消息与预加载准备队列中的应用程序数量一致。
190.示例地，根据当前时间、上次预加载的应用程序加载所需时长以及上次预加载的应用程序开始预加载时的时间，确定上次预加载的应用程序是否正在加载可以是：判断上次预加载的应用程序开始预加载时的时间加上其加载所需时长，是否小于或等于当前时间。若小于或等于则确定没有正在加载，若大于则说明正在加载。
191.通过该步骤可以确定出当前是否存在正在预加载的应用程序，从而避免加载该应用程序时对正在预加载的应用程序造成影响。当然，在本技术的其他一些可能的实施方式中，还可以通过其他方式来确定是否存在正在预加载的应用程序，此处不做限制。
192.s1517、决策模块将该应用程序的包名发送给预加载模块。
193.s1518、预加载模块从虚拟屏管理模块获取虚拟屏参数。
194.例如，预加载模块向虚拟屏管理模块发送获取虚拟屏参数的请求。
195.相应地，虚拟屏管理模块会向预加载模块返回虚拟屏参数。其中，虚拟屏参数可以包括虚拟屏唯一编码(identity document，id)。
196.可选地，当预加载模块获取虚拟屏参数时，若虚拟屏管理模块确定虚拟屏不存在，则虚拟屏管理模块会创建一个虚拟屏然后向预加载模块返回该虚拟屏的虚拟屏参数(如虚拟屏id)。当预加载模块获取虚拟屏参数时，若虚拟屏管理模块确定虚拟屏未打开，则虚拟
屏管理模块会打开虚拟屏然后向预加载模块返回该虚拟屏的虚拟屏参数。其中，虚拟屏的创建和打开均可通过屏幕管理服务(displaymanagerservice，dms)来实现。例如，虚拟屏管理模块可以向dms发送创建或打开虚拟屏的请求，dms接收到请求后便可以创建或打开虚拟屏，并将虚拟屏的虚拟屏参数返回给虚拟屏管理模块。
197.s1519、预加载模块从应用管理模块获取启动该应用程序所需的启动参数。
198.相应地，应用管理模块可以向预加载模块返回启动参数。
199.其中，启动参数可以包括启动方式(如标准模式(standard)、栈顶复用模式(singletop)、栈内复用模式(singletask)、单例模式(singleinstance)等)，要启动的进程，要启动的界面等。
200.可选地，预加载模块在获取到虚拟屏参数和/或启动参数之后，还可以根据当前时间更新最新预加载的应用程序(即决策模块当前处理的该应用程序，也即第二应用程序)的开始加载时间，以及最新预加载的应用程序的包名。从而便于下一次决策模块执行s1516时使用。还可以将该应用程序从准备预加载的应用程序的队列中移除，并放到正在预加载的应用程序的队列中。
201.s1520、预加载模块向ams发送启动该应用程序的界面的请求(如start activity)。其中，该请求中可以携带s1519中获取的启动参数以及s1518中获取的虚拟屏参数。
202.s1521、ams向预加载管理模块发送启动该应用程序的界面的请求。
203.s1522、预加载管理模块确定该请求为预加载模块的请求。
204.示例地，在预加载模块向ams发送启动该应用程序的界面的请求时，该请求中可以携带有相应的来源信息，从而预加载管理模块可以根据ams转发来的请求中的来源信息来确定该请求是否为预加载模块发送的请求。
205.s1523、预加载管理模块确定该应用程序为冷启动。
206.示例地，预加载管理模块可以根据当前是否存在该应用程序的进程来判断该应用程序是否为冷启动。即当前不存在该应用程序的进程时，可确定该应用程序为冷启动。从而，可避免根据应用程序内切换界面时发起的启动应用程序界面的请求将对应应用程序界面启动到了虚拟屏。
207.s1524、预加载管理模块确定存在启动该应用程序的界面的请求中指定的虚拟屏。
208.示例地，预加载管理模块可以通过dms来确定虚拟屏是否存在。例如，预加载管理模块可以向dms发送携带虚拟屏参数的确认虚拟屏是否存在的请求，dms可根据接收到的虚拟屏参数确定对应的虚拟屏是否存在并返回给预加载管理模块。
209.s1525、预加载管理模块确定虚拟屏上的应用程序数量未达到阈值。示例地的阈值可以是5个。可选地，可以根据虚拟屏上显示的应用程序界面数量，或者完成预加载队列中的应用程序数量等来确定虚拟屏上的应用程序数量。
210.当确定虚拟屏上的应用程序未达到阈值时再执行后续步骤，可避免因虚拟屏上启动的应用程序过多导致系统资源占用过大影响前台应用的情况。
211.可选地，预加载管理模块可以保存当前使用的虚拟屏参数。以便记录当前被用于预加载应用程序的虚拟屏。
212.s1526、预加载管理模块向ams发送确定启动该应用程序的界面的指示。
213.s1527、ams根据预加载模块发送的启动该应用程序的界面的请求中携带的虚拟屏参数和启动参数启动该应用程序的界面到虚拟屏。
214.通常，通过ams将应用程序启动到虚拟屏时，该应用程序能够在虚拟屏上运行显示到第一界面，该第一界面即用户期望的界面，可以是应用程序冷启动后无用户操作情况下最终停留的界面，如主界面或登陆界面等。
215.相应地，当该应用程序启动到虚拟屏上时，虚拟屏上的应用程序数量会相应加1。
216.可选地，ams在启动该应用程序的界面到虚拟屏时，还可以向activityrecord指示显示该应用程序的窗口(如发送showstartingwindow()指示)，以指示其不显示该应用程序的启动动效。如此，能够使应用程序在预加载到虚拟屏时不显示启动动效，从而降低对应用程序进行预加载时的系统负载。
217.可选地，在s1526之后预加载管理模块还可以将该应用程序从正在预加载应用程序的队列移入已完成预加载的应用程序队列中。
218.或者，在ams启动该应用程序的界面到虚拟屏时，可以为ams启动的该应用程序的activity对应的activityrecord对象设置一个预加载标签(flag)以指示该应用程序为预加载到虚拟屏的应用程序。例如，该预加载标签为默认值(如0)时表示应用程序不是预加载到虚拟屏的应用程序，当预加载标签为指定值(如1)时表示应用程序是预加载到虚拟屏的应用程序。
219.当应用程序被预加载到虚拟屏之后，用户对相应应用程序进行启动操作(如用户点击相应的应用程序的图标)时，相应的应用程序便能够从虚拟屏显示切换到在主屏上进行显示。从而，预加载到虚拟屏上的应用程序在被用户主动启动时，相应应用程序的界面便能够直接显示到主屏上，而不需要用户等待，从而提高用户启动应用程序时的使用体验。
220.基于前述实施方式，电子设备可以对用户的操作行为进行预测，以在用户启动某个应用程序之前，先将该应用程序预加载到虚拟屏。从而当用户想要启动相应的应用程序时，电子设备能够直接将相应的应用程序的可操作界面由虚拟屏切换显示在主屏上，从而减小用户启动相应用程序的感知时间(启动应用程序的感知时间，即从用户对应用程序进行启动操作到电子设备主屏显示该应用程序的可操作界面所经历的时间)。如此，能够提高用户启动应用程序时的流畅体验，提高电子设备在用户启动应用程序时的响应速度。
221.基于前述实施方式，图20为本技术实施例提供的一种应用程序加载方法的流程示意图。该方法可以包括以下s2001-s2007。
222.s2001、预测出一个或多个预加载应用程序。
223.s2002、对预加载应用程序分别进行入参合法性校验。
224.s2003、遍历预加载应用程序中入参合法性校验通过的应用程序，以确定出准备预加载的应用程序并添加到预加载准备队列中。
225.示例地，遍历预加载应用程序中入参合法性校验通过的应用程序，以确定出准备预加载的应用程序并添加到预加载准备队列中可以是，对于入参合法性校验通过的预加载应用程序中的任一个校验通过的预加载应用程序：确定该校验通过的预加载应用程序为准备预加载的应用程序时，将该校验通过的预加载应用程序添加到预加载准备队列中。
226.其中，确定该校验通过的预加载应用程序为准备预加载的应用程序的方式，可以包括以下至少一种：
227.确定该校验通过的预加载应用程序已安装；
228.确定该校验通过的预加载应用程序不在预加载准备队列中；
229.确定当前正在预加载的应用程序的数量以及准备预加载的应用程序的数量未超过预设数量；
230.确定该校验通过的预加载应用程序不是正在预加载的应用程序、不是已经预加载完成的应用程序、也不是已经运行在前台的应用程序。
231.s2004、每次获取预加载准备队列中的一个准备预加载的应用程序。
232.s2005、获取虚拟屏参数以及该准备预加载的应用程序的启动参数。
233.其中，虚拟屏参数用于标识该虚拟屏。
234.可选地，可以先获取该准备预加载的应用程序对应的加载时所耗系统资源，然后根据当前电子设备的系统资源和该应用程序加载时所耗系统资源，在确定当前电子设备的系统资源支持预加载该准备预加载的应用程序时，再执行s2005。
235.s2006、根据虚拟屏参数和启动参数启动该准备预加载的应用程序的界面到虚拟屏上。
236.可选地，可以在确定虚拟屏参数标识的虚拟屏存在，且确定虚拟屏参数标识的虚拟屏上的应用程序数量未达到阈值时，再执行s2006。
237.以将预加载准备队列中的第一应用程序加载到虚拟屏上为例。
238.s2007、在用户启动第一应用程序时，将第一应用程序从虚拟屏切换至显示屏，并在显示屏上显示第一应用程序的界面。
239.对应于前述实施例中的方法，本技术实施例还提供一种应用程序加载装置。该装置可以应用于上述的电子设备用于实现前述实施例中的方法。该装置的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块。例如，该装置可以包括预测模块、预加载模块、预加载管理模块等如图9所示的系统架构中的模块。通过上述模块相互配合可以实现前述实施例中的方法。示例地，可以参考前述实施例中图15所示的方法。
240.应理解以上装置中单元或模块(以下均称为单元)的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且装置中的单元可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分单元以软件通过处理元件调用的形式实现，部分单元以硬件的形式实现。
241.例如，各个单元可以为单独设立的处理元件，也可以集成在装置的某一个芯片中实现，此外，也可以以程序的形式存储于存储器中，由装置的某一个处理元件调用并执行该单元的功能。此外这些单元全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件又可以称为处理器，可以是一种具有信号的处理能力的集成电路。在实现过程中，上述方法的各步骤或以上各个单元可以通过处理器元件中的硬件的集成逻辑电路实现或者以软件通过处理元件调用的形式实现。
242.在一个例子中，以上装置中的单元可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个asic，或，一个或多个dsp，或，一个或者多个fpga，或这些集成电路形式中至少两种的组合。
243.再如，当装置中的单元可以通过处理元件调度程序的形式实现时，该处理元件可
以是通用处理器，例如cpu或其它可以调用程序的处理器。再如，这些单元可以集成在一起，以片上系统(system-on-a-chip，soc)的形式实现。
244.在一种实现中，以上装置实现以上方法中各个对应步骤的单元可以通过处理元件调度程序的形式实现。例如，该装置可以包括处理元件和存储元件，处理元件调用存储元件存储的程序，以执行以上方法实施例所述的方法。存储元件可以为与处理元件处于同一芯片上的存储元件，即片内存储元件。
245.在另一种实现中，用于执行以上方法的程序可以在与处理元件处于不同芯片上的存储元件，即片外存储元件。此时，处理元件从片外存储元件调用或加载程序于片内存储元件上，以调用并执行以上方法实施例所述的方法。
246.例如，本技术实施例还可以提供一种装置，如：电子设备，可以包括：处理器，用于存储该处理器可执行指令的存储器。该处理器被配置为执行上述指令时，使得该电子设备实现如前述实施例中电子设备实施的应用程序加载方法。该存储器可以位于该电子设备之内，也可以位于该电子设备之外。且该处理器包括一个或多个。
247.在又一种实现中，该装置实现以上方法中各个步骤的单元可以是被配置成一个或多个处理元件，这些处理元件可以设置于对应上述的电子设备上，这里的处理元件可以为集成电路，例如：一个或多个asic，或，一个或多个dsp，或，一个或者多个fpga，或者这些类集成电路的组合。这些集成电路可以集成在一起，构成芯片。
248.例如，本技术实施例还提供一种芯片系统，该芯片系统可以应用于上述电子设备。芯片系统包括一个或多个接口电路和一个或多个处理器；接口电路和处理器通过线路互联；处理器通过接口电路从电子设备的存储器接收并执行计算机指令，以实现以上方法实施例中电子设备相关的方法。
249.本技术实施例还提供一种计算机程序产品，包括电子设备，如上述电子设备，运行的计算机指令。
250.通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
251.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
252.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
253.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单
元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
254.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，如：程序。该软件产品存储在一个程序产品，如计算机可读存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
255.例如，本技术实施例还可以提供一种计算机可读存储介质，其上存储有计算机程序指令。当计算机程序指令被电子设备执行时，使得电子设备实现如前述方法实施例中所述的应用程序加载方法。
256.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。