CN115562742A - 应用启动方法、电子设备及可读存储介质 - Google Patents

Abstract

本申请提供一种应用启动方法、电子设备及可读存储介质，涉及终端应用技术领域，可以解决应用启动响应时间较长的问题。该方法包括：在电子设备中的应用启动时，可以根据该应用之前冷启动时的应用启动时长预估本次启动时的进程启动时长和Activity加载时长之和，并根据该应用本次启动时，该应用的进程的状态(是否已经启动)以及预估的本次启动时的进程启动时长和Activity加载时长之和等参数，确定本次启动时应用启动响应时长，在该响应时长较长时，将快照页作为启动页，由于快照页和应用启动后显示的界面相似或相同，认为显示快照页时应用已经启动完成，因此，应用启动响应时间较短，用户体验较好；在该响应时长较短时，可以将其他页面作为启动页。

Description

应用启动方法、电子设备及可读存储介质

技术领域

本申请涉及终端应用领域，尤其涉及应用启动方法、电子设备及可读存储介质。

背景技术

随着电子设备的智能化程度越来越高，电子设备中安装运行的应用软件也越来越多。当用户使用应用软件提供的服务时，用户需要执行操作启动应用软件，例如，用户点击电子设备的系统桌面上应用软件的图标，电子设备可以打开应用软件以显示应用软件提供的界面。

电子设备启动应用软件时电子设备系统内部需要进行处理得到应用软件的界面，所以，在用户的操作结束后，电子设备可能会延迟一段时间才能显示应用软件的界面。目前，在该段时间可以显示应用软件的logo页等。然而，从用户的角度，应用软件的启动响应时长(从用户触发启动应用软件的时刻到应用软件显示应用软件的界面)较长，用户体验较差。

发明内容

本申请提供一种应用启动方法、电子设备及可读存储介质，可以提高应用软件的启动响应速度，提高用户体验。

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

第一方面，本申请提供一种应用启动方法，该方法包括：

电子设备接收用户输入的第一操作，第一操作作用于第一应用的图标；

响应于第一操作，电子设备启动第一应用的第一进程，电子设备显示第一界面，第一界面包括：广告页、Logo页或空白页；

电子设备显示第一应用的第二界面，第二界面包括第一控件；

响应于作用于第一控件的第二操作，电子设备显示第一应用的第三界面；

响应于第三操作，电子设备显示第一应用的第二界面；

电子设备接收用户输入的第四操作；

响应于第四操作，电子设备将第一应用切换到后台运行；

电子设备销毁第一进程；

电子设备接收用户输入的第五操作；

响应于第五操作，电子设备启动第一进程，电子设备显示第一图像，电子设备显示第二界面，其中，第一图像为包含第一控件的图像。

本申请可以在应用退后台后，应用在后台被系统杀掉再次启动时显示电子设备的快照图像(上一次退后台时显示的最后界面对应的图像，即第一图像)，再显示电子设备上一次退后台时显示的最后界面(第二界面)。从用户的角度，认为电子设备显示快照图像时就已经启动完成，因此，从用户的角度，提高了应用的启动响应速度。

作为本申请第一方面的一种实现方式，电子设备销毁第一进程之后，电子设备接收用户输入的第五操作之前，该方法还包括：

电子设备启动第一进程；

电子设备接收用户输入的第五操作之后，该方法还包括：

响应于第五操作，电子设备启动第一应用的第一活动，电子设备显示第一图像，电子设备显示第二界面，其中，第一图像为包含第一控件的图像，第一活动用于生成第二界面。

本申请中，若电子设备接收用户输入的第五操作之前，电子设备的第一进程已经在后台自启，也可以先显示电子设备的快照图像(上一次退后台时显示的最后界面对应的图像，即第一图像)，再显示电子设备上一次退后台时显示的最后界面(第二界面)。从用户的角度，认为电子设备显示快照图像时就已经启动完成，因此，从用户的角度，提高了应用的启动响应速度。

作为本申请第一方面的另一种实现方式，该方法还包括：

电子设备显示第二应用的第四界面，第四界面包括第二控件；

响应于作用于第二控件的第六操作，电子设备显示第二应用的第五界面；

响应于第七操作，电子设备显示第二应用的第四界面；

电子设备接收用户输入的第八操作；

响应于第八操作，电子设备将第二应用切换到后台运行；

电子设备销毁第二应用的第二进程；

电子设备接收用户输入的第九操作；

响应于第九操作，电子设备启动第二进程，电子设备显示第六界面，电子设备显示第四界面，其中，第六界面包括：广告页、Logo页或空白页。

本申请中，针对不同的应用，可能显示的启动页不同，作为示例，第二应用冷启动时可能显示的为广告页、Logo页或空白页，而不是快照页。

作为本申请第一方面的另一种实现方式，电子设备显示第一图像之前，该方法还包括：

电子设备确定电子设备中存储有第一图像的索引；

电子设备确定第一应用的应用启动响应时长小于第一值，应用启动响应时长为电子设备接收第五操作至电子设备显示第二界面之间的时长；

电子设备确定第一应用的任务栈中存储有第一活动，第一活动用于生成第二界面；

电子设备获取电子设备中存储的第一图像的索引和第一应用的窗口信息，第一图像的索引用于表示第一图像在电子设备中的存储位置，第一应用的窗口信息包括电子设备显示第一图像时的显示参数。

本申请中，若在应用在后台被杀过的情况下，应用再次启动时，需要确定第一应用的任务栈中存储有第一活动，以确保电子设备启动后显示的第一应用的界面和快照的内容相同相似；还需要确定该电子设备中存储的第一图像的索引和第一应用的窗口信息，以确保能够获取到快照从而基于窗口信息显示快照；为了获得较好的体验，可以设置第一应用本次启动时的响应时长较短(小于第一值)的情况，显示快照页；这是由于若响应时长较长(大于或等于第一值)，则显示的快照页时间较长，用户误以为显示快照页为应用真实的界面，用户在快照页上进行操作后，应用不会有响应，导致用户体验较差。

作为本申请第一方面的另一种实现方式，电子设备显示第六界面之前，该方法还包括：

电子设备确定电子设备中存储有第二图像的索引，第二图像为包含第二控件的图像；

电子设备确定第二应用的应用启动响应时长大于或等于第一值。

本申请中，可以将响应时长较长(大于或等于第一值)时，将广告页、Logo页或空白页作为启动页。

作为本申请第一方面的另一种实现方式，电子设备接收用户输入的第五操作之后，该方法还包括：

电子设备确定第一进程是否启动；

在第一进程未启动的情况下，电子设备确定第一应用的应用启动响应时长为第一时长，第一时长由第一应用历史冷启动时的历史应用启动时长确定；

在第一进程已启动的情况下，电子设备确定第一进程已启动时长；

在第一进程已启动时长大于或等于第二时长的情况下，确定第一应用的应用启动响应时长为第三时长，第二时长由第一应用历史冷启动时的历史进程启动时长确定，第三时长由第一应用历史冷启动时的历史应用启动时长和历史进程启动时长确定；

在第一进程已启动时长小于第二时长的情况下，确定第一应用的应用启动响应时长为第四时长，第四时长由第一应用的历史冷启动时的历史应用启动时长和第一进程已启动时长确定。

作为本申请第一方面的另一种实现方式，电子设备确定第一进程是否启动包括：

电子设备获取第一进程的processrunning标志位；

在processrunning标志位为第一标识符的情况下，电子设备确定第一进程已启动；

在processrunning标志位不为第一标识符的情况下，电子设备确定第一进程未启动。

作为本申请第一方面的另一种实现方式，电子设备确定第一进程已启动时长包括：

电子设备计算当前时刻与第一进程的开始启动时刻的第二差值，第一进程的已启动时长为第二差值，第一进程的开始启动时刻为第一进程的processrunning标志位最后一次变为第一标识符的时刻。

或者，电子设备计算接收第五操作的时刻与第一进程的开始启动时刻的第三差值，第一进程的已启动时长为第三差值；

或者，电子设备计算第一时刻与第一进程的开始启动时刻的第四差值，第一时刻为电子设备接收第五操作的时刻至当前时刻之间的任一时刻，第一进程的已启动时长为第四差值。

作为本申请第一方面的另一种实现方式，该方法还包括：

电子设备获取第一应用历史上最后N次冷启动时的历史应用启动时长和历史进程启动时长，N为大于或等于1的自然数；

电子设备根据第一应用历史上最后N次冷启动时的历史应用启动时长得到第二值，第二值为预估的第一应用本次启动时的进程启动时长和Activity加载时长之和；

电子设备根据第一应用历史上最后N次冷启动时的历史进程启动时长得到第三值，第三值为预估的第一应用本次启动时的进程启动时长；

其中，第一时长为第二值，第二时长为第三值，第三时长为第二值减去第三值，第四时长为第二值减去第一进程已启动时长。

作为本申请第一方面的另一种实现方式，电子设备根据第一应用历史上最后N次冷启动时的历史应用启动时长得到第二值包括：

电子设备获取第一应用历史上最后N次冷启动时的历史应用启动时长以及分别对应的权重，N为大于或等于2的自然数；

电子设备计算历史上最后N次冷启动时的历史应用启动时长的加权平均值，得到第二值；

电子设备根据第一应用历史上最后N次冷启动时的历史进程启动时长得到第三值包括：

电子设备获取历史上最后N次冷启动时的历史进程启动时长以及分别对应的权重；

电子设备计算历史上最后N次冷启动时的历史进程启动时长的加权平均值，得到第三值。

作为本申请第一方面的另一种实现方式，历史上最后N次冷启动时的第i次冷启动的时刻小于第j次冷启动时的时刻，第i次冷启动时的历史应用启动时长的权重小于或等于第j次冷启动时的历史应用启动时长的权重，第i次冷启动时的历史进程启动时长的权重小于或等于第j次冷启动时的历史进程启动时长的权重，i和j均为小于或等于N的正整数，i不等于j。

作为本申请第一方面的另一种实现方式，第i次冷启动时应用启动时长的权重为S^N-i，S为衰减系数。

作为本申请第一方面的另一种实现方式，N等于1。

作为本申请第一方面的另一种实现方式，在第一进程未启动的情况下，该方法还包括：

在第一进程启动完成之后，电子设备通过第一进程将第一进程的本次进程启动时长发送给systemserver进程；

电子设备从systemserver进程获取本次进程启动时长；

电子设备将本次进程启动时长存储，本次进程启动时长为第一应用下次启动时的历史进程启动时长。

作为本申请第一方面的另一种实现方式，在第一进程未启动的情况下，该方法还包括：

在电子设备显示第二界面之后，电子设备通过ActivityMetricsLogger获取第二界面的绘制完成的第一时刻和电子设备检测到第五操作的第二时刻；

电子设备通过ActivityMetricsLogger计算第一时刻和第二时刻的差值，得到第一应用的本次应用启动时长；

电子设备将本次应用启动时长存储，本次应用启动时长为第一应用下次启动时的历史应用启动时长。

作为本申请第一方面的另一种实现方式，电子设备接收用户输入的第四操作之后，该方法还包括：

电子设备基于第二界面生成第一图像，存储第一图像；

电子设备在第一存储空间缓存第一图像的索引。

本申请中，在应用退后台时可以存储该应用退后台前显示的最后界面的图像，并存储，还可以将快照索引存储在第一存储空间。

作为本申请第一方面的另一种实现方式，电子设备销毁第一应用的第一进程之后，该方法还包括：

电子设备从第一存储空间获取第一图像的索引；

电子设备从windowstate获取第一应用的窗口信息；

电子设备在第二存储空间缓存第一图像的索引和第一应用的窗口信息；

电子设备在任务栈中缓存第一应用的任务栈顶部的活动，第一应用的任务栈顶部的活动为第一活动。

由于在系统原生流程中，应用在后台被杀后，电子设备会删除第一存储空间的快照索引，会清除windowstate记录的第一应用的窗口信息，因此，电子设备需要将第一存储空间的快照索引和windowstate记录的第一应用的窗口信息缓存在第二存储空间，以在再次启动时可以得到快照索引和窗口信息。另外，由于任务栈中的活动依赖于windowstate记录的信息，在应用在后台被杀时，若清除了windowstate，则再次启动时无法获取到任务栈顶部的Activity(活动)。因此，还需要将第一应用的任务栈顶部的Activity再次缓存在任务栈中。

作为本申请第一方面的另一种实现方式，在电子设备缓存第一图像的索引、第一应用的窗口信息和第一活动之后，该方法还包括：

电子设备删除第一存储空间缓存的第一图像的索引；

电子设备删除windowstate记录的第一应用的窗口信息。

作为本申请第一方面的另一种实现方式，电子设备获取电子设备中存储的第一图像的索引和第一应用的窗口信息包括：

电子设备从第二存储空间获取第一图像的索引和第一应用的窗口信息。

作为本申请第一方面的另一种实现方式，电子设备从第二存储空间获取第一图像的索引和第一应用的窗口信息之前，该方法还包括：

电子设备从第一存储空间未获取到第一图像的索引。

作为本申请第一方面的另一种实现方式，电子设备确定第一应用的任务栈中存储有第一活动包括：

电子设备通过Tasksnapshotsurface向第一应用的任务栈发送第一请求，第一请求用于获取第一应用的任务栈中缓存的第一活动；

在电子设备从第一应用的任务栈中获取到缓存的第一活动的情况下，电子设备确定第一应用的任务栈中存储有第一活动。

作为本申请第一方面的另一种实现方式，在电子设备通过Tasksnapshotsurface向第一应用的任务栈发送第一请求之前，该方法还包括：

电子设备通过Tasksnapshotsurface向第一应用的任务栈发送第二请求，第二请求用于获取第一应用的任务栈中记录的第一活动；

电子设备基于第二请求未获取到第一活动。

作为本申请第一方面的另一种实现方式，电子设备确定第一应用的任务栈中存储有第一活动之前，该方法还包括：

电子设备通过Tasksnapshotsurface从Activityrecord获取第一应用的任务栈。

作为本申请第一方面的另一种实现方式，在电子设备缓存第一图像的索引、第一应用的窗口信息和第一活动之后，该方法还包括：

在电子设备的显示配置被修改的情况下，电子设备删除第二存储空间缓存的窗口信息和第一图像的索引，删除第一应用的任务栈中缓存的第一活动；

在第二存储空间存储的第一图像的索引和第一应用的窗口信息的时长大于第五时长的情况下，电子设备删除第二存储空间缓存的窗口信息和第一图像的索引，删除第一应用的任务栈中缓存的第一活动；

在电子设备关机或重启的情况下，电子设备删除第二存储空间缓存的窗口信息和第一图像的索引，删除第一应用的任务栈中缓存的第一活动；

在电子设备卸载第一应用的情况下，电子设备删除第二存储空间缓存的窗口信息和第一图像的索引，删除第一应用的任务栈中缓存的第一活动。

本申请中，由于电子设备的显示配置被修改后，快照页的显示方式和应用启动后的界面的内容可能存在不同，导致用户体验不好，因此，可以在显示配置被修改的情况下，该电子设备删除缓存的信息。当然，缓存的信息缓存时间过长的情况下，应用的界面可能发生变化，避免快照页和应用启动后的界面的内容可能存在不同，导致用户体验不好，因此，可以在缓存时间过长的情况下，该电子设备删除缓存的信息。另外，在电子设备卸载第一应用、电子设备关机或重启的情况下，电子设备将删除该应用的相关信息，相应的，缓存信息会一并删除。

作为本申请第一方面的另一种实现方式，显示参数包括屏幕适配信息和窗口属性信息。

第三方面，本申请提供一种应用启动方法，该方法包括：

电子设备显示第一应用的第二界面，第二界面包括第一控件；

响应于作用于第一控件的第二操作，电子设备显示第一应用的第三界面；

响应于第三操作，电子设备显示第一应用的第二界面；

电子设备接收用户输入的第四操作；

响应于第四操作，电子设备将第一应用切换到后台运行；

电子设备销毁第一应用的第一进程；

电子设备启动第一进程；

电子设备接收用户输入的第五操作；

响应于第五操作，电子设备启动第一活动，电子设备显示显示第一界面，电子设备显示第二界面，其中，第一活动用于生成第二界面，第一界面包括：广告页、Logo页或空白页；

响应于作用于第一控件的第二操作，电子设备显示第一应用的第三界面；

响应于第三操作，电子设备显示第一应用的第二界面；

电子设备接收用户输入的第四操作；

响应于第四操作，电子设备将第一应用切换到后台运行；

电子设备销毁第一进程；

电子设备启动第一进程；

电子设备接收用户输入的第五操作；

响应于第五操作，电子设备启动第一活动，电子设备显示第一图像，电子设备显示第二界面，其中，第一图像为包含第一控件的图像。

本申请中，若电子设备接收用户输入的第五操作之前，第一应用的第一进程已经在后台自启，也可以先显示电子设备的快照图像(上一次退后台时显示的最后界面对应的图像，即第一图像)，再显示电子设备上一次退后台时显示的最后界面(第二界面)。从用户的角度，认为电子设备显示快照图像时就已经启动完成，因此，从用户的角度，提高了应用的启动响应速度。

当然，实际应用中，也可以设置第一值，预估第一应用的启动响应时长，将启动响应时长与第一值进行比较，在启动响应时长小于第一值的情况下，将快照页作为启动页；在在启动响应时长大于或等于第一值的情况下，将logo页、空白页或广告页作为启动页。

第三方面，提供一种电子设备，包括处理器，处理器用于运行存储器中存储的计算机程序，实现本申请第一方面任一项的方法。

第四方面，提供一种芯片系统，包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现本申请第一方面任一项的方法。

第五方面，提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被一个或多个处理器执行时实现本申请第一方面任一项的方法。

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

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

附图说明

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

图2为本申请实施例提供的一种应用启动时的界面变化示意图；

图3为本申请实施例提供的另一种应用启动时的界面变化示意图；

图4为本申请实施例提供的另一种应用启动时的界面变化示意图；

图5为本申请实施例提供的一种应用启动退后台的流程示意图；

图6为本申请实施例提供的一种改进的应用启动退后台的流程示意图；

图7为本申请实施例提供的触发应用启动的操作界面示意图；

图8为本申请实施例提供的一种应用启动方法的时序图；

图9为本申请实施例提供的另一种应用启动方法的时序图；

图10为本申请实施例提供的另一种应用启动方法的时序图；

图11为本申请实施例提供的一种应用启动方法的流程示意图；

图12为本申请实施例提供的一种应用冷启动时的时间关系示意图；

图13为本申请实施例提供的另一中应用冷启动时的时间关系示意图；

图14为本申请实施例提供的一种应用温启动时的时间关系示意图；

图15为本申请实施例提供的另一应用温启动时的时间关系示意图；

图16为本申请实施例提供的一种应用启动时的流程示意图；

图17为本申请实施例提供的一种应用启动方法的技术架构图；

图18为本申请实施例提供的一种应用启动方法的时序图；

图19为本申请实施例提供的一种应用启动时的界面变化示意图；

图20为本申请实施例提供的另一种应用启动方法的时序图；

图21为本申请实施例提供的另一种应用启动方法的时序图；

图22为本申请实施例提供的另一种应用启动方法的时序图；

图23为本申请实施例提供的另一种应用启动方法的时序图；

图24为本申请实施例提供的另一种应用启动方法的时序图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”、“第四”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

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

本申请实施例提供的一种应用启动方法，可以适用于电子设备中。该电子设备可以为平板电脑、手机、可穿戴设备、笔记本电脑、超级移动个人计算机(ultra-mobilepersonal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等电子设备。本申请实施例对电子设备的具体类型不作限定。

图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，摄像头193，显示屏194，以及用户标识模块(subscriberidentification module，SIM)卡接口195等。其中，传感器模块180可以包括压力传感器180A，触摸传感器180K等。

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

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

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

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

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。

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

内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)。

此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。

在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

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

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

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。

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

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信号转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了监听语音信息，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。

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

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

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。

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

显示屏194用于显示图像，视频等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

摄像头193用于捕获静态图像或视频。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。

本申请实施例并未特别限定一种应用启动方法的执行主体的具体结构，只要可以通过运行记录有本申请实施例的一种应用启动方法的代码，以根据本申请实施例提供的一种应用启动方法进行处理即可。例如，本申请实施例提供的一种应用启动方法的执行主体可以是电子设备中能够调用程序并执行程序的功能模块，或者为应用于电子设备中的处理装置，例如，芯片。

电子设备中可以安装并运行应用。电子设备在前台运行应用A(电子设备中安装的任一应用)时，电子设备的显示屏显示应用A的界面，电子设备的使用者可以与电子设备的显示屏当前显示的应用A的界面进行交互操作。电子设备在后台运行应用A时，电子设备不再显示应用A的界面，电子设备的使用者不能与应用A的界面进行交互操作；当然，应用A在后台运行过程中可以接收到其他信息(例如，即时通讯应用可以接收其他用户发送的消息)并将该其他信息通知用户。

用户在使用电子设备过程中，若应用A未运行(未在后台运行也未在前台运行)，用户通过电子设备桌面上的应用A的图标启动应用A，电子设备首先为该应用创建并启动该应用的进程，在应用A的进程已经完成启动后，通过该进程加载应用A的Activity(例如Activity1)，Activity1进入任务栈，且位于任务栈的顶部，电子设备显示Activity1对应一个界面1。用户可以通过Activity1对应的界面1进行交互操作，若该交互操作将使得电子设备显示另一新的界面，则系统中应用A的进程加载另一新的Activity(例如Activity2)，该Activity2将进入任务栈且位于任务栈顶部，旧的Activity1将被推入任务栈的下面。相应的，电子设备的显示屏显示Activity2对应的界面2，旧的Activity1的界面被销毁。当然，用户可以通过在Activity2对应的界面2上进行交互操作(例如，返回操作)，使得任务栈中的Acitivity1回到任务栈的顶部，则Activity2被销毁，相应的，电子设备的显示屏显示任务栈顶部Activity1对应的界面1。

通过上述描述可以理解，应用显示的各个界面依赖于应用的进程加载各个Activity。另外，在应用从前台进入后台运行后，该应用的进程可以依然存在于系统中(例如，该应用的进程未消亡)。若用户点击该应用的图标使得该应用再到前台运行时，由于系统后台存在该应用的进程，则系统不再需要为应用创建并启动进程；若应用的Activity仍然存在于系统内存中，则应用不需要重复Activity初始化、渲染、绘制操作，而是将应用的任务栈顶部的Activity对应的界面在前台显示，这种启动过程记为热启动。

在应用从前台进入后台运行后，该应用的进程可以依然存在于系统中(例如，该应用的进程未消亡)。若该应用在后台被杀掉(该应用的进程被销毁、Activity被回收)，这种情况下，系统后台不存在该应用的进程。然而，该应用的进程被销毁后，该应用还可能存在自启行为，即该应用可以在后台自行请求系统为该应用创建并启动进程。如在系统后台成功创建并启动应用的进程后，用户点击该应用的图标使得该应用再到前台运行时，由于系统后台存在该应用的进程，则系统不再需要为应用创建并启动进程；由于应用的Activity之前已经被回收，则系统需要通过该应用的进程加载该应用的Activity，直到加载成功Activity后显示该应用的界面(加载成功的Activity对应的界面)，将这种启动过程记为温启动。

在应用从前台进入后台运行后，该应用的进程也可能被销毁，同时，Activity被回收，即系统后台不存在该应用的进程。若用户点击该应用的图标使得该应用再到前台运行时，由于系统后台不存在该应用的进程，则系统需要为该应用创建并启动进程，在该进程完成启动后，通过该应用的进程加载该应用的Activity，直到加载成功Activity后显示该应用的界面(加载成功的Activity对应的界面)，将这种启动过程记为冷启动。

作为冷启动的另一示例，电子设备开机后，首次启动某个应用时，该应用的启动过程也为以上描述的冷启动。

在实际应用中，在应用从前台进入后台运行后，该应用被杀掉(该应用的进程被销毁、Activity被回收)，这种情况下，系统后台不存在该应用的进程。然而，该应用的进程被销毁后，该应用还可能存在自启行为，即该应用可以在后台自行请求系统为该应用创建并启动进程。在用户点击该应用的图标使得该应用再到前台运行时，应用根据该应用的进程的当前状态(例如，该应用的进程可能在启动过程中，也可能已经启动完成，还可能未创建)继续执行后续操作，直到显示该应用的界面。这种启动方式可能为冷启动也可能为温启动。

无论是冷启动还是温启动，电子设备均需要进行一系列处理(例如，通过应用进程加载应用的Activity)，才能显示应用的界面。从用户点击应用图标到显示应用的界面，需要经过一段时间，实际应用中，在该段时间电子设备可以显示启动页。启动页为应用启动时，在电子设备显示应用本身的界面(例如，主界面、上一次退回到后台前显示的最后界面)之前显示的页面，该页面记为启动页。该启动页可以包括广告页、空白页、Logo页和快照页。为了便于描述，可以将广告页、空白页和Logo页统称为过渡页。即启动页包括过渡页和快照页。关于过渡页和快照页的示例具体可参照图2至图4所述的实施例。

作为启动页的一种场景示例，参见图2，为本申请实施例提供的一种冷启动或温启动应用时的界面变化示意图。以启动时系统后台不存在应用的任务栈为例。

参见图2中的(a)，用户在系统桌面点击应用的图标，若应用当前的启动方式为冷启动或温启动，由于启动时系统后台不存在应用的任务栈，则电子设备在启动完成后显示应用的主界面参见图2中的(d)所示的主界面。

实际应用中，在电子设备显示图2中的(d)所示的完整界面之前，通常会存在显示图2中的(c)所示的界面的过程。图2中的(c)所示的界面为电子设备绘制图2中的(d)所示的界面之前对应的启动窗口(startWindow)的界面。当然，实际应用中，由于电子设备的显示屏刷新频率较快，从用户的视角，可能并未感知到电子设备显示图2中的(c)所示的启动窗口的界面的过程，而是直接感知到电子设备显示图2中的(d)所示的界面。本申请实施例对是否能够感知到显示图2中的(c)所示的界面不做限定。

以电子设备冷启动应用时为例，在用户点击应用的图标之后，参见图2中的(e)，电子设备首先加载logo页(在此期间依然显示系统桌面)，以得到logo页对应界面，在得到logo页对应的界面之后，电子设备显示logo页。当然，在电子设备显示logo页期间，系统会创建并启动应用的进程，在成功创建应用的进程后，通过应用的进程加载主界面对应的Activity1，在加载Activity1期间，首先得到Activity1对应的主界面的启动窗口。在得到启动窗口之后，电子设备显示启动窗口，系统继续且在启动窗口中添加view，得到Activity1对应的主界面的首帧；在得到Activity1对应的主界面的首帧之后，电子设备界面1的首帧。因此，电子设备需要经过一段时间进行创建并启动进程的操作、加载Activity的操作等才能得到图2中的(c)所示的启动窗口的界面，所以，在该段时间可以显示过渡页，具体可参见图2中的(b)所示的logo页。图2中的(b)所示的界面仅以logo页为例进行说明，实际应用中，还可以是应用的广告页、空白页等。

当然，实际应用中，电子设备温启动应用时若系统后台不存在应用的任务栈，则启动页也为所述过渡页，只是系统可能不在创建应用的进程，而是可以直接采用应用的进程加载Activity1。不再进行举例。

作为启动页的另一种场景示例，参见图3，为本申请实施例提供的一种冷启动或温启动时的界面变化示意图。以启动时系统后台存在应用的任务栈为例。

参见图3中的(a)，电子设备中的应用显示界面1，用户通过手势(例如，图中由电子设备的显示屏底部向上滑动的手势)触发应用A退回到后台运行。

参见图3中的(b)，电子设备保存界面为快照。该快照可以不包括状态栏内容。

参见图3中的(c)，应用退回到后台运行后，电子设备可以显示系统桌面，用户在系统桌面点击应用的图标，若应用当前的启动方式为冷启动或温启动，且启动时系统后台存在应用的任务栈，则电子设备在启动完成后显示应用的上一次退回到后台前显示的最后界面。参见图3中的(f)。

实际应用中，在电子设备显示图3中的(f)所示的完整界面之前，通常会存在显示图3中的(e)所示的界面的过程。图3中的(e)所示的界面为电子设备绘制图3中的(f)所示的界面之前对应的启动窗口(startWindow)的界面。当然，实际应用中，由于电子设备的显示屏刷新频率较快，从用户的视角，可能并未感知到电子设备显示图3中的(e)所示的启动窗口的界面的过程，而是直接感知到电子设备显示图3中的(f)所示的界面。本申请实施例对是否能够感知到显示图3中的(e)所示的界面不做限定。

以电子设备冷启动应用时为例，在用户点击应用的图标之后，参见图3中的(g)，具体可参照图2中的(e)的相关描述。只是，由于该应用的任务栈未被销毁，电子设备加载的为上一次退回到后台前显示的最后界面对应的Activity2。同图2中所描述，电子设备需要经过一段时间进行创建并启动进程的操作、加载Activity的操作等才能得到图3中的(e)所示的启动窗口的界面，所以，在该段时间可以显示过渡页，具体可参见图3中的(d)所示的logo页。图3中的(d)所示的界面仅以logo页为例进行说明，实际应用中，还可以是应用的广告页、空白页等。

当然，实际应用中，电子设备温启动应用时若系统后台存在应用的任务栈，则启动页也为所述过渡页，只是系统可能不在创建应用的进程，而是可以直接采用应用的进程加载Activity2。不再进行举例。

作为启动页的另一种场景示例，参见图4，为本申请实施例提供的一种热启动应用时的界面变化示意图。

图4中的(a)至图4中的(c)可以参见图3中的(a)至图3中的(c)的相关描述，在此不再赘述。

参见图4中的(c)，用户在系统桌面点击应用的图标，若应用当前的启动方式为热启动，则电子设备在启动完成后显示应用上一次退回到后台前显示的最后界面，具体可参见图4中的(f)所示的上一次退回到后台前显示的最后界面为例。

如上述实施例所理解，在电子设备绘制得到图4中的(f)所示的完整界面之前，通常会存在显示图4中的(e)所示的界面的过程。图4中的(e)所示的界面为电子设备绘制图4中的(f)所示的界面之前对应的启动窗口的界面。当然，实际应用中，由于电子设备的显示屏刷新频率较快，从用户的视角，可能并未感知到电子设备显示图4中的(e)所示的启动窗口的界面的过程，而是直接感知到电子设备显示图4中的(f)所示的界面。本申请实施例对是否能够感知到显示图4中的(e)所示的界面也不做限定。

电子设备在热启动时，在用户点击应用的图标之后，参见图4中的(g)，电子设备首先加载快照页(在此期间依然显示系统桌面)，得到快照页对应的界面，在得到快照页对应的界面后，电子设备显示快照页。由于应用的进程存在，且应用的Activity未被回收，因此，在电子设备显示快照页期间，只要resume任务栈顶部的Activity2，从而先得到Activity2对应的启动窗口，系统继续且在启动窗口中添加view，再得到Activity2对应的界面1的首帧。在得到Activity1对应的主界面的首帧之后，电子设备界面1的首帧。如上述描述，电子设备也需要经过一段时间进行resume Activity2的等操作(例如，绘制渲染等)才能得到图4中的(f)所示的界面，所以，在该段时间可以显示快照页(该应用上一次退回到后台前显示的最后界面对应的图像)，具体可参见图4中的(d)所示的快照页。

通过图2所示场景示例至图4所示场景示例可以理解，本申请实施例提供的启动页包括：过渡页和快照页。图2和图3所示示例中的过渡页和应用启动后显示的界面无关，用户的体验较差。图4所示示例中的快照页通常和应用启动后显示的界面的内容相同或相似，用户的体验优于显示过渡页的体验；然而，在应用的启动时间较长的情况下，用户可能会认为显示的快照页为应用真实的界面，若用户在快照页上进行操作，则应用不会对用户的操作进行响应，用户的体验也较差。

综合两种情况，本申请实施例可以预估用户点击系统桌面上的应用图标的时刻至电子设备显示第一帧应用界面对应的启动窗口中间经历的时间。例如，从图2中的(a)所示的应用图标的点击时刻至电子设备显示图2中的(c)所示的界面中间经历的时间；从图3中的(c)所示的应用图标的点击时刻至电子设备显示图3中的(e)所示的界面中间经历的时间；从图4中的(c)所示的应用图标的点击时刻至电子设备显示图4中的(e)所示的界面中间经历的时间。本申请实施例可以将该段时间记为启动页的显示时长。

另外，由于图2中的(c)所示的界面到图2中的(d)所示的界面中间的时间很短，本申请实施例也可以预估用户点击系统桌面上的应用图标的时刻至电子设备显示第一帧应用界面中间经历的时间。例如，从图2中的(a)所示的应用图标的点击时刻至电子设备显示图2中的(d)所示的第一帧应用界面中间经历的时间；从图3中的(c)所示的应用图标的点击时刻至电子设备显示图3中的(f)所示的第一帧应用界面中间经历的时间；从图4中的(c)所示的应用图标的点击时刻至电子设备显示图4中的(f)所示的第一帧应用界面中间经历的时间。本申请实施例可以将该段时间记为应用的启动响应时长。

通过上述示例可以理解，可以认为应用的启动响应时长和启动页的显示时长相近或相等。在预估的应用的启动响应时长或启动页显示时长较短的情况下，在显示应用的界面之前显示快照页，在预估的应用的启动响应时长或启动页显示时长较长的情况下，在显示应用的界面之前显示过渡页。

然而，在应用图标的点击时刻之后就需要预判显示过渡页还是快照页，所以，需要在应用图标的点击时刻之后首先预估应用本次启动响应时长或启动页显示时长，然后根据预估的应用本次启动响应时长(或启动页显示时长)与预先设置的阈值进行对比，在预估的应用本次启动响应时长(或启动页显示时长)大于或等于阈值的情况下，将过渡页作为启动页显示，在预估的应用本次启动响应时长(或启动页显示时长)小于阈值的情况下，将快照页作为启动页显示。

当然，为了避免将快照页作为启动页显示时，出现快照页与应用的界面不一致的情况，本申请实施例需要在应用的任务栈未被销毁的情况下实施。在应用的任务栈未被销毁(即系统存在应用的任务栈)的情况下，应用再次到前台运行时，系统会通过应用的进程加载任务栈顶部的Activity对应的界面。

在实际应用中，在应用A从前台退回到后台时，虽然保存了应用A在退回到后台前显示的最后界面的快照以及快照索引。然而，在应用A的进程在后台被杀掉时，系统通常会清理掉该应用A的快照索引以及其他信息(例如，应用A的windowstate)，导致在应用A再次启动时(冷启动或温启动)时无法根据快照索引获取应用A的快照以显示应用A的快照页，而是执行过渡页显示流程，再显示应用A的真正的界面。

鉴于此，本申请实施例可以设置：后台的应用满足系统设置的被杀掉的条件时，在清除快照索引之前，先将即将被清理掉的该应用的快照索引从当前存储空间(例如，存储空间A)缓存至另一存储空间(例如，存储空间B)。需要说明，应用在后台被系统杀掉时，存储空间A中缓存的快照索引会被一并清理，然而，存储空间B中缓存的快照索引不会因为应用A在系统后台被杀掉而被清理。在应用再次启动到前台运行时，可以查看存储空间B是否缓存有应用的快照索引；若缓存有上述该应用的快照索引，则基于缓存的应用的快照索引获取快照页。当然，在实际应用中，其他信息(例如，应用A的windowstate)也可以一并存储在存储空间B中。

下面将通过图5和图6描述本申请实施例如何实现在应用在后台被杀后再次启动时可以显示快照页的流程示意图。图5为系统原有流程。

步骤A1，电子设备检测到触发应用A退回到后台的操作。

本申请实施例中触发应用A退回到后台的操作可以为手势导航操作。

作为示例，用户在电子设备的显示屏底部向上滑动，以触发应用A退回到后台运行，同时电子设备显示系统桌面。

当然，实际应用中，用户触发应用A退回到后台运行，电子设备也可以显示系统桌面以外的其他界面。

作为示例，用户通过手势触发电子设备显示侧边导航栏，该侧边导航栏为电子设备侧面出现的悬浮界面，该悬浮界面中包括多个应用的图标，用户点击侧边导航栏中的应用B的图标，则电子设备控制应用A从前台切换到后台，同时电子设备显示应用B的界面。

上述示例均以用户在电子设备的触控屏上的手势作为示例触发电子设备切换应用到后台。实际应用中，还可以通过语音指令或隔空手势的方式进行应用从前台到后台的切换。

作为示例，在电子设备显示应用A的界面的情况下，用户发出“回到系统桌面”的语音信息，则电子设备切换应用A到系统后台，电子设备显示系统桌面。

本申请实施例对应用从前台到后台运行的触发方式不做限定。对该应用到后台运行后，电子设备显示的界面也不做限定。

步骤A2，电子设备检测到触发应用A退回到后台的操作的情况下，存储应用A的快照，缓存应用A的快照索引到存储空间A。

在具体实现时，若触发应用A退回到后台的操作为显示屏底部向上滑动的手势，则系统中的导航组件可以检测到该操作，导航组件通知系统中的ATMS，ATMS向系统中的Snapshot发送指令，该指令用于指示Snapshot生成应用A的快照并存储。Snapshot生成应用A的快照后，将应用A的快照索引缓存在snapshotcache中。存储空间A为该snapshotcache。

当然，触发应用A退回到后台的操作为侧边导航栏上的操作的情况下，则电子设备的侧边导航栏检测到该操作，导航组件通知系统中的ATMS。其他情况不再一一举例。

步骤A3，电子设备检测到应用A满足被杀掉的条件。

通常，系统会设置进程回收机制，在应用到前台运行时，系统为每个应用分配一部分内存，在应用退回到后台后，通常系统不会立即将应用杀掉，而是将退回到后台的应用的相关数据缓存。在系统打开的应用越来越多的情况下，系统后台缓存的进程也越来越多，会占用电子设备很大的内存。若系统内存不足时，系统就会根据本身的进程回收机制杀掉应用(销毁应用的进程)。

步骤A4，电子设备杀掉后台运行的应用A的进程，同时清除存储空间A中缓存的应用A的快照索引。

在应用被杀掉(进程被杀掉)时，该应用的Activity也都会被销毁，该应用的快照索引也会被清理掉。然而，系统提供了一些补救措施，即该应用的任务栈并未被清理掉。所以，在应用满足被杀掉的条件下，该应用的进程可能被销毁，然后该应用的任务栈还存在于系统中。

步骤B1，电子设备检测到触发应用A进入前台运行的操作。

本申请实施例中，应用A进入前台运行的触发操作可以是用户点击系统桌面上应用A的图标的操作。这种情况下，桌面启动器检测到触发应用A进入前台运行的操作。

当然，实际应用中，也可以是通过其他应用跳转到应用A以启动应用A的场景，在这种场景下，其他应用也可以检测到启动应用A的操作。或者，用户点击系统桌面上的小控件的方式启动应用A的场景，在这种场景下，小控件可以检测到启动应用A的操作。

参见图7中的(a)，为从其他应用跳转到应用A以启动应用A的场景。该场景下，电子设备显示其他应用(例如，应用B)的界面，该界面中包括应用A的跳转控件，用户点击应用A的跳转控件，应用B检测到启动应用A的操作，电子设备将启动应用A。

参见图7中的(b)，为用户点击系统桌面上的小控件的方式启动应用A的场景。在用户点击系统桌面上的小控件时，该小控件可以检测到启动应用A的操作。

步骤B2，电子设备判断启动页内容。

本申请实施例中，系统通常会存在判断逻辑，作为示例，在应用为冷启动时，将过渡页(Logo页、广告页、空白页等)作为启动页(显示应用的真实界面之前的界面)。在应用为热启动时，将快照页(应用上一次退回到后台运行前显示的最后界面对应的图像)作为启动页。

步骤B3，电子设备显示过渡页。

在电子设备判断将过渡页作为启动页的情况下，电子设备会得到过渡页Activty对应的界面。然后电子设备显示过渡页对应的界面。

电子设备在显示过渡页对应的界面时，可以一并显示电子设备的状态栏，即电子设备显示的完整界面为过渡页Activity对应的界面和状态栏内容合成后的界面。

当然，实际应用中，电子设备在显示过渡页对应的界面时，也可以不显示电子设备的状态栏，即电子设备显示的完整界面为过渡页Activity对应的界面。

本申请实施例对具体的实现方式不做限定。

步骤B4，电子设备显示应用A的主界面(系统后台不存在应用A的任务栈的情况下)或任务栈顶部Activity对应的界面(系统后台存在应用A的任务栈的情况下)。

电子设备在显示过渡页期间，应用A的进程需要加载主界面的Activity或任务栈顶部Activity对应的界面，在加载完成后，电子设备由显示过渡页变为显示应用A的主界面或任务栈顶部Activity对应的界面。

为了实现应用在后台被杀后再次启动时可以显示快照页，本申请实施例在图5的基础上进行了改进。参见图6，为改进后的流程示意图。

图6所示实施例相比于图5所示实施例进行以下改进：

(1)在步骤A3电子设备检测到应用A满足被杀掉的条件和步骤A4电子设备清除存储空间A中缓存的应用A的快照索引之间，增加步骤A5将存储空间A中缓存的快照索引缓存到存储空间B。

需要说明，实际应用中，在清除存储空间A中缓存的应用A的快照索引之前，将存储空间A缓存的应用A的快照索引存储在存储空间B，在应用A的进程被杀之前还是之后，不做限制。

(2)在步骤B2判断启动页内容中新增以下判断逻辑：

判断存储空间B是否缓存有快照索引(或者其他相关信息)。该判断示例中，可以通过从存储空间B获取快照索引的方式确定是否缓存有快照索引。

判断是否存在应用A的任务栈，任务栈中是否存储有上一次退后台前任务栈顶部的Activity。

当然，实际应用中，还可以增加其他判断逻辑：判断预估的应用启动响应时长(预估的欢迎页显示时长)是否小于预设值。

本申请实施例基于图8所示时序图中的模块实现，当然，实际应用中，这些模块之间的交互还可以通过其他未示出的模块实现。或者某个模块执行某个步骤时，需要调用其他未示出的模块实现。本申请实施例对此不做限定。

参见图8所述的时序图。为本申请实施例提供的图6所示的流程图对应的时序图。

步骤K1，响应于操作A，应用A开始执行退后台处理。

该步骤中，对用于图6中的步骤A1，步骤K1中的操作A为图6中的步骤A1中的触发应用A退回到后台的操作。

步骤K2，应用A向snapshot发送用于保存应用A的快照的消息。

步骤K3，snapshot接收到应用A发送的用于保存应用A的快照的消息后，snapshot保存应用A的快照。

在实际应用中，snapshot可以将快照保存在存储器。

步骤K4，snapshot将应用A的快照的快照索引发送至shapshotcache(可以记为第一存储空间)。

步骤K5，shapshotcache接收到应用A的快照的快照索引后，将缓存快照索引。

其中，步骤K2至步骤K5对应于图6所示流程图中对应的步骤A2。

通过该示例，可以理解，图6所示流程图中的存储空间A为该snapshotcache。

当然，实际应用中，系统还需要进行其他操作才能使得应用A完成退后台流程。

步骤L1，应用A满足系统设置的被杀的条件，开始被杀。

该步骤对应于图6所示流程图中的步骤A3。

步骤L2，应用A触发死亡回调通知windowstate清理应用A的窗口资源。

在实际应用中，每个应用的进程可以加载多个Activity，每个Activity对应一个window(窗口)，每个window负责承载一个界面。其中，window的信息通过windowstate记录。

作为示例，windowstate中记录了布局参数(layoutparam)。layoutparam携带了window中各个layout的位置、高、宽等属性信息。Layout在显示屏上占据一个区域，用于承载添加到该Layout中的view。

当进程加载一个Activity的情况下，系统会新增一个windowstate记录该Activity对应window的信息，系统基于该windowstate记录的window的信息得到该Activity对应的窗口，然后，通过该窗口承载该Activity对应的界面。

当应用在后台被杀时，系统会清理该应用的所有Window，在系统清理该应用的Window时，应用进程通过死亡回调机制通知系统清除记录window信息的windowstate，在清除windowstate时，会一并清理该应用缓存在存储空间A中的快照索引。

当应用下一次启动时，应用进程加载任务栈顶部的Activity，然而，任务栈顶部的Activity已经不存在window(窗口)信息，也不存在快照页导致无法加载快照页。

为解决该问题，可以在系统清除记录window信息的windowstate之前，将快照页以及该应用的Activity的窗口参数进行缓存，以方便下次启动时调用。

步骤L3，windowstate从SnapshotCache获取应用退回后时缓存的快照索引。

步骤L4，windowstate将自身记录的窗口信息和获取到的快照索引缓存到信息缓存模块(可以记为第二存储空间)中。

步骤L5，信息缓存模块接收到windowstate发送的快照索引和窗口信息之后，缓存快照索引和窗口信息至信息缓存模块对应的cache中。通过该示例可以理解，图6所示流程图中的存储空间B为信息缓存模块对应的cache。

其中，步骤L3至步骤L5对应于图6所示的流程图中的步骤A5。另外，应用在后台被杀时的缓存信息参见表1所示。

表1应用在后台被杀时缓存的信息

该缓存的信息中可以包括快照索引，还可以包括电子设备显示第一图像时的显示参数，例如，屏幕适配信息、窗口属性信息等。

作为屏幕适配信息的一种示例，可以包括sysUiVis，dimAmount等。

作为窗口属性信息的一种示例，可以包括windowFlags、privateFlags等。

本申请实施例对上述参数属于屏幕适配信息还是窗口属性信息不做限定。将上述信息分为屏幕适配信息和窗口属性信息仅作为一种示例，并不对本申请造成限制。

当然，实际应用中，还可以包括相比于上述信息更多的信息。

步骤L6，信息缓存模块向task发送缓存标志位为true的消息。

该缓存标志位用于表示从信息缓存模块获取快照索引和窗口信息。当该缓存标志位为true时，表示应用在后台被杀时，已经将存储空间A中缓存的快照索引缓存在存储空间B中，同时，已经将应用的任务栈顶部的Activity对应的窗口信息缓存在存储空间B中。

步骤L7，task将缓存标志位修改为true。

步骤L8，task从windowstate获取栈顶的Activity的相关信息(Activityrecord)。

步骤L9，task将栈顶的Activity的信息缓存。

缓存栈顶Activity的信息，用于再次启动时，能够显示栈顶的Activity对应的界面。这样，再次启动时快照页和应用界面内容相同或相似，用户体验较好。

步骤L10，windowstate向snapshotcache发送清理快照索引的信息。

步骤L11，snapshotcache清理应用A的快照索引。

步骤L12，snapshotcache在清理应用A的快照索引后，向windowstate返回成功清理快照索引的响应。

步骤L13，windowstate清理自身记录的应用A的窗口信息。

步骤L8至步骤L12对应于图6所示流程图中的步骤A4。

需要说明，在应用在后台被杀时，通常会保留应用的任务栈。

步骤M1，响应于操作B，应用A开始启动。

该步骤中，对用于图6中的步骤B1，步骤M1中的操作B为图6中的步骤B1中的触发应用A进入前台运行的操作。

当然，实际应用中，应用A开始启动表示系统开始为应用创建进程，创建完成后启动进程。

步骤M2，应用A向ActivityRecord发送应用A开始启动的消息。

在实际应用中，发送的应用A开始启动的消息。

在ActivityRecord接收到应用A发送的应用A开始启动的消息之后，开始判断启动页内容。

步骤M3，ActivityRecord向snapshotcache发送快照索引获取请求，得到快照索引为空的信息。

由于应用A被系统在后台杀掉时，snapshotcache已经清理了snapshotcache中的快照索引(参见步骤L9)，所以返回快照索引为空的信息。

步骤M4，ActivityRecord向信息缓存模块发送快照索引获取请求，得到快照索引。

由于应用A被系统在后台杀掉时，系统已经将快照索引和窗口信息缓存在信息缓存模块中(参见步骤L5)，所以，返回快照索引。

步骤M5，ActivityRecord向Task发送获取缓存标志位的请求，得到标志位为true的信息。

由于在步骤L6和步骤L7中Task已经将缓存标志位设置为true，所以，将返回缓存标志位为true的消息。在缓存标志位为true的情况下，表示已经缓存应用A的快照索引和窗口信息。

步骤M6，ActivityRecord确定快照索引对应的图像是否满足系统规定的快照页条件。

在实际应用中，ActivityRecord会确定快照索引对应的图像是否满足系统规定的快照图像的条件，若满足得到快照类型。

当然，实际应用中，在该步骤中还可以确定预估的应用启动响应时长是否小于预设值。具体步骤参见后续实施例中的描述。

若预估的应用启动响应时长小于预设值，则执行后续步骤。

当然，实际应用中，若设置应用在后台被杀后，再次启动时不考虑应用启动响应时长与预设值的关系，也可以直接执行后续步骤。

步骤M7，在满足的情况下，ActivityRecord向TaskSnapshotsurface发送绘制快照页的信息。

步骤M8，TaskSnapshotsurface在接收到绘制快照页的信息的情况下，从ActivityRecord获取主窗口信息，得到空。

由于应用在后台被杀时，系统已经清理了窗口信息，所以主窗口信息不存在。

步骤M9，TaskSnapshotsurface从ActivityRecord获取应用A的任务栈信息。

步骤M10，TaskSnapshotsurface基于应用A的任务栈信息，以getTopFullScreenActivity()函数(记为第二请求)从任务栈(task)中获取栈顶的Activity(TopFullScreenActivity)。

通常，TopFullScreenActivity对象依赖于windowState，由于应用在后台被杀掉(windowState被清理)，windowstate中记录的相关信息将不存在，所以，按照正常流程通过Task模块从windowState中无法获取TopFullScreenActivity对象。

可以理解为，通过第二请求从任务栈的第四存储空间获取栈顶的Activity。

步骤M11，TaskSnapshotsurface以getCachedTopFullscreenActivty()函数从任务栈(task)中获取栈顶的Activity(TopFullScreenActivity)。

在实际应用中，可以在task中新增函数getCachedTopFullscreenActivty()。在通过正常流程返回为空的情况下，通过Task模块以getCachedTopFullscreenActivty()函数(记为第一请求)获取TopFullScreenActivity对象。由于之前已经将TopFullScreenActivity对象缓存在task中，所以可以获取到该TopFullScreenActivity对象。

这种方式从任务栈的缓存(第三存储空间)中获取到栈顶的Activity。

步骤M12，TaskSnapshotsurface从ActivityRecord获取缓存标志位(为true)。

步骤M13，在标志位为true的情况下，TaskSnapshotsurface从信息缓存模块获取快照索引和窗口信息。以得到窗口信息中的相关变量(例如，sysUiVis、windowFlags等)。

步骤M14，TaskSnapshotsurface在确定获取到快照索引和窗口信息，且任务栈顶部的Activity被缓存过的情况下，基于获取的快照索引和窗口信息绘制快照页，并显示快照页。

当然，在实际应用中，TaskSnapshotsurface调用其他模块绘制快照页和显示快照页。

另外，在电子设备显示快照页期间，电子设备将创建并启动应用A的进程，通过应用A的进程加载应用A的任务栈顶部的Activity的界面。

步骤N1，应用A的第一帧界面绘制结束。

步骤N2，在应用A的第一帧界面绘制结束后，应用A向ActivityRecord发送相关信息，以指示ActivityRecord移除快照页，并显示第一帧界面。

步骤N3，ActivityRecord接收到该信息后，移除启动窗口。

步骤N4，ActivityRecord向应用A发送已经移除的信息。

步骤N5，应用A接收到该信息后，显示应用A的第一帧界面。

步骤N6，ActivityRecord移除启动窗口之后，向信息缓存模块发送清除缓存的快照索引和窗口信息的指令。

信息缓存模块接收到该指令后，清除该应用上一次在后台被杀时缓存的快照索引和窗口信息。

在系统原生流程中，在应用启动完成后，启动页退出时，通常会进行启动动画的清理，因此，本申请实施例中可以在每次清理启动动画时，一并清理信息缓存模块中的缓存信息(快照索引和窗口信息)。当然，实际应用中，在以下情况，信息缓存模块也将清除缓存的快照索引和窗口信息。

(1)若应用在后台被杀掉之后至再次启动期间，电子设备的显示设置(例如，分辨率，白天夜晚模式的切换、分屏启动和其他启动方式的切换)被修改后，将清除信息缓存模块缓存的快照索引和窗口信息，当然，也可以清除任务栈缓存的Activity。

在该情况下，由于之前缓存的窗口信息不能匹配电子设备修改显示设置后的启动窗口参数。

(2)在应用在后台运行的时间超过预设时间的情况下，将清除信息缓存模块缓存的快照索引和窗口信息，当然，也可以清除任务栈缓存的Activity。

在该情况下，由于应用在后台时间较长的情况下，再次启动时该应用任务栈中的Activity对应的界面可能存在较大差异。

在实际应用中，可以记录快照索引和窗口信息被缓存的时刻，在应用启动时，可以将应用启动的时刻(或者，启动时取快照的时刻等)减去记录的快照索引和窗口信息的缓存时刻得到快照索引缓存时长，在快照索引缓存时长大于某阈值(例如，18小时，24小时等)的情况下，将信息缓存模块缓存的快照索引和窗口信息清理掉，并返回快照索引为空的信息。

(3)在电子设备关机、重启或卸载该应用时，将清除信息缓存模块缓存的快照索引和窗口信息，当然，也可以清除任务栈缓存的Activity。

当然，实际应用中，还可以包括其他未示出的情况。

作为本申请另一实施例，参见图9所示的时序图，该图在图8所示实施例的基础上，还可以在步骤M7发送的信息中携带缓存标志位，在TaskSnapshotsurface接收到的步骤M7对应的信息后，若该信息携带缓存标志位，则可以直接执行步骤M11，以从task的缓存中获取栈顶Activity。

由于TaskSnapshotsurface在步骤M7对应的信息中已经获得缓存标志位，则可以不再执行步骤M12。

其他步骤可以参照图8所示实施例的描述，在此不再赘述。

作为本申请另一实施例，参见图10所示的时序图，该图在图8或图9所示实施例的基础上，在步骤L5，信息缓存模块缓存快照索引和窗口信息之后，向ActivityRecord发送信息，以表示快照索引和窗口信息已经缓存在信息缓存模块中。在ActivityRecord接收到步骤M2对应的消息之后，不再从snapshotcache获取快照索引(即取消步骤M3)，而是执行步骤M4，从信息缓存模块获取快照索引。其他步骤参照上述实施例中的描述，在此不再赘述。

下面将描述图6所示实施例中的步骤B2执行的流程示意图。参见图11，为本申请实施例提供的一种流程示意图。

步骤P1，电子设备检测到触发应用启动的操作，电子设备开始添加启动窗口。

步骤P2，电子设备获取存储空间A(snapshotcache)中的快照索引。

步骤P3，电子设备确定快照索引是否为空。

在快照索引不为空的情况下，相当于应用退后台后未被杀过，即应用当前为热启动方式，可以基于存储空间A中的快照页索引执行快照页作为启动页的原生流程。

步骤P4，在snapshotcache中的快照索引为空的情况下，从存储空间B(信息缓存模块)中获取快照索引。

步骤P5，判断快照索引是否为空。

在快照索引为空的情况下(例如，电子设备开机后的首次启动，电子设备安装后的首次启动，电子设备上一次退后台后超过一定时间等)，继续走原生流程。

步骤P6，在存储空间B(信息缓存模块)中的快照页索引不为空的情况下，获取缓存标志位，判断缓存标志位是否为true，以及判断是否满足快照页启动条件。

作为示例，满足快照页启动条件包括：是否得到任务栈顶部的Activity信息，是否获取到窗口信息等。当然，还可以增加其他条件：预估应用启动响应时长(从电子设备检测到触发应用本次启动的操作至系统绘制得到应用的界面的首帧中的时长)是否小于阈值。

在缓存标志位不为true或者不满足快照页启动条件(上述条件中的任一项为否)的情况下，执行过渡页作为启动页的原生流程。

步骤P7，在缓存标志位为true、且满足快照页启动条件的情况下(上述条件均为是)，执行快照页作为启动页的流程。

在确定应用在后台被杀过再次启动时能够获取到快照索引等相关信息的情况下，将描述如何预估应用本次启动时的应用启动响应时长(预估的启动页显示时长)。

如前所述，应用冷启动时，系统需要为该应用创建并启动进程，在该进程完成启动后，通过该应用的进程加载该应用的Activity，直到Activity加载完成显示第一帧应用界面。

在实际应用中，在应用冷启动时，系统中的Activity Manager Service会向Zygote进程(android系统中一个重要的进程，负责fork其他进程)发送创建应用的进程的请求，Zygote接收该请求后，会创建并启动该应用的进程。所以，系统为应用创建进程后会一并启动该进程，由于创建进程的过程时间很短，可以忽略创建进程的时长。

参见图12，以应用的一次冷启动(用户点击系统桌面上的应用图标启动该应用)为例，应用启动时长为应用图标的点击时刻至应用界面首帧加载完成时刻。应用的启动时长包括两部分：一部分为进程启动时长，另一部分为Activity加载时长。

如前所述，由于可以忽略创建进程的时长，因此，应用冷启动时，应用启动时长也可以理解为该应用的进程开始启动时刻至首帧加载完成的时刻。

当然，实际应用中，创建进程的时长也可以归为进程启动时长中。本申请实施例的重点不在于各个时长的开始时刻和结束时刻，而在于如何通过各个时长实现本申请实施例提供的方案。

如前所述，在应用从前台进入后台后，该应用可能被杀死。然而，该应用被杀死之后可能存在自启行为，即该应用会请求系统为该应用创建并启动进程，因此，在用户点击应用的图标的时刻，该应用的进程可能已经启动完成，也可能处于启动过程中，还可能未被创建。

鉴于上述情况，在预估应用本次启动响应时长(或本次启动页显示时长)时，根据用户点击应用的图标的时刻可能存在以下几种情况：

情况一：应用图标的点击时刻，应用的进程未创建(系统后台不存在应用的进程)。

参见图13中的(a)，若用户点击应用图标的时刻，应用的进程还未创建，则在用户点击应用的图标后，应用需要执行以下过程：创建并启动应用的进程，在启动完成后，加载Activity。那么，应用本次的启动响应时长(或本次启动页显示时长)为：本次启动时进程的启动时长与本次启动时Activity加载时长之和。

在具体实现时，经过测试，同一应用在同一型号的电子设备上冷启动时的应用启动时长比较稳定，即同一应用在同一型号的电子设备上每次冷启动时的应用启动时长的波动较小，因此，参见图13中的(b)，可以根据历史上应用冷启动时的应用启动时长预估应用本次启动时进程的启动时长与本次启动时Activity加载时长之和，将预估的本次启动时进程启动时长与本次启动时Activity加载时长之和作为应用本次启动时的预估应用启动响应时长(或预估启动页显示时长)。

当然，实际应用中，还可以根据历史上应用启动时的进程启动时长预估应用本次启动时的进程启动时长，根据历史上应用启动时的Activity加载时长预估应用本次启动时的Activity加载时长。然后，将预估的应用本次启动时的进程启动时长和预估的应用本次启动时的Activity加载时长相加得到预估的应用本次启动时的进程启动时长和Activity加载时长之和，将预估的应用本次启动时的进程启动时长和Activity加载时长之和作为应用本次启动时的应用启动响应时长(或本次启动页显示时长)。

另外，系统中的进程在开始启动后会将processRuning标志位设置为True。因此，可以基于该processRuning标志位的值判定该应用的进程是否已经启动，若电子设备检测到应用图标的点击操作之后，查看应用的进程的processRuning标志位为Flase，表示属于情况一(系统不存在该应用图标对应的应用的进程)。当然，实际应用中，还可以采用其他方式判断应用的进程是否已经开始启动，本申请实施例对此不做限定。

情况二：应用图标的点击时刻，应用的进程已经启动且未启动完成。参见图14中的(a)，若用户点击应用图标的时刻，应用的进程在启动过程中，则在用户点击应用的图标后，应用需要执行以下过程：继续启动应用的进程，在启动完成后，加载Activity。那么，应用本次启动时的应用启动响应时长(或本次启动页显示时长)为：本次启动时进程的剩余启动时长加上本次启动时加载Activity的时长。

在具体实现时，可以根据该应用历史上启动时的进程启动时长预估应用本次启动时的进程启动时长，根据该应用历史上启动时的Activity加载时长预估应用本次启动时的Activity加载时长，然后将预估的应用本次启动时的进程启动时长减去进程已启动时长得到应用本次启动时的进程剩余启动时长，最后，计算预估的Activity加载时长和本次进程剩余启动时长得到应用本次启动时的应用启动响应时长。

实际应用中，基于图14中的(a)所示的各个参数之间的关系，也可以得到其他计算方式以预估应用本次启动时的应用启动响应时长(或本次启动页显示时长)。

作为另一示例，参见图14中的(b)，还可以根据该应用历史上冷启动时的应用启动时长预估应用本次启动时进程的启动时长与本次启动时Activity加载时长之和，然后将预估的应用本次启动时进程的启动时长与本次启动时Activity加载时长之和减去应用本次启动时的进程已启动时长，得到预估的应用本次启动时的应用启动响应时长(或本次启动页显示时长)。

在具体实现时，电子设备检测到应用图标的点击操作之后，查看，查看应用的进程的processRuning对应的标志位，若为True，则继续判断应用的进程是否已经启动完成。可以将应用图标点击时刻减去应用进程开始启动时刻得到应用本次启动时的进程已启动时长；若计算的该进程已启动时长小于预估的进程启动时长(由应用历史上启动时的进程启动时长预估)则表示该进程还未启动完成。当然，实际应用中，也可以通过其他方式判断应用的进程是否已经启动完成，本申请实施例对此不做限定。

在实际应用中，应用进程的processRuning标志位变为True时，系统还会记录processRuning标志位变化的时间。因此，可以根据该processRuning标志位变化的时间确定进程开始启动的时间。

如前所述，该进程是否完成时是根据该进程已启动时长与预估的进程启动时长的关系确定的，然而，在实际应用中，即使进程已启动时长小于预估的本次进程启动时长，该应用的进程也可能已经启动完成。

参见图14中的(c)，若系统本次启动进程较为迅速，在应用图标点击时刻应用进程已经启动完成，然而，按照上述计算方式得到的结果为应用的进程还未启动完成(进程已启动时长小于预估的进程启动时长)。按照上述计算方式，采用预估1的方式预估的应用本次启动时的应用启动响应时长(或本次启动页显示时长)为：预估的进程启动时长与Activity加载时长之和减去本次进程已经启动时长。

然而，实际上，应用图标的点击时刻之后，系统需要做的步骤为：通过应用的进程加载Activity，若采用预估2的方式，即实际查看进程是否已启动完成，而不是预估1的方式通过应用图标的点击时刻和进程开始启动时刻的差值与预估进程启动时长对比，则预估的应用本次启动时的应用启动响应时长(或本次启动页显示时长)为预估的Activity加载时长(预估的进程启动时长和Activity加载时长之和减去预估的进程启动时长)。所以，可能出现一段时长的误差。该段时长的误差为：预估的进程剩余启动时长。

由于本身应用启动响应时长(或本次启动页显示时长)为预估的。并且，应用每次启动时进程的启动时长的波动也较小，所以，即使存在图14中的(c)所示的情况，通常预估的进程剩余启动时长较短，所以，按照图14中的(b)所示的方式(图14中的(c)所示的预估1的方式)预估的应用启动响应时长(或本次启动页显示时长)也比较接近实际上启动页的显示时长。

情况三：应用图标的点击时刻，应用的进程已经启动完成。

参见图15中的(a)，若在用户点击应用图标的时刻，应用的进程已经完成启动，则在用户点击应用的图标后，应用需要执行以下过程：通过应用的进程加载Activity。那么应用本次的启动响应时长(或本次启动页显示时长)为：本次启动时加载Activity的时长。

在具体实现时，可以根据该应用历史上Acitivty加载时长预估应用本次启动时的Activity加载时长。然后将预估应用本次启动时的Activity加载时长作为预估的应用本次启动时的应用启动响应时长(或本次启动页显示时长)。

作为另一示例，参见图15中的(b)，还可以根据历史上该应用冷启动时的应用启动时长预估本次启动时的进程启动时长和Activity加载时长之和。由于本次进程已经启动完成，因此，可以采用预估的本次启动时的进程启动时长和Activity加载时长之和减去本次进程启动时长得到应用本次的应用启动响应时长。

当然，在具体实现时，电子设备检测到应用图标的点击操作之后，查看应用的进程的processRuning标志位，若为True，则继续判断应用的进程是否已经启动完成；如前所述，可以将应用图标点击时刻减去应用进程开始启动时刻得到应用本次启动时的进程已启动时长；若计算的该进程已启动时长大于或等于预估的进程启动时长(由应用历史上启动时的进程启动时长预估)则表示该进程已经启动完成。当然，实际应用中，也可以通过其他方式判断应用的进程是否已经启动完成，本申请实施例对此不做限定。

如前所述，该进程是否完成时是根据该进程已启动时长与预估的进程启动时长的关系确定的，然而，在实际应用中，即使进程已启动时长大于或等于预估的本次进程启动时长，该应用的进程也可能未启动完成。

参见图15中的(c)，若系统本次启动进程较为缓慢，在应用图标点击时刻应用进程还启动完成，按照上述计算方式得到的结果为应用的进程已经启动完成(进程已启动时长大于或等于预估的进程启动时长)，预估的应用本次启动时的应用启动响应时长(或本次启动页显示时长)为：预估的Activity加载时长。

然而，实际上，应用图标的点击时刻之后，系统需要做的步骤为：继续启动应用进程，在应用进程启动完成后，通过应用的进程加载Activity，若采用预估2的方式，即实际查看进程是否已启动完成，而不是预估1的方式通过应用图标的点击时刻和进程开始启动时刻的差值与预估进程启动时长对比，则预估的应用本次启动时的应用启动响应时长(或本次启动页显示时长)为预估的Activity加载时长加上实际上的进程剩余启动时长。所以，可能出现一段时长的误差。该段时长的误差为：实际上的进程剩余启动时长。

如前所述，由于应用启动响应时长(或本次启动页显示时长)为预估的。并且，应用每次启动时进程的启动时长的波动也较小，所以，即使存在图15中的(c)所示的情况，通常在应用图标点击时刻之后，进程剩余启动时长也较短，所以，按照图15中的(b)所示的方式(图15中的(c)所示的预估1的方式)预估的应用启动响应时长(或本次启动页显示时长)也比较接近实际上启动页的显示时长。

当然，实际应用中，无论应用本次启动属于哪种情况，在该情况下得到预估的应用启动响应时长(或本次启动页显示时长)之后，在预估的应用启动响应时长(或本次启动页显示时长)大于或等于某个阈值的情况下，则认为本次应用启动时长将过长，需要展示过渡页(例如Logo页)。若预估的应用启动响应时长(或本次启动页显示时长)小于该阈值，则认为本次应用启动时长将不长，需要展示快照页。

通过图13至图15可以理解：

应用冷启动(图13所示示例)时，应用的启动响应时长(启动页显示时长)包括：进程启动时长和Activity加载时长。

应用温启动时的一个示例(图15所示示例)，应用的启动响应时长(启动页显示时长)包括：Activity加载时长(或者，历史上应用冷启动时的应用启动时长减去本次进程启动时长)。

应用温启动时的另一个示例(图14所示示例)，应用的启动响应时长(启动页显示时长)包括：进程剩余启动时长和Activity加载时长(或者，历史上应用冷启动时的应用启动时长减去本次进程已启动时长)。

如图12所示，本申请实施例定义应用冷启动时的应用启动时长为应用冷启动时的应用图标点击时刻至电子设备显示首帧应用界面的时刻中间经过的时长，且通过应用冷启动时的应用启动时长预估应用本次启动时的进程启动时长与Activity加载时长之和。为了保持数据一致性，也可以采用应用历史在本电子设备冷启动时的进程启动时长预估应用本次启动时的进程启动时长。当然，本申请实施例中，可以采用历史上任何启动方式时的进程启动时长预估本次启动时的进程启动时长。

作为本申请另一实施例，还可以定义应用启动时长为进程开始启动时刻到显示首帧应用界面的时刻。由于情况一所示的冷启动和情况二所示的温启动时，进程启动时长和Activity加载时长为连续的时间段，所以可以获取历史上同一应用冷启动和/或情况二所示的温启动时的应用启动时长预估应用本次启动时的进程启动时长与Activity加载时长之和；本申请实施例对此不做限定。

通过上述实施例的描述，可以得到如图16所示的电子设备在检测到应用图标的点击事件后判断执行加载过渡页还是执行加载快照页的流程示意图。需要说明，其中，步骤A2之后的步骤为上述图8所示实施例中位于步骤M6和步骤M7之间的步骤。

步骤A1，电子设备检测到应用图标的点击操作。

本申请实施例中，应用图标表示在电子设备的系统桌面上显示的应用图标。该应用图标的点击操作用于启动该应用。

本申请实施例以用户点击系统桌面上显示的应用图标启动应用为例进行说明。

当然，实际应用中，也可以是通过其他应用跳转到本应用以启动本应用的场景，在这种场景下，电子设备通过其他应用也可以检测到启动本应用的操作。或者，用户点击系统桌面上的小控件的方式以启动本应用的场景，在这种场景下，电子设备通过小控件可以检测到本启动应用的操作。

参见图7中的(a)，为从其他应用跳转到本应用(例如，应用A)以启动本应用的场景。该场景下，电子设备显示其他应用(例如，应用B)的界面，该界面中包括应用A的跳转控件，用户点击应用A的跳转控件，应用B检测到启动应用A的操作，电子设备将启动应用A。相应的，上述实施例中，应用图标的点击时刻可以理解为：应用的跳转控件的点击时刻。

参见图7中的(b)，为用户点击系统桌面上的小控件的方式启动本应用(例如，应用A)的场景。在用户点击系统桌面上的小控件时，该小控件可以检测到启动应用A的操作。相应的，上述实施例中，应用图标的点击时刻可以理解为：系统桌面上的小控件的点击时刻。

当然，实际应用中，本申请实施例中的应用图标的点击时刻仅为电子设备检测到任一可以触发启动应用A的操作的时刻。

如前所述，本申请实施例应用在系统存在该应用的任务栈的场景中时，具有较好的用户体验。所以，在步骤A1之后，电子设备还需要确定系统是否存在该应用的任务栈。

当然，本申请实施例也可以应用在系统不存在该应用的任务栈的场景中，只是在判定显示快照页时，显示快照页之后会显示应用的主界面，用户的体验较差。

步骤A2，电子设备判断该应用的进程是否已经开始启动。

在本申请实施例中，可以通过查看该应用的进程的processrunning标记位(True或者False)，若该应用的进程的processrunning标记位为True时，表示该应用的进程已经创建并开始启动。在该应用的进程的process running的标记位False时，表示该应用的进程还未启动。

如前所述，AMS会向Zygote进程发送创建进程的请求，Zygote接收该请求后，会创建并启动该应用的进程。所以，系统为应用创建进程后会一并启动该进程，由于创建进程的过程时间很短，可以理解为应用的进程的process running的标记位为False，表示该应用的进程也未创建。确定应用的进程已启动的标识符记为第一标识符。例如，上述实施例中的true。

步骤A3，若该应用的进程已经开始启动，则计算应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值(该差值记为第三差值)。

在此需要说明，可以采用该差值作为进程已经启动时长，进程开始启动的时刻可以为进程的process running的标记位最后一次变为True的时刻。

如前所述，本申请实施例中的时长值并非必须采用精确的时刻值作为时长值的端点，因此，本申请实施中，还可以计算当前时刻与所述第二进程的开始启动时刻的第二差值，所述第二进程的已启动时长为所述第二差值，所述第二进程的开始启动时刻为所述第二进程的processrunning标志位最后一次变为所述第一标识符的时刻。

或者，所述电子设备计算第一时刻与所述第二进程的开始启动时刻的第四差值，所述第一时刻为所述电子设备接收应用图标的点击操作的时刻至所述当前时刻之间的任一时刻，所述第二进程的已启动时长为所述第四差值。

步骤A4，判断应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值是否大于或等于预估的本次进程启动时长(T2)。

本申请实施例中，通过应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值与预估的本次进程启动时长的大小，判断该应用的进程是否已经完成启动。

若应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值大于或等于预估的本次进程启动时长(可以记为第二时长)，表示该应用的进程已经启动完成。若应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值小于预估的本次进程启动时长，表示该应用的进程还在启动过程中。

步骤A5，若应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值大于或等于预估的本次进程启动时长(T2)，则将预估的本次进程启动时长和本次Acitivty加载时长之和(T1，可以记为第二值)减去预估的本次进程启动时长(T2，可以记为第三值)得到预估的启动页显示时长。此时预估的启动页显示时长可以记为第三时长。

步骤A6，判断预估的启动页显示时长是否大于或等于阈值(该值可以记为第一值)。

步骤A7，预估的启动页显示时长大于或等于阈值的情况下，执行加载过渡页流程。

步骤A8，预估的启动页显示时长小于阈值的情况下，执行加载快照页流程。

本申请实施例中，加载过渡页流程可以是现有的电子设备在显示应用的界面之前显示过渡页的流程；加载快照页流程可以是现有的电子设备在显示应用的界面之前显示快照页的流程。

上述流程步骤A1至步骤A7(或A8)的流程对应于上述情况三。

作为本申请另一实施例，在执行步骤A2时，判断的结果为：该应用的进程还未启动；则执行步骤B1，将预估的本次进程启动时长和Activity加载时长之和(记为第一时长)作为预估的启动页显示时长。在获得预估的启动页显示时长之后，执行步骤A6。该实施例对应于上述情况一。

作为本申请另一实施例，在执行步骤A4时，判断的结果为：应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值小于预估的本次进程启动时长(T2)，则执行步骤C1，将预估的本次进程启动时长和Activity加载时长之和减去差值(应用图标的点击时刻(T4)和进程开始启动的时刻(T3)的差值)得到预估的启动页显示时长。此时得到的预估的启动页显示时长可以记为第四时长。在获得预估的启动页显示时长之后，执行步骤A6。该实施例对应于上述情况二。

通过上述实施例可以理解，本申请实施例在具体实现时，需要依赖于以下参数：预估的本次进程启动时长和本次Activity加载时长之和，预估的本次进程启动时长，本次应用图标的点击时刻，本次进程开始启动时刻。

其中，本次应用图标的点击时刻和本次进程开始启动时刻需要在应用本次启动时才可以获取到。预估的本次进程启动时长和本次Activity加载时长之和，以及预估的本次进程启动时长可以在应用上一次冷启动(或者，上一次冷启动或情况二所示的温启动)之后至本次步骤B1(或步骤A4)需要采用预估的时长参数之前的任意时间得到。

作为本申请另一实施例，在执行图16所示实施例中的步骤B1对应的流程(冷启动)的情况下，需要在本次启动完成后，将本次应用启动时的应用启动时长和进程启动时长作为历史数据存储，以预估应用下一次启动时的进程启动时长和Activity记载时长之和，以及进程启动时长。

当然，若采用情况二所示的温启动和冷启动对应的参数作为历史数据，则在执行图16所示实施例中的步骤B1对应的流程或执行图16所示实施例中的步骤C1对应的流程的情况下，需要在本次启动后，将本次应用启动时的应用启动时长和进程启动时长作为历史数据存储以预估应用下一次启动时的进程启动时长和Activity记载时长之和，以及进程启动时长。

当然，实际应用中，系统也可以保存应用每次启动时的应用启动时长和进程启动时长，只是在获取历史数据时，选择符合要求的历史数据(例如，冷启动时对应的历史数据)。

作为另一示例，还可以在步骤A1之后再获取应用历史上冷启动时的应用启动时长和进程启动时长以预估本次启动时的时长数据。该示例具体可参照后续实施例的描述。

下面将描述如何得到预估的本次进程启动时长和本次Activity加载时长之和，以及预估的本次进程启动时长。

以下实施例中，应用历史启动时的参数数据(最近N次)均表示上述实施例中描述的冷启动时的参数数据，或者冷启动和/或情况二所示的温启动时的参数数据。具体采用冷启动时的参数数据作为历史数据还是冷启动和情况二所示的温启动时的参数数据均可以作为历史数据，请参照上述实施例中的描述。N为大于或等于1的自然数。当然，即使可以冷启动时的参数数据，也可以采用情况二所示的温启动时的参数数据的情况下，若最近N次均为应用情况二所示的温启动时的参数数据，则获取的历史数据均为情况二所示的温启动时的参数数据；若最近N次均为应用冷启动时的参数数据，则获取的历史数据均为冷启动时的参数数据。

以采用冷启动时应用启动时长和进程启动时长作为历史数据为示例，可以将本次应用启动之前最近N次应用冷启动时的应用启动时长的均值作为预估的本次进程启动时长和Activity加载时长之和；将本次应用启动之前最近N次应用冷启动时的进程启动时长的均值作为预估的本次进程启动时长。

作为另一示例，为最近N次应用冷启动时的应用启动时长赋予不同的权重，计算N次应用启动时长的加权平均数，该平均数作为预估的本次进程启动时长和Activity加载时长之和。为最近N次进程启动时长赋予不同的权重，计算N次进程启动时长的加权平均数，该平均数作为预估的本次进程启动时长。

作为另一示例，距离本次更近的应用启动时长的权重大于距离本次更远的应用启动时长的权重。

例如，N次应用冷启动时的应用启动时长按照时间从远到近(也可以理解为时间从先到后)的顺序分别记为：第1次应用启动时长……第i次应用启动时长……第N次应用启动时长。按照上述顺序将权重设置的依次变小。当然，实际应用中，相邻的应用启动时长的权重也可以相同，i为小于或等于N的正整数。

作为另一示例，可以将N次应用启动时长中的第1次应用启动时长的权重设为S^N-1，将第i次应用启动时长设为S^N-i，将第N次应用启动时长设为S⁰。0＜S＜1。

在实际应用中，不同应用的应用启动时长和进程启动时长可能存在较大差异，因此可以设置列表：该列表中以不同应用的包名作为索引，存储该应用最近N次冷启动时的应用启动时长和进程启动时长。具体可参见表2。

表2应用冷启动时间列表

以最近3次应用启动时长为例，最近3次应用启动时长中的第1次(时间距离本次最远)应用启动时长(L₁)的权重设为S²，将第2次应用启动时长(L₂)设为S，将第3次(时间最靠近本次)应用启动时长(L₃)设为1。则预估的本次应用启动时长和Activity加载时长之和(L₀)为：

S表示衰减系数。

以表2中的一个应用的启动时长作为一个示例，L₁为2199ms，L₂为2219ms，L₃为2230ms，S为0.95，基于上述公式得到预估的本次应用启动时长和Activity加载时长之和(L₀)为2216ms。

以最近3次进程启动时长为例，最近3次进程启动时长中的第1次(时间距离本次最远)进程启动时长(P₁)的权重设为S²，将第2次进程启动时长(P₂)设为S，将第3次(时间最靠近本次)进程启动时长(P₃)设为1。则预估的本次进程启动时长(P₀)为：

以表2中的一个应用的进程启动时长作为一个示例，P₁为1782ms，P₂为1789ms，P₃为1790ms，S为0.95，基于上述公式得到本次进程启动时长(P₀)为1787ms。

当然，表2中应用启动时长和进程启动时长均表示应用同一次启动时的应用启动时长和进程启动时长。

上述实施例可以基于图17所述的技术架构图实现。该技术架构图包括应用层和框架层。实际应用中，实施本申请提供的应用启动方法的技术架构可以比图17所示的技术架构包括更多的层，也可以包括更多的模块，本申请实施例对比不做限定。当然，图17所示的模块中两个或两个以上的模块也可以合并为一个模块。图17所示的模块也可以再拆分为两个或两个以上的子模块。

应用层存在各种应用。

框架层存在信息采集模块和处理决策模块。

信息采集模块用于采集并存储本申请实施例需要的各种参数。例如，历史应用启动时长、历史进程启动时长、本次应用图标的点击时刻、本次进程开始启动时刻等。信息采集模块将采集的历史应用启动时长、历史进程启动时长、本次应用图标的点击时刻和本次进程开始启动时刻发送给处理决策模块。

信息采集模块包括ATMS、ActivityRecord、ActivityMetricsLogger和WindowProcessController。

ATMS用于获取进程启动时长，并将进程启动时长存储在ActivityRecord中。

ActivityMetricsLogger用于计算应用启动时长，并将应用启动时长存储在ActivityRecord中。

ActivityRecord用于存储上述示例中的进程启动时长和应用启动时长，还用于存储应用开始启动时刻。本申请实施例中，应用开始启动时刻可以为应用图标的点击时刻(或任意触发应用启动的操作发生的时刻)。

WindowProcessController用于存储进程开始启动时刻。该进程的processrunning的标记最近一次变为true的时刻为本次进程开始启动时刻。

由于在具体实现时，确定执行显示过渡页流程还是执行显示快照页流程时采用的启动页的显示时间本身就为预估的时间，所以，在实际应用中，各个时长参数的起始时刻和终止时刻可以与本申请实施例中的示例不同，允许和本申请实施例提供的起始时刻和结束时刻存在差异。同理，各个时刻参数对应的时刻值也可以与本申请实施例中的示例不同，也允许和本申请实施提供的各个时刻存在差异。

作为另一示例，应用启动时长可以以进程开始启动时刻作为应用启动时长的起始时刻；还可以将应用进程的process running的标志位变为True的时刻作为应用启动时长的起始时刻。

作为另一示例，进程启动时长可以以应用进程的process running的标志位变为True的时刻作为进程启动时长的起始时刻。对于其他示例不再一一举例。

处理决策模块包括信息处理模块和加载决策模块。

信息处理模块用于将信息采集模块得到的应用启动时长和进程启动时长作为历史数据预估的本次进程启动时长和本次Activity加载时长之和，以及本次进程启动时长；并将预估的本次进程启动时长和本次Activity加载时长之和，以及本次进程启动时长发送给加载决策模块。

加载决策模块用于基于各种参数(信息处理模块预估的进程启动时长和Activity加载时长之和，预估的进程启动时长，信息采集模块采集的本次进程开始启动时刻和应用图标点击时刻)预估本次启动页(快照或过渡页)显示时长；在预估的本次启动页的显示时长大于或等于某个阈值的情况下，则认为本次应用启动响应时长将较长，确定执行展示过渡页(例如广告界面)流程。若预估的本次启动页的显示时长大于该阈值，则认为本次应用启动响应时长将较短，确定执行展示快照页流程。

下面将以一个应用(应用A)为例，描述该应用的启动过程。参见图18所示实施例的时序图。其中，步骤E1至步骤E7为应用A的冷启动过程，重点描述如何获得应用冷启动时的应用启动时长和进程启动时长。步骤H1至步骤H15为应用A采用本申请实施例所示的决策执行过渡页流程还是执行快照页流程。其中，步骤H1至步骤H15中采用的历史数据包括步骤E1至步骤E7中获得的应用启动时长和进程启动时长。

步骤E1，响应于操作1，应用A的进程启动。

本申请实施例中，操作1可以是任意能够触发应用A启动的操作。另外，需要说明，应用A本次启动为冷启动方式。

电子设备关机后再开机，在电子设备开机后第一次启动该应用A时，应用A的启动方式为冷启动。

当然，实际应用中，电子设备开机后不是首次启动应用A时，应用A的启动方式也可能为冷启动。例如，应用A在后台运行时，被系统杀掉。

在具体实现时，响应于操作1，系统的首个JAVA进程为Zygote进程，Zygote进程为所有Java进程的父进程，负责框架层其他进程的创建和启动工作。

SystemServer进程是由Zygote进程孵化的第一个进程，大部分Android提供的服务(例如，ActivityManagerService，WindowManagerService等)都在该进程中。其中，ActivityManagerService(AMS)统一调度各应用进程。

当一个应用启动时，ActivityManagerService通过Socket进程间通信机制，通知Zygote进程为这个应用程序创建一个新的进程并启动该进程。

作为示例，用户从系统桌面点击应用图标以启动该应用时，Launcher所在的进程通过binder发送消息给systemserver进程中运行的AMS。systemserver进程中运行的AMS通过socket向Zygote进程发送创建新进程的消息，从而使得Zygote进程创建应用的进程。

作为另一示例，用户从应用B点击跳转控件以启动该应用时，应用B的进程通过binder发送消息给systemserver进程中运行的AMS。systemserver进程中运行的AMS通过socket向Zygote进程发送创建新进程的消息，从而使得Zygote进程创建应用的进程。

其他示例不再一一举例。

另外，不同系统中，有一些功能从ActivityManagerService(AMS)移到了ActivityTaskManagerService(ATMS)中。本申请实施例中的AMS等同于ATMS。

步骤E2，应用A向ActivityMetricsLogger传输电子设备接收到操作1的时刻t1。

需要说明，本申请实施例中，systemserver进程中设置有Trace采集点。本申请可以在设置的Trace采集点函数中增加时间戳，ActivityMetricsLogger可以获取应用A第一帧绘制完成的采集点函数的时间戳(t2)和应用图标点击时刻(或者任意触发应用启动的操作发生的时刻，t1)的采集点函数的时间戳。ActivityMetricsLogger计算两个时间戳的差值得到应用A本次启动时的应用启动时长。该应用启动时长将作为该应用下次启动时的历史应用启动时长。

因此，该步骤仅用于信息的传递方向，即ActivityMetricsLogger能够拿到电子设备接收到操作1的时刻t1，并不表示应用A会向ActivityMetricsLogger发送电子设备接收到操作1的时刻t1。

步骤E3，应用A的进程启动完成，应用A将应用A本次启动时的进程启动时长发送给活动任务管理组件(ActivityTaskManegerServer，ATMS)。

当成功创建一个应用的进程后，该应用进程通过Blnder(进程间通信)与systemserver进程进行跨进程通信以实现一些功能。

在实际应用中，可以设置应用进程启动完成后，应用进程将自身启动完成时刻和开始启动时刻的差值(该差值为进程启动时长)通过Binder(进程间通信)传递给systemserver进程，ATMS作为运行在system_server进程中的服务，可以从systemserver进程中获取到进程启动时长。

在具体实现时，应用进程可以将UIThread线程中的bindApplication函数的执行时长传递给systemserver进程。(因为bindApplication函数的执行时长占进程启动时长的绝大部分，因此统计这里的时间)。

作为另一示例，在实际应用中，也可以在应用进程启动完成时通过预先设置的Trace采集点函数采集进程启动完成时刻。然后，ActivityMetricsLogger基于设置的采集点函数计算进程启动时长，将进程启动时长存储在ActivityMetricsLogger中，或ActivityRecord中。

步骤E4，ATMS接收到应用A本次启动时的进程启动时长的情况下，将进程启动时长发送给活动记录组件(ActivityRecord)。

本申请实施例中，活动记录组件可以记录应用冷启动时的应用启动时长和进程启动时长。因此，活动记录组件接收到进程启动时长后，存储接收到的进程启动时长。

步骤E5，应用A启动完成后，应用A向ActivityMetricsLogger传输应用A启动完成的时刻t2。

本申请实施例中，应用A启动完成表示应用A已经绘制完成应用A的第一帧应用界面(例如应用A的主界面)。应用A启动完成后，预先设置的采集点函数对应的时间戳会传向ActivityMetricsLogger。该步骤仅用于信息的传递方向，并不表示应用A会向ActivityMetricsLogger发送时刻t1。

在实际应用中，可以由ActivityMetricsLogger主动从系统进程(systemserver进程)获取两个端点(应用图标点击时刻和应用第一帧界面绘制完成时刻)的采集点函数的时间戳，然后计算应用启动时长。

步骤E6，应用A在启动完成后，ActivityMetricsLogger能够检测到应用A启动完成，ActivityMetricsLogger检测到应用A启动完成后，获取采集点函数的时间戳(t2和t1)，计算应用A的应用启动时长(t2减去t1)。

步骤E7，ActivityMetricsLogger得到应用A的应用启动时长之后，将应用启动时长发送给ActivityRecord。

在ActivityRecord接收到应用启动时长后，存储接收到的应用启动时长。

在实际应用中，可以设置在应用A每次冷启动(或者，非热启动)后，ActivityRecord中会记录应用A本次启动时的应用启动时长和进程启动时长。在应用A下次启动时可以将ActivityRecord中记录的最近N次应用启动时长和进程启动时长作为历史数据预估本次启动时的数据。

当然，也可以设置在应用A每次启动后，ActivityRecord中会记录应用A本次启动时的应用启动时长和进程启动时长。在应用A下次启动时可以将ActivityRecord中记录的最近N次冷启动(或者，非热启动)时应用启动时长和进程启动时长作为历史数据预估本次启动时的数据。本申请实施例对具体的实现方式不做限定。

需要说明，步骤E1至步骤E7仅用于示例应用冷启动时的应用启动时长和进程启动时长会存储在系统中作为历史数据，并不表示每次启动应用以执行本申请实施例提供的应用启动方法之前，均需要执行一次冷启动过程。在实际应用中，电子设备执行步骤E1至步骤E7的过程中也可以实施本申请实施例提供的应用启动方法。

经过步骤E1至步骤E7，系统可以得到一次应用A的冷启动时的应用启动时长和进程启动时长。

在应用A启动完成后，用户可以在应用A的界面上进行操作，以体验应用A提供的各项功能。

步骤F1，响应于操作2，应用A退回到后台。

在本申请实施例中，操作2可以是以下任意操作，用户可以在电子设备显示应用A的界面的情况下，通过手势导航显示系统桌面以将应用A退回到后台运行。用户还可以在电子设备显示应用A的界面的情况下，进入多任务界面，通过点击多任务界面中的一个应用(例如，应用B)的任务卡片以将另一应用(应用B)调到前台运行，则应用A退回到后台运行。用户还可以在电子设备显示应用A的界面的情况下，点击侧边导航栏中显示的其他应用(例如，应用C)的控件以将其他应用(应用C)调到前台运行，则应用A退回到后台运行。

另外，用户将该应用退回到后台之前，系统会缓存该应用显示的最后界面的快照。

步骤F2，应用A的进程被杀掉。

在本申请实施例中，系统中通常会设置后台的应用被杀掉的规则，例如，在后台的应用进入后台运行的时间超过一定时间后，将该后台的应用杀掉。在系统的功耗较高时，将后台的应用杀掉。

另外，一个应用在后台被杀掉表示将该应用的进程杀掉。在该应用的进程被杀掉时，该应用的任务栈还存在，这样才能保证在确定显示快照页时，显示的快照页和最终显示的任务栈顶部的Activity对应的界面的内容相同或相似。

步骤F3，在应用A的进程被杀掉之后，应用A向Activityrecord发送应用A的进程被杀的信息。

步骤F4，Activityrecord将processrunning标志位变为False。

图18所示实施例中，以应用A先在后台自启，用户后点击应用A的图标作为示例。

步骤G1，应用A的进程开始启动。

在本申请实施例中，应用在后台被杀掉后，该应用在后台可能存在自启行为。

在实际应用中，若系统中设置了允许应用A自启，则应用A可以在特定时间(例如，每天的19点)或达到某个条件(例如，被其他应用唤醒，被杀死后经过特定时长)的情况下自启。实际应用中，自启的条件不做限制。

当然，在应用A自启后，系统还可能将后台自启后的应用A再次杀死，同样，在再次到达特定时间或达到某个条件的情况下再次自启……。

步骤G2，在应用A的进程开始启动的情况下，应用A将应用A的进程开始启动的信息发送给ActivityRecord。

步骤G3，ActivityRecord接收到应用A的进程开始启动的信息之后，将ProcessRunning标志位设置为true，得到进程开始启动时间(ProcessRunning标志位变为true的时刻)。

步骤G4，ActivityRecord向WindowProcessController发送ProcessRunning标志位变为true的时刻(进程开始启动时间)，WindowProcessController将记录有ProcessRunning标志位变为true的时刻为进程开始启动时刻。

在步骤G4之后，WindowProcessController存储进程开始启动时间(ProcessRunning标志位变为true的时刻)。

步骤H1，响应于操作3，应用A的进程加载Activity。

本申请实施例中，操作3可以为用户可以点击系统桌面上应用A的图标启动应用A，当然，也可以为图7所示的任意方式。

需要说明，本申请实施例中，步骤H1中的响应于操作3，应用开始启动，也可以理解为进应用的进程开始加载Activity。当然，应用启动开始时刻表示触发应用到前台运行的触发事件发生的时刻，而不是应用的进程开始启动的时刻。

步骤H2，应用A向ActivityRecord发送应用A开始启动的消息，以指示ActivityRecord记录本次开始启动时刻。

步骤H3，ActivityRecord接收到应用A发送的信息之后，记录应用A本次开始启动时刻。

作为一个示例，若步骤H1中，用户点击应用A的图标以启动应用A，则记录的应用A本次开始启动的时刻为电子设备检测到用户点击应用A的图标的时刻。即上述实施例中应用图标的点击时刻为该步骤中记录的应用本次开始启动的时刻。步骤H2中的消息可以携带应用开始启动的时刻(电子设备接收到操作3的时刻)。当然，实际应用中，步骤H2中的消息不携带应用开始启动的时刻，步骤H3将接收到步骤H2对应的消息的时刻作为应用开始启动的时刻。

步骤H4，ActivityRecord向处理决策模块请求启动页加载策略。

ActivityRecord向处理决策模块请求启动页加载策略可以得到启动页加载策略，以基于得到的启动页加载策略加载过渡页或快照页。

处理决策模块接收到ActivityRecord发送的请求信息后，开始决策执行过渡页加载策略还是快照页加载策略。

处理决策模块决策执行过渡页加载策略还是快照页加载策略的逻辑可以参照图16所示实施例中的步骤A2之后的步骤。

作为处理决策模块执行步骤A2之后的步骤的一个示例：

步骤H5，处理决策模块接收到ActivityRecord发送的请求信息后，从ActivityRecord获取ProcessRunning标志位的值。

步骤H7，处理决策模块从ActivityRecord获取存储的应用A的应用启动时长和进程启动时长。

需要说明，在步骤H5和步骤H7之间，可以存在步骤H6。

步骤H6，处理决策模块确定ProcessRunning标志位为true还是False，当然，在true的情况下，需要继续基于其他数据判断属于情况二还是属于情况三。

在实际应用中，获取应用A的应用启动时长和进程启动时长时，可以携带应用A的唯一标识，例如，包名等。当然，获取到的存储的应用A的应用启动时长和进程启动时长将作为本次启动时的历史数据。该历史数据可以包括步骤E4之后存储的进程启动时长和步骤E8之后存储的应用启动时长。

步骤H8，处理决策模块根据获取历史应用启动时长预估应用本次启动时的进程启动时长和Activity加载时长之和，根据历史进程启动时长预估应用本次启动时的进程启动时长。

在实际应用中，可以设置的上一次冷启动时的应用启动时长作为本次应用启动时的进程启动时长和Activity加载时长之和，上一次冷启动时的进程启动时长作为本次应用启动时的进程启动时长。

还可以设置历史N次冷启动时的应用启动时长预估本次应用启动时的进程启动时长和Activity加载时长之和，历史N次冷启动时的进程启动时长预估本次应用启动时的进程启动时长。具体可参照上述实施例中的描述。

步骤H9，处理决策模块从WindowProcessController获取进程开始启动时刻(ProcessRunning标志位变为true的时刻)。

步骤H10，处理决策模块从ActivityRecord获取应用A本次开始启动时刻。

本申请实施例中，步骤H8在步骤H7之后，步骤H7、步骤H9和步骤H10的执行顺序可以基于判断逻辑的顺序设置，并非完全按照本申请实施例中的执行先后顺序。作为示例，可以先执行H10再执行步骤H9。也可以先执行步骤H9和H10，再执行步骤H7和步骤H8。

步骤H11，处理决策模块基于步骤H6判定进程已经开始启动；在进程已经开始启动的情况下，继续判断步骤H10获取的应用开始启动时刻减去步骤H9获取的进程开始启动时刻是否大于或等于步骤H8中预估的进程启动时长；若大于或等于预估的进程启动时长，则得到预估的启动页显示时长为预估的进程启动时长和Activity加载时长之和减去预估的进程启动时长；在预估的启动页显示时长小于阈值的情况下，确定启动页加载策略为加载快照页；在预估的启动页显示时长大于或等于阈值的情况下，确定启动页加载策略为加载过渡页。

当然，作为另一示例，判断步骤H10获取的应用开始启动时刻减去步骤H9获取的进程开始启动时刻是否大于或等于步骤H8中预估的进程启动时长时；若小于预估的进程启动时长，则得到预估的启动页显示时长为预估的进程启动时长和Activity加载时长之和减去进程已启动时长(步骤H10获取的应用开始启动时刻减去步骤H9获取的进程开始启动时刻)；在预估的启动页显示时长小于阈值的情况下，确定启动页加载策略为加载快照页；在预估的启动页显示时长大于或等于阈值的情况下，确定启动页加载策略为加载过渡页。

步骤H12至步骤H15以确定启动页加载策略为加载快照页为例进行说明。

步骤H12，在预估启动页显示时长小于阈值的情况下，处理决策模块向ActivityRecord发送确定的启动页加载策略为加载快照页。

本申请实施例中，可以设置所有应用的该阈值相等。这种情况下，冷启动时的应用启动时长较短的应用在冷启动(任务栈存在)时，也可以显示快照页。

实际应用中，可以采用不同的标识作为不同的启动页加载策略，作为示例，以第一标识(例如，1)作为加载快照页的标识，以第二标识(例如，0)作为加载过渡页的标志。

步骤H13，ActivityRecord接收到启动页加载策略后，基于启动页加载策略加载快照页。

在加载快照页之后，电子设备将显示快照页。

步骤H14，应用A的首个Activity的首帧界面绘制结束。

步骤H15，应用A向ActivityRecord发送退出显示快照页的消息。

相应的，电子设备在步骤H15之后将显示第一帧应用界面。

作为执行加载Logo页的一个示例，参见图19所示界面示意图。

图19中的(a)为触发步骤H1发生的触发事件的一种示例。

图19中的(b)为步骤H13执行加载Logo页之后的一种示例。

图19中的(c)为步骤H15执行退回显示Logo页之后，显示应用A的首个Activity(任务栈顶部的Activity)对应的界面之前的启动窗口的一种示例。

图19中的(d)为电子设备启动应用A后显示的首个Activity(任务栈顶部的Activity)对应的界面的一种示例。

作为执行加载快照页的一个示例，可以参见图4所示的界面示意图，如前所述图4所示界面变化示意图为应用热启动时的界面变化示意图。即本申请实施例在冷启动或温启动时可能由于本次启动响应时长较短，采用的界面变化和应用热启动时的界面变化相似。

将图4作为冷启动或温启动时加载快照页的一个示例，图4中的(c)为触发步骤H1发生的触发事件的一种示例。即冷启动或温启动时的界面显示过程和热启动时的界面显示过程相似。

图4中的(d)为步骤H13执行加载快照页之后的一种示例。

图4中的(e)为步骤H15执行退回显示快照页之后，显示应用A的首个Activity(任务栈顶部的Activity)对应的界面之前的启动窗口的一种示例。

图4中的(f)为电子设备启动应用A后显示的首个Activity(任务栈顶部的Activity)对应的界面的一种示例。

需要说明，图4所示的执行快照页加载策略的示例中，在该应用本次启动前上一次退回到后台时，系统保存的快照页可以为电子设备显示的应用的界面(不包括状态栏内容)的图像。应用本次启动时电子设备显示的图4中的(d)所示的界面包括系统保存的快照页和状态栏当前的内容。即应用启动时加载快照页时显示的界面为快照图像图层和状态栏图层合成的界面。

作为另一示例，系统之前保存的快照还可以为电子设备退回后到后台前电子设备显示的整个界面(包括状态栏内容)对应的图像。应用本次启动时电子设备显示的图4中的(d)所示的界面为状态栏当前的内容覆盖系统保存的快照图像的状态栏区域后得到的图像。即应用启动时加载快照页时显示的界面为状态栏图层覆盖快照图像图层中的状态栏区域后合成的界面。

作为另一示例，参见图20，在图18所示时序图的基础上，在步骤F2和步骤H1之间若不存在步骤G1至步骤G4，则步骤H6中处理决策模块基于ProcessRunning标志位的值(False)判定属于情况一。则预估启动页显示时长需要预估进程启动时长和Activity加载时长之和。因此，继续执行步骤H7(不再获取进程启动时长)至步骤H8(不再预估进程启动时长)，不再执行步骤H9至步骤H10。在步骤H11中，得到预估启动页显示时长为预估进程启动时长和Activity加载时长之和。

另外，由于在用户在电子设备上输入操作3之前，应用A的进程未在后台自启，所以，在电子设备接收到操作3之后，电子设备创建应用A的进程，并启动应用A的进程。

作为示例，在步骤H1之后，存在步骤Z1至步骤Z3。

步骤Z1，应用A的进程开始启动。

步骤Z2，在应用A的进程开始启动后，应用A向Activityrecord发送应用A的进程开始启动的信息。

步骤Z3，Activityrecord将processrunning标志位变为true。

需要说明，实际应用中，在步骤H1之后，系统并行的执行步骤H2至步骤H13，以及步骤Z1至步骤Z3。只是由于步骤H2至步骤H5的执行速度高于步骤Z1至步骤Z3的速度。所以，通常在步骤Z3中的processrunning标志位变为true之前，系统已经执行完步骤H5，获取到proccessrunning的标志位为Flase。

当然，实际应用中，若在步骤F2和步骤H1之间若不存在步骤G1至步骤G4，则步骤H6中处理决策模块基于ProcessRunning标志位的值(False)判定属于情况一。也可以按照图21所示实施例中的步骤执行。即步骤H7和图18所示的ProcessRunning标志位的值为true时的情况时步骤H7的内容相同，即可以采用同一get函数，同时得到进程启动时长和应用启动时长，只是，在步骤H8中，不再需要预估进程启动时长，只需要预估进程启动时长和Activity加载时长之和。

当然，实际应用中，处理决策模块在接收到步骤H4中的请求信息后，可以基于实际情况设置获取各个时长参数(历史应用启动时长和历史进程启动时长)和获取各个时刻参数(本次进程开始启动时刻和本次应用开始启动时刻)的顺序。作为示例，参见图22，可以按照以下顺序执行：步骤H7(获取历史应用启动时长和历史进程启动时长)、步骤H8、步骤H10(获取本次应用开始启动时刻)和步骤H5，在步骤H5得到的结果为True的情况下执行步骤H9(获取本次进程开始启动时刻)。在步骤H5得到的结果为False的情况下不再执行步骤H9。其他执行顺序的示例不再一一举例。

作为处理决策模块的另一示例，处理决策模块包括信息处理模块和加载决策模块。

信息处理模块和加载决策模块作为处理决策模块中的虚拟模块，与信息采集模块之间的交互也不是唯一固定的，在实际应用中，可以基于图23所示的示例实现，也可以基于图23所示示例以外的其他示例实现。

图23所示实施例中，步骤J1至步骤J4可以参照图18所示实施例中步骤H1至步骤H4的描述。

在加载决策模块接收到J4对应的请求后，首先需要判断ProcessRunning标志位的值，因此执行步骤J5。

步骤J5，加载决策模块从ActivityRecord获取ProcessRunning标志位的值。

步骤J6，加载决策模块确定得到的ProcessRunning标志位的值为True。

步骤J7，加载决策模块确定得到的ProcessRunning标志位的值为True的情况下，向信息处理模块发送获取预估应用启动时长和Activity加载时长之和以及预估进程启动时长的请求。

步骤J8，信息处理模块接收到加载决策模块发送的该请求后，从ActivityRecord获取历史应用启动时长和历史进程启动时长。

步骤J9，信息处理模块基于获取的历史应用启动时长和历史进程启动时长得到预估应用启动时长和Activity加载时长之和以及预估进程启动时长的请求。

步骤J10，信息处理模块将得到的预估应用启动时长和Activity加载时长之和以及预估进程启动时长的请求发送给加载决策模块。

步骤J11，加载决策模块从WindowProcessController获取进程开始启动时刻(ProcessRunning标志位变为true的时刻)。

步骤J12，加载决策模块从ActivityRecord获取应用开始启动时刻。

步骤J13，加载决策模块基于获取到的各个参数可以预估启动页显示时长，确定启动页加载策略。

步骤J14至步骤J17的内容可以参照图18所示实施例中的相关描述，在此不再赘述。

本申请所示实施例以应用启动时长和进程启动时长记录在信息采集模块中的ActivityRecord中，在应用下次启动时处理决策模块从信息采集模块的ActivityRecord中再获取为例。实际应用中，信息采集模块中的ActivityRecord也可以在应用启动完成后，将获取到的进程启动时长和应用启动时长发送到处理决策模块中的信息处理模块存储，即信息处理模块负责维护上述实施例中的表2。在应用下次启动时信息处理模块不再从信息采集模块获取历史数据。本申请实施例对具体实现方式不做限定。

如前所述，本申请实施例通过图8至图10所示实施例实现应用在后台被杀后再次启动时显示快照页的方案；通过图18至图23所示实施例实现应用在后台被杀后再次启动时预估应用启动响应时长，根据应用启动响应时长决策显示快照页还是过渡页。

在实际应用中，图18至图23所示实施例的实现(执行快照页显示策略时)需要基于图8至图10所示实施例提供的显示快照页的方案。

为了便于理解，通过图24描述应用在后台被杀后再次启动时预估应用启动响应时长，根据应用启动响应时长决策显示快照页的流程示意图。

本申请实施例主要在图8至图10所示的实施例的基础上，在步骤M6至步骤M7之间增加图18至图22所示实施例中的步骤H4至步骤H12。

本申请实施例以在图8所示实施例基础上，在步骤M6至步骤M7之间增加图18所示实施例中的步骤H4至步骤H12为例进行说明。

当然，图24中，在图8所示实施例的基础上，还可以增加其他步骤。

作为示例，在应用后台被杀时，增加图18所示实施例中的步骤F3至步骤F4。

若应用在后台存在自启行为，在图8所示实施例中增加步骤G1至步骤G4。

在应用接收到操作B(即图20所示实施例中的操作3)之后，增加图18所示实施例中的步骤H3。

其他步骤的描述请参照图8所示实施例和图18所示实施例中的描述，在此不再赘述。

另外，在图18所示实施例中，步骤H13，Activityrecord基于策略加载快照页的步骤也可以理解为通过Activityrecord通过步骤M7指示tasksnapshotsurface执行步骤M8至步骤M14的过程。

当然，实际应用中，若经过步骤H4至步骤H12之后，得到的为加载过渡页的策略，则无需执行步骤M7至步骤M14，而是走原生的执行过渡页的流程。在此不再赘述。

本申请实施例中，以应用A作为举例，实际上，电子设备中安装的多个应用均可以适用于本申请实施例提供的应用启动方法。

作为一种示例，电子设备中可以安装第一应用和第二应用，其中第一应用和第二应用均可以适用于上述实施例提供的应用启动方法。

其中，第一应用的主进程可以记为第一进程。第一应用启动后加载的第一个应用的Activity记为第一活动。该第一活动用于得到第一应用启动后显示的第一个应用的界面。

在本申请实施例中，第一应用在某些情况(例如，电子设备开机后首次启动第一应用、电子设备安装第一应用后首次启动第一应用，电子设备上一次启动第一应用后，经过一定时长再次启动第一应用等)下的冷启动时可能显示过渡页，在另一些情况(例如，满足显示快照页的各种条件)下的冷启动时，可能显示快照页。

首先以第一应用冷启动时显示过渡页为例，电子设备显示系统桌面，系统桌面上显示第一应用的图标的情况下，用户输入第一操作，该第一操作作用于第一应用的图标，则电子设备启动第一应用的第一进程，电子设备显示过渡页(该过渡页可以记为第一界面)。

以第一应用冷启动时显示快照页为例，在电子设备显示第一应用的第二界面的情况下，可以将第一应用退后台，将第一应用退后台前显示的最后界面记为第二界面。用户在退后台前，可以在第二界面上进行点击操作(可以记为第二操作)，例如，点击第二界面中显示的第一控件，使得电子设备显示应用的第三界面。当然，用户还可以在电子设备显示第三界面时，进行第三操作(例如，显示屏上的后退的手势、点击电子设备显示的导航控件中的后退控件等)，使得电子设备从显示第三界面退回到显示第二界面。触发第一应用退后台的操作记为第四操作。在第一应用退后台后，触发第一应用再次到前台运行的操作记为第五操作。其中，第一应用退后台保存的快照可以记为第一图像。

由于电子设备在接收用户输入的第五操作之前，第一应用可能存在自启，也可能未自启，因此，所述电子设备接收用户输入的第五操作之后，可能直接采用第一应用后台自启的第一进程启动应用的第一活动，也可能需要启动第一应用的第一进程，在第一应用的第一进程启动完成后，再采用第一应用的第一进程启动第一应用的第一活动。当然，在电子设备本次启动后，显示了快照页，再显示第二界面(上一次退后台前显示的最后界面)。

当然，实际应用中，由于第一应用的进程有可能在后台自启，根据用户的第五操作的时机不同(上述示例中的情况二和情况三)，导致应用本次启动时的响应时长不同，本次启动后有可能将过渡页作为启动页，也有可能将快照页作为启动页。

即即使采用相同的操作、相同的过程启动第一应用，第一应用也可能显示过渡页，也肯能显示快照页。

作为显示过渡页的一种示例，电子设备显示第一应用的第二界面，所述第二界面包括第一控件；

响应于作用于所述第一控件的第二操作，所述电子设备显示所述第一应用的第三界面；

响应于第三操作，所述电子设备显示所述第一应用的所述第二界面；

所述电子设备接收用户输入的第四操作；

响应于所述第四操作，所述电子设备将所述第一应用切换到后台运行；

所述电子设备销毁所述第一进程；

所述电子设备启动所述第一进程；

所述电子设备接收用户输入的第五操作；

响应于所述第五操作，所述电子设备启动第一活动，所述电子设备显示显示第一界面，所述电子设备显示所述第二界面，其中，所述第一活动用于生成所述第二界面，所述第一界面包括：广告页、Logo页或空白页。

在电子设备显示第二界面的情况下，若用户采用相同的操作、相同的过程启动第一应用，第一应用可能显示快照页。

作为显示快照页的一种示例，由于上一次启动第一应用后，第一应用显示第二界面，第二界面中包含第一控件，采用相同的过程(同样先退后台再启动)再次启动第一应用：

响应于作用于所述第一控件的第二操作，所述电子设备显示所述第一应用的第三界面；

响应于第三操作，所述电子设备显示所述第一应用的所述第二界面；

所述电子设备接收用户输入的第四操作；

响应于所述第四操作，所述电子设备将所述第一应用切换到后台运行；

所述电子设备销毁所述第一进程；

所述电子设备启动所述第一进程；

所述电子设备接收用户输入的第五操作；

响应于所述第五操作，所述电子设备启动所述第一活动，所述电子设备显示第一图像，所述电子设备显示所述第二界面，其中，所述第一图像为包含所述第一控件的图像。

由于第二应用和第一应用同为电子设备中安装的应用，因此，第二应用和第一应用启动时的情况下相同。在实际应用中，每个应用的启动响应时长可能不同，导致第一应用启动时可能将快照页作为启动页，也可能将过渡页作为启动页；第二应用启动时可能将快照页作为启动页，也可能将过渡页作为启动页。

为了便于区分，可以将第二应用的主进程可以记为第二进程。第二应用启动后加载的第一个应用的Activity记为第二活动。该第二活动用于得到第二应用启动后显示的第一个应用的界面。

在本申请实施例中，将第二应用退后台前显示的最后界面记为第四界面。用户在退后台前，可以在第四界面上进行点击操作(可以记为第六操作)，例如，点击第四界面中显示的第二控件，使得电子设备显示应用的第五界面。当然，用户还可以在电子设备显示第五界面时，进行第七操作(例如，显示屏上的后退的手势、点击电子设备显示的导航控件中的后退控件等)，使得电子设备从显示第五界面退回到显示第四界面。触发第二应用退后台的操作记为第八操作。在第二应用退后台后，触发第二应用再次到前台运行的操作记为第九操作。其中，第二应用退后台保存的快照可以记为第二图像。

由于电子设备在接收用户输入的第九操作之前，第二应用可能存在自启，也可能未自启，因此，所述电子设备接收用户输入的第九操作之后，可能直接采用第二应用后台自启的第二进程启动应用的第二活动，也可能需要启动第二应用的第二进程，在第二应用的第二进程启动完成后，再采用第二应用的第二进程启动第二应用的第二活动。当然，由于第二应用启动后可能显示过渡页也可能显示快照页。该第二应用显示的过渡页可以记为第六界面，该第二应用显示的快照页可以记为第二图像，第二图像为包含第二控件的图像。

另外，实际应用中，缓存的Activity实际上为缓存的Activity索引。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种计算机程序产品，当计算机程序产品在第一设备上运行时，使得电子设备可实现上述各个方法实施例中的步骤。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质至少可以包括：能够将计算机程序代码携带到第一设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

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

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (29)

1.一种应用启动方法，其特征在于，包括：

电子设备接收用户输入的第一操作，所述第一操作作用于第一应用的图标；

响应于所述第一操作，所述电子设备启动所述第一应用的第一进程，所述电子设备显示第一界面，所述第一界面包括：广告页、Logo页或空白页；

所述电子设备显示所述第一应用的第二界面，所述第二界面包括第一控件；

响应于作用于所述第一控件的第二操作，所述电子设备显示所述第一应用的第三界面；

响应于第三操作，所述电子设备显示所述第一应用的所述第二界面；

所述电子设备接收用户输入的第四操作；

响应于所述第四操作，所述电子设备将所述第一应用切换到后台运行；

所述电子设备销毁所述第一进程；

所述电子设备接收用户输入的第五操作；

响应于所述第五操作，所述电子设备启动所述第一进程，所述电子设备显示第一图像，所述电子设备显示所述第二界面，其中，所述第一图像为包含所述第一控件的图像。

2.如权利要求1所述的方法，其特征在于，所述电子设备销毁所述第一进程之后，所述电子设备接收用户输入的第五操作之前，所述方法还包括：

所述电子设备启动所述第一进程；

所述电子设备接收用户输入的第五操作之后，所述方法还包括：

响应于所述第五操作，所述电子设备启动所述第一应用的第一活动，所述电子设备显示所述第一图像，所述电子设备显示所述第二界面，其中，所述第一图像为包含所述第一控件的图像，所述第一活动用于生成所述第二界面。

3.如权利要求1或2所述的方法，其特征在于，所述方法还包括：

所述电子设备显示第二应用的第四界面，所述第四界面包括第二控件；

响应于作用于所述第二控件的第六操作，所述电子设备显示所述第二应用的第五界面；

响应于第七操作，所述电子设备显示所述第二应用的所述第四界面；

所述电子设备接收用户输入的第八操作；

响应于所述第八操作，所述电子设备将所述第二应用切换到后台运行；

所述电子设备销毁所述第二应用的第二进程；

所述电子设备接收用户输入的第九操作；

响应于所述第九操作，所述电子设备启动所述第二进程，所述电子设备显示第六界面，所述电子设备显示所述第四界面，其中，所述第六界面包括：广告页、Logo页或空白页。

4.如权利要求1或2所述的方法，其特征在于，所述电子设备显示第一图像之前，所述方法还包括：

所述电子设备确定所述电子设备中存储有所述第一图像的索引；

所述电子设备确定所述第一应用的应用启动响应时长小于第一值，所述应用启动响应时长为所述电子设备接收所述第五操作至所述电子设备显示所述第二界面之间的时长；

所述电子设备确定所述第一应用的任务栈中存储有第一活动，所述第一活动用于生成所述第二界面；

所述电子设备获取所述电子设备中存储的所述第一图像的索引和所述第一应用的窗口信息，所述第一图像的索引用于表示所述第一图像在所述电子设备中的存储位置，所述第一应用的窗口信息包括所述电子设备显示所述第一图像时的显示参数。

5.如权利要求3所述的方法，其特征在于，所述电子设备显示第六界面之前，所述方法还包括：

所述电子设备确定所述电子设备中存储有第二图像的索引，所述第二图像为包含所述第二控件的图像；

所述电子设备确定所述第二应用的应用启动响应时长大于或等于第一值。

6.如权利要求4所述的方法，其特征在于，所述电子设备接收用户输入的第五操作之后，所述方法还包括：

所述电子设备确定所述第一进程是否启动；

在所述第一进程未启动的情况下，所述电子设备确定所述第一应用的应用启动响应时长为第一时长，所述第一时长由所述第一应用历史冷启动时的历史应用启动时长确定；

在所述第一进程已启动的情况下，所述电子设备确定所述第一进程已启动时长；

在所述第一进程已启动时长大于或等于第二时长的情况下，确定所述第一应用的应用启动响应时长为第三时长，所述第二时长由所述第一应用历史冷启动时的历史进程启动时长确定，所述第三时长由所述第一应用历史冷启动时的历史应用启动时长和历史进程启动时长确定；

在所述第一进程已启动时长小于所述第二时长的情况下，确定所述第一应用的应用启动响应时长为第四时长，所述第四时长由所述第一应用的历史冷启动时的历史应用启动时长和所述第一进程已启动时长确定。

7.如权利要求6所述的方法，其特征在于，所述电子设备确定所述第一进程是否启动包括：

所述电子设备获取所述第一进程的processrunning标志位；

在所述processrunning标志位为第一标识符的情况下，所述电子设备确定所述第一进程已启动；

在所述processrunning标志位不为所述第一标识符的情况下，所述电子设备确定所述第一进程未启动。

8.如权利要求7所述的方法，其特征在于，所述电子设备确定所述第一进程已启动时长包括：

所述电子设备计算当前时刻与所述第一进程的开始启动时刻的第二差值，所述第一进程的已启动时长为所述第二差值，所述第一进程的开始启动时刻为所述第一进程的processrunning标志位最后一次变为所述第一标识符的时刻；

或者，所述电子设备计算接收所述第五操作的时刻与所述第一进程的开始启动时刻的第三差值，所述第一进程的已启动时长为所述第三差值；

或者，所述电子设备计算第一时刻与所述第一进程的开始启动时刻的第四差值，所述第一时刻为所述电子设备接收所述第五操作的时刻至所述当前时刻之间的任一时刻，所述第一进程的已启动时长为所述第四差值。

9.如权利要求6至8任一项所述的方法，其特征在于，所述方法还包括：

所述电子设备获取所述第一应用历史上最后N次冷启动时的历史应用启动时长和历史进程启动时长，N为大于或等于1的自然数；

所述电子设备根据所述第一应用历史上最后N次冷启动时的历史应用启动时长得到第二值，所述第二值为预估的所述第一应用本次启动时的进程启动时长和Activity加载时长之和；

所述电子设备根据所述第一应用历史上最后N次冷启动时的历史进程启动时长得到第三值，所述第三值为预估的所述第一应用本次启动时的进程启动时长；

其中，所述第一时长为所述第二值，所述第二时长为所述第三值，所述第三时长为所述第二值减去所述第三值，第四时长为所述第二值减去所述第一进程已启动时长。

10.如权利要求9所述的方法，其特征在于，所述电子设备根据所述第一应用历史上最后N次冷启动时的历史应用启动时长得到第二值包括：

所述电子设备获取第一应用历史上最后N次冷启动时的历史应用启动时长以及分别对应的权重，N为大于或等于2的自然数；

所述电子设备计算所述历史上最后N次冷启动时的历史应用启动时长的加权平均值，得到所述第二值；

所述电子设备根据所述第一应用历史上最后N次冷启动时的历史进程启动时长得到第三值包括：

所述电子设备获取历史上最后N次冷启动时的历史进程启动时长以及分别对应的权重；

所述电子设备计算所述历史上最后N次冷启动时的历史进程启动时长的加权平均值，得到所述第三值。

11.如权利要求10所述的方法，其特征在于，历史上最后N次冷启动时的第i次冷启动的时刻小于第j次冷启动时的时刻，第i次冷启动时的历史应用启动时长的权重小于或等于第j次冷启动时的历史应用启动时长的权重，第i次冷启动时的历史进程启动时长的权重小于或等于第j次冷启动时的历史进程启动时长的权重，i和j均为小于或等于N的正整数，i不等于j。

12.如权利要求11所述的方法，其特征在于，第i次冷启动时应用启动时长的权重为S^{N -i}，S为衰减系数。

13.如权利要求9所述的方法，其特征在于，N等于1。

14.如权利要求6至13任一项所述的方法，其特征在于，在所述第一进程未启动的情况下，所述方法还包括：

在所述第一进程启动完成之后，所述电子设备通过所述第一进程将所述第一进程的本次进程启动时长发送给systemserver进程；

所述电子设备从所述systemserver进程获取所述本次进程启动时长；

所述电子设备将所述本次进程启动时长存储，所述本次进程启动时长为所述第一应用下次启动时的历史进程启动时长。

15.如权利要求6至14任一项所述的方法，其特征在于，在所述第一进程未启动的情况下，所述方法还包括：

在所述电子设备显示所述第二界面之后，所述电子设备通过ActivityMetricsLogger获取所述第二界面的绘制完成的第一时刻和所述电子设备检测到所述第五操作的第二时刻；

所述电子设备通过ActivityMetricsLogger计算所述第一时刻和所述第二时刻的差值，得到所述第一应用的本次应用启动时长；

所述电子设备将所述本次应用启动时长存储，所述本次应用启动时长为所述第一应用下次启动时的历史应用启动时长。

16.如权利要求4、6至15任一项所述的方法，其特征在于，所述电子设备接收用户输入的第四操作之后，所述方法还包括：

所述电子设备基于所述第二界面生成所述第一图像，存储所述第一图像；

所述电子设备在第一存储空间缓存所述第一图像的索引。

17.如权利要求16所述的方法，其特征在于，所述电子设备销毁所述第一应用的第一进程之后，所述方法还包括：

所述电子设备从所述第一存储空间获取所述第一图像的索引；

所述电子设备从windowstate获取所述第一应用的窗口信息；

所述电子设备在第二存储空间缓存所述第一图像的索引和所述第一应用的窗口信息；

所述电子设备在任务栈中缓存所述第一应用的任务栈顶部的活动，所述第一应用的任务栈顶部的活动为所述第一活动。

18.如权利要求17所述的方法，其特征在于，在所述电子设备缓存所述第一图像的索引、所述第一应用的窗口信息和所述第一活动之后，所述方法还包括：

所述电子设备删除所述第一存储空间缓存的所述第一图像的索引；

所述电子设备删除所述windowstate记录的所述第一应用的窗口信息。

19.如权利要求18所述的方法，其特征在于，所述电子设备获取所述电子设备中存储的所述第一图像的索引和所述第一应用的窗口信息包括：

所述电子设备从所述第二存储空间获取所述第一图像的索引和所述第一应用的窗口信息。

20.如权利要求19所述的方法，其特征在于，所述电子设备从所述第二存储空间获取所述第一图像的索引和所述第一应用的窗口信息之前，所述方法还包括：

所述电子设备从所述第一存储空间未获取到所述第一图像的索引。

21.如权利要求17至20任一项所述的方法，其特征在于，所述电子设备确定所述第一应用的任务栈中存储有所述第一活动包括：

所述电子设备通过Tasksnapshotsurface向所述第一应用的任务栈发送第一请求，所述第一请求用于获取所述第一应用的任务栈中缓存的所述第一活动；

在所述电子设备从所述第一应用的任务栈中获取到缓存的所述第一活动的情况下，所述电子设备确定所述第一应用的任务栈中存储有所述第一活动。

22.如权利要求21所述的方法，其特征在于，在所述电子设备通过Tasksnapshotsurface向所述第一应用的任务栈发送第一请求之前，所述方法还包括：

所述电子设备通过Tasksnapshotsurface向所述第一应用的任务栈发送第二请求，所述第二请求用于获取所述第一应用的任务栈中记录的所述第一活动；

所述电子设备基于所述第二请求未获取到所述第一活动。

23.如权利要求21或22所述的方法，其特征在于，所述电子设备确定所述第一应用的任务栈中存储有所述第一活动之前，所述方法还包括：

所述电子设备通过Tasksnapshotsurface从Activityrecord获取所述第一应用的任务栈。

24.如权利要求17至23任一项所述的方法，其特征在于，在所述电子设备缓存所述第一图像的索引、所述第一应用的窗口信息和所述第一活动之后，所述方法还包括：

在所述电子设备的显示配置被修改的情况下，所述电子设备删除所述第二存储空间缓存的所述窗口信息和所述第一图像的索引，删除所述第一应用的任务栈中缓存的所述第一活动；

在所述第二存储空间存储的所述第一图像的索引和所述第一应用的窗口信息的时长大于第五时长的情况下，所述电子设备删除所述第二存储空间缓存的所述窗口信息和所述第一图像的索引，删除所述第一应用的任务栈中缓存的所述第一活动；

在所述电子设备关机或重启的情况下，所述电子设备删除所述第二存储空间缓存的所述窗口信息和所述第一图像的索引，删除所述第一应用的任务栈中缓存的所述第一活动；

在所述电子设备卸载所述第一应用的情况下，所述电子设备删除所述第二存储空间缓存的所述窗口信息和所述第一图像的索引，删除所述第一应用的任务栈中缓存的所述第一活动。

25.如权利要求4、6至23任一项所述的方法，其特征在于，所述显示参数包括屏幕适配信息和窗口属性信息。

26.一种应用启动方法，其特征在于，包括：

电子设备显示第一应用的第二界面，所述第二界面包括第一控件；

响应于作用于所述第一控件的第二操作，所述电子设备显示所述第一应用的第三界面；

响应于第三操作，所述电子设备显示所述第一应用的所述第二界面；

所述电子设备接收用户输入的第四操作；

响应于所述第四操作，所述电子设备将所述第一应用切换到后台运行；

所述电子设备销毁所述第一应用的第一进程；

所述电子设备启动所述第一进程；

所述电子设备接收用户输入的第五操作；

响应于所述第五操作，所述电子设备启动第一活动，所述电子设备显示显示第一界面，所述电子设备显示所述第二界面，其中，所述第一活动用于生成所述第二界面，所述第一界面包括：广告页、Logo页或空白页；

响应于作用于所述第一控件的第二操作，所述电子设备显示所述第一应用的第三界面；

响应于第三操作，所述电子设备显示所述第一应用的所述第二界面；

所述电子设备接收用户输入的第四操作；

响应于所述第四操作，所述电子设备将所述第一应用切换到后台运行；

所述电子设备销毁所述第一进程；

所述电子设备启动所述第一进程；

所述电子设备接收用户输入的第五操作；

响应于所述第五操作，所述电子设备启动所述第一活动，所述电子设备显示第一图像，所述电子设备显示所述第二界面，其中，所述第一图像为包含所述第一控件的图像。

27.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器与存储器耦合，所述处理器用于运行所述存储器中存储的计算机程序，以使得所述电子设备实现如权利要求1至26任一项所述的方法。

28.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储计算机程序，所述计算机程序在处理器上运行时实现如权利要求1至26任一项所述的方法。

29.一种计算机程序产品，其特征在于，当所述计算机程序产品在电子设备上运行时，使得所述电子设备实现如权利要求1至26任一项所述的方法。

Images