Application program optimization method and electronic equipment

Abstract

The embodiment of the invention provides an application program optimization method and electronic equipment, and relates to the technical field of computers. The problem that after upgrading and restarting, all application programs cannot be executed through machine codes within a long time is solved. According to the specific scheme, a first operating system runs; an upgrade installation package is obtained, and the upgrade installation package is used for upgrading the operating system; the operation system upgrading comprises the steps that an upgrading installation package is installed, a first number of first applications are optimized and compiled, and the first number is smaller than the total number of the application programs; and in response to completion of optimized compiling of the first number of first applications, triggering restart.

Description

[0001] This application is a divisional application of the invention patent application with application number 202310930634.6 submitted to the State Intellectual Property Office of China, application date July 27, 2023, and invention name “An application optimization method and electronic device”. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to an application optimization method and electronic device. Background Art

[0003] When an electronic device runs an application, it needs to execute the code corresponding to the application. Among the optional code execution methods, machine code execution is the most efficient code execution method.

[0004] However, after each system upgrade of an electronic device, all applications cannot enable machine code execution for a long period of time, resulting in poor code execution efficiency of the application and affecting the running speed of the application. Summary of the invention

[0005] In view of this, the present application provides an application optimization method and an electronic device to improve the code execution efficiency of the application after the system is upgraded.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, an embodiment of the present application provides an application optimization method, the method comprising: an electronic device obtaining an upgrade installation package for upgrading an operating system; the electronic device installing the upgrade installation package; in response to completion of the installation of the upgrade installation package, the electronic device optimizing and compiling a first number of first applications to obtain corresponding optimized executable odex files, the first number being less than the total number of applications in the electronic device, and the electronic device restarting.

[0008] The odex file includes the binary code corresponding to the application. Only when the application has the odex file can the application be run in a machine execution mode.

[0009] In the above embodiment, after the upgrade data package is installed and before the device is restarted, some applications (the first number of applications) are first compiled to obtain corresponding odex files. In this way, after the upgrade and restart, the first number of applications in the electronic device can be executed in machine code, and after the upgrade and restart, the average code execution efficiency of the applications in the electronic device is reduced.

[0010] In addition, compiling some applications can avoid adding more upgrade waiting time compared to compiling all applications.

[0011] In some embodiments, the operating system of the electronic device includes a first operating system and a second operating system; the electronic device runs on the first operating system, and the electronic device installs the upgrade installation package, including: upgrade data parsed from the upgrade installation package; writing the upgrade data in a first storage partition, the first storage partition including a static partition occupied by the second operating system in the memory of the electronic device, and a virtual dynamic partition; in response to the installation of the upgrade installation package being completed, the electronic device optimizes and compiles a first number of first applications, including: in response to the upgrade data having been written to the first storage partition, optimizing and compiling the first number of first applications based on the second operating system.

[0012] In the above embodiment, during the operation of the first operating system, not only the second operating system can be upgraded, but also the first number of first applications can be optimized and compiled based on the upgraded second operating system. In this way, the upgrade of the second operating system and the optimized compilation after the upgrade are completed without affecting the normal use of the electronic device by the user. This avoids that after the upgrade and restart, all applications cannot be run in the machine code execution mode.

[0013] It is understandable that the above upgrade process can be called a virtual A / B upgrade. In the process of a virtual A / B upgrade, after the second operating system is upgraded 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 on the upgraded operating system.

[0014] In the embodiment of the present application, before the electronic device switches the operating system, that is, when the electronic device is running in the first operating system, the system data corresponding to the first operating system is unchanged, so that the odex file compiled based on the first operating system before the upgrade is still valid. In this way, before the electronic device switches to the second operating system, the electronic device can run various applications in a machine code execution manner.

[0015] In addition, when the electronic device is running on the first operating system, after the system data of the second operating system is updated, the electronic device will compile the first number of application programs based on the updated second operating system to obtain the first number of odex files, and the first number of odex files can be used when running the new version of the operating system. In this way, after the electronic device switches the operating system, the first number of first applications can still be run in a machine code execution manner.

[0016] Obviously, before the electronic device enables the new version of the operating system, the electronic device can run the application program in a machine code execution manner. After the electronic device enables the new version of the operating system, the electronic device can also run part of the application program (the first number of first applications) in a machine code execution manner. The code execution efficiency of the application program is ensured during the operation of the electronic device.

[0017] In some embodiments, optimizing and compiling a 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 the first number of first applications through a compiler in the virtual machine of the second operating system.

[0018] In some embodiments, the method also includes: in response to the electronic device completing the optimized compilation of the first number of the first applications, configuring the boot sequence identifier to start from the second operating system; the electronic device restarts, including: after restarting and powering on, loading the data in the first storage partition according to the boot sequence identifier, so that the electronic device runs on the second operating system.

[0019] In the above embodiment, the process of modifying the startup sequence identifier is configured after the first application is compiled, which can avoid the problem that the operating system cannot be switched normally after the upgrade.

[0020] In some embodiments, the first number is a preset value. In the above embodiments, the electronic device controls the time that the user waits for the upgrade and restart within a reasonable range by limiting the number of compiled applications.

[0021] In some embodiments, the first number is the number of applications optimized and compiled by the electronic device within a first time period, and the first time period is preconfigured. In the above embodiments, the electronic device controls the time the user waits for the upgrade and restart within a reasonable range by limiting the compilation time.

[0022] 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 following: the first application is an application ranked in the top N positions in terms of activity level among the applications of the electronic device, where N is a positive integer, and the activity level is the activity level of the application evaluated based on the application running record and the application download volume; the first application belongs to a first set, which is a set of applications that provide specified types of services.

[0023] In the above embodiment, it is ensured that after the upgrade and restart, the user's frequently used applications (for example, applications ranked in the top N in terms of activity level) or applications with more important uses (for example, providing specified types of services) can be run in the form of machine code execution to cover the user's main usage needs.

[0024] In some embodiments, the electronic device optimizes the compilation of a first number of first applications, including: compiling the first applications in order from high to low according to the activity levels of the first applications until a cutoff condition is met; the cutoff condition is that the number of the compiled first applications reaches a preset first number, or the cutoff condition is that the time for optimized compilation reaches a preset first duration.

[0025] In some embodiments, after the electronic device is restarted, the method further includes: optimizing and compiling a second number of second applications when a second condition is met; the second applications include applications without valid odex files and applications with valid odex files and uncompiled hotspot functions; the probability that the electronic device meets the second condition is higher than the probability that the electronic device meets the third condition, and the third condition is a scenario condition in the operating system of the electronic device that triggers the optimized compilation of applications.

[0026] It is understandable that after the upgrade and restart, the electronic device needs to meet the third condition before it can continue to compile applications that do not contain valid odex files, or perhaps applications that add hotspot functions. Usually, the third condition is not easy to meet, so after the restart, the above application needs to wait for a long time before it can be compiled. During the waiting period, the code execution efficiency of the above application is very low.

[0027] In the above embodiment, after the upgrade and restart, by lowering the scenario conditions that trigger the compilation, that is, enabling the second condition that is easier to meet instead of the native third condition, the time that the application in the electronic device waits for compilation can be shortened, thereby further improving the code execution efficiency of the application in the electronic device.

[0028] In some embodiments, the second number is preconfigured and is greater than the first number.

[0029] In some embodiments, when the second condition is met, optimizing the compilation of the second number of second applications may include: compiling each second application in order from high to low according to the activity level of the second application.

[0030] In some embodiments, when the second condition is met and the number of optimized compiled second applications reaches a second number, the optimized compiled application is suspended; when the third condition is met, the optimized compiled application continues.

[0031] In the above embodiment, compatibility with native compilation scenario conditions is achieved, and in the process of completing the compilation of all application programs in the device, the impact on the user's actual use of the electronic device is reduced.

[0032] In some embodiments, the second condition includes a combination of one or more of the following: being in a screen-off state; being in a charging state; an actual power level greater than a first value; the third condition is that the electronic device is in the screen-off state, in the above-mentioned charging state and the actual power level greater than a second value; the second value is greater than the first value.

[0033] In a second aspect, an embodiment of the present application provides an application optimization method, the method comprising: an electronic device obtains an upgrade installation package for upgrading an operating system; after completing the upgrade using the upgrade installation package, the electronic device restarts; in response to the first restart after the upgrade, optimizing and compiling a second number of second applications if a second condition is met; the second applications include applications without valid odex files, and applications with valid odex files and uncompiled hotspot functions, wherein the hotspot functions are functions recorded in a configuration file of the application; the probability that the electronic device meets the second condition is higher than the probability that the electronic device meets the third condition, and the third condition is a scenario condition in the operating system of the electronic device that triggers the optimization and compilation of applications.

[0034] In the above embodiment, after the upgrade and restart, by reducing the scenario conditions that trigger the compilation of the application, for example, enabling the second condition that is easier to meet instead of the native third condition, the time that the application in the electronic device waits to be compiled can be shortened, thereby improving the code execution efficiency of the application in the electronic device.

[0035] In some embodiments, the method further includes: pausing the optimization compilation of the application program when the second condition is met and the second optimized compiled application program reaches a second number; and continuing the optimization compilation of the application program when the third condition is met.

[0036] In some embodiments, when the second condition is met, optimizing the compilation of the second number of second applications may include: compiling each second application in order from high to low according to the activity level of the second application.

[0037] In some embodiments, before the electronic device is restarted, the method also includes: in response to the installation of the upgrade installation package being completed, the electronic device optimizes and compiles a first number of first applications to obtain corresponding optimized executable odex files, and the first number is less than the total number of application programs in the electronic device.

[0038] In some embodiments, the operating system of the electronic device includes a first operating system and a second operating system; the electronic device runs on the first operating system, and the electronic device installs the upgrade installation package, including: upgrade data parsed from the upgrade installation package; writing the upgrade data in a first storage partition, the first storage partition including a static partition occupied by the second operating system in the memory of the electronic device, and a virtual dynamic partition; in response to the installation of the upgrade installation package being completed, the electronic device optimizes and compiles a first number of first applications, including: in response to the upgrade data having been written to the first storage partition, optimizing and compiling the first number of first applications based on the second operating system.

[0039] In some embodiments, the first number is a preset value. Alternatively, the first number is the number of applications optimized and compiled by the electronic device within a first time period, and the first time period is preconfigured.

[0040] In some embodiments, the first application is an application that satisfies the first condition. The first condition includes a combination of one or more of the following: the first application is an application ranked in the top N positions in terms of activity level from high to low among the applications of the electronic device, where N is a positive integer. The activity level is the activity level of the application evaluated based on the application running record and the application download volume; the first application belongs to a first set, which is a set consisting of applications that provide a specified type of service.

[0041] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising one or more processors and a memory; the processor comprises a modem processor, the memory is coupled to the processor, the memory is used to store computer program code, the computer program code comprises computer instructions, and when one or more processors execute the computer instructions, the one or more processors are used to execute the methods in the first aspect, the second aspect and possible embodiments thereof.

[0042] In a fourth aspect, an embodiment of the present application provides a computer storage medium, comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the methods in the above-mentioned first aspect, second aspect and possible embodiments thereof.

[0043] In a fifth aspect, the present application provides a computer program product. When the computer program product runs on the above-mentioned electronic device, it enables the electronic device to execute the methods in the above-mentioned first aspect, second aspect and possible embodiments thereof.

[0044] In a sixth aspect, the present application provides a chip system, which is applied to an electronic device and stores a computer program. When the computer program is executed, the electronic device executes the methods in the above-mentioned first aspect, second aspect and possible embodiments thereof.

[0045] It can be understood that the electronic devices, computer storage media and computer program products provided in the above-mentioned aspects are all applied to the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 An example diagram of a scenario of optimizing and compiling an application after a system upgrade in the related art;

[0047] Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0048] Figure 3 An example diagram of the software structure of an electronic device provided in an embodiment of the present application;

[0049] Figure 4 One of the step flow charts of an application optimization method provided in an embodiment of the present application;

[0050] Figure 5 This is one of the example diagrams of the scenario of optimizing and compiling the application after the system upgrade in the embodiment of the present application;

[0051] Figure 6 A second flowchart of a method for optimizing an application program provided in an embodiment of the present application;

[0052] Figure 7 This is an example diagram of the system upgrade interface in the embodiment of the present application;

[0053] Figure 8 A flowchart of a method for optimizing an application program provided in an embodiment of the present application;

[0054] Fig. 9 This is a second example diagram of a scenario of optimizing and compiling an application after a system upgrade in an embodiment of the present application;

[0055] Fig.10 This is a third example of a scenario of optimizing and compiling an application after a system upgrade in an embodiment of the present application;

[0056] Fig.11 This is the fourth example diagram of the scenario of optimizing and compiling an application after a system upgrade in an embodiment of the present application. DETAILED DESCRIPTION

[0057] The technical scheme in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. Wherein, in the description of the present application, unless otherwise specified, "at least one" refers to one or more, and "a plurality of" refers to two or more than two. In addition, in order to facilitate the clear description of the technical scheme of the embodiment of the present application, in the embodiment of the present application, the words "first", "second" and the like are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit necessarily different.

[0058] For ease of understanding, the technical terms involved in the embodiments of the present application are first introduced below.

[0059] 1. Application source code: Code data written by the application developer to support the implementation of various application services of the application. The executable (dex) file of the electronic device contains the corresponding source code. When the electronic device downloads the application installation package (android application package, apk) of the application, the dex file containing the source code is written into the data partition of the electronic device along with the application apk.

[0060] When an electronic device runs an application, it needs to execute the source code of the application to provide the corresponding application service to the user. Of course, the source code of the application is code data that cannot be directly recognized by the electronic device. At present, electronic devices mainly use interpreted execution and machine code execution to execute the source code of the application.

[0061] 2. Interpretation and execution: When an electronic device runs an application, it uses an interpreter to interpret the source code into binary code that the electronic device can recognize, and then executes the binary code. In this way, when running an application, the electronic device interprets a sentence of source code before executing the corresponding binary code.

[0062] In a scenario where the amount of code in a source file is large, the source code execution efficiency of the application is very low.

[0063] 3. Machine code execution: It can also be called compiled execution, which means translating source code into machine instructions through a compiler, such as translating into binary code that can be directly recognized by electronic devices. Based on the compiled binary code, a corresponding optimized executable (odex) file is generated. When running an application, the electronic device can directly execute the binary code in the odex file corresponding to the application and provide corresponding application services to users.

[0064] The above-mentioned method of compiling source code into machine instructions may include: ahead of time (AOT) compilation and just-in-time (JIT) compilation.

[0065] In the scenario of AOT compilation, the source code of the application is compiled into machine code and the corresponding odex file is generated before the application is executed. This can make the application start faster and have better running performance.

[0066] In the scenario of JIT compilation, during the running of the application, a sentence of source code is interpreted and a corresponding binary code is recorded. After all the source codes are interpreted once, an odex file containing the binary code of all the source codes can be obtained. Of course, after the application stops running, the electronic device will destroy the odex file corresponding to the application. The above two compilation methods have their own advantages and disadvantages. In the embodiments of the present application, the scenario of AOT compilation is mainly described, and the subsequent embodiments may also be referred to as optimizing the compilation of the application.

[0067] Exemplarily, the above odex file may include binary codes of all source codes of the application. Exemplarily, the above odex file may also include binary codes corresponding to hot functions in the source code. The hot functions may be code functions whose call counts are ranked before a specified ranking during the running of the application. Usually, the configuration file of the application may record the hot functions corresponding to the application.

[0068] It can be understood that the binary code in the odex file is an instruction that can be directly recognized by the electronic device. When the electronic device runs the application, the binary code in the odex file is executed faster. In this way, the application responds faster during operation. However, the odex file of the application is not a file that comes with the apk of the application. The electronic device needs to use the application for a period of time before the corresponding odex file can be generated.

[0069] Before the odex file of the application is generated, the electronic device cannot use machine code to execute because there is no odex file of the application in the electronic device. In this scenario, the application can only be run in an interpreted execution mode.

[0070] It can be seen that the prerequisite for enabling machine code execution is to generate the corresponding odex file.

[0071] In addition, the odex file is a file compiled based on the boot class path (BootClassPath) provided by the operating system. The odex file also records the BootClassPath it depends on, as well as the size of the basic file package (for example, jar package (java archive file)) stored in the location indicated by BootClassPath. In this way, when the electronic device executes the odex file, it can call various types of jar packages according to the BootClassPath.

[0072] After the operating system's BootClassPath changes, the odex file will become invalid, causing the electronic device to be unable to continue to enable machine code execution. Usually, after an electronic device upgrades its operating system, the BootClassPath in the electronic device may change, such as the address changes or the size of the jar package in the storage location indicated by the BootClassPath changes.

[0073] Exemplarily, the above operating system upgrade may be an operating system upgrade based on over-the-air download technology.

[0074] 4. Operating system upgrade based on over the air (OTA) technology: refers to the software upgrade of electronic devices through the air interface of mobile communications. The electronic device corresponds to a server for publishing the upgrade installation package of the operating system. The electronic device can obtain the latest upgrade installation package from the server and use the upgrade installation package to upgrade the electronic device.

[0075] During the operating system upgrade process, the electronic device may update the BootClassPath. After the BootClassPath is updated, the odex files of all applications in the electronic device will become invalid.

[0076] In some embodiments, before the electronic device runs an application, it can check whether the application corresponds to an odex file. In the case where it is determined that the application already corresponds to an odex file, it is detected whether the corresponding odex file is valid. For example, the BootClassPath recorded in the odex file is compared with the actual BootClassPath in the operating system. If the addresses are the same and the corresponding jar package sizes are the same, it is determined that the odex file is valid. If the addresses are different or the corresponding jar package sizes are different, it is determined that the odex file is invalid.

[0077] When it is determined that there is an odex file corresponding to the application and the odex file is valid, the electronic device runs the application in a machine code execution manner.

[0078] When it is determined that the application has no corresponding odex file or the odex file is invalid, the electronic device runs the application in an interpreted execution manner.

[0079] In addition, if the application does not have a corresponding odex file (for example, the electronic device has just installed the application), or the odex file of the application has expired (for example, the electronic device updated the BootClassPath during the OTA operating system upgrade process), the electronic device needs to compile the application and generate the corresponding odex file when it is idle and has sufficient power.

[0080] For example, in the system native rules of the electronic device, the condition for determining whether it is idle may be: the display screen is off and charging is in progress. The condition for determining whether the power is sufficient may be: the power of the electronic device is not less than 90% (second value).

[0081] However, as users become more dependent on electronic devices, they use them more frequently and for longer periods of time. It is becoming increasingly difficult to trigger the compilation of applications in native rules. The above-mentioned native rules may be rules that come with the operating system.

[0082] For example, users often continue to use their electronic devices while they are charging. In this way, during charging, the electronic device is not in the screen-off state, and the optimization compilation for the application cannot be triggered. For another example, during the charging process, the user stops charging before the power reaches 90%. In this way, even if the electronic device is off and charging, the optimization compilation for the application cannot be triggered because the power does not reach 90%.

[0083] Exemplary scenarios such as Figure 1As shown, after the electronic device upgrades the operating system according to the upgrade installation package, the upgraded operating system takes effect by restarting the device. The restart process after the upgrade is as follows: the electronic device restarts and powers on. Then, the data (data partition) is mounted. The data partition is the storage area for storing the application apk. After mounting the data partition, the apk can be scanned and optimized accordingly.

[0084] like Figure 1 As shown, in period 1, the electronic device can perform corresponding optimization processing on system applications and third-party applications. Among them, system applications refer to applications or services that come with the operating system, and third-party applications refer to applications developed by a third party.

[0085] Exemplarily, during the restart process after the upgrade, the electronic device displays an interface indicating application optimization, and then classifies and optimizes the application programs in the electronic device in different ways. For example, the system application is processed in a speed-profile mode: the executable file (dex) in the system application is verified, and then the hot function methods listed in the configuration file of the system application are translated in advance.

[0086] For another example, third-party applications are processed in the verification mode: only the dex files of the third-party applications are verified.

[0087] After turning on the device, the user uses the electronic device in period 2. In period 2, it is difficult to simultaneously meet the scenario conditions for triggering compilation indicated in the native rule. For example, the scenario conditions for triggering compilation in the above native rule may be "screen off", "charging" and "remaining power is not less than 90%" at the same time.

[0088] This not only increases the duration of the first restart after the upgrade, but also third-party applications frequently used by users have a chance to generate corresponding odex files only after period 2, resulting in low operating efficiency of third-party applications when users use them during period 2.

[0089] According to actual statistics, after an electronic device performs an OTA operating system upgrade, it takes about 2 to 3 days for the odex file of the application in the electronic device to be regenerated. However, during these 2 to 3 days, the electronic device can only run the application in an interpreted execution mode or a JIT compilation mode. In this way, the code execution efficiency of the application is very low during the entire operation cycle, and the corresponding response speed is also slow, which greatly affects the human-computer interaction efficiency of the electronic device.

[0090] In order to improve the above problems, an embodiment of the present application provides an application optimization method, which can be applied to electronic devices. Among them, the electronic device can compile some applications before upgrading and restarting, generate odex files of some applications, and save them. In this way, after the OTA operating system upgrade is completed, the electronic device can still run the part of the application in a machine code execution manner.

[0091] In some embodiments, before the upgrade and restart, the compiled application may be a hot application in the electronic device. It is understandable that the hot application may be an application with a high activity ranking in the electronic device. In this way, before the odex files of all applications are generated, the user's use needs for the electronic device can be met.

[0092] Exemplarily, 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 (PDA), a media player, etc. The embodiments of the present application do not impose any special restrictions on the specific form of the electronic device.

[0093] Please refer to Figure 2 , Figure 2 A possible hardware structure diagram of an electronic device is shown:

[0094] like Figure 2 As shown, the electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0095] Among them, the above-mentioned sensor module 180 may include sensors such as pressure sensor, gyroscope sensor, air pressure sensor, magnetic sensor, acceleration sensor, distance sensor, proximity light sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor and bone conduction sensor.

[0096] It is to be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0097] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0098] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0099] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

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

[0101] It is understandable that the interface connection relationship between the modules shown in this embodiment is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

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

[0103] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc.

[0104] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0105] ISP is used to process the data fed back by camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element (image sensor) through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0106] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, and then passes the electrical signal to the ISP for conversion 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 other format. In some embodiments, the electronic device 100 may include N cameras 193, where N is a positive integer greater than 1.

[0107] The digital signal processor is used to process digital signals, and can process not only digital image signals but also other digital signals. For example, when the electronic device 100 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.

[0108] Video codecs are used to compress or decompress digital videos. The electronic device 100 may support one or more video codecs. Thus, the electronic device 100 may play or record videos in a variety of coding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0109] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of electronic device 100 can be realized, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0110] The software system of the electronic device can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to illustrate the software structure of the electronic device.

[0111] Figure 3 It is a software structure block diagram of the electronic device according to an embodiment of the present application.

[0112] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the operating system of the electronic device can be divided into multiple layers, from top to bottom, namely, the application layer, the application framework layer, the Android runtime (ART) and the system library, and the kernel layer.

[0113] The application layer can include a series of application packages.

[0114] like Figure 3 As shown, the application layer can be installed with online update client (OUC), chat application, payment application, music application, video application, game application, browser, etc. Of course, the application layer also includes Figure 3 Applications not shown in the figure include calls, memos, contacts, camera, gallery, calendar, map, Bluetooth, etc.

[0115] The OUC is used to obtain the latest upgrade installation package from the server that serves the upgrade installation package.

[0116] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0117] like Figure 3 As shown, the application framework layer may include an update engine, a compilation optimization service module (dexopt service), an OTA upgrade management service (ota preopt service), etc. Of course, it may also include Figure 3 Services and modules not shown, such as window manager, resource manager, view system, etc.

[0118] Exemplarily, the update engine is used to drive the upgrade of the operating system.

[0119] Exemplarily, the compilation optimization service module is used to determine the application programs that need to be compiled and the compilation order between the application programs. For example, hot applications can be determined as the application programs that need to be compiled.

[0120] Exemplarily, the above OTA upgrade management service is used to manage matters related to operating system upgrades. Taking an electronic device using a virtual A / B operating system as an example, the target operating system to be upgraded can be determined. For example, the electronic device runs based on the A operating system, and the target operating system to be upgraded is the B operating system.

[0121] like Figure 3 As shown, the system library can include multiple functional modules. For example: layer integrator (SurfaceFlinger), media library (Media Libraries), 3D graphics processing library (for example: OpenGL ES), 2D graphics engine (for example: SGL), etc. SurfaceFlinger is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc. The 2D graphics engine is a drawing engine for 2D drawing.

[0122] Android Runtime includes core libraries and virtual machines. Android runtime is responsible for the scheduling and management of the Android system. The virtual machine of the above Android Runtime runs encoder (dalvik excutable file to optimized art file, dex2oat) and optimization compilation (dexopt) modules. Among them, dexopt can be used to convert the dex file containing source code into an odex file containing binary code. For example, dexopt can call dex2oat to translate the source code of the application, and generate the odex file corresponding to the application according to the translation result of dex2oat.

[0123] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0124] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0125] The kernel layer is a layer between hardware and software. The kernel layer at least includes a camera driver, an audio driver, a sensor driver, etc., and the present application embodiment does not impose any restrictions on this.

[0126] The following is an introduction to the implementation details of an application optimization method provided by an embodiment of the present application in conjunction with the accompanying drawings:

[0127] In some embodiments, the developer can store the written upgrade installation package on the server and publish the upgrade installation package through the server. The upgrade installation package is a data package used to upgrade the operating system to the latest version. In some embodiments, the upgrade installation package can be a full upgrade package or an incremental upgrade package, which is not specifically limited in the embodiments of the present application.

[0128] In an embodiment of the present application, in addition to the data for updating the operating system, the above-mentioned upgrade installation package also includes a final installation (PostInstall) file. Among them, the above-mentioned PostInstall file can indicate the process to be executed after the upgrade installation package is installed and verified. The above-mentioned PostInstall file can be the last file executed by the update engine in the process of performing an operating system upgrade according to the upgrade installation package. For example, after installing and verifying the upgrade installation package, the PostInstall file is executed to compile some applications. For another example, when the electronic device enables the virtual A / B operating system, after installing and verifying the upgrade installation package, the PostInstall file is executed to compile some applications in the target operating system, and the electronic device indicated activates the target operating system, wherein the target operating system is the upgraded operating system in the A / B operating system.

[0129] In some embodiments, the electronic device obtains the upgrade installation package and can upgrade the operating system of the electronic device based on the upgrade installation package. As an implementation method, the above process of obtaining the upgrade installation package and installing the upgrade installation package can refer to Figure 4 S101~S104 in:

[0130] S101, the OUC in the electronic device may search and download an upgrade installation package from a server.

[0131] In a feasible implementation scheme, the electronic device can periodically initiate a package search request to the server through the OUC, and the package search request contains the version number of the operating system currently running on the electronic device (for example, version 1.1). The server searches whether there is an upgrade installation package with a newer version number (for example, version 1.2) based on the operating system version number in the package search request. When there is an upgrade installation package of a newer version, the server feeds back the download address of the upgrade installation package (for example, a full upgrade installation package of version 1.2) to the electronic device. The electronic device downloads the upgrade installation package according to the download address.

[0132] In another feasible implementation, the server may also actively push the upgrade installation package of the new version to the electronic device after obtaining it.

[0133] In some embodiments, after the electronic device obtains the upgrade installation package, it has the ability to upgrade the operating system. In some embodiments, the electronic device can automatically upgrade based on the upgrade installation package when idle. In other embodiments, the electronic device can upgrade based on the upgrade installation package in response to the user's upgrade instruction.

[0134] In the embodiments of the present application, Figure 5 As shown, upgrading the operating system of the electronic device may include two stages. In the first stage, the electronic device may install and verify the upgrade installation package. In the second stage, the electronic device may perform AOT compilation on the first number of applications according to the PostInstall file in the upgrade installation package to generate corresponding odex files.

[0135] As an implementation method, OUC can download and save the upgrade installation package to the user data partition (Userdata). Afterwards, OUC instructs the start of the update engine, which executes the first stage of upgrading the operating system, see S102 to S104 for details:

[0136] S102, OUC instructs the update engine to start upgrading the operating system.

[0137] As an implementation method, OUC can set the startup attribute of the update engine by sending an upgrade instruction to the update engine, and set its corresponding startup attribute to true. In addition, the 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 startup attribute of the update engine is true, the servicemanger starts the update engine.

[0138] After that, OUC obtains the status of the update engine through binder communication. After OUC confirms that the update engine has been successfully started, OUC passes the upgrade parameters to the update engine (for example, the upgrade parameters can indicate whether the current upgrade operation is a file update operation or a file storage operation), triggering the update engine to enter the upgrade process.

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

[0140] In some embodiments, the update engine can verify whether the META-INF (ie, digital signature) in the upgrade installation package is legal, and confirm whether the upgrade installation package is a legal upgrade package. For specific implementation details, please refer to the relevant technology, which will not be repeated here.

[0141] After determining that the upgrade installation package passes the inspection, the update engine can parse the upgrade installation package to obtain the upgrade data for updating the operating system. Then, the update engine can write the upgrade data into the storage partition (static partition or dynamic partition, etc.) corresponding to the operating system in the memory.

[0142] Taking the upgrade of an electronic device that enables a virtual A / B operating system, where the electronic device runs on an A operating system as an example, the implementation of the above S103 is as follows:

[0143] S103-1, the update engine reads the saved upgrade installation package from the user data partition (Userdata), and writes the upgrade data for the static partition in the upgrade installation package into the static partition (B) to upgrade the static partition.

[0144] For example, the system upgrade package contains the data of the static partition of version 1.2, that is, the upgrade data for the static partition. After the update engine parses the upgrade installation package, it overwrites the data of the static partition carried in the upgrade installation package (that is, the static partition data of version 1.2) into the static partition (B).

[0145] S103-2, the update engine creates a virtual dynamic partition in the user data partition (Userdata), and writes the data for the dynamic partition in the upgrade data into the virtual dynamic partition.

[0146] For example, the upgrade installation package includes data of the dynamic partition of version 1.2. After the data of the dynamic partition of version 1.2 is parsed from the upgrade installation package, the data of the dynamic partition (Super) of version 1.2 is written into the virtual dynamic partition.

[0147] S104, the update engine performs verification after the upgrade.

[0148] In some embodiments, after installing the upgrade data package, the update engine verifies whether the upgraded B operating system (data in static partition B and virtual dynamic partition) is valid. If valid, it is determined that the installation and verification have been completed, and the PostInstall file in the upgrade installation package is executed.

[0149] In this way, the second stage of the operating system upgrade is entered. In the second stage, the electronic device can optimize and compile the first number of applications to obtain corresponding odex files. Exemplarily, the electronic device can optimize and compile the application in response to installing the upgrade installation package. For example, after executing the aforementioned S101 to S104, in response to passing the verification after the upgrade, the application is optimized and compiled. For another example, after executing S101 to S103, in response to the upgrade data having been written to the first storage partition (such as written to the static partition (B) and the virtual dynamic partition), the application can be optimized and compiled.

[0150] As an implementation method, the process of optimizing compilation can be referred to Figure 4 S105~S106 in:

[0151] S105 , the update engine instructs ART to compile a first number of application programs.

[0152] In some embodiments, a first number may be configured in the PostInstall file. In this way, the update engine may instruct ART to compile the first number of applications through the compiler. For example, the first number may be configured as 5 in the PostInstall file, and the update engine may instruct ART to compile 5 applications in the electronic device through the compiler when executing the PostInstall file. Exemplarily, the above first number may be less than the total number of applications in the electronic device.

[0153] When the electronic device uses a virtual A / B operating system, the application can be optimized and compiled through the ART of the target operating system. In this way, the compiled odex file is generated based on the BootClassPath of the target operating system. After the above optimization compilation, when the electronic device switches from running the original operating system to running the target operating system, the compiled application can be run in the form of machine code execution.

[0154] It can be understood that when the electronic device is running on operating system A (the original operating system, or the first operating system), when upgrading operating system B (the target operating system, or the second operating system), only the data in the storage partition corresponding to operating system B (such as the first storage partition) is updated. For example, the first storage partition includes the static partition of operating system B, as well as the virtual dynamic partition created for operating system B, etc.

[0155] Obviously, the above update will not affect the system data corresponding to the A operating system. In this way, before the electronic device activates the B operating system, the BootClassPath in the A operating system remains unchanged, and the odex file compiled based on the A operating system before the upgrade is still valid. During the operation of the A operating system, the electronic device can run the application in the way of machine code execution.

[0156] After the data in the first storage partition of the B operating system is updated, the BootClassPath in the B operating system changes. In order to ensure that the first number of applications in the B operating system can be executed using machine code after switching to enable the B operating system, the odex files of the first number of applications can be compiled in the B operating system before switching to the B operating system, and the odex files compiled in the B operating system are assigned a target identifier, which is used to distinguish from the original odex file of the application (the odex file compiled based on the A operating system) to avoid the electronic device from mistakenly loading the odex file compiled based on the B operating system during the operation of the A operating system, resulting in machine code execution failure.

[0157] For example, if the target operating system is the B operating system, the file name of the odex file compiled in the ART of the B operating system can carry the identifier of the B operating system, such as the suffix of the file name includes "b" as the corresponding target identifier. In addition, the above is only an example of the target identifier and is not intended to limit the target identifier.

[0158] In other embodiments, a first duration may be configured in the PostInstall file, so that the update engine may instruct ART to compile the applications in sequence through the compiler within the first duration. It is understandable that the number of applications actually compiled within the first duration is the first number. For example, the first duration may be configured as 3 minutes in the PostInstall file, and the update engine executing the PostInstall file may instruct ART to compile the applications in sequence through the compiler, and stop compiling after the compilation time reaches 3 minutes. In this example, if 5 applications are compiled within 3 minutes, the corresponding first number is 5.

[0159] In some embodiments, ART can compile the applications one by one during the process of compiling the first number of applications. During the compilation process, the hotspot functions recorded in the configuration file of the application can be obtained, and then the source code of the hotspot function is translated into binary code, and a corresponding odex file is generated. It can be understood that the hotspot function is related to the activity level (or calling frequency) of each function called in the source code, and is related to the user's habit of using the application and the operating rules of the application. In the process of using the application by the electronic device, the hotspot function in the configuration file can also be updated according to the activity level of the function.

[0160] In some embodiments, the compiled application program may be the first application in the electronic device that satisfies the first condition.

[0161] The first condition may include one or more of the following combinations:

[0162] (1) The first application is an application ranked in the top N positions in terms of activity level among the applications of the electronic device, where N is a positive integer. For example, if N is 5, the first application may be an application ranked in the top 5 in terms of activity level among the applications of the electronic device. The activity level is the activity level of the application evaluated based on the application running records (foreground running, background running, etc.) and the application download volume.

[0163] It is understandable that the activity level of each application in the electronic device can be evaluated based on information such as user usage habits (indicated by application running records) and application download volume. Exemplarily, the user's application running records for each application can be obtained to evaluate the score 1 indicating the usage habits. Then, the application download volume is quantified into score 2. Combining the weights corresponding to the user's usage habits and the application download volume, an activity score is fitted based on score 1 and score 2. Then, the activity level is divided according to the activity score. The higher the activity score, the higher the corresponding activity level, and the lower the activity score, the lower the corresponding activity level. Arranged from high to low according to the activity level, the applications ranked in front are more popular than the applications ranked in the back.

[0164] (2) The first application belongs to a first set, which is a set of application programs that provide a specified type of service.

[0165] Exemplarily, the first set (also referred to as an application set) includes multiple applications, and each application is an application of a preselected type. An application of a preselected type is an application that can provide a specified application service. In addition, there may be one preselected type or multiple preselected types, which is not specifically limited in the embodiments of the present application.

[0166] For example, the pre-selected type of application is an application that provides communication services, and the electronic device is installed with chat applications, payment applications, transportation card applications, short message applications, video applications, work communication applications, etc. In this scenario, the application set (first set) can be a set consisting of chat applications, short message applications, work communication applications, etc.

[0167] Exemplarily, the process of ART compiling the first number of applications may be: 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 turn. In another exemplary embodiment, the process of ART compiling the first number of applications may be: randomly extracting an application from the application set for optimization compilation, after completing the optimization compilation for the application, randomly extracting another unoptimized compiled application from the application set, and continuing to optimize and compile the application until a cutoff condition is met. The cutoff condition may be that the total duration of ART compiling the application reaches a first duration, or the cutoff condition may also be that the total number of ART compiled applications reaches a first number.

[0168] As another example, the process of ART compiling the first number of applications may also include: selecting the 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 applications to be compiled are the top N applications ranked from high to low in terms of activity level among the applications of the electronic device.

[0169] As another example, the process of ART compiling the first number of applications may be: from the applications in the application set, select the application with the highest activity level for optimized compilation. After completing the optimized compilation for one application, select the application with the highest activity level from the unoptimized compiled applications in the application set, and continue to optimize the compilation of the application until the cutoff condition is met. The cutoff condition may be that the total duration of ART compiling the application reaches the first duration, or the cutoff condition may also be that the total number of ART compiled applications reaches the first number.

[0170] Exemplarily, the process of ART compiling the first number of applications may also be: sorting the applications in the electronic device according to the activity level, selecting the first number of applications from the applications ranked in the top N in terms of activity as applications to be compiled, and optimizing and compiling them. Wherein, N is a positive integer. As another example, the process of ART compiling the first number of applications may also be: sorting the applications in the electronic device according to the activity level, selecting the application ranked in the first place for optimization and compilation, and completing the optimization and compilation of one application. Then, according to the activity level, from high to low, rearrange the applications that have not been optimized and compiled, select the application ranked in the first place in terms of activity to continue to optimize and compile, and repeat the above process until the cutoff condition is met. Wherein, the cutoff condition may be that the total duration of ART optimization and compilation of applications reaches the first duration, or the cutoff condition is that the total number of ART optimization and compilation of applications is the first number.

[0171] S106, ART optimizes and compiles the application according to the upgrade compilation script file in the PostInstall file.

[0172] In some embodiments, after running the upgrade compilation script file (otapreopt_script.sh), system components related to ART, such as otachoor-bootrap, com.android.runtime, com.android.art, com.android.sdkext, etc., can be activated in apexd of the target operating system.

[0173] After activating the corresponding system components, ART can achieve optimized compilation for the application based on otapreopt_script.sh.

[0174] As a way to achieve this, Figure 6 As shown, the process of implementing optimized compiled applications is as follows:

[0175] S1, the upgrade compilation script module instructs the compilation optimization service module to perform compilation preparation tasks.

[0176] The upgrade compilation script module may be a software module that occupies system resources after ART runs otapreopt_script.sh. The upgrade compilation script module may run according to the program rules in otapreopt_script.sh to implement the functions indicated by otapreopt_script.sh. For example, it may instruct the compilation optimization service module to initialize, obtain the dexopt command that instructs the compiler to perform compilation optimization from the compilation optimization service module, and other functions.

[0177] In some embodiments, the upgrade compile script module may send a command prompt (command, CMD) to the compile optimization service module to instruct initialization. Afterwards, the upgrade compile script module may call the prepare() function to enter S2.

[0178] S2, the compilation optimization service module determines the application program that needs to be compiled and optimized.

[0179] It can be understood that the compilation preparation task may include determining an application program that needs to be compiled and optimized. The application program that needs to be compiled and optimized may be referred to as an application to be compiled.

[0180] In some embodiments, the upgrade compile script module can instruct the compile optimization service module to determine the application programs that need to be compiled and optimized through the prepare() function. The compile optimization service module determines the applications to be compiled and the compilation sequence between the applications to be compiled in response to the instruction of the upgrade compile script module.

[0181] For example, the application programs ranked in the top N in terms of activity level may be obtained as the applications to be compiled. Then, the order of optimizing the compilation of the applications to be compiled is determined according to the activity level. The higher the activity level, the earlier the compilation order. The lower the activity level, the later the compilation order.

[0182] In another exemplary embodiment, the applications to be compiled are determined from the application set, and the implementation process is referred to the above embodiment, which will not be described here. Then, the optimized compilation order between the applications to be compiled is randomly arranged, or the optimized compilation order between the applications to be compiled is arranged according to the activity level.

[0183] S3, the compilation optimization service module notifies the upgrade compilation script module that the compilation preparation task has been completed.

[0184] In some embodiments, the result callback of the prepare() function can be used to notify the upgrade compilation script module that the compilation preparation task has been completed.

[0185] S4, the upgrade compilation script module sends a request message 1 to the compilation optimization service module.

[0186] The request information 1 is used to request a dexopt command, which can instruct the compiler to perform compilation optimization. Exemplarily, the dexopt command includes information about an application to be compiled, and is used to instruct dexopt to call the compiler to optimize the compilation of the application.

[0187] In some embodiments, the upgrade compilation script module can send the request information 1 to the compilation optimization service module by calling the next() function.

[0188] S5, in response to the request information 1, the compilation optimization service module feeds back to the upgrade compilation script module a target dexopt command indicating the compilation of the target application.

[0189] In some embodiments, when the upgrade compilation script module sends the request information 1 to the compilation optimization service module, the application that is actually not compiled and is ranked first among the to-be-compiled applications is used as the target application. Then, the compilation optimization service module sends the target dexopt command indicating the compilation of the target application to the upgrade compilation script module. The upgrade compilation script module is triggered to start the optimization compilation for the target application, that is, S6 to S13 are executed.

[0190] Exemplarily, before the number of times the request information 1 is sent does not reach the first number, after completing the optimization compilation of the i-1th target application (that is, executing S6 to S13 based on the i-1th target application), the upgrade compilation script module can send the i-th request information 1 to the compilation optimization service module, where i is a positive integer greater than 1. The compilation optimization service module uses the application that is ranked first among the applications to be compiled that have not actually been compiled as the i-th target application.

[0191] In other embodiments, after completing the optimized compilation of the i-1th target application (that is, executing S6 to S13 based on the i-1th target application), if the time interval between the current system time and the sending of the first request information 1 does not exceed the first time length, the request information 1 is sent to the compilation optimization service module again, instructing the optimized compilation of the i-1th target application.

[0192] It can be understood that the first i target applications determined have completed compilation, and the i-th target application is the application ranked first among the applications to be compiled after the first i target applications are removed.

[0193] Afterwards, the upgrade compilation script module executes S6 to S13 based on the i-th target application. Of course, when i is still less than the first number, the upgrade compilation script module can send the i+1-th request information 1 to the compilation optimization service module, repeat the above process, and compile the i+1-th target application.

[0194] S6, the upgrade compilation script module instructs the directory change module (otapreopt_chroot) to run based on the target dexopt command.

[0195] In some embodiments, the upgrade compilation script module may call the otapreopt_chroot() function based on the target dexopt command to enable otapreopt_chroot.

[0196] S7, otapreopt_chroot executes the target dexopt command.

[0197] In some embodiments, the process of executing the target dexopt command may be otapreopt_chroot executing the target dexopt command through the exec() function.

[0198] S8, otapreopt_chroot can call the first tool class (otapreopt_utils).

[0199] In some embodiments, otapreopt_chroot may call otapreopt_utils based on the target application indicated in the target dexopt command during the execution of the target dexopt command.

[0200] S9, otapreopt_utils instructs the second tool class (otapreopt) to determine the compilation preparation information corresponding to the target application.

[0201] In some embodiments, otapreopt_utils may be responsive to the call of otapreopt_chroot, based on the target application, through the fork() function, to instruct otapreopt to determine the compilation preparation information corresponding to the target application. Exemplarily, the above-mentioned compilation preparation information includes the application identifier of the target application (used to determine the object for performing optimized compilation), the storage location of the odex file and other information. Among them, the above-mentioned otapreopt_utils and otapreopt are both compilation-related tool classes that can be enabled after the oat upgrade. The above-mentioned otapreopt_utils can call otapreopt, and otapreopt can obtain preparation information related to compilation.

[0202] S10, otapreopt determines the compilation preparation information corresponding to the target application.

[0203] In some embodiments, otapreopt may call the runpreopt() function to initialize otapreopt and obtain the application identifier of the target application. Then, the open_oat_out_file() function is called to trigger the call of the create_oat_out_path() function. When the create_oat_out_path() function is called, the calculate_oat_file_path() function may be triggered to determine the target storage location for storing the odex file subsequently generated for the target application.

[0204] S11, otapreopt obtains the identifier of the target operating system from the OTA upgrade management service.

[0205] In some embodiments, otapreopt may call the gettargetslot() function to obtain the identifier of the target operating system from the OTA upgrade management service, wherein the target operating system may be an operating system that has been upgraded with data.

[0206] Taking an electronic device with a virtual A / B operating system enabled as an example, when the electronic device runs on the A operating system, otapreopt can call the gettargetslot() function to obtain the identifier of the B operating system (target operating system) from the OTA upgrade management service.

[0207] S12, otapreopt sends compilation preparation information and the identifier of the target operating system to dexopt.

[0208] In some embodiments, otapreopt may pass compilation preparation information and an identifier of the target operating system to dexopt by calling a dexopt() function.

[0209] S13, dexopt calls the compiler to optimize and compile the target application on the target operating system, generate a corresponding target odex file, and store the target odex file in the target storage location.

[0210] In some embodiments, the file name of the target odex file may carry the identifier of the target operating system. For example, if the target operating system is the B operating system, the file name of the target odex file includes "b".

[0211] Take the electronic device with virtual A / B operating system as an example, Figure 7As shown, during the operating system upgrade, the electronic device can display an upgrade interface 701, wherein the upgrade interface 701 is an application interface corresponding to the OUC. In addition, the upgrade interface 701 displays upgrade progress information 702.

[0212] After S103 is executed, the upgrade progress information 702 of the upgrade interface 701 indicates the first ratio. The first ratio is less than 100%, for example, the first ratio is 75%. In addition, during the execution of S1 to S13, each time the compilation of a target application is completed, the OUC is instructed to update the upgrade progress information 702.

[0213] In an exemplary scenario, after installing the upgrade package, a solution is adopted to limit the compilation of a first number of applications. In this way, at the time point when the upgrade progress information 702 changes to the first proportion, the electronic device does not contain odex files compiled on the target operating system. During the period when the upgrade progress information 702 in the upgrade interface 701 reaches 100% from the first proportion, the odex files compiled on the target operating system in the electronic device gradually increase until the first number is reached. After that, the process enters S107.

[0214] In another exemplary scenario, after installing the upgrade installation package, a solution is adopted to limit the compilation of applications within a first time period. In this way, at the time point when the upgrade progress information 702 changes to the first proportion, the electronic device does not yet contain the odex files compiled on the target operating system. During the period when the upgrade progress information 702 in the upgrade interface 701 reaches 100% from the first proportion, the odex files compiled on the target operating system in the electronic device gradually increase until the upgrade progress information 702 reaches 100%, wherein the time interval between the upgrade progress information 702 changing from the first proportion to 100% is the first time period. In some embodiments, after the electronic device completes the optimization compilation of a first number of applications, or after the time for optimizing and compiling applications reaches the first time period, the electronic device can trigger a restart after the upgrade.

[0215] As an implementation method, the process of triggering a restart can be referred to Figure 4 S107 and S108 in.

[0216] S107, after compiling the first number of application programs, the update engine configures the electronic device to restart based on the target operating system.

[0217] In some embodiments, the update engine can activate a slot corresponding to the target operating system. The boot sequence of the master boot record (MBR) is configured to boot from the target operating system. Exemplarily, in response to the electronic device completing the optimization compilation of the first number of first applications, the boot sequence identifier is configured to boot from the target operating system.

[0218] It is understandable that in an Android system that uses a virtual A / B upgrade method, since only the static partition uses the A / B solution, and the dynamic partition uses the solution of constructing a virtual dynamic partition during the upgrade. In order to match the static partition with the dynamic partition, the metadata ( / supermetadata) in the header of the super header information, also known as the dynamic partition (Super), contains Slot0 corresponding to the static partition (A) and Slot1 of the static partition (B). Slot0 and Slot1 are both used to save the partition table of the Super partition.

[0219] For example, activating Slot0 indicates loading the partition table of the corresponding super partition from Slot0. Activating Slot1 indicates loading the partition table of the corresponding super partition from Slot1. Only one of the two is activated at the same time. When the device starts, the static partition of the target operating system is loaded according to the boot sequence of the MBR, and then the partition information of the Super partition is obtained from the activated slot to load the Super partition.

[0220] After the slot corresponding to the target operating system is activated, the process enters S108.

[0221] S108, the update engine instructs the OUC to trigger a device restart.

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

[0223] After the electronic device is powered on again, the basic partition (Common) and the static partition (B) are loaded in sequence.

[0224] In some embodiments, when the target operating system is the B operating system, during the restart process, according to the boot order of the MBR, the electronic device changes from booting from the static partition (A) to booting from the static partition (B).

[0225] For example, after the electronic device is powered on, the electronic device reads the boot sequence identifier of the MBR as B, that is, it indicates that the boot sequence has been configured to start from the B operating system. In this way, the electronic device first loads the basic partition (Common). In the process of loading the basic partition (Common), the electronic device reads the boot sequence identifier of the MBR in the basic partition (Common); when the boot sequence mark is read as (B), the electronic device can load the static partition (B), thereby starting from the static partition (B). Then, according to the partition information in slot1, the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata) are loaded.

[0226] In some embodiments, after the electronic device is restarted, Figure 8 As shown, the above method may further include S201 to S206.

[0227] S201, ART sets the target odex file to a valid state.

[0228] It can be understood that the target odex file is an odex file compiled based on the target operating system before the target operating system is 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".

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

[0230] In this way, during the activation of the target operating system, the electronic device can run the corresponding application based on the effective target odex file.

[0231] S202, ART sends a notification 1 to OUC, indicating that the target odex files have all taken effect.

[0232] S203, OUC instructs the update engine to start the merge.

[0233] S204, the update engine triggers the merge process.

[0234] In some embodiments, after the reboot, the new system takes effect and the merge process is started:

[0235] (1) The electronic device is successfully started and enters the user interaction interface.

[0236] (2) The electronic device stores the data of the virtual dynamic partition to the dynamic partition (Super) in the background.

[0237] In the description of this application specification, the write-to-disk operation refers to writing the dynamic partition (Super) upgrade file (COW file) saved in the virtual dynamic partition on the user data partition (Userdata) into the dynamic partition (Super) during the operating system upgrade process.

[0238] In some examples, the electronic device performs a boot broadcast after successfully starting up, and starts the process corresponding to the update engine after the boot broadcast. The process corresponding to the update engine reads the disk status information in the metadata ( / metadata) of the basic partition (Common), and if the disk status information is "merged", the device enters the normal operation mode.

[0239] If the disk status information is "Not yet flushed (wait for merge)", the corresponding process of the update engine flushes the COW files in the user data partition (Userdata) to the dynamic partition (Super).

[0240] In some embodiments, the process corresponding to the update engine writes the upgraded 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) are the upgraded new version data.

[0241] After that, the corresponding process of the update engine deletes the COW files in the user data partition (Userdata) and returns the storage space to the user data partition (Userdata); and changes the disk status information in the metadata ( / metadata) of the basic partition (Common) from "not yet flushed to disk (wait for merge)" to "already flushed to disk (merged)".

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

[0243] In some embodiments, the above S204 is only an example of a method for updating the static partition (A). In the embodiments of the present application, there may be other possible implementation methods. For example, the update engine can use the system upgrade package to update the data in the static partition (A). The embodiments of the present application do not make specific limitations on this.

[0244] S206, the update engine indicates that the OUC has completed the upgrade.

[0245] In some embodiments, before the upgrade and restart, a portion of the application programs are optimized and compiled. After the upgrade and restart, a second number of application programs may also be optimized and compiled.

[0246] The second number may be a pre-configured value indicating the number of applications that can be compiled after the first restart of the operating system upgrade when the first compilation condition (such as the second condition) is met. The second number is greater than the first number, for example, when the first number is 5, the second number is 15.

[0247] Exemplarily, the first compilation condition is a scenario condition that triggers the compilation of an application. The first compilation condition is different from the scenario condition that triggers compilation in the native rule (such as the second compilation condition, or the third condition). The triggering probability of the first compilation condition is higher than the triggering probability of the second compilation condition. In addition, when the electronic device satisfies the second compilation condition, the first compilation condition is also satisfied. Of course, when the first compilation condition is satisfied, the second compilation condition may not be satisfied.

[0248] For example, the second compilation condition in the native rule is: the electronic device is in the off state, is charging and the power is more than 90%. The first compilation condition includes any of the following:

[0249] 1) The electronic device is in screen-off state and the battery level exceeds 40% (first value).

[0250] 2) The electronic device is in the screen-off state and is charging.

[0251] Obviously, compared with the scenario conditions that trigger compilation in the native rules, the probability of the first compilation condition being triggered is higher. In this way, after restarting, the electronic device can complete the optimization compilation of the second number of applications more quickly.

[0252] In some embodiments, while the first compilation condition is met, the electronic device determines an application program that needs to be compiled, which may also be referred to as an application to be compiled, or a second application.

[0253] Exemplarily, the application to be compiled may include an application with a valid odex file. For example, an application that has been compiled in the second stage and contains an uncompiled hotspot function may also be determined as an application to be compiled (second application).

[0254] As another example, the above-mentioned application to be compiled may also include an application whose odex has expired, for example, an application that has not been compiled in the above-mentioned second stage of the system upgrade, which is not limited to this.

[0255] In some embodiments, the electronic device may continue to determine the activity level of each application to be compiled (second application), and then sort the applications to be compiled from high to low according to the activity level. The applications to be compiled with higher activity levels are ranked at the front. Then, the applications to be compiled are optimized and compiled in sequence according to the ranking order to obtain corresponding odex files.

[0256] In some embodiments, when the electronic device no longer meets the first compilation condition, it can stop compiling the application.

[0257] In a scenario where the number of compiled applications has not reached the second number while the first compilation condition is met, after determining that the first compilation condition is not met and stopping the optimization compilation, if it is detected again that the first compilation condition is met, continue to optimize and compile the applications to be compiled that have not been compiled after the upgrade and restart, and the compilation order of the applications to be compiled is still consistent with the order of their activity levels.

[0258] Alternatively, if it is detected that the first compilation condition is met again, the application to be compiled is re-determined. The application to be compiled may include an application with a valid odex file but with newly added hotspot functions that have not been compiled, or an application with an invalid odex file. Then, the applications to be compiled are sorted according to the activity level. In this way, while the first compilation condition is met, the applications to be compiled are optimized and compiled in sequence according to the sorting.

[0259] During the period when the first compilation condition is met, if the number of applications compiled after the upgrade and restart reaches the second number, the optimization compilation is stopped. After that, the electronic device can continue to perform the optimization compilation when the second compilation condition is met. When only the first compilation condition is met but the second compilation condition is not met, the optimization compilation is not performed.

[0260] Exemplary scenarios such as Fig. 9As shown, in the second stage of the system upgrade, the electronic device can complete the optimization compilation of the first number of applications and obtain the corresponding odex files. After the system upgrade, in the case of the first restart, in the first period of time, the electronic device meets the first compilation condition, and before the first period of time, the electronic device does not meet the first compilation condition. The electronic device can complete the optimization compilation of the second number of applications in the first period of time.

[0261] like Fig. 9 In the illustrated scenario, before the second period, the electronic device does not meet the second compilation condition, and during the second period, the electronic device meets the second compilation condition. After completing the optimization compilation of the second number of applications, the electronic device can perform optimization compilation on the applications during the second period.

[0262] Obviously, the first period is earlier than the second period. In the related art, before the second period, no optimization compilation is performed for the application program, so that the electronic device cannot run the application program in a machine code execution manner before the second period.

[0263] In the embodiment of the present application, after the upgrade and restart, there are a first number of applications with valid odex files, that is, when the user instructs to enable the application with a valid odex file, the application can be run in a machine code execution manner. After the first period, more applications that can be executed in machine code will be added to the electronic device.

[0264] In addition, after the first period, the applications with valid odex files can already cover most of the user's usage needs. Afterwards, in the second period, the application can continue to be compiled. In this way, the compilation of all the applications in the electronic device can be gradually completed.

[0265] Exemplary scenarios such as Fig.10 As shown, in the second stage of the system upgrade, the electronic device can complete the optimization compilation of the first number of applications and obtain the corresponding odex file. After the system upgrade, in the case of the first restart, in the third time period, the electronic device meets the first compilation condition, and before the third time period, the first compilation condition is not met. In the fourth time period, the electronic device also meets the first compilation condition. In the fifth time period between the third time period and the fourth time period, the first compilation condition is not satisfied. The electronic device completes the optimization compilation of the third number of applications in the third time period, wherein the third number is less than the second number. The electronic device completes the optimization compilation of the fourth number of applications in the fourth time period, wherein the fourth number is less than the second number, and the sum of the third number and the fourth number is equal to the second number. The second compilation condition is not met before the sixth time period, and in the sixth time period, the electronic device meets the second compilation condition. The electronic device can perform optimization compilation on the application in the sixth time period.

[0266] Exemplary scenarios such as Fig.11 As shown, in the second stage of the system upgrade, the electronic device can complete the optimization compilation of the first number of applications and obtain the corresponding odex file. After the system upgrade, in the case of the first restart, in the seventh time period, the electronic device meets the first compilation condition. In the eighth time period after the seventh time period, the first compilation condition is not met. The electronic device completes the optimization compilation of the fifth number of applications in the seventh time period, wherein the fifth number is less than the second number. Afterwards, the electronic device restarts in response to the user operation, and after the restart, in the ninth time period, when it is determined that the first compilation condition is met, but the second compilation condition is not met, the optimization compilation is not performed. In the tenth time period, the electronic device meets the second compilation condition. The electronic device can perform optimization compilation on the application in the tenth time period.

[0267] In other possible scenarios, in the second stage of the system upgrade, the electronic device can complete the optimization compilation of the first number of application programs and obtain corresponding odex files. After the system upgrade is restarted, the electronic device meets the second compilation condition and starts to optimize the application programs.

[0268] In other possible scenarios, the application programs are not optimized and compiled during the system upgrade process. After the system upgrade, when the electronic device is restarted for the first time, the second number of application programs are optimized and compiled while the first compilation condition is met. Afterwards, the application programs need to be optimized and compiled while the second compilation condition is met.

[0269] The following is a comparative test between device 1 that uses the method provided in the embodiment of the present application and device 2 that does not use the method provided in the embodiment of the present application. The same application is installed in device 1 and device 2, and they have the same system resources and actually occupy the same amount of system resources.

[0270] Before the system upgrade, test the average cold start duration of applications in device 1 and device 2. For example, set the application values ​​in device 1 and device 2 to not running, and then obtain the duration between clicking the application icon of each application and displaying the first frame data of the application as the cold start duration of the application. Obtain the average value 1 of the cold start duration of all applications in device 1, and obtain the average value 2 of the cold start duration of all applications in device 2. The above average values ​​1 and 2 are very close.

[0271] During the first restart after the system upgrade, the average cold start duration of the applications in device 1 and device 2 was tested again. After the system upgrade, the average cold start duration of device 1 obtained by the test was 3, and the average cold start duration of device 2 was 4. The above average value 3 is significantly smaller than the average value 4. After the system upgrade, the average cold start duration of device 1 is shortened by about 20% compared with that of device 2.

[0272] During the first restart after the system upgrade, the response of each device was tested on device 1 and device 2 during the sliding process on the application interface of the hot application. Compared with device 2, device 1 had a lower probability of freezing, a shorter average freezing time, and a shorter average freezing time per 100 sliding.

[0273] The embodiment of the present 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 used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device can execute the various steps executed by the mobile phone in the above embodiment. Of course, the electronic device includes but is not limited to the above memory and one or more processors.

[0274] The embodiment of the present application also provides a chip system, which can be applied to the electronic device in the aforementioned embodiment. The chip system includes at least one processor and at least one interface circuit. The processor can be the processor in the above-mentioned electronic device. The processor and the interface circuit can be interconnected through a line. The processor can receive and execute computer instructions from the memory of the above-mentioned electronic device through the interface circuit. When the computer instructions are executed by the processor, the electronic device can execute the various steps executed by the mobile phone in the above-mentioned embodiment. Of course, the chip system can also include other discrete devices, which are not specifically limited in the embodiment of the present application.

[0275] In some embodiments, through the description of the above implementation methods, technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0276] Each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0277] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as flash memory, mobile hard disk, read-only memory, random access memory, disk or optical disk.

[0278] The above is only a specific implementation of the embodiment of the present application, but the protection scope of the embodiment of the present application is not limited thereto, and any changes or replacements within the technical scope disclosed in the embodiment of the present application should be included in the protection scope of the embodiment of the present application. Therefore, the protection scope of the embodiment of the present application should be based on the protection scope of the claims.

Claims

1. An application optimization method, characterized in that: Applied to electronic equipment, the method comprises: running a first operating system; Obtaining an upgrade installation package, wherein the upgrade installation package is used to upgrade the operating system; Upgrading the operating system includes: installing the upgrade installation package, optimizing and compiling a first number of first applications, wherein the first number is less than the total number of application programs; In response to completion of the optimization compilation of the first number of first applications, restart is triggered.

2. The method according to claim 1, characterized in that After the restart is triggered, the method further includes: running a second operating system.

3. The method according to claim 1, characterized in that The step of installing the upgrade installation package comprises: Parsing upgrade data from the upgrade installation package; The upgrade data is written into a first storage partition, where the first storage partition includes a static partition occupied by the second operating system in the memory and a virtual dynamic partition.

4. The method according to claim 3, characterized in that: The optimizing and compiling the first number of first applications includes: In response to the upgrade data being written into the first storage partition, a first number of first applications are optimized and compiled based on the second operating system.

5. The method according to claim 4, characterized in that The optimizing and compiling the first number of first applications based on the second operating system includes: Starting a virtual machine corresponding to the second operating system; The first number of first applications is optimized and compiled through a compiler in the virtual machine of the second operating system.

6. The method according to claim 4, characterized in that The method further comprises: In response to the optimizing and compiling the first number of the first applications, configuring a startup sequence identifier to start from the second operating system; The triggering of restart includes: after restarting and powering on, loading the data in the first storage partition according to the startup sequence identifier to run on the second operating system.

7. The method according to any one of claims 1 to 6, characterized in that: The first number is a preset value; or, The first number is the number of optimized compiled applications within a first duration, and the first duration is preconfigured.

8. The method according to any one of claims 1 to 6, characterized in that: The first application is an application that satisfies a first condition; the first condition includes a combination of one or more of the following: The first application is an application ranked in the top N positions in terms of activity level from high to low among the applications, wherein N is a positive integer, and the activity level is the activity level of the application evaluated based on the application operation record and the application download volume; The first application belongs to a first set, which is a set consisting of application programs that provide services of a specified type.

9. The method according to claim 8, characterized in that The optimizing and compiling the first number of first applications includes: Compiling the first applications in order from high to low according to the activity levels of the first applications until a cutoff condition is met; The cut-off condition is that the number of the first applications compiled reaches the preset first number, or the cut-off condition is that the time for optimization compilation reaches a preset first duration.

10. The method according to any one of claims 1 to 6, characterized in that: After the triggering restart, the method further includes: When the second condition is met, optimizing and compiling a second number of second applications; The second application includes an application without a valid odex file and an application with a valid odex file and uncompiled hotspot functions; the probability of satisfying the second condition is higher than the probability of satisfying the third condition, and the third condition is a scenario condition in the operating system that triggers the optimization compilation of the application.

11. The method according to claim 10, characterized in that The second number is preconfigured, and the second number is greater than the first number.

12. The method according to claim 10, characterized in that The method further comprises: When the second condition is met and the second optimized compiled applications reach a second number, suspending the optimized compiled application program; When the third condition is met, the optimization and compilation of the application program continues.

13. The method according to claim 10, characterized in that The second condition includes a combination of one or more of the following: the screen is off; the battery is charging; the actual power is greater than the first value; The third condition is that the device is in the screen-off state, in the above-mentioned charging state, and the actual power is greater than a second value; and the second value is greater than the first value.

14. An electronic device, characterized in that: The electronic device comprises: a processor and a memory, wherein the memory is used to store computer instructions. When the processor executes the computer instructions, the electronic device executes the method as claimed in any one of claims 1 to 13.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises a computer program or instructions, and when the computer program or instructions are executed on a computer, the computer is caused to perform the method according to any one of claims 1 to 13.

Images