CN116643778A - 一种应用程序优化方法及电子设备 - Google Patents

Abstract

本申请实施例提供了一种应用程序优化方法及电子设备，涉及计算机技术领域。解决升级重启后，在较长时间内，所有应用程序都不能采用机器码执行的问题。具体方案为：电子设备获取用于升级操作系统的升级安装包；所述电子设备安装所述升级安装包；响应于所述升级安装包安装完成，所述电子设备优化编译第一数量的第一应用，得到对应的优化可执行odex文件，所述第一数量小于所述电子设备中应用程序的总数量；电子设备重启。

Description

一种应用程序优化方法及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用程序优化方法及电子设备。

背景技术

电子设备运行应用程序时，需要执行应用程序对应的代码。在可选的执行代码的方式之中，机器码执行是最高效的代码执行方式。

然而，电子设备每次系统升级之后，在较长时间内，所有应用程序都无法启用机器码执行，导致应用程序的代码执行效率不佳，影响应用程序的运行速度。

发明内容

有鉴于此，本申请提供了一种应用程序优化方法及电子设备，改善系统升级之后，应用程序的代码执行效率。

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

第一方面，本申请实施例提供的一种应用程序优化方法，所述方法包括：电子设备获取用于升级操作系统的升级安装包；电子设备安装升级安装包；响应于升级安装包安装完成，电子设备优化编译第一数量的第一应用，得到对应的优化可执行odex文件，第一数量小于电子设备中应用程序的总数量，电子设备重启。

其中，odex文件包括应用程序对应的二进制代码，应用程序具有odex文件的情况下，才能够采用机器执行的方式运行该应用程序。

在上述实施例中，安装升级数据包之后、设备重启之前，先对部分应用程序（第一数量的应用）进行编译，得到对应的odex文件。这样，在升级重启之后，电子设备中第一数量的应用程序可以采用机器码执行的方式，在升级重启后，电子设备中应用程序的平均代码执行效率。

另外，部分应用程序的编译相较于编译所有的应用程序，能够避免增加更多的升级等待时长

在一些实施例中，电子设备的操作系统包括第一操作系统和第二操作系统；所述电子设备运行于所述第一操作系统，所述电子设备安装所述升级安装包，包括：从所述升级安装包中解析出的升级数据；在第一存储分区中，写入所述升级数据，所述第一存储分区包括所述第二操作系统在所述电子设备的存储器中占用的静态分区，以及虚拟动态分区；所述响应于所述升级安装包安装完成，所述电子设备优化编译第一数量的第一应用，包括：响应于所述升级数据已写入所述第一存储分区，基于所述第二操作系统，优化编译第一数量的第一应用。

在上述实施例中，在运行第一操作系统期间，不仅可以升级第二操作系统，还可以基于升级后的第二操作系统，优化编译第一数量的第一应用。这样，在不影响用户正常使用电子设备的情况下，完成针对第二操作系统的升级，和升级后的优化编译。避免升级重启之后，所有应用程序都不能采用机器码执行的方式运行。

可以理解的，上述升级过程可称为虚拟A/B升级。通常进行虚拟A/B升级的过程中，利用升级安装包升级第二操作系统之后，通过重启，指示电子设备由运行第一操作系统切换至运行第二操作系统，这样，电子设备可以运行于升级后的操作系统。

在本申请实施例中，在电子设备切换操作系统之前，也即，电子设备运行于第一操作系统期间，第一操作系统对应的系统数据未变化，这样，升级前基于第一操作系统编译出的odex文件依然有效。这样，在电子设备切换至第二操作系统前，电子设备都可以采用机器码执行的方式，运行各个应用程序。

另外，在电子设备运行于第一操作系统期间，在第二操作系统的系统数据被更新之后，电子设备会基于更新后的第二操作系统对第一数量的应用程序进行编译，得到第一数量的odex文件，第一数量的odex可以在运行新版操作系统时使用。这样，电子设备切换操作系统之后，对于第一数量的第一应用，依然能够采用机器码执行的方式运行。

显然，在电子设备启用新版的操作系统之前，电子设备可以采用机器码执行的方式运行应用程序。在电子设备启用新版的操作系统之后，电子设备也可以采用机器码执行的方式运行部分应用程序（第一数量的第一应用）。保障电子设备运行过程中，应用程序的代码执行效率。

在一些实施例中，基于所述第二操作系统，优化编译第一数量的第一应用，包括：启动所述第二操作系统对应的虚拟机；通过所述第二操作系统的虚拟机中的编译器，优化编译第一数量的第一应用。

在一些实施例中，所述方法还包括：响应于所述电子设备完成优化编译所述第一数量的所述第一应用，将启动顺序标识配置为从所述第二操作系统启动；所述电子设备重启，包括：重启上电之后，按照所述启动顺序标识，加载所述第一存储分区中的数据，使所述电子设备运行于所述第二操作系统。

在上述实施例中，将修改启动顺序标识的流程配置在第一应用编译完成之后，可以避免出现升级后，操作系统不能正常切换的问题。

在一些实施例中，第一数量是预设值。在上述实施例中，电子设备通过限制被编译的应用程序数量，将用户等待升级重启的时长，控制在合理的范围内。

在一些实施例中，第一数量是所述电子设备在第一时长内优化编译的应用程序的数量，所述第一时长是预先配置的。在上述实施例中，电子设备通过限制编译的时长，将用户等待升级重启的时长，控制在合理的范围内。

在一些实施例中，所述第一应用是满足第一条件的应用程序；所述第一条件包括以下一项或多项的组合：所述第一应用是所述电子设备的应用程序中活跃等级由高到低排列在前N位的应用程序，其中，N为正整数，所述活跃等级是根据应用运行记录及应用下载量评估出的应用的活跃程度；所述第一应用属于第一集合，所述第一集合是由提供指定类型服务的应用程序组成的集合。

在上述实施例中，确保升级重启之后，用户常用的应用程序（比如，活跃等级排列在前N位的应用程序）或者，用途较为重要的应用程序（比如，提供指定类型服务），可以采用机器码执行的方式运行，覆盖用户主要的使用需求。

在一些实施例中，所述电子设备优化编译第一数量的第一应用，包括：按照所述第一应用的活跃等级，由高到低的顺序，依次编译所述第一应用，直至满足截止条件；所述截止条件为被编译的所述第一应用的数量达到预设的所述第一数量，或者，所述截止条件为优化编译的时间达到预设的第一时长。

在一些实施例中，在所述电子设备重启之后，所述方法还包括：在满足第二条件的情况下，优化编译第二数量的第二应用；所述第二应用包括无有效的odex文件的应用程序，以及具有有效的odex文件且存在未编译的热点函数的应用程序；所述电子设备满足第二条件的概率高于所述电子设备满足第三条件的概率，所述第三条件是所述电子设备的操作系统中自带的触发优化编译应用程序的场景条件。

可以理解的，升级重启之后，电子设备需要在满足第三条件的情况下，才能继续编译不含有效odex文件的应用程序，或许，新增热点函数的应用程序。通常上述第三条件不易满足，这样，重启之后，上述应用程序需要等待比较长的时间，才能够被编译。在等待期间，上述应用程序的代码执行效率都很低。

在上述实施例中，在升级重启之后，通过降低触发编译的场景条件，也即，启用更容易满足的第二条件，替代原生的第三条件，可以缩短电子设备中应用程序等待被编译的时长，进一步提升电子设备中应用程序的代码执行效率。

在一些实施例中，第二数量是预先配置的，第二数量大于所述第一数量。

在一些实施例中，在满足第二条件的情况下，优化编译第二数量的第二应用，可以包括：按照第二应用的活跃等级，由高到低的顺序，依次编译各个第二应用。

在一些实施例中，在满足第二条件且优化编译的第二应用达到第二数量的情况下，暂停优化编译应用程序；在满足第三条件的情况下，继续优化编译应用程序。

在上述实施例中，实现对于原生的编译场景条件的兼容，在完成设备内所有应用程序编译的过程中，降低对用户实际使用电子设备的影响。

在一些实施例中，所述第二条件包括以下一项或多项之间的组合：处于灭屏状态；处于充电状态；实际电量大于第一值；所述第三条件为所述电子设备处于所述灭屏状态、处于上述充电状态且所述实际电量大于第二值；所述第二值大于所述第一值。

第二方面，本申请实施例提供的一种应用程序优化方法，所述方法包括：电子设备获取用于升级操作系统的升级安装包；在利用所述升级安装包完成升级之后，所述电子设备重启；响应于升级后的首次重启，在满足第二条件的情况下，优化编译第二数量的第二应用；所述第二应用包括无有效的odex文件的应用程序，以及具有有效的odex文件且存在未编译的热点函数的应用程序，所述热点函数是所述应用程序的配置文件中记录的函数；所述电子设备满足第二条件的概率高于所述电子设备满足第三条件的概率，所述第三条件是所述电子设备的操作系统中自带的触发优化编译应用程序的场景条件。

在上述实施例中，在升级重启之后，通过降低触发编译应用程序的场景条件，比如，启用更容易满足的第二条件，替代原生的第三条件，可以缩短电子设备中应用程序等待被编译的时长，提升电子设备中应用程序的代码执行效率。

在一些实施例中，所述方法还包括：在满足所述第二条件且优化编译的所述第二应用达到第二数量的情况下，暂停优化编译应用程序；在满足所述第三条件的情况下，继续优化编译应用程序。

在一些实施例中，在满足第二条件的情况下，优化编译第二数量的第二应用，可以包括：按照第二应用的活跃等级，由高到低的顺序，依次编译各个第二应用。

在一些实施例中，在电子设备重启之前，所述方法还包括：响应于升级安装包安装完成，电子设备优化编译第一数量的第一应用，得到对应的优化可执行odex文件，第一数量小于电子设备中应用程序的总数量。

在一些实施例中，电子设备的操作系统包括第一操作系统和第二操作系统；所述电子设备运行于所述第一操作系统，所述电子设备安装所述升级安装包，包括：从所述升级安装包中解析出的升级数据；在第一存储分区中，写入所述升级数据，所述第一存储分区包括所述第二操作系统在所述电子设备的存储器中占用的静态分区，以及虚拟动态分区；所述响应于所述升级安装包安装完成，所述电子设备优化编译第一数量的第一应用，包括：响应于所述升级数据已写入所述第一存储分区，基于所述第二操作系统，优化编译第一数量的第一应用。

在一些实施例中，第一数量是预设值。或者，第一数量是所述电子设备在第一时长内优化编译的应用程序的数量，所述第一时长是预先配置的。

在一些实施例中，第一应用是满足第一条件的应用程序。其中，第一条件包括以下一项或多项的组合：第一应用是电子设备的应用程序中活跃等级由高到低排列在前N位的应用程序，其中，N为正整数。活跃等级是根据应用运行记录及应用下载量评估出的应用的活跃程度；所述第一应用属于第一集合，第一集合是由提供指定类型服务的应用程序组成的集合。

第三方面，本申请实施例提供的一种电子设备，电子设备包括一个或多个处理器和存储器；所述处理器包括调制解调处理器，所述存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，所述一个或多个处理器，用于执行第一方面、第二方面及其可能的实施例中的方法。

第四方面，本申请实施例提供的一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行上述第一方面、第二方面及其可能的实施例中的方法。

第五方面，本申请提供一种计算机程序产品，当计算机程序产品在上述电子设备上运行时，使得电子设备执行上述第一方面、第二方面及其可能的实施例中的方法。

第六方面，本申请提供一种芯片系统，应用于电子设备，存储有计算机程序，在所述计算机程序被执行时，使得所述电子设备执行上述第一方面、第二方面及其可能的实施例中的方法。

可以理解地，上述各个方面所提供的电子设备、计算机存储介质以及计算机程序产品均应用于上文所提供的对应方法，因此，其所能达到的有益效果可参考上文所提供的对应方法中的有益效果，此处不再赘述。

附图说明

图1为相关技术中系统升级之后优化编译应用程序的场景示例图；

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

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

图4为本申请实施例提供的一种应用程序优化方法的步骤流程图之一；

图5为本申请实施例中系统升级之后优化编译应用程序的场景示例图之一；

图6为本申请实施例提供的一种应用程序优化方法的步骤流程图之二；

图7为本申请实施例中系统升级的界面示例图；

图8为本申请实施例提供的一种应用程序优化方法的步骤流程图之三；

图9为本申请实施例中系统升级之后优化编译应用程序的场景示例图之二；

图10为本申请实施例中系统升级之后优化编译应用程序的场景示例图之三；

图11为本申请实施例中系统升级之后优化编译应用程序的场景示例图之四。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“至少一个”是指一个或多个，“多个”是指两个或多于两个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

方便理解，下面先介绍本申请实施例所涉及的技术术语。

1、应用程序的源代码：由应用程序的开发人员编写的代码数据，用于支持实现应用程序的各类应用服务。电子设备的可执行（dex）文件中包含有对应的源代码。在电子设备下载应用程序的应用安装包（android application package，apk）时，包含源代码的dex文件，随应用程序的apk，被写入电子设备的数据（data）分区中。

在电子设备运行应用程序时，需要执行该应用程序的源代码，向用户提供相应的应用服务。当然，应用程序的源代码是电子设备不可直接识别的代码数据。目前，电子设备主要采用解释执行和机器码执行等方式，执行应用程序的源代码。

2、解释执行：电子设备运行应用程序的过程中，利用解释器将源代码解释为电子设备可识别的二进制代码，再执行该二进制代码。这样，采用解释执行的方式，运行应用程序的过程中，电子设备解释一句源代码，才能执行一句对应的二进制代码。

在源文件的代码量较多的场景下，该应用程序的源代码执行效率很低。

3、机器码执行：也可以称为编译执行，是指通过编译器，将源代码翻译成机器指令，如，翻译为电子设备可直接识别的二进制代码。基于编译出的二进制代码，生成对应的优化可运行（odex）文件。在运行应用程序时，电子设备可以直接执行应用程序对应的odex文件中的二进制代码，向用户提供相应的应用服务。

其中，上述将源代码编译为机器指令的方式可以包括：运行前（ahead of time，AOT）编译和动态（just-in-time，JIT）编译。

采用AOT编译的场景下，在执行应用程序之前，将应用程序的源代码编译成机器代码，并生成对应的odex文件。这样，可以使应用程序启动更快、运行性能更好。

采用JIT编译的场景下，在运行应用程序的过程中，解释一句源代码，记录一句对应的二进制代码。在所有的源代码都经过一次解释之后，可以得到包含所有源代码的二进制代码的odex文件。当然，在应用程序停止运行之后，电子设备会销毁该应用程序对应的odex文件。以上两种编译方法各具优缺点，本申请实施例中，主要以采用AOT编译的场景进行描述，后续实施例中也可以称为对应用程序进行优化编译。

示例性地，上述odex文件中可以包括应用程序所有的源代码的二进制代码。又示例性地，上述odex文件也可以包括源代码中热点函数所对应的二进制代码。其中，热点函数可以是在应用程序运行过程中，调用次数排列在指定名次之前的代码函数，通常应用程序的配置文件中可以记录该应用程序所对应的热点函数。

可以理解地，odex文件中的二进制代码是电子设备可直接识别的指令，电子设备运行应用程序过程中，执行odex文件中的二进制代码的速度更快。这样，应用程序在运行过程中，响应速度也越快。但是，应用程序的odex文件不是应用程序的apk中自带的文件，电子设备需要使用应用程序一段时间之后，才能生成对应的odex文件。

在生成应用程序的odex文件之前，由于电子设备中没有应用程序的odex文件，电子设备无法采用机器码执行。在此场景下，只能采用解释执行的方式，运行该应用程序。

可见，启用机器码执行的前提是生成了对应的odex文件。

另外。odex文件是基于操作系统提供的引导类路径（BootClassPath）编译出的文件。该odex文件中还记录了所依赖的BootClassPath，以及BootClassPath指示位置中存储的基础文件包（比如，jar包（java archive file））大小。这样，电子设备执行odex文件的过程中，可以按照BootClassPath，调用各种类型的jar包。

在操作系统的BootClassPath出现变化之后，odex文件会失效，导致电子设备不能继续启用机器码执行。通常电子设备进行操作系统升级之后，电子设备中的BootClassPath可能出现变化，比如，地址改变、BootClassPath指示的存储位置中的jar包大小变化。

示例性的，上述操作系统升级可以是基于空中下载技术的操作系统升级。

4、基于空中下载技术（over the air，OTA）的操作系统升级：是指通过移动通信的空中接口实现对电子设备的软件升级。该电子设备对应有用于发布操作系统的升级安装包的服务器，电子设备可以从服务器获取到最新的升级安装包，并利用升级安装包对电子设备进行升级。

在操作系统升级过程中，电子设备可能会更新BootClassPath。BootClassPath更新之后，电子设备中所有应用程序的odex文件都会失效。

在一些实施例中，电子设备运行应用程序之前，可以检验该应用程序是否对应有odex文件。在确定应用程序已对应有odex文件的情况下，检测对应的odex文件是否有效。比如，将odex文件中记录的BootClassPath，与操作系统中实际的BootClassPath进行比较，如果地址相同且对应的jar包大小相同，确定odex文件有效。如果地址不同或对应的jar包大小不相同，确定odex文件已失效。

在确定应用程序对应有odex文件且该odex文件有效的情况下，电子设备采用机器码执行的方式，运行该应用程序。

在确定应用程序没有对应的odex文件，或者该odex文件已失效的情况下，电子设备采用解释执行的方式，运行应用程序。

另外，如果应用程序还没有对应的odex文件（比如，电子设备刚安装该应用程序），或者，应用程序的odex文件已失效（比如，电子设备在OTA操作系统升级过程中，更新了BootClassPath），电子设备需要在空闲且电量充足的情况下，对应用程序进行编译，生成对应的odex文件。

示例性地，电子设备的系统原生规则中，用于判断是否空闲的条件可以是：显示屏灭屏且正在充电。用于判断电量是否充足的条件可以是：电子设备的电量不低于90%（第二值）。

然而，随着用户对电子设备的依赖程度提升，用户使用电子设备的频率越高和使用时长也越长。触发原生规则中编译应用程序的场景越来越难出现。其中，上述原生规则可以是操作系统自带的规则。

比如，用户经常在电子设备充电时，继续使用该电子设备。这样，在充电期间，电子设备未处于灭屏状态，不能触发针对应用程序的优化编译。再比如，在充电过程中，电量未达到90%，用户就停止充电，这样，即使电子设备灭屏且正在充电，由于电量未达到90%，同样也不能触发针对应用程序的优化编译。

示例性的场景，如图1所示，电子设备根据升级安装包对操作系统进行升级之后，通过设备重启的方式，使升级后的操作系统生效。其中，升级后的重启过程如下：电子设备重启上电。然后，挂载数据（data分区）。其中，data分区是存储应用程序apk的存储区域，在挂载data分区之后，可以扫描apk，并进行相应的优化处理。

如图1所示，在时段1内，电子设备可以对系统应用和第三方应用进行相应优化处理。其中，系统应用是指操作系统中自带的应用程序或服务，第三方应用是指通过第三方开发的应用程序。

示例性的，升级后的重启过程中，电子设备显示指示优化应用的界面，然后，分类地对电子设备中的应用程序进行不同的优化处理。比如，按照快速编译（speed-profile）模式处理系统应用：对系统应用中的可执行文件（dex）进行校验，然后，提前翻译该系统应用的配置文件中列出的热点函数方法。

再比如，按照检验（verify）模式处理第三方应用：仅检验第三方应用的dex文件。

在开机后，在时段2内，用户使用电子设备。时段2内，很难同时满足原生规则中指示的触发编译的场景条件，比如，上述原生规则中触发编译的场景条件可以是同时满足“处于灭屏状态”、“处于正在充电状态”且“剩余电量不低于90%”。

这样，不仅增加升级后首次重启的时长，而且用户常使用的第三方应用程序在时段2之后，才有机会生成相应的odex文件，导致时段2内用户使用第三方应用程序时，第三方应用程序运行效率低。

经过实际统计，电子设备进行OTA操作系统升级之后，大约需要2~3天的时间，电子设备中的应用程序的odex文件才能够重新生成。然而，在这2~3天的时间内，电子设备只能采用解释执行的方式，或，JIT编译的方式，运行应用程序。这样，应用程序在整个运行周期内，代码执行效率都很低，对应的响应速度也较慢，十分影响电子设备的人机交互效率。

为了改善上述问题，本申请实施例提供了一种应用程序优化方法，该方法可以应用于电子设备。其中，电子设备可以在升级重启之前，对部分应用程序进行编译，生成部分应用程序的odex文件，并保存。这样，OTA操作系统升级完成之后，电子设备依然可以采用机器码执行的方式，运行该部分应用程序。

在一些实施例中，在升级重启前，所编译的应用程序可以是电子设备中的热点应用。可以理解的，上述热点应用可以是电子设备中活跃度排名靠前的应用程序。这样，在所有应用程序的odex文件生成之前，可以满足用户对电子设备的使用需求。

示例性的，本申请实施例中的电子设备可以是便携式计算机（如手机）、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机（ultra-mobile personalcomputer，UMPC）、上网本，以及蜂窝电话、个人数字助理（personal digital assistant，PDA）、媒体播放器等，本申请实施例对该电子设备的具体形态不作特殊限制。

请参考图2，图2示出了电子设备的一种可能的硬件结构示意图：

如图2所示，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。

其中，上述传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器和骨传导传感器等传感器。

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

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

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

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

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路（inter-integrated circuit，I2C）接口，集成电路内置音频（inter-integrated circuitsound，I2S）接口，脉冲编码调制（pulse code modulation，PCM）接口，通用异步收发传输器（universal asynchronous receiver/transmitter，UART）接口，移动产业处理器接口（mobile industry processor interface，MIPI），通用输入输出（general-purposeinput/output，GPIO）接口，用户标识模块（subscriber identity module，SIM）接口，和/或通用串行总线（universal serial bus，USB）接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

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

显示屏194用于显示图像，视频等。该显示屏194包括显示面板。显示面板可以采用液晶显示屏（liquid crystal display，LCD），有机发光二极管（organic light-emittingdiode，OLED），有源矩阵有机发光二极体或主动矩阵有机发光二极体（active-matrixorganic light emitting diode，AMOLED），柔性发光二极管（flex light-emittingdiode，FLED），Miniled，MicroLed，Micro-oLed，量子点发光二极管（quantum dot lightemitting diodes，QLED）等。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

ISP 用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件（图像传感器）上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件（charge coupled device，CCD）或互补金属氧化物半导体（complementary metal-oxide-semiconductor，CMOS）光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括N个摄像头193，N为大于1的正整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组（moving picture experts group，MPEG）1，MPEG2，MPEG3，MPEG4等。

NPU为神经网络（neural-network，NN）计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。

上述电子设备的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备的软件结构。

图3是本申请实施例的电子设备的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，电子设备的操作系统可以分为多层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(android runtime，ART)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图3所示，应用程序层中可以安装线上升级客户端（online update client，OUC）、聊天应用、支付应用、音乐应用、视频应用、游戏应用、浏览器等。当然，应用程序层中还包括图3中未示出的应用程序，比如，通话，备忘录，联系人，相机，图库，日历，地图，蓝牙等应用程序。

其中，OUC用于从服务升级安装包的服务器处，获取最新的升级安装包。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图3所示，应用程序框架层可以包括升级引擎（update engine）、编译优化服务模块（dexopt service）、OTA升级管理服务（ota preopt service）等。当然，也可以包括图3中未示出的服务及模块，比如，窗口管理器、资源管理器、视图系统等。

示例性地，上述update engine，用于驱动执行操作系统的升级。

示例性地，上述编译优化服务模块，用于确定需要进行编译的应用程序，以及确定应用程序之间的编译顺序。比如，可以确定出热点应用，作为需要编译的应用程序。

示例性地，上述OTA升级管理服务，用于管理操作系统升级的相关事项。以采用虚拟A/B操作系统的电子设备为例，可以确定被升级的目标操作系统。比如，电子设备基于A操作系统运行，被升级的目标操作系统为B操作系统。

如图3所示，系统库可以包括多个功能模块。例如：图层整合器(SurfaceFlinger)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。SurfaceFlinger用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如: MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。上述Android Runtime的虚拟机中运行有编码器（dalvik excutable file tooptimized art file，dex2oat）和优化编译（dexopt）模块。其中，dexopt，可用于将包含源代码的dex文件转化为包含二进制代码的odex文件。比如，dexopt可以调用dex2oat对应用程序的源代码进行翻译，根据dex2oat的翻译结果生成该应用程序对应的odex文件。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

内核层是硬件和软件之间的层。内核层至少包含摄像头驱动，音频驱动，传感器驱动等，本申请实施例对此不做任何限制。

下面结合附图介绍本申请实施例提供的一种应用程序优化方法的实现细节：

在一些实施例中，开发人员可以将编写的升级安装包存储于服务器，通过服务器发布该升级安装包。其中，该升级安装包是用于将操作系统升级至最新版本的数据包。在一些实施例中，升级安装包可以是全量升级包，也可以是增量升级包，本申请实施例不作具体限定。

在本申请实施例中，上述升级安装包除了用于更新操作系统的数据之外，还包括最后安装（PostInstall）文件。其中，上述PostInstall文件可以指示在安装和校验该升级安装包之后，所需执行的流程。上述PostInstall文件可以是update engine按照升级安装包执行操作系统升级的过程中，最后执行的文件。比如，在安装和校验升级安装包之后，执行PostInstall文件，实现编译部分应用程序。再比如，电子设备启用虚拟A/B操作系统的情况下，在安装和校验升级安装包之后，执行PostInstall文件，实现在目标操作系统编译部分应用程序，并指示的电子设备激活启用目标操作系统，其中，目标操作系统是A/B操作系统中被升级的操作系统。

在一些实施例中，电子设备获取到升级安装包，可以基于该升级安装包，升级电子设备的操作系统。作为一种实现方式，上述获取升级安装包和安装该升级安装包的过程可参考图4中的S101~S104：

S101，电子设备中的OUC可以从服务器中搜索并下载升级安装包。

在一种可行的实现方案中，电子设备可以通过OUC定期向服务器发起搜包请求，搜包请求包含电子设备当前运行的操作系统的版本号（例如版本1.1）。服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的升级安装包（例如版本1.2）。当存在更新版本的升级安装包时，服务器向电子设备反馈升级安装包（例如，版本1.2的全量升级安装包）的下载地址。电子设备根据升级安装包的下载地址进行下载。

在另一种可行的实现方案中，服务器也可在得到新版本的升级安装包之后，主动向电子设备推送。

在一些实施例中，电子设备得到升级安装包之后，具备升级操作系统的能力。在一些实施例中，电子设备可以在空闲的情况下，自动基于升级安装包进行升级。在另一些实施例中，电子设备可以响应于用户的升级指示，基于升级安装包进行升级。

在本申请实施例中，如图5所示，升级电子设备的操作系统可以包括两个阶段。其中，第一个阶段下，电子设备可以安装和校验升级安装包。第二个阶段，电子设备可以按照升级安装包中的PostInstall文件，针对第一数量的应用程序进行AOT编译，生成对应的odex文件。

作为一种实现方式，OUC可以将升级安装包下载并保存到用户数据分区（Userdata）。之后，OUC指示启动update engine，由update engine执行升级操作系统的第一阶段，具体参见S102~S104：

S102，OUC指示update engine启动针对操作系统的升级。

作为一种实现方式，OUC可以通过向update engine发送升级指令的方式，设置update engine的启动属性，将其对应的启动属性设置为true。另外，电子设备中常驻操作系统后台的服务servicemanger会监控update engine的启动属性。当servicemanger检测到update engine的启动属性为true时，servicemanger启动update engine。

之后，OUC通过binder通信获取update engine的状态。OUC确认update engine已成功启动之后，OUC向update engine传递升级参数（例如，上述升级参数可以指示当前的升级操作是文件更新操作还是文件落盘操作），触发update engine进入升级流程。

S103，update engine根据升级安装包进行安装。

在一些实施例中，update engine可以是校验升级安装包中的META-INF（也即，数字签名）是否合法，确认升级安装包是否为合法的升级包。具体实现细节，可参考相关技术，在此不再赘述。

在确定升级安装包通过检验之后，update engine可以解析升级安装包，得到用于更新操作系统的升级数据。然后，update engine可以将升级数据写入操作系统在存储器中对应的存储分区（静态分区或动态分区等）。

以升级启用虚拟A/B操作系统的电子设备，电子设备运行于A操作系统为例，上述S103的实现方式如下：

S103-1，update engine从用户数据分区（Userdata）读取已保存的升级安装包，将升级安装包中针对静态分区的升级数据，写入静态分区（B），以升级静态分区。

例如，系统升级包中包含版本1.2的静态分区的数据，也即，针对静态分区的升级数据。update engine解析升级安装包之后，将升级安装包中携带的静态分区的数据（也即，版本1.2的静态分区数据）覆写到静态分区（B）中。

S103-2，update engine在用户数据分区（Userdata）创建虚拟动态分区，并将升级数据中针对动态分区的数据写入该虚拟动态分区。

例如，升级安装包中包含版本1.2的动态分区的数据，在从升级安装包中解析出版本1.2的动态分区的数据之后，在虚拟动态分区中写入版本1.2的动态分区（Super）的数据。

S104，update engine进行升级后的校验。

在一些实施例中，update engine在安装升级数据包之后，校验升级后的B操作系统（静态分区B和虚拟动态分区中的数据）是否有效。在有效的情况下，确定已完成安装和校验，执行升级安装包中的PostInstall文件。

这样，进入操作系统升级的第二阶段。在第二阶段下，电子设备可以优化编译第一数量的应用程序，得到对应的odex文件。示例性地，电子设备可以响应于安装完升级安装包，针对应用程序进行优化编译。如，执行完前述S101~S104，响应于通过升级之后的校验，进行针对应用程序的优化编译。再比如，执行完S101~S103，响应于升级数据已写入所述第一存储分区（如，写入静态分区（B）和虚拟动态分区），可以进行针对应用程序的优化编译。

作为一种实现方式，进行优化编译的过程可参考图4中的S105~S106：

S105，update engine指示ART编译第一数量的应用程序。

在一些实施例中，PostInstall文件中可以配置有第一数量。这样，update engine可以指示ART通过编译器，对第一数量的应用程序进行编译。比如，PostInstall文件中可以配置第一数量为5，update engine执行PostInstall文件可以指示ART通过编译器，对电子设备中5个应用程序进行编译。示例性地，上述第一数量可以少于电子设备中应用程序的总数量。

在电子设备应用了虚拟A/B操作系统的情况下，可以通过目标操作系统的ART，对应用程序进行优化编译。这样，编译得到的odex文件是基于目标操作系统的BootClassPath生成的，经过上述优化编译，待电子设备从运行原操作系统切换至运行目标操作系统之后，被编译的应用程序可以采用机器码执行的方式运行。

可以理解的，电子设备运行于A操作系统（原操作系统，或第一操作系统）的情况下，升级B操作系统（目标操作系统，或称为第二操作系统），只更新B操作系统所对应的存储分区（如称为第一存储分区）中的数据，比如，第一存储分区包括B操作系统的静态分区，以及，为B操作系统创建的虚拟动态分区等。

显然，上述更新不会影响A操作系统对应的系统数据。这样，在电子设备启用B操作系统之前，A操作系统中的BootClassPath不变，升级前基于A操作系统，编译出的odex文件依然有效，电子设备在运行A操作系统期间，可以按照机器码执行的方式，运行应用程序。

B操作系统的第一存储分区中的数据被更新之后，B操作系统中的BootClassPath改变，为了确保切换启用B操作系统之后，B操作系统中第一数量的应用程序可以采用机器码执行，可以在切换B操作系统之前，在B操作系统中编译第一数量的应用程序的odex文件，并给在B操作系统中编译出的odex文件赋予目标标识，该目标标识用于与该应用程序的原odex文件（基于A操作系统编译出的odex文件）进行区分，避免电子设备运行于A操作系统期间，误加载基于B操作系统编译的odex文件，导致机器码执行失败。

比如，目标操作系统是B操作系统，B操作系统的ART中编译得到的odex文件的文件名可以携带B操作系统的标识，如，文件名称的后缀包括“b”，作为对应的目标标识。另外，以上仅为目标标识的一种举例，不作为对目标标识的限定。

在另一些实施例中，PostInstall文件中可以配置有第一时长，这样，updateengine可以指示ART通过编译器，在第一时长内，依次对应用程序进行编译。可以理解地，第一时长内实际编译的应用程序数量为第一数量。比如，PostInstall文件中可以配置第一时长为3分钟，update engine执行PostInstall文件可以指示ART通过编译器，依次对应用程序进行编译，在编译时长达到3分钟之后，停止编译。在此举例中，如果在3分钟之内编译了5个应用程序，对应的第一数量为5。

在一些实施例中，ART在编译第一数量的应用程序的过程中，可以逐一对应用程序进行编译。编译过程中，可以获取应用程序的配置文件中记录的热点函数，然后，将热点函数的源代码翻译为二进制代码，并生成对应的odex文件。可以理解地，热点函数是根据源代码中各个函数被调用的活跃程度（或调用频率）相关，与用户使用应用程序的习惯和应用程序的运行规则相关，在电子设备使用应用程序的过程中，还可以根据函数的活跃程度，更新配置文件中的热点函数。

在一些实施例中，被编译的应用程序可以是电子设备中满足第一条件的第一应用。

其中，上述第一条件可以包括以下一项或多项的组合：

（1）第一应用是电子设备的应用程序中活跃等级由高到低排列在前N位的应用程序，其中，N为正整数。比如，N为5，第一应用可以是电子设备中活跃等级排列在top5的应用程序。活跃等级是根据应用运行记录（前台运行、后台运行等记录）及应用下载量评估出的应用的活跃程度。

可以理解地，可以根据用户使用习惯（由应用运行记录指示）、应用下载量等信息，评估电子设备中每一个应用程序的活跃等级。示例性的，可以获取用户对各个应用程序的应用运行记录，评估指示使用习惯的分值1。然后，将应用下载量量化为分值2。结合用户使用习惯和应用下载量所对应的权重，基于分值1和分值2，拟合出活跃分数。然后，按照活跃分数划分活跃等级。活跃分数越高，对应的活跃等级越高，活跃分数越低，对应的活跃等级越低。按照活跃等级由高到低进行排列，排列在前的应用程序相对于排列在后的应用程序热度更高。

（2）第一应用属于第一集合，第一集合是由提供指定类型服务的应用程序组成的集合。

示例性的，上述第一集合（又可称为应用集合）包括多个应用程序，且各个应用程序均是预选类型的应用。预选类型的应用是可以提供指定应用服务的应用。另外，可以存在一种预选类型，也可以存在多种预选类型，本申请实施例对此不做具体限定。

比如，预选类型的应用是提供沟通类服务的应用，电子设备中安装有聊天应用、支付应用、交通卡应用、短信息应用、视频应用、工作沟通应用等。在此场景下，应用集合（第一集合）可以是由聊天应用、短信息应用、工作沟通应用等应用组成的集合。

示例性地，ART编译第一数量的应用程序的过程可以是：随机从应用集合中选出第一数量的待编译应用，然后，依次对待编译应用程序进行优化编译。再示例性地，ART编译第一数量的应用程序的过程可以是：从应用集合随机抽取一个应用程序进行优化编译，完成针对一个应用程序的优化编译之后，再从应用集合中随机再抽取一个未优化编译的应用程序，并继续对该应用程序进行优化编译，直至满足截止条件。其中，截止条件可以是ART编译应用程序的总时长达到第一时长，或者，截止条件还可以是ART编译应用程序的总数量达到第一数量。

又示例性地，ART编译第一数量的应用程序的过程还可以是：从应用集合中选出第一数量的待编译应用，然后，依次针对待编译应用进行优化编译。其中，所选出的待编译应用是电子设备的应用程序中活跃等级由高到低排列在前N位的应用程序。

再示例性地， ART编译第一数量的应用程序的过程可以是：从应用集合的应用程序中，选择活跃等级最高的应用程序进行优化编译。完成针对一个应用程序的优化编译之后，再从应用集合的未优化编译的应用程序中，选择活跃等级最高的应用程序，并继续对该应用程序进行优化编译，直至满足截止条件。其中，截止条件可以是ART编译应用程序的总时长达到第一时长，或者，截止条件还可以是ART编译应用程序的总数量达到第一数量。

示例性的，ART编译第一数量的应用程序的过程还可以是：电子设备中的应用程序按照活跃等级进行排序，在活跃程度排列在前N位的应用程序中，选出第一数量的应用程序作为待编译应用，并进行优化编译。其中，N为正整数。又示例性的，ART编译第一数量的应用程序的过程还可以是：电子设备中的应用程序按照活跃等级进行排序，选择排列在第一位的应用程序进行优化编译，完成针对一个应用程序的优化编译之后。再按照活跃等级，由高到低，重新排列未优化编译的应用程序，选择活跃等级排列在第一位的应用程序继续进行优化编译，重复上述过程，直至满足截止条件。其中，截止条件可以是ART优化编译应用程序的总时长达到第一时长，或者，截止条件是ART优化编译应用程序的总个数为第一数量。

S106，ART根据PostInstall文件中的升级编译脚本文件，对应用程序进行优化编译。

在一些实施例中，在运行升级编译脚本文件（otapreopt_script.sh）之后，可以在目标操作系统的apexd中，激活与ART中的相关的系统组件，比如，otachoor-bootrap、com.android.runtime、com.android.art、com.android.sdkext等。

在激活相应的系统组件之后，ART基于otapreopt_script.sh可以实现针对应用程序的优化编译。

作为一种实现方式，如图6所示，实现优化编译应用程序的过程如下：

S1，升级编译脚本模块指示编译优化服务模块执行编译准备任务。

其中，升级编译脚本模块可以是ART运行otapreopt_script.sh之后形成的、对系统资源存在占用的软件模块。该升级编译脚本模块可以按照otapreopt_script.sh中的程序规则运行，实现otapreopt_script.sh所指示的功能。比如，指示编译优化服务模块进行初始化、从编译优化服务模块获取指示编译器执行编译优化的dexopt命令等功能。

在一些实施例中，升级编译脚本模块可以向编译优化服务模块发送指示进行初始化的命令提示符（command，CMD）。之后，升级编译脚本模块可以调用prepare（）函数，使流程进入S2。

S2，编译优化服务模块确定需要进行编译优化的应用程序。

可以理解地，上述编译准备任务可以包括确定需要进行编译优化的应用程序。上述需要进行编译优化的应用程序可称为待编译应用。

在一些实施例中，升级编译脚本模块可以通过prepare（）函数，指示编译优化服务模块确定需要进行编译优化的应用程序。编译优化服务模块响应于升级编译脚本模块的指示，确定出待编译应用以及待编译应用之间的编译先后顺序。

示例性地，可以是获取活跃等级排列在前N位的应用程序作为待编译应用。然后，按照活跃等级，确定待编译应用之间的进行优化编译的先后顺序。其中，活跃等级越高，编译顺序越靠前。活跃等级越地，编译顺序越靠后。

又示例性的，从应用集合中确定出待编译应用，实现过程参考前述实施例，在此暂不赘述。然后，随机排列待编译应用之间的优化编译顺序，或者按照活跃等级，排列待编译应用之间的优化编译顺序。

S3，编译优化服务模块通知升级编译脚本模块，已完成编译准备任务。

在一些实施例中，可以通过prepare（）函数的结果回调的方式，实现通知升级编译脚本模块，目前已完成编译准备任务。

S4，升级编译脚本模块向编译优化服务模块发送请求信息1。

其中，上述请求信息1，用于请求获取dexopt命令，该dexopt命令可以指示编译器执行编译优化。示例性的，该dexopt命令中包括需要被编译的一个应用程序的信息，用于指示dexopt调用编译器对该应用程序进行优化编译。

在一些实施例中，升级编译脚本模块可以通过调用next（）函数，实现向编译优化服务模块发送请求信息1。

S5，响应于请求信息1，编译优化服务模块向升级编译脚本模块反馈指示编译目标应用程序的目标dexopt命令。

在一些实施例中，升级编译脚本模块向编译优化服务模块发送请求信息1时，将实际还未编译的待编译应用中，排列在第一位的应用程序，作为目标应用程序。然后，编译优化服务模块将指示编译该目标应用程序的目标dexopt命令，发送给升级编译脚本模块。触发升级编译脚本模块启动针对该目标应用程序的优化编译，也即，执行S6~S13。

示例性的，在发送请求信息1的次数未达到第一数量之前，完成第i-1个目标应用程序的优化编译（也即，基于第i-1个目标应用程序，执行S6~S13）之后，升级编译脚本模块可以向编译优化服务模块发送第i个请求信息1，其中，i是大于1的正整数。编译优化服务模块将实际还未编译的待编译应用中，排列在第一位的应用程序，作为第i个目标应用程序。

在其他实施例中，完成第i-1个目标应用程序的优化编译（也即，基于第i-1个目标应用程序，执行S6~S13）之后，如果当前系统时间距离发送第一个请求信息1的时间间隔不超过第一时长，再次向编译优化服务模块发送请求信息1，指示对第i个目标应用程序进行优化编译。

可以理解的，确定出的前i个目标应用程序已完成编译，第i个目标应用程序是在去除前i个目标应用程序之后，待编译应用程序中排列于第一位的应用程序。

之后，升级编译脚本模块基于第i个目标应用程序，执行S6~S13。当然，在i依然小于第一数量时，升级编译脚本模块可以向编译优化服务模块发送第i+1个请求信息1，重复上述过程，实现对第i+1个目标应用程序进行编译。

S6，升级编译脚本模块基于目标dexopt命令，指示目录改变模块（otapreopt_chroot）运行。

在一些实施例中，升级编译脚本模块可以基于目标dexopt命令，调用otapreopt_chroot（）函数，实现启用otapreopt_chroot。

S7，otapreopt_chroot执行目标dexopt命令。

在一些实施例中，执行目标dexopt命令的过程可以是otapreopt_chroot通过exec（）函数，执行目标dexopt命令。

S8,otapreopt_chroot可以调用第一工具类（otapreopt_utils）。

在一些实施例中，可以是otapreopt_chroot在执行目标dexopt命令的过程中，基于目标dexopt命令中指示的目标应用程序，调用otapreopt_utils。

S9，otapreopt_utils指示第二工具类（otapreopt）确定目标应用程序对应的编译准备信息。

在一些实施例中，otapreopt_utils可以是响应于otapreopt_chroot的调用，基于目标应用程序，通过fork（）函数，实现指示otapreopt确定目标应用程序对应编译准备信息。示例性的，上述编译准备信息包括目标应用程序的应用标识（用于确定执行优化编译的对象）、odex文件的存储位置等信息。其中，上述otapreopt_utils和otapreopt均为oat升级后可启用的编译相关的工具类，上述otapreopt_utils可以调用otapreopt，otapreopt可以获取到与编译相关的准备信息。

S10，otapreopt确定目标应用程序对应编译准备信息。

在一些实施例中，otapreopt可以调用runpreopt（）函数，初始化otapreopt，获取目标应用程序的应用标识。然后，调用open_oat _out_file（）函数，触发调用create_oat_out_path（）函数。在create_oat_out_path（）函数被调用的情况下，可以触发调用calculate_oat_file_path（）函数，实现确定目标存储位置，用于存储后续针对目标应用程序生成的odex文件。

S11，otapreopt从OTA升级管理服务获取目标操作系统的标识。

在一些实施例中，otapreopt可以调用gettargetslot（）函数，从OTA升级管理服务获取目标操作系统的标识。其中，目标操作系统可以是已进行数据升级的操作系统。

以启用虚拟A/B操作系统的电子设备为例，电子设备运行于A操作系统的情况下，otapreopt可以调用gettargetslot（）函数，可以从OTA升级管理服务获取到B操作系统（目标操作系统）的标识。

S12，otapreopt向dexopt发送编译准备信息和目标操作系统的标识。

在一些实施例中，otapreopt可以通过调用dexopt（）函数，向dexopt传递编译准备信息和目标操作系统的标识。

S13，dexopt调用编译器，在目标操作系统上对目标应用程序进行优化编译，生成对应的目标odex文件，并将目标odex文件存储于目标存储位置。

在一些实施例中，目标odex文件的文件名称中可以携带有目标操作系统的标识。比如，目标操作系统是B操作系统，这样，目标odex文件的文件名称中包括“b”。

以启用虚拟A/B操作系统的电子设备为例，如图7所示，在进行操作系统升级期间，电子设备可以显示升级界面701，其中，升级界面701是OUC对应的应用界面。另外，在显示升级界面701中显示有升级进度信息702。

在执行完S103之后，升级界面701的升级进度信息702指示第一比例。其中，第一比例小于100%，比如，第一比例为75%。另外，在执行上述S1~S13的过程中，每完成针对一个目标应用程序的编译，指示OUC更新一下升级进度信息702。

示例性的场景，采用安装升级安装包之后，限制编译第一数量的应用程序的方案。这样，升级进度信息702变为第一比例的时间点，电子设备中不含在目标操作系统上编译出的odex文件。在升级界面701中的升级进度信息702由第一比例达到100%期间，电子设备中在目标操作系统上编译出的odex文件，逐渐增加，直到达到第一数量。之后，流程进入S107。

又示例性的场景，采用安装升级安装包之后，限制在第一时长内编译应用程序的方案。这样，升级进度信息702变为第一比例的时间点，电子设备中还不含在目标操作系统上编译出的odex文件。在升级界面701中的升级进度信息702由第一比例达到100%期间，电子设备中在目标操作系统上编译出的odex文件，逐渐增加，直至升级进度信息702达到100%，其中，升级进度信息702由第一比例至变为100%之间的时间间隔为第一时长。在一些实施例中，电子设备完成第一数量的应用程序优化编译，或者，优化编译应用程序的时间达到第一时长之后，电子设备可以触发升级后的重启。

作为一种实现方式，触发重启的过程，可参考图4中的S107和S108。

S107，在编译完第一数量的应用程序之后，update engine配置电子设备基于目标操作系统重启。

在一些实施例中，update engine可以激活目标操作系统对应的slot。将主引导记录（Master Boot Record，MBR）的启动顺序配置为从目标操作系统启动。示例性地，响应于电子设备完成优化编译第一数量的第一应用，将启动顺序标识配置为从目标操作系统启动。

可以理解的，在采用虚拟A/B升级方式的安卓系统中，由于只有静态分区采用A/B方案，而动态分区采用升级时构造虚拟动态分区的方案。为了静态分区与动态分区的匹配，在super头信息，又称为动态分区（Super）的头部的元数据（/supermetadata）中，包含对应静态分区（A）的Slot0以及静态分区（B）的Slot1。Slot0以及Slot1均用于保存Super分区的分区表。

例如，激活Slot0，指示从Slot0中加载对应的super分区的分区表。激活Slot1，指示从Slot1中加载对应的super分区的分区表。同时段内，二者中仅一个被激活。在设备启动时，按照MBR的启动顺序，加载目标操作系统的静态分区，然后，选择从被激活的slot中获取Super分区的分区信息，实现加载Super分区。

在目标操作系统对应的slot被激活之后，流程进入S108。

S108，update engine指示OUC触发设备重启。

在一些实施例中，退出当前的操作系统，切断设备电源，再次开启设备电源。

在电子设备重新上电之后，依次加载基础分区（Common）、静态分区（B）。

在一些实施例中，目标操作系统为B操作系统时，在重启过程中，按照MBR的启动顺序，电子设备由从静态分区（A）启动变更为从静态分区（B）启动。

例如，在电子设备上电后，电子设备读取到MBR的启动顺序标识为B，也即，指示启动顺序已配置为从B操作系统启动。这样，电子设备首先加载基础分区（Common）。在加载基础分区（Common）的过程中，电子设备读取基础分区（Common）中MBR的启动顺序标识；在读取到启动顺序标记为（B），电子设备可以加载静态分区（B），从而从静态分区（B）启动。然后，根据slot1中的分区信息，加载动态分区（Super）以及用户数据分区（Userdata）的虚拟动态分区。

在一些实施例中，在电子设备重启之后，如图8所示，上述方法还可以包括S201~S206。

S201，ART将目标odex文件置为生效状态。

可以理解地，目标odex文件是在未启用目标操作系统之前，基于目标操作系统编译出的odex文件。该目标odex文件的文件名称中携带有目标操作系统的标识，比如，目标操作系统为B操作系统时，文件名称中包括“b”。

在一些实施例中，上述S201可以是：利用目标odex文件覆盖目标应用程序对应的原odex文件，使目标odex文件生效。例如，去除目标odex文件所携带的目标操作系统的标识。可以理解的，在去除目标操作系统的标识之后，目标odex文件的文件名与目标应用程序的原odex文件的文件名相同，去除目标操作系统的标识的目标odex文件作为新文件，可直接覆盖原odex文件。

这样，在启用目标操作系统期间，电子设备可以基于生效的目标odex文件，运行对应的应用程序。

S202，ART向OUC发送通知1，指示目标odex文件均已生效。

S203，OUC指示update engine启动落盘（merge）。

S204，update engine触发merge流程。

在一些实施例中，重启之后，新系统生效，启动merge流程：

（1）电子设备成功启动，进入用户交互界面。

（2）电子设备在后台将虚拟动态分区的数据落盘到动态分区（Super）。

在本申请说明书的描述中，落盘操作指的是，在操作系统升级过程中，将用户数据分区（Userdata）上虚拟动态分区中保存的动态分区（Super）升级文件（COW文件）写入到动态分区（Super）中。

在一些示例中，电子设备在启动成功后进行开机广播，开机广播后开启updateengine对应的进程。update engine对应的进程读取基础分区（Common）的元数据（/metadata）中的落盘状态信息，如果落盘状态信息为“已落盘（merged）”，则设备进入正常运行模式。

如果落盘状态信息为“未落盘（wait for merge）”，update engine对应的进程将用户数据分区（Userdata）中的COW文件落盘到动态分区（Super）中。

在一些实施例中，update engine对应的进程将用户数据分区（Userdata）中的COW文件中的升级数据写入到动态分区（Super）中的对应地址上，使得动态分区（Super）中的全部数据均为升级后的新版本的数据。

在此之后update engine对应的进程删除用户数据分区（Userdata）中的COW文件，将存储空间归还给用户数据分区（Userdata）；并且，将基础分区（Common）的元数据（/metadata）中的落盘状态信息由“未落盘（wait for merge）”改为“已落盘（merged）”。

S205，update engine将B系统的静态分区复制到A系统的静态分区中。

在一些实施例中，上述S204仅为一种更新静态分区（A）的方式示例，本申请实施例中，还可以存在其他可能的实现方式，例如，update engine可以利用系统升级包，更新静态分区（A）中的数据，本申请实施例对此不作具体限定。

S206，update engine指示OUC已完成升级。

在一些实施例中，在升级重启之前，优化编译了一部分应用程序。在升级重启之后，还可以优化编译第二数量的应用程序。

其中，第二数量可以是预先配置的数值，指示在操作系统升级的首次重启之后，在满足第一编译条件（如称为第二条件）的情况下，可编译的应用程序数量。其中，第二数量大于第一数量，比如，第一数量为5时，第二数量为15。

示例性的，上述第一编译条件是触发编译应用程序的场景条件。上述第一编译条件与原生规则中的触发编译的场景条件（如称为第二编译条件，或第三条件）不同。上述第一编译条件的触发概率高于第二编译条件的触发概率。另外，电子设备满足第二编译条件的情况下，也满足第一编译条件。当然，满足第一编译条件的情况下，可能不满足第二编译条件。

比如，原生规则中第二编译条件为：电子设备处于灭屏状态、正在充电且电量超过90%。第一编译条件包括以下任意一项：

1）电子设备处于灭屏状态且电量超过40%（第一值）。

2）电子设备处于灭屏状态且正在充电。

显然，相比于原生规则中触发编译的场景条件，上述第一编译条件触发的概率越高。这样，重启之后，电子设备可以更快地完成对第二数量的应用程序的优化编译。

在一些实施例中，电子设备在满足第一编译条件期间，确定出需要被编译的应用程序，也可称为待编译应用，或，第二应用。

示例性的，上述待编译应用可以包括具有有效的odex文件的应用程序。比如，在上述第二阶段中已编译过的应用程序，且包含未编译的热点函数的情况下，也可以被确定为待编译应用（第二应用）。

又示例性的，上述待编译应用也可以包括odex已失效的应用程序，比如，在系统升上述第二阶段中未编译过的应用程序，对此不做限定。

在一些实施例中，电子设备可以继续确定每一个待编译应用（第二应用）的活跃等级，然后，按照活跃等级由高到低，对待编译应用进行排序。其中，活跃等级越高的待编译应用，排列在越靠前的位置。然后，按照排列顺序，依次对待编译应用进行优化编译，得到对应的odex文件。

在一些实施例中，电子设备不再满足第一编译条件的情况下，可以停止继续编译应用程序。

在满足第一编译条件期间，编译的应用程序数量还未达到第二数量的场景下，在确定不满足第一编译条件且停止优化编译之后，如果再次检测到满足第一编译条件，继续对升级重启后还未编译的待编译应用进行优化编译，待编译应用的编译顺序依然与待编译应用的活跃程度的高低顺序一致。

或者，如果再次检测到满足第一编译条件，重新确定待编译应用。其中，待编译应用可以包括具有有效odex文件，但新增未编译的热点函数的应用程序，也可以包括odex文件已失效的应用程序。然后，按照活跃等级，对待编译应用进行排序。这样，在满足第一编译条件期间，按照排序，依次对待编译应用进行优化编译。

在满足第一编译条件期间，如果升级重启后编译的应用程序数量达到第二数量，停止继续进行优化编译。之后，电子设备可以在满足第二编译条件，继续进行优化编译。在仅满足第一编译条件，但不满足第二编译条件的情况下，不进行优化编译。

示例性的场景，如图9所示，在系统升级的第二阶段内，电子设备可以完成第一数量的应用程序的优化编译，得到对应的odex文件。在系统升级后，首次重启的情况下，在第一时段内，电子设备满足第一编译条件，在第一时段之前，电子设备不满足第一编译条件。电子设备可以在第一时段内完成第二数量的应用程序的优化编译。

如图9所示的场景中，第二时段之前，电子设备均不满足第二编译条件，第二时段内，电子设备满足第二编译条件。在完成第二数量的应用程序的优化编译之后，在第二时段内，电子设备可以针对应用程序进行优化编译。

显然，第一时段早于第二时段。相关技术中，在第二时段之前，都未针对应用程序进行优化编译，这样，电子设备在第二时段之前，都无法采用机器码执行的方式，运行应用程序。

在本申请实施例中，在升级重启后，存在第一数量的应用程序具有有效的odex文件，也即，用户指示启用具有有效odex文件的应用程序时，已可以采用机器码执行的方式，运行该应用程序。在第一时段之后，电子设备中会新增更多可采用机器码执行的应用程序。

另外，在第一时段之后，具有有效odex文件的应用程序，已经能覆盖用户大部分的使用需求。之后，在第二时段内，还可以继续编译应用程序。这样，可以逐步完成针对电子设备中所有应用程序的编译。

示例性的场景，如图10所示，在系统升级的第二阶段内，电子设备可以完成第一数量的应用程序的优化编译，得到对应的odex文件。在系统升级后，首次重启的情况下，在第三时段内，电子设备满足第一编译条件，在第三时段之前，不满足第一编译条件。在第四时段内，电子设备也满足第一编译条件。在第三时段和第四时段之间的第五时段，不满第一编译条件。电子设备在第三时段内完成第三数量的应用程序的优化编译，其中，第三数量小于第二数量。电子设备在第四时段内完成第四数量的应用程序的优化编译，其中，第四数量小于第二数量，且第三数量与第四数量之和等于第二数量。在第六时段之前均不满足第二编译条件，在第六时段内，电子设备满足第二编译条件。电子设备可以在第六时段内针对应用程序进行优化编译。

示例性的场景，如图11所示，在系统升级的第二阶段内，电子设备可以完成第一数量的应用程序的优化编译，得到对应的odex文件。在系统升级后，首次重启的情况下，在第七时段内，电子设备满足第一编译条件。第七时段之后的第八时段，不满足第一编译条件。电子设备在第七时段内完成第五数量的应用程序的优化编译，其中，第五数量小于第二数量。之后，电子设备响应用户操作重启，重启之后，在第九时段内，确定满足第一编译条件，但不满足第二编译条件时，不进行优化编译。在第十时段内，电子设备满足第二编译条件。电子设备可以在第十时段内针对应用程序进行优化编译。

在其他可能的场景中，在系统升级的第二阶段内，电子设备可以完成第一数量的应用程序的优化编译，得到对应的odex文件。在系统升级重启之后，电子设备满足第二编译条件，开始针对应用程序进行优化编译。

在其他可能的场景中，在系统升级过程中不优化编译应用程序。在系统升级后，首次重启的情况下，电子设备在满足第一编译条件期间，完成第二数量的应用程序的优化编译。之后，需要在满足第二编译条件的情况下，针对应用程序进行优化编译。

下面以启用了本申请实施例提供的方法的设备1和未启用了本申请实施例提供的方法的设备2进行比较测试。其中，设备1和设备2中安装相同的应用程序，具有相同的系统资源，实际占用的系统资源量也相同。

在进行系统升级前，测试设备1和设备2中应用程序的冷启动的平均时长。比如，将设备1和设备2中的应用程序值为未运行状态，然后，获取点击每一个应用程序的应用图标，至显示该应用程序的首帧数据之间的时长，作为该应用程序的冷启动时长。获取设备1中所有应用程序的冷启动时长之间的平均值1，获取设备2中所有应用程序的冷启动时长之间的平均值2。上述平均值1和平均值2非常接近。

在进行系统升级之后的首次重启，再次测试设备1和设备2中应用程序的冷启动的平均时长。经过系统升级之后，测试得到的设备1对应的冷启动的平均时长为平均值3，获取设备2对应的冷启动的平均时长为平均值4。上述平均值3明显小于平均值4。系统升级之后，设备1的冷启动平均时长相较于设备2缩短百分之20左右。

在进行系统升级之后的首次重启，分别在设备1和设备2上测试，在热点应用的应用界面上滑动的过程中，各个设备的响应情况。其中，设备1相较于设备2，出现卡顿的概率更低，卡顿平均时长更短，百次滑动的平均卡顿时间更短。

本申请实施例还提供一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，可使得电子设备执行上述实施例中手机执行的各个步骤。当然，该电子设备包括但不限于上述存储器和一个或多个处理器。

本申请实施例还提供一种芯片系统，该芯片系统可以应用于前述实施例中的电子设备。该芯片系统包括至少一个处理器和至少一个接口电路。该处理器可以是上述电子设备中的处理器。处理器和接口电路可通过线路互联。该处理器可以通过接口电路从上述电子设备的存储器接收并执行计算机指令。当计算机指令被处理器执行时，可使得电子设备执行上述实施例中手机执行的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

在一些实施例中，通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种应用程序优化方法，其特征在于，所述方法包括：

电子设备获取用于升级操作系统的升级安装包；

所述电子设备安装所述升级安装包；

响应于所述升级安装包安装完成，所述电子设备优化编译第一数量的第一应用，得到对应的优化可执行odex文件，所述第一数量小于所述电子设备中应用程序的总数量；

所述电子设备重启。

2.根据权利要求1所述的方法，其特征在于，所述电子设备的所述操作系统包括第一操作系统和第二操作系统；所述电子设备运行于所述第一操作系统，所述电子设备安装所述升级安装包，包括：

从所述升级安装包中解析出的升级数据；

在第一存储分区中，写入所述升级数据，所述第一存储分区包括所述第二操作系统在所述电子设备的存储器中占用的静态分区，以及虚拟动态分区；

所述响应于所述升级安装包安装完成，所述电子设备优化编译第一数量的第一应用，包括：响应于所述升级数据已写入所述第一存储分区，基于所述第二操作系统，优化编译第一数量的第一应用。

3.根据权利要求2所述的方法，其特征在于，基于所述第二操作系统，优化编译第一数量的第一应用，包括：

启动所述第二操作系统对应的虚拟机；

通过所述第二操作系统的虚拟机中的编译器，优化编译第一数量的第一应用。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

响应于所述电子设备完成优化编译所述第一数量的所述第一应用，将启动顺序标识配置为从所述第二操作系统启动；

所述电子设备重启，包括：重启上电之后，按照所述启动顺序标识，加载所述第一存储分区中的数据，使所述电子设备运行于所述第二操作系统。

5.根据权利要求1-4任一项所述的方法，其特征在于，

所述第一数量是预设值；或者，

所述第一数量是所述电子设备在第一时长内优化编译的应用程序的数量，所述第一时长是预先配置的。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述第一应用是满足第一条件的应用程序；所述第一条件包括以下一项或多项的组合：

所述第一应用是所述电子设备的应用程序中活跃等级由高到低排列在前N位的应用程序，其中，N为正整数，所述活跃等级是根据应用运行记录及应用下载量评估出的应用的活跃程度；

所述第一应用属于第一集合，所述第一集合是由提供指定类型服务的应用程序组成的集合。

7.根据权利要求6所述的方法，其特征在于，所述电子设备优化编译第一数量的第一应用，包括：

按照所述第一应用的所述活跃等级，由高到低的顺序，依次编译所述第一应用，直至满足截止条件；

所述截止条件为被编译的所述第一应用的数量达到预设的所述第一数量，或者，所述截止条件为优化编译的时间达到预设的第一时长。

8.根据权利要求1-4任一项所述的方法，其特征在于，在所述电子设备重启之后，所述方法还包括：

在满足第二条件的情况下，优化编译第二数量的第二应用；所述第二应用包括无有效的odex文件的应用程序，以及具有有效的odex文件且存在未编译的热点函数的应用程序；所述电子设备满足第二条件的概率高于所述电子设备满足第三条件的概率，所述第三条件是所述电子设备的操作系统中自带的触发优化编译应用程序的场景条件。

9.根据权利要求8所述的方法，其特征在于，所述第二数量是预先配置的，所述第二数量大于所述第一数量。

10.根据权利要求8所述的方法，其特征在于，所述方法还包括：

在满足所述第二条件且优化编译的所述第二应用达到第二数量的情况下，暂停优化编译应用程序；

在满足所述第三条件的情况下，继续优化编译应用程序。

11.根据权利要求8所述的方法，其特征在于，所述第二条件包括以下一项或多项之间的组合：处于灭屏状态；处于充电状态；实际电量大于第一值；

所述第三条件为所述电子设备处于所述灭屏状态、处于上述充电状态且所述实际电量大于第二值；所述第二值大于所述第一值。

12.一种应用程序优化方法，其特征在于，所述方法包括：

电子设备获取用于升级操作系统的升级安装包；

在利用所述升级安装包完成升级之后，所述电子设备重启；

响应于升级后的首次重启，在满足第二条件的情况下，优化编译第二数量的第二应用；所述第二应用包括无有效的odex文件的应用程序，以及具有有效的odex文件且存在未编译的热点函数的应用程序，所述热点函数是所述应用程序的配置文件中记录的函数；所述电子设备满足第二条件的概率高于所述电子设备满足第三条件的概率，所述第三条件是所述电子设备的操作系统中自带的触发优化编译应用程序的场景条件。

13.根据权利要求12所述的方法，其特征在于，所述方法还包括：

在满足所述第二条件且优化编译的所述第二应用达到第二数量的情况下，暂停优化编译应用程序；

在满足所述第三条件的情况下，继续优化编译应用程序。

14.一种电子设备，其特征在于，所述电子设备包括：处理器和存储器，所述存储器用于存储计算机指令，当所述处理器执行所述计算机指令时，以使所述电子设备执行如权利要求1-13中任一项所述方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机程序或指令，当所述计算机程序或指令在计算机上运行时，使得所述计算机执行如权利要求1-13中任一项所述的方法。