Compiling optimization method and device, electronic equipment and computer readable medium

Abstract

The application discloses a compilation optimization method and device, electronic equipment and a computer readable medium, and relates to the technical field of computers. The method comprises the following steps: determining target threads related to user interaction from all candidate threads of an application program; obtaining running parameters of all code units corresponding to each target thread; based on the running parameters of each code unit, finding target code units meeting preset conditions from all code units corresponding to each target thread; and compiling the target code units into machine code. Therefore, the target code units are determined from the threads related to user interaction, and the target code units are pre-compiled into machine code, so that the target code units run more smoothly, and thus the excellent use experience brought by the smooth code can be better perceived by users.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a compilation optimization method, apparatus, electronic device, and computer-readable medium. Background Technology

[0002] To improve the efficiency of applications running on electronic devices, compilers can be used to optimize the compilation of applications. Currently, a common approach is to collect hotspot code information of specific applications on user terminals and compile this information into machine code. This allows subsequent runs of the application's corresponding code to directly use the machine code without further compilation, thus improving execution speed. However, current methods for identifying hotspot code are not entirely accurate and may not be entirely reliable. Summary of the Invention

[0003] This application proposes a compiler optimization method, apparatus, electronic device, and computer-readable medium to improve the above-mentioned deficiencies.

[0004] In a first aspect, embodiments of this application provide a compilation optimization method, comprising: determining a target thread related to user interaction among all candidate threads of an application; obtaining the running parameters of all code units corresponding to each target thread; based on the running parameters of each code unit, searching for target code units that meet preset conditions from all code units corresponding to each target thread; and compiling the target code units into machine code.

[0005] Secondly, embodiments of this application also provide a compilation optimization apparatus, including: a determining unit, an acquiring unit, a searching unit, and a compiling unit. The determining unit is used to determine the target thread related to user interaction among all candidate threads of an application. The acquiring unit is used to acquire the running parameters of all code units corresponding to each target thread. The searching unit is used to search for target code units that meet preset conditions from all code units corresponding to each target thread based on the running parameters of each code unit. The compiling unit is used to compile the target code units into machine code.

[0006] Thirdly, embodiments of this application also provide an electronic device, including: one or more processors; a memory; one or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more application programs are configured to perform the methods described above.

[0007] Fourthly, embodiments of this application also provide a computer-readable medium storing processor-executable program code, which, when executed by the processor, causes the processor to perform the above-described method.

[0008] Fifthly, embodiments of this application also provide a computer program product, including a computer program / instructions, characterized in that the computer program / instructions implement the above-described method when executed by a processor.

[0009] The compilation optimization method, apparatus, electronic device, and computer-readable medium provided in this application determine the target thread related to user interaction among all candidate threads of an application, obtain the running parameters of all code units corresponding to each target thread, and search for target code units that meet preset conditions from all code units corresponding to each target thread based on the running parameters of each code unit. In other words, the hotspot code, i.e., the target code unit, determined in this application is based on the thread related to user interaction in the application. Then, the target code unit is compiled from bytecode into machine code. When the application executes the target code unit subsequently, it can directly use the pre-compiled machine code without recompiling it. Therefore, the target code unit determined from the thread related to user interaction and pre-compiled into machine code makes the target code unit run more smoothly, thus allowing users to better perceive the superior user experience brought by the smooth code.

[0010] Other features and advantages of the embodiments of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the embodiments of this application. The objects and other advantages of the embodiments of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0012] Figure 1 A flowchart of a compiler optimization method according to an embodiment of this application is shown;

[0013] Figure 2 A flowchart of a compiler optimization method according to another embodiment of this application is shown;

[0014] Figure 3 A schematic diagram of inter-thread calls provided in an embodiment of this application is shown;

[0015] Figure 4 A schematic diagram of the interface displayed by an application provided in an embodiment of this application is shown;

[0016] Figure 5 A schematic diagram of the interface displayed by an application provided in another embodiment of this application is shown;

[0017] Figure 6 This illustration shows a module block diagram of a compiler optimization apparatus provided in one embodiment of this application;

[0018] Figure 7 A structural block diagram of an electronic device provided in an embodiment of this application is shown;

[0019] Figure 8 It is a storage unit in this application embodiment for storing or carrying program code that implements the compilation optimization method according to this application embodiment. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. The components of the embodiments of the present application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without inventive effort are within the scope of protection of the present application.

[0021] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0022] Typically, Android uses two virtual machine execution environments: Dalvik and ART. In Dalvik, each time an application runs, its bytecode needs to be converted into machine code by a Just-In-Time (JIT) compiler before the machine can execute it, which slows down application performance. In Android 4.4, the ART virtual machine began to replace Dalvik. In the early ART versions, when an application was first installed, the system used a tool called dex2oat to compile the dex file in the APK into an oat file containing native machine code. This allowed the program to directly use the pre-compiled machine code during execution, improving efficiency. This mechanism of pre-compiling machine code is called AOT (Ahead-of-Time). The disadvantages of AOT are that application optimization after installation and system upgrades is time-consuming (recompiling the dex bytecode into native machine code), and the optimized file occupies additional storage space.

[0023] Most applications on the Android platform are written in Java. Java programs were initially executed solely through the Java interpreter, meaning they were executed line by line of bytecode. Theoretically, AOT (Ahead-of-Time) execution offers the best performance, but at the cost of longer compilation times and larger executable file sizes. AOT, on the other hand, completes the machine code conversion during the compilation phase, eliminating the need for compilation during runtime and thus not impacting performance. However, this method is relatively slow, especially when a particular method or code block is executed frequently. Therefore, a JIT (Just-In-Time) compiler was introduced into the virtual machine. When the virtual machine detects a frequently executed method or code block, it identifies this code as "hot spot code," records it in the profile file, and improves its execution efficiency at runtime by compiling it into platform-specific machine code. The JIT compiler handles this task. JIT combines the advantages of both AOT and interpreted execution, employing a balanced strategy that considers both performance and file size.

[0024] In simple terms, the profile file records the methods or code blocks that the application runs frequently. After being compiled by JIT or AOT, it becomes the .odex / .oat file. This file contains the binary machine code compiled from these frequently used codes, which can be directly executed by the underlying CPU, thereby improving the running speed.

[0025] Currently, most mobile phone manufacturers use a hybrid compilation model of ART+Interpreter+JIT+AOT. The process is as follows:

[0026] 1) The application's dex file will not be compiled again during installation;

[0027] 2) When the App runs, the dex file is first executed directly by the parser. Frequently executed functions or code blocks are identified as hot code and are compiled by JIT and stored in the JIT code cache, and a profile file is generated to record information about hot functions.

[0028] 3) When the phone enters IDLE and Charging state, the system will scan the profile file in the App directory and perform the AOT process to compile;

[0029] Each app's profile file is located in the / data / misc / profiles / directory: / data / misc / profiles / cur / 0 / package-name / primary.prof.

[0030] In this mode, the application installation speed and OAT upgrade speed will not be affected. The application performance will not be improved much at the beginning, but as users run the application more often and more hot code is compiled, the performance will get better and better.

[0031] In addition, in Android Pie, Google introduced a new feature on Google Play based on the hybrid model of Interpreter+JIT+AOT. By configuring hotspot code for an application in Play Cloud, when a user downloads an application from Google Play, the application's hotspot profile file is simultaneously distributed to the user's phone from the cloud. During the application installation process, dex2oat is called to compile the hotspot code, thereby improving the performance of the application after installation.

[0032] While collecting hotspot code information from specific applications on user terminals and compiling this information into machine code allows subsequent runs of that application's code to directly use the machine code without further compilation, thus improving execution speed, the inventors have found that current methods for identifying hotspot code are not entirely accurate. Most methods rely on statistically analyzing the number of times all application code is run, then identifying the most frequently run hotspot codes. This approach is too simplistic and results in inaccurate identification of hotspot codes, failing to truly and meaningfully improve application efficiency.

[0033] Therefore, in order to improve the accuracy of hotspot code, embodiments of this application provide a compilation optimization method, apparatus, electronic device, and computer-readable medium, which can extract hotspot code from the code of user interaction-related threads and pre-compile it into machine code, thereby making the functional modules of the application that can be perceived by the user run more smoothly and improving the user experience.

[0034] Specifically, please refer to Figure 1 , Figure 1 An embodiment of this application provides a compilation optimization method, which includes steps S101 to S104.

[0035] S101: Determine the target thread related to user interaction from all candidate threads of the application.

[0036] An application (APP) is typically a collection of multiple programs, each program corresponding to a process, and each process corresponding to at least one thread. That is, a process can be single-threaded or multi-threaded. In essence, a process is an instance; that is, a process can correspond to a function of an application. For example, the video playback function of an application can be a process of that application. Typically, the running process of an application is the main process, and the various functions within the application can be child processes of that main process.

[0037] It's important to note that threads related to user interaction can refer to threads that acquire operational data generated when the user interacts with the application, or threads that output data related to user perception. For the former, user actions can be swiping, clicking, or other actions on a specific screen within the application. In this case, if the application includes threads capable of detecting swipes and clicks, then these threads are considered user-interaction related threads. For the latter, outputting user-perceived data can be data that can be perceived by the user's hearing or vision, such as audio or video data.

[0038] In addition, the thread related to user interaction can also be a thread related to the various display interfaces of the application, that is, a thread that serves the display interface. For example, taking a video playback interface of the application as an example, if the video playback interface has a video playback control, then the thread that serves the video playback control to enable the video playback control to play the video belongs to the target thread related to user interaction.

[0039] The aforementioned user operation-related data, user-perceptible data, or application interface all fall under the category of user interaction-related data. Threads that generate or acquire this data will be more noticeably slower than background threads that do not interact with the user. Therefore, this application embodiment searches for target threads related to user interaction from all candidate threads of the application as analysis files. Then, it identifies hotspot code from the analysis files for pre-compilation to ensure that the operation of functional modules in the application that are clearly perceptible to the user does not experience slowdowns.

[0040] S102: Obtain the running parameters of all code units corresponding to each target thread.

[0041] It is understandable that code can be understood as functions, methods, or classes in the application's source code. The execution parameters of a code unit can be data that characterizes the popularity of that code unit, obtained statistically during its execution. For example, these parameters can include at least one of execution frequency and runtime. The execution frequency of a code unit refers to the ratio of the number of times the code unit is executed within a preset time period to the duration of that preset time period, reflecting how frequently the code unit is used. This execution frequency is positively correlated with the popularity of the code unit. Similarly, the runtime of a code unit can be the duration for which the code is executed within a preset time period, also reflecting how frequently the code unit is used. This execution frequency is also positively correlated with the popularity of the code unit. Specifically, the preset time period can refer to the period from when the application is started to when it is closed, that is, the period from when the application's main process is started to when it is terminated. In this case, the execution parameters are obtained in real-time based on statistics during the current execution of the application. Alternatively, the preset time period can also be a preset time length before the execution of step S102. In this case, the execution parameters are obtained statistically based on the historical execution data of the code unit.

[0042] Of course, the running parameter can also be other parameters that can characterize the usage frequency of the code unit. For example, in addition to the running frequency and running time mentioned above, the running parameter can also be the running peak value. The running peak value can refer to the highest point of the curve of the number of times the code unit is run within a preset time period, which represents the maximum number of times the code unit is run within a unit sampling period within the preset time period. Of course, it can also be other parameters that can characterize the usage frequency of the code unit, such as the number of runs, which are not limited here.

[0043] S103: Based on the running parameters of each code unit, find the target code unit that meets the preset conditions from all code units corresponding to each target thread.

[0044] Since the runtime parameters can characterize the frequency of use of a code unit, hot code, which is the code that is frequently used, can be found from all code units corresponding to each target thread based on these runtime parameters. Therefore, the target code unit is the code that is frequently used by the user in the user-related threads of the application.

[0045] It's important to note that each thread corresponds to at least one code unit, which implements the operations of that thread. As mentioned earlier, an application comprises multiple processes, each implementing at least one function of the application. The operations of all threads within each process collectively complete the function corresponding to that process, and all the code within each thread is used to complete its operations. Of course, each code unit can also implement certain functions, which can be considered sub-functions under the function corresponding to the process. For example, if the function of the process is the application's audio playback function, the operation of a code unit under the audio decoding thread of that process is used to decode MP3 format audio. If this code unit is a hotspot, it indicates that users mostly play MP3 format audio files. Therefore, this target code unit represents the frequently executed code in threads related to user interaction operations.

[0046] S104: Compile the target code unit into machine code.

[0047] It should be noted that each of the aforementioned code units is bytecode. Specifically, the code unit can be found in the application's class file. Typically, bytecode is a hexadecimal file and cannot be directly executed by the processor of an electronic device (such as a CPU). The file that the CPU can directly execute is binary code. Therefore, the bytecode needs to be compiled into binary code, i.e., machine code. In the embodiments of this application, after the target code is compiled into machine code, when the application subsequently uses the code unit, the CPU does not need to perform the process of compiling the target code from bytecode to machine code again, but can use the machine code of the target code unit, thereby improving the execution efficiency of the code unit.

[0048] The timing and order in which the operating system counts object code units differs between the two different compilation methods, AOT and JIT. The following sections will explain these two different compilation methods separately.

[0049] As one implementation method, for AOT compilation, the aforementioned obtained runtime parameters can be runtime parameters of code units within a preset time period prior to the current moment. That is, the runtime parameters are obtained based on historical data of code units within the preset time period. Furthermore, the application can be opened and closed multiple times within this preset time period. If we define one startup to shutdown process of the application as one run, then the application can run multiple times within this preset time period. Therefore, the timing for executing S102 and subsequent steps (which can be named the statistical time period) can be between the application's last shutdown and its next startup. Alternatively, it can be when the electronic device is in an IDLE and Charging state; this is not limited here. It should be noted that the shutdown of the application mentioned in this embodiment can refer to the application process being killed, or the application being in a background frozen state. Specifically, the application process runs in the background and is retained in RAM, but its connection with the processor is broken, and the processor does not execute any operations of the application.

[0050] Therefore, for AOT compilation, the electronic device identifies the target code unit (i.e., hotspot code) of the application within the statistical time period. This target code unit is then compiled into machine code and stored. Specifically, the machine code of the target code unit can be stored as a configuration file so that the application can use the machine code in the configuration file to execute the target code unit when it runs later. It should be noted that regardless of whether the application is running within the statistical time period or whether the application is closed after generating the configuration file, the configuration file is not deleted when the application is closed. Therefore, this configuration file, as the machine code obtained from AOT compilation, can be directly used by the application each time it starts, eliminating the need to recompile the target code unit after application startup.

[0051] It should be noted that as users use the application, the runtime parameters of the code units of each target thread will change. Therefore, the configuration file for AOT compilation needs to be updated. For example, an update cycle can be set, such as once every three days or once a week. Based on this update cycle, the electronic device will execute S102 and subsequent steps again when a new update cycle arrives, thereby updating the configuration file.

[0052] As another implementation method, for JIT compilation, since JIT compilation counts hotspot code during the current run of the application after each application startup, and then compiles this hotspot code into machine code, and deletes the machine code after the application is closed, and counts and compiles the hotspot code into machine code again after the application is restarted, JIT compilation is a just-in-time compilation, and the resulting machine code is only used during the current run of the application. Therefore, for JIT compilation, the implementation method for obtaining the running parameters of all code units corresponding to each candidate thread is to obtain the running parameters generated by all code units corresponding to each candidate thread during the current run of the application. Then, after obtaining the machine code of the target code unit during the current run of the application, if the target code unit is run again before the application is closed, the machine code can be used directly. For example, suppose the target thread of an application corresponds to code unit A and code unit B. During the current run of the application, the accumulated runtime parameters of code unit A during the 5th run meet the preset conditions. Then, code unit A is used as the target code unit and compiled into machine code. During the current run of the application, code unit A must be compiled each time it is executed from the 1st to the 5th execution. After the machine code is used, it is deleted. After the 5th execution, code unit A is compiled into machine code and stored, that is, stored in the configuration file. In the 6th execution, it is not necessary to perform a compilation operation; the machine code can be directly obtained from the configuration file until the application is closed.

[0053] Similarly, when the application is installed for the first time, the target code units can be obtained and compiled based on the aforementioned steps. It should be noted that if the compilation method is JIT, the compilation process is no different from that of JIT. If the compilation method is AOT, since the current running parameters are initial values, for example, all of them are 0, the target code units are all the code units of each target thread related to user interaction among all the candidate threads of the application. Although all the code units of each target thread are compiled when the application is installed for the first time, the compiled configuration file is smaller and more targeted compared to the traditional AOT method that compiles all the code units of the application.

[0054] Therefore, embodiments of this application can determine the target thread related to user interaction among all candidate threads of the application, obtain the running parameters of all code units corresponding to each target thread, and, based on the running parameters of each code unit, search for target code units that meet preset conditions from all code units corresponding to each target thread. In other words, the hotspot code, i.e., the target code unit, determined in this application is based on the thread related to user interaction in the application. Then, the target code unit is compiled from bytecode into machine code. When the application subsequently executes the target code unit, it can directly use the pre-compiled machine code without having to recompile it. Therefore, the target code unit determined from the thread related to user interaction, and pre-compiled into machine code for that target code unit, makes the target code unit run more smoothly, thereby allowing the user to better perceive the superior user experience brought by the smooth code.

[0055] Specifically, please refer to Figure 2 , Figure 2 An embodiment of this application provides a compilation optimization method, which includes steps S201 to S205.

[0056] S201: Determine the function corresponding to each of the candidate threads in the application.

[0057] It should be noted that the functions corresponding to the candidate threads can be referred to the functional modules corresponding to the threads described in the previous embodiments. In other words, the display of each area of ​​the application, the operation of each control, and even the processing of each data can be regarded as a functional module, and each thread is composed of code units that implement the functions corresponding to each thread.

[0058] S202: From all threads in the application, find the candidate thread that belongs to the specified function and select it as the target thread.

[0059] Among them, the thread for the specified function is used for user interaction. That is to say, the implementation of the specified function of the application will interact with the user. For example, it may be a function triggered by user operation, or there may be a sensory interaction with the user such as vision, touch, and hearing. Therefore, whether the process of implementing the specified function of the application executes smoothly can directly affect the user's sensory experience. For example, if the specified function is touch response, if the thread corresponding to the touch response is lagging, it may be possible that when the user triggers the touch response, the application does not respond at all, or the response is delayed. This will lead to a very poor user experience. Moreover, the user's sensory perception of this touch is very obvious. That is to say, the specified function is a function that the user can easily perceive, or a function that the user perceives clearly.

[0060] As one implementation method, the specified functions include at least one of the following: interface sliding function, touch response function, audio playback function, recording function, image acquisition function, and video playback function. Among them, the interface sliding function and touch response function belong to user tactile interaction, the audio playback function and recording function include user auditory interaction, and may even include tactile interaction, the image acquisition function and video playback function belong to user visual interaction, and may even include tactile interaction and auditory interaction. Therefore, user interaction can include at least one of user tactile interaction, user auditory interaction and user visual interaction.

[0061] Specifically, either after obtaining the application's installation package or after the application is installed, the functional modules served by each thread within the application can be analyzed to determine the function corresponding to each thread. Then, based on the function corresponding to each candidate thread in the application, a candidate thread belonging to the specified function is searched from all threads in the application as the target thread. Since the target thread serves the user interaction-related functions in the application, pre-compiling for the target thread can improve the smoothness of the target thread's operation, thereby improving the user's experience of using the user interaction-related functions in the application. This allows the application to pay more attention to the actual user experience and perform targeted pre-compilation operations.

[0062] For example, the specific functions of an application can be determined based on its type. For instance, for a video playback application, the specified functions could be at least one of the following: interface swiping, touch response, image capture, and video playback. It should be noted that the application category can be set by the application developer during development, or it can be set by the user after the application is installed on the electronic device. For example, after a user installs an application on their electronic device and enters the application, a dialog box will appear instructing the user to set the application's category. The specific category the application belongs to can be set by the user according to their needs. For example, a user can set a social networking software to audio, video, or social networking.

[0063] Additionally, electronic devices often have application installer software installed, such as the App Store on iOS. This installer software contains a list of applications that users can download, update, and open. Furthermore, it can categorize applications by type, such as audio, video, or games. Therefore, users are already aware of the application's category when installing it using this installer software.

[0064] Furthermore, considering that some applications can play both video and audio, if an application supports video playback, its type will be set to video; if it only supports audio playback, its type will be set to audio. Specifically, whether an application supports video playback can be determined by examining its feature description, such as supported playback formats, or by checking if a video playback module is present within the application's program modules, such as the encoding / decoding algorithm used for a particular video.

[0065] Furthermore, if some applications have diverse functions, their category needs to be determined based on their specific operational behavior. For example, if some applications can play both video and audio, such as some video playback software that can play both audio files and videos, then the category of the application can be determined based on the application's usage history. That is, based on the application's usage history over a certain period of time, it can be determined whether the user prefers to play video or audio when using the application.

[0066] Specifically, the system acquires the operational behavior data of all users within a preset time period. Here, "all users" refers to all users who have installed the application. This operational behavior data can be obtained from the server corresponding to the application. In other words, when a user uses the application, they log in with their corresponding user account, and the operational behavior data associated with that user account is sent to the application's server. The server then stores the acquired operational behavior data in association with the corresponding user account. In some embodiments, the electronic device sends an operational behavior query request for the application to the application's server, and the server sends the operational behavior data of all users within a certain preset time period to the electronic device.

[0067] The operation behavior data includes the name and time of the played audio files and the name and time of the played video files. By analyzing this operation behavior data, the number of audio files played by the application and the total time can be determined within a certain preset time period. The number of video files played by the application and the total time can also be obtained. Based on the proportion of the total playback time of audio and video files within the preset time period, the application category is determined. Specifically, the proportion of the total playback time of audio and video files within the preset time period is obtained. For ease of description, the proportion of the total playback time of audio files within the preset time period is recorded as the audio playback proportion, and the proportion of the total playback time of video files within the preset time period is recorded as the video playback proportion. If the video playback proportion is greater than the audio playback proportion, the application category is set to video type; if the audio playback proportion is greater than the video playback proportion, the application category is set to audio type. For example, if the preset time period is 30 days, or 720 hours, and the total playback time of audio files is 200 hours, then the audio playback ratio is 27.8%, and the total playback time of video files is 330 hours, then the video playback ratio is 45.8%. Since the video playback ratio is greater than the audio playback ratio, the application category is set to video type.

[0068] Therefore, after determining the type of application in this application, the specified function corresponding to the application in this embodiment of the application is determined based on the pre-defined correspondence between the application type and the specified function, which serves as the basis for determining the target thread.

[0069] As one implementation method, user perception can be divided into direct perception and indirect perception. Direct perception refers to the user's perception of the thread corresponding to the function of the application running on the screen, while indirect perception refers to the user's perception of the thread used by the component corresponding to the function of the application running on the screen. For example, the user's perception of a display component on a certain interface is direct perception. However, if the first component of the application calls other threads while running, for example, if the called thread also displays a component (denoted as the second component), the user's perception of the second component is direct perception, while the perception of the first component is indirect perception. It should be noted that both direct and indirect perception are considered obvious user perception.

[0070] Therefore, for situations involving indirect perception, in this embodiment of the application, for candidate threads in the application that do not belong to the functional modules corresponding to the specified function, the indirectly perceived threads can also be used as target threads for subsequent optimization. Specifically, each candidate thread corresponding to a functional module that does not belong to the specified function is determined as a first thread; a second thread is searched from each first thread, wherein the second thread needs to call other threads and wait for the return results of other threads; all second threads are traversed, and if the functional modules corresponding to all called threads of the second thread contain the functional module of the specified function, then the second thread is determined as the target thread. Specifically, the second thread is a thread that has a direct or indirect calling relationship with the first thread. In addition, when traversing the second threads, the calling hierarchy between each second thread and the first thread can be used as a basis. For example, the thread directly called by the first thread belongs to the first level, the other threads called by the thread directly called by the first thread belong to the second level, and so on. During the traversal of the second threads, the function corresponding to each second thread is determined. Once a second thread with the specified function is found, the traversal can be stopped and the first thread can be determined as the target thread.

[0071] It's important to note that electronic devices may run multiple threads simultaneously, and these threads may interact with each other. For example, consider threads A, B, and C. Thread A might call a Remote Procedure Call (RPC) service to thread B, while thread B waits for thread C to release a lock, and thread C waits to be scheduled for execution by the CPU. In this case, there is an interaction between threads A, B, and C. It can be seen that thread A directly calls thread B, and thread C is called by thread B. In other words, thread A indirectly calls thread C. Therefore, if thread A is the first thread, then threads B and C are both second threads.

[0072] Furthermore, at least two threads can form a thread chain, and each thread in the thread chain can be considered a node. Nodes with interactive relationships can have edge relationships. This thread chain can include at least two threads and the interactive relationships between each thread in the chain. The interactive relationships between threads can manifest as a calling relationship. For example, if thread A and thread B have an interactive relationship, it could mean that thread A needs to call thread B, thread B needs to call thread A, or thread A and thread B can call each other. Specifically, the edges between nodes can be directional, representing the calling relationship between the threads corresponding to the nodes. Specifically, the direction of the edge between two nodes is from the caller to the receiver. For example, if there is an edge between the first node and the second node pointing from the first node to the second node, it can represent that the thread corresponding to the first node has a calling relationship with the thread corresponding to the second node. For example, if node A initiates a data request to node B, then node A is the caller and node B is the receiver; therefore, the edge between node A and node B can be from node A to node B. Optionally, a node can act as both a caller and a call receiver. For example, nodes A and B can call each other, meaning that both nodes A and B are both callers and receivers. In this case, the edge between nodes A and B can point from node A to node B, and vice versa.

[0073] For an example, please refer to Figure 3 , Figure 3 A schematic diagram of a thread chain is shown. Figure 3 The network includes nodes A, B, and C. If node A needs to call node B, and node B needs to call node C, then in the node link formed by nodes A, B, and C, there can be an edge between node A and node B pointing from node A to node B, and there can be an edge between node B and node C pointing from node B to node C.

[0074] For example, threads can communicate with each other through inter-process communication (IPC) mechanisms. Specifically, remote procedure calls enable interaction between client and service programs, thereby achieving various system-level functions such as playing music and refreshing the interface. Currently, operating systems (e.g., Android) implement RPC functionality through the Binder mechanism. Specifically, Binder communication involves two processes: Client and Service. Client and Service are relative; the message sender is the Client, and the message receiver is the Service. RPC access between the client and server is based on the operating system's inter-process communication mechanism.

[0075] As one implementation method, the operating system's profiling tool can be used to view the call relationships between various threads. The profiling tool can display the functions executed by a thread, the target thread it depends on (e.g., SystemServer), and the functions called by RPC (e.g., functions in SystemServer).

[0076] For example, suppose an application currently displays multiple display areas on an electronic device's screen, each display area corresponding to at least one component, and all components within each display area serve to refresh and display the content of that display area. Figure 4As shown, the interface includes four display areas, named Area 1 (301), Area 2 (302), Area 3 (303), and Area 4 (304). Area 1 is the top status display area. Compared to Areas 2 and 3, the content displayed in Area 1 updates less frequently. Area 2 displays the video content currently playing on the screen. Area 3 displays comments from viewers on the video content. Area 4 displays a content input component, allowing the user to input content. Specifically, Area 2 includes a video playback component with corresponding video playback functionality. Area 3 includes a text display component, a sliding component, and a touch response component. Therefore, the threads corresponding to the video playback component in Area 2, the sliding and touch response components in Area 3, and the content input component in Area 4 all belong to the target thread. Specifically, if the update frequency of the displayed content of a component is set to be greater than a preset frequency, the component can be considered a component directly perceived by the user, and the thread corresponding to the component can be used as the target thread. The update frequency of the displayed content of the video playback component in the second area is greater than the preset frequency, while the sliding component and touch response component in the third area and the content input component in the fourth area belong to the interface sliding function and touch response function. Therefore, the threads corresponding to the sliding component and touch response component in the third area and the content input component in the fourth area should belong to the target thread.

[0077] The content display component in the first area updates less frequently than the preset frequency. Therefore, the content displayed by this component is not directly perceived by the user. However, the thread of the first area's content display component calls a preset thread, whose function is to count the number of viewers in the first area. For example... Figure 4 The displayed view count is 10. When a certain number of viewers is reached, a pop-up window will appear, such as... Figure 5 As shown, the pop-up window displays "Prompt: The number of viewers has exceeded 1,000". Therefore, it can be seen that the preset thread is also a functional module that serves a specific function. Thus, the thread corresponding to the content display component in the first area is a thread that is indirectly perceived by the user. Therefore, the thread corresponding to the content display component in the first area is also used as the target thread.

[0078] It should be noted that before determining the target thread related to user interaction among all candidate threads of the application, it is necessary to first determine candidate threads from all threads of the application. In some embodiments, all threads of the application can be used as candidate threads. In other embodiments, considering that the application has multiple interfaces, but the interface used by the user is relatively fixed, the thread applicable to the specified interface of the application can be searched from all threads of the application as the candidate thread. The specified interface can be the interface used by the user within a first preset time period. This first preset time period can be the time period from the moment the application is launched to the current moment, or it can be the time period within a first preset time length before the current moment, which can be set based on actual usage needs. Additionally, the specified interface can also be the interface currently displayed by the application. In yet another embodiment, the specified interface can be the interface of the application whose usage frequency is greater than a specified frequency. Specifically, it can be determined by statistically analyzing the usage frequency of each interface of the application within a second preset time period, and selecting the interface with a usage frequency greater than the specified frequency as the specified interface. The second preset time period can be the time period from when the application is installed to the current moment, or it can be the time period within a second preset time length before the current moment, which can be set based on actual usage needs.

[0079] S203: Obtain the execution parameters of all code units corresponding to each target thread.

[0080] S204: Based on the running parameters of each code unit, find the target code unit that meets the preset conditions from all code units corresponding to each target thread.

[0081] The execution parameters of a code unit include at least one of the execution frequency and runtime. The execution frequency refers to the number of times the code is executed per unit of time, and the runtime refers to the total duration for which the code is executed. Specifically, the implementation methods for the execution frequency and runtime can be found in the foregoing embodiments.

[0082] As one implementation method, the running parameters of the code unit include the running frequency of the code unit. Based on the running parameters of each code unit, one implementation method for finding target code units that meet preset conditions from all code units corresponding to each target thread can be to find code units whose running frequency is greater than a first threshold from all code units corresponding to each target thread, and use these as target code units. The first threshold can be set based on actual needs and is not limited here.

[0083] As another implementation, the runtime parameters of the code unit include the runtime of the code unit. One implementation of finding a target code unit that meets the preset conditions from all code units corresponding to each target thread is to find a code unit whose runtime is greater than a second threshold from all code units corresponding to each target thread, and use it as the target code unit.

[0084] In another implementation, the running parameters of the code unit include the running frequency and runtime of the code unit. One implementation for finding target code units that meet preset conditions from all code units corresponding to each target thread is to find code units whose running frequency is greater than a first threshold and whose runtime is greater than a second threshold, and use these as target code units. Alternatively, after determining the running frequency and runtime of each code unit, a weighted sum of the runtime and running frequency of each code unit is taken to obtain a score value for each code unit. The score value of each code unit is positively correlated with its popularity. Then, each code unit is sorted in descending order of its score value, and the top N code units in the sorted list are taken as target code units, where N is a positive integer, and the specific value is not limited here.

[0085] S205: Compile the target code unit into machine code.

[0086] Therefore, the embodiments of this application can reduce the size of the compiled code file while improving the execution efficiency of the application code, thereby improving the running performance of the application and reducing the storage pressure of the machine code file on the electronic device.

[0087] Please see Figure 6 The diagram illustrates a structural block diagram of a compiler optimization device 600 provided in an embodiment of this application. The device may include: a determining unit 601, an acquiring unit 602, a searching unit 603, and a compiling unit 604.

[0088] The determining unit 601 is used to determine the target thread related to user interaction among all candidate threads of the application.

[0089] Furthermore, the determining unit 601 is also configured to determine the function corresponding to each of the candidate threads in the application; and to search for candidate threads belonging to a specified function from all threads in the application, as target threads, wherein the thread with the specified function is used for user interaction. The specified function includes at least one of the following: interface swiping function, touch response function, audio playback function, recording function, image acquisition function, and video playback function.

[0090] Furthermore, the determining unit 601 is also used to determine the candidate thread corresponding to each functional module that does not belong to the specified function as the first thread; to search for the second thread from each first thread, wherein the second thread needs to call other threads and wait for the return result of other threads; to traverse all the second threads, and if the functional module corresponding to all the called threads of the second thread contains the functional module of the specified function, then the second thread is determined as the target thread.

[0091] Furthermore, the determining unit 601 is also configured to, before determining the target thread related to user interaction among all candidate threads of the application, search for a thread applicable to a specified interface of the application as a candidate thread. The specified interface is an interface of the application whose usage frequency is greater than a specified frequency.

[0092] The acquisition unit 602 is used to acquire the running parameters of all code units corresponding to each target thread.

[0093] The search unit 603 is used to search for target code units that meet preset conditions from all code units corresponding to each target thread, based on the running parameters of each code unit. The running parameters of the code unit include at least one of the code unit's running frequency and running duration.

[0094] Furthermore, the running parameters of the code unit include the running frequency of the code unit, and the search unit 603 is also used to search for code units with a running frequency greater than a first threshold from all code units corresponding to each target thread, and use them as target code units.

[0095] Furthermore, the runtime parameters of the code unit include the runtime of the code unit, and the search unit 603 is also used to search for code units with a runtime greater than a second threshold from all code units corresponding to each target thread, as target code units.

[0096] Compilation unit 604 is used to compile the target code unit into machine code.

[0097] Furthermore, the compilation unit 604 is also configured to store the machine code of the target code unit as a configuration file, so that when the application runs later, it uses the machine code in the configuration file to execute the target code unit.

[0098] Furthermore, the compilation unit 604 is also used to obtain the running parameters generated by all code units corresponding to each candidate thread during the current run of the application.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0100] In the several embodiments provided in this application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0101] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0102] Please refer to Figure 7 This document illustrates a structural block diagram of an electronic device according to an embodiment of this application. The electronic device 100 can be a smartphone, tablet computer, e-reader, or other electronic device capable of running applications. The electronic device 100 in this application may include one or more of the following components: a processor 110, a memory 120, and one or more applications, wherein the one or more applications can be stored in the memory 120 and configured to be executed by one or more processors 110, and the one or more applications are configured to perform the methods described in the foregoing method embodiments.

[0103] Processor 110 may include one or more processing cores. Processor 110 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data of the electronic device 100 by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 110 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately using a communication chip.

[0104] The memory 120 may include random access memory (RAM) or read-only memory (ROM). The memory 120 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the terminal 100 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0105] Please refer to Figure 8 This diagram illustrates a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable medium 800 stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0106] The computer-readable storage medium 800 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 800 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 800 has storage space for program code 810 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 810 may be compressed, for example, in a suitable form.

[0107] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A compiler optimization method, characterized in that, include: Determine the function corresponding to each candidate thread in the application; Based on the type of the application, determine the specified function corresponding to the application; From all candidate threads in the application, find the candidate thread belonging to the specified function and use it as the target thread, wherein the thread for the specified function is used for user interaction; Identify the candidate thread for each functional module that does not belong to the specified function, and designate it as the first thread; Find the second thread from each of the first threads, wherein the second thread needs to call other threads through inter-process communication mechanisms and wait for the return results of other threads; Iterate through all the second threads. If any called thread corresponds to a functional module that belongs to the specified function, then the second thread is identified as the target thread and the iteration stops. Obtain the running parameters of all code units corresponding to each target thread, wherein each thread corresponds to at least one code unit, and all code units of each thread are used to complete the operation of that thread; Based on the running parameters of each code unit, target code units that meet preset conditions are searched from all code units corresponding to each target thread; The target code unit is compiled into machine code.

2. The method according to claim 1, characterized in that, The specified functions include at least one of the following: interface sliding function, touch response function, audio playback function, recording function, image acquisition function, and video playback function.

3. The method according to claim 1, characterized in that, Before determining the target thread related to user interaction among all candidate threads of the application, the process further includes: Find the thread that applies to the specified interface of the application from all threads of the application, and select it as the candidate thread.

4. The method according to claim 3, characterized in that, The specified interface is the interface of the application that is used more frequently than the specified frequency.

5. The method according to claim 1, characterized in that, The operating parameters of the code unit include at least one of the code unit's operating frequency and operating time.

6. The method according to claim 5, characterized in that, The running parameters of the code unit include the running frequency of the code unit. Based on the running parameters of each code unit, target code units that meet preset conditions are searched from all code units corresponding to each target thread, including: From all the code units corresponding to each target thread, find the code units whose execution frequency is greater than the first threshold, and use them as target code units.

7. The method according to claim 6, characterized in that, The runtime parameters of the code unit include the runtime of the code unit. Based on the runtime parameters of each code unit, target code units that meet preset conditions are searched from all code units corresponding to each target thread, including: From all code units corresponding to each target thread, find code units with a runtime longer than the second threshold and use them as target code units.

8. The method according to claim 1, characterized in that, After compiling the target code unit into machine code, the process further includes: The machine code of the target code unit is stored as a configuration file so that the application can execute the target code unit using the machine code in the configuration file when it runs later.

9. The method according to claim 1, characterized in that, The machine code of the target code unit is used to be executed during the current run of the application. Obtaining the execution parameters of all code units corresponding to each candidate thread includes: Obtain the runtime parameters generated by all code units corresponding to each candidate thread during the current run of the application.

10. A compiler optimization apparatus, characterized in that, include: The determining unit is used to determine the function corresponding to each candidate thread in the application. Based on the type of the application, determine the specified function corresponding to the application; From all candidate threads in the application, find the candidate thread belonging to the specified function and designate it as the target thread, wherein the thread of the specified function is used for user interaction; determine the candidate thread corresponding to each functional module that does not belong to the specified function and designate it as the first thread; find the second thread from each first thread, wherein the second thread needs to call other threads through the inter-process communication mechanism and wait for the return result of other threads; traverse all second threads, and if the functional module corresponding to any called thread belongs to the specified function, then determine the second thread as the target thread and stop traversing; The acquisition unit is used to acquire the running parameters of all code units corresponding to each target thread, wherein each thread has at least one code unit, and all code units of each thread are used to complete the operation of the thread; The search unit is used to search for target code units that meet preset conditions from all code units corresponding to each target thread, based on the running parameters of each code unit. A compilation unit is used to compile the target code unit into machine code.

11. An electronic device, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the method as described in any one of claims 1-9.

12. A computer-readable medium, characterized in that, The computer-readable medium stores processor-executable program code, which, when executed by the processor, causes the processor to perform the method according to any one of claims 1-9.

13. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method described in any one of claims 1-9.

Images