一种应用启动管理方法、装置、终端及设备
文献发布时间：2023-06-19 11:32:36
技术领域
本文属于移动互联领域，具体涉及一种应用启动管理方法、装置、终端及设备。
背景技术
随着科学技术发展，以智能手机为例的智能设备能覆盖大部分日常生活的场景，同时移动应用已经深入用户的生活的各个场景，打车出行、线上购物、扫码买单、线上缴费、即时通讯等等各种场景都需要用到智能手机，随着实现场景的增加，应用软件也越来越多，应用软件(App)启动的速度会越来越影响到用户的使用体验感，应用启动速度成为应用软件存留率的重要因素，现有技术中，应用启动过程中各种任务启动顺序是固定的，各种任务执行时可能出现互相等待或者空转，加大耗时，而对于每个应用程序启动优化一般是开发者在电脑(PC)端检测手机侧启动该应用程序的启动耗时，从而实现一定的启动任务时序的调整，这种方式效率低下，很难根据任务的实际启动情况实时调整。
发明内容
针对现有技术的上述问题，本文的目的在于，提供一种应用启动管理方法、装置、终端及设备，能够实现应用启动任务时序的自动调节，提高启动速度。
为了解决上述技术问题，本文的具体技术方案如下：
一方面，本文提供一种应用启动管理方法，所述方法包括：
根据预先配置的任务启动队列启动应用，并获取各个任务的启动耗时；
根据所述预先配置的任务启动队列，确定各个任务之间的依赖关系；
根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合；
根据所述各个任务的启动耗时，计算所述初始任务启动队列集合中每个初始任务启动队列的启动总耗时，并将启动总耗时最少的初始任务启动队列确定为目标任务启动队列，以使当所述应用下次启动时，按照所述目标任务启动队列启动。
当所述应用为首次启动时，所述预先配置的任务启动队列为人工配置的任务启动队列；
当所述应用为非首次启动时，所述预先配置的任务启动队列为上一次应用启动完成后确定的目标任务启动队列。
进一步地，所述获取各个任务的启动耗时包括：
获取各个任务的启动起始时间和结束时间；
根据所述启动起始时间和结束时间，确定各个任务的启动耗时。
作为可选地，所述获取各个任务的启动起始时间和结束时间包括：通过设置插桩函数获取各个任务的启动起始时间和结束时间。
进一步地，根据所述预先配置的任务启动队列，确定各个任务之间的依赖关系，包括：
根据所述预先配置的任务启动队列，获得各个任务的任务类型和启动时序；
根据所述任务类型和所述启动时序，确定不同任务之间的相关性，以此确定各个任务之间的依赖关系。
进一步地，所述根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合，包括：
根据所述依赖关系，对各个任务进行拓扑排序，生成多组有向无环图，其中每个所述有向无环图中的顶点为不同的任务，顶点之间的向边和箭头分别表示不同任务之前的依赖关系和启动时序，每个所述有向无环图表示一个初始任务启动队列；
根据多组所述有向无环图，确定应用下次启动时的初始任务启动队列集合。
进一步地，所述根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合之后还可以包括：
获取用户调整启动任务的操作指令，并根据所述操作指令确定调整后的各个任务之间的依赖关系；
根据调整后各个任务之间的依赖关系，获取应用下次启动时调整后的初始任务启动队列集合。
进一步地，所述用户调整启动任务的操作指令包括增加或减少启动任务。
进一步地，所述获取用户调整启动任务的操作指令，并根据所述操作指令确定调整后的各个任务之间的依赖关系，包括：
根据用户操作指令，确定增加或减少下次启动时的任务；
根据增加或减少启动时的任务，确定应用下次启动时调整后的各个任务；
根据本次启动时各个任务之间的依赖关系和历史任务启动队列中各个任务的依赖关系，确定应用下次启动时调整后各个任务之间的依赖关系。
进一步地，当应用下次启动时存在新增任务时，所述目标任务启动队列的确定包括：
获取新增任务的历史启动耗时；
根据新增任务的历史启动耗时和其他非新增任务的启动耗时，计算调整后的初始任务启动队列集合中每个初始任务启动队列的启动总耗时；
确定调整后的初始任务启动队列集合中启动总耗时最少的初始任务启动队列为目标任务启动队列。
进一步地，所述根据所述各个任务的启动耗时，计算所述初始任务启动队列集合中每个初始任务启动队列的启动总耗时，并将启动总耗时最少的初始任务启动队列确定为目标任务启动队列，之后包括：
将所述目标任务启动队列保存到存储单元中，以使应用下次启动时按照所述目标任务启动队列启动。
作为可选地，以使当所述应用下次启动时，按照所述目标任务启动队列启动，包括：
所述应用下次启动时，通过线程控制单元使用统一线程池对所述目标任务启动队列中任务进行创建、调度和排序。
另一方面，本文还提供一种应用启动管理装置，所述装置包括：
启动耗时获取模块，用于根据预先配置的任务启动队列启动应用，并获取各个任务的启动耗时；
依赖关系确定模块，用于根据所述预先配置的任务启动队列，确定各个任务之间的依赖关系；
初始任务启动队列集合获取模块，用于根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合；
目标任务启动队列确定模块，用于根据所述各个任务的启动耗时，计算所述初始任务启动队列集合中每个初始任务启动队列的启动总耗时，并将启动总耗时最少的初始任务启动队列确定为目标任务启动队列，以使当所述应用下次启动时，按照所述目标任务启动队列启动。
另一方面，本文还提供一种终端，所述终端包括存储单元、处理单元及存储在存储单元上并可在处理单元上运行的计算机程序，所述处理单元执行所述计算机程序时实现如上述所述的方法步骤。
另一方面，本文还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述所述的方法步骤。
另一方面，本文还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行计算机程序，所述计算机程序被处理器执行时实现如上述所述的方法步骤。
采用上述技术方案，本文所述的一种应用启动管理方法、装置、终端及设备，通过获得启动时应用中任务启动队列确定启动应用时各个任务之间的依赖关系，并根据依赖关系获得多组初始任务启动队列，通过计算每组初始任务启动队列的启动总耗时，确定启动总耗时最短的出师任务启动队列为目标任务启动队列，即应用下一次启动时的启动任务队列，本文能快速确定应用下次的任务启动耗时最短队列，从而实现启动队列的自动调整，提高应用启动速度。
为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。
附图说明
为了更清楚地说明本文实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本文的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1示出了本文实施例中应用启动管理方法的步骤示意图；
图2示出了本文实施例中任务启动耗时获取的步骤示意图；
图3示出了本文实施例中调整后的各个任务之间依赖关系确定步骤示意图；
图4示出了本文实施例中调整任务后的目标任务启动队列获取步骤示意图；
图5示出了本文实施例中应用启动管理方法的步骤示意图；
图6示出了本文实施例中有向无环图的示意图；
图7示出了本文实施例中应用启动管理装置的结构示意图；
图8示出了本文实施例中计算机设备的结构示意图。
附图符号说明：
100、启动耗时获取模块；
200、依赖关系确定模块；
300、初始任务启动队列集合获取模块；
400、目标任务启动队列确定模块；
702、计算机设备；
704、处理器；
706、存储器；
708、驱动机构；
710、输入/输出模块；
712、输入设备；
714、输出设备；
716、呈现设备；
718、图形用户接口；
720、网络接口；
722、通信链路；
724、通信总线。
具体实施方式
下面将结合本文实施例中的附图，对本文实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本文一部分实施例，而不是全部的实施例。基于本文中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本文保护的范围。
需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先对本说明书实施例中的技术名词进行解释：
插桩函数(程序插桩)：程序插桩，最早是由J.C.Huang教授提出的，是在保证被测程序原有逻辑完整性的基础上在程序中插入一些探针(又称为“探测仪”，本质上就是进行信息采集的代码段，可以是赋值语句或采集覆盖信息的函数调用)，通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，可以获得程序的控制流和数据流信息，进而得到逻辑覆盖等动态信息，从而实现测试目的的方法。
有向图：一个有向图D是指一个有序三元组(V(D)，A(D)，ψD)，其中ψD为关联函数，它使A(D)中的每一个元素(称为有向边或弧)对应于V(D)中的一个有序元素(称为顶点或点)对。
有向无环图(Directed Acyclic Graph)：有向无环图指的是一个无回路的有向图。如果有一个非有向无环图，且A点出发向B经C可回到A，形成一个环。将从C到A的边方向改为从A到C，则变成有向无环图。有向无环图的生成树个数等于入度非零的节点的入度积。在图论中，如果一个有向图无法从某个顶点出发经过若干条边回到该点，则这个图是一个有向无环图。
拓扑排序:对一个有向无环图(Directed Acyclic Graph简称DAG)G进行拓扑排序，是将G中所有顶点排成一个线性序列，使得图中任意一对顶点u和v，若边
随着人们对智能手机等终端设备的依赖越来越大，提高智能手机的体验感也是每个服务商重点追求的一个方面，其中智能手机能覆盖的场景越来越多，每个应用软件的启动速度成为影响用户体验感的重要因素，现有技术中，应用启动过程中各个任务启动顺序都是固定的，在复杂的应用场景下，各个任务执行时可能出现互相等待或者空转，加大耗时，而对于每个应用程序的启动优化都是开发者在电脑端通过人工调整启动队列，这种方式效率低下，调整频率低，而且很难根据每个任务的实际启动情况实时调整。
为了解决上述问题，本说明书实施例提供适应于智能终端的应用启动管理方法，具体为：通过获取当前应用程序启动时各个任务之间的依赖关系，自动进行拓扑排序得到多组启动队列，再通过每个任务当前启动时的启动耗时，计算每组启动队列的启动总耗时，总而可以得到启动总耗时最少的启动队列作为应用程序下一次启动时的启动队列，本说明书实施例通过应用程序每次启动时得到每个任务的启动耗时及依赖关系，得到下一次应用程序启动时的最短路径，可以实时对应用程序启动任务队列进行自动优化，可以实现移动终端对应用程序的加速启动。
其中所述智能终端可以是车机控制设备、智能手机、台式电脑、平板电脑、笔记本电脑、数字助理、智能可穿戴设备等类型的能够运用应用程序的实体设备；其中，智能可穿戴设备可以包括智能手环、智能手表、智能眼镜、智能头盔等。当然，所述智能终端并不限于上述具有一定实体的电子设备，其还可以为运行于上述电子设备中的软体，例如，所述智能终端可以为服务商提供给用户的网页页面或应用。
所述智能终端可以包括通过数据总线相连的显示屏、存储设备和处理器。所述显示屏用于显示操作界面或者与用户交互等，该显示屏可以是车机、手机或者平板电脑等的触摸屏等。所述存储设备用于存储拍摄装置的程序代码和数据资料等，该存储设备可以是智能终端的内存，也可以是智能媒体卡(smart media card)、安全数字卡(secure digitalcard)、快闪存储器卡(flash card)等储存设备。所述处理器可以是单核或多核处理器。
进一步地，本文实施例提供了一种应用启动管理方法，能够对应用程序启动队列进行实时优化，提高应用程序启动速度。图1是本文实施例提供的一种应用启动管理方法的步骤示意图，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的如图1所示，所述方法可以包括：
S101：根据预先配置的任务启动队列启动应用，并获取各个任务的启动耗时；
S102：根据所述预先配置的任务启动队列，确定各个任务之间的依赖关系；
S103：根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合；
S104：根据所述各个任务的启动耗时，计算所述初始任务启动队列集合中每个初始任务启动队列的启动总耗时，并将启动总耗时最少的初始任务启动队列确定为目标任务启动队列，以使当所述应用下次启动时，按照所述目标任务启动队列启动。
在应用程序启动时，通过预先配置的任务启动队列启动，从而可以获得每个任务的启动耗时，并且通过预先配置的任务启动队列可以获得每个任务之间的依赖关系，从而可以通过所述依赖关系得到多组的任务启动队列，并结合上述得到的每个任务的启动耗时，可以计算得出每组任务启动队列的启动总耗时，进而可以选出下一次应用软件启动时的目标任务启动队列，也就是说，所述目标任务启动队列就是应用下一次启动时的预先配置的任务启动队列，本文能自动快速的根据上一次应用启动情况调节下一次应用启动时的启动队列，从而实现应用启动速度的自动优化，提高了应用启动速度优化的频率，减少了部分任务完成后的CPU空转，提高了用户体验感。
可以理解为，所述依赖关系为各个任务之间的关联性，即各个任务启动时序的关系，其中任务启动队列可以为单个应用程序启动过程中各个启动线程之间的队列，各个任务可以为启动过程中各个线程，示例性地，通过预先配置的任务启动队列可以确定启动任务有四个任务：A、B、C和D；其中A为应用程序起始任务，B和C依赖于A，D依赖于C，同时终点依赖于B和D，因此可以形成该应用程序中各个任务之间的依赖关系，此时对这个关系集进行拓扑排序，得出一个线性的序列，则排在前面的任务就是需要先完成的任务，如图6所示，为通过上述依赖关系确定的有向无环图，也可以为本次应用程序启动时的预先配置的任务启动队列执行时序，当然，在一些其他需要更多个任务启动的应用程序，其中各个任务之间的依赖关系更复杂，确定的有向无环图更多，因此可以从中选择耗时较短的路径，具体选择步骤在下文详述。
在实际工作中，针对一具体的应用程序在启动中，可以包括如下启动顺序：初始化数据库、初始化推送、初始化各种第三方组件(第三方地图、第三方分享等)、检测新版本、下载广告数据等，通过各个任务的启动顺序和类型可以确定它们之间的相关性，比如初始化推送的执行是依赖初始化数据库的成功才能执行，因此初始化推送依赖于初始化数据库，第三方组件中的第三方地图和第三方分享为同类型任务，并无先后顺序，因此可以同时执行或有现有顺序，检测新版本和下载广告数据的执行也并无直接关联，因此二者也无依赖关系，因此通过上述初始的任务执行顺序以及各个任务类型就可以得到各个任务之间的依赖关系。
在本说明书实施例中，所述预先配置的任务启动队列根据应用启动的实际情况设置，具体为：
当所述应用为首次启动时，所述预先配置的任务启动队列为人工配置的任务启动队列；
当所述应用为非首次启动时，所述预先配置的任务启动队列为上一次应用启动完成后确定的目标任务启动队列。
其中所述首次启动可以为应用程序下载后的第一次启动，或者是所述应用程序版本更新后的第一次启动，又或者是所述智能终端更换系统后的第一次启动，当所述应用程序首次启动时，所述智能终端内存没有储存所述应用程序的历史启动信息，因此需要通过任务配置的任务启动队列进行启动，需要说明的是，在应用程序版本更新后，可能会存在启动任务调整的情况，因此为了保证应用程序顺利启动，通过更新前的任务启动队列可能会存在启动失败的情况，因此在本说明书实施例中，在所述应用程序版本更新后，还是以人工配置的任务启动队列启动。
进一步的，目前针对智能终端上应用程序(APP)的任务启动耗时是通过在各个任务中加入trace代码，比如Debug.startMethodTracing("xxx")，在应用程序完成后，使用PC工具traceview获取智能终端内存上生成.trace文件，进而分析各个任务的启动耗时，当前使用在任务启动代码中插入trace代码，trace代码会在任务启动过程中保持持续运行，会使应用本身启动耗时加大，无法真实反映应用的运行情况，而且操作繁琐，无法做到合理安排启动任务。因此为了提高对各个任务启动耗时获取的便捷性和准确性，如图2所示，在本说明书实施例中，获取各个任务的启动耗时包括：
S201：获取各个任务的启动起始时间和结束时间；
S202：根据所述启动起始时间和结束时间，确定各个任务的启动耗时。
可以理解为，本说明书实施例是通过在每个任务启动的开始和结束插入函数，只需获得每个任务启动开始和结束的时间，通过计算时间差就能得到每个任务的启动耗时，因此在任务启动过程中并没有其他代码运行，从而避免了额外代码运行带来的启动耗时加大情况，提高了每个任务启动耗时计算的准确性。
作为可选地，所述获取各个任务的启动起始时间和结束时间通过如下方式获得：通过设置插桩函数获取各个任务的启动起始时间和结束时间。插桩函数(又称程序插桩)是在保证被测程序原有逻辑完整性的基础上在程序中插入一些探针(代码段)进行信息采集，通过探针的执行并抛出程序运行的特征数据，通过对这些数据的分析，可以获得程序数据流信息，因此在本说明书实施例中，是通过在每个任务程序运行前后插入代码段获取任务程序运行的开始和结束时间，从而获得准确的任务启动耗时。
在实际工作中，为了实现上述每个任务启动耗时的准确获得，在应用程序开发过程中或上传与目标终端系统(比如IOS系统、Android系统)进行适配过程中，可以提前进行插桩函数的设置，这样所述目标终端系统对应的智能终端处理器就能通过运行提前设置的插桩函数获得每个任务启动的准确耗时，在一些其他实施例中，还可以为智能终端在进行系统配置时，与其适配的应用程序中的任务代码提前进行插桩函数的设置，这样也可以实现对任务启动耗时的获得，具体的设置方式在本说明书实施例不做限定。
在本说明书实施例中，为了确定应用程序启动过程中各个任务之间的关系，根据所述预先配置的任务启动队列，确定各个任务之间的依赖关系，可以包括以下步骤：
根据所述预先配置的任务启动队列，获得各个任务的任务类型和启动时序；
根据所述任务类型和所述启动时序，确定不同任务之间的相关性，以此确定各个任务之间的依赖关系。
可以理解为，通过各个任务的任务类型可以获得各个任务在执行时的逻辑关系，从而可以全面的判断各个任务之间的初始相关性，再结合预先配置的任务启动队列中各个任务的启动时序，可以对已经确定的初始相关性进一步选择得到各个任务之间的相关性，比如确定起始的任务和最终的任务等等。通过确定各个任务之间的依赖关系就能在预先配置的任务启动队列基础上，再去获得其他能够顺利启动所述应用程序的任务启动队列。
因此，在本说明书实施例中，所述根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合，包括：
根据所述依赖关系，对各个任务进行拓扑排序，生成多组有向无环图，其中每个所述有向无环图中的顶点为不同的任务，顶点之间的向边和箭头分别表示不同任务之前的依赖关系和启动时序，每个所述有向无环图表示一个初始任务启动队列；
根据多组所述有向无环图，确定应用下次启动时的初始任务启动队列集合。
可以理解为，在一有向无环图中，如图6所示，每个顶点代表一个任务，并且每个任务只能出现一次，向边两端的顶点代表的任务有依赖关系，其中箭头方向表示相连两个任务的执行先后顺序，具体可以通过广度优先算法获得起点任务到各个点的路径。确定的初始任务启动队列集合中的每个任务启动队列都可以为下一次应用程序启动时的队列，即下一次应用程序启动时的各个任务启动路径，为了提高下一次应用程序启动时的启动速度，可以通过上述步骤获得的每个任务的启动耗时，计算每个任务启动队列的启动总耗时，这样就可以选择其中启动总耗时最少的队列作为目标任务启动队列，示例性地，在已经确定各个路径的基础上，可以通过深度优先算法计算每个任务启动队列的启动总耗时。
在本说明书实施例中，用户在操作应用程序的过程中还可以根据需要调整下次启动时的任务，具体地，所述根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合之后还可以包括：
获取用户调整启动任务的操作指令，并根据所述操作指令确定调整后的各个任务之间的依赖关系；
根据调整后各个任务之间的依赖关系，获取应用下次启动时调整后的初始任务启动队列集合。
其中，所述调整启动任务可以为调整任务的数量，比如增加或减少启动任务，一般情况下，通过用户操作调整的任务可以为第三方组件，比如通过减少第三方组件的数量，可以减少任务启动的路径，从而提高应用程序启动的时间；相应地，用户也可以根据需要增加任务数量，具体操作时，可以为用户通过智能终端的操作界面进入到对应应用程序的启动项选择，并根据需求选择增加或减少启动项，在所述应用程序下次启动时，就能根据调整后的任务启动。
在本说明书实施例中，如图3所示，所述获取用户调整启动任务的操作指令，并根据所述操作指令确定调整后的各个任务之间的依赖关系，还可以包括如下步骤：
S301：根据用户操作指令，确定增加或减少下次启动时的任务；
S302：根据增加或减少启动时的任务，确定应用下次启动时调整后的各个任务；
S303：根据本次启动时各个任务之间的依赖关系和历史任务启动队列中各个任务的依赖关系，确定应用下次启动时调整后各个任务之间的依赖关系。
其中当确定为增加下次启动时的任务时，则增加的任务和原先的各个任务之间的依赖关系不明确，因此可以通过获得智能手段存储的历史任务启动队列中去获得增加的任务和其他任务之间的依赖关系。而当所述应用程序为首次启动时，则不存在历史任务启动队列，或者历史任务启动队列并不存在增加的任务时，则可以按照增加的任务的类型与原先的各个任务进行匹配，从而得到相似的任务类型，这样就可以建立增加的任务和匹配成功的任务之间的依赖关系。在一些其他实施例中，还可以按照开发者预设的依赖关系确定规则或启动队列确定规则进行匹配，在本说明书实施例不做赘述。
相应地，当确定为减少下次启动时的任务时，则可以将减少的任务和其他任务之间的依赖关系省略，从而得到新的各个任务之间的依赖关系，当然在一些特殊情况下，由于减少的任务导致其中部分任务的依赖关系不明确，也可以通过智能终端存储的历史任务启动队列进行依赖关系的进一步确定。
需要说明的是，在开发者进行默认启动项选项设置时，已经通过预设的逻辑程序保证了任意组合的默认启动项都能实现应用程序的顺利启动，因此通过增加或减少启动任务并不会导致应用程序的死机(启动失败)，具体预设的逻辑程序在本说明书不做赘述。
当应用程序下次启动时存在减少任务时，可以通过减少后的任务之间的依赖关系确定初始任务启动队列集合，然后在根据每个任务的启动耗时计算初始任务启动队列集合中的每个队列的启动总耗时，进而确定其中启动总耗时最少的任务启动队列为下一次应用程序启动时的目标任务启动队列。
进一步地，如图4所示，当应用下次启动时存在新增任务时，所述目标任务启动队列的确定包括：
S401：获取新增任务的历史启动耗时；
S402：根据新增任务的历史启动耗时和其他非新增任务的启动耗时，计算调整后的初始任务启动队列集合中每个初始任务启动队列的启动总耗时；
S403：确定调整后的初始任务启动队列集合中启动总耗时最少的初始任务启动队列为目标任务启动队列。
可以理解为，在不确定新增任务的启动耗时时，可以通过历史启动耗时来确定，所述历史启动耗时可以为上一次所述新增任务启动时的启动耗时，也可以为在启动预设次数的平均耗时，这样就可以当做新增任务当前阶段的启动耗时，从而实现对初始任务启动队列集合中每个队列启动总耗时的计算，进而选出启动总耗时最少的目标任务启动队列。
进一步地，在已经确定了目标任务启动队列时，即确定了目标有向无环图，将所述目标任务启动队列保存到存储单元中，以使应用下次启动时按照所述目标任务启动队列启动。当应用程序下一次运行时，读取存储单元中的目标有向无环图，根据目标有向无环图进行任务排序，并使用线程池进行任务的创建、调度、排序。
在进行应用程序下一次启动时，还是按照上一次启动的流程：对函数进行插桩，计算耗时，并继续动态调整启动顺序，生成新的目标有向无环图，用来调整下一次启动，通过每次启动不断地对应用进行耗时分析，并且根据算法生成新的有向图，可以使得应用启动越来越快，实现启动任务智能重排，提升用户体验。
需要说明的是，为了减少任务执行时出现CPU空转，所述应用下次启动时，通过线程控制单元使用统一线程池对所述目标任务启动队列中任务进行创建、调度和排序，使用统一线程池进行管理调度，避免不同线程之间无谓的CPU抢占而消耗系统性能，导致启动耗时增加。
如图5所示，为本说明书实施例一具体实例，其中所述应用管理方法包括如下步骤：
S501：接收应用启动指令；
S502：读取用户设置的各个任务信息，并确定各个任务之间的依赖关系；
S503：判断任务是否首次启动；
S504：若应用是首次启动，则根据预设的任务启动队列进行启动；
S505：若应用不是首次启动，则读取储存器中保存的最优有向无环图，并进行任务排序、管理和调度；
S506：获取应用在启动过程中各个任务的启动耗时；
S507：根据各个任务之间的依赖关系拓扑排序形成多组有向无环图；
S508：通过计算多组有向无环图的启动总耗时，确定目标有向无环图；
S509：目标有向无环图保存在储存器中；
S510：启动完成。
本说明书实施例，通过对应用程序每次启动过程中各个任务启动队列的重新调整，使得新队列能够实现更快的启动总耗时，从而保证对应用程序启动速度的自动实时调节，在每次启动时都能实现下次更快的启动，避免了开发者手动分析任务耗时和排序，达到移动客户端加速启动的效果，提高了用户体验。
基于同一发明构思，如图7所示，本说明书实施例还提供一种应用启动管理装置，所述装置包括：
启动耗时获取模块100，用于根据预先配置的任务启动队列启动应用，并获取各个任务的启动耗时；
依赖关系确定模块200，用于根据所述预先配置的任务启动队列，确定各个任务之间的依赖关系；
初始任务启动队列集合获取模块300，用于根据所述依赖关系，获取应用下次启动时的初始任务启动队列集合；
目标任务启动队列确定模块400，用于根据所述各个任务的启动耗时，计算所述初始任务启动队列集合中每个初始任务启动队列的启动总耗时，并将启动总耗时最少的初始任务启动队列确定为目标任务启动队列，以使当所述应用下次启动时，按照所述目标任务启动队列启动。
本说明书实施例提供的一种应用启动管理装置所取得的有益效果和上述方法取得的有益效果一致，在本说明书不做赘述。
另一实施例中，本说明书还提供一种终端，所述终端包括存储单元、处理单元及存储在存储单元上并可在处理单元上运行的计算机程序，所述处理单元执行所述计算机程序时实现如上述所述的方法步骤。
如图8所示，为本文实施例提供的一种计算机设备，所述计算机设备802可以包括一个或多个处理器804，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备802还可以包括任何存储器806，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器806可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备802的固定或可移除部件。在一种情况下，当处理器804执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备802可以执行相关联指令的任一操作。计算机设备802还包括用于与任何存储器交互的一个或多个驱动机构808，诸如硬盘驱动机构、光盘驱动机构等。
计算机设备802还可以包括输入/输出模块810(I/O)，其用于接收各种输入(经由输入设备812)和用于提供各种输出(经由输出设备814))。一个具体输出机构可以包括呈现设备816和相关联的图形用户接口(GUI)818。在其他实施例中，还可以不包括输入/输出模块810(I/O)、输入设备812以及输出设备814，仅作为网络中的一台计算机设备。计算机设备802还可以包括一个或多个网络接口820，其用于经由一个或多个通信链路822与其他设备交换数据。一个或多个通信总线824将上文所描述的部件耦合在一起。
通信链路822可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路822可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。
对应于图1-图5中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。
本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图1至图5所示的方法。
应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。
还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。
另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。
- 一种应用启动管理方法、装置、终端及设备
- 一种应用程序启动方法、应用程序启动装置及终端设备