Compilation optimization method and electronic equipment

Abstract

The invention provides a compiling optimization method and electronic equipment, and relates to the field of compiling optimization. The compiling optimization method provided by the invention is applied to a server, the server sends a target system installation package to the terminal equipment, odex files corresponding to N system applications are preset in the target system installation package, and after the terminal equipment installs the target system installation package and restarts, the odex files corresponding to the N system applications are stored in the terminal equipment. And loading the odex file in a process of running the system application so as to execute compilation optimization at a speed-profile level. By adopting the method provided by the embodiment of the invention, the system application in the electronic equipment can directly load the corresponding odex file during running so as to execute speed-profile level compilation optimization, the running speed and the performance of the system application are improved, and the running power consumption of the system application is reduced.

Description

Technical Field

[0001] This application relates to the field of compiler optimization, and more particularly to a compiler optimization method and electronic device. Background Technology

[0002] Applications in electronic devices require compiler optimization to improve their performance. A common optimization method involves identifying "hotspot" functions during application runtime and optimizing these functions. However, these hotspot functions are only available after the application is running. Therefore, electronic devices typically perform compilation optimizations on applications after they have been running for a period of time. After each optimization, the compiled executable file must be loaded when the application restarts for the changes to take effect.

[0003] However, the system applications of electronic devices are basically long-term keep-alive applications. They are rarely restarted after the electronic device is powered on, making it difficult for the compiled runtime files of the system applications to take effect, which affects the running speed, power consumption and performance of the system applications. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a compilation optimization method and an electronic device, enabling system applications in the electronic device to directly load the corresponding odex file at runtime to perform speed-profile level compilation optimization, thereby improving the running speed and performance of the system applications and reducing the power consumption of the system applications.

[0005] In a first aspect, embodiments of this application provide a compilation optimization method applied to a first electronic device, comprising: obtaining hotspot function set files of N system applications, where N is an integer greater than 0; generating a target system installation package based on the hotspot function set files of the N system applications, wherein the target system installation package includes optimized runtime odex files of the N system applications; sending the target system installation package to a second electronic device for the second electronic device to install the target system installation package, wherein when the second electronic device restarts, the N system applications of the second electronic device load their respective corresponding odex files during operation to perform speed-profile level compilation optimization.

[0006] For example, the first electronic device can be a server, and the second electronic device can be a terminal device, such as a mobile phone, smartwatch, tablet computer, or in-vehicle computer.

[0007] For example, N system applications are compileable and optimizeable system applications. N can be 1, 2, 3 or more, and system applications can be such as desktop, negative one screen, SystemUI, etc.

[0008] For example, the hotspot function set file for N system applications is a readable hotspot function set file, and the format can be text format.

[0009] In this way, the target system installation package generated by the server includes odex files for N system applications. After the second electronic device installs the target system installation package and restarts, the N system applications can directly load their respective odex files at runtime to perform speed-profile level compilation optimization. Since speed-profile level compilation optimization is faster than verify level compilation optimization, it improves the running efficiency of system applications, thereby reducing the number of exceptions that occur during system application operation, improving system application performance, and reducing the power consumption of system applications.

[0010] According to the first aspect, obtaining hotspot function set files for N system applications includes: collecting first profile files and corresponding version information of the N system applications from a test device, wherein the first profile files are used to record the hotspot function sets of the system applications; and / or: collecting the first profile files and corresponding version information of the N system applications while simulating the operation of the N system applications in different scenarios; and converting the first profile files of the N system applications into hotspot function set files unbound from the N system applications based on the first profile files and corresponding version information of the N system applications, wherein the format of the hotspot function set files is text format.

[0011] For example, the test device can be a device of the same type as the second electronic device, such as a test mobile phone. The more test devices there are, the more hot functions of the system application are collected, making the generated odex file of each system application more accurate.

[0012] For example, the hotspot function set can come from the hotspot function set collected during the runtime of the simulated system application. By simulating the hotspot functions collected during the runtime of the simulated system application, the number of hotspot functions in the system application can be greatly increased, thus ensuring the accuracy of the odex file generated for each subsequent system application. During simulation, test models such as motion models, mokey models, or test cases can be used.

[0013] For example, the method signature of a hotspot function set file can be a text command.

[0014] For example, maintenance personnel can add uncollected hot functions to the hot function set file to increase the number of hot functions in the system application, making the hot function set file cover more comprehensive hot functions.

[0015] In this way, the server obtains each first profile file (which is an unreadable file) and the corresponding system application version information (such as version number). Based on the profile file and the corresponding system application version information, the server can use the Proman tool to convert the first profile file (which is an unreadable file) into a readable hotspot function set file. By converting the first profile file into a readable hotspot function set file, the first profile file is unbound from the corresponding system application. This allows the unbound hotspot function set file to be used in different versions of system applications, improving the flexibility and applicability of the pre-built odex file.

[0016] According to the first aspect, based on the hot function set files of N system applications, a target system installation package is generated, including: generating a second profile file for each of the N system applications based on the hot function set files of the N system applications, the second profile file including the hot functions in the system application; performing speed-profile level compilation optimization on the second profile files of the N system applications to obtain the odex files of each of the N system applications; and packaging the odex files of each of the N system applications with the system installation package to be distributed to generate the target system installation package, the system installation package to be distributed including the installation packages of the N system applications.

[0017] In this way, since the hot function set files of N system applications are in text format, they can be applied to different versions of the system application. Based on the hot function set files, a second profile file corresponding to each system application is generated, and the second profile file is bound to the corresponding system application. The server compiles and optimizes the second profile file to obtain the corresponding odex file, and packages the odex file together with the system installation package, so that the system installation package includes the odex files of N system applications.

[0018] According to the first aspect, based on the hotspot function set files of the N system applications, generating a second profile file for each of the N system applications includes: merging the hotspot function sets of the N system applications to obtain a separate hotspot function set file for each of the N system applications; archiving the separate hotspot function set files of the N system applications into the dex version of the system installation package; extracting the hotspot function set files of the N system applications from the running dex version of the system installation package and archiving them into the odex version of the system installation package; deleting the paths of the hotspot function set files of the N system applications from the dex version of the system installation package; and converting the hotspot function set files in the odex version of the system installation package into a second profile file bound to the installation package of each system application.

[0019] In this way, the server extracts the hot function set files for each system application from the dex version and deletes the original paths, reducing the size of the system installation package. Additionally, the hot function set files for each system application are archived into the system's odex version. Since the hot function set files are in text format and are unbound from the system applications, the archived hot function set files do not carry any version information of the system applications, allowing them to be archived according to different versions of the system applications.

[0020] Based on the first aspect, the hotspot function sets of N system applications are merged to obtain a separate hotspot function set file for each of the N system applications. This includes performing the following operations on the hotspot function sets of each system application: merging the hotspot function sets of each system application to obtain a merged set; and deleting duplicate hotspot functions from the merged set to obtain a separate hotspot function set file for each system application. Since the hotspot function set file is a text file, the server can perform deduplication, avoiding duplicate hotspot functions in the merged hotspot function set files of the N system applications. The server can also avoid storing duplicate hotspot functions, reducing the size of the target system installation package.

[0021] According to the first aspect, converting the hotspot function set file in the odex version of the system installation package into a second profile file bound to the installation package of each system application includes: performing the following first traversal operation on each system application in the odex version of the system installation package: when a hotspot function set file is detected in a system application, converting the hotspot function set file into a second profile file bound to the system application using a first tool based on the system application's installation package and the corresponding hotspot function set file; obtaining the percentage of hotspot functions that failed to be converted during this conversion process as a first percentage; when the first percentage is detected to be greater than a first threshold and less than a second threshold, sending a first prompt message and performing a first traversal operation on the next system application, the first prompt message being used to prompt maintenance personnel that the first percentage is greater than the first threshold; when the first percentage is detected to be less than the first threshold, performing a first traversal operation on the next system application; when the first percentage is detected to be greater than the second threshold, exiting the first traversal operation; when a hotspot function set file is detected not to be present in a system application, performing a first traversal operation on the next system application.

[0022] In this way, the server can avoid missing the conversion of the second profile file by iterating through the data. During the first iteration, if too many hotspot functions fail to convert, the effectiveness of the odex file loaded by the second electronic device is diminished, limiting its impact on system application efficiency. Therefore, in this example, the percentage of failed hotspot functions (i.e., the ratio of failed hotspot functions to the number of hotspot functions in the hotspot function set file of the system application) is calculated. If the percentage exceeds a first threshold, the system application maintenance personnel are notified. If the percentage exceeds a second threshold, the first iteration and odex file generation operations are terminated, and an alarm is sent to the maintenance personnel. In this example, the first threshold can be 5%, and the second threshold can be 10%.

[0023] Based on the first aspect, speed-profile level compilation optimization is performed on the second profile files of N system applications to obtain the odex files for each of the N system applications. This includes: performing the following second traversal operation on each system application in the odex version of the system installation package: determining whether a second profile file exists in the system application; when a second profile file is detected, performing speed-profile level compilation optimization on the second profile file of the system application and performing the second traversal operation on one system application; when a second profile file is detected, performing the second traversal operation on one system application. In this way, the server can avoid the problem of not performing compilation optimization on all second profile files through the second traversal operation.

[0024] According to the first aspect, before converting the first profile files of the N system applications into hotspot function set files unbound from the N system applications based on the first profile files of the N system applications and the corresponding version information of the system applications, the method includes: detecting that the first profile files of the N system applications are not empty. This allows the server to avoid using empty profile files.

[0025] Secondly, embodiments of this application provide a compilation optimization method applied to a second electronic device, comprising: downloading a target system installation package from a first electronic device, the target system installation package including optimized runtime odex files for N system applications; decompressing the target system installation package and installing it on the second electronic device; restarting the second electronic device after installing the target system installation package; and loading the corresponding odex files for each of the N system applications during their operation to perform speed-profile level compilation optimization.

[0026] Thirdly, this application provides an electronic device, including: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the electronic device performs the compilation optimization method corresponding to the first aspect and any implementation of the first aspect.

[0027] The third aspect and any implementation thereof correspond to the first aspect and any implementation thereof, respectively. The technical effects of the third aspect and any implementation thereof are similar to those of the first aspect and any implementation thereof, and will not be repeated here.

[0028] Fourthly, this application provides a computer-readable medium for storing a computer program that, when run on an electronic device, causes the electronic device to perform the compilation optimization method corresponding to the first aspect and any implementation thereof. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1a This is an exemplary diagram illustrating how to query the compilation optimization level of a system application;

[0031] Figure 1b This is an illustrative diagram showing a queried file loaded at runtime by a system application.

[0032] Figures 1c-1d This is an example of a trace graph showing the JIT thread blocking the main thread;

[0033] Figures 2a-2b This is an exemplary schematic diagram illustrating the operating scenario of a system application;

[0034] Figure 3 This is an exemplary schematic diagram illustrating the process of installing a target system installation package on a terminal device;

[0035] Figure 4 This is an exemplary software structure diagram illustrating the generation and application of the target system installation package;

[0036] Figure 5 This is an exemplary flowchart illustrating the compilation optimization in this application;

[0037] Figure 6 This is an exemplary flowchart illustrating the process of converting a hotspot function set file into a profile file in this application;

[0038] Figures 7a-7b This is an exemplary schematic diagram illustrating the running scenario of system applications after the target system installation package is installed;

[0039] Figure 8a This is an exemplary diagram illustrating how to query files within the installation package of a system application;

[0040] Figure 8b This is an illustrative diagram showing a queried file loaded at runtime by a system application.

[0041] Figure 9 This is an exemplary schematic diagram illustrating the running scenario of system applications after the target system installation package is installed;

[0042] Figure 10 This is an exemplary hardware structure diagram of an electronic device. Detailed Implementation

[0043] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0044] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0045] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0046] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0047] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0048] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0049] (1) Android Runtime (ART): The Android Runtime is also known as the ART virtual machine. The ART virtual machine is a virtual machine technology used in the Android operating system. In versions 1 and 2, ART replaced the previous Dalvik virtual machine. One of the main improvements of ART compared to Dalvik is the use of Ahead-Of-Time (AOT) compilation instead of Just-In-Time (JIT) compilation. This means that applications can be pre-compiled into native machine code during the first installation to improve performance, but it requires more storage space.

[0050] The most significant feature of the ART virtual machine is that it pre-compiles all the application's dex (DalvikExecutable) files and generates native machine code during application installation for subsequent execution, thereby speeding up application execution. Compared to the Dalvik virtual machine, the ART virtual machine offers higher performance, faster startup speed, smaller application footprint, and also improves the security of Android applications. Overall, the ART virtual machine enhances application efficiency and user experience.

[0051] (2) Interpreted Execution: Interpreted execution refers to the method by which an electronic device directly runs the source code of an application, interpreting and executing it line by line. In this method, the source code needs to be parsed and translated each time the program is executed, transforming it into a sequence of executable instructions. Because interpretation and translation are required for each execution, interpreted execution is relatively slow.

[0052] (3) Just-In-Time (JIT) compilation: JIT refers to compiling an electronic device during the execution of an application (at runtime) rather than before execution. JIT is faster than interpreted execution.

[0053] (4) Ahead-of-Time (AOT): During the installation of the Android application package (Android APK), the system uses the dex2oat (Dalvik Executable file to optimized ART file) tool to compile the dex (Dalvik Executable) files in the APK into an OAT (Optimized ART) file containing native machine code for storage. In the Android system, there are two runtime executable file formats: dex files and OAT files. Dex files are the standard executable file format running on the Dalvik virtual machine, while OAT files are an optimized executable file format running on the ART virtual machine. OAT files contain not only native machine instructions translated from the dex file but also the original dex file. For the APK, the OAT file is essentially a wrapper around the odex file. During application installation, dex2oat compiles the dex files extracted from the installation package to obtain the odex file. The installed application can directly load and run the odex file during runtime, greatly improving application efficiency; that is, AOT is faster than JIT.

[0054] It should be noted that when an OAT file is included during application execution, ART uses the OAT file directly; when no OAT file is included, ART executes the DEX file via JIT and the interpreter.

[0055] dex2oat includes several different levels of compiler optimization, with common optimization levels including Verify, Speed-profile, and Speed. Verify-level optimization only verifies the bytecode, minimizing ROM usage. Speed-profile optimization only optimizes hot functions, balancing ROM usage and performance. Speed-profile optimization optimizes the entire application code, but has the highest ROM usage. Verify-level optimization performs worse compilation performance than Speed-profile optimization, and Speed-profile optimization performs worse compilation performance than Speed-level optimization.

[0056] In this embodiment, the terminal device running the application is a mobile phone. The mobile phone downloads the application installation package (Android application package, Android APK) from the server.

[0057] The phone has system applications installed, such as desktop applications and system UI. The default compilation level for system applications is Verify. Since Verify-level compilation optimization only verifies the bytecode, although it uses less ROM space, its compilation performance is poor. In some examples, to improve application performance, the phone is often triggered to optimize the compilation of system applications when idle, i.e., the compilation mode of optimizable system applications is set to speed-profile level. For example, the default compilation optimization level for desktop applications is Verify. When the phone is idle, compilation optimization is triggered for the desktop application, changing its compilation optimization level to speed-profile. Use a first query command (such as "dumpsys package dexopt") to check the compilation optimization level of the desktop application, and refer to... Figure 1a As shown, the query results display "status=speed-profile", indicating that the current compilation optimization level of this desktop application has been set to the speed-profile level.

[0058] Continuing the example above, after the phone triggers compilation optimization for the desktop application, an odex file is generated, meaning the desktop application's compilation optimization level has been set to speed-profile. Once the phone obtains the desktop application's odex file, the compiled executable file (i.e., the odex file) can only be loaded when the desktop application restarts. Only after the odex file in the desktop application takes effect can the desktop application's compilation optimization level successfully switch to speed-profile.

[0059] However, since system applications are essentially always-on applications and rarely restart after the phone is powered on, the odex files corresponding to these applications, generated when the phone is idle, cannot be loaded for extended periods. This prevents the system applications' compilation optimization level from successfully switching to the speed-profile level, thus failing to improve the performance of desktop applications. For example, continuing with the desktop application example above, such as... Figure 1a As shown, the desktop application's compilation optimization level is set to the speed-profile level, but the desktop application does not load the odex file during runtime. Figure 1b As shown, engineers can use a second query command (such as "ps -ef") to query the files loaded when the desktop application runs, from... Figure 1b The white dashed box shows no odex files among the file types.

[0060] In other embodiments, the phone typically restarts after an operating system upgrade; that is, the system applications on the phone restart after a version upgrade. However, different versions of system applications have different odex files, and the phone cannot load the odex file of the previous version of the system application when running the current version of the system application. For example, when the phone is idle, it compiles and optimizes version A of the desktop application, generating odex file A. The desktop application is upgraded from version A to version B and restarted. When version B of the desktop application runs, it cannot load odex file A, and version B of the desktop application runs in interpreter and JIT mode, resulting in degraded performance of the desktop application after the system upgrade.

[0061] On the other hand, the JIT compilation strategy has changed, and the current JIT compilation time for a single function has increased by 55.79% compared to the previous version. In other words, the current JIT compilation time for a single function has increased.

[0062] On the other hand, systems typically use interpreted execution during initial startup. When a single function is executed a certain number of times, a JIT compilation is performed on that function. Current versions of JIT compilation have lowered this first trigger threshold, leading to an increase in the number of JIT compilations.

[0063] As the system application runs, the number of JIT compilations increases and the time spent on JIT compilation of individual functions increases, leading to performance degradation, increased load, and increased power consumption in the system application after system upgrades, which affects the smoothness of the system application's operation.

[0064] For example, after the system upgrades from version A to version B, the desktop application also upgrades from version A to version B. By tracking the performance of the desktop application, a trace graph of the application can be obtained. Each tracking point is a trace, and the trace graph can record information such as application runtime, runtime formatted data, processes, or threads. When the desktop application is running, engineers can observe from the desktop trace graph that there are many JIT processes. A high number of JIT processes during desktop runtime leads to increased load and increased power consumption on the phone.

[0065] Figure 1c This is a trace graph showing how the JIT thread blocks the main thread due to lock blocking.

[0066] When a user clicks the short video app icon on the desktop, the launcher responds to the click and initiates the app's launch. Assume the app displays an animation upon launch. The launcher uses a JIT (Just-In-Time) compilation method, and during compilation, the JIT thread needs to hold a lock, such as... Figure 1c As shown, when the JIT thread is blocked, because the JIT thread holds the lock, the main thread (i.e., the launcher thread) must wait for the JIT thread to release the lock before it can acquire the lock, thus causing the main thread to be blocked. The end point of the main thread's blocking is the end point of the JIT thread's lock-holding blocking. Main thread blocking causes frame drops in the short video startup animation.

[0067] Figure 1d This is a trace graph showing how the JIT thread blocks the main thread due to a condition variable.

[0068] Please refer to Figure 1d The rendering thread has two worker threads, hwuiTask0 and hwuiTask1, used for rendering frames. The main thread (hwuiTask1 thread) needs to use the first condition variable, but this first condition variable is currently being used by the JIT thread. The main thread needs to wait for the JIT thread to release the first condition variable, causing the main thread to block. Figure 1d As shown, the blocking period of the main thread (i.e., c~d) is the same as the duration of the JIT thread using the first condition variable. In actual application, as shown in Figure 2(1), the mobile phone displays the album interface 203. The user swipes in the direction of the black arrow on the album interface (i.e., exits the camera application). Due to the JIT compilation optimization method used in the system application launcher, the JIT thread is blocked by the condition variable on the main thread, causing the animation effect of exiting the camera application to be stuttered. As shown in Figure 2(2), the album interface stutters for 1 second before the desktop 204 is displayed on the mobile phone display interface.

[0069] Therefore, when the system application runs inefficiently, it may lead to poor system application performance (such as causing the main thread to be blocked), high power consumption, and slow running speed.

[0070] Therefore, embodiments of this application provide a compilation optimization method, such as... Figure 3 As shown, during the system installation package packaging stage, the server pre-installs the odex files corresponding to the optimized system applications within the system installation package. During the installation package download and installation stage, the terminal device downloads the system installation package from the server, decompresses it, and installs it on the terminal device. Since the system installation package already contains the pre-installed odex files, these files are loaded when the terminal device restarts. After the system upgrade, the system applications can run in speed-profile compilation mode, thereby improving the application's runtime efficiency.

[0071] Figure 4 The diagram illustrates the architecture of a compiler optimization method as an example. Figure 4This includes servers and terminal devices. The compilation optimization process includes:

[0072] Step 401: Test the hotspot functions of the mobile phone data acquisition system application.

[0073] For example, when an application first starts, it typically uses interpreted execution. After a certain period of use, the application records a set of hot functions in a profile file, compiles the recorded set of hot functions, and generates an odex file. Hot functions are those functions that are executed more than a certain threshold during the application's runtime. In this example, the test user uses a test phone, which collects profile files from various system applications used to record hot functions. Multiple test phones can be configured, such as 100, 1000, or 10000.

[0074] Optionally, the electronic device can also run a test model to collect hotspot functions. Specifically, the test model is a pre-trained model used to run various system applications on the electronic device and automatically collect hotspot functions from each system application, recording them in a profile file. The electronic device can be a computer. The test model can simulate the operation of various system applications under different application scenarios, thereby collecting hotspot functions from different system applications.

[0075] Step 402: Test the mobile phone to upload the collected profile file and APK version information to the server.

[0076] For example, each test mobile phone can upload the collected profile file and the corresponding system application (i.e., APK) version information to the server. Optionally, the electronic device obtains the version information of each hot function and the corresponding system application collected during the test model's runtime, and uploads the version information of each hot function and the corresponding system application collected based on the test model to the server. The system application version information may include the version number of the system application.

[0077] In one example, the electronic device can aggregate the hot functions and corresponding system application version information collected by each system application based on the test model, as well as the profile files and corresponding system application version information collected by each test phone. The electronic device uploads the aggregated information to a server; in this example, the electronic device could be a computer.

[0078] Step 403: The server converts the profile file and the corresponding version of the APK to obtain readable hotspot functions, and these readable hotspot functions are not bound to the version of the APK.

[0079] For example, the server obtains target upload information, which includes collected hotspot function sets (i.e., profile files) for various system applications and corresponding system APK version information (i.e., system application version information). Based on the profile file and its corresponding APK version information, the server converts the profile file into a readable hotspot function set file. Specifically, the server can run the profman tool, inputting the system APK version information corresponding to the profile file into it. The profman tool then converts the profile file from a binary file into a readable text format (i.e., txt format) hotspot function set file.

[0080] In this example, the profile file obtained by the server is an unreadable binary file, making it strongly correlated with the corresponding APK version information; that is, the profile file and the corresponding APK version information are bound together. When the profman tool converts this profile file from a binary file into a readable hotspot function set file, the hotspot function set file is unbound from the APK version information because it is now readable.

[0081] The server stores system installation packages awaiting distribution, including both dex and odex versions. Once the server obtains a readable hotspot function set file, it archives the readable hotspot function set file into the dex version of the system installation package.

[0082] Step 404: During the version release process, the server generates a profile file bound to the new APK based on the hotspot function file and the archived new APK.

[0083] Specifically, the server obtains a readable hotspot function set file from the dex version of the system installation package. The server uses the profman tool to bind the readable hotspot function set file with the version information of the new APK, generating a profile file bound to the new APK (hereinafter referred to as the second profile file).

[0084] Step 405: The server performs speed-profile compilation optimization on system applications based on the profile file.

[0085] For example, the server performs speed-profile compilation optimization on the system applications based on the second profile file, generating odex files corresponding to each system application.

[0086] Step 406: The server performs version archiving.

[0087] For example, the server packages the odex files of each system application together with the system installation package to generate the target system installation package.

[0088] Step 407: The server distributes the downloaded version of the system upgrade to the terminal devices.

[0089] Specifically, the server distributes the target system installation package to the terminal device.

[0090] Step 408: The terminal device loads the pre-configured odex file when starting the application and uses the OAT file when executing hotspot functions.

[0091] For example, the terminal device downloads the application's installation package from the server, then decompresses the package and runs the functions within it to successfully install the application on the terminal device. Specifically, the package manager service (PMS) in the system services decompresses the target system installation package and installs it on the terminal device. After the terminal device restarts, when the system applications start, they can directly load the pre-installed odex files of each system application to perform speed-profile level compilation optimizations.

[0092] It should be noted that the layered architecture of a terminal device divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into three layers, from top to bottom: the application layer, the application framework layer, and the kernel layer.

[0093] like Figure 4 As shown, the application package can include applications such as the desktop, the negative one screen, and SystemUI.

[0094] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0095] like Figure 4 As shown, the application framework layer can include system services. The main function of system services is to provide various system-level functions and management services, helping developers implement functions such as device information acquisition, location services, and network management, while optimizing application performance and resource utilization. Examples include package management services and window management services.

[0096] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0097] Understandable Figure 4 The layers in the illustrated software structure and the components contained in each layer do not constitute a specific limitation on the terminal device. In other embodiments of this application, the terminal device may include more or fewer layers than illustrated, and each layer may include more or fewer components; this application does not impose any limitations.

[0098] The following is combined Figure 5 This section details the process by which the server pre-installs the odex file in the target system installation package.

[0099] Step 501: The server retrieves the hot functions and archives them into a hot function set file.

[0100] Specifically, the source of the hotspot function set can be test mobile phones, and there can be multiple test mobile phones, such as 100 or 1000. The test mobile phones can run various system applications on different system versions. After running on the test mobile phones for a period of time, the hotspot functions of each system application under different system versions, along with the corresponding system application version information, are obtained. The test mobile phones then upload the collected hotspot function set to the server.

[0101] In one example, the set of hotspot functions can also originate from the experimental environment. Specifically, in the experimental environment, experimental equipment (such as a computer, or even the server itself) collects the hotspot functions generated during the experiment using a test model. The test model is used to simulate the operation of the system application under different system versions; this test model can be a dynamic model, a monkey model, or test cases of the system application running in different common scenarios. The experimental equipment can then upload the acquired hotspot functions to the server.

[0102] It should be noted that during application runtime, the system records the application's hotspot functions through profile files. In other words, the set of hotspot functions collected by the test phone or experimental device constitutes the collection of profile files. Hotspot functions for each system application are recorded in the same profile file. The test phone or experimental device also obtains the version information (such as the system application version number) of the system application corresponding to the collected profile files. The test phone or experimental device then uploads the profile files of each system application and the corresponding system application version information to the server. Optionally, the test phone or experimental device can collect a preset number of profile files and then upload the profile files and corresponding system application version information of each system application to the server, or it can upload the profile file and corresponding system application version information to the server as soon as a profile file is collected.

[0103] The server can obtain the profile file from the test phone, or from the experimental environment, or obtain both the profile file from the test phone and the profile file from the experimental environment (i.e., the first profile file).

[0104] This example demonstrates how the server obtains profile files from both a test phone and an experimental environment.

[0105] After obtaining the profile files, the server processes each profile file and its corresponding system application version information as follows: It checks if the profile file is empty. If the server detects that the profile file is empty, it determines that the hotspot function collection has failed and can discard the profile file. If the server detects that the profile file is not empty, it inputs the profile file and its corresponding system application version information into the Proman tool. The Proman tool then converts the profile file into a readable hotspot function set file in TXT format. For example, the profile file may be an unreadable binary file (appearing as garbled text) before conversion, and the converted function set file may be in TXT format. A portion of the content from the readable hotspot function set file may appear as " / content / ContentGroup…".

[0106] After converting the profile files of each system application into readable hotspot function set files, the server merges all the converted readable hotspot function set files for that system application. Specifically, for each system application, the server performs the following processing: It aggregates all readable hotspot function set files for that system application, and based on the content of these files, removes duplicate hotspot functions from the aggregated readable hotspot function set files to obtain a merged hotspot function set file (referred to as the first hotspot function set file) corresponding to that system application.

[0107] Optionally, the server can also add other hotspot function set files to the first hotspot function set file. For example, if the server detects that hotspot function A does not exist in the first hotspot function set file, it can add readable hotspot function A to the first hotspot function set file.

[0108] Optionally, the server can name the method signature of the first hotspot function set file in a readable format, for example, "apk.txt". In this example, because the first hotspot function set file is in a readable format and is unbound from the system version information, it can be archived with different system applications and different system versions. That is, the first hotspot function set file of each system application is archived along with that system application into the system's dex version.

[0109] It should be noted that the content in step 501 corresponds to the content in steps 401 to 403.

[0110] Step 502: The server retrieves the hot function set file from the system's dex version and deletes the hot function set file in the original path of the dex version.

[0111] For example, the server retrieves the first hot function set file from the system's dex version and re-archives it to the system's (system installation package) odex version. The server then deletes the path containing the first hot function set file from the system's dex version.

[0112] Specifically, the system's dex version resources (i.e., the dex version of the system installation package) store the APKs of each system application. The server can traverse the system's dex version resources to check if a first hotspot function set file exists. The server retrieves the found first hotspot function set files from the system's dex version resources and deletes the paths of each first hotspot function set file in the system's dex version. The server then stores the retrieved first hotspot function set files in the system's odex version.

[0113] It should be noted that this step is in Figure 4 The compilation optimization process shown is not illustrated and is performed before step 404.

[0114] Step 503: The server converts the hotspot function set file into a profile file.

[0115] The following is combined Figure 6 The specific process of step 503 will be explained in detail.

[0116] Step 601: The server begins traversing the odexed archive resources.

[0117] For example, the system's odex version (i.e., odex-archived resources) includes the APKs of each system application. In step 502, the server has archived the hotspot function set files of each system application in the APK corresponding to the odex version, so at this time, the APK of the system application that can be optimized contains readable hotspot function set files.

[0118] In this example, the server can sequentially traverse each system application APK in the odexed archive resource to determine whether there is a readable hotspot function set file in the system application, so that the readable hotspot function set file can be bound to the system application APK.

[0119] Step 602: The server determines whether a hot function set file exists in the current system application. If the server determines that a hot function set file exists in the current system application, proceed to step 603; if the server determines that a hot function set file does not exist in the current system application, proceed to step 608.

[0120] For example, the server begins iterating through each system application APK in the odexed archive resource. The server determines whether a hotspot function set file exists in the currently iterated system application. Specifically, the server checks if a .txt file exists in the current system application. If it does, the server determines that a hotspot function set file exists in the system application. If the server does not detect a .txt file, it determines that a hotspot function set file does not exist in the system application.

[0121] When the server determines that a hot function set file exists in the current system application, step 603 is executed; when the server determines that a hot function set file does not exist in the current system application, step 608 is executed, that is, to determine whether there is an untraversed system application in the odex archive resources.

[0122] Step 603: The server records the total number of hot functions in the hot function set file.

[0123] For example, each hotspot function set file records multiple hotspot functions, and the server obtains the number of hotspot functions in the hotspot function set file of the current system application.

[0124] Step 604: The server converts the hotspot function set file into a profile file.

[0125] For example, the server can convert the hot function set file of the system application into a profile file bound to the system application, based on the system application itself. Specifically, the server can use the profman tool to convert the hot function set file of the system application into a profile file bound to the system application. For example, the server can use the command "profman --create-profile-from=apk.txt --apk=absolute path to apk --reference-profile-file=apk.prof" to convert the hot function set file of the system application into a profile file located in the archive resource path of the system application. This profile file is bound to the system application.

[0126] Step 605: The server obtains the number of hot functions that failed to be converted during the profile file conversion process.

[0127] For example, during the process of converting a hotspot function set file to a profile file, the server may encounter conversion failures, resulting in the absence of some hotspot functions in the profile file. In this example, the server can obtain the Profman processing logs and retrieve the number of unfound hotspot functions from them. These unfound hotspot functions are the conversion failures. The server then calculates the ratio of the number of conversion failures to the total number of hotspot functions in the hotspot function set file of the system application (i.e., the percentage of conversion failures). For instance, assuming the total number of hotspot functions in the hotspot function set file of system application A is M, and the number of conversion failures is k, then the percentage of conversion failures = k / M, where M is greater than k, and k is an integer greater than or equal to 0.

[0128] Step 606: The server determines whether the percentage of hot functions that failed to convert is greater than the first threshold and less than the second threshold. If the server determines that the percentage of hot functions that failed to convert is greater than the first threshold and less than the second threshold, proceed to step 607; if the server determines that the percentage of hot functions that failed to convert is less than the first threshold or greater than the second threshold, proceed to step 609.

[0129] For example, the first and second thresholds can be set according to the actual application. For instance, the first threshold can be 3%, 4%, 5%, 6%, etc., and the second threshold can be 8%, 9%, 10%, etc. In this example, the first threshold is 5%, and the second threshold is 10%. When the server determines that the proportion of hotspot functions that failed conversion is greater than 5% but less than 10%, it can send a first prompt message to the maintenance equipment or personnel to adjust the subsequently collected hotspot functions, thereby reducing the proportion of hotspot functions that failed conversion.

[0130] When the server determines that the percentage of hot functions that failed to be converted is less than or equal to 5%, or greater than or equal to 10%, the server determines whether the percentage of hot functions that failed to be converted is greater than 10%, and then executes step 609.

[0131] Step 607: The server sends the first notification message. Step 608 is then executed.

[0132] For example, the server can send a first notification message to the maintenance personnel or equipment of the system application, indicating that the proportion of hot-spot functions that have failed conversion in the current system application is greater than 5% and less than 10%. After receiving the first notification message, the maintenance personnel can adjust the operating environment or test mode of the system application to reduce the proportion of hot-spot functions that have failed conversion.

[0133] Step 608: The server checks if there are any untraversed APKs in the odexed archive resources. If so, the server executes step 602, which checks if there are any hotspot function set files in the next system application. If not, the server executes step 610, which ends the odexification process.

[0134] For example, the server determines whether there is an untraversed system application (i.e., APK) in the odexed archive resources. When the server detects the existence of an untraversed system application, it determines whether there is a hot function set file in the next system application, i.e., it executes step 602. When the server detects that there is no untraversed system application, it ends the odexification process.

[0135] Step 609: The server determines whether the percentage of hot functions that failed to convert is greater than the second threshold. If the server determines that the percentage of hot functions that failed to convert is greater than the second threshold, it executes step 610, i.e., ends the odex conversion process. If the server determines that the percentage of hot functions that failed to convert is less than the second threshold, it executes step 608.

[0136] For example, assuming the percentage of failed hotspot functions is 3%, the first threshold is 5%, and the second threshold is 10%, if the server determines that the percentage of failed hotspot functions is less than 5%, it executes step 608, which determines whether there are any untraversed APKs in the odexed archive resources. If the percentage of failed hotspot functions is 11%, the server directly terminates the odexed processing of each system application in the odexed archive resources and sends an alarm to maintenance personnel or equipment to indicate that the preset odex file operation failed.

[0137] Step 610: The server ends the odex process.

[0138] Steps 601 to 610 above correspond to step 503, and also to... Figure 4 Steps 404 and 405 in the process.

[0139] Step 504: The server uses the prof file to perform speed-profile level odex processing on the corresponding system applications.

[0140] For example, after the server converts each hot function set file into a profile file bound to the system application, the server can perform odex processing on the profile file bound to the system application based on the speed-profile compilation level to generate the odex file of the system application.

[0141] Specifically, the server can iterate through each system application to check if a profile file (i.e., a prof file) exists in each application. For example, for system application A (such as systemUI), it can search for the file and path "system / priv-app / SystemUI / SystemUI.prof" under the odex archive resource path "$project_work_path+ci_odex_dependencies / system_profile". When the server finds the prof file and path for SystemUI, it performs odex processing on the prof file based on the speed-profile compilation level to generate the odex file for SystemUI.

[0142] This step corresponds to Figure 4 Step 405 in the process.

[0143] It should be noted that after the server performs odex processing on the profile files bound to the system applications based on the speed-profile compilation level, the obtained odex files of each system application are packaged with the corresponding system applications to generate the target system installation package.

[0144] The server distributes the target system installation package to the terminal device. The PMS on the terminal device downloads, decompresses, and installs the target system installation package. Because the target system installation package includes odex files for optimized system applications, after the terminal device installs the new version of the system and restarts, the optimized system applications load their respective odex files and run, improving the running efficiency and performance of system applications while reducing the power consumption of the terminal device.

[0145] In one example, when the target system installation package installed on the terminal device includes the odex file of an optimizable system application, the system application uses speed-profile level compilation optimization during runtime, reducing the number of JIT iterations. Table 1 lists the percentage of JIT iterations for SystemUI and the launcher when using Verify level compilation optimization and when using speed-profile level compilation optimization.

[0146] Table 1

[0147]

[0148] Table 1 shows that when the two system applications use speed-profile level compilation optimization, the number of JIT operations is significantly reduced under the same operation. In other words, when the terminal device installs the target system installation package (i.e., the system installation package with pre-installed odex files) in this embodiment, SystemUI and the launcher experience significantly fewer JIT operations under the same operation compared to installing an existing system installation package. This avoids main thread blocking due to JIT thread blocking and reduces frame drops during application startup animations.

[0149] In another example, when the terminal device has installed the target system installation package (i.e., the system installation package with pre-installed odex files) from the embodiments of this application, since the odex files of the system application already exist on the terminal device, the system application can perform speed-profile level compilation optimizations after startup, thus improving the running speed of the system application. Table 2 lists the running speed of the system application when the terminal device has installed the system installation package with pre-installed odex files distributed by the server in the embodiments of this application.

[0150] Table 2

[0151]

[0152] Table 2 shows the process before optimization, where the application runs using existing compilation optimization methods, such as interpreted and JIT compilation. After optimization, the application runs faster when the target system installation on the terminal device includes the optimized system application's odex file. Since the system application's odex file is already present on the terminal device, the system application can perform speed-profile level compilation optimizations upon startup. As can be seen from Table 2, the system application runs faster.

[0153] For example, Figure 9 As shown in (1), when the target system installation package is not installed on the phone, the phone's display interface shows desktop 901. When the user slides on desktop 901 along the direction of the black arrow, the launcher responds to the user's swipe operation and displays the control center interface 902 after 150ms, as shown in (1). Figure 9 As shown in (2). When the target system installation package (i.e., the system installation package with the odex file pre-installed) is installed on the mobile phone, the launcher responds to the user's swipe down operation and displays the control center interface 902 after 50ms, as shown in (2). Figure 9 As shown in (3) of the text.

[0154] In one example, when the target system installation package (i.e., the system installation package with pre-installed odex files) of this application is installed on the terminal device, since the odex files of the system application already exist on the terminal device, the system application can perform speed-profile level compilation optimization after startup. This results in high system application running efficiency, improved system application performance, and reduced number of application exceptions. Table 3 lists the number of application exceptions.

[0155] Table 3

[0156]

[0157] In Table 3, "before optimization" refers to applications using existing compilation optimization methods, such as interpreted and JIT compilation optimization. "After optimization" means the system APK installed on the terminal device includes the optimized system application's odex file. Since the system application's odex file already exists on the terminal device, the system application performs speed-profile level compilation optimization upon startup. Table 3 shows that the number of system application anomalies has decreased. For example, the number of times the page refresh duration was reduced by more than 50ms during startup and exit animations (called frame drops greater than 50ms) decreased from 4 before optimization to 2. The number of times frame drops were greater than 50ms during multitasking animations decreased from 2 before optimization to 1. The number of times frame drops were greater than 50ms during desktop swiping animations decreased from 0.3 to 0.2. The number of times frame drops were greater than 50ms during unlocking the desktop animations decreased from 0.765 to 0.7. The number of times the application response time was greater than 150ms during swiping to exit decreased from 16.5 to 15.

[0158] This example assumes the target system installation package (i.e., the system installation package with a pre-installed odex file) is installed on the phone, taking the desktop swiping scenario as an example.

[0159] like Figure 7a As shown in (1), the phone's display interface shows desktop 701. When the user swipes up along the direction of the black arrow on the desktop (i.e., exits the camera application), the launcher responds to the user's swipe operation, and the interface switches to the negative one screen interface 702. In this example, the system version installed on the phone has the launcher's odex file pre-installed. The launcher uses AOT compilation optimization to improve its performance, making it respond to the user's desktop swipe operation, i.e., it swipes from desktop 701 to the negative one screen interface 702 after 50ms. Figure 7a As shown in (2) of the text.

[0160] This example demonstrates the scenario of swiping up to exit the application, assuming the target system installation package (i.e., the system installation package with a pre-installed odex file) is installed on the phone.

[0161] like Figure 7bAs shown in (1), the phone's display interface shows the photo album interface 801. When the user swipes up in the direction of the black arrow in the photo album interface (i.e., exits the camera application), the launcher responds to the user's swipe up, exits the photo album application, and displays the desktop. In this example, the system version installed on the phone has the launcher's odex file pre-installed. The launcher uses AOT compilation optimization to improve its performance, reducing the launcher's response time to the user's swipe up to 50ms. That is, it takes 50ms to jump from the photo album interface 801 to the desktop 802, as shown in (1). Figure 7b As shown in (2) of the text.

[0162] In one example, if the new version of the system APK installed on the terminal device includes the optimized odex file of the system application (i.e., the odex file of the system application is pre-installed), the power consumption of the system application during cold start can be reduced. Table 4 lists the power consumption of cold start on the negative one screen in different scenarios.

[0163] Table 4

[0164]

[0165] In Table 4, "normal installation" refers to a system installation package on the terminal device that does not include pre-installed odex files. "Optimized installation" refers to a system installation package on the terminal device that includes pre-installed odex files for system applications. Taking the negative one screen as an example, under normal installation, the negative one screen performs Verify-level compilation optimization during cold start, while under optimized installation, the negative one screen performs Speed-Profile-level compilation optimization. In scenarios where no processes are running in the background of the terminal device, the instantaneous power consumption of the negative one screen during cold start under normal installation (e.g., the instantaneous power consumption during a 4-second cold start) is greater than that under optimized installation. When multiple (e.g., more than two) processes are running in the background of the terminal device, the instantaneous power consumption of the negative one screen during cold start under normal installation is greater than that under optimized installation.

[0166] Understandably, when the system installation package includes the odex files of the system applications, after the terminal device installs the system installation package and restarts, the system applications will run using speed-profile level compilation optimization because the odex files of the system applications already exist. Taking SystemUI as an example, SystemUI's compilation mode is written at the speed-profile level. Checking the SystemUI installation directory, you can see that it contains pre-installed odex files, such as... Figure 8a As shown. Additionally, the odex files in the oat / arm64 directory are quite large, at least larger than 1MB. Furthermore, as... Figure 8bAs shown, engineers can use a second query command (such as "ps -ef") to check if the files loaded by the SystemUI runtime contain odex files. All of the above demonstrates that the system application runtime uses speed-profile level compilation optimizations.

[0167] The terminal devices to which the embodiments of this application are applicable may be, for example, mobile phones, laptops, or tablets.

[0168] It should be understood that, Figure 10 The terminal device 100 shown is merely an example of an electronic device, and the terminal device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 10 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits. In this example, electronic device 100 is exemplified by a mobile phone.

[0169] Terminal 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, antenna 1, 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a Subscriber Identification Module (SIM) card interface 195, etc. The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0170] It is understood that, in order to achieve the above-mentioned functions, the terminal device includes hardware and / or software modules that perform the respective functions. Based on the algorithm steps of the examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0171] This application also provides a chip system including at least one processor and at least one interface circuit. The processor and the interface circuit are interconnected via lines. For example, the interface circuit can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit can be used to send signals to other devices (e.g., the processor). Exemplarily, the interface circuit can read instructions stored in the memory and send the instructions to the processor. When the instructions are executed by the processor, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application does not specifically limit this.

[0172] This embodiment also provides a computer storage medium storing computer instructions. When these computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the compilation optimization method described in the above embodiment. The storage medium includes various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0173] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the compilation optimization method in the above embodiment.

[0174] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding compilation and optimization methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0175] Any content in the various embodiments of this application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application.

[0176] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for compiler optimization, characterized in that, Applied to a first electronic device, including: Obtain the hot function set files of N system applications, where N is an integer greater than 0; Based on the hot function set files of the N system applications, a target system installation package is generated, which includes optimized runtime odex files of the N system applications. The target system installation package is sent to the second electronic device for the second electronic device to install the target system installation package. After the second electronic device restarts, the N system applications of the second electronic device load their respective odex files during operation to perform speed-profile level compilation optimization.

2. The method according to claim 1, characterized in that, The process of obtaining the hot function set file for N system applications includes: Collect the first profile files and corresponding version information of the N system applications from the test equipment. The first profile file is used to record the hot function set of the system application; and / or, collect the first profile files and corresponding version information of the N system applications under the condition of simulating the operation of the N system applications in different scenarios. Based on the first profile files of the N system applications and the corresponding version information of the system applications, the first profile files of the N system applications are converted into hotspot function set files that are unbound from the N system applications. The hotspot function set files are in text format.

3. The method according to claim 2, characterized in that, The step of generating the target system installation package based on the hot function set files of the N system applications includes: Based on the hotspot function set files of the N system applications, generate a second profile file for each of the N system applications, wherein the second profile file includes the hotspot functions in the system applications; Speed-profile level compilation optimization is performed on the second profile files of the N system applications to obtain the odex files of the N system applications respectively; The odex files of the N system applications are packaged together with the system installation package to be distributed to generate the target system installation package, which includes the installation packages of the N system applications.

4. The method according to claim 3, characterized in that, Based on the hotspot function set files of the N system applications, generate a second profile file for each of the N system applications, including: By merging the hotspot function sets of the N system applications, a hotspot function set file for each of the N system applications is obtained; Archive a set of hot functions for the N system applications into the dex version of the system installation package; Extract the hot function set files of the N system applications from the running dex version of the system installation package and archive them into the odex version of the system installation package; Delete the paths of the hot function set files of the N system applications in the dex version of the system installation package; The hotspot function set file in the odex version of the system installation package is converted into a second profile file that is bound to the installation package of the respective system application.

5. The method according to claim 4, characterized in that, The process of integrating the hotspot function sets of the N system applications to obtain a separate hotspot function set file for each of the N system applications includes: For each system application's set of hot functions, perform the following operations: Merge each set of hot functions in the system application to obtain a merged set; Remove duplicate hotspot functions from the merged set to obtain a set of hotspot functions for the system application.

6. The method according to claim 4, characterized in that, The step of converting the hotspot function set file in the odex version of the system installation package into a second profile file bound to the installation package of each system application includes: For each system application in the odex version of the system installation package, the following first traversal operation is performed: When a hotspot function set file is detected in the system application, the hotspot function set file is converted into a second profile file bound to the system application using a first tool, based on the system application's installation package and the corresponding hotspot function set file. The percentage of hot functions that failed to convert during this conversion process is taken as the first percentage. When the first quantity percentage is detected to be greater than the first threshold and less than the second threshold, a first prompt message is sent and the next system application is traversed for the first time. The first prompt message is used to prompt the maintenance personnel that the first quantity percentage is greater than the first threshold. When the first quantity percentage is detected to be less than the first threshold, the first traversal operation is performed on the next system application. When the proportion of the first quantity is detected to be greater than the second threshold, the first traversal operation is exited; When it is detected that there is no hotspot function set file in the system application, the first traversal operation is performed on the next system application.

7. The method according to claim 4, characterized in that, Speed-profile level compilation optimizations are performed on the second profile files of the N system applications to obtain the respective odex files of the N system applications, including: For each system application in the odex version of the system installation package, the following second traversal operation is performed: Determine whether the second profile file exists in the system application; When the existence of the second profile file in the system application is detected, speed-profile level compilation optimization is performed on the second profile file of the system application, and a second traversal operation is performed on a system application; When it is detected that the second profile file does not exist in the system application, a second traversal operation is performed on a system application.

8. The method according to claim 2, characterized in that, Before converting the first profile files of the N system applications into hotspot function set files unbound from the N system applications based on the first profile files of the N system applications and the version information of the corresponding system applications, the method includes: The first profile file of the N system applications was detected to be non-empty.

9. A method for compiler optimization, characterized in that, Applied to a second electronic device, including: Download the target system installation package from the first electronic device, the target system installation package including optimized runtime odex files for N system applications; Decompress the target system installation package and install it on the second electronic device; After installing the target system installation package, restart the second electronic device; During the operation of the N system applications, their respective odex files are loaded to perform speed-profile level compilation optimizations.

10. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is coupled to the processor; The memory stores program instructions that, when executed by the processor, cause the electronic device to perform the compilation optimization method according to any one of claims 1 to 9.

11. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on an electronic device, it causes the electronic device to perform the compilation optimization method according to any one of claims 1 to 9.

Images