WO2019128571A1

WO2019128571A1 - Resource management method and device, mobile terminal, as well as computer readable storage medium

Info

Publication number: WO2019128571A1
Application number: PCT/CN2018/116944
Authority: WO
Inventors: 方攀; 陈岩
Original assignee: Oppo广东移动通信有限公司
Priority date: 2017-12-29
Filing date: 2018-11-22
Publication date: 2019-07-04
Also published as: CN109992399A; CN109992399B

Abstract

A resource management method, comprising: acquiring operating characteristics of a background application, and determining an application scenario type of the background application according to the operating characteristics, the application scenario type comprising a perceptible application and an imperceptible application; determining a resource constraint level of the background application according to the application scenario type; and performing resource management on the background application according to the resource constraint level.

Description

Resource management method, device, mobile terminal and computer readable storage medium

Cross-reference to related applications

This application claims the priority of the Chinese Patent Application filed on Dec. 29, 2017, the Chinese Patent Application No. 201711488953.7, entitled "Resource Management Methods, Devices, Mobile Terminals, and Computer Readable Storage Media", the entire contents of which are incorporated herein by reference. This is incorporated herein by reference.

Technical field

The present application relates to the field of computer technologies, and in particular, to a resource management method, apparatus, mobile terminal, and computer readable storage medium.

Background technique

With the rapid development of the Internet, smart mobile terminals have become the most commonly used electronic devices for many users, such as smart phones and tablet boards. Users can install various applications on the smart mobile terminal for use. When the application runs in the background, it will preempt the CPU (Central Processing Unit), memory, bandwidth and other system resources with the application running in the foreground. This leads to problems such as the application running in the foreground, the slow operation of the system, and the fever of the mobile terminal.

Summary of the invention

The embodiment of the present application provides a resource management method, device, mobile terminal, and computer readable storage medium.

A resource management method, including:

Obtaining an running feature of the background application, and determining an application scenario type of the background application according to the running feature, where the application scenario type includes a perceptible application and an imperceptible application;

Determining, according to the type of the application scenario, a resource restriction level of the background application;

Resource management is performed on the background application according to the resource restriction level.

A resource management device comprising:

a scenario determining module, configured to acquire a running feature of the background application, and determine an application scenario type of the background application according to the running feature, where the application scenario type includes a perceptible application and an imperceptible application;

a level determining module, configured to determine a resource restriction level of the background application according to the application scenario type;

And a management module, configured to perform resource management on the background application according to the resource restriction level.

A mobile terminal includes a memory and a processor in which is stored a computer program that, when executed by the processor, causes the processor to implement the method as described above.

A computer readable storage medium having stored thereon a computer program that, when executed by a processor, implements the method as described above.

The resource management method, the device, the mobile terminal, and the computer readable storage medium acquire the running characteristics of the background application, determine the application scenario type of the background application according to the running feature, and determine the resource restriction level of the background application according to the application scenario type, according to the resource limitation. The level manages the resources of the background application, and can dynamically implement different levels of resource restrictions on the background application according to the application scenario type of the background application, optimize system performance, and save power consumption.

DRAWINGS

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings to be used in the embodiments or the prior art description will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present application, and other drawings can be obtained according to the drawings without any creative work for those skilled in the art.

1 is a block diagram of a mobile terminal in one embodiment.

2 is a system architecture diagram of a resource management method in an embodiment.

FIG. 3 is a schematic flow chart of a resource management method in an embodiment.

4 is a schematic diagram of different resource restriction levels in one embodiment.

FIG. 5 is a schematic flowchart of unified resource management for a process running in a background application in an embodiment; FIG.

FIG. 6 is a schematic flowchart of reducing the resource restriction level of a background process having a dependency relationship with a foreground process in one embodiment.

Figure 7 is a block diagram of a resource management device in one embodiment.

Figure 8 is a block diagram of a management module in one embodiment.

Figure 9 is a block diagram of a resource management apparatus in another embodiment.

Figure 10 is a block diagram of a mobile terminal in another embodiment.

Detailed ways

In order to make the objects, technical solutions, and advantages of the present application more comprehensible, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

It will be understood that the terms "first", "second" and the like, as used herein, may be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish one element from another. For example, a first client may be referred to as a second client, and similarly, a second client may be referred to as a first client, without departing from the scope of the present application. Both the first client and the second client are clients, but they are not the same client.

1 is a block diagram of a mobile terminal in one embodiment. As shown in FIG. 1, the mobile terminal includes a processor, a memory, a display screen, and an input device connected through a system bus. The memory may include a non-volatile storage medium and a processor. The non-volatile storage medium of the mobile terminal stores an operating system and a computer program, which are executed by the processor to implement a resource management method provided in the embodiments of the present application. The processor is used to provide computing and control capabilities to support the operation of the entire mobile terminal. The internal memory in the mobile terminal provides an environment for the operation of a computer program in a non-volatile storage medium. The display screen of the mobile terminal may be a liquid crystal display or an electronic ink display screen. The input device may be a touch layer covered on the display screen, or may be a button, a trackball or a touchpad provided on the casing of the mobile terminal, or may be An external keyboard, trackpad, or mouse. The mobile terminal can be a mobile phone, a tablet or a personal digital assistant or a wearable device. A person skilled in the art can understand that the structure shown in FIG. 1 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the mobile terminal to which the solution of the present application is applied. The specific mobile terminal may It includes more or fewer components than those shown in the figures, or some components are combined, or have different component arrangements.

2 is a system architecture diagram of a resource management method in an embodiment. As shown in FIG. 2, the system architecture includes a JAVA spatial layer 210, a local framework layer 220, and a kernel space layer 230. The JAVA spatial layer 210 can include a freeze management module 212. The freeze management module 212 can implement a freeze policy for each running application, and freeze the related applications that consume more power in the background or preempt a large amount of system resources. . The resource priority and restriction management module 222 and the platform freeze management module 224 are included in the local framework layer 220. The mobile terminal can maintain different applications in different resource usage priorities and different resource groups in real time through the resource priority and restriction management module 222, and adjust the resource group of the application according to the requirements of the upper layer to achieve optimized performance. Save power. The mobile terminal can allocate the application that can be frozen in the background to the frozen layer corresponding to the preset different levels according to the length of the entry freeze time through the platform freeze management module 224. Optionally, the frozen layer may include three: a CPU limited sleep mode, a CPU freeze sleep mode, and a process deep freeze mode. The CPU restricts the sleep mode to limit the CPU resources occupied by the related processes, so that the related processes occupy less CPU resources, and the free CPU resources are tilted to other unfrozen processes, thereby limiting the occupation of CPU resources. It also limits the occupation of network resources and I/O interface resources by the process; CPU freeze sleep mode refers to prohibiting related processes from using the CPU, while preserving the occupation of memory, when prohibiting the use of CPU resources, the corresponding network resources and I The /O interface resource is also forbidden; the process deep freeze mode means that in addition to prohibiting the use of CPU resources, the memory resources occupied by the related processes are further recovered, and the recovered memory can be used by other processes. Optionally, the local framework layer 220 may further include an interface module, where the interface module includes a binder interface developed to the upper layer, and the upper layer framework or the application sends the resource restriction or the frozen instruction to the resource priority and the limit management through the provided binder interface. Module 222 and platform freeze management module 224.

The kernel space layer 230 may include a UID management module 231, a Cgroup module 233, a Binder management module 235, a process memory recovery module 237, and a freeze timeout exit module 239. The UID management module 231 is configured to implement an application-based User Identifier (UID) to manage resources of a third-party application or freeze. Compared with the Process Identifier (PID) for process management and control, it is easier to uniformly manage the resources of a user's application through UID. The Cgroup module 233 is used to provide a complete set of CPU, CPUSET, memory, input/output (I/O) and Net related resource restriction mechanisms. The Binder management module 235 is used to implement the priority control of the background binder communication. The process memory recovery module 237 is configured to implement the process deep freeze mode, so that when a third-party application is in a frozen state for a long time, the file area of the process is mainly released, thereby saving the memory module and speeding up the application next time. The speed at startup. The freeze timeout exit module 239 can be used to resolve an exception generated by the freeze timeout scenario. Through the system architecture described above, the resource management method in various embodiments of the present application can be implemented.

As shown in FIG. 3, in an embodiment, a resource management method is provided, including the following operations:

In operation 310, the running feature of the background application is obtained, and the application scenario type of the background application is determined according to the running feature.

The mobile terminal can run one or more applications at the same time, and can include a foreground application running in the foreground and a background application running in the background. The mobile terminal can obtain the running characteristics of the background application, and determine the application scenario type of each background application according to the running characteristics. Optionally, the application scenario type may include a perceptible application and an imperceptible application. A perceptible application refers to an application that can be heard, seen, and the like that can be perceived by a user, such as a music application that is playing music, an application that is downloading a file, and the like, but is not limited thereto, although the application has entered Running in the background, but still being perceived by the user that the app is running. An imperceptible application refers to an application that is not perceptible to the user, such as a social application running in the background, a payment application, etc., but is not limited thereto. In an embodiment, the non-aware application may include an imperceptible application that receives the process communication and an unperceivable application that has no process communication, wherein the non-aware application that receives the process communication refers to the process running under the application and other processes exist communication, etc. An imperceptible application of interaction, an imperceptible application of no process communication refers to an imperceptible application in which a process running under an application does not communicate with other processes.

The mobile terminal can obtain the running features of each background application that is currently running in the background. The running features can include, but are not limited to, the currently executed task, the communication event of each process under the application, the resource type and proportion currently occupied by the application, and the like. The mobile terminal can determine the application scenario type of the background application according to the running feature of the background application, and the different application scenario types can preset the corresponding scenario conditions according to the actual requirements, and determine the application scenario type according to the scenario conditions that the running feature meets. For example, the application scenario type is a scenario condition corresponding to the perceptible application, which may include the currently executed task being a play task or a download task, and the application scenario type is an insensitive application that receives the process communication, and the application may include the process existing in the preset time period. Communication events, etc., but are not limited to this.

Optionally, the application scenario type of the background application may change according to the running feature. For example, when the music application plays music in the background, the application scenario type of the music application may be a perceptible application, and when the music application stops playing, When music is played, the type of application scene of the music application can be changed to an imperceptible application. In an embodiment, the mobile terminal may acquire running characteristics of each background application at intervals, and determine an application scenario type of each background application according to the running characteristics. The mobile terminal can also monitor the tasks performed by the various background applications. When it is detected that the background application starts executing the task or the task is completed, the running characteristics of the background application are obtained, and then the application scenario type of the background application is determined according to the running characteristics.

Operation 320, determining a resource restriction level of the background application according to the application scenario type.

The mobile terminal can set different resource restriction levels according to actual needs. The resource restriction level can be used to indicate the extent to which the application usage resource is restricted. The higher the resource restriction level, the greater the degree of restriction. Restricted resources may include, but are not limited to, CPU resources, memory resources, I/O resources, network resources, and the like. The application scenarios of the background application are different, and may respectively correspond to different resource restriction levels. Optionally, the resource restriction level corresponding to the background application of the application-aware application type may be lower than the non-sensible application, and the application scenario type is the receiving process communication. The background application of the non-perceived application may have a resource restriction level lower than that of the non-process communication.

In an embodiment, the resource restriction level set by the mobile terminal may include an unrestricted level, a normal restriction level, a depth restriction level, and a freeze level. An unrestricted level can mean that the resources used by the application are not restricted, and the applications running in the foreground can correspond to an unrestricted level, thereby ensuring the normal operation of the foreground application. The normal restriction level may refer to an application that can use less resources, such as an application that can only use up to 50% of resources, etc., but is not limited thereto. A background application whose application type is a perceptible application can correspond to a common restriction level, and the background application can reduce the preemption of resources in the case that the perceptible task of the background application can be executed normally. The depth limit level can refer to the application to use very few resources, such as the application can only use up to 20% of resources, etc., but is not limited to this. The background application whose application scenario type is an unperceived application that receives the communication of the process can correspond to the depth limit level, and the used resources can meet the processing requirements of the inter-process communication task. The freeze level refers to the behavior of the application that cannot use any resources and stop the application. A background application whose application scenario type is an insensible application of a processless communication application can correspond to a freeze level and save power. It can be understood that the resource restriction level can also be divided in other ways, and is not limited to the above several ways.

Operation 330, performing resource management on the background application according to the resource restriction level.

The different resource restriction levels may respectively correspond to different resource usage priorities. The higher the resource restriction level, the lower the corresponding resource usage priority, the fewer resources the application can use, the lower the resource restriction level, and the corresponding resource usage priority. The higher the level, the more resources the application can use. Optionally, after the mobile terminal determines the resource restriction level according to the application scenario type of the background application, the background application may configure the resource usage priority corresponding to the resource restriction level. The resource usage priority configured by the application scenario type application-aware background application may be higher than the non-sensible application, and the application scenario type is the non-perceived application configured to receive the process communication, and the resource usage priority may be higher than the non-processless application of the non-process communication. .

After the mobile terminal configures the resource usage priority according to the resource restriction level of the background application, the resource used by the background application may be managed according to the configured resource usage priority. When the application scenario type of the background application changes, the mobile terminal may re-determine the resource usage level according to the changed application scenario type.

4 is a schematic diagram of different resource restriction levels in one embodiment. As shown in FIG. 4, four different resource restriction levels can be set in the mobile terminal, including an unrestricted level, a normal limit level, a depth limit level, and a freeze level. Unrestricted levels do not limit resources such as CPU, memory, I/O, and networking used by applications. Ordinary limit level restrictions apply to using less resources such as CPU, memory, I/O, and networking. The depth limit level limits the application to use very few resources such as CPU, memory, I/O, and networking. Freeze level restrictions apply to resources such as CPU, memory, I/O, and networking. The mobile terminal can determine the resource restriction level according to the application scenario type of the background application, and implement different levels of resource limitation for the background application of different application scenario types.

In this embodiment, the running feature of the background application is obtained, and the application scenario type of the background application is determined according to the running feature, the resource restriction level of the background application is determined according to the application scenario type, and resource management is performed on the background application according to the resource restriction level. The application scenario type of the background application dynamically implements different levels of resource limits for the background application, optimizes system performance, and saves power consumption.

As shown in FIG. 5, in an embodiment, operation 330 performs resource management on the background application according to the resource restriction level, including the following operations:

Operation 502: Obtain user group information of the background application.

Process is a computer program run on a set of data on the activities of the system is the basic unit of resource allocation and scheduling, is the underlying operating system architecture. There are usually multiple processes running on a mobile terminal, and different processes can be used to perform different tasks separately. An application may run one or more processes. After the mobile terminal determines the resource restriction level according to the application scenario type of the background application, the unified resource management may be performed on each process running in the background application according to the resource restriction level. Optionally, when the application is running, the mobile terminal can assign different user groups to the running application, manage the permissions of the application through the user group, and the like. The mobile terminal can obtain the user group information of the background application, and obtain the processes running under the background application according to the user group information, where the user group information can include the user group identifier, etc., and the user group identifier can be represented by numbers, letters, symbols, and the like. One or more are constructed.

Operation 504, querying a process identifier that has a mapping relationship with the user group information.

The mobile terminal can query the process identifiers that are in a mapping relationship with the user group information according to the user group information of the background application, thereby obtaining each process running under the background application. The kernel space layer of the mobile terminal can collect the user group information to which the process belongs in real time. When the process is created or destroyed, the kernel can allocate and release the user group information to which the process belongs, and the process can also occur during the running process. The case where the user group information is changed. The kernel space layer collects user group information of each process in real time, and can establish a mapping relationship between process information such as process ID and process name and user group information. When the mobile terminal needs to adjust the resource restriction level of the background application, the process identifier of the mapping relationship may be directly queried according to the user group information of the background application, and the process running under the background application is found by directly traversing all the running processes, and directly searching and The process ID of the user group information with mapping relationship is more convenient and faster.

Operation 506, adding a background process that matches the process identifier to the resource group corresponding to the resource restriction level.

The mobile terminal can be divided into different resource groups, and each resource group can respectively correspond to different resource restriction levels, and corresponding resource usage priorities are configured. After the mobile terminal queries the process identifier that has the mapping relationship with the user group information, the background process that matches the process identifier may be added to the resource group corresponding to the determined resource restriction level, so as to run on the background application according to the resource restriction level. Each process carries out unified resource management. Optionally, the mobile terminal may divide different resource groups based on a kernel Cgroup (control group) mechanism, and set a resource usage priority of each resource group by using a file node write configuration manner, and use the processes in each resource group. The time or proportion of resources is managed. Cgroup is a kind of physical resources (such as CPU, memory, I/O, etc.) that can be used to limit, record, and isolate process groups. mechanism. The mobile terminal can load a Cgroup configuration file, and the configuration file can record the divided resource groups, the resource usage priorities of the resource groups, and the resource scheduling policies corresponding to the resource usage priorities. The resource scheduling policy may include, but is not limited to, the time when the process uses the resource, the proportion of the occupied resource, the resource identifier used, and the like. For example, the process that can configure the resource group corresponding to the common restriction level can use 30 seconds of CPU resources in one minute. The process of the resource group corresponding to the common restriction level can only use the CPU resource numbered X, but is not limited thereto. When you need to add a new resource group, or modify the resource usage priority and resource scheduling policy of the resource group, you can modify the Cgroup configuration file.

In this embodiment, the process identifier with the mapping relationship may be found according to the user group information of the background application, and the background process matching the process identifier is added to the resource group corresponding to the resource restriction level, and the resource restriction level may be Unified resource management is performed for each process running under the background application. The resource group can also achieve different levels of resource limitation, optimize system performance, and save power consumption.

As shown in FIG. 6, in an embodiment, the foregoing resource management method further includes the following operations:

Operation 602, obtaining a foreground process running in the foreground.

The mobile terminal can obtain a foreground process running in the foreground. Optionally, the mobile terminal can obtain a list of all running processes through the activity manager's RunningAppProcessInfo class, and obtain a process running in the foreground from the process list to determine the process. The running state is that the foreground running process is the foreground process.

Operation 604, when there is a background process having a dependency relationship with the foreground process, reducing the resource restriction level of the background process having the dependency.

After the mobile terminal obtains the foreground process running in the foreground, it can detect whether there is a background process that has a dependency relationship with the foreground process. The dependency relationship refers to a process that needs to wait for the message of another process to be executed normally, and then the two processes are executed. There is a dependency. Optionally, the mobile terminal may pre-record the process identifier with the dependency, obtain the process identifier of the foreground process, and obtain the process identifier that has a dependency relationship with the foreground process according to the process identifier of the foreground process. The mobile terminal may detect each process running in the background according to the process identifier having a dependency relationship with the foreground process, and determine whether there is a background process having a dependency relationship with the foreground process.

The mobile terminal can reduce the resource restriction level of the background process that has a dependency relationship with the foreground process, and improve the resource usage priority of the background process with the dependency. Optionally, the mobile terminal may adjust the resource restriction level of the background process that has a dependency relationship with the foreground process to the same resource restriction level as the foreground process, and allocate the background process with the dependency to the same resource group as the foreground process. Medium, and configure the same resource usage priority as the foreground process. Improve the resource usage priority of the background process that has dependencies on the processes running in the foreground, which can speed up the task execution of the background process that has dependencies on the processes running in the foreground, thereby reducing the waiting time of the foreground running process and speeding up the running of the foreground process. .

In an embodiment, the mobile terminal may detect whether there is a background process that has interactive communication with the foreground process, and determine a background process that has interactive communication with the foreground process as a background process having a dependency relationship with the foreground process. Optionally, the inter-process interaction communication may include a synchronization mechanism and/or a communication mechanism, etc., wherein the synchronization mechanism may refer to two processes coordinating with each other to complete a task, and the communication mechanism refers to spreading between different processes. Or exchange information.

In one embodiment, the mobile terminal may detect whether there is a background process having a communication mechanism with the foreground process, and may determine a background process having a communication mechanism with the foreground process as a background process having a dependency. The communication mechanism may include a socket, a binder, a shared memory, etc., wherein two programs on the network exchange data through a two-way communication connection, and one end of the connection is called a socket; the binder is an inter-process communication mechanism, providing Remote procedure call function; shared memory is to allow two unrelated processes to access the same logical memory, shared memory is a very effective way to share and transfer data between two running processes, sharing between different processes The memory is usually arranged in the same piece of physical memory. Optionally, the mobile terminal may detect whether there is a background process that has a socket and/or a binder communication with the process running in the foreground, and may determine, as a dependency, a background process that has a socket and/or a binder communication with the process running in the foreground. backstage process. The mobile terminal can also detect whether there is a background process that performs memory sharing with the process running in the foreground, and can determine the background process that performs memory sharing with the process running in the foreground as a background process with dependencies. In an embodiment, the mobile terminal may add a detection mechanism to the binder driver, and detect whether there is a background process having a communication mechanism with the foreground process according to the detection mechanism added in the binder driver.

In one embodiment, the mobile terminal may detect whether there is a background process having a synchronization mechanism with the foreground process, and may determine a background process having a synchronization mechanism with the foreground process as a background process having a dependency. The synchronization mechanism may include a semaphore, a mutex, etc., wherein the semaphore data structure is a value and a pointer pointing to the next process waiting for the semaphore, and the mutex can be used to ensure the integrity of the shared data. Sex, only one process can access an object with a mutex lock at any time. Optionally, the mobile terminal can detect, by using a call of a futex (fast user space mutex) system, whether there is a background process that has a synchronization mechanism with the foreground process. The call of the futex system can be used to implement the synchronization mechanism between processes, and the operation in the user space is a user mode and kernel mode hybrid mechanism, wherein the user state refers to a non-privileged state.

In one embodiment, when the mobile terminal detects that a foreground process has a lock wait behavior, it may determine a lock resource that the foreground process waits for. The lock resource may include a thread lock, a file handle, a signal, etc., wherein the file handle refers to a sequence number retrieved by the operating system function when the data is read from the file, so that the file can be opened, and the file handle is unique to the opened file. Identification basis. The mobile terminal can traverse all the processes running in the background, and detect whether there is a background process waiting for the same lock resource as the foreground process, and the background process waiting for the same lock resource as the foreground process can be determined as a background process having a dependency.

In one embodiment, the mobile terminal can detect whether the background process having a dependency on the foreground process ends the dependency. For example, the mobile terminal can detect whether the background process ends the communication with the socket and/or the binder of the process running in the foreground, and if the communication ends, it can determine that the dependency is ended. The mobile terminal can also detect whether the background process waiting for the same lock resource as the process running in the foreground completes the task, and if the task is completed, it can judge the end of the dependency, but is not limited thereto. The mobile terminal can restore the background process that ends the dependency to the resource restriction level before the reduction, and re-limit the resource usage of the background process.

In this embodiment, the resource restriction level of the background process having the dependency relationship with the foreground process can be reduced, and the foreground process can be timely responded to prevent the foreground process from entering the wait due to the limitation of the resource usage of the background process, and the power consumption is reduced. At the same time improve the speed of the front desk.

In one embodiment, a resource management method is provided, including the following operations:

The operation (1) is performed to obtain the running feature of the background application, and the application scenario type of the background application is determined according to the running feature, and the application scenario type includes the perceptible application and the non-perceivable application.

Operation (2) determines a resource restriction level of the background application according to the type of the application scenario.

Optionally, the non-aware application includes an unperceptible application that receives the process communication and an unperceivable application that has no process communication. After the operation (2), the method further includes: configuring, by the background application, a resource usage priority corresponding to the resource restriction level, the application The scenario type is that the resource usage priority of the application is higher than that of the non-aware application, and the application scenario type is that the resource usage priority of the non-aware application receiving the process communication is higher than that of the non-process communication.

Operation (3), resource management of the background application according to the resource restriction level.

Optionally, the operation (3) includes: acquiring user group information of the background application; querying a process identifier that has a mapping relationship with the user group information; and adding a background process that matches the process identifier to the resource group corresponding to the resource restriction level. in.

Optionally, after the operation (3), the method further includes: acquiring a foreground process running in the foreground; and reducing a resource restriction level of the background process having the dependency when there is a background process having a dependency relationship with the foreground process.

Optionally, after obtaining the foreground process running in the foreground, the method further includes: determining, when the background process and the foreground process have a synchronization mechanism and/or a communication mechanism, the background process having the synchronization mechanism and/or the communication mechanism as having a dependency relationship Background process.

Optionally, after obtaining the foreground process running in the foreground, the method further includes: determining a waiting lock resource when detecting that the foreground process has a lock waiting behavior; if there is a background process waiting for the lock resource, waiting for the lock resource The background process is determined to be a background process with dependencies.

Optionally, after the resource restriction level of the background process having the dependency is reduced, the method further includes: when the current process ends the dependency relationship with the background process, the background process that restores the end dependency is lowering the previous resource restriction level.

It should be understood that the operations in the above-described flowcharts are sequentially displayed in accordance with the indication of the arrows, but the operations are not necessarily performed in the order indicated by the arrows. Except as explicitly stated herein, the execution of these operations is not strictly limited, and the operations may be performed in other sequences. Moreover, at least a part of the operations in the above flow diagram may include multiple sub-operations or multiple stages, which are not necessarily performed at the same time, but may be executed at different times, and these sub-operations or stages The order of execution is also not necessarily sequential, but may be performed alternately or alternately with at least a portion of the sub-operations or stages of other operations or other operations.

As shown in FIG. 7, in one embodiment, a resource management apparatus 700 is provided, including a scene determination module 710, a level determination module 720, and a management module 730.

The scenario determining module 710 is configured to obtain an running feature of the background application, and determine an application scenario type of the background application according to the running feature, where the application scenario type includes the perceptible application and the non-perceptible application.

The level determining module 720 is configured to determine a resource restriction level of the background application according to the application scenario type.

Optionally, the non-aware application includes an imperceptible application that receives process communication and an imperceptible application that has no process communication. The level determining module 720 is further configured to: configure, by the background application, a resource usage priority corresponding to the resource restriction level, where the application scenario type is a perceptible application, the resource usage priority is higher than the non-sensible application, and the application scenario type is a non-sensible application communication. The perceived resource usage of the application is higher than the non-aware application of the processless communication.

The management module 730 is configured to perform resource management on the background application according to the resource restriction level.

As shown in FIG. 8, in an embodiment, the management module 730 includes an obtaining unit 732, a query unit 734, and an adding unit 736.

The obtaining unit 732 is configured to obtain user group information of the background application.

The query unit 734 is configured to query a process identifier that has a mapping relationship with the user group information.

The adding unit 736 is configured to add a background process that matches the process identifier to the resource group corresponding to the resource restriction level.

As shown in FIG. 9 , in one embodiment, the resource management apparatus 700 includes a process determination module 710 and a reduction module 750 in addition to the scenario determination module 710 , the level determination module 720 , and the management module 730 .

The process obtaining module 740 is configured to obtain a foreground process running in the foreground.

The lowering module 750 is configured to reduce the resource restriction level of the background process having the dependency when there is a background process having a dependency relationship with the foreground process.

In an embodiment, the resource management apparatus 700 further includes a dependency determination module.

The dependency determining module is configured to determine, when the background process and the foreground process have a synchronization mechanism and/or a communication mechanism, a background process having a synchronization mechanism and/or a communication mechanism as a background process having a dependency relationship.

In an embodiment, the dependency determining module is further configured to determine a waiting lock resource when detecting a lock waiting behavior of the foreground process; if there is a background process waiting for the lock resource, the background process in the lock resource is to be waited Determined as a background process with dependencies.

In one embodiment, the lowering module 750 is further configured to restore the previous resource restriction level when the current process ends the dependency relationship with the background process.

The embodiment of the present application further provides a mobile terminal. As shown in FIG. 10, for the convenience of description, only the parts related to the embodiments of the present application are shown. For the specific technical details not disclosed, refer to the method part of the embodiment of the present application. The mobile terminal can be any mobile device, a tablet computer, a personal digital assistant (PDA), a point of sale (POS), a car computer, a wearable device, and the like, and the mobile terminal is used as a mobile phone. :

FIG. 10 is a block diagram showing a partial structure of a mobile phone related to a mobile terminal provided by an embodiment of the present application. Referring to FIG. 10, the mobile phone includes: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (WiFi) module 1070, and a processor 1080. And power supply 1090 and other components. It will be understood by those skilled in the art that the structure of the handset shown in Fig. 10 does not constitute a limitation to the handset, and may include more or less components than those illustrated, or some components may be combined, or different components may be arranged.

The RF circuit 1010 can be used for receiving and transmitting signals during the transmission and reception of information or during a call. The downlink information of the base station can be received and processed by the processor 1080. The uplink data can also be sent to the base station. Generally, RF circuits include, but are not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, RF circuit 1010 can also communicate with the network and other devices via wireless communication. The above wireless communication may use any communication standard or protocol, including but not limited to GSM, GPRS, Code Division Multiple Access (CDMA), W-CDMA, Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.

The memory 1020 can be used to store software programs and modules, and the processor 1080 executes various functional applications and data processing of the mobile phone by running software programs and modules stored in the memory 1020. The memory 1020 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as an application of a sound playing function, an application of an image playing function, etc.); The data storage area can store data (such as audio data, address book, etc.) created according to the use of the mobile phone. Moreover, memory 1020 can include high speed random access memory, and can also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 1030 can be configured to receive input numeric or character information and to generate key signal inputs related to user settings and function control of the handset 1000. Specifically, the input unit 1030 may include a touch panel 1032 and other input devices 1034. The touch panel 1032, which may also be referred to as a touch screen, can collect touch operations on or near the user (such as a user using a finger, a stylus, or the like on the touch panel 1032 or near the touch panel 1032. Operation) and drive the corresponding connection device according to a preset program. In one embodiment, the touch panel 1032 can include two portions of a touch detection device and a touch controller. Wherein, the touch detection device detects the touch orientation of the user, and detects a signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts the touch information into contact coordinates, and sends the touch information. The processor 1080 is provided and can receive commands from the processor 1080 and execute them. In addition, the touch panel 1032 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 1032, the input unit 1030 can also include other input devices 1034. Specifically, other input devices 1034 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.).

The display unit 1040 can be used to display information input by the user or information provided to the user as well as various menus of the mobile phone. The display unit 1040 can include a display panel 1042. In one embodiment, the display panel 1042 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. In one embodiment, the touch panel 1032 can cover the display panel 1042. When the touch panel 1032 detects a touch operation thereon or nearby, the touch panel 1032 transmits to the processor 1080 to determine the type of the touch event, and then the processor 1080 is The type of touch event provides a corresponding visual output on display panel 1042. Although in FIG. 10, the touch panel 1032 and the display panel 1042 are used as two independent components to implement the input and input functions of the mobile phone, in some embodiments, the touch panel 1032 can be integrated with the display panel 1042. Realize the input and output functions of the phone.

The handset 1000 can also include at least one type of sensor 1050, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 1042 according to the brightness of the ambient light, and the proximity sensor may close the display panel 1042 and/or when the mobile phone moves to the ear. Or backlight. The motion sensor may include an acceleration sensor, and the acceleration sensor can detect the magnitude of the acceleration in each direction, and the magnitude and direction of the gravity can be detected at rest, and can be used to identify the gesture of the mobile phone (such as horizontal and vertical screen switching), and vibration recognition related functions (such as Pedometer, tapping, etc.; in addition, the phone can also be equipped with gyroscopes, barometers, hygrometers, thermometers, infrared sensors and other sensors.

Audio circuitry 1060, speaker 1062, and microphone 1064 can provide an audio interface between the user and the handset. The audio circuit 1060 can transmit the converted electrical data of the received audio data to the speaker 1062, and convert it into a sound signal output by the speaker 1062. On the other hand, the microphone 1064 converts the collected sound signal into an electrical signal, and the audio circuit 1060. After receiving, it is converted into audio data, and then processed by the audio data output processor 1080, transmitted to another mobile phone via the RF circuit 1010, or outputted to the memory 1020 for subsequent processing.

WiFi is a short-range wireless transmission technology. The mobile phone through the WiFi module 1070 can help users to send and receive e-mail, browse the web and access streaming media, etc. It provides users with wireless broadband Internet access. Although FIG. 10 shows the WiFi module 1070, it can be understood that it does not belong to the essential configuration of the mobile phone 1000 and can be omitted as needed.

The processor 1080 is the control center of the handset, which connects various portions of the entire handset using various interfaces and lines, by executing or executing software programs and/or modules stored in the memory 1020, and invoking data stored in the memory 1020, The phone's various functions and processing data, so that the overall monitoring of the phone. In one embodiment, processor 1080 can include one or more processing units. In one embodiment, the processor 1080 can integrate an application processor and a modem, wherein the application processor primarily processes an operating system, a user interface, an application, etc.; the modem primarily processes wireless communications. It will be appreciated that the above described modem may also not be integrated into the processor 1080. For example, the processor 1080 can integrate an application processor and a baseband processor, and the baseband processor and other peripheral chips can form a modem. The mobile phone 1000 also includes a power source 1090 (such as a battery) for powering various components. Preferably, the power source can be logically coupled to the processor 1080 through a power management system to manage functions such as charging, discharging, and power management through the power management system.

In one embodiment, the handset 1000 may also include a camera, a Bluetooth module, and the like.

In the embodiment of the present application, the processor 880 included in the mobile terminal implements the foregoing resource management method when executing a computer program stored in a memory.

In one embodiment, the mobile terminal can include a memory 1020 and a processor 1080. The memory 1020 stores a computer program that, when executed by the processor 1080, causes the processor to perform the following operations:

Obtaining a running feature of the background application, and determining an application scenario type of the background application according to the running feature, where the application scenario type includes the perceptible application and the non-perceivable application;

Determining a resource restriction level of the background application according to the type of the application scenario;

Resource management of background applications according to resource restriction levels.

In one embodiment, a computer readable storage medium is provided having stored thereon a computer program that, when executed by a processor, implements the resource management method described above.

In one embodiment, a computer program product comprising a computer program, when executed on a computer device, causes the computer device to perform the resource management method described above when executed.

One of ordinary skill in the art can understand that all or part of the process of implementing the above embodiments can be completed by a computer program to instruct related hardware, and the program can be stored in a non-volatile computer readable storage medium. Wherein, the program, when executed, may include the flow of an embodiment of the methods as described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or the like.

Any reference to a memory, storage, database or other medium as used herein may include non-volatile and/or volatile memory. Suitable non-volatile memories can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM), which acts as an external cache. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronization. Link (Synchlink) DRAM (SLDRAM), Memory Bus (Rambus) Direct RAM (RDRAM), Direct Memory Bus Dynamic RAM (DRDRAM), and Memory Bus Dynamic RAM (RDRAM).

The technical features of the above-described embodiments may be arbitrarily combined. For the sake of brevity of description, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction between the combinations of these technical features, All should be considered as the scope of this manual.

The above-mentioned embodiments are merely illustrative of several embodiments of the present application, and the description thereof is more specific and detailed, but is not to be construed as limiting the scope of the invention. It should be noted that a number of variations and modifications may be made by those skilled in the art without departing from the spirit and scope of the present application. Therefore, the scope of the invention should be determined by the appended claims.

Claims

A resource management method, including:

Obtaining an running feature of the background application, and determining an application scenario type of the background application according to the running feature, where the application scenario type includes a perceptible application and an imperceptible application;

Determining, according to the type of the application scenario, a resource restriction level of the background application; and

Resource management is performed on the background application according to the resource restriction level.
The method according to claim 1, wherein the non-aware application comprises an imperceptible application that receives process communication and an unperceivable application that has no process communication;

After the determining the resource restriction level of the background application according to the application scenario type, the method further includes:

And configuring, by the background application, a resource usage priority corresponding to the resource restriction level, where the application scenario type is a resource usage priority of the perceptible application is higher than the non-sensible application, and the application scenario type is a resource of the non-perceivable application receiving the process communication Use an imperceptible application with a higher priority than no process communication.
The method according to claim 1, wherein the performing resource management on the background application according to the resource restriction level comprises:

Obtaining user group information of the background application;

Querying a process identifier that has a mapping relationship with the user group information; and

A background process matching the process identifier is added to the resource group corresponding to the resource restriction level.
The method of claim 3, wherein the method further comprises:

Get the foreground process running in the foreground;

When there is a background process having a dependency relationship with the foreground process, the resource restriction level of the background process having the dependency is reduced.
The method according to claim 4, wherein after the obtaining the foreground process running in the foreground, the method further comprises:

When the background process and the foreground process have a synchronization mechanism and/or a communication mechanism, the background process having the synchronization mechanism and/or the communication mechanism is determined as a background process having a dependency.
The method of claim 5 wherein said communication mechanism comprises at least one of a socket, a binder, and a shared memory.
The method according to claim 4, wherein after the obtaining the foreground process running in the foreground, the method further comprises:

Determining the waiting lock resource when detecting that the foreground process has a lock waiting behavior;

When there is a background process waiting for the lock resource, the background process waiting for the lock resource is determined as a background process having a dependency.
The method according to any one of claims 4 to 7, wherein after the reducing the resource restriction level of the background process having the dependency, the method further comprises:

When the foreground process ends the dependency relationship with the background process, the background process that restores the end of the dependency is lowering the previous resource restriction level.
A resource management device, comprising:

a scenario determining module, configured to acquire a running feature of the background application, and determine an application scenario type of the background application according to the running feature, where the application scenario type includes a perceptible application and an imperceptible application;

a level determining module, configured to determine a resource restriction level of the background application according to the application scenario type;

And a management module, configured to perform resource management on the background application according to the resource restriction level.
A mobile terminal comprising a memory and a processor, wherein the memory stores a computer program, the computer program being executed by the processor, causing the processor to implement the method of any one of claims 1 to 8. .
A computer readable storage medium having stored thereon a computer program, characterized in that the computer program is executed by a processor to implement the method of any one of claims 1 to 8.