CN116700817B - Application program running method and electronic equipment - Google Patents

Abstract

The application provides an application program running method and electronic equipment, and relates to the field of terminals. The method for running the application program in the application comprises the following steps: responding to the operation of a user on the application program, and running a first thread in the application program; if the first thread fails to lock the target resource and the first thread is detected to belong to the target thread, the target thread updates the first priority of the second thread to the second priority, and the second thread is the thread with the lock of the target resource; before the target thread enters a blocking state, transmitting first identification information of a second thread to the kernel; the kernel schedules resources for the second thread preferentially in a preset duration according to the first identification information; and if the second thread does not release the lock within the preset time, the second thread operates according to the second priority. By adopting the method of the application, the starting speed of the electronic equipment or the data loading speed can be improved, and the problems of blocking and frame loss of the display page of the application program can be avoided.

Description

Application program running method and electronic device

Technical Field

The present application relates to the field of terminals, and in particular to a method for running an application and an electronic device.

Background technique

With the continuous development of smart phones, more and more applications are running on smart phones, such as video applications, social applications, etc. In order to reduce the cost of using applications for users, some applications also allow other small programs to run in the application.

However, when the application is started, there will be problems with slow startup and startup page jamming; the mini-programs in the application will also have problems with slow startup or slow loading when starting or loading scan results (such as the results of scanning a QR code).

Summary of the invention

In order to solve the above technical problems, the present application provides a method for running an application and an electronic device, which can improve the speed of starting up the electronic device or loading data, and avoid freezes and frame drops in the display page of the application.

In a first aspect, the present application provides a method for running an application, comprising: in response to a user's operation on the application, a first thread in the application runs; if the first thread fails to lock a target resource and it is detected that the first thread belongs to the target thread, the target thread updates the first priority of the second thread to a second priority, the second priority is higher than the first priority, and the second thread is the thread holding the lock of the target resource; the priority of the target thread is higher than the first priority, and the first identification information of the second thread is transmitted to the kernel; the kernel schedules resources for the second thread preferentially within a preset time length based on the first identification information; if the second thread does not release the lock within the preset time length, it runs according to the second priority.

In this way, the electronic device can be a mobile phone, a bracelet, a tablet computer, a computer and other devices. When the user operates the application, the first thread in the application runs. The user's operation on the application can be an operation to start the application, an operation to start the applet in the application, an operation to scan a QR code, etc. After the first thread is started, when the first thread fails to lock the target resource and detects that the first thread is the target thread, the priority of the locking thread (i.e., the second thread) is increased; and the first identification information of the locking thread is transmitted to the kernel, and the kernel prioritizes the scheduling of resources for the locking thread within a preset duration. Since the kernel prioritizes scheduling resources for the second thread, the second thread can preferentially obtain the CPU time slice, that is, the second thread can frequently obtain the CPU time slice within the preset duration, thereby improving the running speed of the second thread and shortening the running time of the second thread. At the same time, the kernel only allocates resources to the second thread preferentially within the preset time. When the second thread does not release the lock within the preset time, the second thread runs according to the second priority. Since the second priority of the second thread is higher than the first priority, the processor can allocate resources to the second thread according to the second priority, avoiding the problem that the second thread is preempted by other threads with higher priority than the first priority after exceeding the preset time, causing the second thread to be in a ready state and unable to release the lock in time. In this example, the method of modifying the priority of the second thread and the method of allocating resources to the second thread by the kernel within the preset time are combined. The two methods complement each other, which can further speed up the running speed of the second thread and reduce the length of time the first thread is blocked, thereby solving the problems of slow data loading, frame loss and freeze on the startup page caused by the blocking of the first thread.

According to the first aspect, the method further includes: the first thread performs a locking operation on the target resource, and if it is detected that the lock of the target resource is heavily locked and the lock has not been released by the second thread, the first thread determines that the locking of the target resource has failed. In this way, if the lock of the target resource is in a lightly locked state, the first thread can try to lock it multiple times, and the first thread will not enter a blocked state; and if the lock is heavily locked and has not been released by the second thread, the first thread will enter a blocked state after the locking fails. In this case, detecting whether the first thread belongs to the target thread can avoid the situation where the priority of the second thread is changed incorrectly.

According to the first aspect, detecting whether the first thread belongs to the target thread includes: the first thread detecting whether the process to which the first thread belongs is in the foreground running state; if the first thread determines that the process to which the first thread belongs is in the foreground running state, then detecting whether the first thread is a key thread; if the first thread detects that the first thread is a key thread, then determining that the first thread belongs to the target thread. In this way, the blocking of the key thread of the process in the application usually causes page freezes and frame drops. For the blocking of the key thread in the application running in the background, it is not easy to cause abnormalities in the display screen of the application. Therefore, only the process in the foreground running state is detected, and the scenario where the priority of the second thread needs to be increased and the kernel prioritizes the scheduling of resources for the second thread can be quickly located.

According to the first aspect, detecting whether the first thread is a key thread includes: the first thread obtains the second identification information of the process to which the first thread belongs; judging whether the second identification information is the same as the third identification information of the first thread; if the second identification information is detected to be the same as the third identification information, then determining that the first thread is a key thread; if the second identification information is detected to be different from the third identification information, then determining that the first thread is not a key thread. In this way, through the identification information of the first thread and the identification information of the process to which the first thread belongs, it is possible to quickly judge whether the first thread is a key thread in the process to which it belongs.

According to the first aspect, the kernel preferentially schedules resources for the second thread within a preset duration according to the first identification information, including: if the kernel obtains the first identification information, the timer is started; when the kernel detects that the duration recorded by the timer reaches the preset duration, the operation of preferentially scheduling resources for the second thread is terminated. In this way, the duration for which the kernel preferentially schedules resources for the second thread can be detected in time through the timer, and after reaching the preset duration, the operation of preferentially scheduling resources for the second thread is terminated, which can avoid the impact of the operation of preferentially scheduling resources for the second thread for a long time on other threads.

According to the first aspect, the first identification information includes: the identity identification number of the second thread and the first attribute information, and the first attribute information is used to indicate whether the kernel prioritizes the scheduling of resources for the second thread. In this way, the kernel can quickly determine whether to prioritize the scheduling of resources for the second thread according to the first attribute information.

According to the first aspect, the method further includes: when the target thread successfully locks the target resource, the second priority of the second thread is updated to the first priority. In this way, when the second thread has released the lock, the target thread attempts to lock the target resource, and after the lock is successful, the target thread will end the blocking state and resume operation. At this time, the target thread changes the second priority of the second thread to the first priority, so that the priority of the second thread can be restored to the original first priority in time to avoid affecting the operation of other threads.

According to the first aspect, the target thread updates the first priority of the second thread to the second priority, including: the target thread detects that the lock is re-locked, then obtains the first identification information of the second thread; the target thread updates the first priority to the second priority through the interface according to the first identification information. In this way, the first thread can pass the first identification information of the second thread to the kernel by calling the interface.

According to the first aspect, the preset duration is less than or equal to 20 milliseconds. In this way, the kernel can avoid the problem of preferentially scheduling resources for the second thread for a long time and affecting the operation of other threads.

According to the first aspect, the first thread belongs to the application or to a small program in the application. In this way, the first thread can belong to the application or to a small program in the application, which increases the applicable scenarios of the method for running the application.

In a second aspect, the present application provides a method for running an application, comprising: in response to a user operation on the application, a first thread in the application runs; if the first thread in the application fails to lock a target resource and it is detected that the first thread belongs to the target thread, the target thread updates the first priority of the second thread to a second priority, the second priority is higher than the first priority, and the second thread is the thread holding the lock of the target resource; the priority of the target thread is higher than the first priority, and the second thread runs according to the second priority.

In this way, the electronic device can be a mobile phone, a bracelet, a tablet computer, a computer and other devices. When the first thread of the application fails to lock the target resource and detects that the first thread is the target thread, the priority of the lock-holding thread (i.e., the second thread) is increased; the second thread runs at the second priority, and since the second priority of the second thread is higher than the first priority, the processor can allocate resources to the second thread according to the second priority, which can reduce the probability of threads higher than the first priority seizing the CPU, thereby reducing the probability of the first thread being blocked for a long time, thereby reducing the problems of slow data loading, frame loss, and freezes on the startup page caused by the first thread being blocked for a long time.

According to the second aspect, detecting whether the first thread belongs to the target thread includes: the first thread detecting whether the process to which the first thread belongs is in the foreground running state; if the first thread determines that the process to which the first thread belongs is in the foreground running state, detecting whether the first thread is a key thread; if the first thread detects that the first thread is a key thread, determining that the first thread belongs to the target thread.

According to the second aspect, detecting whether the first thread is a critical thread includes: the first thread obtains second identification information of the process to which the first thread belongs; determining whether the second identification information is the same as the third identification information of the first thread; if it is detected that the second identification information is the same as the third identification information, determining that the first thread is the critical thread; if it is detected that the second identification information is not the same as the third identification information, determining that the first thread is not the critical thread.

According to the second aspect, the method further includes: when the target thread successfully locks the target resource, updating the second priority of the second thread to the first priority.

Any implementation of the second aspect corresponds to any implementation of the first aspect. The technical effect corresponding to any implementation of the second aspect can refer to the technical effect corresponding to any implementation of the first aspect, which will not be repeated here.

In a third aspect, the present application provides an electronic device comprising: a memory and a processor, the memory being coupled to the processor; the memory storing program instructions, which, when executed by the processor, enables the electronic device to execute a method for running an application corresponding to any one of the implementations of the first aspect, or to execute a method for running an application corresponding to any one of the implementations of the second aspect.

The third aspect and any implementation method of the third aspect respectively correspond to the first aspect and any implementation method of the first aspect, or correspond to the second aspect and any implementation method of the second aspect, and will not be repeated here.

In a fourth aspect, the present application provides a computer-readable medium for storing a computer program. When the computer program is run on an electronic device, the electronic device executes a method for running an application corresponding to any one of the implementations of the first aspect, or executes a method for running an application corresponding to any one of the implementations of the second aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

FIG1 is a schematic diagram showing an exemplary electronic device starting a video application;

FIG2 is an exemplary diagram showing the duration corresponding to each running state of a key thread;

FIG3 is an exemplary diagram of a Java object header structure;

FIG4a is a schematic diagram showing an exemplary embodiment of thread A competing for a lock of a shared resource;

FIG4b is a schematic diagram showing an example of a thread calling a CPU when a startup page of an application program freezes;

FIG5 is a schematic diagram showing the structure of an electronic device;

FIG6 is a block diagram showing an exemplary software structure of an electronic device;

FIG7 is a flowchart showing an exemplary operation of an application program;

FIG8 is a schematic diagram exemplarily showing the interaction between the first thread, the second thread and the kernel;

FIG9 is a schematic diagram exemplarily showing a thread calling a CPU using the method for running an application program in the present application;

FIG10 is a flowchart showing an exemplary operation of an application program;

FIG. 11 is a schematic diagram exemplarily showing the interaction between a first thread and a second thread.

Detailed ways

The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

Before describing the technical solution of the embodiment of the present application, the application scenario of the embodiment of the present application is first described in conjunction with the accompanying drawings. Figure 1 is a schematic diagram of an electronic device starting a video application (such as application A) as shown in an exemplary manner. As shown in Figure 1, the mobile phone responds to the user's startup operation, and the display interface 101 of the mobile phone displays the startup animation of application A. The normal screen of the startup animation is shown in 1a of Figure 1. When the startup animation is stuck or frame-dropped, the display effect in the display interface 102 is shown in 1b of Figure 1. When the user finds that the mobile phone has a stuck problem as shown in 1b of Figure 1, the user mistakenly believes that the electronic device has a stuck problem, which reduces the user experience of using the electronic device.

In another example, when a small program in a chat application is started, there is also a problem of long startup time. For applications or small programs with scanning functions, the time from the end of scanning the QR code to the display of the scan results is long, and users are easily mistaken for the problem that the application is stuck. Usually, when the user encounters an application stuck, they will manually kill the application (that is, end the entire application), but even if the application or small program is restarted, the above problems may still exist (such as the long time to display the results of the QR code), which reduces the user's experience of using the electronic device.

During the running of the application, multiple processes will be generated, and each process includes multiple (such as 2 or more) threads. Multiple threads can run synchronously. In this application, the performance analysis of the application A in Figure 1 is performed. For example, the running state of the thread in the stuck page can be analyzed by a performance analysis tool. Figure 2 is an exemplary illustration of the duration corresponding to each running state of a certain key thread. The key thread can be the UI (User Interface, human-computer interaction interface) thread of the startup page of the application A. As shown in Figure 2, the total time (wall Duration) consumed by the thread during the startup process is 234.58ms. The duration of the thread in the ready state is 195.764151ms, the duration of the thread in the running state is 22.721464ms, the duration of the thread in the sleep state is 8.95877ms, and the duration of the thread in the uninterruptible sleep state is 7.135615ms. The time that the thread is in the ready state accounts for 83% of the total time, while the running time accounts for 9.6% of the total time. It can be seen that the UI thread spends a lot of time in the ready state, resulting in the problem of the total running time of the UI thread being long, which makes the page display time longer, or causes freezes and frame drops.

Specifically, when an application is running, the operating system of the mobile phone creates a process for the application, which may include one or more threads. When multiple applications are running simultaneously in a mobile phone, the CPU allows the instructions and data of each program to run on the CPU for a very short period of time (time slice). When the program time slice ends, it switches to the next program. Due to the time-sharing mechanism of the CPU, when multiple threads concurrently access shared data, in order to ensure that the shared data is only used by one or some threads at the same time, it is usually implemented in a mutually exclusive synchronization manner, such as pessimistic locking (Synchronized), which is implemented through the Monitor synchronization mechanism.

FIG3 is an exemplary diagram showing the structure of the Java object header. The relevant information of the lock state of the target resource can be identified from the object header. As shown in FIG3, the lock state includes an unlocked state (Unlock State), a light lock (Thin State, also known as "thin lock") state and a heavy lock (Fat State, also known as "fat lock"). In actual applications, the lock also includes other states, which are not listed one by one in this example.

When the lock in a shared resource is in an unlocked state, the shared resource can be locked by any thread and the lock of the shared resource can be acquired. The structure of the object header is shown in Figure 3. The object header includes 32 bits, and bits 30 to 31 are used to indicate the lock type, where "00" is used to indicate that the lock is in an unlocked state or a lightly locked state. Bits 29 and 28 are the mark bit and the read barrier bit, respectively. These two bits are used to cooperate with the GC (Garbage Collection) mechanism and will not be described in detail here. When the lock is in an unlocked state, bits 0 to 27 are all 0.

Light lock state: refers to the situation that fewer threads request the lock within a period of time, and the execution time of the thread holding the lock is short, and other waiting threads can obtain the lock in a limited spin waiting period. Bits 30 to 31 of the object header structure are also used to indicate the lock type, and bits 29 and 28 are mark bit and Read Barrier bit respectively. Bits 0 to 27 include the lock count and the identity number of the thread holding the lock.

Re-locked state: When the lock in a shared resource is in a re-locked state, only one thread can hold the lock. When multiple threads access the shared resource at the same time, the non-lock holder thread will first try to obtain the ownership of the monitor in the lock object of the shared resource; if the non-lock holder thread fails to obtain the ownership of the monitor, the current non-lock holder thread will be blocked, waiting for the lock holder thread to unlock and then wake up, and compete for the lock of the shared resource again. Bits 30 to 31 of the object header structure are also used to indicate the lock type, where "01" is used to indicate that the current state is re-locked. Bits 29 and 28 are the mark bit and the read barrier bit, respectively. These two bits are used to cooperate with the GC (Garbage Collection) mechanism and will not be described in detail here. Bits 0 to 27 include the monitor object's identity number (Monitor Id).

FIG4a is a schematic diagram showing an example of CPU being occupied when thread A competes for the lock of a shared resource. As shown in FIG4a , thread C accesses the shared resource at time T0 and successfully locks the shared resource, that is, thread C obtains the lock of the shared resource at time T0. If the state of the lock is a relocked state, when thread A competes to lock the shared resource at time T1, since the lock of the shared resource is already held by thread C and the state of the lock is a relocked state, thread A will be blocked and wait for thread C to release the lock of the shared resource. When thread C releases the lock of the shared resource at time T2, thread A is awakened by thread C and competes for the lock of the shared resource again. At this time, since thread C has released the lock of the shared resource, thread A successfully holds the lock. As shown in FIG4a , time T1 to T3 is the duration of the time when thread A is in a blocked state.

In some scenarios, as shown in 1b of FIG1 , in a scenario where the startup page of an application is stuck, it is assumed that the UI thread is thread A. The priority of thread A is higher than the priority of thread B, and the priority of thread B is higher than the priority of thread C. The thread with a higher priority calls computing resources first.

As shown in Figure 4b, thread C locks the shared resource at time T0, and the lock is in the relocked state. Thread A locks the shared resource at time T1. Since the lock of the target resource is already held by thread C, thread A fails to compete for the lock, causing thread A to enter a blocked state. Since thread B has a higher priority than thread C, the CPU will prioritize thread B in scheduling resources, that is, thread B will occupy the CPU before thread C. As shown in Figure 4b, thread B seizes the CPU at time T2, and thread C becomes ready at time T2, waiting for thread B to run. Thread B finishes running at time T3 and releases the occupied CPU. At this time, thread C obtains the CPU and continues to run until the lock is released at time T4. After thread C releases the lock, thread A successfully competes for the lock. Since thread B has a higher priority than thread C, thread B can seize the CPU before thread C, resulting in an increase in the running time of thread C (that is, the increase is T4-T3), which increases the blocking time of thread A. That is to say, in the scenario shown in Figure 4b, the priority of thread B is higher than the priority of the lock holding thread, and the lock holding thread is prioritized in scheduling resources. The total running time (including ready time and running time) of the lock holding thread increases, and the blocking time of the UI thread increases, causing the startup page of the application to become stuck, drop frames, and other phenomena.

A method for running an application is provided in an embodiment of the present application, and the method is executed by an electronic device, and the electronic device can be a mobile phone, a bracelet, a tablet computer, a computer and other devices. When the first thread of the application fails to lock the target resource and the first thread is detected as the target thread, the priority of the lock-holding thread is increased; and the identification information of the lock-holding thread is transmitted to the kernel, and the kernel prioritizes scheduling resources for the lock-holding thread within a preset time. By giving priority to scheduling resources for the lock-holding thread by the kernel, if the lock-holding thread does not release the lock within the preset time, the lock-holding thread can run at a high priority, so that the processor can prioritize allocating resources to the lock-holding thread, further shortening the running time of the lock-holding thread, and shortening the blocking time of the first thread, so as to solve the problems of frame loss and freeze in the application, and the problem that the application takes too long to display the scan result.

FIG5 is a schematic diagram of the structure of an electronic device 100 shown in an embodiment of the present application. It should be understood that the electronic device 100 shown in FIG5 is only an example of an electronic device, and the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. The various components shown in FIG1 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: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

FIG. 6 is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

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

The application layer can include a series of application packages.

As shown in FIG6 , the application package may include applications such as video, music, map, WLAN, calendar, short message, gallery, call, navigation, Bluetooth, camera, etc.

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

As shown in FIG. 6 , the application framework layer may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like.

The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.).

The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

Android Runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.

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

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

The system library may include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

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

The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

A 2D graphics engine is a drawing engine for 2D drawings.

The kernel layer is the layer between hardware and software. The kernel layer includes a kernel scheduling module, which can modify the priority of threads; it can also prioritize resources for the second thread within a preset time according to the instructions of the first thread. The kernel layer can also package various drivers. For example, the kernel layer includes display drivers, camera drivers, audio drivers, and sensor drivers.

It is understandable that the layers in the software structure shown in FIG6 and the components contained in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer layers than shown in the figure, and each layer may include more or fewer components, which is not limited in the present application.

FIG7 is a flowchart showing an example of an application program running. The method for running the application program is executed by an electronic device. In this example, the electronic device is described by taking a mobile phone as an example. The process of running the application program includes:

Step 701: In response to a user operation on an application, a first thread in the application runs.

Specifically, a mobile phone has multiple applications installed, and the mobile phone starts the application in response to the user's operation of starting the application. When the application is started (or the mini program is started, the scan result is displayed), the operating system of the mobile phone creates a process for the application, and the process includes one or more threads. The mobile phone allows multiple threads to run simultaneously. In this example, the first thread can be any thread in the running application. The user's operation on the application may include: starting the application, starting the mini program, scanning the QR code, and other operations.

Step 702: If the first thread in the application fails to lock the target resource and it is detected that the first thread belongs to the target thread, the target thread updates the first priority of the second thread to the second priority.

Specifically, when the first thread fails to lock the target resource, the first thread may detect whether the first thread belongs to the target thread. The target resource may be a data resource, a code resource, an input/output resource, etc.

Optionally, the first thread may detect whether the process to which the first thread belongs is in the foreground running state, and if it is detected that the process to which the first thread belongs is in the foreground running state, then detect whether the first thread is a key thread. The key thread may be the main thread in the process.

Optionally, there are multiple ways for the first thread to detect whether the process to which it belongs is in the foreground running state. For example, the first thread can detect whether a canvas is displayed in the process to which it belongs. If so, it is determined that the process to which the first thread belongs is in the foreground running state. Optionally, running attribute information of the running state can be set in the process. If the running attribute information is true, it indicates that the process is in the foreground running state. The first thread can obtain the running attribute information in the process to which the first thread belongs, and can determine whether the process to which the first thread belongs is in the foreground running state.

Optionally, when the first thread determines that the process to which it belongs is in the foreground running state, the first thread can detect whether the second identification information of the process to which the first thread belongs is the same as the third identification information of the first thread; if the first thread determines that the second identification information is the same as the third identification information, it is determined that the first thread belongs to a critical thread.

If the first thread detects that the process to which the first thread belongs is not in the foreground running state, the process ends.

When the first thread fails to load the target resource and it is detected that the first thread belongs to the target thread, the first thread updates the first priority of the second thread to the second priority, the second priority is higher than the first priority, and the second thread is the thread holding the lock of the target resource; the priority of the target thread is higher than the first priority.

Optionally, the second priority can be the highest priority within the priority range of the second thread. For example, the priority range of the second thread is 139 to 100, where the value 139 represents the lowest priority and the value 100 represents the highest priority. If the first priority is 139, the first thread can update the priority of the second thread from 139 to 100.

Optionally, the first thread can also increase the priority of the second thread by a preset level within a preset priority range. For example, the priority range is 139 to 100. If the first priority of the second thread is 139 and the preset level is 20, the first thread can update the priority of the second thread from 139 to 119.

Step 703: Before entering the blocking state, the target thread transmits the first identification information of the second thread to the kernel.

Specifically, since the first thread fails to lock and before entering the blocking state, the first thread may also transmit the first identification information of the second thread to the kernel. The first identification information may include the thread ID of the second thread. Optionally, the first identification information may also include first attribute information, which is used to indicate whether the kernel gives priority to calling resources for the thread corresponding to the first identification information. For example, the first attribute information is represented by "is_vip". If the value of the first attribute information is true, it indicates that the kernel determines to give priority to calling resources for the thread to which the first attribute belongs within a preset time length.

Step 704: The kernel preferentially schedules resources for the second thread within a preset time period according to the first identification information.

Specifically, the kernel obtains the first identification information and, according to the instruction in the first identification information, preferentially schedules resources for the second thread within a preset duration. Optionally, if the kernel sees that the first attribute information in the first identification information is true, it may preferentially schedule resources for the second thread within a preset duration.

Since the kernel prioritizes scheduling resources for the second thread, the second thread can frequently obtain CPU time slices, which speeds up the operation of the second thread. The CPU frequently allocates CPU time slices to the second thread, which reduces the probability of other threads obtaining CPU time slices. In order to avoid adverse effects on the operation of other threads, the time for the kernel to prioritize scheduling resources for the second thread should not be too long. In this example, the preset duration can be less than or equal to 20 milliseconds (such as the preset duration is 5 milliseconds, 10 milliseconds, 15 milliseconds, 20 milliseconds, etc.). When the kernel detects that the duration of the priority scheduling of resources for the second thread reaches the preset duration, the operation of prioritizing scheduling resources for the second thread ends.

Step 705: If the second thread does not release the lock within the preset time, it runs according to the second priority.

Specifically, if the second thread has not finished running within the preset time and has not released the lock, the kernel ends the operation of preferentially scheduling resources for the second thread. Since the priority of the second thread is updated to the second priority, the second thread runs according to the second priority. The second priority is higher than the first priority, and the second thread of the second priority will obtain the CPU time slice and schedule resources preferentially before the second thread of the first priority, thereby shortening the time the second thread holds the lock and shortening the time the first thread is blocked.

Optionally, after the second thread finishes running, the second thread releases the lock. The first thread is awakened by the second thread, and the first thread competes for the lock again and successfully locks. After successfully holding the lock, the first thread changes the second priority of the second thread to the first priority.

In this example, the electronic device can be a mobile phone, a bracelet, a tablet computer, a computer and other devices. The kernel only preferentially allocates resources to the second thread within a preset time length. When the second thread does not release the lock within the preset time length, the second thread runs according to the second priority. Since the second priority of the second thread is higher than the first priority, the processor can allocate resources to the second thread according to the second priority, thereby avoiding the problem that the second thread is preempted by other threads with higher priority than the first priority after exceeding the preset time length, resulting in the second thread being in a ready state and unable to release the lock in time. In this example, the method of modifying the priority of the second thread and the method of allocating resources to the second thread by the kernel within a preset time length are combined. The two methods complement each other, which can further shorten the time the second thread holds the lock and reduce the time the first thread is blocked, thereby solving the problems of slow data loading, frame loss and freeze on the startup page caused by the blocking of the first thread.

Fig. 8 is a schematic diagram showing the interaction between the first thread, the second thread and the kernel. The process of running the application in the present application will be described in detail below with reference to Fig. 8 .

In this example, thread A is taken as an example of the first thread, and thread C is taken as an example of the second thread.

When the lock of the target resource is in an unlocked state, if thread C performs a locking operation on the target resource, the lock of the target resource is in a light lock state. When other threads (such as thread D) access the target resource, thread D waits by spinning. When the number of times thread D spins exceeds the number threshold, the lock of the target resource will expand and upgrade from a light lock state to a heavy lock state. Alternatively, when the lock of the target resource is in a light lock state, when thread D is spinning and thread E accesses the target resource, the lock of the target resource will be upgraded from a light lock state to a heavy lock state.

The lock of the target resource is in a relocked state at time T1, at which time the thread C holds the Monitor object, wherein the Monitor object contains a lock instance (ie, a mutex instance, also referred to as mutex hereinafter).

Step 801: Thread A performs a lock operation on the target resource.

Specifically, at time T1, thread C holds the lock of the target resource, and the lock of the target resource is in a relocked state, and the Monitor object of the target resource is held by thread C. At time T2, thread A locks the target resource, that is, executes the MonitorEnter() method. Among them, time T2 is later than time T1. When thread A executes the MonitorEnter() method, thread A will try to obtain the Monitor object.

Step 802: Thread A attempts to lock, and fails to lock.

Specifically, thread A may attempt to hold the Monitor object through a CAS (Compare And Swap) algorithm. If the attempt fails, it is determined that thread A has failed to lock.

Step 803: Thread A detects whether it belongs to the target thread.

Specifically, thread A detects that the state of the lock is in a relocked state, and can detect whether thread A belongs to the target thread. Thread A first detects whether the process to which thread A belongs is in the foreground running state. If the process to which thread A belongs is in the foreground running state, thread A can obtain the identification information (i.e., PID) of the process to which thread A belongs, and compare the identification information of the process to which thread A belongs with the identification information of thread A. If thread A detects that the identification information (i.e., PID) of the process to which thread A belongs is consistent with the identification information of thread A (i.e., TID), it is determined that thread A is the key thread of the process to which thread A belongs, that is, thread A is the target thread.

In one example, since there is also a small program in the application program, the process to which thread A belongs may be the process of the small program.

It should be noted that, when thread A detects that the lock is in a relocked state, thread A can detect whether thread A is in the target thread through the Monitor object.

Thread A determines that thread A belongs to the target thread, and then executes step 804.

Step 804: If thread A detects that it belongs to the target thread, thread A changes the first priority of thread C to the second priority.

Specifically, if thread A detects that thread A belongs to the target thread, thread A can change the first priority of thread C to a second priority, which is higher than the first priority. Optionally, the second priority can be the highest priority within the priority range of thread C. For example, the range of ordinary priority is 139 to 100, where 139 is the lowest priority and 100 is the highest priority. The priority of thread C belongs to the ordinary priority, so thread A can change the priority of thread C to 100, which is the highest priority.

Optionally, thread A may also obtain the first priority of thread C, and determine the second priority according to the priority range of thread C. For example, if thread A detects that the first priority is within the priority range after increasing the preset level, thread A determines the second priority as the sum of the current first priority and the preset level (such as the preset level is -20, -15, -30, etc.), that is, the second priority = the first priority (139-20).

Step 805: Before entering the blocking state, thread A obtains the identification information of thread C from the lock.

Specifically, before entering the blocking state, thread A can obtain the identification information of thread C from the Monitor object or mutex. The Monitor object or mutex stores a pointer to the lock-holding thread, through which the identification information of the lock-holding thread (i.e., thread C) can be obtained, so that thread A can subsequently change the priority of the lock-holding thread (i.e., thread C).

In this example, thread A obtains the identification information of thread C from mutex.

Step 806: Thread A passes the identification information of thread C to the kernel.

Specifically, thread A transmits the first identification information of thread C to the kernel. The first identification information may include the ID number of the thread, and may also include first attribute information for indicating that the kernel should give priority to scheduling resources for thread C within a preset duration. For example, the first attribute information may be represented by "is_Vip". When the first attribute information is true, it indicates that the thread needs to schedule resources within the preset duration.

Step 807: The kernel schedules resources for thread C preferentially.

Specifically, when the kernel obtains the thread ID number and the first attribute information in the first identification information, the timer can be started to prioritize scheduling resources for thread C within a preset duration. For example, the kernel receives the first identification information, recognizes that the ID number and the first attribute information of thread C are true, and then starts the timer to start timing, wherein the preset duration is less than or equal to 20 milliseconds, such as the preset duration is 20 milliseconds, 15 milliseconds, 10 milliseconds, etc. In this example, the preset duration is illustrated by taking 20 milliseconds as an example. Within 20 milliseconds, the kernel can frequently allocate resources to thread C, that is, thread C can frequently occupy the CPU within 20 milliseconds. When the kernel detects that the timer reaches 20 milliseconds, the operation of allocating resources to thread C is immediately terminated. Optionally, the preset duration can also be detected by a timer.

Step 808: After the preset duration is reached, the kernel ends the operation of prioritizing resource scheduling for thread C.

Specifically, the kernel may delete the first identification information after completing the operation of preferentially scheduling resources for thread C.

Optionally, if thread C finishes running within a preset time and releases the lock, the kernel may also end the operation of prioritizing resource scheduling for thread C.

Step 809: Thread C runs at the second priority.

Specifically, if thread C does not release the lock within the preset time, thread C will run at the modified second priority because the kernel has finished scheduling resources for thread C. Since the second priority of thread C is higher than the first priority, the probability of thread C being preempted by other threads during its execution is reduced, thereby reducing the problem of thread A being blocked for a long time.

If the second priority is the highest priority, the problem of CPU being preempted by other threads can be avoided, the time that thread C is in the ready state is shortened, the lock holding time of thread C is further reduced, and the time that thread A is blocked is reduced.

Step 810: Thread C releases the lock.

Specifically, when thread C finishes running, the lock can be released, that is, thread C releases the monitor object.

Step 811: Thread A is awakened.

Specifically, because thread C releases the Monitor object, thread A is awakened and step 811 is executed.

Step 812: Thread A holds the lock successfully.

Specifically, after thread C releases the lock, thread A attempts to lock the target resource again. Since the lock of the target resource is in a relocked state and is not held by the thread at this time, thread A successfully holds the lock.

Step 813: Thread A updates the second priority of thread C to the first priority.

Specifically, after thread C releases the lock, thread A successfully holds the lock and ends the blocking. Thread A can update the second priority of thread C to the first priority. Changing the priority of thread C to the first priority avoids unnecessary impact of thread C on other threads in a high priority state.

FIG. 9 is a schematic diagram exemplarily showing a thread calling a CPU using the method for running an application program in the present application.

As shown in FIG9 , thread A is the main thread in the startup process of application A. The priority of thread A is higher than that of thread C. The priority of thread A is higher than that of thread B, and the priority of thread B is higher than that of thread C. Thread C locks the shared resource at time T0, and the lock is in a relocked state. Thread A locks the shared resource at time T1. Since the lock of the target resource is already held by thread C, thread A fails to compete for the lock. As shown by the dotted arrow in FIG9 , thread A modifies the first priority of thread C (such as 139) to the second priority, and the second priority is the highest priority (such as 100) within the priority range to which thread C belongs. Thread A obtains the first identification information of thread C, which includes the identity ID of thread C and the first attribute information, and the first attribute information indicates true. Thread A transmits the first identification information of thread C to the kernel, and the kernel obtains the first identification information, starts the timer, and the kernel preferentially schedules resources for thread C. When the kernel detects that the timer reaches the preset duration (such as T1 to T2), the operation of preferentially scheduling resources for thread C ends. Thread C does not release the lock within the preset time, and thread C will run at priority 100. Since the priority of thread C is 100 and the priority of thread B is 120, the priority of thread C is higher than that of thread B. Thread C will prioritize resource scheduling, that is, thread C will prioritize CPU time slices, and thread B is in the ready state. Thread C releases the lock at time T3, and thread A locks the target resource, and thread A successfully locks the target resource. Thread A can modify the priority of thread C to the first priority (that is, 139). At this time, the priority of thread B is 120, and it can obtain the CPU time slice. Since the running time of thread C is shortened, the blocking time of thread A is shortened, thereby solving the problem of frame loss and jamming on the startup page due to long blocking time of thread A, and also solving the problem of long time to display the scan result due to long blocking time of thread A.

In some embodiments, when the first thread in the application fails to lock the target resource and it is detected that the first thread is the target thread, the priority of the current lock-holding thread can be increased so that the lock-holding thread can preempt other threads from seizing the CPU, thereby reducing the running time of the lock-holding thread and thereby shortening the time the first thread is blocked, thereby solving the problem of frame loss and freeze in the application.

FIG10 is a flowchart showing an exemplary operation of an application program, wherein the process includes:

Step 1001: The second thread successfully locks the target resource.

In this example, the second thread successfully locks the target resource. When the lock state of the target resource is in a relocked state, the second thread holds the lock of the target resource.

Step 1002: The first thread attempts to lock the target resource.

Specifically, the priority of the first thread is higher than the priority of the second thread. The first thread can attempt to lock the target resource. If the lock state of the target resource is in a re-locked state, it can be detected whether the re-lock is released by the holding thread, that is, step 1003 is executed.

Step 1003: The first thread detects whether the lock of the target resource is held by other threads.

Specifically, the first thread may detect whether the lock of the target resource is released by attempting to lock. If the locking attempt fails, it may be determined that the lock of the target resource is held by other threads.

Step 1004: If the first thread detects that the lock of the target resource is held by other threads, the first thread detects whether it belongs to the target thread.

This process is similar to step 803, and reference may be made to the description in step 803, which will not be repeated here.

Step 1005: If the first thread detects that the first thread belongs to the target thread, the first thread updates the first priority of the second thread to the second priority.

This process is similar to step 804 , and the description in step 804 may be referred to, and will not be repeated here. After the priority of the second thread is the second priority, the second thread runs according to the second priority, that is, step 1007 is executed.

Step 1006: The first thread is in a blocked state, waiting for the second thread to release the lock of the target resource.

Specifically, after the first thread changes the priority of the second thread to the second priority, the first thread enters a blocked state and waits for the second thread to release the lock of the target resource.

Step 1007: The second thread runs according to the second priority, and the processor schedules resources for the second thread according to the second priority.

This process is similar to step 809, and you can refer to the description in step 809, which will not be repeated here.

Step 1008: The second thread releases the lock.

Specifically, after the second thread finishes running according to the second priority, the lock of the target resource can be released.

Step 1009: The first thread successfully locks the target resource, and the second priority of the second thread is updated to the first priority.

After the second thread releases the lock, the first thread successfully locks and the first thread resumes running. The first thread can update the second priority of the second thread to the first priority.

Fig. 11 is a schematic diagram showing the interaction between the first thread and the second thread. The following specifically describes the process of running the application in the present application in conjunction with Fig. 11.

Step 1101: Thread A performs a lock operation on the target resource.

Step 1102: Thread A attempts to lock, and fails to lock.

Step 1103: Thread A detects whether it belongs to the target thread.

Step 1104: If thread A detects that it belongs to the target thread, thread A changes the first priority of thread C to the second priority.

Steps 1101 to 1104 are similar to steps 801 to 804 , and reference may be made to the relevant descriptions in steps 801 to 804 , which will not be repeated here.

Step 1105: Thread C runs at the second priority.

Specifically, since the second priority of thread C is higher than the first priority, the probability of CPU being preempted by other threads during the running of thread C is reduced, thereby reducing the problem of thread A being blocked for a long time.

If the second priority is the highest priority, the problem of CPU being preempted by other threads can be avoided, the time that thread C is in the ready state is shortened, the running time of thread C is further reduced, and the time that thread A is blocked is reduced.

Step 1106: Thread C releases the lock.

Step 1107: Thread A is awakened.

Step 1108: Thread A holds the lock successfully.

Step 1109: Thread A updates the second priority of thread C to the first priority.

Steps 1106 to 1109 are similar to steps 810 to 813 , and reference may be made to the relevant descriptions in steps 810 to 813 , which will not be repeated here.

It is understandable that, in order to realize the above functions, the electronic device includes hardware and/or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of the present application.

This embodiment also provides a computer storage medium, in which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the method for running the application program in the above-mentioned embodiment. The storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

This embodiment also provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the method for running the application program in the above-mentioned embodiment.

Among them, the electronic device, computer storage medium, computer program product or chip provided in this embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above and will not be repeated here.

The term "and/or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects rather than to describe a specific order of objects. For example, a first target object and a second target object are used to distinguish different target objects rather than to describe a specific order of target objects.

In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

In the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" refers to two or more than two. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

Any content of each embodiment of the present application, as well as any content of the same embodiment, can be freely combined. Any combination of the above content is within the scope of the present application.

The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims (11)

1. A method for running an application, comprising:

Responding to the operation of a user on an application program, wherein a first thread in the application program runs;

if the first thread fails to lock the target resource and the first thread is detected to belong to the target thread, the target thread updates the first priority of the second thread to a second priority, wherein the second priority is higher than the first priority, and the second thread is a thread holding the lock of the target resource; the target thread has a higher priority than the first priority, and the target resource includes: a data resource, a code resource or an input/output resource, wherein the process of the target thread is in a foreground running state and the target thread is a main thread in the process;

Transmitting the first identification information of the second thread to a kernel;

The kernel schedules resources for the second thread preferentially in a preset duration according to the first identification information;

if the second thread does not release the lock within the preset time, the second thread operates according to the second priority;

And when the target thread successfully locks the target resource, updating the second priority of the second thread to the first priority.

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

And the first thread performs locking operation on the target resource, and if the first thread detects that the lock of the target resource is a heavy lock and the lock is not released by the second thread, the first thread determines that the locking of the target resource fails.

3. The method of claim 1, wherein detecting whether the first thread belongs to the target thread comprises:

the first thread detects whether a process to which the first thread belongs is in a foreground running state;

If the first thread determines that the process to which the first thread belongs is in a foreground running state, detecting whether the first thread is a key thread, wherein the key thread is a main thread in the process to which the first thread belongs;

and if the first thread detects that the first thread is a key thread, determining that the first thread belongs to a target thread.

4. The method of claim 3, wherein the detecting whether the first thread is a critical thread comprises:

the first thread acquires second identification information of a process to which the first thread belongs;

Judging whether the second identification information is identical to third identification information of the first thread;

If the second identification information is detected to be the same as the third identification information, determining that the first thread is a key thread;

and if the second identification information is detected to be different from the third identification information, determining that the first thread is not a key thread.

5. The method of claim 1, wherein the core prioritizing scheduling resources for the second thread for a preset duration according to the first identification information, comprising:

If the kernel acquires the first identification information, starting a timer;

and if the kernel detects that the time length recorded by the timer reaches the preset time length, ending the operation of preferentially scheduling the resources for the second thread.

6. The method of claim 1, wherein the first identification information comprises: the identity number of the second thread and first attribute information, wherein the first attribute information is used for indicating whether the kernel schedules resources for the second thread preferentially.

7. The method of claim 1, wherein the target thread updates the first priority of the second thread to the second priority, comprising:

The target thread acquires first identification information of the second thread when detecting that the lock is a lock;

And the target thread updates the first priority to the second priority through an interface according to the first identification information.

8. The method of claim 1, wherein the predetermined duration is less than or equal to 20 milliseconds.

9. The method of claim 1, wherein the first thread belongs to the application or to an applet in the application.

10. An electronic device, comprising:

A memory and a processor, the memory coupled with the processor;

The memory stores program instructions that, when executed by the processor, cause the electronic device to perform the method of application execution of any of claims 1-9.

11. 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 a method of running an application program executed by the electronic device according to any of claims 1-9.