CN110362314A - 信息处理方法及装置、计算机可读介质、电子设备 - Google Patents

Abstract

本公开涉及计算机技术领域，具体涉及一种信息处理方法、一种信息处理装置、一种计算机可读介质以及一种电子设备。所述方法包括：响应于对目标应用的控制操作，提取所述目标应用对应的配置文件；读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求；将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。本公开提供的方案能够降低预优化事件的触发条件，从而提高对配置文件进行优化的触发频率。同时，仅在系统状态满足预设条件时才执行预优化事件，能够保证在不影响系统性能的情况下进行优化，提升应用的执行效率。

Description

信息处理方法及装置、计算机可读介质、电子设备

技术领域

本公开涉及计算机技术领域，具体涉及一种信息处理方法、一种信息处理装置、一种计算机可读介质以及一种电子设备。

背景技术

应用程序在Android系统中运行时，需要在虚拟机中解释执行。在执行过程中，虚拟机会不间断的收集频繁执行的Java方法，并将这些方法保存在本地的一个Profile配置文件中，系统在合适的时机可以借助这个Profile配置文件对频繁执行的Java方法进行dex2oat本地编译优化，从而提高执行效率。

但在现有方案中，现有的android系统仅能够在系统空闲且终端设备充电的情况下，每间隔24小时集中对系统的应用根据Profile配置文件进行本地编译优化。这样的优化方式触发条件较高，触发频率低。并且，不同用户对终端设备的使用频率和使用时间不同，会出现不满足上述条件的情况，导致android系统不能按时或及时的进行优化，进而影响用户对系统和应用程序的使用体验。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种信息处理方法、一种信息处理装置、一种计算机可读介质、一种电子设备，从而提供一种应用于android系统的优化方案，能够及时的对配置文件进行dex2oat本地编译优化，提高应用程序的执行效率，从而在一定程度上克服相关技术的限制和缺陷。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的第一方面，提供一种信息处理方法，包括：

响应于对目标应用的控制操作，提取所述目标应用对应的配置文件；

读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求；

将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

根据本公开的第二方面，提供一种信息处理方法，包括：

接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列；

按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态；

在所述当前系统状态为可用时，调用包管理服务以执行所述预优化事件；或者

在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行所述预优化事件。

根据本公开的第三方面，提供一种信息处理装置，包括：

配置文件提取模块，用于响应于对目标应用的控制操作，提取所述目标应用对应的配置文件；

配置文件识别模块，用于读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求；

处理请求发送模块，用于将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

根据本公开的第四方面，提供一种信息处理装置，包括：

处理请求接收模块，用于接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列；

系统状态读取模块，用于按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态；

第一执行模块，用于在所述当前系统状态为可用时，调用包管理服务以执行所述预优化事件；

第二执行模块，用于在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行所述预优化事件。

根据本公开的第五方面，提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的信息处理方法。

根据本公开的第六方面，提供一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现上述的信息处理方法。

本公开的一种实施例所提供的信息处理方法，对于应用侧来说，当目标应用启动时，可以首先提取对应的配置文件，并对配置文件中的相关参数进行读取和判断，并仅在配置文件的相关参数满足预设的条件时才生成对应的预优化事件处理请求，并将该预优化事件处理请求发送至系统侧，再由系统侧根据当前系统状态来判断是否执行对应预优化事件。通过在目标应用程序启动时便激活对应的目标线程，从而降低预优化事件的触发条件，从而提高对配置文件进行优化的触发频率。同时，仅在系统状态满足预设条件时才执行预优化事件，能够保证在不影响系统性能的情况下进行优化，提升应用的执行效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中一种信息处理方法的流程示意图；

图2示意性示出本公开示例性实施例中一种应用侧的信息处理方法流程示意图；

图3示意性示出本公开示例性实施例中一种信息处理方法的流程示意图；

图4示意性示出本公开示例性实施例中一种信息处理方法的流程示意图；

图5示意性示出本公开示例性实施例中一种信息处理装置的组成示意图；

图6示意性示出本公开示例性实施例中一种信息处理装置的组成示意图；

图7示意性示出本公开示例性实施例中一种电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

android应用程序大多采用Java语言编写，并需要在虚拟机环境下运行，虚拟机的功能便是解释、执行应用程序的代码文件。android应用程序大多为APK格式的文件，APK文件中可以包含多个不同功能的dex文件。为使APK文件可以不加改动的在所有虚拟机上运行，则需要对dex文件进行优化。在ART虚拟机中，便可以调用dex2oat将dex文件优化成二进制格式的文件，从而可以让ART虚拟机执行。而dex2oat的任务是将原来的dex文件做预先的翻译，从而可以加快APP运行的时间。但是由于某些应用程序比较复杂，所以优化的时间就比较长。

另外在代码执行过程中，虚拟机会不断的收集频繁执行的Java方法，并将这些方法保存在本地的一个Profile文件(配置文件)中，待系统在合适的时机借助这个Profile文件对频繁执行的Java方法进行dex2oat本地编译优化，从而提高执行效率。而在现有的方案中，android系统的优化方式会在系统空闲且充电的情况下，每间隔24小时集中对系统的应用程序根据Profile文件进行本地编译优化，以提高这些应用的执行速度。但这样的优化方式存在触发条件较高，触发频率低，大多数场景下难以满足该条件等缺点。

针对上述的现有技术的缺点和不足，本示例实施方式中提供了一种信息处理方法，可以保证在不影响系统性能的情况下及时进行优化。参考图1中所示，上述的信息处理方法可以包括以下步骤：

S11，响应于对目标应用的控制操作，提取所述目标应用对应的配置文件；

S12，读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求；

S13，将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

本示例实施方式所提供的信息处理方法中，一方面，通过在目标应用程序启动时便激活对应的目标线程，从而降低预优化事件的触发条件，从而提高对配置文件进行优化的触发频率；另一方面，仅在系统状态满足预设条件时才执行预优化事件，能够保证在不影响系统性能的情况下进行优化，提升应用的执行效率。

下面，将结合附图及实施例对本示例实施方式中的信息处理方法的各个步骤进行更详细的说明。

步骤S11，响应于对目标应用的控制操作，提取所述目标应用对应的配置文件。

本示例性实施例中，上述的针对目标应用的控制操作可以是在终端设备上针对目标应用程序点击、选中等以使目标应用开始执行的控制操作。上述的终端设备可以是基于android系统的手机、平板电脑、便携式笔记本等智能设备。上述的控制操作可以是在终端设备的人机交互界面上的触控操作，也可以是通过鼠标、键盘等输入设备输入的控制动作。

对于应用侧而言，具体来说，终端设备在检测到针对目标应用的启动操作后，可以响应于对所述目标应用的启动操作，启动目标线程，使该目标线程执行配置文件读取的任务。具体的，参考图2所示，可以通过目标线程首先判断目标应用的Profile配置文件是否存在。若存在配置文件，则进行后续步骤；若不存在上述的配置文件，则使目标线程进入休眠状态，并可以对配置文件进行监听；在配置文件更新后，通知并激活目标线程，执行后续的步骤。

在其他示例性实施例中，当判断不存在配置文件时，还可以设置一定的识别周期，使得目标线程每达到一时间周期时，便读取一次配置文件，判断配置文件是否存在，配置文件的读取周期可以是5s、10s或15s等时间长度。另外，还可以设置若连续多次判断不存在配置文件时，便生成提示信息或终止配置文件的读取操作。

步骤S12，读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求。

本示例性实施例中，在目标线程提取目标应用的配置文件后，便可以对其相关参数进行读取，并判断目标参数是否满足预设的条件。

举例来说，配置文件的目标参数可以是配置文件的大小等等。具体地，可以设置配置文件大小的判断阈值，如20KB、30KB等。参考图2所示，当判断配置文件的大小大于或等于该预设的判断阈值时，便可以生成预优化事件处理请求。

或者，若判断配置文件的大小小于上述的判断阈值，则表明配置文件可能存在不正确、存在错误或无法使用等情况，此时便可以将目标线程设置为休眠状态。同时，还可以对配置文件进行监听，当系统保存Profile文件时，配置文件发生更新，便可以通知并唤醒目标线程，使目标线程重新提取配置文件，并读取配置文件的相关目标参数。如果不满足则继续等待。

步骤S13，将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

本示例性实施例中，上述的预优化事件处理请求可以是针对dex2oat事件的处理请求。具体的，dex2oat事件可以包含多项参数；例如，目标应用对应的包名、执行预优化事件所占用的线程数，以及编译模型的类型。其中，包名可以是指需要进行编译优化的应用程序的包名。线程数可以是指进行此编译优化dex2oat工具开启的线程数；例如，当CUP为8核处理器时，便可以设置线程数为小于8的数量。上述的编译模式可以是指进行此编译优化所选择的编译模式，例如speed-profile模式或speed模式等。当然，还可以设置默认模式，若dex2oat事件处理请求中为指定编译模式，便可以利用默认模式对dex文件进行编译。

本示例性实施例中，参考图3所示，提供一种信息处理方法，对于系统侧来说，具体可以包括以下步骤：

步骤S31，接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列；

步骤S32，按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态；

步骤S33，在所述当前系统状态为可用时，调用包管理服务以执行所述预优化事件；或者

步骤S34，在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行所述预优化事件。

下面，将结合附图及实施例对本示例实施方式中的信息处理方法的各个步骤进行更详细的说明。

步骤S31，接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列。

本示例性实施例中，对于系统侧来说，终端设备中可以安装有多个应用程序，例如购物、社交以及交通等类型的app。系统侧可以设置dex2oat Managre(预优化管理器)，用于接收各应用程序发出的预优化事件处理请求。此外，在系统侧还可以设置dex2oat消息队列，用于将预优化事件处理请求按照接收的顺序保存在消息队列中。

步骤S32，按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态。

本示例性实施例中，对于预优化管理器来说，可以定期读取消息队列的长度，判断消息队列的长度是否为0；若消息队列的长度为0，则表明消息队列当前没有待处理的预优化事件处理请求，可以令预优化管理器进入等待状态，并在下一个周期节点时再次读取消息队列的长度，或者，也可以在新的预优化事件处理请求保存至消息队列中时，通知预优化管理器读取消息队列。

若消息队列的长度不为0，则表明当前存在若干个待处理的预优化事件处理请求，便可以提取消息队列中的第一个预优化事件处理请求，并准备执行。在对该第一个预优化事件处理请求执行结束后，可以再次对消息队列的长度进行读取，判断是否有待处理的预优化事件处理请求。

当预优化管理器在消息队列中提取一待处理的预优化事件处理请求后，还可以对当前时刻的系统状态进行读取，以判断当前的系统状态是否能够执行预优化事件处理请求。具体地，读取的系统状态可以包含多项参数，例如：CPU使用状态、内存使用状态以及当前是否存在正在执行的dex文件的编译优化操作等参数。

举例来说，可以在CPU空闲比例大于等于50％、非低内存状态以及当前没有正在执行的dex文件的编译优化任务时，判定为系统状态为可用，若有任意一项参数不满足时，便判定为系统状态为不可用。

在本公开的其他示例性实施例中，还可以读取其他的系统参数来判定系统状态是否可用；或者，也可以仅使用上述的一项或两项参数来判定系统状态是否可用，本公开对此不做特殊限定。

步骤S33，在所述当前系统状态为可用时，调用包管理服务以执行所述预优化事件。

本示例性实施例中，参考图3所示，在读取并判断当前时刻系统状态可用时，便可以调用Package Manager Service(包管理服务)来执行提取的预优化事件处理请求，执行installd任务后，根据预优化事件处理请求中所包含的各项参数调用dex2oat工具对dex文件进行编译优化。

步骤S34，在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行所述预优化事件。

本示例性实施例中，参考图4所示，若读取并判断当前时刻系统状态不可用，则不执行预优化事件处理请求。并在一预设时间间隔后重新读取系统状态，再次判断系统状态是否可用，并在系统状态为可用时再执行预优化时间处理请求。举例而言，重新读取系统状态的时间周期可以设置为10s、15s或者其他时长，本公开对此不做特殊限定。

本公开实施例所提供的方法，对于应用侧来说，当应用程序启动时，启动对应的目标线程，使其对Profile文件是否存在及相关参数进行读取和判断，并在满足预设条件时生成dex2oat事件处理请求并发送至系统侧。对于系统侧而言，在接收到dex2oat事件处理请求后，对当前时刻的系统状态进行读取和判断，并能够根据系统当前状态来决定立即执行该dex2oat事件，还是延后处理。本方案能够在应用启动完成后，根据虚拟机生成的Profile文件生成dex2oat事件处理请求，从而降低系统优化的触发条件，并提高触发频率。同时考虑到系统当前的负载状况，在不影响当前性能的情况下，对应用触发本地化编译，将频繁执行的java方法编译为二进制，加快该部分方法的执行速度，从而提高应用的执行效率。由于只有系统空闲且内存充足时进行，不会造成系统卡顿，提高了用户体验。

需要注意的是，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

进一步的，参考图5所示，本示例的实施方式中还提供一种信息处理装置50，包括：配置文件提取模块501、配置文件识别模块502和处理请求发送模块503。其中：

所述配置文件提取模块501可以用于响应于对目标应用的控制操作，提取所述目标应用对应的配置文件。

所述配置文件识别模块502可以用于读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求。

所述处理请求发送模块503可以用于将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

在本公开的一种示例中，上述的配置文件提取模块501可以是：响应于对所述目标应用的启动操作以启动目标线程，以使所述目标线程判断所述目标应用的配置文件是否存在，并在所述配置文件存在时提取所述配置文件。

在本公开的一种示例中，所述配置文件提取模块501还可以包括：进程休眠模块(图中未示出)。

所述进程休眠模块可以用于在所述配置文件不存在时，将所述目标进程置于休眠状态，并监听所述配置文件是否存在更新，以在所述配置文件更新后激活所述目标线程并提取更新后的配置文件。

在本公开的一种示例中，所述预优化事件处理请求包括以下任意一项或任意多项：所述目标应用对应的包名、执行预优化事件所占用的线程数，以及编译模型的类型。

进一步的，参考图6所示，本示例的实施方式中还提供一种信息处理装置60，包括：处理请求接收模块601、系统状态读取模块602、第一执行模块603和第二执行模块604。其中：

所述处理请求接收模块601可以用于接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列。

所述系统状态读取模块602可以用于按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态。

所述第一执行模块603可以用于在所述当前系统状态为可用时，调用包管理服务以执行预优化事件。

所述第二执行模块604可以用于在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行预优化事件。

在本公开的一种示例中，所述系统状态读取模块602可以包括：提取当前CPU占用状态参数、内存占用状态参数，以及当前是否存在dex文件编译任务，以判断当前系统状态是否可用。

上述的信息处理装置中各模块的具体细节已经在对应的信息处理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

图7示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图7示出的电子设备的计算机系统700仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(Central Processing Unit，CPU)701，其可以根据存储在只读存储器(Read-Only Memory，ROM)702中的程序或者从存储部分708加载到随机访问存储器(Random Access Memory，RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(Input/Output，I/O)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本发明的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本发明实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图1或图3所示的各个步骤。

此外，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。

Claims (10)

1.一种信息处理方法，其特征在于，包括：

响应于对目标应用的控制操作，提取所述目标应用对应的配置文件；

读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求；

将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

2.根据权利要求1所述的信息处理方法，其特征在于，所述响应于对目标应用的控制操作，提取所述目标应用对应的配置文件包括：

响应于对所述目标应用的启动操作以启动目标线程，以使所述目标线程判断所述目标应用的配置文件是否存在，并在所述配置文件存在时提取所述配置文件。

3.根据权利要求2所述的信息处理方法，其特征在于，所述提取所述目标应用对应的配置文件时，所述方法还包括：

若所述配置文件不存在，则将所述目标进程置于休眠状态，并监听所述配置文件是否存在更新，以在所述配置文件更新后激活所述目标线程并提取更新后的配置文件。

4.根据权利要求1所述的信息处理方法，其特征在于，所述预优化事件处理请求包括以下任意一项或任意多项：

所述目标应用对应的包名、执行预优化事件所占用的线程数，以及编译模型的类型。

5.一种信息处理方法，其特征在于，包括：

接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列；

按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态；

在所述当前系统状态为可用时，调用包管理服务以执行预优化事件；或者

在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行预优化事件。

6.根据权利要求5所述的信息处理方法，其特征在于，所述读取当前系统状态包括：

提取当前CPU占用状态参数、内存占用状态参数，以及当前是否存在dex文件编译任务，以判断当前系统状态是否可用。

7.一种信息处理装置，其特征在于，包括：

配置文件提取模块，用于响应于对目标应用的控制操作，提取所述目标应用对应的配置文件；

配置文件识别模块，用于读取所述配置文件的目标参数，并在目标参数符合预设要求时，生成预优化事件处理请求；

处理请求发送模块，用于将所述预优化事件处理请求发送至系统侧，以使系统侧的在系统状态满足预设条件时执行预优化事件。

8.一种信息处理装置，其特征在于，包括：

处理请求接收模块，用于接收应用侧的预优化事件处理请求，并将所述预优化事件处理请求保存至消息队列；

系统状态读取模块，用于按顺序提取所述消息队列中的预优化事件处理请求，并读取当前系统状态；

第一执行模块，用于在所述当前系统状态为可用时，调用包管理服务以执行预优化事件；

第二执行模块，用于在所述当前系统状态为不可用时，在预设时间周期后重新读取系统状态参数以判断是否执行预优化事件。

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

10.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至6中任一项所述的信息处理方法。