CN116643778B

CN116643778B - Application program optimization method and electronic equipment

Info

Publication number: CN116643778B
Application number: CN202310930634.6A
Authority: CN
Inventors: 张康; 朱金鹏; 韩军辉; 陈超
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-07-27
Filing date: 2023-07-27
Publication date: 2024-03-19
Anticipated expiration: 2043-07-27
Also published as: CN116643778A

Abstract

The embodiment of the application provides an application program optimization method and electronic equipment, and relates to the technical field of computers. The problem that all application programs cannot be executed by adopting machine codes in a long time after upgrading and restarting is solved. The specific scheme is as follows: the electronic equipment acquires an upgrade installation package for upgrading an operating system; the electronic equipment installs the upgrade installation package; responding to the completion of the installation of the upgrade installation package, the electronic equipment optimally compiles a first number of first applications to obtain corresponding optimized executable odex files, wherein the first number is smaller than the total number of application programs in the electronic equipment; the electronic device is restarted.

Description

Application program optimization method and electronic equipment

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to an application program optimization method and an electronic device.

Background

When the electronic device runs the application program, the code corresponding to the application program needs to be executed. Among the alternative ways of executing code, machine code execution is the most efficient way of executing code.

However, after each system upgrade of the electronic device, all the application programs cannot enable the machine code to execute for a long time, which results in poor code execution efficiency of the application programs and affects the running speed of the application programs.

Disclosure of Invention

In view of the foregoing, the present application provides an application program optimizing method and an electronic device, which improve the code execution efficiency of an application program after a system upgrade.

In order to achieve the above purpose, the embodiments of the present application adopt the following technical solutions:

in a first aspect, an embodiment of the present application provides an application optimization method, where the method includes: the electronic equipment acquires an upgrade installation package for upgrading an operating system; the electronic equipment is provided with an upgrade installation package; and in response to the completion of the installation of the upgrade installation package, the electronic device optimally compiles a first number of first applications to obtain corresponding optimized executable odex files, wherein the first number is smaller than the total number of application programs in the electronic device, and the electronic device is restarted.

The odex file includes binary codes corresponding to the application program, and the application program can be run by adopting a machine execution mode only when the application program has the odex file.

In the above embodiment, after installing the upgrade data packet and before restarting the device, part of the application programs (the first number of applications) are compiled, so as to obtain the corresponding odex file. Thus, after the upgrade is restarted, the first number of application programs in the electronic device can be executed by adopting a machine code, and after the upgrade is restarted, the average code execution efficiency of the application programs in the electronic device is improved.

In addition, compared with compiling all the application programs, compiling of part of the application programs can avoid increasing more upgrade waiting time

In some embodiments, the operating system of the electronic device includes a first operating system and a second operating system; the electronic device runs in the first operating system, the electronic device installs the upgrade installation package, and the upgrade installation package comprises: upgrade data analyzed from the upgrade installation package; writing the upgrade data in a first storage partition, wherein the first storage partition comprises a static partition occupied by the second operating system in a memory of the electronic device and a virtual dynamic partition; the electronic device optimizing compilation of a first number of first applications in response to the upgrade installation package installation being completed, comprising: responsive to the upgrade data having been written to the first storage partition, a first number of first applications are optimized for compilation based on the second operating system.

In the above embodiment, during the running of the first operating system, not only the second operating system may be upgraded, but also the compiling of the first number of first applications may be optimized based on the upgraded second operating system. Thus, the upgrade of the second operating system and the optimized compiling after the upgrade are completed under the condition that the normal use of the electronic equipment by the user is not affected. And after the upgrade is restarted, all application programs cannot be operated in a mode of executing machine codes.

It will be appreciated that the upgrade process described above may be referred to as a virtual A/B upgrade. In the process of performing virtual a/B upgrade, after the second operating system is upgraded by using the upgrade installation package, the electronic device is instructed to switch from running the first operating system to running the second operating system by restarting, so that the electronic device can run in the upgraded operating system.

In this embodiment of the present application, before the electronic device switches operating systems, that is, during the period when the electronic device runs in the first operating system, system data corresponding to the first operating system is unchanged, so that an odex file compiled based on the first operating system before upgrading is still valid. In this way, before the electronic device switches to the second operating system, the electronic device may execute each application program in a machine code execution manner.

In addition, during the period that the electronic device runs in the first operating system, after the system data of the second operating system is updated, the electronic device compiles the first number of application programs based on the updated second operating system to obtain a first number of odex files, and the first number of odex files can be used when a new version of operating system is run. In this way, after the electronic device switches operating systems, the first application of the first number can still be run in a manner of executing machine code.

Obviously, the electronic device may run the application program in a manner that machine code executes before the electronic device enables the new version of the operating system. After the electronic device enables the new version of the operating system, the electronic device may also run a portion of the application programs (the first number of first applications) in a manner that machine code executes. And ensuring the code execution efficiency of the application program in the running process of the electronic equipment.

In some embodiments, optimizing compiling the first number of first applications based on the second operating system includes: starting a virtual machine corresponding to the second operating system; and optimizing and compiling a first number of first applications through a compiler in a virtual machine of the second operating system.

In some embodiments, the method further comprises: responsive to the electronic device completing optimizing compilation of the first number of the first applications, configuring a boot sequence identification to boot from the second operating system; the electronic device reboots, comprising: and after the power-on is restarted, loading the data in the first storage partition according to the starting sequence identification, so that the electronic equipment runs in the second operating system.

In the above embodiment, the process of modifying the start sequence identifier is configured after the first application is compiled, so that the problem that the operating system cannot be switched normally after upgrading can be avoided.

In some embodiments, the first number is a preset value. In the above embodiment, the electronic device controls the duration of waiting for the upgrade to restart by limiting the number of compiled applications to a reasonable range.

In some embodiments, the first number is a number of applications that the electronic device optimizes compilation within a first time period, the first time period being preconfigured. In the above embodiment, the electronic device controls the duration of waiting for the upgrade to restart by limiting the duration of compiling, so as to control the duration of waiting for the upgrade to restart within a reasonable range.

In some embodiments, the first application is an application that satisfies a first condition; the first condition includes a combination of one or more of: the first application is an application program with the activity level of the application program of the electronic equipment arranged in the front N bits from high to low, wherein N is a positive integer, and the activity level is the activity level of the application estimated according to the application running record and the application downloading amount; the first application belongs to a first set, which is a set of applications providing a specified type of service.

In the above embodiment, it is ensured that after the upgrade is restarted, the application program commonly used by the user (for example, the application program with the active level arranged in the first N bits) or the application program with more important use (for example, providing the service of the specified type) may be run in a machine code execution mode, so as to cover the main use requirement of the user.

In some embodiments, the electronic device optimizing compiles a first number of first applications, including: according to the activity level of the first application, compiling the first application in sequence from high to low until a cut-off condition is met; the cut-off condition is that the number of the compiled first applications reaches the preset first number, or the cut-off condition is that the time for optimizing the compiling reaches the preset first duration.

In some embodiments, after the electronic device reboots, the method further comprises: optimizing compiling a second number of second applications if the second condition is satisfied; the second application comprises an application program without a valid odex file and an application program with a valid odex file and an uncompiled hot spot function; the probability that the electronic equipment meets the second condition is higher than the probability that the electronic equipment meets the third condition, wherein the third condition is a scene condition of a self-contained trigger optimization compiling application program in an operating system of the electronic equipment.

It can be appreciated that after the upgrade is restarted, the electronic device needs to continuously compile the application program that does not contain the valid odex file, and perhaps, the application program of the newly added hot spot function, under the condition that the third condition is satisfied. The third condition is generally not easy to satisfy, so that after restarting, the application program needs to wait a relatively long time before being compiled. During waiting, the code execution efficiency of the application program is low.

In the above embodiment, after the upgrade is restarted, the time period for waiting for compiling the application program in the electronic device can be shortened by reducing the scene condition for triggering the compiling, that is, enabling the second condition which is easier to be satisfied, instead of the original third condition, so that the code execution efficiency of the application program in the electronic device is further improved.

In some embodiments, the second number is preconfigured, the second number being greater than the first number.

In some embodiments, optimizing compiling the second number of second applications if the second condition is satisfied may include: and compiling the second applications sequentially according to the activity level of the second applications from high to low.

In some embodiments, suspending the optimizing compilation application if the second condition is met and the second number of optimizing compilation applications reaches a second number; and continuing to optimize the compiling application program when the third condition is met.

In the embodiment, compatibility of the native compiling scene conditions is realized, and the influence on actual use of the electronic equipment by a user is reduced in the process of completing compiling of all application programs in the equipment.

In some embodiments, the second condition comprises a combination between one or more of: in a screen-off state; is in a charged state; the actual electric quantity is larger than the first value; the third condition is that the electronic equipment is in the screen-off state, in the charging state and the actual electric quantity is larger than a second value; the second value is greater than the first value.

In a second aspect, an embodiment of the present application provides an application optimization method, where the method includes: the electronic equipment acquires an upgrade installation package for upgrading an operating system; after the upgrade is completed by using the upgrade installation package, restarting the electronic equipment; in response to the first restart after the upgrade, optimizing compiling a second number of second applications if a second condition is satisfied; the second application comprises an application program without a valid odex file and an application program with a valid odex file and an uncompiled hot spot function, wherein the hot spot function is a function recorded in a configuration file of the application program; the probability that the electronic equipment meets the second condition is higher than the probability that the electronic equipment meets the third condition, wherein the third condition is a scene condition of a self-contained trigger optimization compiling application program in an operating system of the electronic equipment.

In the above embodiment, after the upgrade is restarted, by reducing the scene condition for triggering the compiling application program, for example, enabling the second condition which is easier to be met, instead of the original third condition, the time period for waiting for the compiling of the application program in the electronic device can be shortened, and the code execution efficiency of the application program in the electronic device can be improved.

In some embodiments, the method further comprises: suspending optimizing the compiling application program under the condition that the second condition is met and the second application of optimizing the compiling reaches a second number; and continuing to optimize the compiling application program under the condition that the third condition is met.

In some embodiments, before the electronic device is restarted, the method further comprises: and in response to the completion of the installation of the upgrade installation package, the electronic device optimally compiles a first number of first applications to obtain corresponding optimized executable odex files, wherein the first number is smaller than the total number of application programs in the electronic device.

In some embodiments, the first number is a preset value. Alternatively, the first number is a number of applications that the electronic device optimizes compilation within a first time period, the first time period being preconfigured.

In some embodiments, the first application is an application that satisfies a first condition. Wherein the first condition comprises a combination of one or more of: the first application is an application with the top N bits of the activity level arranged from high to low in the application programs of the electronic device, wherein N is a positive integer. The activity level is the activity level of the application estimated according to the application running record and the application downloading amount; the first application belongs to a first set, which is a set of applications providing a specified type of service.

In a third aspect, an electronic device provided in an embodiment of the present application includes one or more processors and a memory; the processor comprises a modem processor, the memory being coupled to the processor, the memory for storing computer program code comprising computer instructions for performing the method of the first aspect, the second aspect and possible embodiments thereof, when the computer instructions are executed by one or more processors.

In a fourth aspect, embodiments of the present application provide a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method of the first aspect, the second aspect, and possible embodiments thereof.

In a fifth aspect, the present application provides a computer program product for, when run on an electronic device as described above, causing the electronic device to perform the method of the first aspect, the second aspect and possible embodiments thereof as described above.

In a sixth aspect, the present application provides a chip system, applied to an electronic device, storing a computer program, which when executed, causes the electronic device to perform the method of the first aspect, the second aspect and possible embodiments thereof.

It will be appreciated that the electronic device, the computer storage medium and the computer program product provided in the above aspects are all applicable to the corresponding methods provided above, and therefore, the advantages achieved by the electronic device, the computer storage medium and the computer program product may refer to the advantages in the corresponding methods provided above, and are not repeated herein.

Drawings

FIG. 1 is a diagram illustrating a scenario in which a compiled application is optimized after a system upgrade in the related art;

Fig. 2 is a schematic hardware structure of an electronic device according to an embodiment of the present application;

fig. 3 is a diagram illustrating a software structure of an electronic device according to an embodiment of the present application;

FIG. 4 is one of the step flowcharts of an application optimization method according to an embodiment of the present application;

FIG. 5 is an exemplary diagram of a scenario for optimizing a compiled application after a system upgrade in an embodiment of the present application;

FIG. 6 is a second flowchart illustrating a method for optimizing an application according to an embodiment of the present disclosure;

FIG. 7 is an exemplary diagram of an interface for system upgrades in an embodiment of the present application;

FIG. 8 is a third flowchart illustrating a method for optimizing an application according to an embodiment of the present disclosure;

FIG. 9 is a diagram illustrating a second example of a scenario for optimizing a compiled application after a system upgrade in an embodiment of the present application;

FIG. 10 is a third exemplary diagram of a scenario for optimizing a compiled application after a system upgrade in an embodiment of the present application;

FIG. 11 is a diagram illustrating an example of a scenario for optimizing a compiled application after a system upgrade in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. Wherein, in the description of the present application, unless otherwise indicated, "at least one" means one or more, and "a plurality" means two or more. In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", and the like are used to distinguish the same item or similar items having substantially the same function and effect. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ.

It is convenient to understand that technical terms related to the embodiments of the present application are first described below.

1. Source code of the application: code data written by a developer of an application program is used to support various application services implementing the application program. The executable (dex) file of the electronic device contains the corresponding source code. When an electronic device downloads an application installation package (android application package, apk) of an application, a dex file containing source code is written into a data (data) partition of the electronic device along with the apk of the application.

When the electronic device runs the application program, the source code of the application program needs to be executed, and corresponding application services are provided for users. Of course, the source code of the application is code data that is not directly identifiable by the electronic device. At present, an electronic device mainly adopts modes of interpretation execution, machine code execution and the like to execute source codes of application programs.

2. Interpretation execution: during the running of the application program by the electronic device, the source code is interpreted by an interpreter as a binary code recognizable by the electronic device, and then the binary code is executed. In this way, in the process of running the application program by adopting the interpretation execution mode, the electronic device interprets a sentence of source code and can execute a sentence of corresponding binary code.

In a scenario where the code amount of the source file is large, the source code of the application program is inefficient to execute.

3. Machine code performs: also referred to as compiled execution, refers to the translation of source code into machine instructions, e.g., into binary code that is directly recognizable by an electronic device, by a compiler. Based on the compiled binary code, a corresponding optimized executable (odex) file is generated. When the application program is operated, the electronic equipment can directly execute binary codes in the odex file corresponding to the application program, and provide corresponding application services for users.

The compiling the source code into the machine instruction may include: pre-run (AOT) compilation and dynamic (JIT) compilation.

Under the scene of adopting AOT compiling, before executing an application program, compiling source codes of the application program into machine codes, and generating corresponding odex files. Thus, the application program can be started faster and has better running performance.

Under the JIT compiling scene, a sentence of source codes is interpreted and a sentence of corresponding binary codes is recorded in the process of running an application program. After all source codes are interpreted once, an odex file containing binary codes of all source codes can be obtained. Of course, after the application program stops running, the electronic device will destroy the odex file corresponding to the application program. The two compiling methods have advantages and disadvantages, and in the embodiment of the application, the description is mainly performed by adopting a scene of AOT compiling, and in the subsequent embodiment, the method can also be called as optimizing compiling of the application program.

Illustratively, the abovementioned odex file may include binary code of all source codes of the application program. Also, for example, the abovementioned odex file may also include binary code corresponding to the hot-spot function in the source code. The hot spot function may be a code function with calling times arranged before a designated ranking in the running process of the application program, and generally, the hot spot function corresponding to the application program may be recorded in a configuration file of the application program.

It can be appreciated that the binary code in the odex file is an instruction that can be directly recognized by the electronic device, and the electronic device executes the binary code in the odex file faster in the process of running the application program. Thus, the faster the application program is responding during running. However, the odex file of the application is not a self-contained file in the apk of the application, and the electronic device needs to use the application for a period of time before generating the corresponding odex file.

Before the generation of the odex file of the application program, the electronic device cannot execute with the machine code because there is no odex file of the application program in the electronic device. In this scenario, the application can only be run in an interpreted execution mode.

It can be seen that the premise of enabling machine code execution is that a corresponding odex file is generated.

In addition, the method comprises the following steps. The odex file is a file compiled based on a boot class path (BootClassPath) provided by the operating system. The odex file also records the dependent BootClassPath and the size of the base file packet (e.g., jar packet (java archive file)) stored in the BootClassPath indication location. In this way, in the process of executing the odex file, the electronic device can call various types of jar packages according to BootClassPath.

After the BootClassPath of the operating system changes, the odex file may fail, resulting in the electronic device not being able to continue enabling machine code execution. Typically, after an electronic device performs an operating system upgrade, a BootClassPath in the electronic device may change, for example, an address change, and a jar packet size change in a storage location indicated by the BootClassPath.

The operating system upgrades described above may be, for example, operating system upgrades based on over-the-air technology.

4. Operating system upgrades Over The Air (OTA): refers to the implementation of software upgrades to electronic devices over the air interface of mobile communications. The electronic equipment corresponds to a server for issuing an upgrade installation package of the operating system, the electronic equipment can acquire the latest upgrade installation package from the server, and the electronic equipment is upgraded by utilizing the upgrade installation package.

During an operating system upgrade, the electronic device may update BootClassPath. After BootClassPath updates, the odex files of all applications in the electronic device will fail.

In some embodiments, before the electronic device runs the application, it may be checked whether the application corresponds to an odex file. In the case that the application program is determined to correspond to the corresponding odex file, whether the corresponding odex file is valid or not is detected. For example, bootClassPath recorded in the odex file is compared with the actual BootClassPath in the operating system, and if the addresses are the same and the corresponding jar packet sizes are the same, the effectiveness of the odex file is determined. If the addresses are different or the corresponding jar packet sizes are different, determining that the odex file has failed.

When the application program is determined to correspond to the odex file and the odex file is valid, the electronic device runs the application program in a machine code execution mode.

And under the condition that the application program is determined to have no corresponding odex file or the odex file is invalid, the electronic equipment adopts an interpretation execution mode to run the application program.

In addition, if the application program does not have a corresponding odex file (for example, the electronic device just installs the application program), or if the odex file of the application program has failed (for example, the electronic device updates BootClassPath in the process of upgrading the OTA operating system), the electronic device needs to compile the application program under the condition of being idle and having sufficient electric quantity, so as to generate the corresponding odex file.

Illustratively, in the system native rule of the electronic device, the condition for determining whether to be idle may be: the display screen is off and charging. The condition for judging whether the electric quantity is sufficient may be: the power of the electronic device is not less than 90% (second value).

However, as the user's degree of dependence on the electronic device increases, the higher the frequency and longer the time of use the electronic device is. The scenario of triggering a compiled application in a native rule becomes more and more difficult to appear. The native rule may be a rule of the operating system.

For example, users often continue to use an electronic device while the device is being charged. Thus, during charging, the electronic device is not in an off-screen state and cannot trigger optimal compilation for the application. For another example, in the charging process, the user stops charging when the electric quantity is less than 90%, so that even if the electronic device is off-screen and charging, the optimal compiling for the application program cannot be triggered because the electric quantity is less than 90%.

In an exemplary scenario, as shown in fig. 1, after the electronic device upgrades the operating system according to the upgrade installation package, the upgraded operating system is validated by restarting the device. The restarting process after upgrading is as follows: the electronic device is restarted to power up. Then, the data (data partition) is mounted. The data partition is a storage area for storing the application program apk, and after the data partition is mounted, the apk can be scanned and correspondingly optimized.

As shown in fig. 1, in period 1, the electronic device may perform corresponding optimization processing on the system application and the third party application. The system application refers to an application program or service carried by the operating system, and the third party application refers to an application program developed by a third party.

In an exemplary process of restarting the electronic device after upgrading, the electronic device displays an interface indicating the optimized application, and then performs different optimization treatments on the application programs in the electronic device in a classified manner. For example, system applications are processed in a fast compile (speed-profile) mode: and checking an executable file (dex) in the system application, and then translating the hot spot function methods listed in the configuration file of the system application in advance.

For another example, the third party application is processed in a verify (verify) mode: only the dex file of the third party application is checked.

After power-on, the user uses the electronic device during period 2. In period 2, it is difficult to satisfy the scene condition for triggering compilation indicated in the native rule at the same time, for example, the scene condition for triggering compilation in the above-described native rule may be that "in off-screen state", "in charging state" and "remaining power is not less than 90%", are satisfied at the same time.

Therefore, the time length of the first restart after the upgrading is increased, and the third party application program frequently used by the user has the opportunity to generate the corresponding odex file after the period 2, so that the operation efficiency of the third party application program is low when the user uses the third party application program in the period 2.

After the electronic equipment performs OTA operation system upgrading through actual statistics, the time required for the electronic equipment to upgrade is about 2-3 days, and the odex file of the application program in the electronic equipment can be regenerated. However, during this 2-3 day period, the electronic device can only run the application program in an interpreted execution manner, or in a JIT compilation manner. Therefore, the application program has low code execution efficiency and relatively slow response speed in the whole running period, and the man-machine interaction efficiency of the electronic equipment is very affected.

In order to improve the above problems, the embodiments of the present application provide an application optimization method, which can be applied to an electronic device. Before the electronic device is restarted, compiling the partial application program to generate an odex file of the partial application program, and storing the odex file. Thus, after the OTA operating system is upgraded, the electronic device can still operate the part of the application program in a machine code execution mode.

In some embodiments, the compiled application may be a hotspot application in the electronic device prior to the upgrade restart. It will be appreciated that the hotspot application may be a top-ranked application in the electronic device. Thus, before the odex files of all application programs are generated, the use requirement of a user on the electronic equipment can be met.

By way of example, the electronic device in the embodiments of the present application may be a portable computer (such as a mobile phone), a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (personal digital assistant, PDA), a media player, etc., and the specific form of the electronic device is not particularly limited in the embodiments of the present application.

Referring to fig. 2, fig. 2 shows a schematic diagram of one possible hardware structure of the electronic device:

as shown in fig. 2, the electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, etc.

The sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

It is to be understood that the structure illustrated in the present embodiment does not constitute a specific limitation on the electronic apparatus 100. In other embodiments, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and command center of the electronic device 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device 100. In other embodiments, the electronic device 100 may also employ different interfaces in the above embodiments, or a combination of interfaces.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (flex), a mini, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element (image sensor) through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing, so that the electric signal is converted into an image visible to the naked eye. ISP can also optimize the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, electronic device 100 may include N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, or the like.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

The software system of the electronic device may adopt a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. In the embodiment of the application, taking an Android system with a layered architecture as an example, a software structure of an electronic device is illustrated.

Fig. 3 is a software configuration block diagram of an electronic device according to an embodiment of the present application.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the operating system of the electronic device may be divided into multiple layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (ART) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages.

As shown in fig. 3, an online upgrade client (online update client, OUC), chat application, payment application, music application, video application, game application, browser, etc. may be installed in the application layer. Of course, applications not shown in fig. 3, such as a call, a memo, a contact, a camera, a gallery, a calendar, a map, bluetooth, etc., are also included in the application layer.

The OUC is configured to obtain the latest upgrade installation package from the server of the service upgrade installation package.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions.

As shown in fig. 3, the application framework layer may include an upgrade engine (update engine), a compile optimization service module (dexopt service), an OTA upgrade management service (OTA preopt service), and the like. Of course, services and modules not shown in fig. 3, such as a window manager, resource manager, view system, etc., may also be included.

Illustratively, the update engine is used for driving and executing the upgrade of the operating system.

The compiling optimization service module is used for determining application programs needing compiling and determining compiling sequence among the application programs. For example, a hot spot application may be determined as an application program that needs to be compiled.

The OTA upgrade management service described above is exemplary for managing operating system upgrades. Taking an electronic device employing a virtual A/B operating system as an example, the target operating system being upgraded may be determined. For example, the electronic device runs based on the operating system a, and the target operating system to be upgraded is the operating system B.

As shown in fig. 3, the system library may include a plurality of functional modules. For example: layer integrators (surfeflingers), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc. SurfaceFlinger is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications. Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio and video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc. The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like. The 2D graphics engine is a drawing engine for 2D drawing.

Android run time includes a core library and virtual machines. Android run time is responsible for scheduling and management of the Android system. An encoder (dalvik excutable file to optimized art file, dex2 oat) and an optimization compiling (dexopt) module are operated in the Android run virtual machine. The dexopt can be used for converting a dex file containing source codes into a dex file containing binary codes. For example, the dexopt may call dex2oat to translate the source code of the application program, and generate an odex file corresponding to the application program according to the translation result of the dex2 oat.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The kernel layer is a layer between hardware and software. The kernel layer at least comprises a camera driver, an audio driver, a sensor driver and the like, and the embodiment of the application does not limit the application.

The following describes implementation details of an application program optimization method provided in an embodiment of the present application with reference to the accompanying drawings:

in some embodiments, a developer may store a written upgrade installation package on a server, through which the upgrade installation package is published. The upgrade installation package is a data package for upgrading the operating system to the latest version. In some embodiments, the upgrade installation package may be a full upgrade package or an incremental upgrade package, and embodiments of the present application are not particularly limited.

In this embodiment of the present application, the upgrade installation package includes a final installation (postinstruments) file in addition to the data for updating the operating system. The postinstruments file may indicate a procedure to be performed after installing and verifying the upgrade installation package. The postinstruments file may be a file executed last in the process of executing the operating system upgrade according to the upgrade installation package. For example, after installing and verifying the upgrade installation package, the postinstruments file is executed to implement compiling a portion of the application. For another example, in the case that the electronic device enables the virtual a/B operating system, after installing and verifying the upgrade installation package, the postinstruments file is executed to implement compiling a part of the application program in the target operating system, and instruct the electronic device to activate and enable the target operating system, where the target operating system is the operating system upgraded in the a/B operating system.

In some embodiments, the electronic device obtains an upgrade installation package, and an operating system of the electronic device may be upgraded based on the upgrade installation package. As an implementation manner, the process of obtaining the upgrade installation package and installing the upgrade installation package may refer to S101 to S104 in fig. 4:

s101, the OUC in the electronic device may search for and download the upgrade installation package from the server.

In one possible implementation, the electronic device may periodically initiate a search request to the server via the OUC, the search request containing the version number (e.g., version 1.1) of the operating system currently running by the electronic device. The server retrieves whether an upgrade installation package (e.g., version 1.2) currently exists for the update version number based on the operating system version number in the package search request. When there is an updated version of the upgrade installation package, the server feeds back to the electronic device the download address of the upgrade installation package (e.g., the full upgrade installation package of version 1.2). And the electronic equipment downloads according to the download address of the upgrade installation package.

In another possible implementation, the server may also push to the electronic device actively after obtaining the new version of the upgrade installation package.

In some embodiments, the electronic device is provided with the capability to upgrade the operating system after obtaining the upgrade installation package. In some embodiments, the electronic device may automatically upgrade based on the upgrade installation package in an idle condition. In other embodiments, the electronic device may be upgraded based on the upgrade installation package in response to an upgrade instruction by the user.

In an embodiment of the present application, as shown in fig. 5, upgrading the operating system of the electronic device may include two phases. In the first stage, the electronic device can install and verify the upgrade installation package. In the second stage, the electronic device may perform AOT compiling for the first number of application programs according to the postinstruments file in the upgrade installation package, to generate a corresponding odex file.

As one implementation, the OUC may download and save the upgrade installation package to a user data partition (Userdata). Then, OUC indicates to start the update engine, and the update engine executes the first stage of upgrading the operating system, see specifically S102-S104:

s102, OUC indicates update Engine to initiate an upgrade to the operating system.

As one implementation, the OUC may set the startup attribute of the update engine to true by sending an upgrade instruction to the update engine. In addition, a service servicemanger resident in the background of the operating system in the electronic device monitors the startup attribute of the update engine. When the servicemanger detects that the starting attribute of the update engine is true, the servicemanger starts the update engine.

The OUC then obtains the status of the update engine via the binder communication. After the OUC confirms that the update engine has been successfully started, the OUC transmits an upgrade parameter to the update engine (e.g., the upgrade parameter may indicate whether the current upgrade operation is a file update operation or a file drop operation), and triggers the update engine to enter an upgrade procedure.

S103, the update engine is installed according to the upgrade installation package.

In some embodiments, the update engine may be a check if META-INF (i.e., digital signature) in the upgrade installation package is valid, confirming if the upgrade installation package is a valid upgrade package. For specific implementation details, reference may be made to the related art, and details are not repeated here.

After determining that the upgrade installation package passes the inspection, the update engine may parse the upgrade installation package to obtain upgrade data for updating the operating system. The update engine may then write the upgrade data to the corresponding memory partition (static partition or dynamic partition, etc.) in the memory.

Taking upgrading the electronic device with the virtual a/B operating system enabled, the electronic device runs in the a operating system as an example, and the implementation manner of S103 is as follows:

s103-1, the update engine reads the saved upgrade installation package from the user data partition (Userdata), and writes upgrade data aiming at the static partition in the upgrade installation package into the static partition (B) to upgrade the static partition.

For example, the system upgrade package contains data of the static partition of version 1.2, i.e., upgrade data for the static partition. After the update engine parses the upgrade installation package, the static partition data (i.e., the static partition data of version 1.2) carried in the upgrade installation package is overwritten into the static partition (B).

S103-2, creating a virtual dynamic partition in a user data partition (Userdata) by the update engine, and writing data aiming at the dynamic partition in the upgrade data into the virtual dynamic partition.

For example, the upgrade installation package includes data of the dynamic partition of version 1.2, and after the data of the dynamic partition of the publication 1.2 is parsed from the upgrade installation package, the data of the dynamic partition (Super) of version 1.2 is written in the virtual dynamic partition.

S104, checking after upgrading the update engine.

In some embodiments, after installing the upgrade data package, the updated B operating system (data in static partition B and virtual dynamic partition) is checked for validity. If so, determining that the installation and verification are completed, and executing the PostInstallal file in the upgrade installation package.

Thus, the second phase of operating system upgrade is entered. In the second stage, the electronic device can optimally compile the first number of application programs to obtain corresponding odex files. For example, the electronic device may perform optimized compilation for the application in response to the upgrade installation package being installed. If the foregoing S101 to S104 are executed, the optimization compiling for the application program is performed in response to the verification after the upgrade. For another example, after S101 to S103 are performed, in response to upgrade data being written to the first storage partition (e.g., written to the static partition (B) and the virtual dynamic partition), optimized compilation for the application may be performed.

As an implementation manner, the process of performing optimization compilation may refer to S105 to S106 in fig. 4:

s105, the update engine instructs the ART to compile the first number of application programs.

In some embodiments, the PostIntal file may be configured with a first number. Thus, the update engine may instruct the ART to compile the first number of applications via the compiler. For example, the postinstruments file may be configured to have a first number of 5, and the update engine executing the postinstruments file may instruct the ART to compile 5 applications in the electronic device via the compiler. The first number may be, for example, less than the total number of applications in the electronic device.

In the case of an electronic device that employs a virtual a/B operating system, the application program may be optimally compiled by means of ART of the target operating system. In this way, the compiled odex file is generated based on the BootClassPath of the target operating system, and after the electronic device is switched from the original operating system to the target operating system, the compiled application program can be run in a machine code execution mode.

It will be appreciated that in the case where the electronic device is running on the a operating system (the original operating system, or the first operating system), the B operating system (the target operating system, or the second operating system) is updated, and only the data in the storage partition (e.g., the first storage partition) corresponding to the B operating system is updated, for example, the first storage partition includes a static partition of the B operating system, and a virtual dynamic partition created for the B operating system, etc.

Obviously, the update does not affect the system data corresponding to the operating system a. In this way, before the electronic device starts the operating system B, bootClassPath in the operating system A is unchanged, the compiled odex file is still valid based on the operating system A before upgrading, and the electronic device can run an application program according to the machine code execution mode during the operation of the operating system A.

After the data in the first storage partition of the B operating system is updated, bootClassPath in the B operating system is changed, in order to ensure that after the B operating system is switched and enabled, a first number of application programs in the B operating system may be executed by using machine codes, the odex files of the first number of application programs may be compiled in the B operating system before the B operating system is switched, and a target identifier is assigned to the odex files compiled in the B operating system, where the target identifier is used to distinguish from original odex files of the application programs (the odex files compiled based on the a operating system), so that the error loading of the odex files compiled based on the B operating system during the operation of the electronic device in the a operating system is avoided, and the execution failure of the machine codes is caused.

For example, the target operating system is a B operating system, and the file name of the odex file compiled in the ART of the B operating system may carry the identifier of the B operating system, for example, the suffix of the file name includes "B" as the corresponding target identifier. The above is merely an example of the target mark, and is not intended to limit the target mark.

In other embodiments, the postinstrument file may be configured with a first time period, such that the update engine may instruct the ART to sequentially compile the application program through the compiler for the first time period. It will be appreciated that the number of applications actually compiled within the first time period is the first number. For example, the postinstruction file may be configured to have a first duration of 3 minutes, and the update engine executing the postinstruction file may instruct the ART to sequentially compile the application program through the compiler, and after the compiling duration reaches 3 minutes, the compiling is stopped. In this example, if 5 applications were compiled within 3 minutes, the corresponding first number would be 5.

In some embodiments, the ART may compile the applications one by one during the compiling of the first number of applications. In the compiling process, a hot spot function recorded in a configuration file of an application program can be obtained, then, a source code of the hot spot function is translated into a binary code, and a corresponding odex file is generated. It can be understood that the hot spot function is related to the habit of using the application program and the operation rule of the application program according to the activity degree (or the calling frequency) of each function in the source code, and the hot spot function in the configuration file can be updated according to the activity degree of the function in the process of using the application program by the electronic device.

In some embodiments, the compiled application may be a first application in the electronic device that satisfies the first condition.

Wherein the first condition may include a combination of one or more of:

(1) The first application is an application with the top N bits of the activity level arranged from high to low in the application programs of the electronic device, wherein N is a positive integer. For example, N is 5, and the first application may be an application program with an active level arranged at top5 in the electronic device. The liveness level is the liveness level of an application estimated from application running records (records of foreground running, background running, etc.) and application download amounts.

It will be appreciated that the activity level of each application in the electronic device may be evaluated based on information such as user usage habits (indicated by application running records), application download amounts, and the like. For example, a record of the user's application execution for each application may be obtained, and a score of 1 indicating usage habits may be evaluated. Then, the application download amount is quantized to score 2. And fitting the activity score based on the score 1 and the score 2 by combining the weight corresponding to the using habit and the application downloading amount of the user. Then, the activity level is divided by the activity score. The higher the activity score, the higher the corresponding activity level, the lower the activity score, and the lower the corresponding activity level. The applications arranged in front are hotter than the applications arranged in back, with the activity level being arranged from high to low.

(2) The first application belongs to a first set, which is a set of applications providing a specified type of service.

Illustratively, the first set (which may also be referred to as an application set) includes a plurality of applications, and each application is a preselected type of application. The pre-selected type of application is an application that can provide a specified application service. In addition, there may be one or more pre-selected types, and the embodiments of the present application are not particularly limited.

For example, the pre-selected type of application is an application providing a communication-type service, and a chat application, a payment application, a traffic card application, a short message application, a video application, a work communication application, and the like are installed in the electronic device. In this scenario, the application set (first set) may be a set composed of applications such as chat applications, short message applications, work communication applications, and the like.

Illustratively, the process of compiling the first number of applications by the ART may be: and randomly selecting a first number of applications to be compiled from the application set, and then optimizing and compiling the applications to be compiled in sequence. Still further by way of example, the process by which the ART compiles the first number of applications may be: and randomly extracting an application program from the application set to perform optimal compiling, randomly extracting an application program which is not optimally compiled from the application set after the optimal compiling of the application program is completed, and continuously performing optimal compiling on the application program until a cut-off condition is met. The cut-off condition may be that the total duration of the ART compiling application reaches the first duration, or the cut-off condition may be that the total number of ART compiling applications reaches the first number.

Also by way of example, the process of compiling the first number of applications by ART may also be: and selecting a first number of applications to be compiled from the application set, and then optimizing and compiling the applications to be compiled in sequence. The selected application to be compiled is an application program with the top N bits of active level arranged from high to low in the application programs of the electronic equipment.

Still further by way of example, the process by which the ART compiles the first number of applications may be: and selecting the application program with the highest activity level from the application programs in the application set to perform optimized compiling. After optimizing compiling for one application program is completed, selecting the application program with the highest activity level from the application programs which are not optimized and compiled in the application set, and continuing optimizing compiling for the application program until a cut-off condition is met. The cut-off condition may be that the total duration of the ART compiling application reaches the first duration, or the cut-off condition may be that the total number of ART compiling applications reaches the first number.

Illustratively, the process of compiling the first number of applications by the ART may also be: and the application programs in the electronic equipment are ordered according to the activity level, and a first number of application programs are selected from the application programs with the activity level arranged in the first N bits to serve as the application to be compiled, and optimized compiling is carried out. Wherein N is a positive integer. Also by way of example, the process of compiling the first number of applications by ART may also be: the application programs in the electronic equipment are ordered according to the activity level, the application programs arranged at the first position are selected for optimal compiling, and after the optimal compiling for one application program is completed. And rearranging the application programs which are not optimally compiled according to the activity level from high to low, selecting the application program with the activity level arranged at the first position to continuously optimally compile, and repeating the process until the cut-off condition is met. The cut-off condition may be that the total duration of the ART optimizing and compiling application program reaches the first duration, or the cut-off condition is that the total number of ART optimizing and compiling application programs is the first number.

And S106, carrying out optimized compiling on the application program by the ART according to the upgrade compiling script file in the PostInstall file.

In some embodiments, after running the upgrade compilation script file (otatreopt_script. Sh), the relevant system components in the ART, such as otachoor-bootrap, com.android.run, com.android.art, com.android.sdkext, etc., may be activated in the apexd of the target operating system.

After activating the corresponding system components, ART can implement optimized compilation for applications based on otatreopt_script.

As one implementation, as shown in fig. 6, the process of implementing the optimized compilation application is as follows:

s1, the upgrade compiling script module instructs the compiling optimization service module to execute a compiling preparation task.

The upgrade compiling script module may be a software module which is formed after the ART runs the otatreopt_script. The upgrade compiling script module can run according to the program rule in the otape_script.sh, and achieves the functions indicated by the otape_script.sh. For example, the function of instructing the compilation optimization service module to initialize, acquiring a dexopt command instructing the compiler to execute compilation optimization from the compilation optimization service module, and the like.

In some embodiments, the upgrade compilation script module may send a command prompt (CMD) to the compilation optimization service module indicating that initialization is to take place. Then, the upgrade compilation script module may call a preparation () function, causing the flow to enter S2.

S2, the compiling and optimizing service module determines an application program needing compiling and optimizing.

It will be appreciated that the compilation preparation task described above may include determining an application program that requires compilation optimization. The application program requiring compilation optimization may be referred to as an application to be compiled.

In some embodiments, the upgrade compilation script module may instruct the compilation optimization service module to determine applications that require compilation optimization via a preparation () function. And the compiling optimization service module responds to the instruction of upgrading the compiling script module to determine the applications to be compiled and the compiling sequence among the applications to be compiled.

By way of example, it may be that an application program whose activity level is ranked in the top N bits is acquired as an application to be compiled. And then, determining the sequence of optimizing compiling among the applications to be compiled according to the activity level. Wherein, the higher the activity level, the earlier the compiling order. The more active the level, the later the compilation order.

Also, for example, the application to be compiled is determined from the application set, and the implementation process refers to the foregoing embodiment, which is not described herein in detail. Then, the optimized compiling order between the applications to be compiled is arranged randomly, or according to the activity level, the optimized compiling order between the applications to be compiled is arranged.

And S3, the compiling optimization service module informs the upgrading compiling script module that the compiling preparation task is completed.

In some embodiments, the upgrade compilation script module may be notified by way of a result callback of the prepare () function that the compilation preparation task is currently completed.

S4, the upgrade compiling script module sends request information 1 to the compiling optimization service module.

The request information 1 is used for requesting to acquire a dexopt command, and the dexopt command can instruct a compiler to execute compiling optimization. Illustratively, the dexopt command includes information of an application program to be compiled, which is used to instruct the dexopt call compiler to perform optimal compiling on the application program.

In some embodiments, the upgrade compilation script module may implement sending request information 1 to the compilation optimization service module by invoking a next () function.

And S5, responding to the request information 1, and feeding back a target dexopt command for indicating to compile the target application program to the upgrade compiling script module by the compiling optimization service module.

In some embodiments, when the upgrade compiling script module sends the request information 1 to the compiling optimization service module, the application program which is arranged in the first place in the application to be compiled, which is not yet compiled actually, is used as the target application program. And then, the compiling optimization service module sends a target dexopt command for indicating to compile the target application program to the upgrading compiling script module. Triggering the upgrade compiling script module to start optimizing compiling aiming at the target application program, namely executing S6-S13.

For example, after optimizing compilation of the i-1 th target application (i.e., executing S6-S13 based on the i-1 st target application) is completed before the number of times the request information 1 is transmitted does not reach the first number, the upgrade compilation script module may transmit the i-th request information 1 to the compilation optimization service module, where i is a positive integer greater than 1. And the compiling and optimizing service module regards the application program which is arranged at the first position in the application to be compiled which is not compiled actually as the ith target application program.

In other embodiments, after the optimization compilation of the i-1 th target application program is completed (i.e., S6-S13 are executed based on the i-1 th target application program), if the current system time distance does not exceed the first duration during which the first request information 1 is sent, the request information 1 is sent again to the compilation optimization service module, and the optimization compilation of the i-1 th target application program is indicated.

It can be understood that the first i target applications determined have completed compiling, and the i target applications are the applications arranged in the first order in the applications to be compiled after the first i target applications are removed.

And then, the upgrade compiling script module executes S6-S13 based on the ith target application program. Of course, when i is still smaller than the first number, the upgrade compiling script module may send the (i+1) th request information 1 to the compiling optimization service module, and repeat the above process, so as to compile the (i+1) th target application program.

S6, the upgrade compiling script module instructs a directory changing module (otalreopt_color) to run based on the target dexopt command.

In some embodiments, the upgrade compilation script module may invoke an otalreopt_color () function based on the target dexopt command to enable the otalreopt_color.

S7, executing a target dexopt command by the otaprenopt_color.

In some embodiments, the process of executing the target dexopt command may be that the otaprenopt_color executes the target dexopt command through exec () function.

S8, the otalreopt_color can call a first tool class (otalreopt_utels).

In some embodiments, it may be that the otapmropt_color calls the otapmropt_utets based on the target application indicated in the target dexopt command in the process of executing the target dexopt command.

S9, the second tool class (otapratopt_utets) indicates that compiling preparation information corresponding to the target application program is determined.

In some embodiments, the otapieopt_uteis may be a function that instructs the otapieopt to determine, based on the target application, that the target application corresponds to the compilation preparation information through a fork () function in response to the call of the otapieopt_color. Illustratively, the compiling preparation information includes information such as an application identification of the target application program (for determining an object for performing optimization compiling), a storage location of the odex file, and the like. Wherein, the above-mentioned otoreopt_uteils and otoreopt are both tools related to compilation which can be started after oat is upgraded, the above-mentioned otoreopt_uteils can call otoreopt, and the otoreopt can obtain the preparation information related to compilation.

S10, determining corresponding compiling preparation information of the target application program by using the otatreopt.

In some embodiments, the otapratopt may call the runpratopt () function, initialize the otapratopt, and obtain the application identification of the target application. Then, the open_oat_out_file () function is called, triggering the call of the create_oat_out_path () function. In the case that the create_oat_out_path () function is called, the call of the calculate_oat_file_path () function may be triggered to implement determining a target storage location for storing an odex file that is subsequently generated for the target application.

S11, the otatreopt acquires the identification of the target operating system from the OTA upgrade management service.

In some embodiments, the otatreopt may call a gettargetslot () function to obtain the identity of the target operating system from the OTA upgrade management service. The target operating system may be an operating system that has been subjected to data upgrade.

Taking the electronic device with the virtual a/B operating system enabled as an example, under the condition that the electronic device runs in the a operating system, the otatreopt can call the gettargetslot () function, and can obtain the identification of the B operating system (target operating system) from the OTA upgrade management service.

S12, the otaprenopt sends compiling preparation information and the identification of the target operating system to the dexopt.

In some embodiments, the otapieopt may pass compilation preparation information and the identity of the target operating system to the dexopt by calling a dexopt () function.

S13, the dexopt calls a compiler, optimizes and compiles the target application program on the target operating system, generates a corresponding target odex file, and stores the target odex file in a target storage position.

In some embodiments, the file name of the target odex file may carry the identification of the target operating system. For example, the target operating system is a B operating system, and thus, the file name of the target odex file includes "B".

Taking an electronic device with a virtual a/B operating system enabled as an example, as shown in fig. 7, during an operating system upgrade, the electronic device may display an upgrade interface 701, where the upgrade interface 701 is an application interface corresponding to the OUC. In addition, upgrade progress information 702 is displayed in the display upgrade interface 701.

After S103 is performed, the upgrade progress information 702 of the upgrade interface 701 indicates a first scale. Wherein the first ratio is less than 100%, for example, the first ratio is 75%. In addition, in the process of executing S1 to S13, the OUC is instructed to update the upgrade progress information 702 every time the compilation for one target application is completed.

An exemplary scenario, employing a scheme that limits the compilation of a first number of applications after installation of an upgrade installation package. In this way, the upgrade progress information 702 is not included in the electronic device at the point in time when the first scale is changed, the odex file compiled on the target operating system. During the time that the upgrade progress information 702 in the upgrade interface 701 reaches 100% from the first scale, the odex file compiled on the target operating system in the electronic device gradually increases until the first number is reached. After that, the flow advances to S107.

In yet another exemplary scenario, after the upgrade installation package is installed, the solution for compiling the application program is restricted for a first duration. In this way, the upgrade progress information 702 is not yet included in the electronic device at the point in time when the first scale is changed, and the odex file compiled on the target operating system. During the period that the upgrade progress information 702 in the upgrade interface 701 reaches 100% from the first scale, the odex file compiled on the target operating system in the electronic device is gradually increased until the upgrade progress information 702 reaches 100%, wherein the time interval between the upgrade progress information 702 from the first scale to the 100% is the first duration. In some embodiments, the electronic device may trigger a restart after the upgrade after the electronic device completes the first number of application optimization compilations, or after the time to optimally compile the application reaches a first time length.

As an implementation, the process of triggering the restart may refer to S107 and S108 in fig. 4.

S107, after the first number of application programs are compiled, the update engine configures the electronic device to restart based on the target operating system.

In some embodiments, the update engine may activate a slot corresponding to the target operating system. The boot sequence of the master boot record (Master Boot Record, MBR) is configured to boot from the target operating system. The boot sequence identification is configured to boot from the target operating system in response to the electronic device completing the optimizing compilation of the first number of first applications.

It can be understood that in the android system adopting the virtual a/B upgrade mode, only the static partition adopts the a/B scheme, and the dynamic partition adopts the scheme of constructing the virtual dynamic partition during upgrade. For matching of the static partition and the dynamic partition, in the Super header information, metadata (/ Super metadata) of the header of the also called a dynamic partition (Super), slot0 of the corresponding static partition (a) and Slot1 of the static partition (B) are contained. Slot0 and Slot1 are used to store the partition table of the Super partition.

For example, slot0 is activated, indicating that the partition table of the corresponding super partition is loaded from Slot 0. And activating Slot1, and indicating loading the partition table of the corresponding super partition from Slot1. Only one of the two is activated during the same period. When the device is started, according to the starting sequence of the MBR, loading the static partition of the target operating system, and then selecting to acquire partition information of the Super partition from the activated slot to realize loading of the Super partition.

After the slot corresponding to the target operating system is activated, the flow proceeds to S108.

S108, an update engine indicates the OUC to trigger the device to restart.

In some embodiments, the current operating system is exited, the device power is turned off, and the device power is turned on again.

After the electronic device is powered up again, the base partition (Common), the static partition (B) are loaded in sequence.

In some embodiments, when the target operating system is the B operating system, during the reboot, the electronic device is changed from booting from the static partition (a) to booting from the static partition (B) in the order of the MBR boot.

For example, after the electronic device is powered up, the electronic device reads the boot sequence identification of the MBR as B, i.e., indicates that the boot sequence has been configured to boot from the B operating system. In this way, the electronic device first loads the base partition (Common). In the process of loading the basic partition (Common), the electronic equipment reads the starting sequence identification of the MBR in the basic partition (Common); upon reading the boot sequence flag as (B), the electronic device may load the static partition (B) to boot from the static partition (B). Then, according to the partition information in slot1, virtual dynamic partitions of the dynamic partition (Super) and the user data partition (Userdata) are loaded.

In some embodiments, after the electronic device is restarted, as shown in fig. 8, the method may further include S201 to S206.

S201, the ART sets the target odex file into a validity state.

It is understood that the target odex file is an odex file compiled based on the target operating system before the target operating system is not enabled. The file name of the target odex file carries the identifier of the target operating system, for example, when the target operating system is the B operating system, the file name includes "B".

In some embodiments, S201 may be: and covering the original odex file corresponding to the target application program by using the target odex file, and enabling the target odex file to be effective. For example, the identification of the target operating system carried by the target odex file is removed. It can be understood that after the identifier of the target operating system is removed, the file name of the target odex file is the same as the file name of the original odex file of the target application program, and the target odex file with the identifier of the target operating system removed is used as a new file, so that the original odex file can be directly covered.

Thus, during the enabling of the target operating system, the electronic device may run the corresponding application based on the validated target odex file.

S202, ART sends a notification 1 to OUC, indicating that the target odex files are all validated.

S203, OUC indicates update Engine to start a landing (merge).

S204, triggering a merge flow by the update engine.

In some embodiments, after a restart, the new system is validated, a merge flow is initiated:

(1) And the electronic equipment is successfully started and enters the user interaction interface.

(2) The electronic device drops the virtual dynamic partition's data in the background to a dynamic partition (Super).

In the description of the present specification, the disk-dropping operation refers to writing, in an operating system upgrade process, a dynamic partition (Super) upgrade file (COW file) stored in a virtual dynamic partition on a user data partition (Userdata) into the dynamic partition (Super).

In some examples, the electronic device performs a boot broadcast after the boot is successful, and starts a process corresponding to the update engine after the boot broadcast. The process corresponding to the update engine reads the disk-dropping state information in the metadata (/ metadata) of the basic partition (Common), and if the disk-dropping state information is "dropped (merge)", the device enters a normal running mode.

And if the landing status information is "no landing for merge", the corresponding process of the update engine drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).

In some embodiments, the process corresponding to the update engine writes the upgrade data in the COW file in the user data partition (Userdata) to the corresponding address in the dynamic partition (Super), so that all the data in the dynamic partition (Super) is the data of the new version after the upgrade.

After that, deleting the COW file in the user data partition (Userdata) by the process corresponding to the update engine, and returning the storage space to the user data partition (Userdata); and, the disk-drop state information in the metadata (/ metadata) of the base partition (Common) is changed from "no disk for merge" to "dropped disk (merge)".

S205, the update engine copies the static partition of the B system to the static partition of the A system.

In some embodiments, S204 is merely an example of a manner of updating the static partition (a), and in embodiments of the present application, other possible implementations may also exist, for example, an update engine may update data in the static partition (a) with a system upgrade package, which is not specifically limited in embodiments of the present application.

S206, update Engine indicates that OUC has completed upgrading.

In some embodiments, a portion of the application is optimally compiled prior to an upgrade restart. After the upgrade is restarted, the compiling of the second number of applications may also be optimized.

Wherein the second number may be a pre-configured value indicating the number of applications that may be compiled after a first restart of the operating system upgrade if the first compiling condition (e.g., referred to as the second condition) is met. Wherein the second number is greater than the first number, e.g., when the first number is 5, the second number is 15.

Illustratively, the first compiling condition is a scene condition that triggers compiling the application. The first compiling condition is different from a scene condition (such as a second compiling condition or a third condition) triggering compiling in the native rule. The triggering probability of the first compiling condition is higher than that of the second compiling condition. In addition, when the electronic device satisfies the second compiling condition, the first compiling condition is also satisfied. Of course, in the case where the first compiling condition is satisfied, the second compiling condition may not be satisfied.

For example, the second compiling condition in the native rule is: the electronic device is in an off-screen state, being charged and the amount of power exceeds 90%. The first compiling condition includes any one of:

1) The electronic device is in an off-screen state and the amount of power exceeds 40% (first value).

2) The electronic device is in an off-screen state and is being charged.

Obviously, the higher the probability that the first compilation condition triggers, compared to the scene condition that triggers compilation in the native rule. In this way, after a restart, the electronic device may complete the optimal compilation of the second number of applications faster.

In some embodiments, the electronic device determines, during satisfaction of the first compilation condition, an application that needs to be compiled, which may also be referred to as an application to be compiled, or a second application.

For example, the application to be compiled may include an application program having a valid odex file. For example, in the case of an application program that has been compiled in the second stage described above and that contains an uncompiled hotspot function, it may also be determined as an application to be compiled (second application).

Also, for example, the application to be compiled may also include an application program whose odex has failed, for example, an application program that has not been compiled in the second stage of the system upgrade, which is not limited thereto.

In some embodiments, the electronic device may continue to determine an activity level for each application to be compiled (second application), and then rank the applications to be compiled by the activity level from high to low. Wherein, the higher the activity level is, the more front the application to be compiled is arranged. And then, optimizing and compiling the application to be compiled according to the arrangement sequence in sequence to obtain the corresponding odex file.

In some embodiments, the electronic device may stop continuing to compile the application if the first compilation condition is no longer satisfied.

And under the scene that the number of the compiled application programs does not reach the second number during the first compiling condition is met, after the first compiling condition is not met and the optimizing compiling is stopped, if the first compiling condition is detected to be met again, optimizing compiling is continuously carried out on the application to be compiled which is not compiled after the upgrading restarting, and the compiling sequence of the application to be compiled is still consistent with the high-low sequence of the activity degree of the application to be compiled.

Or if the first compiling condition is detected to be met again, re-determining the application to be compiled. The application to be compiled may include an application program having a valid odex file, but a hot spot function that is not compiled newly may also include an application program in which the odex file has failed. Then, the applications to be compiled are ordered according to the activity level. In this way, during the period when the first compiling condition is satisfied, optimizing compiling is sequentially performed on the applications to be compiled according to the order.

And stopping continuing to perform optimized compiling if the number of the compiled application programs reaches the second number after the upgrading and restarting is performed during the period of meeting the first compiling condition. Then, the electronic device may continue with the optimized compilation when the second compilation condition is satisfied. In the case where only the first compiling condition is satisfied but the second compiling condition is not satisfied, the optimal compiling is not performed.

In an exemplary scenario, as shown in fig. 9, in the second stage of the system upgrade, the electronic device may complete the optimized compilation of the first number of applications to obtain the corresponding odex file. Under the condition of restarting for the first time after the system is upgraded, the electronic equipment meets the first compiling condition in a first period, and does not meet the first compiling condition before the first period. The electronic device may complete the optimized compilation of the second number of applications within the first period of time.

In the scenario shown in fig. 9, the electronic device does not satisfy the second compiling condition until the second period, and the electronic device satisfies the second compiling condition during the second period. After completing the optimal compilation of the second number of applications, the electronic device may perform the optimal compilation for the applications for a second period of time.

Obviously, the first period is earlier than the second period. In the related art, before the second period, no optimization compiling is performed for the application program, so that the electronic device cannot use the machine code execution mode to run the application program before the second period.

In the embodiment of the present application, after the upgrade is restarted, there is a first number of application programs with valid odex files, that is, when the user indicates that the application program with the valid odex files is enabled, the application program may be executed in a machine code execution manner. After the first period of time, more applications executable with machine code are newly added to the electronic device.

In addition, after the first period, the application program with the valid odex file can already cover most of the user's usage needs. Thereafter, the compiling of the application may also continue for a second period of time. In this way, the compilation for all applications in the electronic device can be completed step by step.

In an exemplary scenario, as shown in fig. 10, in the second stage of the system upgrade, the electronic device may complete the optimized compilation of the first number of applications to obtain the corresponding odex file. And under the condition of restarting for the first time after the system is upgraded, the electronic equipment meets the first compiling condition in a third period, and does not meet the first compiling condition before the third period. In the fourth period, the electronic device also satisfies the first compiling condition. The first compiling condition is not satisfied in a fifth period between the third period and the fourth period. The electronic device completes the optimized compilation of a third number of applications within a third period of time, wherein the third number is less than the second number. The electronic device completes the optimized compiling of the fourth number of application programs in a fourth period, wherein the fourth number is smaller than the second number, and the sum of the third number and the fourth number is equal to the second number. The second compiling condition is not satisfied until a sixth period in which the electronic device satisfies the second compiling condition. The electronic device may perform optimal compilation for the application during the sixth time period.

In an exemplary scenario, as shown in fig. 11, in the second stage of the system upgrade, the electronic device may complete the optimized compilation of the first number of applications to obtain the corresponding odex file. And after the system is upgraded, under the condition of restarting for the first time, in a seventh period, the electronic equipment meets the first compiling condition. The eighth period after the seventh period does not satisfy the first compiling condition. The electronic device completes the optimized compilation of a fifth number of applications within a seventh time period, wherein the fifth number is less than the second number. And then, the electronic equipment is restarted in response to the user operation, and in a ninth period after the restarting, when the first compiling condition is determined to be met but the second compiling condition is not met, the optimal compiling is not carried out. In the tenth period, the electronic device satisfies the second compiling condition. The electronic device may perform optimal compilation for the application during the tenth period.

In other possible scenarios, in the second stage of system upgrade, the electronic device may complete optimized compilation of the first number of applications to obtain the corresponding odex file. After the system is upgraded and restarted, the electronic equipment meets a second compiling condition and starts to optimize compiling for the application program.

In other possible scenarios, the compiled application is not optimized during a system upgrade. And after the system is upgraded, under the condition of restarting for the first time, the electronic equipment completes the optimized compiling of the second number of application programs during the period of meeting the first compiling condition. Then, in the case where the second compiling condition is satisfied, it is necessary to perform optimal compiling for the application program.

The following is a comparative test with device 1 enabled with the method provided by the embodiments of the present application and device 2 not enabled with the method provided by the embodiments of the present application. The same application program is installed in the device 1 and the device 2, the same system resources are provided, and the actually occupied system resources are the same.

The average duration of the cold start of the application in device 1 and device 2 is tested before a system upgrade is performed. For example, the application values in the device 1 and the device 2 are set to be in an un-running state, and then, a time period from clicking the application icon of each application to displaying the first frame data of the application is obtained as a cold start time period of the application. The average value 1 among the cold start time durations of all the application programs in the device 1 is obtained, and the average value 2 among the cold start time durations of all the application programs in the device 2 is obtained. The above average 1 and average 2 are very close.

The average duration of the cold start of the application in device 1 and device 2 is again tested, the first restart after a system upgrade has been made. After the system is upgraded, the average duration of the cold start corresponding to the equipment 1 obtained through testing is an average value 3, and the average duration of the cold start corresponding to the equipment 2 is an average value 4. The above average value 3 is significantly smaller than the average value 4. After a system upgrade, the average cold start time of device 1 is reduced by about 20 percent compared to device 2.

After the system is upgraded, the first restart is performed, the test is performed on the device 1 and the device 2 respectively, and the response condition of each device is performed in the process of sliding on the application interface of the hot spot application. The probability of occurrence of the jamming is lower in the device 1 compared with the device 2, the average duration of the jamming is shorter, and the average jamming time of hundred sliding is shorter.

The embodiment of the application also provides an electronic device, which may include: a memory and one or more processors. The memory is coupled to the processor. The memory is for storing computer program code, the computer program code comprising computer instructions. The computer instructions, when executed by the processor, cause the electronic device to perform the steps performed by the handset in the embodiments described above. Of course, the electronic device includes, but is not limited to, the memory and the one or more processors described above.

The embodiment of the application also provides a chip system, which can be applied to the electronic equipment in the previous embodiment. The system-on-chip includes at least one processor and at least one interface circuit. The processor may be a processor in an electronic device as described above. The processors and interface circuits may be interconnected by wires. The processor may receive and execute computer instructions from the memory of the electronic device via the interface circuit. The computer instructions, when executed by the processor, may cause the electronic device to perform the steps performed by the handset in the embodiments described above. Of course, the chip system may also include other discrete devices, which are not specifically limited in this embodiment of the present application.

In some embodiments, it will be clearly understood by those skilled in the art from the foregoing description of the embodiments, for convenience and brevity of description, only the division of the above functional modules is illustrated, and in practical application, the above functional allocation may be implemented by different functional modules, that is, the internal structure of the apparatus is divided into different functional modules to implement all or part of the functions described above. The specific working processes of the above-described systems, devices and units may refer to the corresponding processes in the foregoing method embodiments, which are not described herein.

The functional units in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: flash memory, removable hard disk, read-only memory, random access memory, magnetic or optical disk, and the like.

The foregoing is merely a specific implementation of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the embodiments of the present application should be covered by the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims

1. An application program optimizing method is characterized by being applied to electronic equipment, wherein an operating system of the electronic equipment comprises a first operating system and a second operating system; after the electronic device runs on the first operating system, the method comprises the following steps:

the electronic equipment acquires an upgrade installation package for upgrading an operating system;

upgrade data analyzed from the upgrade installation package;

writing the upgrade data in a first storage partition, wherein the first storage partition comprises a static partition occupied by the second operating system in a memory of the electronic device and a virtual dynamic partition;

responding to the update data written into the first storage partition, and optimizing and compiling a first number of first applications based on the second operating system before the update is restarted to obtain corresponding optimized executable odex files, wherein the first number is smaller than the total number of application programs in the electronic equipment;

The electronic device is restarted.

2. The method of claim 1, wherein optimizing compiling the first number of first applications based on the second operating system comprises:

starting a virtual machine corresponding to the second operating system;

and optimizing and compiling a first number of first applications through a compiler in a virtual machine of the second operating system.

3. The method according to claim 1, wherein the method further comprises:

responsive to the electronic device completing optimizing compilation of the first number of the first applications, configuring a boot sequence identification to boot from the second operating system;

the electronic device reboots, comprising: and after the power-on is restarted, loading the data in the first storage partition according to the starting sequence identification, so that the electronic equipment runs in the second operating system.

4. A method according to any one of claim 1 to 3, wherein,

the first number is a preset value; or,

the first number is a number of applications that the electronic device optimizes compilation within a first time period, the first time period being preconfigured.

5. A method according to any one of claims 1-3, wherein the first application is an application meeting a first condition; the first condition includes a combination of one or more of:

The first application is an application program with the activity level of the application program of the electronic equipment arranged in the front N bits from high to low, wherein N is a positive integer, and the activity level is the activity level of the application estimated according to the application running record and the application downloading amount;

the first application belongs to a first set, which is a set of applications providing a specified type of service.

6. The method of claim 5, wherein the electronic device optimizing compiling the first number of first applications comprises:

according to the activity level of the first application, compiling the first application in sequence from high to low until a cut-off condition is met;

the cut-off condition is that the number of the compiled first applications reaches the preset first number, or the cut-off condition is that the time for optimizing the compiling reaches the preset first duration.

7. A method according to any of claims 1-3, wherein after the electronic device is restarted, the method further comprises:

optimizing compiling a second number of second applications if the second condition is satisfied; the second application comprises an application program without a valid odex file and an application program with a valid odex file and an uncompiled hot spot function; the probability that the electronic equipment meets the second condition is higher than the probability that the electronic equipment meets the third condition, wherein the third condition is a scene condition of a self-contained trigger optimization compiling application program in an operating system of the electronic equipment.

8. The method of claim 7, wherein the second number is preconfigured, the second number being greater than the first number.

9. The method of claim 7, wherein the method further comprises:

suspending optimizing the compiling application program under the condition that the second condition is met and the second application of optimizing the compiling reaches a second number;

and continuing to optimize the compiling application program under the condition that the third condition is met.

10. The method of claim 7, wherein the second condition comprises a combination between one or more of: in a screen-off state; is in a charged state; the actual electric quantity is larger than the first value;

the third condition is that the electronic equipment is in the screen-off state, in the charging state and the actual electric quantity is larger than a second value; the second value is greater than the first value.

11. A method of application optimization, the method comprising:

after the upgrade is completed by using the upgrade installation package, restarting the electronic equipment;

in response to the first restart after the upgrade, optimizing compiling a second number of second applications if a second condition is satisfied; the second application comprises an application program without a valid odex file and an application program with a valid odex file and an uncompiled hot spot function, wherein the hot spot function is a function recorded in a configuration file of the application program; the probability that the electronic equipment meets the second condition is higher than the probability that the electronic equipment meets the third condition, wherein the third condition is a scene condition of a self-contained trigger optimization compiling application program in an operating system of the electronic equipment;

12. An electronic device, the electronic device comprising: a processor and a memory for storing computer instructions which, when executed by the processor, cause the electronic device to perform the method of any of claims 1-11.

13. A computer readable storage medium, characterized in that the computer readable storage medium comprises a computer program or instructions which, when run on a computer, cause the computer to perform the method of any of claims 1-11.