CN111831441A

CN111831441A - Memory recovery method and device, storage medium and electronic equipment

Info

Publication number: CN111831441A
Application number: CN202010628803.7A
Authority: CN
Inventors: 周华材; 张诗明; 郭健
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2020-07-01
Filing date: 2020-07-01
Publication date: 2020-10-27

Abstract

The embodiment of the application discloses a memory recovery method, a memory recovery device, a storage medium and electronic equipment, wherein a target thread for executing a relevant task in a user interaction event is determined, and the target thread is marked as a first type of thread; when a memory allocation request sent by a first type of thread is received, allocating memory pages for the first type of thread from an idle memory space, wherein the memory pages allocated to the first type of thread are used as the first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as second type of memory pages; and when the system is detected to enter the memory recovery flow, recovering the second type of memory pages in the allocated memory space. According to the scheme, the memory pages occupied by the threads executing the related tasks in the user interaction event can be prevented from being frequently recycled, the running efficiency of the threads is improved, the blocking phenomenon in an interaction scene is reduced, and the user experience is improved.

Description

Memory recovery method and device, storage medium and electronic equipment

Technical Field

The present application relates to the field of electronic devices, and in particular, to a method and an apparatus for recycling a memory, a storage medium, and an electronic device.

Background

With the development of technology, various applications installed in electronic devices are increasing, such as video applications, game applications, instant messaging applications, and the like. This makes the electronic device often need to run many applications in the foreground and background, and the karton phenomenon easily appears in the user interaction scene.

Disclosure of Invention

The embodiment of the application provides a memory recovery method and device, a storage medium and an electronic device, which can reduce the stuck phenomenon in an interactive scene.

In a first aspect, an embodiment of the present application provides a memory recycling method, including:

determining a target thread for executing related tasks in a user interaction event, and marking the target thread as a first type thread;

when a memory allocation request sent by the first type of thread is received, allocating memory pages for the first type of thread from an idle memory space, wherein the memory pages allocated to the first type of thread are used as first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as second type of memory pages;

and when the system is detected to enter a memory recovery flow, recovering the second type of memory pages in the allocated memory space.

In a second aspect, an embodiment of the present application further provides a memory recycling device, including:

the thread marking module is used for determining a target thread for executing related tasks in the user interaction event and marking the target thread as a first type thread;

a memory allocation module, configured to allocate memory pages for the first type of threads from an idle memory space when a memory allocation request sent by the first type of threads is received, where the memory pages allocated to the first type of threads are used as first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as second type of memory pages;

and the memory recovery module is configured to, when it is detected that the system enters a memory recovery process, perform recovery processing on the second type of memory pages in the allocated memory space.

In a third aspect, an embodiment of the present application further provides a storage medium, where a computer program is stored, and when the computer program runs on a computer, the computer is caused to execute the memory recovery method provided in any embodiment of the present application.

In a fourth aspect, an embodiment of the present application further provides an electronic device, which includes a processor and a storage, where the storage has a computer program, and the processor is configured to execute the memory recovery method provided in any embodiment of the present application by calling the computer program.

According to the technical scheme provided by the embodiment of the application, the target threads for executing the related tasks in the user interaction event are determined, and the target threads are marked as the first type threads. When the system allocates the memory for the threads, the memory pages allocated to the first type of threads are used as the first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as the second type of memory pages. The method comprises the steps that the operation condition of threads executing related tasks in a user interaction event influences whether the phenomenon of blocking can occur in the user interaction event, if memory pages occupied by the threads are frequently recovered in a memory recovery process, re-reading and writing or decompression operation needs to be carried out, and the operation efficiency of the threads is low.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a first flowchart of a memory recycling method according to an embodiment of the present disclosure.

Fig. 2 is a second flowchart of the memory recycling method according to the embodiment of the present disclosure.

Fig. 3 is a schematic structural diagram of a memory recovery device according to an embodiment of the present application.

Fig. 4 is a first structural schematic diagram of an electronic device according to an embodiment of the present application.

Fig. 5 is a second structural schematic diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It is to be understood that the embodiments described are only a few embodiments of the present application and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without inventive step, are within the scope of the present application.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

An execution main body of the memory recovery method may be the memory recovery device provided in the embodiment of the present application, or an electronic device integrated with the memory recovery device, where the memory recovery device may be implemented in a hardware or software manner. The electronic device may be a smart phone, a tablet computer, a palm computer, a notebook computer, or a desktop computer.

Referring to fig. 1, fig. 1 is a first flowchart illustrating a memory recycling method according to an embodiment of the present disclosure. The specific process of the memory recovery method provided by the embodiment of the application can be as follows:

in 101, a target thread for executing a task related to a user interaction event is determined, and the target thread is marked as a first type thread.

In this embodiment, the operating system of the electronic device may be a linux kernel-based system, such as an android operating system. The electronic device runs a system process and a process of an application program, and a thread is an execution path of the process and is the minimum unit during program execution. A process may have multiple threads but at least one thread.

For the kernel, when performing resource scheduling, for example, CPU scheduling, it is specific to a certain thread. There is a main thread in the process, which also creates many sub-threads to assist in work. Such as a process of a content interaction application, which creates a main thread to execute code and creates other sub-threads to assist in running task code for various parts during execution.

In the embodiment of the application, from the perspective of whether the running condition of the thread can affect the user experience, the threads which directly or indirectly affect the user experience are marked.

Whether the threads executing the related tasks in the user interaction event can run smoothly or not is determined, and whether the user-perceivable incrustation can be generated in the user interaction event or not is determined. In the embodiment of the present application, the threads other than the ux thread are denoted as the second type of threads. The running condition of the second type of thread generally does not influence the user experience or has little influence on the user experience.

The system architecture of the electronic device at least comprises an application framework (frame) layer and a kernel (kernel) layer, and in the embodiment of the application, the ux threads are identified and marked from the perspective of the application framework layer and the kernel layer, for example, the application framework layer adds a first preset label to some threads which directly execute related tasks in a user interaction event so as to mark the threads as static ux threads, and the kernel layer marks some threads which indirectly influence the execution of related tasks in the user interaction event as dynamic ux threads.

The processes in the embodiments of the present application include system level processes and application level processes. The scene of the stuck generating user-perceptible interface is mostly relative to the process running in the foreground. Therefore, in the solution of the embodiment of the present application, "determining a thread that executes a relevant task in a user interaction event" includes: when detecting that a process is switched to foreground operation, determining a foreground process; and determining a thread for executing a related task in the user interaction event from the threads of the foreground process as a target thread.

For example, in one embodiment, "determining a target thread for executing a task related to a user interaction event from threads of a foreground process, and marking the target thread as a first type thread" includes: identifying a first preset thread used for executing related tasks in the user interaction event from threads of a foreground process as a target thread; and adding a first preset label to the target thread so as to mark the thread as a first type of thread.

For example, the first preset thread includes some threads created by the process runtime for directly performing related tasks of the user interaction event, such as a UI (user interface) thread, a Render thread, a GL thread, a distribution thread of the user input event, a detection thread of the user input event, and the like. Whether these threads can run smoothly determines whether user perceivable jams will be generated in the user's interface with the process.

For example, a user chats with a friend using the chat software, the user inputs text in a dialog box, and the electronic device sends the text input by the user to the electronic device of the friend through the server. In the interaction event, the UI thread, the Render thread, the distribution thread of the user input event, the detection thread of the user input event and other threads need to work together to complete the user interaction event, wherein the running of each thread needs the system to allocate resources for the thread. Thus, upon detecting that the chat software is running in the foreground, these threads are identified and marked as ux threads.

The first preset thread is generally an application level thread, and the threads can be determined by analyzing an actual katoon scene. For example, in a test, if an application is stuck in a certain user interaction scenario, and the scenario is analyzed to find that the stuck phenomenon is caused by that a certain thread processes a task too slowly, the thread may be considered to be used for executing a related task in a user interaction event, the running of the thread is closely related to the user experience, and the thread may be taken as a first preset thread.

Based on this, the threads causing the katton can be recorded by testing various possible katton scenarios. The electronic equipment stores the related information of the first preset threads, and when the process is switched to foreground operation, the threads belonging to the first preset threads recorded in advance under the process are marked as ux threads.

It is understood that, for the electronic device, the stored information about the first preset thread is not non-modifiable, and the information about the first preset thread may be updated when a system upgrade is performed.

Further, in another embodiment, the method further comprises: when the second preset thread is detected to be created, the created second preset thread is marked as a first type thread, wherein the second preset thread is a system level thread.

Since some system level threads may be involved in performing tasks in addition to application level threads in performing user interaction events, the system framework layer also needs to mark these system level threads as ux threads. These threads are typically created at system startup and, therefore, may be identified and marked when system startup is detected, e.g., a surfaflinger thread, a system animation thread, etc. Alternatively, during system operation, if it is detected that threads of a new system process are created and used to perform related tasks in a user interaction event, the system framework layer also marks these threads as ux threads. Such as a systemuui thread. The second preset thread can also be determined by analyzing the actual stuck scene. For example, in a test, if an application stuck occurs in a certain user interaction scenario, and the scenario is analyzed to find that the stuck phenomenon is caused by that a certain system level thread processes a task too slowly, the system level thread may be considered to be used for executing a related task in a user interaction event, the running of the system level thread is closely related to the user experience, and the system level thread may be used as a second preset thread. The electronic device stores the relevant information of the second preset threads, and if the threads are detected to be created by the system, the threads are marked as ux threads.

The first preset tag can be a ux tag, and the adding mode is as follows: linux uses a task _ struct structure to describe and record threads, and each thread has a corresponding task _ struct structure. the task _ struct records attribute information such as the name, identifier, status, priority, memory pointer, and context data of the thread. Therefore, the application framework layer may add a corresponding ux flag member to the task _ struct structure, so as to execute the UI thread, Render thread, GL thread, etc. of the foreground process to the thread of the relevant task in the user interaction event, and enable the kernel layer to identify the task attribute of the thread by marking the ux flag bit.

It should be noted that the above several static ux threads are only for illustration and not limited thereto, and as long as the threads directly execute the related tasks in the user interaction event, so that the running conditions of the threads directly affect the user experience, the threads may be labeled as static ux threads. For the application framework layer, when it is detected that a newly created thread is used to perform a user interaction event, or that some resident system level thread is used to handle a user interaction event, ux tags are added to these threads to mark them as static ux threads.

In another embodiment, the "determining a target thread for executing a task related to a user interaction event from threads of a foreground process, and marking the target thread as a first type thread" further comprises: in the running process of a foreground process, when the creation of a new thread is detected, determining whether the newly created thread is used for executing related tasks in a user interaction event; when the newly created thread is used to perform the relevant task in the user interaction event, the newly created thread is marked as a first type of thread.

In the running process of the foreground process, if a user interaction event occurs, besides the first preset thread of the application level and the second preset thread of the system level, some temporarily created task threads may also be provided, and the running of the task threads also directly influences whether user-perceivable incarceration can be generated in an interaction interface between a user and the process. Thus, the application framework layer will label these threads as ux threads as well.

Wherein the electronic device determines an occurring user interaction event according to the detected user instruction. The user interaction event generally refers to a situation that after a user triggers a certain instruction, the electronic device needs to respond to the instruction immediately, perform certain processing, and display a processing result on an interface. For example, a user watching a video using an electronic device, editing a short message, using chat software, using game software, controlling the switching of an interface of the electronic device, browsing a web page, and the like belong to the user interaction events. For example, a user chats with a friend using the chat software, the user inputs text in a dialog box, and the electronic device sends the text input by the user to the electronic device of the friend through the server. In this process, the electronic device needs to schedule multiple threads to complete the user interaction event, and all the threads created by the process to complete the user interaction event may be considered as threads related to user experience in the whole process from the start to the completion of the user interaction event.

In another embodiment, after adding the first preset tag to the target thread, the method further comprises: and if the foreground process is the application process, deleting the first preset label of the first preset thread when the foreground process is detected to be switched to the background operation. When the foreground process is switched to the background process, the running condition of the process is irrelevant to the user experience, and the importance degree of the thread is reduced, so that the ux mark of the first preset thread corresponding to the process can be deleted, and the ux threads are recovered to be common threads.

In addition, for task threads temporarily created in a user interaction event, the task threads are destroyed after the corresponding task is executed, and the ux tags are naturally lost. For the second preset thread at the system level, even if the foreground and background switching of the process occurs, the threads are always related to the user experience, so the ux label is always kept.

With the above embodiments, the framework layer identifies and tags threads that directly impact the user experience. The running of a thread requires the kernel to allocate system resources for it. Thus, a thread may request resources from a kernel before executing a task. When the kernel allocates resources for the thread based on the request, the kernel may first determine whether the thread is a ux thread, and different resource allocation manners are adopted for the ux thread and the non-ux thread.

It should be noted that the "first class" and "second class" in the first class of threads and the second class of threads are only used to distinguish whether the threads have ux tags, and not to divide the threads in the system into the two classes. The resource allocation optimization scheme is based on the angle that whether a thread has a ux label, and if the thread also has other attributes, the other attributes are still considered after the attribute of whether the thread has the ux label is considered during resource allocation.

The above embodiments describe the identification of static ux threads. Although some threads do not directly execute the tasks related to the user interaction events, the running conditions of the threads also affect the running conditions of the static ux threads, and thus indirectly affect the execution of the tasks related to the user interaction events. That is, these threads are not always relevant to the user experience, but may be associated with static ux threads by resource constraints during a certain period of execution of the process, and therefore, in some embodiments, to further reduce the stuck-at phenomenon in the interaction scenario, the kernel layer marks these threads having constraint relationships with the static ux threads as well. And once this constraint relationship ends, the thread is restored to a non-ux thread. In the embodiment of the application, such threads are defined as dynamic ux threads. The specific constraint relationship includes, but is not limited to, interprocess communication, inter-thread communication, or holding a critical resource. For example, a static ux thread is a common thread requested by inter-process communication, a static ux thread is a common thread requested by some inter-thread communication, and a common thread holding critical resources such as a wait semaphore, a read-write semaphore, and a mutex lock required by the static ux thread is marked as a dynamic ux thread in the embodiment of the present application.

Based on this, in some embodiments, the method further comprises: detecting the running state of the first type of thread; when detecting that the first type of thread enters a blocking state, determining an associated thread having a constraint relation with the first type of thread entering the blocking state; and adding a first preset label to the associated thread so as to mark the associated thread as a first type thread.

In some embodiments, after marking the associated thread as a first type of thread, the method further comprises: and when the constraint relation is detected to be released, deleting the first preset label of the associated thread.

Regarding the blocking state of a thread, the kernel layer is generally divided into a D state (uninterruptableleep state, uninterruptible sleep state) and an S state (interruptible sleep state), for example, if the thread initiates an IO request but cannot be satisfied, the thread enters the D state; the thread initiates a sync Binder request and enters the S state. The thread enters these states generally because these are all thread tasks that require active or passive relinquishing of CPU resources for some reason or logic during execution.

In this embodiment, the kernel layer detects the state of the static ux thread, and when it is detected that the ux thread enters the blocked state, determines an associated thread having a constraint relationship with the ux thread entering the blocked state, and if the associated thread is not allocated with resources in time, such as IO resources, and operation is blocked, the ux thread is in the blocked state for a long time due to slow operation of the associated thread, so that, in order to avoid that the ux thread is in the blocked state for a long time, the kernel layer marks the identified associated thread as the ux thread, so as to improve IO processing efficiency of the ux thread, ensure that the ux thread is executed in time, and further quickly release the blocked state of the ux thread.

The manner in which the application framework layer and the kernel layer identify and mark the ux thread is described above. Those threads that affect the user experience are identified and marked as ux threads by any one or more of the above embodiments.

At 102, when a memory allocation request sent by a first type of thread is received, memory pages are allocated to the first type of thread from an idle memory space, where the memory pages allocated to the first type of thread are used as the first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as second type of memory pages.

With the above embodiments, the framework layer and the kernel layer identify and tag threads that apply directly to the user experience. And a thread requires a kernel to allocate system resources for it to run. Thus, a thread may send a system resource allocation request to a kernel before executing a task. When the kernel receives the resource allocation request, it may first determine whether the thread is a ux thread, where it may determine whether the thread is a first type of thread according to a tag carried by the thread. For example, if the thread carries a ux tag, the thread is determined to be a ux thread, and if the thread does not have a ux tag, the thread is determined to be a normal thread.

If the thread is a UX thread, after the memory PAGEs are matched for the thread, adding a second preset tag, for example, UX _ PAGE, to the memory PAGEs including the anonymous PAGE and the file PAGE, which are requested by the thread, so as to mark the memory PAGEs as the first type memory PAGEs. And taking the allocated memory pages in the allocated memory space except the first type of memory pages as second type of memory pages. The second type of memory page does not need to be added with any tag, and the kernel can determine whether the allocated memory page belongs to the first type of memory page or the second type of memory page according to whether the allocated memory page has the second preset tag.

In 103, when it is detected that the system enters the memory recovery process, the second type of memory pages in the allocated memory space are recovered.

When the kernel receives the memory allocation request, the current free memory amount is determined. When the amount of the idle memory is insufficient, the memory is recycled first. The kernel uses three memory waterlines to mark the state of the idle memory amount of the system, and the states are respectively as follows in sequence from small to large: high waterline, low waterline and min waterline. When the amount of the idle memory of the system is lower than a low water line, the system wakes up a memory recovery process kswapd to perform memory recovery until the amount of the idle memory is not lower than a high water line. When the memory reclamation process kswapd reclaims the memory, the memory consumption speed is relatively slow, but the memory allocation also enters a slow allocation path (slowpath), which means that the memory allocation efficiency is also slow. It should be noted that the slow allocation path is an abstract concept, and means that the system needs to perform memory recovery in the background, so that the memory allocation efficiency of the thread is reduced.

The kernel mainly realizes memory recovery by recovering anonymous pages and file pages. The strategy for recovering the anonymous page is different from that of the file page, the anonymous page is generally stored in an RAM after being compressed, and because the process needs to use a CPU to compress the anonymous page and then decompress the anonymous page when in use, certain CPU time is consumed in the recovery process, and the recovery process is relatively slow. The recovery file pages are divided into two types, and if the file contents are not modified, the file page contents are directly discarded; if the file content is modified, the content needs to be written back to disk and the file pages discarded, and read from disk again if necessary.

For the ux thread, if the memory page occupied by the ux thread is likely to be used again soon after being recycled, if such a situation occurs frequently, the operating efficiency of the ux thread may be affected due to the fact that the memory page is recycled and needs to be decompressed again (anonymous page) or IO (file page) occurs again, so that the user interaction event processing efficiency is low and a stuck phenomenon occurs.

In order to improve such a drawback, in the embodiment of the present application, the threads related to the user experience are marked, and during memory recovery, the memory pages occupied by the threads other than the ux thread are preferentially recovered, while the memory pages occupied by the ux thread are kept as much as possible, so that the memory pages occupied by the ux thread are prevented from being frequently recovered.

In particular implementation, the present application is not limited by the execution sequence of the described steps, and some steps may be performed in other sequences or simultaneously without conflict.

As can be seen from the above, the memory recovery method provided in the embodiment of the present application determines target threads for executing related tasks in a user interaction event, and marks the target threads as first-class threads. When the system allocates the memory for the threads, the memory pages allocated to the first type of threads are used as the first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as the second type of memory pages. The method comprises the steps that the operation condition of threads executing related tasks in a user interaction event influences whether the phenomenon of blocking can occur in the user interaction event, if memory pages occupied by the threads are frequently recovered in a memory recovery process, re-reading and writing or decompression operation needs to be carried out, and the operation efficiency of the threads is low.

In an embodiment, when it is detected that the system enters a memory recovery process, performing recovery processing on a second type of memory pages in the allocated memory space includes: when the system is detected to enter a memory recovery process, acquiring a second memory page linked list corresponding to a second type of memory pages, wherein the second memory page linked list is a least recently used linked list; and recovering anonymous pages and file pages occupied by the second type of threads according to a second memory page linked list, wherein other threads except the first type of threads are marked as the second type of threads.

In this embodiment, when memory pages occupied by non-ux threads are recovered, the occupied anonymous pages and file pages may be recovered according to a preset ratio of the anonymous pages to the file pages. The anonymous page and the file page which are occupied respectively have LRU (Least Recently Used) linked lists corresponding to the anonymous page and the file page. During recovery, the memory pages which are used least recently are recovered preferentially according to the LRU linked list.

Or, in some other embodiments, the anonymous page may be recycled first, and when the anonymous page does not meet the recycling requirement, the file page may be recycled. For example, the recovering of the anonymous page and the file page occupied by the second type of thread according to the second memory page linked list includes: recovering the anonymous pages occupied by the second type of threads according to the second anonymous page linked list until the amount of the idle memory is not less than a first preset threshold value; and if the idle memory amount is less than the first preset threshold after the anonymous page occupied by the second type thread is recovered, recovering the file page occupied by the second type thread according to the second file page linked list until the idle memory amount is not less than the first preset threshold.

The method according to the preceding embodiment is illustrated in further detail below by way of example.

Referring to fig. 2, fig. 2 is a second flow chart illustrating a memory reclamation method according to an embodiment of the invention.

The method comprises the following steps:

in 201, a target thread for executing a task related to a user interaction event is determined, and the target thread is marked as a first type thread.

At 202, when a memory allocation request sent by a first type of thread is received, memory pages are allocated for the first type of thread from the free memory space.

At 203, the memory pages allocated to the first type of thread are regarded as first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are regarded as second type of memory pages.

For the way of identifying and marking the ux thread from the system thread and the way of distinguishing the first type of memory page from the second type of memory page, please refer to the above embodiments, which are not described herein again.

In 204, when it is detected that the system enters a memory recovery process, the anonymous pages occupied by the second type of threads are recovered according to the second anonymous page linked list until the amount of the idle memory is not less than the first preset threshold.

In 205, the file pages occupied by the second type of thread are recycled according to the second file page linked list until the amount of the idle memory is not less than the first preset threshold.

And executing 206 if the free memory amount is less than the second preset threshold after the file page occupied by the second type of thread is recovered.

In 206, a first anonymous page linked list corresponding to the first type of memory page is obtained, and the anonymous page occupied by the first type of thread is recovered according to the first anonymous page linked list until the amount of the idle memory is not less than a second preset threshold.

And if the amount of the idle memory is less than the second preset threshold after the anonymous page occupied by the first type thread is recovered, executing 207.

In 207, the file pages occupied by the first type of threads are recycled according to the first file page linked list until the amount of the idle memory is not less than a second preset threshold.

Besides the originally set low water line and high water line, the kernel additionally sets a ux _ high water line aiming at the ux thread, wherein the high water line is a first preset threshold, the ux _ high water line is a second preset threshold, and the ux _ high water line is larger than the low water line but smaller than the high water line.

When the kernel receives the memory allocation request, the current free memory amount is determined. When the amount of the idle memory is insufficient, the memory is recycled first. And after the kernel enters a memory recovery flow, firstly recovering the anonymous page occupied by the non-ux thread, and if the anonymous page occupied by the non-ux thread is recovered, stopping the memory recovery process if the idle memory amount is not less than a first preset threshold value. Otherwise, if the idle memory amount is smaller than the first preset threshold after the anonymous page occupied by the second type of thread is recovered, recovering the file page occupied by the non-ux thread, and if the idle memory amount is not smaller than the first preset threshold through recovering the file page occupied by the non-ux thread, stopping the memory recovery process. On the contrary, if the file page occupied by the second type of thread is recycled, the amount of the idle memory does not reach the ux _ high waterline, and the memory occupied by the ux thread is recycled until the amount of the idle memory is not less than the ux _ high waterline. For the memory pages occupied by the ux threads, the anonymous pages can be recovered first, and then the file pages can be recovered, or both the anonymous pages and the file pages can be recovered according to a preset ratio between the anonymous pages and the file.

In one embodiment, the difference between the ux _ high and high water lines is less than the difference between the ux _ high and low water lines. More memory pages occupied by non-ux threads are recycled when the memory is recycled, and the memory pages occupied by the ux threads are recycled as less as possible.

When detecting that the free memory amount is not less than the second preset threshold and less than the first preset threshold, 208 is executed.

At 208, it is detected whether any memory pages occupied by the second type of thread are recoverable.

In 209, when it is detected that the memory page occupied by the second type of thread is recoverable, the memory page occupied by the second type of thread is recovered until the amount of the idle memory is not less than the first preset threshold.

In the memory recovery process, once the amount of the idle memory is recovered to be not less than the second preset threshold but less than the first preset threshold, the memory page occupied by the ux thread is not recovered any more, but whether the memory page occupied by the second type of thread is recoverable or not is detected, and when the memory page occupied by the second type of thread is detected to be recoverable, the memory page occupied by the second type of thread is recovered until the amount of the idle memory is not less than the first preset threshold.

As can be seen from the above, the memory recovery method provided in the embodiment of the present invention marks the threads related to the user experience, and preferentially recovers the memory pages occupied by the threads other than the ux thread during the memory recovery, while reserving the memory pages occupied by the ux thread as much as possible, so as to avoid that the memory pages occupied by the ux thread are frequently recovered. Therefore, the problem that the running efficiency of the thread is low due to the fact that re-reading and writing or decompression operation is needed is solved, the running efficiency of the thread related to user experience is improved, the pause phenomenon in an interactive scene is reduced, and the user experience is improved.

In one embodiment, a memory recycling device is also provided. Referring to fig. 3, fig. 3 is a schematic structural diagram of a memory recycling device 300 according to an embodiment of the present disclosure. The memory recycling device 300 is applied to an electronic device, and the memory recycling device 300 includes a thread marking module 301, a memory allocating module 302, and a memory recycling module 303, as follows:

a thread marking module 301, configured to determine a target thread for executing a relevant task in a user interaction event, and mark the target thread as a first type of thread;

a memory allocation module 302, configured to allocate memory pages for the first type of thread from an idle memory space when a memory allocation request sent by the first type of thread is received, where the memory pages allocated to the first type of thread are used as first type of memory pages, and allocated memory pages in the allocated memory space except for the first type of memory pages are used as second type of memory pages;

the memory recovery module 303 is configured to, when it is detected that the system enters a memory recovery process, perform recovery processing on the second type of memory pages in the allocated memory space.

In some embodiments, the memory reclamation module 303 is further configured to: when the system is detected to enter a memory recovery process, acquiring a second memory page linked list corresponding to a second type of memory pages, wherein the second memory page linked list is a least recently used linked list;

and recovering anonymous pages and file pages occupied by the second type of threads according to the second memory page linked list, wherein other threads except the first type of threads are marked as the second type of threads.

In some embodiments, the memory reclamation module 303 is further configured to: recovering the anonymous pages occupied by the second type of threads according to a second anonymous page linked list until the amount of idle memory is not less than the first preset threshold;

and if the idle memory amount is smaller than the first preset threshold after the anonymous page occupied by the second type thread is recovered, recovering the file page occupied by the second type thread according to the second file page linked list until the idle memory amount is not smaller than the first preset threshold.

In some embodiments, the memory reclamation module 303 is further configured to: if the idle memory amount is smaller than the second preset threshold after the file pages occupied by the second type of thread are recovered, acquiring a first memory page linked list corresponding to the first type of memory pages, wherein the first memory page linked list is a least recently used linked list, and the second preset threshold is smaller than the first preset threshold;

and recovering the anonymous pages and/or the file pages occupied by the first type of threads according to the first memory page linked list until the idle memory amount is not less than the second preset threshold.

In some embodiments, the memory reclamation module 303 is further configured to: recovering the anonymous pages occupied by the first type of threads according to the first anonymous page linked list until the amount of the idle memory is not less than the second preset threshold;

and if the idle memory amount is smaller than the second preset threshold after the anonymous page occupied by the first type thread is recovered, recovering the file page occupied by the first type thread according to the first file page linked list until the idle memory amount is not smaller than the second preset threshold.

In some embodiments, the memory reclamation module 303 is further configured to: when detecting that the amount of the idle memory is not smaller than the second preset threshold and smaller than the first preset threshold, detecting whether memory pages occupied by the second type of threads can be recycled;

when detecting that the memory page occupied by the second type of thread can be recycled, recycling the memory page occupied by the second type of thread until the amount of the idle memory is not less than the first preset threshold value.

In some embodiments, the thread marking module 301 is further configured to: when detecting that a process is switched to foreground operation, determining a foreground process;

and determining a target thread for executing related tasks in the user interaction event from the threads of the foreground process, and marking the target thread as a first type thread.

In some embodiments, the thread marking module 301 is further configured to: in the running process of the foreground process, when the creation of a new thread is detected, determining whether the newly created thread is used for executing related tasks in the user interaction event;

when the newly created thread is used to perform the relevant task in the user interaction event, the newly created thread is marked as a first type of thread.

In some embodiments, the thread marking module 301 is further configured to: when the first type of threads are detected to enter a blocking state, determining associated threads having a constraint relation with the first type of threads entering the blocking state;

and adding the first preset label to the associated thread so as to mark the associated thread as a first type thread.

It should be noted that the memory recovery device provided in the embodiment of the present application and the memory recovery method in the foregoing embodiment belong to the same concept, and any method provided in the embodiment of the memory recovery method can be implemented by the memory recovery device, and a specific implementation process of the method is described in detail in the embodiment of the memory recovery method, and is not described herein again.

As can be seen from the above, the memory recycling device provided in the embodiment of the present application determines target threads for executing related tasks in a user interaction event, and marks the target threads as first-class threads. When the system allocates the memory for the threads, the memory pages allocated to the first type of threads are used as the first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as the second type of memory pages. The method comprises the steps that the operation condition of threads executing related tasks in a user interaction event influences whether the phenomenon of blocking can occur in the user interaction event, if memory pages occupied by the threads are frequently recovered in a memory recovery process, re-reading and writing or decompression operation needs to be carried out, and the operation efficiency of the threads is low.

The embodiment of the application also provides the electronic equipment. The electronic device can be a smart phone, a tablet computer and the like. Referring to fig. 4, fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. The electronic device 400 comprises a processor 401 and a memory 402. The processor 401 is electrically connected to the memory 402.

The processor 401 is a control center of the electronic device 400, connects various parts of the entire electronic device using various interfaces and lines, and performs various functions of the electronic device and processes data by running or calling a computer program stored in the memory 402 and calling data stored in the memory 402, thereby performing overall monitoring of the electronic device.

Memory 402 may be used to store computer programs and data. The memory 402 stores computer programs containing instructions executable in the processor. The computer program may constitute various functional modules. The processor 401 executes various functional applications and data processing by calling a computer program stored in the memory 402.

In this embodiment, the processor 401 in the electronic device 400 loads instructions corresponding to one or more processes of the computer program into the memory 402 according to the following steps, and the processor 401 runs the computer program stored in the memory 402, so as to implement various functions:

In some embodiments, please refer to fig. 5, and fig. 5 is a second structural diagram of an electronic device according to an embodiment of the present disclosure. The electronic device 400 further comprises: radio frequency circuit 403, display 404, control circuit 405, input unit 406, audio circuit 407, sensor 408, and power supply 409. The processor 401 is electrically connected to the radio frequency circuit 403, the display 404, the control circuit 405, the input unit 406, the audio circuit 407, the sensor 408, and the power source 409.

The radio frequency circuit 403 is used for transceiving radio frequency signals to communicate with a network device or other electronic devices through wireless communication.

The display screen 404 may be used to display information entered by or provided to the user as well as various graphical user interfaces of the electronic device, which may be comprised of images, text, icons, video, and any combination thereof.

The control circuit 405 is electrically connected to the display screen 404, and is configured to control the display screen 404 to display information.

The input unit 406 may be used to receive input numbers, character information, or user characteristic information (e.g., fingerprint), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control. The input unit 406 may include a fingerprint recognition module.

The audio circuit 407 may provide an audio interface between the user and the electronic device through a speaker, microphone. Wherein the audio circuit 407 comprises a microphone. The microphone is electrically connected to the processor 401. The microphone is used for receiving voice information input by a user.

The sensor 408 is used to collect external environmental information. The sensors 408 may include one or more of ambient light sensors, acceleration sensors, gyroscopes, etc.

The power supply 409 is used to power the various components of the electronic device 400. In some embodiments, the power source 409 may be logically connected to the processor 401 through a power management system, so that functions of managing charging, discharging, and power consumption are implemented through the power management system.

Although not shown in the drawings, the electronic device 400 may further include a camera, a bluetooth module, and the like, which are not described in detail herein.

In view of the above, embodiments of the present application provide an electronic device, which determines target threads for executing related tasks in a user interaction event, and marks the target threads as first-class threads. When the system allocates the memory for the threads, the memory pages allocated to the first type of threads are used as the first type of memory pages, and the allocated memory pages in the allocated memory space except the first type of memory pages are used as the second type of memory pages. The method comprises the steps that the operation condition of threads executing related tasks in a user interaction event influences whether the phenomenon of blocking can occur in the user interaction event, if memory pages occupied by the threads are frequently recovered in a memory recovery process, re-reading and writing or decompression operation needs to be carried out, and the operation efficiency of the threads is low.

An embodiment of the present application further provides a storage medium, where a computer program is stored in the storage medium, and when the computer program runs on a computer, the computer executes the memory recovery method according to any of the above embodiments.

It should be noted that, all or part of the steps in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, which may include, but is not limited to: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.

Furthermore, the terms "first", "second", and "third", etc. in this application are used to distinguish different objects, and are not used to describe a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or modules is not limited to only those steps or modules listed, but rather, some embodiments may include other steps or modules not listed or inherent to such process, method, article, or apparatus.

The memory recovery method, the memory recovery device, the storage medium, and the electronic device provided in the embodiments of the present application are described in detail above. The principle and the implementation of the present application are explained herein by applying specific examples, and the above description of the embodiments is only used to help understand the method and the core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A memory reclamation method, comprising:

2. The method according to claim 1, wherein the performing a recycle process on the second type of memory pages in the allocated memory space when the system is detected to enter a memory recycle process includes:

when the system is detected to enter a memory recovery process, acquiring a second memory page linked list corresponding to a second type of memory pages, wherein the second memory page linked list is a least recently used linked list;

3. The memory recovery method according to claim 2, wherein the second memory page linked list includes a second anonymous page linked list and a second file page linked list; the recovering, according to the second memory page linked list, the anonymous page and the file page occupied by the second type of thread includes:

recovering the anonymous pages occupied by the second type of threads according to a second anonymous page linked list until the amount of idle memory is not less than the first preset threshold;

4. The method for memory reclamation as recited in claim 3, wherein after the reclaiming the file pages occupied by the second type of thread according to the second file page linked list, the method further comprises:

if the idle memory amount is smaller than the second preset threshold after the file pages occupied by the second type of thread are recovered, acquiring a first memory page linked list corresponding to the first type of memory pages, wherein the first memory page linked list is a least recently used linked list, and the second preset threshold is smaller than the first preset threshold;

5. The memory recovery method according to claim 4, wherein the first memory page linked list includes a first anonymous page linked list and a first file page linked list; the recovering, according to the first memory page linked list, the anonymous page and/or the file page occupied by the first type of thread until the idle memory amount is not less than the second preset threshold includes:

recovering the anonymous pages occupied by the first type of threads according to the first anonymous page linked list until the amount of the idle memory is not less than the second preset threshold;

6. The method for memory recovery according to claim 5, wherein the recovering, according to the first memory page linked list, the anonymous page and/or the file page occupied by the first type of thread until the amount of the free memory is not less than the second preset threshold further includes:

when detecting that the amount of the idle memory is not smaller than the second preset threshold and smaller than the first preset threshold, detecting whether memory pages occupied by the second type of threads can be recycled;

7. The method for memory reclamation as recited in claim 1, wherein the determining a target thread for executing a task associated with a user interaction event and marking the target thread as a first type of thread comprises:

when detecting that a process is switched to foreground operation, determining a foreground process;

8. The memory reclamation method as recited in claim 7, wherein the method further comprises:

in the running process of the foreground process, when the creation of a new thread is detected, determining whether the newly created thread is used for executing related tasks in the user interaction event;

9. The method for memory reclamation as recited in claim 8, wherein after marking the target thread as a first type of thread, further comprising:

when the first type of threads are detected to enter a blocking state, determining associated threads having a constraint relation with the first type of threads entering the blocking state;

10. A memory recycling device, comprising:

11. A storage medium having stored thereon a computer program, characterized in that, when the computer program is run on a computer, it causes the computer to execute the memory reclamation method as recited in any one of claims 1 to 9.

12. An electronic device comprising a processor and a memory, the memory storing a computer program, wherein the processor is configured to execute the memory reclamation method according to any one of claims 1 to 9 by calling the computer program.