应用程序启动优化方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用程序启动优化方法、装置、电子设备及存储介质。

背景技术

如今，随着智能手机等设备的逐渐普及，应用程序(Application，APP)得到了迅速发展，用户在各大应用市场上能够下载使用的应用程序越来越多。其中，应用程序开发者致力于为用户提供更好的用户体验，用户体验的一个很重要的衡量因素就是应用程序的运行速度，特别是应用程序的启动速度，如果应用程序的启动速度过慢，将导致启动时长过长，严重影响用户体验。

目前，随着应用程序的开发迭代，新增的类也逐渐增多，需要引用的头文件也越来越多，文件的引用链也会越来越长，越来越复杂。在直接引用或间接引用的过程中，一个类会因为引用头文件过多而关联大量的量，即使有些关联并没有什么用，甚至不需要关联这些量，如此造成应用程序启动时，类关联量的次数增多，降低了应用程序的启动速度。

发明内容

为了解决上述在直接引用或间接引用的过程中，一个类会因为引用头文件过多而关联大量的量，即使有些关联并没有什么用，甚至不需要关联这些量，如此造成应用程序启动时，类关联量的次数增多，降低了应用程序的启动速度的技术问题，本申请实施例提供了一种应用程序启动优化方法、装置、电子设备及存储介质。具体技术方案如下：

在本申请实施例的第一方面，首先提供了一种应用程序启动优化方法，所述方法包括：

在启动应用程序的情况下，获取所述应用程序调用的函数的标识，并存储至预设标识列表中；

根据所述预设标识列表中的所述标识，确定目标函数，所述目标函数为加载类的过程中将所述类与量进行关联的函数；

确定所述目标函数所引用的所述类，获取所述类所关联的量，对所述量进行优化处理。

在一个可选的实施方式中，在执行所述方法之前，还包括：

响应于在集成应用的字段添加操作，在所述集成应用添加目标字段；以及，

确定所述应用程序中可执行的代码文件，在所述可执行的代码文件中引入目标头文件，所述目标头文件中定义虚函数。

在一个可选的实施方式中，所述在启动应用程序的情况下，获取所述应用程序调用的函数的标识，并存储至预设标识列表中，包括：

在所述集成应用启动所述应用程序的情况下，通过所述虚函数执行以下处理：

获取所述应用程序每次调用的函数，并判断所述函数是否为主函数；

在所述函数不是所述主函数的情况下，获取所述函数的标识，并存储至所述预设标识列表中；

在所述函数为所述主函数的情况下，将所述预设标识列表存储至预设文件夹。

在一个可选的实施方式中，所述根据所述预设标识列表中的所述标识，确定目标函数，包括：

从所述预设文件夹中获取所述预设标识列表，并遍历所述预设标识列表中的所述标识，获取包含目标字符的目标标识；

将所述目标标识对应的函数确定为目标函数，并将所述目标标识存储至预设标识表格中；

所述确定所述目标函数所引用的所述类，包括：

确定所述预设标识表格中的所述目标标识对应的目标函数所引用的所述类。

在一个可选的实施方式中，在所述虚函数中预先添加条件断点，所述条件断点的条件为判定函数的标识与所述预设标识表格中的所述目标标识一致；

所述确定所述预设标识表格中的所述目标标识对应的目标函数所引用的所述类，包括：

在所述集成应用重新启动所述应用程序的情况下，通过所述虚函数中的所述条件断点执行以下处理：

获取所述应用程序每次调用的函数，判断所述函数的标识是否与所述预设标识表格中的所述目标标识一致；

在所述函数的标识与所述预设标识表格中的所述目标标识一致的情况下，暂停启动所述应用程序，获取所述函数所引用的所述类。

在一个可选的实施方式中，所述获取所述类所关联的量，包括：

查找所述类对应的文件，其中，所述文件为所述类直接或间接引用的文件；

从所述类对应的文件中，获取所述类所关联的量。

在一个可选的实施方式中，所述对所述量进行优化处理，包括：

通过全局搜索，判断所述量中的全局变量是否正在使用；

在所述全局变量不在使用的情况下，删除所述全局变量；

和/或，

通过全局搜索，判断所述量中的全局常量是否正在使用；

在所述全局常量不在使用的情况下，删除所述全局常量。

在一个可选的实施方式中，所述方法还包括：

在所述全局变量正在使用的情况下，将所述全局变量写入所述应用程序中可执行的代码文件。

在一个可选的实施方式中，所述方法还包括：

在所述全局常量正在使用的情况下，根据所述全局常量的使用范围，对所述全局常量进行处理。

在一个可选的实施方式中，所述根据所述全局常量的使用范围，对所述全局常量进行处理，包括：

在所述全局常量的使用范围超过预设使用范围的情况下，对所述全局常量采用预设形式的预处理操作；

在所述全局常量的使用范围未超过预设使用范围的情况下，将所述全局常量放置在应用到所述全局常量的位置。

在本申请实施例的第二方面，还提供了一种应用程序启动优化装置，所述装置包括：

标识获取模块，用于在启动应用程序的情况下，获取所述应用程序调用的函数的标识，并存储至预设标识列表中；

函数确定模块，用于根据所述预设标识列表中的所述标识，确定目标函数，所述目标函数为加载类的过程中将所述类与量进行关联的函数；

类确定模块，用于确定所述目标函数所引用的所述类；

量获取模块，用于获取所述类所关联的量；

量优化模块，用于对所述量进行优化处理。

在一个可选的实施方式中，所述装置还包括：

字段添加模块，用于响应于在集成应用的字段添加操作，在所述集成应用添加目标字段；以及，

文件引入模块，用于确定所述应用程序中可执行的代码文件，在所述可执行的代码文件中引入目标头文件，所述目标头文件中定义虚函数。

在一个可选的实施方式中，所述标识获取模块具体用于：

在所述集成应用启动所述应用程序的情况下，通过所述虚函数执行以下处理：

获取所述应用程序每次调用的函数，并判断所述函数是否为主函数；

在所述函数不是所述主函数的情况下，获取所述函数的标识，并存储至所述预设标识列表中；

在所述函数为所述主函数的情况下，将所述预设标识列表存储至预设文件夹。

在一个可选的实施方式中，所述函数确定模块具体用于：

从所述预设文件夹中获取所述预设标识列表，并遍历所述预设标识列表中的所述标识，获取包含目标字符的目标标识；

将所述目标标识对应的函数确定为目标函数，并将所述目标标识存储至预设标识表格中；

所述类确定模块具体用于：

确定所述预设标识表格中的所述目标标识对应的目标函数所引用的所述类。

在一个可选的实施方式中，在所述虚函数中预先添加条件断点，所述条件断点的条件为判定函数的标识与所述预设标识表格中的所述目标标识一致；

所述类确定模块具体用于：

在所述集成应用重新启动所述应用程序的情况下，通过所述虚函数中的所述条件断点执行以下处理：

获取所述应用程序每次调用的函数，判断所述函数的标识是否与所述预设标识表格中的所述目标标识一致；

在所述函数的标识与所述预设标识表格中的所述目标标识一致的情况下，暂停启动所述应用程序，获取所述函数所引用的所述类。

在一个可选的实施方式中，所述量获取模块具体用于：

查找所述类对应的文件，其中，所述文件为所述类直接或间接引用的文件；

从所述类对应的文件中，获取所述类所关联的量。

在一个可选的实施方式中，所述量优化模块具体用于：

通过全局搜索，判断所述量中的全局变量是否正在使用；

在所述全局变量不在使用的情况下，删除所述全局变量；

和/或，

通过全局搜索，判断所述量中的全局常量是否正在使用；

在所述全局常量不在使用的情况下，删除所述全局常量。

在一个可选的实施方式中，所述量优化模块还用于：

在所述全局变量正在使用的情况下，将所述全局变量写入所述应用程序中可执行的代码文件。

在一个可选的实施方式中，所述量优化模块还用于：

在所述全局常量正在使用的情况下，根据所述全局常量的使用范围，对所述全局常量进行处理。

在一个可选的实施方式中，所述量优化模块还用于：

在所述全局常量的使用范围超过预设使用范围的情况下，对所述全局常量采用预设形式的预处理操作；

在所述全局常量的使用范围未超过预设使用范围的情况下，将所述全局常量放置在应用到所述全局常量的位置。

在本申请实施例的第三方面，还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现上述第一方面中任一所述的应用程序启动优化方法。

在本申请实施例的第四方面，还提供了一种存储介质，所述存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面中任一所述的应用程序启动优化方法。

在本申请实施例的第五方面，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的应用程序启动优化方法。

本申请实施例提供的技术方案，在启动应用程序的情况下，获取应用程序调用的函数的标识，并存储至预设标识列表中，根据预设标识列表中的标识，确定目标函数，目标函数为加载类的过程中将类与量进行关联的函数，确定目标函数所引用的类，获取类所关联的量，对量进行优化处理。在启动应用程序的情况下，通过获取应用程序调用的函数的标识，存储至预设标识列表中，并据此确定目标函数，确定目标函数所引用的类，获取类所关联的量，对量进行优化处理，如此应用程序启动过程中可以减少类对量的关联操作，进而减少启动加载负荷，从而减少加载时间，提高了应用程序的启动速度，减少了应用程序的启动时长。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1为本申请实施例中示出的一种应用程序启动优化方法的实施流程示意图；

图2为本申请实施例中示出的另一种应用程序启动优化方法的实施流程示意图；

图3为本申请实施例中示出的一种量优化方法的实施流程示意图；

图4为本申请实施例中示出的一种应用程序启动优化装置的结构示意图；

图5为本申请实施例中示出的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

下文的公开提供了许多不同的实施例或例子用来实现本申请的不同结构。为了简化本申请的公开，下文中对特定例子的部件和设置进行描述。当然，它们仅仅为示例，并且目的不在于限制本申请。此外，本申请可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。

在本申请实施例中，先介绍一下应用程序A启动过程：

1、应用程序A刚被唤起时，操作系统首先会分配给应用程序A一整块虚拟内存(也称逻辑内容)，该虚拟内存并非实际的物理内存。真正的物理内存会在应用程序A启动过程中按需分段提供，提供后将物理内存与虚拟内存进行关联对应。

2、唤起后，应用程序A的执行程序会从硬盘里拷贝到内存中。操作系统不会立即分配一个应用程序A所需的完整的物理内存，此时应用程序A会出现内存不足的情况，便会向操作系统发起缺页中断的信号，此时应用程序A会进入等待。操作系统接收到信号后，会去尝试查找空闲的内存或者回收其它应用程序A的内存，重新分配给应用程序A，然后应用程序A才继续执行。

3、在分配到内存后，操作系统会先初始化一个初始内存地址，然后将应用程序A执行文件拷贝到内存中。

4、关联应用程序A中的动态库。

5、初始化oc类和量。在这个过程中，若应用程序A当前应加载的类已经被拷贝至内存中，则调用对应的加载方法，否则等待应用程序A拷贝完成后再加载。

6、在加载oc类过程中，如果类文件引用了一个或多个量，应用程序A会调用一个cxx_+"MD5"的函数方法，通过该方法将量与oc类关联起来。

7、完成加载后，调用应用程序A的main函数，开始初始化应用实例，完成应用程序A初始化和启动。

随着应用程序A的开发迭代，功能日渐强大。新增的代码日积月累的增加，新增的类也越来越多。在开发过程中，时长会使用到量。

大量的类产生，再加上编写应用程序A时，大量的类相互引用。也就导致了一个庞大而又复杂的引用网产生。数量巨大的量在这个过程中被关联到类上。久而久之，便增加了类关联量的次数，也就导致了步骤6操作太多。

在这些量的关联中，许多关联是多余的，仅仅只是在文件引用中，顺便被关联上的，这对于应用程序A来讲就成为了一种无用的负载。

为此，本申请实施例对量进行优化处理，如此应用程序启动过程中可以减少类对量的关联操作，进而减少启动加载负荷，从而减少加载时间，提高了应用程序的启动速度，减少了应用程序的启动时长。

基于上述发明构思，如图1所示，为本申请实施例提供的一种应用程序启动优化方法的实施流程示意图，该方法应用于电子设备，具体可以包括以下步骤：

S101，在启动应用程序的情况下，获取应用程序调用的函数的标识，并存储至预设标识列表中。

在本申请实施例中，对于应用程序，对应用程序进行编译并启动，从而在启动应用程序的情况下，获取应用程序在调用主函数之前每次调用的函数的标识，并存储至预设标识列表中。

需要说明的是，对于应用程序中主函数，一般指的是应用程序中main函数，对于函数的标识，例如可以是函数的名称(亦称之为函数名)，本申请实施例对此不作限定。

例如，对于应用程序A，对应用程序A进行编译并启动，从而在启动应用程序A的情况下，获取应用程序A在调用main函数之前每次调用的函数的名称，并存储至预设函数名称列表中。

S102，根据预设标识列表中的标识，确定目标函数，目标函数为加载类的过程中将类与量进行关联的函数。

在本申请实施例中，对于预设标识列表，其中记录着应用程序在调用主函数之前每次调用的函数的标识，由此可以根据预设标识列表中的标识，确定目标函数。

需要说明的是，对于目标函数，通常指的是加载类的过程中将类与量进行关联的函数，为了后续定位到类所关联的量，在这里，量包括全局变量和/或全局常量，本申请实施例对此不作限定。

例如，根据预设标识列表中的标识，确定目标函数，目标函数为加载类的过程中将类与全局变量进行关联的函数。

例如，根据预设标识列表中的标识，确定目标函数，目标函数为加载类的过程中将类与全局常量进行关联的函数。

例如，根据预设标识列表中的标识，确定目标函数，目标函数为加载类的过程中将类与全局变量和全局常量进行关联的函数。

S103，确定目标函数所引用的类，获取类所关联的量，对量进行优化处理。

在本申请实施例中，对于目标函数，可以确定目标函数所引用的类(例如oc类)，获取类所关联的量，如此定位到量，可以对量进行优化处理。

需要说明的是，对量进行优化处理(例如删除操作)，意在为了减少类对量的关联操作，如此应用程序启动过程中可以减少类对量的关联操作，进而减少启动加载负荷，从而减少加载时间，提高了应用程序的启动速度，减少了应用程序的启动时长。

通过上述对本申请实施例提供的技术方案的描述，在启动应用程序的情况下，通过获取应用程序调用的函数的标识，存储至预设标识列表中，并据此确定目标函数，确定目标函数所引用的类，获取类所关联的量，对量进行优化处理，如此应用程序启动过程中可以减少类对量的关联操作，进而减少启动加载负荷，从而减少加载时间，提高了应用程序的启动速度，减少了应用程序的启动时长。

在本申请实施例中，Xcode(Xcode是运行在操作系统Mac OS X上的集成应用)提供了一个clang(clang是一个C语言、C++、Objective-C语言的轻量级编译器)插桩的方式，通过往代码中注入方法，将特有的方法添加到应用程序A中每个函数调用之前。该功能会使应用程序A中两个虚函数生效，通过实现这两个虚函数，从而可完成对函数调用的获取，获取到的函数可获取到调用类和调用名等信息。这里获取的具体方式可以是截获。

通过clang插桩获取的信息，将应用程序A调用main函数前获取的函数信息记录下来，生成一张表格，解析记载负荷项。

获取的方法中，添加条件断点(结合记录下来的函数信息表格)，定位负荷项的调用堆栈找到调用的类，通过查看类文件的实现，定位量。

定位到量后，对其进行分析，若应用程序A中不在使用量则删除量，若局部使用的全局常量，则写到方法中作为普通常量，若广泛使用的全局常量，则改写为预定义的形式。

基于上述发明构思，如图2所示，为本申请实施例提供的另一种应用程序启动优化方法的实施流程示意图，该方法应用于电子设备，具体可以包括以下步骤：

S201，响应于在集成应用的字段添加操作，在集成应用添加目标字段。

在本申请实施例中，对于Xcode，在其工程的Build Setting配置栏，找到Other CFiags配置选项。添加字段：-fsanitize-coverage＝func，trace-pc-guard。这里是Xcode提供的配置功能，设置该字段，意味着应用程序开启了clang功能。

基于此，用户可以在集成应用的Build Setting配置栏，Other C Fiags配置选项中执行相应的字段添加操作，从而可以响应于在集成应用的字段添加操作，在集成应用添加目标字段，这里目标字段如上述-fsanitize-coverage＝func，trace-pc-guard。

S202，确定应用程序中可执行的代码文件，在可执行的代码文件中引入目标头文件，目标头文件中定义虚函数。

在本申请实施例中，在添加了目标字段之后，需要引入dlfcn.h和libkern/OSAtomic.h两个头文件，然后实现__sanitizer_cov_trace_pc_guard_init(uint32_t*start,uint32_t*stop)和__sanitizer_cov_trace_pc_guard(uint32_t*guard)这两个方法。Xocde中申明了这两个方法为虚函数，在添加了目标字段后生效。生效后需要实现这两个方法，应用程序才会编译通过。

基于此，可以确定应用程序中可执行的代码文件，在可执行的代码文件中引入目标头文件，这里的目标头文件可以如上述所示的dlfcn.h和libkern/OSAtomic.h两个头文件，通过这两个头文件实现了__sanitizer_cov_trace_pc_guard_init(uint32_t*start,uint32_t*stop)和__sanitizer_cov_trace_pc_guard(uint32_t*guard)这两个方法，这两个方法在Xocde中被申明为虚函数。

需要说明的是，对于可执行的代码文件(即.m文件)，可以随机确定应用程序中某个可执行的代码文件，也可以是由用户指定应用程序中某个可执行的代码文件，本申请实施例对此不作限定。

此外，在本申请实施例中，对于由上述两个头文件实现的__sanitizer_cov_trace_pc_guard_init(uint32_t*start,uint32_t*stop)和__sanitizer_cov_trace_pc_guard(uint32_t*guard)这两个方法，可以在这两个方法中添加条件断点，也就意味着在虚函数中预先添加条件断点，条件断点的条件为判定函数的标识与预设标识表格中的目标标识一致。

S203，在集成应用启动应用程序的情况下，通过虚函数执行以下处理。

S204，获取应用程序每次调用的函数，并判断函数是否为主函数。

S205，在函数不是主函数的情况下，获取函数的标识，并存储至预设标识列表中。

S206，在函数为主函数的情况下，将预设标识列表存储至预设文件夹。

在本申请实施例中，经过上述处理，可以在Xocde中编译并启动应用程序，从而在集成应用，编译并启动应用程序的情况下，通过虚函数执行以下处理：

获取应用程序每次调用的函数，并判断函数是否为主函数，在函数不是主函数的情况下，获取函数的标识，并存储至预设标识列表中，在函数为主函数的情况下，将预设标识列表存储至预设文件夹。其中，这里的获取具体可以是截获，即截获应用程序每次调用的函数。

由此经过上述处理，在集成应用，编译并启动应用程序的情况下，可以获取应用程序在调用主函数之前每次调用的函数的标识，并存储至预设标识列表中，在应用程序调用主函数后，将预设标识列表存储至预设文件夹。

例如，可以在Xocde中编译并启动应用程序，从而在集成应用，编译并启动应用程序的情况下，通过虚函数执行以下处理：

获取应用程序A每次调用的函数，并判断函数是否为main函数，在函数不是main函数的情况下，获取函数的函数名，并存储至预设函数名列表中，在函数为main函数的情况下，将预设函数名列表存储至预设文件夹。

由此经过上述处理，在集成应用，编译并启动应用程序A的情况下，可以获取应用程序A在调用main函数之前每次调用的函数的函数名，并存储至预设函数名列表中，在应用程序A调用main函数后，将预设函数名列表存储至预设文件夹。

需要说明的是，对于应用程序每次调用的函数，会形成调用堆栈，从而获取应用程序每次调用的函数，在函数不是主函数的情况下，从调用堆栈获取函数的标识，然后存储至预设标识列表中，本申请实施例对此不作限定。

S207，从预设文件夹中获取预设标识列表，并遍历预设标识列表中的标识，获取包含目标字符的目标标识。

S208，将目标标识对应的函数确定为目标函数，并将目标标识存储至预设标识表格中。

在本申请实施例中，可以从预设文件夹中获取预设标识列表，在得到预设标识列表后，可以遍历预设标识列表中的标识，获取包含目标字符的目标标识，将目标标识对应的函数确定为目标函数，并将目标标识存储至预设标识表格中。

例如，遍历预设函数名列表中的函数名，获取包含cxx的目标函数名，目标函数名含有cxx，后面跟着一串MD5的字符，将目标函数名对应的函数确定为目标函数，目标函数就是加载类的过程中，将量与类进行关联的函数，由此可以将目标标识存储至预设标识表格中，方便后续定位到量。

需要说明的是，在开发过程中，可能会用到多个全局变量，这些变量可能名字相同，存在于不同的库中，若没有地方直接同时引入时不会有冲突的。编译器为了解决同名变量的引入冲突，会把这些函数名在编译过程中重新定义一个名字，采用cxx+MD5的命名方式。

此外，对于预设标识表格，可以确定预设标识表格中的目标标识对应的目标函数所引用的类，对于确定预设标识表格中的目标标识对应的目标函数所引用的类的过程，具体可以参考下述步骤S209～S211。

S209，在集成应用重新启动应用程序的情况下，通过虚函数中的条件断点执行以下处理。

S210，获取应用程序每次调用的函数，判断函数的标识是否与预设标识表格中的目标标识一致。

S211，在函数的标识与预设标识表格中的目标标识一致的情况下，暂停启动应用程序，获取函数所引用的类。

S212，查找类对应的文件，其中，文件为类直接或间接引用的文件。

S213，从类对应的文件中，获取类所关联的量，对量进行优化处理。

在本申请实施例中，可以在Xcode重新编译并启动应用程序，从而在集成应用，重新编译并启动应用程序的情况下，通过虚函数中的条件断点执行以下处理，可以定位到类所关联的量：

获取应用程序每次调用的函数，判断函数的标识是否与预设标识表格中的目标标识一致，在函数的标识与预设标识表格中的目标标识一致的情况下，暂停启动应用程序，获取函数所引用的类，查找类对应的文件，其中，文件为类直接或间接引用的文件，从类对应的文件中，获取类所关联的量。

例如，在集成应用，重新编译并启动应用程序A的情况下，通过虚函数中的条件断点执行以下处理，可以定位到类所关联的量：

获取应用程序A每次调用的函数，判断函数的函数名是否与预设函数名表格中的目标函数名一致，在函数的函数名与预设函数名表格中的目标函数名一致的情况下，暂停启动应用程序A，获取函数所引用的类，查找类对应的文件，其中，文件为类直接或间接引用的文件，从类对应的文件中，获取类所关联的量。

需要说明的是，对于应用程序每次调用的函数，会形成调用堆栈，从而获取应用程序每次调用的函数，在函数的标识与预设标识表格中的目标标识一致的情况下，，从调用堆栈获取函数所引用的类，然后查找类对应的文件，其中，文件为类直接或间接引用的文件，从类对应的文件中，获取类所关联的量，本申请实施例对此不作限定。

如此经过上述处理，对所有找到的被大量引用的量进行优化处理，其中，可以将所有找到的被大量引用的量逐一作修改，将其改为预定义或者用函数获得。不同的情况可采用不同的方式去完成。

具体地，如图3所示，为本申请实施例提供的一种量优化方法的实施流程示意图，该方法应用于电子设备，具体可以包括以下步骤：

S301，通过全局搜索，判断量中的全局变量是否正在使用。

在本申请实施例中，对于Xcode，提供了全局搜索功能，因而对于全局变量，可以通过全局搜索，判断量中的全局变量是否正在使用。

需要说明的是，通过全局搜索，假设可以搜索到全局变量，说明全局变量正在使用，否则说明全局变量不在使用，本申请实施例对此不作限定。

S302，在全局变量不在使用的情况下，删除全局变量。

在本申请实施例中，对于全局变量，在全局变量不在使用的情况下，删除全局变量。

S303，在全局变量正在使用的情况下，将全局变量写入应用程序中可执行的代码文件。

在本申请实施例中，在全局变量正在使用的情况下，则改为在头文件暴露方法来读写，意味着将全局变量写入应用程序中可执行的代码文件，即写入.m文件中，这样，做关联的仅仅只影响到自身的.m文件。

S304，通过全局搜索，判断量中的全局常量是否正在使用。

在本申请实施例中，对于Xcode，提供了全局搜索功能，因而对于全局常量，可以通过全局搜索，判断量中的全局常量是否正在使用。

需要说明的是，通过全局搜索，假设可以搜索到全局常量，说明全局常量正在使用，否则说明全局常量不在使用，本申请实施例对此不作限定。

S305，在全局常量不在使用的情况下，删除全局常量。

在本申请实施例中，对于全局常量，在全局常量不在使用的情况下，删除全局常量。

S306，在全局常量正在使用的情况下，根据全局常量的使用范围，对全局常量进行处理。

在本申请实施例中，对于全局常量，在全局常量正在使用的情况下，可以根据全局常量的使用范围，对全局常量进行处理。

其中，在全局常量使用面不广的情况下，则将单一的常量放到使用处去初始化，使之成为函数的普通常量。在全局常量使用面广的情况下，可采用#define来预处理。

基于此，在全局常量的使用范围超过预设使用范围的情况下，对全局常量采用预设形式的预处理操作；在全局常量的使用范围未超过预设使用范围的情况下，将全局常量放置在应用到全局常量的位置。

如此对于量，经过如上步骤的优化处理，应用程序启动过程中可以减少类对量的关联操作，进而减少启动加载负荷，从而减少加载时间，提高了应用程序的启动速度，减少了应用程序的启动时长。

结果检测工具：

Xcode配置DYLD_PRINT_STATISTICS。该配置生效后，会在应用程序A启动后，去检测应用程序A启动过程中各个环节的加载时长，并在Xcode后台输出面板中输出报告。可以在同配置下，对比改动的效果。

Xcode辅助工具Instruments。该工具包中，提供了一个应用程序ALaunch的检测工具，该工具可以录制程序启动过程的加载项，并统计加载时长。生成可视化界面。

与上述方法实施例相对应，本申请实施例还提供了一种应用程序启动优化装置，如图4所示，该装置可以包括：标识获取模块410、函数确定模块420、类确定模块430、量获取模块440、量优化模块450。

标识获取模块410，用于在启动应用程序的情况下，获取应用程序调用的函数的标识，并存储至预设标识列表中；

函数确定模块420，用于根据预设标识列表中的标识，确定目标函数，目标函数为加载类的过程中将类与量进行关联的函数；

类确定模块430，用于确定目标函数所引用的类；

量获取模块440，用于获取类所关联的量；

量优化模块450，用于对量进行优化处理。

在一个可选的实施方式中，上述装置还包括：

字段添加模块，用于响应于在集成应用的字段添加操作，在集成应用添加目标字段；以及，

文件引入模块，用于确定应用程序中可执行的代码文件，在可执行的代码文件中引入目标头文件，目标头文件中定义虚函数。

在一个可选的实施方式中，标识获取模块具体用于：

在集成应用启动应用程序的情况下，通过虚函数执行以下处理：

获取应用程序每次调用的函数，并判断函数是否为主函数；

在函数不是主函数的情况下，获取函数的标识，并存储至预设标识列表中；

在函数为主函数的情况下，将预设标识列表存储至预设文件夹。

在一个可选的实施方式中，函数确定模块具体用于：

从预设文件夹中获取预设标识列表，并遍历预设标识列表中的标识，获取包含目标字符的目标标识；

将目标标识对应的函数确定为目标函数，并将目标标识存储至预设标识表格中；

类确定模块具体用于：

确定预设标识表格中的目标标识对应的目标函数所引用的类。

在一个可选的实施方式中，在虚函数中预先添加条件断点，条件断点的条件为判定函数的标识与预设标识表格中的目标标识一致；

类确定模块具体用于：

在集成应用重新启动应用程序的情况下，通过虚函数中的条件断点执行以下处理：

获取应用程序每次调用的函数，判断函数的标识是否与预设标识表格中的目标标识一致；

在函数的标识与预设标识表格中的目标标识一致的情况下，暂停启动应用程序，获取函数所引用的类。

在一个可选的实施方式中，量获取模块具体用于：

查找类对应的文件，其中，文件为类直接或间接引用的文件；

从类对应的文件中，获取类所关联的量。

在一个可选的实施方式中，量优化模块具体用于：

通过全局搜索，判断量中的全局变量是否正在使用；

在全局变量不在使用的情况下，删除全局变量；

和/或，

通过全局搜索，判断量中的全局常量是否正在使用；

在全局常量不在使用的情况下，删除全局常量。

在一个可选的实施方式中，量优化模块还用于：

在全局变量正在使用的情况下，将全局变量写入应用程序中可执行的代码文件。

在一个可选的实施方式中，量优化模块还用于：

在全局常量正在使用的情况下，根据全局常量的使用范围，对全局常量进行处理。

在一个可选的实施方式中，量优化模块还用于：

在全局常量的使用范围超过预设使用范围的情况下，对全局常量采用预设形式的预处理操作；

在全局常量的使用范围未超过预设使用范围的情况下，将全局常量放置在应用到全局常量的位置。

本申请实施例还提供了一种电子设备，如图5所示，包括处理器51、通信接口52、存储器53和通信总线54，其中，处理器51，通信接口52，存储器53通过通信总线54完成相互间的通信，

存储器53，用于存放计算机程序；

处理器51，用于执行存储器53上所存放的程序时，实现如下步骤：

在启动应用程序的情况下，获取所述应用程序调用的函数的标识，并存储至预设标识列表中；根据所述预设标识列表中的所述标识，确定目标函数，所述目标函数为加载类的过程中将所述类与量进行关联的函数；确定所述目标函数所引用的所述类，获取所述类所关联的量，对所述量进行优化处理。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请提供的又一实施例中，还提供了一种存储介质，该存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的应用程序启动优化方法。

在本申请提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的应用程序启动优化方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在存储介质中，或者从一个存储介质向另一个存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。