CN115543334B

CN115543334B - Compiling optimization method and electronic equipment

Info

Publication number: CN115543334B
Application number: CN202211134773.XA
Authority: CN
Inventors: 邹雄杰; 黄德志
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-09-19
Filing date: 2022-09-19
Publication date: 2023-10-27
Anticipated expiration: 2042-09-19
Also published as: CN115543334A

Abstract

The embodiment of the application provides a compiling optimization method and electronic equipment. In the method, when compiling and optimizing an application, in a java layer PMS, a mutual exclusion lock required to be held by a thread is only used for locking and protecting an Installd daemon to execute compiling and optimizing operation, and in a native layer Installd daemon, a mutual exclusion lock required to be held by the thread is only used for locking and protecting a file involved in the Installd daemon to execute the compiling and optimizing operation. Thus, when the application is compiled and optimized, the thread does not need to hold a global lock, and other threads can be executed without waiting for the completion of the compiling of the application, so that the lock competition problem in the application optimization is reduced.

Description

Compiling optimization method and electronic equipment

Technical Field

The application relates to the technical field of intelligent terminals, in particular to a compiling optimization method and electronic equipment.

Background

Dex2oat (dalvik excutable file to optimized art file) is a program that compiles and optimizes a Dex (binary byte code) file. The Dex2oat compilation tool is an important module in Android Run Time (ART). Through compiling optimization, daily use experience of a user on an Android mobile phone can be improved, such as application installation speed, starting speed, smoothness in the application use process and the like.

However, during the Dex2oat compilation process, related methods in the packet management service (Package Manager Service, PMS) may always hold the lock (msitallock), so that other methods or operations in the PMS that need to hold the lock cannot be performed due to the lock, and even problems such as system blocking, slow system response, ANR (Application Not Response, application unresponsiveness) may occur due to the long-time lock.

Disclosure of Invention

In order to solve the technical problems, the embodiment of the application provides a compiling optimization method and electronic equipment. In the method, when the application is compiled and optimized, the thread does not need to hold a global lock and holds independent exclusive locks only related to the compiling and optimizing, so that other threads can be executed without waiting for the completion of compiling the application, and the lock competition problem during the application optimizing is reduced.

In a first aspect, an embodiment of the present application provides a compiling optimization method, applied to an electronic device, where a system of the electronic device is an android system, including:

a first thread in the PMS applies for holding a first mutual exclusion lock in the PMS, and submits a compiling optimization task to a software package Installer instructor after holding the first mutual exclusion lock; the first mutual exclusion lock is only used for locking and protecting the Installld daemon to execute compiling optimization operation;

A second thread in the instrler applies for a second exclusive lock in the instred daemon, and requests the instred daemon to execute compiling optimization operation after the second exclusive lock is held; the second mutual exclusion lock is only used for locking and protecting files involved in the execution of compiling optimization operation by the Installld daemon.

Illustratively, the first mutex lock is hereinafter the NewjavaLock lock in the java layer PMS of fig. 6, and the second mutex lock is hereinafter the mDexOptLock in the native layer instrumentation daemon of fig. 7.

Thus, in the java layer PMS, the mutual exclusion lock required to be held by the thread is only used for locking and protecting the Installd daemon to execute the compiling and optimizing operation, and in the native layer Installd daemon, the mutual exclusion lock required to be held by the thread is only used for locking and protecting the files involved in the compiling and optimizing operation executed by the Installd daemon. Furthermore, when the application is compiled and optimized, the thread does not need to hold a global lock, and other threads can be executed without waiting for the completion of the compiling of the application, so that the lock competition problem in the application optimization is reduced.

According to the first aspect, the PMS further includes a third exclusive lock, and the third exclusive lock is used for locking and protecting access to the instrunt daemon, where the access to the instrunt daemon does not include a request for the instrunt daemon to perform a compiling optimization operation;

The instred daemon also comprises a fourth mutual exclusion lock, wherein the fourth mutual exclusion lock is used for locking and protecting files accessed by the instred daemon, and the files accessed by the instred daemon do not comprise files involved in compiling and optimizing operations executed by the instred daemon.

Illustratively, the third mutex lock is the mInstalLock in the Java layer PMS of FIG. 6 below, and the fourth mutex lock is the mLock in the native layer Instald daemon of FIG. 7.

In this way, the first mutual exclusion lock and the third mutual exclusion lock in the Java layer PMS are mutually independent, and the second mutual exclusion lock and the fourth mutual exclusion lock in the native layer Inlitald daemon are mutually independent, so that the lock competition problem in application optimization is effectively reduced.

According to a first aspect, or any implementation manner of the first aspect, after the first line Cheng Chiyou first mutual exclusion lock, the method further includes: the third line Cheng Shenqing in the PMS holds a third exclusive lock and performs a corresponding operation after holding the third exclusive lock; wherein the third thread is for performing a non-compiled optimization operation.

In this way, in the java layer, as the first mutual exclusion lock and the third mutual exclusion lock are mutually independent, the threads executing the dexopt task cannot be influenced by other threads executing the non-dexopt task even if the threads executing the dexopt task are locked for a long time, and the problem of thread blocking caused by the threads executing the non-dexopt task due to long-time waiting is avoided.

According to a first aspect, or any implementation manner of the first aspect, after the first line Cheng Chiyou first mutual exclusion lock, the method further includes: a fourth line Cheng Shenqing in the PMS holds the first exclusive lock and waits for the first exclusive lock;

after the fourth line Cheng Chiyou first mutex lock, submitting the compile optimization task to an instrer; the fourth thread is used for executing compiling optimization tasks.

According to a first aspect, or any implementation manner of the first aspect, after the second thread holds the second exclusive lock, the method further includes: a fifth thread in the instrler applies for holding a fourth exclusive lock, and requests the instred daemon to execute corresponding operation after holding the fourth exclusive lock; the fifth thread is used for requesting the executed daemon to execute the non-compiling optimization operation, and the file related to the non-compiling optimization operation does not conflict with the file related to the compiling optimization operation.

In this way, in the native layer, since the second exclusive lock and the fourth exclusive lock are independent of each other, the thread performing the dex2oat operation cannot affect other threads performing the non-dex 2oat operation (the file operated by the thread is irrelevant to the dex2oat file) even if the thread performing the dex2oat operation is held for a long time, so that the problem of thread blocking caused by long-time waiting of the threads performing the non-dex 2oat operation is avoided.

According to a first aspect, or any implementation manner of the first aspect, after the second thread holds the second exclusive lock, the method further includes:

a sixth thread in the instrler applies for holding a fourth mutual exclusion lock, applies for holding a second mutual exclusion lock after holding the fourth mutual exclusion lock, and waits for the second mutual exclusion lock; after the sixth thread holds the second exclusive lock, requesting the executed daemon to execute a corresponding operation; the sixth thread is used for requesting the executed daemon to execute the non-compiling optimization operation, and the file related to the non-compiling optimization operation conflicts with the file related to the compiling optimization operation.

Thus, at the native layer, since the second exclusive lock and the fourth exclusive lock are independent of each other, if a file involved in a thread executing a non-dex 2oat operation collides with a file involved in a thread executing a dex2oat operation, the thread executing the non-dex 2oat operation needs to hold the second exclusive lock in addition to the fourth exclusive lock, so that the synchronism of the file involved in the dex2oat operation can be ensured. Moreover, as the thread requesting dex2oat operation does not need to hold the fourth global mutex lock, the phenomenon of occupying the global lock for a long time does not occur.

According to a first aspect, or any implementation manner of the first aspect, after the second thread holds the second exclusive lock, the method further includes: a seventh thread in the instrler applies for holding a second mutual exclusion lock and waits for the second mutual exclusion lock; after the seventh thread holds the second mutex lock, the instrumented daemon is requested to perform a compilation optimization operation.

The seventh thread requests that the accounting perform the dex2oat operation, and although the dexoat file corresponding to the operation does not conflict with the dexoat file corresponding to the second thread request operation, only one process for executing the dex2oat needs to be controlled, so the seventh thread needs to apply for holding the second mutex lock. After the execution of the dex2oat operation requested by the second thread is completed, the second exclusive lock is released, and the thread 6 can request the instrd to continue to execute the dex2oat operation after holding the second exclusive lock.

According to the first aspect, or any implementation manner of the first aspect, when the second exclusive lock is idle, the method further includes:

an eighth thread in the instrler applies for holding a fourth mutual exclusion lock, and applies for holding a second mutual exclusion lock after holding the fourth mutual exclusion lock; after the eighth thread holds the second exclusive lock, requesting the executed daemon to execute corresponding operations; the eighth thread is used for requesting the executed daemon to execute the non-compiling optimization operation, and the file related to the non-compiling optimization operation conflicts with the file related to the compiling optimization operation.

In this way, if the thread requesting the executed daemon to execute the non-compiling optimization operation has a conflict with the file related to the compiling optimization operation in the case that the second exclusive lock is idle, the thread directly acquires the second exclusive lock after the fourth exclusive lock can be applied to continue to execute the corresponding operation.

In a second aspect, an embodiment of the present application provides an electronic device. The electronic device includes: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored on the memory, which when executed by the one or more processors, cause the electronic device to perform the compilation optimization method of any of the first aspect and the first aspect.

Any implementation manner of the second aspect and the second aspect corresponds to any implementation manner of the first aspect and the first aspect, respectively. The technical effects corresponding to the second aspect and any implementation manner of the second aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a third aspect, embodiments of the present application provide a computer-readable storage medium. The computer readable storage medium comprises a computer program which, when run on an electronic device, causes the electronic device to perform the compilation optimization method of any of the first aspect and the first aspect.

Any implementation manner of the third aspect and any implementation manner of the third aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation manner of the third aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a fourth aspect, embodiments of the present application provide a computer program product comprising a computer program which, when run, causes a computer to perform the compilation optimization method of any of the first or second aspects.

Any implementation manner of the fourth aspect and any implementation manner of the fourth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fourth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

In a fifth aspect, the present application provides a chip comprising processing circuitry, transceiver pins. Wherein the transceiver pin and the processing circuit communicate with each other via an internal connection path, the processing circuit performing the compilation optimization method as in the first aspect or any one of the first aspects to control the receiving pin to receive signals and to control the transmitting pin to transmit signals.

Any implementation manner of the fifth aspect and any implementation manner of the fifth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fifth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

Drawings

Fig. 1 is a schematic diagram of a hardware structure of an electronic device exemplarily shown;

FIG. 2 is a schematic diagram of a software architecture of an exemplary electronic device;

FIG. 3 is a flow diagram illustrating an exemplary installation application;

FIG. 4 is a schematic diagram illustrating lock-holding when compile optimization is applied in the prior art;

FIG. 5 is a diagram illustrating the contention for a java lock in a PMS;

FIG. 6 is a schematic diagram illustrating the unlocking of a java lock in a PMS;

FIG. 7 is a schematic diagram illustrating the unlocking of a native lock in Installd;

FIG. 8 is a schematic diagram illustrating lock-holding when compile optimization is applied in an embodiment of the present application;

FIG. 9 is a diagram illustrating lock contention during application of compile optimization;

FIG. 10 is a diagram illustrating lock contention during application of compile optimization;

FIG. 11 is a diagram illustrating lock contention during application of compile optimization;

FIG. 12 is a diagram illustrating lock contention during application of compile optimization;

FIG. 13 is a diagram illustrating lock contention during application of compile optimization;

FIG. 14 is a diagram illustrating lock contention during application of compile optimization.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone.

The terms first and second and the like in the description and in the claims of embodiments of the application, are used for distinguishing between different objects and not necessarily for describing a particular sequential order of objects. For example, the first target object and the second target object, etc., are used to distinguish between different target objects, and are not used to describe a particular order of target objects.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. For example, the plurality of processing units refers to two or more processing units; the plurality of systems means two or more systems.

The method provided by the embodiment of the application can be applied to electronic equipment such as mobile phones, tablet computers, wearable equipment, vehicle-mounted equipment, augmented reality (augmented reality, AR)/Virtual Reality (VR) equipment, notebook computers, ultra-mobile personal computer (UMPC), netbooks, personal digital assistants (personal digital assistant, PDA) and the like, and the embodiment of the application does not limit the specific type of the electronic equipment.

Fig. 1 is a schematic diagram of an electronic device 100. Alternatively, the electronic device 100 may be a terminal, which may also be referred to as a terminal device, and the present application is not limited thereto. It should be understood that the electronic device 100 shown in fig. 1 is only one example of an electronic device, and that the electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations. The various components shown in fig. 1 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

The electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an acceleration sensor, a temperature sensor, a motion sensor, a barometric sensor, a magnetic sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

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

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

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices, etc.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charge management module 140 may receive a charging input of a wired charger through the USB interface 130. In some wireless charging embodiments, the charge management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques.

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

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

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

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

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

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions.

The internal memory 121 may be used to store computer executable program code including instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121, for example, to cause the electronic device 100 to implement a compiling method in an embodiment of the application. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals. The electronic device 100 may listen to music, or to hands-free conversations, through the speaker 170A. In some embodiments, the electronic device 100 may be provided with a plurality of speakers 170A.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal. When electronic device 100 is answering a telephone call or voice message, voice may be received by placing receiver 170B in close proximity to the human ear.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can sound near the microphone 170C through the mouth, inputting a sound signal to the microphone 170C. The electronic device 100 may be provided with at least one microphone 170C. In other embodiments, the electronic device 100 may be provided with two microphones 170C, and may implement a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may also be provided with three, four, or more microphones 170C to enable collection of sound signals, noise reduction, identification of sound sources, directional recording functions, etc.

The earphone interface 170D is used to connect a wired earphone. The headset interface 170D may be a USB interface 130 or a 3.5mm open mobile electronic device platform (open mobile terminal platform, OMTP) standard interface, a american cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The pressure sensor is used for sensing a pressure signal and can convert the pressure signal into an electric signal. In some embodiments, the pressure sensor may be provided on the display screen 194. The electronic device 100 may also calculate the location of the touch based on the detection signal of the pressure sensor.

The gyroscopic sensor may be used to determine a motion pose of the electronic device 100. In some embodiments, the angular velocity of electronic device 100 about three axes (i.e., x, y, and z axes) may be determined by a gyroscopic sensor.

The acceleration sensor may detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). The acceleration sensor may detect the magnitude and direction of gravity when the electronic device 100 is stationary. The acceleration sensor can also be used for recognizing the gesture of the electronic equipment, and is applied to the applications such as horizontal and vertical screen switching, pedometers and the like.

Touch sensors, also known as "touch panels". The touch sensor may be disposed on the display screen 194, and the touch sensor and the display screen 194 form a touch screen, which is also referred to as a "touch screen". The touch sensor is used to detect a touch operation acting on or near it. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type.

The keys 190 include a power-on key (or power key), a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

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

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

The layered architecture of the electronic device 100 divides the software into several layers, each with a distinct role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages.

As shown in fig. 2, the application package may include applications for cameras, gallery, calendar, phone calls, maps, navigation, WLAN, bluetooth, music, video, short messages, etc.

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

As shown in fig. 2, the application framework layer may include a software package manager (Package Manager Service, PMS), a window manager, a content provider, a view system, a resource manager, a notification manager, and the like.

The PMS is mainly used for managing the processes of installation, uninstallation, updating, analysis, authority and the like of the application. In the PMS operation process, package Installer (or named as instructor) (application Installer or software package installation) is often called to execute specific operations, and the instructor calls Native layer again to execute operations such as installation analysis.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification information is used to inform that the download is complete, a message alert, etc. The notification information may also be a notification in the form of a chart or scroll bar text appearing in the system top status bar, such as a notification of a background running application, or a notification appearing on the screen in the form of a dialog window. The notification information may be, for example, text information presented in a status bar, a presentation sound emitted, vibration of an electronic device, flashing of an indicator light, or the like.

Android run time includes a core library and virtual machines. Android run is responsible for scheduling and management of the Android system.

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

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

The system library may include a plurality of functional modules. For example: an instrumentation daemon, a surface manager (surface manager), a Media library (Media Libraries), a three-dimensional graphics processing library (e.g., openGL ES), a 2D graphics engine (e.g., SGL), etc.

Wherein the Inlitddaemon is a native process whose function is to launch a socket to process commands from the Inlitler.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio video encoding formats, such as: MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The kernel layer at least comprises display drive, camera drive, storage drive, sensor drive and the like. The hardware at least comprises a processor, a display screen, a camera, a sensor and the like.

It will be appreciated that the layers and components contained in the layers in the software structure shown in fig. 2 do not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer layers than shown and may include more or fewer components per layer, as the application is not limited.

It will be appreciated that, in order to implement the compiling method according to the embodiment of the application, the electronic device includes corresponding hardware and/or software modules for performing the respective functions. The present application can be implemented in hardware or a combination of hardware and computer software, in conjunction with the example algorithm steps described in connection with the embodiments disclosed herein. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application in conjunction with the embodiments, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

For easy understanding, the following embodiments of the present application will take an electronic device having a structure shown in fig. 1 and fig. 2 as an example, and specifically describe a compiling method provided by the embodiments of the present application in conjunction with the accompanying drawings and application scenarios.

Before describing the method for installing an application according to an embodiment of the present application, a brief description will be given of terms in the embodiment of the present application.

1. Android application package (Application Package, APK): the Android operating system is an application package file format used for distributing and installing mobile applications and middleware. Code of an Android application program is expected to run on an Android device, and the code must be compiled first and then packaged into a file which can be identified by an Android system and can be run, and the file format which can be identified and run by the Android system is "APK". The APK is formed by combining xml, a resource file and a dex file.

2. dexopt thread: the method is used for executing the dexopt task, wherein the dexopt is a process of verifying and optimizing the dex file, and an executable dex file is generated. This process may improve application launch and component loading performance.

3. dex2oat thread: the method is used for executing a dex2oat work task, wherein the dex2oat is a process of compiling and optimizing an APK file to generate an oat file. The oat file is an Android proprietary (Executable and Linkable Format ) file format that contains not only the native machine instructions translated from the dex file, but also the original dex file content. For APK, the oat file is actually a wrapper for the odex file.

4. Mutual exclusion lock (lock_guard): is a type of control of the ownership of a lockable object within a scope and is a mechanism that ensures that only one thread accesses a certain method or variable at a time. In Java or other object-oriented languages, when a thread accesses synchronized code, the exclusive lock to which the code belongs must be acquired, otherwise the thread will block until the object lock is released. The exclusive lock, that is, at most one thread can acquire the lock, when the thread a tries to acquire the exclusive lock held by the thread B, the thread a must wait or block until the thread B releases the lock, and the thread a cannot acquire the exclusive lock to access the corresponding method or variable.

It should be noted that the locks named by various english strings mentioned below are all referred to as exclusive locks.

Fig. 3 is a schematic flow chart of an installation application according to an embodiment of the present application. Taking an electronic device based on an Android (Android) system as an example, the electronic device installs an application through an interface of Package Installer. As shown in fig. 3, the process of installing an application specifically includes the following steps:

s101, an application program layer creates a task of application installation.

S102, the application program layer submits the task to the PMS in the application framework layer, and the PMS installs the application.

S103, PMS installs the application.

When the PMS installs the application, the APK file of the application is copied into the system catalog from the download catalog of the application, the APK file is scanned, and the APK file is analyzed through the scanning process, so that information such as components, configuration files and the like of the application can be obtained.

S104, the PMS submits a dexopt task to the Installer.

When the PMS submits a dexopt task to the Installer, the dexopt thread needs to hold the mInstalLock lock of the java layer. An mInsalLock lock is used to protect all accesses to the Insald interface. When the current dexopt task is not complete, the mInstallLock prevents other dexopt tasks from proceeding, as well as other operations or methods that require holding the mInstallLock.

S105, the instrler requests the instrald daemon to execute the dexopt task.

Insitler provides a Java API interface to make Binder communications with the Insitald daemon (android 8.1.0 was previously through Socket communications). The instrler acts as a client and specific operations are completed by the instrld daemon at the Nativie layer.

When the instrler requests the instrld daemon to execute the dexopt task, the corresponding thread needs to hold the global lock mLock of the active layer. And the mLock lock is used for protecting all file data accessed by the Installd daemon. When the current dexopt task is not complete, the mLock lock prevents other operations or methods that need to hold the mLock lock from proceeding.

S106, the Inlitalld daemon calls a dex2oat thread to execute the dex2oat operation.

When the Instald executes the dexopt task, binary optimization is performed on the APK file through internal call of the dex2oat thread, so that the application starting speed and the component loading performance are improved.

S107, the Inlitddaemon sends a message of ending the execution of the dex2oat thread to the Inlitaler.

When the dex2oat thread finishes executing the dex2oat operation, the instraler releases the mLock lock.

S108, the instrler sends a message of completion of execution of the dexopt task to the PMS.

When the execution of the dexopt task is completed, the dexopt thread releases the mInstallLock lock.

And S109, the PMS sends a message of finishing the application installation to the application program layer.

The present process is not explained in detail with reference to the prior art, and is not described in detail herein.

The above procedure illustrates the scenario involved in the dex2oat operation, taking the installation of a new application as an example. Besides, the scenario involved in the dex2oat operation also includes application first start-up, application upgrade update, etc. The dex2oat operation may be triggered by a user operation (such as an operation of installing an application), or may be triggered by a system automation (such as an application automatic update).

As can be seen from the above flow, in order to implement the dex2oat operation, as shown in fig. 4, the dexopt task needs to hold the mlollock of the java layer in the PMS, and the dex2oat thread needs to hold the mLock lock of the active layer in the instron daemon. Because the dex2oat operation is an operation with a relatively large calculation amount and input/output (IO) amount, the execution time of the dex2oat thread is longer, and further the time that the mInsalLock of the java layer and the mLock of the active layer are held is longer. Furthermore, at this time, if other threads need to use the mInstallLock lock of the java layer or the mLock lock of the native layer, the threads need to be blocked for waiting, but the problems that the system is blocked due to the fact that the lock cannot be acquired for a long time, the system response is slow, ANR and the like may occur, so that the use experience of a user is affected.

As shown in fig. 5, many threads corresponding to an API implementation and an Internal Method function (Internal Method) in the PMS need to hold an mcinnallock of the java layer to continue execution. Therefore, if the dexopt task holds the mInstallLock too long, the lock time of other threads in the PMS will be too long, which affects the user experience. For example, the API implementation that needs to be locked may be an API implementation that uninstalls an application, an API implementation that clears application data, and the like, and the internal method function may be a method function that prepares data when switching privacy spaces or when creating an application split, and the like.

In one possible application scenario, if the a application is executing the dex2oat operation, then the mlnsallock of the java layer and the mLock of the active layer are held at this time. Only after the dex2oat operation of the a application is completed will the mlassock lock of the java layer and the mLock lock of the native layer be released. If the user performs an operation of clearing the B application user data in the setup page while the a application is performing the dex2oat operation, the system will respond to the data clearing operation only after the dex2oat operation of the a application is completed. Assuming that the time taken by the application a is 20 seconds, the system will respond to the data clear operation of the application B after 20 seconds, and the time taken by the user to see that the data clear of the application B was successful is long, for example, 21 seconds.

In one possible application scenario, if the user performs an operation to uninstall the C application while the a application is performing the dex2oat operation, the system will respond to the operation to uninstall the C application only after the dex2oat operation of the a application is completed.

In one possible application scenario, if the user performs an operation of switching the privacy space while the a application is performing the dex2oat operation, the system will respond to the operation of switching the privacy space only after the dex2oat operation of the a application is completed.

In one possible application scenario, if the user performs an operation of creating a split application corresponding to the D application while the a application is performing the dex2oat operation, the system responds to the operation of creating the split application only after the dex2oat operation of the a application is completed.

In one possible application scenario, if a user performs an operation of installing an E application while the a application is performing a dex2oat operation, the system will respond to the operation of installing the E application only after the dex2oat operation of the a application is completed.

It should be noted that the above application scenario is only an exemplary illustration. When any application executes the dex2oat operation, as long as other threads need to hold the mInsalLock of the java layer to continue execution, the thread needs to be responded after the dex2oat operation of the application A is completed.

Thus, the mInstallLock of the java layer can certainly become a bottleneck in the PMS, and a lock contention problem for the mInstallLock occurs in the java layer.

Similarly, when any application performs a dex2oat operation, as long as other threads need to hold the active layer mLock lock to continue execution, the thread needs to be responded to after the dex2oat operation of the application a is completed. Thus, the mLock lock of the native layer can also become a bottleneck in the Installd, where lock contention issues for the mLock lock occur.

In order to reduce the lock competition problem during application optimization, the locks for compiling optimization are split in global locks at a java layer and a native layer respectively, and a newJava Lock lock is predefined in the java layer and used for locking and protecting an Installld daemon to execute dex2oat, and an mdexOptLock lock is predefined in the native layer and used for locking and protecting a file involved in the execution of the dex2oat by the Installld daemon.

Thus, the dex2oat operation is executed, and only the newly added NewjavaLock lock and the newly added mdaxoptlock are required to be applied to the java layer and the native layer. Therefore, the dex2oat operation does not occupy the original java layer global lock and the native layer global lock for a long time, and the lock competition problem in application optimization is reduced.

It should be noted that the names of the newly added NewjavaLock lock and mdaxoptlock are merely exemplary names, and the embodiments of the present application are not limited thereto.

As shown in FIG. 6, at least the mInstallLock and the NewJava Lock are included in the PMS at the java layer. The mInsalLock lock and the NewJava Lock lock are independent of each other.

The mInstallLock lock is used for locking and protecting access to the Installld daemon, the lock protection is not performed on the dex2oat service executed by the Installld daemon any more, and the newJava Lock is only used for locking and protecting the dex2oat service executed by the Installld daemon.

It should be noted that in order to minimize modifications to existing designs of android systems, "mInstallLock" is still used herein to identify locks for protecting access to the Installd daemon. Unlike the prior art mInstallLock, the mInstallLock shown in FIG. 6 is no longer used to lock protection for the execution of dex2oat traffic by the Installd daemon.

The defining manner of the NewjavaLock lock and the msitallock may refer to the defining manner of the mutual exclusion lock in the prior art, and will not be described herein.

When PMS submits a dexopt task to an Installer, the dexopt thread only needs to apply for holding a NewJava Lock lock; while other API imagents and international methods only need to apply for holding an mcinnallock when executing. Thus, the dexopt thread holds the NewjavaLock lock for a long time, and does not affect the execution of other API executions and Internal methods.

As shown in FIG. 7, at least the mLock lock and the mDexOptLock lock are included in the native daemon at the native layer. The mLock lock and the mDexOptLock lock are independent of each other.

The mLock lock is used for locking and protecting files accessed by the Installd daemon, and the files do not comprise files involved in the execution of dex2oat service by the Installd daemon; while the mDexOptLock lock is only used to lock and protect files involved in the execution of the dex2oat service by the instrald daemon.

It should be noted that in order to minimize modifications to existing designs of android systems, "mLock" is still used herein to identify locks for protecting access to files by the Installd daemon. Unlike the prior art mLock, the mLock lock shown in FIG. 7 is no longer used to lock and protect files involved in performing the dex2oat service on the Installd daemon.

The defining manner of the mLock lock and the mDexOptLock lock can refer to the defining manner of the mutual exclusion lock in the prior art, and will not be described herein.

When the operation requested by the thread to the instrald daemon is not a dex2oat operation and the file related to the dex2oat is not operated, the thread only needs to apply for holding the mLock lock. In this case, there is no conflict between the thread operation and the file of the dex2oat thread operation.

For example, thread 1 requests the instrunt daemon to perform the dex2oat operation on the tremble application, the file directory of the operation being a/data/apk/tremble directory; thread 2 requests the instrald daemon to perform a cache data flush operation to the panning application, the file of the operation targeting data/user_de/0/panning directory. At this time, the operation requested by the thread 2 is not a dex2oat operation, and the file of the operation does not conflict with the file of the dex2oat thread operation, and the thread 2 only needs to apply for holding the mLock lock.

When the operation requested by a thread to the instrald daemon is a dex2oat operation, the thread only needs to apply to hold the mdaxoptlock.

For example, thread 3 requests the instrald daemon to perform the dex2oat operation on the tremble application, and thread 3 only needs to apply for holding the mdaxoptlock.

For another example, thread 3 requests the Installd daemon to perform an operation on dex2oat of the tremble application, thread 3 holding the mdexOptLock. When thread 4 also requests the instrald daemon to perform an operation on dex2oat of the panning application, thread 4 also applies to hold the mdaxoptlock. At this point, thread 4 cannot apply to the mdaxoptlock lock because the mdaxoptlock is held by thread 3. After the dex2oat operation for the tremble application is completed, thread 3 releases the mdaxoptlock and thread 4 can apply for the mdaxoptlock.

When a thread requests an operation from the instrald daemon that is not a dex2oat operation, but that requires an operation on a file involved in the dex2oat operation, the thread first applies to hold the mLock lock and then applies to hold the mdaxoptlock lock.

For example, thread 1 requests the instrunt daemon to perform the dex2oat operation on the tremble application, the file directory of the operation being a/data/apk/tremble directory; thread 2 requests the instrald daemon to perform other operations, the file directory of the operation is also the/data/apk/tremble directory. At this time, the operation requested by the thread 2 is not a dex2oat operation, but the file of the operation conflicts with the file of the dex2oat thread operation, so that the thread 2 applies to hold the mLock lock in addition to the mLock lock.

Here, the thread requesting the Installd daemon to perform other operations, still maintaining the AOSP's original logic, needs to hold the global lock of mLock. The embodiment of the application aims to reduce lock contention during application optimization, and the lock is held for a long time by the dex2oat operation. Thus, when the files operated by other threads are the same set of files as the files operated by dex2oat, the threads additionally apply for holding mdaxoptlock in addition to holding mLock lock.

The lock-holding scenario involved in performing the dex2oat operation of the electronic device is explained below in connection with fig. 8. As shown in FIG. 8, the PMS submits a dexopt task to the Installer, and the dexopt thread only needs to hold the NewJava Lock of the Java layer to lock and protect the dex2oat service executed by the Installd daemon. The instraler requests the instrunt daemon to execute the dexopt task, and the corresponding thread only needs to hold the mdaxoptlock in the native layer to lock and protect the files involved in the instrunt daemon executing the dex2 oat. Furthermore, the Inlitddaemon can call the dex2oat thread to complete compiling optimization operation. When the dex2oat thread finishes the dex2oat operation, the Installer releases the mDexOptLock, and when the dexopt task finishes the execution, the dexopt thread releases the NewJava Lock lock.

The lock contention among multiple parallel threads at application compilation optimization is explained below in connection with several possible usage scenarios.

Scene one

In the present scenario, an explanation is made for a lock contention problem in a java layer PMS when compiling optimization is applied.

In one possible scenario, as shown in FIG. 9, at the java layer, thread 1 in the PMS performs dexopt task 1, only needs to hold the NewJava Lock lock. While thread 1 holds the NewjavaLock lock to execute the dexopt task 1, thread 2 starts. For example, thread 2 is used to perform dexopt task 2. In the process that the NewjavaLock is held by the thread 1, the thread 2 is in a state of waiting for the NewjavaLock, and after the thread 1 releases the NewjavaLock, the thread 2 applies to hold the NewjavaLock and executes the dexopt task 2 after holding the NewjavaLock.

In one possible scenario, as shown in FIG. 10, at the java layer, thread 1 in the PMS performs dexopt task 1, only needs to hold the NewJava Lock lock. While thread 1 holds the NewjavaLock lock to execute the dexopt task 1, thread 3 starts. The thread 3 is used for executing other method tasks of non-dexopt tasks, such as a task of unloading an application, a task of clearing data, and the like. After thread 3 starts, a global mInsalLock lock is applied for and corresponding method tasks are executed after the mInsalLock is held.

Therefore, in the java layer, as the NewjavaLock lock and the mInstallLock are mutually independent, the threads for executing the dexopt task cannot be influenced by other threads for executing the non-dexopt task even if the threads for executing the dexopt task are held for a long time, and the problem of thread blocking caused by long-time waiting of the threads for executing the non-dexopt task is avoided.

It should be noted that whether a thread is used to execute a dexopt task is known to a programmer, so that it is predefined whether the thread only needs to apply for holding the mInstallLock lock in the java layer or only needs to apply for holding the newJava Lock lock at runtime. After the thread is started, the corresponding lock is only required to be applied according to the predefined information.

Scene two

In this scenario, the lock contention problem in the native layer Instrument at the time of application compilation optimization is explained.

In one possible scenario, as shown in FIG. 11, at the native layer, thread 4 requests that the InliteDex 2oat be performed, only the mDexOptLock needs to be held. Thread 5 starts while thread 4 holds the mdaxoptlock execution dex2 oat. The thread 5 is used for executing other operations other than dex2oat, such as an operation file. Assuming that the file operated by the thread 5 and the file operated by the thread 4 do not have conflict, after the thread 5 is started, only the global mLock is applied for and the corresponding operation is executed after the mLock is held.

Regarding whether the file involved in the thread performing the non-dex 2oat operation conflicts with the file involved in the thread performing the dex2oat operation, reference may be made to the foregoing examples, and no further description is given here.

Thus, at the native layer, because the mdaxoplock lock and the mLock lock are mutually independent, the thread performing the dex2oat operation can not influence other threads performing the non-dex 2oat operation (the file operated by the lock is irrelevant to the dex2oat file) even if the lock is held for a long time, and the problem of thread blocking caused by the long time waiting of other threads performing the non-dex 2oat operation is avoided.

In one possible scenario, as shown in FIG. 12, at the native layer, thread 4 requests that the InliteDex 2oat1 operation be performed by the InliteInd, only the mdexOptLock needs to be held. Thread 6 starts while thread 4 holds the mdaxoptlock execution dex2 oat. Wherein thread 6 is used to request the instrald to execute dex2oat2. In the process that the mDexOptLock is held by the thread 4, the thread 6 is in a state of waiting for the mDexOptLock, after the mDexOptLock is released by the thread 4, the thread 6 applies to hold the mDexOptLock, and requests the instrumentation to execute the dex2oat2 operation after holding the mDexOptLock.

It should be noted that if the mdaxoptlock lock is in an idle state, the thread for requesting the instrald to perform the dex2oat operation may directly apply to the mdaxoptlock, where there is no lock contention.

Thread 6 requests that the instrument perform a dex2oat2 operation, although its operating dexoat file does not conflict with the dexoat file operated by thread 4, there is only one process that needs to be controlled to perform dex2oat, so thread 6 needs to apply for holding the mdexophtlock. After the execution of the dex2oat operation requested by the waiting thread 4 is completed, the mDexOptLock is released, and the thread 6 can request the instrald to continue to execute the dex2oat2 operation after holding the mDexOptLock.

In one possible scenario, as shown in FIG. 13, at the native layer, thread 4 requests that the InliteDex 2oat1 operation be performed by the InliteInd, only the mDexOptLock needs to be held. Thread 7 starts while thread 4 holds the mdaxoptlock execution dex2 oat. The thread 7 is used for executing other operations than dex2oat, such as an operation file. Assuming that the file operated by the thread 7 conflicts with the file operated by the thread 4, after the thread 7 is started, not only the global mLock lock needs to be applied for holding, but also the mDexOptLock lock needs to be continuously applied for holding after the mLock is held, and corresponding operation is executed after the mDexOptLock lock is held.

Illustratively, thread 7 is used to manipulate files. Thread 7 here still maintains the original logic of the AOSP, first requiring a global lock holding mLock. Therefore, damage to the original design of the android system can be avoided as much as possible. However, when the file to be operated by the thread 7 and the file to be operated by the thread 4 are the same group of files, that is, when the file involved in the execution of the non-dex 2oat operation by the thread 7 conflicts with the file involved in the execution of the dex2oat operation by the thread 4, the thread 7 also additionally requests the mDexOptLock lock, and the operation of the operation file can be continued after waiting for the thread 4 to finish releasing the mDexOptLock.

Thus, at the native layer, since the mdaxoptlock lock and the mLock lock are independent of each other, if a file involved in a thread executing a non-dex 2oat operation conflicts with a file involved in a thread executing a dex2oat operation, the thread executing the non-dex 2oat operation needs to hold the mLock lock as well as the mlexophtlock, so that the synchronicity of the file involved in the dex2oat operation can be ensured. Moreover, as the thread requesting dex2oat operation does not need to hold the global mLock lock, the phenomenon of occupying the mLock global lock for a long time does not occur.

In addition to the above scenario, there is also a case: the thread requesting the non-dex 2oat operation starts earlier than the thread requesting the dex2oat operation, and when the dex2oat operation is to be controlled as well, there is no conflict with the file being operated.

At the active layer, as shown in FIG. 14, thread 8 executes first, but is not used to request that Inliteld execute dex2oat, but rather a related function of the operational file. At this point, thread 8 first requests and holds the mLock lock according to the logic of AOSP. Assuming that the file involved in the operation requested by thread 8 is related to the file involved in the dex2oat operation, thread 8 also needs to simultaneously apply for holding the mDexOptLock. When the mdexOptLock lock is not held by other threads in the current system, the thread 8 can directly apply for the mdexOptLock lock, and further can execute corresponding file operation.

While thread 8 holds the mdaxoptlock, it is assumed that thread 9 is started. Wherein thread 9 is used to request the instrald to perform dex2oat operations. In the process that the mDexOptLock is held by the thread 8, the thread 9 is in a state of waiting for the mDexOptLock, after the mDexOptLock is released by the thread 8, the thread 9 applies to hold the mDexOptLock, and requests the instrumentation to execute the dex2oat operation after holding the mDexOptLock.

Assuming that the file involved in the operation requested by thread 8 is not related to the file involved in the dex2oat operation, thread 8 may continue to perform the related operation after holding the mLock lock.

It should be noted that whether a thread is used to request that the instruction perform the dex2oat, whether the operations related to the thread are known to the programmer about the files related to the dex2oat operations, so that the thread needs to be applied to only hold the mdexoplack lock in the active layer, only to hold the mLock global lock in the active layer, or both the mLock global lock and the mdexoplack lock in the active layer at runtime is predefined. After the thread is started, the corresponding lock is only required to be applied according to the predefined information.

The present embodiment also provides a computer storage medium having stored therein computer instructions which, when executed on an electronic device, cause the electronic device to execute the above-described related method steps to implement the compilation optimization method in the above-described embodiments.

The present embodiment also provides a computer program product which, when run on a computer, causes the computer to perform the above-described related steps to implement the compilation optimization method in the above-described embodiments.

In addition, embodiments of the present application also provide an apparatus, which may be embodied as a chip, component or module, which may include a processor and a memory coupled to each other; the memory is used for storing computer-executable instructions, and when the device runs, the processor can execute the computer-executable instructions stored in the memory, so that the chip executes the compiling optimization method in each method embodiment.

The electronic device (such as a mobile phone) provided in this embodiment, the computer storage medium, the computer program product or the chip are used to execute the corresponding method provided above, so that the beneficial effects thereof can be referred to the beneficial effects in the corresponding method provided above, and will not be described herein.

It will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims

1. The compiling optimization method is characterized by being applied to electronic equipment, wherein a system of the electronic equipment is an android system and comprises the following steps:

a first thread in a software Package Management Service (PMS) applies for holding a first mutual exclusion lock in the PMS, and submits a compiling optimization task to a software package Installer Installer after holding the first mutual exclusion lock; the first mutual exclusion lock is only used for locking and protecting the Inliteld daemon to execute compiling optimization operation;

a second thread in an instrler applies for a second exclusive lock in an instred daemon, and requests the instred daemon to execute compiling optimization operation after holding the second exclusive lock; the second mutual exclusion lock is only used for locking and protecting files involved in the execution of compiling optimization operation by the Inliteld daemon;

the PMS further comprises a third mutual exclusion lock, wherein the third mutual exclusion lock is used for locking and protecting access to the Installd daemon, and the access to the Installd daemon does not comprise a request of the Installd daemon to execute compiling optimization operation;

the method comprises the steps that a first mutual exclusion lock is used for locking and protecting files accessed by the Intalld daemon, and the files accessed by the Intalld daemon do not comprise files involved in compiling and optimizing operations executed by the Intalld daemon.

2. The method of claim 1, further comprising, after the first thread holds the first exclusive lock:

a third thread in the PMS applies for holding the third mutual exclusion lock, and after holding the third mutual exclusion lock, corresponding operation is executed; wherein the third thread is used to perform a non-compiled optimization operation.

3. The method of claim 1, further comprising, after the first thread holds the first exclusive lock:

a fourth thread in the PMS applies for holding the first mutual exclusion lock and waits for the first mutual exclusion lock;

after the first exclusive lock of the fourth line Cheng Chiyou, submitting a compilation optimization task to the instrler; the fourth thread is used for executing compiling optimization tasks.

4. The method of claim 1, further comprising, after the second thread holds the second exclusive lock:

a fifth thread in the instrler applies for holding the fourth exclusive lock, and requests the instred daemon to execute corresponding operation after holding the fourth exclusive lock; the fifth thread is used for requesting the executed daemon to execute the non-compiling optimization operation, and the file related to the non-compiling optimization operation does not conflict with the file related to the compiling optimization operation.

5. The method of claim 1, further comprising, after the second thread holds the second exclusive lock:

a sixth thread in the instrler applies for holding the fourth mutual exclusion lock, applies for holding the second mutual exclusion lock after holding the fourth mutual exclusion lock, and waits for the second mutual exclusion lock;

after the sixth thread holds the second exclusive lock, requesting the executed daemon to execute a corresponding operation; the sixth thread is used for requesting the executed daemon to execute a non-compiling optimization operation, and the file related to the non-compiling optimization operation conflicts with the file related to the compiling optimization operation.

6. The method of claim 1, further comprising, after the second thread holds the second exclusive lock:

a seventh thread in the instrler applies for holding the second mutual exclusion lock and waits for the second mutual exclusion lock;

and after the seventh thread holds the second exclusive lock, requesting the executed daemon to execute compiling optimization operation.

7. The method of claim 1, wherein when the second exclusive lock is idle, further comprising:

The eighth thread in the instrler applies for holding the fourth mutual exclusion lock, and applies for holding the second mutual exclusion lock after holding the fourth mutual exclusion lock;

after the eighth thread holds the second exclusive lock, requesting the executed daemon to execute corresponding operation; the eighth thread is used for requesting the executed daemon to execute a non-compiling optimization operation, and the file related to the non-compiling optimization operation conflicts with the file related to the compiling optimization operation.

8. An electronic device, comprising:

one or more processors;

a memory;

and one or more computer programs, wherein the one or more computer programs are stored on the memory, which when executed by the one or more processors, cause the electronic device to perform the compilation optimization method of any of claims 1-7.

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