Video memory processing method and device, electronic equipment and storage medium

By monitoring application state transitions and reusing buffers in the video memory pool, the problem of decreased smoothness caused by long video memory resource allocation times was solved, resulting in faster response times and fewer dropped frames, thus improving the user experience of application switching.

CN121685248APending Publication Date: 2026-03-17BEIJING XIAOMI MOBILE SOFTWARE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-14
Publication Date
2026-03-17

AI Technical Summary

Technical Problem

When switching applications, the existing technology takes a long time to allocate video memory resources, which leads to a decrease in smoothness and causes problems such as stuttering and frame drops.

Method used

By monitoring when an application switches from a background running state to a foreground running state, the available buffers in the video memory pool associated with the application are reused, reducing direct allocation requests to the underlying video memory and utilizing the buffers in the video memory pool for reuse.

Benefits of technology

It effectively reduces the response time of application warm starts, reduces the number of dropped frames when switching applications, and improves the smoothness of use.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121685248A_ABST
    Figure CN121685248A_ABST
Patent Text Reader

Abstract

The invention relates to a video memory processing method and device, electronic equipment and a storage medium. The method comprises the steps that it is monitored that an application program is switched from a background running state to a foreground running state, and if an available buffer area exists in a video memory pool associated with the application program, the available buffer area is reused. Wherein the video memory pool is used for storing an application process buffer region meeting the video memory pool adding condition, and the application process buffer region is a buffer region to be released when the application program enters a background running state. By implementing the embodiment of the invention, the response time of hot start of the application program can be effectively shortened, the number of lost frames during switching of the application program can be reduced, and the experience fluency is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for processing video memory. Background Technology

[0002] In related technologies, when switching applications, the application process typically creates a frame buffer, which often pre-allocates multiple buffer blocks for subsequent graphics rendering. However, this video memory allocation process incurs performance overhead on the central processing unit (CPU) and memory, involving cross-process communication and switching from user mode to kernel mode to allocate video memory resources. This process is time-consuming and can lead to a decrease in smoothness (such as stuttering and frame drops). Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for processing video memory.

[0004] According to a first aspect of the present disclosure, a video memory processing method is provided, comprising:

[0005] The application was detected to switch from running in the background to running in the foreground.

[0006] Determine that there is an available buffer in the video memory pool associated with the application, and reuse the available buffer;

[0007] The video memory pool is used to store application process buffers that meet the conditions for joining the video memory pool. The application process buffer is the buffer that the application wants to release when it enters the background running state.

[0008] According to a second aspect of the present disclosure, a video memory processing apparatus is provided, comprising:

[0009] The monitoring module is used to detect when an application switches from a background running state to a foreground running state;

[0010] The first determining module is used to determine that there is an available buffer in the video memory pool associated with the application.

[0011] A reuse module is used to reuse the available buffer;

[0012] The video memory pool is used to store application process buffers that meet the conditions for joining the video memory pool. The application process buffer is the buffer that the application wants to release when it enters the background running state.

[0013] According to a third aspect of the present disclosure, an electronic device is provided, comprising:

[0014] One or more processors;

[0015] The electronic device is used to perform the video memory processing method described in the first aspect above.

[0016] According to a fourth aspect of the present disclosure, a storage medium is provided that stores instructions that, when executed on an electronic device, cause the electronic device to perform the video memory processing method described in the first aspect.

[0017] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by an electronic device, implements the steps of the method described in the first aspect.

[0018] According to the technical solution disclosed herein, when switching applications, there is no need to request video memory allocation from the underlying layer. Instead, an available buffer can be found from the video memory pool associated with the application and reused. This can effectively reduce the response time of application warm-start and reduce the number of dropped frames when switching applications, thereby improving the smoothness of the experience.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0021] Figure 1 This is a flowchart illustrating a video memory processing method according to an exemplary embodiment.

[0022] Figure 2 This is a flowchart illustrating a video memory processing method according to an exemplary embodiment.

[0023] Figure 3A This is an example of a video memory processing method illustrated according to an exemplary embodiment. Figure 1 .

[0024] Figure 3B This is an example of a video memory processing method illustrated according to an exemplary embodiment. Figure 2 .

[0025] Figure 4 This is an example diagram illustrating pooling operations on a video memory pool based on a capacity dynamic control mechanism, according to an exemplary embodiment.

[0026] Figure 5This is an example diagram illustrating a pooling operation of the video memory pool based on a specific game optimization mechanism, according to an exemplary embodiment.

[0027] Figure 6 This is an example diagram illustrating a pooling operation of the video memory pool based on a timeout release mechanism, according to an exemplary embodiment.

[0028] Figure 7 This is a block diagram of a video memory processing device according to an exemplary embodiment.

[0029] Figure 8 This is a block diagram of a video memory processing device according to an exemplary embodiment.

[0030] Figure 9 This is a block diagram of a video memory processing device according to an exemplary embodiment.

[0031] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0033] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. The singular forms “a” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0034] In the embodiments of this disclosure, "multiple" refers to two or more. In some embodiments, the notation "at least one of A and B", "A and / or B", "A in one case, B in another", "in response to one case A, in response to another case B", etc., may include the following technical solutions depending on the situation: in some embodiments, A (execute A regardless of B); in some embodiments, B (execute B regardless of A); in some embodiments, selective execution from A and B (A and B are selectively executed); in some embodiments, A and B (both A and B are executed). The same applies when there are more branches such as A, B, C, etc.

[0035] In some embodiments, the notation "A or B" may include the following technical solutions, depending on the situation: in some embodiments, A (execution of A regardless of B); in some embodiments, B (execution of B regardless of A); in some embodiments, execution is selected from A and B (A and B are selectively executed). The same applies when there are more branches such as A, B, C, etc.

[0036] In some embodiments, the terms “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “if…”, “if…”, etc., can be used interchangeably.

[0037] In related technologies, when switching applications, the application process typically creates a frame buffer, which often pre-allocates multiple buffer blocks for subsequent graphics rendering. However, this video memory allocation process incurs performance overhead on the central processing unit (CPU) and memory, involving cross-process communication and switching from user mode to kernel mode to allocate video memory resources. This process is time-consuming and can lead to a decrease in smoothness (such as stuttering and frame drops).

[0038] Therefore, this disclosure provides a video memory processing method that can solve the problem in related technologies where the allocation of video memory resources takes a long time when switching applications, resulting in a decrease in smoothness (such as stuttering, frame dropping, etc.).

[0039] Figure 1 This is a flowchart illustrating a video memory processing method according to an exemplary embodiment. It should be noted that this method can be used in electronic devices; exemplaryly, the electronic device can be a terminal (such as a smartphone) or other electronic devices with a Graphics Processing Unit (GPU). Figure 1 As shown, the video memory processing method may include, but is not limited to, the following steps.

[0040] In step 101, it is detected that the application has switched from a background running state to a foreground running state.

[0041] In some embodiments, the application can be any application software installed on the electronic device; or, for example, the application can be multiple application software installed on the electronic device. For instance, the application can be, but is not limited to, instant messaging software, office software, or game software.

[0042] In one possible implementation, callback methods can be used to monitor whether an application switch has occurred on the electronic device. For example, taking the electronic device's operating system as Android, when an application moves from the background to the foreground, the Activity component undergoes a series of lifecycle changes, including calls to the `onStart()` and `onResume()` methods. By overriding these methods and checking the visibility of the current Activity component in `onResume()`, it's possible to determine whether the application has switched from a background running state to a foreground running state. For instance, this can be determined by checking the `RunningAppProcessInfo` class (which encapsulates information about the running process) provided by the ActivityManager. For example, if checking the `RunningAppProcessInfo` class provided by the ActivityManager reveals that it encapsulates the process information of application A, then it's detected that application A has switched from a background running state to a foreground running state.

[0043] In another possible implementation, tracking can be performed using a custom Application class to monitor application switching on an electronic device. For example, taking an Android operating system as an example, a static variable can be created in the custom Application class to mark the application's foreground and background running states, providing getter methods to retrieve this state and setter methods to set it. For instance, the state can be set to foreground running in the `onResume()` method of the Activity component's base class (`BaseActivity`), and to background running in the `onPause()` method. By checking the value of this static variable, it's possible to determine whether the application has switched from background to foreground running. For example, if the first value of this static variable represents foreground running and the second value represents background running, then a change in the value of the static variable from the second value to the first value indicates that the application has switched from background to foreground running.

[0044] It should be noted that the two possible implementations of monitoring the switching of an application from background to foreground running state given above are only for the convenience of those skilled in the art to understand this disclosure, and should not be regarded as a specific limitation of this disclosure. That is to say, other means can also be used to monitor the switching of an application from foreground to background, and this disclosure does not limit them, nor will it elaborate further.

[0045] In step 102, it is determined that there is an available buffer in the video memory pool associated with the application, and the available buffer is reused.

[0046] In some embodiments, the video memory pool associated with an application can be understood as a cache pool consisting of the video memory corresponding to that application. For example, multiple applications can correspond to one video memory pool; for instance, multiple applications can share (or share) a single video memory pool. Alternatively, for example, each application can correspond to its own video memory pool. For example, taking one video memory pool per application as an example, during an application cold start, a video memory pool corresponding to that application can be created. A cold start can be understood as follows: when there is no background process for that application, the system creates a new process and assigns it to that application, and then starts the corresponding process component according to the startup parameters. This startup method is called a cold start.

[0047] In some embodiments, the video memory pool can be used to store application process buffers that meet the conditions for being added to the video memory pool. These application process buffers are buffers that the application wants to release when it enters a background running state. For example, when an application exits to a background running state (i.e., switches from a foreground running state to a background running state) and releases video memory, the application process buffer that the application wants to release can be determined. The application process buffer that meets the conditions for being added to the video memory pool can be added to the video memory pool associated with the application. For example, the handle of the application process buffer that meets the conditions for being added to the video memory pool can be added to the video memory pool so that when the application re-enters (i.e. switches from a background running state to a foreground running state), it can reuse the buffer in the video memory pool. For example, it can find an available buffer in the video memory pool and reuse the available buffer.

[0048] By implementing the embodiments of this disclosure, when switching applications, it is not necessary to request video memory allocation from the underlying system. Instead, an available buffer can be found from the video memory pool associated with the application and reused. This video memory pool stores application process buffers that meet the conditions for joining the video memory pool; these application process buffers are buffers that the application intends to release when it enters a background running state. This effectively reduces the response time of application warm starts, reduces the number of dropped frames during application switching, and improves the smoothness of the user experience.

[0049] Optionally, in some embodiments, when an application exits to a background running state (i.e., switches from a foreground running state to a background running state) and releases video memory, the application process buffer of the application can be added to the video memory pool associated with the application, so that the application can reuse the buffer in the video memory pool when it re-enters. For example, Figure 2This is a flowchart illustrating a video memory processing method according to an exemplary embodiment. It should be noted that this method can be used in electronic devices. For example... Figure 2 As shown, the video memory processing method may include, but is not limited to, the following steps.

[0050] In step 201, a request to release video memory is received when the application enters a background running state.

[0051] In some embodiments, the application can be any application software installed on the electronic device; or, for example, the application can be multiple application software installed on the electronic device. For instance, the application can be, but is not limited to, instant messaging software, office software, or game software.

[0052] In some embodiments, an application entering a background running state can be understood as the application switching from a foreground running state to a background running state, or it can also be understood as the application exiting to the background. For example, if an application enters a background running state, the application will send a request to release video memory. Correspondingly, the electronic device can receive the video memory release request sent by the application. The video memory release request can be used to request the release of video memory used by the application, such as requesting the release of the application process buffer used by the application.

[0053] In step 202, the application process buffer used by the application is determined based on the request to release video memory.

[0054] In some embodiments, the request to release video memory may include, but is not limited to, the process identifier of the application; the application process buffer used by the application can be determined based on the process identifier included in the request to release video memory. For example, the process of the application corresponding to the process identifier can be determined based on the process identifier included in the request to release video memory, and the application process buffer used by the application can be determined based on the mapping of the process.

[0055] In step 203, based on the parameter information of the application process buffer, it is determined whether the application process buffer meets the conditions for adding to the video memory pool.

[0056] In some embodiments, the application buffer may include, but is not limited to, a graphics buffer. In some embodiments, the parameter information of the application buffer may include, but is not limited to, at least one of the following: pixel color mode; resolution; buffer type; buffer size; number of bits used to store the color of one pixel, etc.

[0057] In some embodiments, if the parameter information of the application process buffer satisfies the parameter information of the target buffer, it can be determined that the application process buffer meets the conditions for joining the video memory pool; or, if the parameter information of the application process buffer does not satisfy the parameter information of the target buffer, it can be determined that the application process buffer does not meet the conditions for joining the video memory pool. In some embodiments, the target buffer may include, but is not limited to, texture-related buffers, such as blit_buffer.

[0058] In some embodiments, if the parameter information of the application process buffer matches the parameter information of the target buffer, it can be determined that the application process buffer meets the conditions for joining the video memory pool. For example, if the parameter information of the application process buffer is consistent with (or identical to) the parameter information of the target buffer, it can be determined that the application process buffer meets the conditions for joining the video memory pool.

[0059] In some embodiments, if the parameter information of the application process buffer does not match the parameter information of the target buffer, it can be determined that the application process buffer does not meet the conditions for joining the video memory pool. For example, if the parameter information of the application process buffer is inconsistent (or different) from the parameter information of the target buffer, it can be determined that the application process buffer does not meet the conditions for joining the video memory pool.

[0060] In some embodiments, if the parameter information of the application process buffer meets the parameter information of the target buffer, it can be determined that the application process buffer meets the conditions for joining the video memory pool; if the parameter information of the application process buffer does not meet the parameter information of the target buffer, it can be determined that the application process buffer does not meet the conditions for joining the video memory pool. For example, the parameter information of the application process buffer can be compared with the parameter information of the target buffer to obtain a comparison result, and the result can be used to determine whether the application process buffer meets the conditions for joining the video memory pool. For instance, if the parameter information of the application process buffer is consistent with (or identical to) the parameter information of the target buffer, it can be determined that the application process buffer meets the conditions for joining the video memory pool; if the parameter information of the application process buffer is inconsistent with (or different from) the parameter information of the target buffer, it can be determined that the application process buffer does not meet the conditions for joining the video memory pool.

[0061] In step 204, if the application process buffer meets the conditions for adding to the video memory pool, then the application process buffer is added to the video memory pool.

[0062] In some embodiments, if the parameter information of the application process buffer matches the parameter information of the target buffer, it can be determined that the application process buffer meets the conditions for adding to the video memory pool, and the application process buffer can be added to the video memory pool. For example, the handle (buffer_handle_t) of the application process buffer can be added to the video memory pool.

[0063] In step 205, if the application process buffer does not meet the conditions for joining the video memory pool, the application process buffer is released.

[0064] In some embodiments, if the parameter information of the application process buffer does not meet the parameter information of the target buffer, it can be determined that the application process buffer does not meet the conditions for joining the video memory pool, and the application process buffer can be released, that is, the mapping and use of the application process can be released.

[0065] It should be noted that in some embodiments, steps 204 and 205 are selectively executed. For example, if step 204 is executed, then step 205 will not be executed; if step 205 is executed, then step 204 will not be executed.

[0066] For example, such as Figure 3A As shown, when an application exits to a background running state (i.e., switches from a foreground running state to a background running state) and releases (i.e., unmaps the application's process) video memory, it can be determined whether the application process buffer used by the application (i.e., the buffer to be released) meets the video memory pool addition conditions. If the application process buffer used by the application meets the video memory pool addition conditions, the handle of the application process buffer can be added to the video memory pool associated with the application. If the application process buffer used by the application does not meet the video memory pool addition conditions, the application process buffer can be released, i.e., the mapping of the application's process can be unmapped.

[0067] Optionally, in some embodiments, such as Figure 2 As shown, the video memory processing method also includes, but is not limited to, the following steps.

[0068] In step 206, it is detected that the application has switched from a background running state to a foreground running state.

[0069] For optional implementations of step 206, please refer to [link / reference]. Figure 1 Optional implementation methods for step 101, and Figure 1 Other related parts in the embodiments involved will not be described in detail here.

[0070] In step 207, it is determined whether there is an available buffer in the video memory pool associated with the application.

[0071] In some embodiments, when an application switches from a background running state to a foreground running state, it sends a video memory allocation request. Accordingly, upon receiving the video memory allocation request from the application, it can be determined whether there is a usable buffer in the video memory pool associated with the application. For example, the existence of a usable buffer in the video memory pool associated with the application can be determined based on at least one of the video memory allocation size, buffer type, pixel color mode, resolution, etc., included in the video memory allocation request. For instance, if a buffer exists in the video memory pool that can satisfy the video memory allocation request, then that buffer can be determined as a usable buffer; that is, it is determined that a usable buffer exists in the video memory pool. If no buffer exists in the video memory pool that can satisfy the video memory allocation request, then it is determined that no usable buffer exists in the video memory pool.

[0072] In step 208, if there is an available buffer in the video memory pool, the available buffer is reused.

[0073] For example, if an available buffer exists in the video memory pool associated with the application, that available buffer can be reused. For example, a handle to the available buffer can be obtained from the video memory pool, and the available buffer can be mapped to reuse it.

[0074] In step 209, if no available buffer exists in the memory pool, a memory request is sent to the GPU to allocate memory for the application.

[0075] For example, if there is no available buffer in the memory pool associated with the application, a memory request can be sent to the GPU, that is, a low-level call process can be used to allocate memory for the application.

[0076] It should be noted that in some embodiments, steps 208 and 209 are selectively executed. For example, if step 208 is executed, then step 209 will not be executed; if step 209 is executed, then step 208 will not be executed.

[0077] For example, such as Figure 3B As shown, when an application switches from a background running state to a foreground running state, it sends a video memory allocation request. Correspondingly, upon receiving this request, the system can determine whether an available buffer exists in the video memory pool associated with that application. If an available buffer exists, its handle can be obtained from the pool, and the buffer can be mapped for reuse. If no available buffer exists, a video memory request can be sent to the GPU to allocate video memory for the application.

[0078] Optionally, in some embodiments, a possible implementation of sending a memory request to the GPU to allocate memory for the application is as follows: Based on the application's needs, a rendering instruction is sent to the GPU, and the required memory size is determined based on the size of the rendering data in the rendering instruction. Before performing rendering, the GPU searches for a matching free memory block based on the requested memory size using a bitmap algorithm and a buddy algorithm. If a matching free memory block is found, a memory request is sent to the GPU. The GPU performs the allocation and resets the corresponding bitmap algorithm status flag on the processor (CPU) side, thereby completing the memory allocation.

[0079] It is worth noting that when switching applications, the buffers of background application processes may not be released, leading to an increase in video memory usage. For high-frequency screens, each additional buffer in the video memory pool consumes a significant amount of memory when the application is displayed in full-screen mode. For example, for a 1080p screen, each additional buffer in the video memory pool consumes up to approximately 8MB of memory when the application is displayed in full-screen mode. To address this issue, this disclosure can use a risk management mechanism to pool the video memory pool, preventing applications from excessively consuming video memory resources. This can solve the problem of wasted memory resources or insufficient video memory allocation in certain scenarios. Optionally, in some embodiments, when the application process buffer is added to the video memory pool, the pool can be pooled based on a risk management mechanism. This risk management mechanism may include, but is not limited to, at least one of the following: dynamic capacity control mechanism; application-specific optimization mechanism; timeout release mechanism. For example, the video memory pool can be pooled based on a dynamic capacity control mechanism. For example, the video memory pool can be pooled based on a game-specific optimization mechanism. For example, the memory pool can be pooled based on a timeout release mechanism.

[0080] Optionally, in some embodiments, the possible implementation of the pooling operation of the video memory pool based on the capacity dynamic control mechanism may include: determining the current number of buffers in the video memory pool after adding the application process buffer; determining the total memory size of the current buffers in the video memory pool after adding the application process buffer; determining the current remaining free memory size (i.e., determining the current remaining free memory size of the GPU); determining whether the capacity dynamic control mechanism is satisfied based on the current number of buffers, the current total memory size of the buffers, and the current remaining free memory size; and performing a eviction operation on the buffers in the video memory pool.

[0081] For example, such as Figure 4As shown, when the application process buffer is added to the video memory pool, the current number of buffers in the video memory pool after the application process buffer is added can be determined, as well as the total memory size of the current buffers in the video memory pool after the application process buffer is added, and the current remaining free memory size of the GPU can also be determined. The ratio of the current remaining free memory size to the current total memory size of the buffers is calculated. If the ratio is greater than a first threshold and the current number of buffers is less than a second threshold, the process exits. If the ratio is less than or equal to the first threshold, and / or the current number of buffers is greater than or equal to the second threshold, it can be determined that the dynamic capacity control mechanism is satisfied, and a eviction algorithm can be used to evict buffers in the video memory pool. For example, the eviction algorithm may include, but is not limited to, any of the following: LFU (Least Frequently Used) algorithm; LRU (Least Recently Used) algorithm, etc. Optionally, in some embodiments, the possible implementation of the above-mentioned pooling operation of the video memory pool based on a specific game optimization mechanism may include: listening for the launch of a specific application and clearing the video memory pool. In some embodiments, the specific application may be understood as the most popular game application, or it may be a designated game application, or it may be other designated applications. For example, such as... Figure 5 As shown, the system listens for the startup of a specific application. If the startup of the specific application is detected, the video memory pool is cleared. For example, all video memory pools in the electronic device can be cleared; these all video memory pools refer to the video memory pools associated with background applications. Optionally, when starting the specific application, a distributed scheduling framework can be used to start the specific application. For example, the distributed scheduling framework can be a VIP (Virtual IP Address) scheduling framework. Optionally, in some embodiments, the possible implementation of the above-described pooling operation based on the timeout release mechanism for the video memory pool may include: determining the duration of the application running in the background; if the duration is greater than or equal to a preset duration, clearing the buffer associated with the application in the video memory pool. For example, as... Figure 6 As shown, when an application switches from a foreground to a background running state, a thread is started to time whether the application switches back to the foreground running state within a preset time period (i.e., the preset duration mentioned above, such as 3 minutes). If the application does not switch back to the foreground running state within the preset time period, the pre-stored buffers of each process in the video memory pool associated with the application can be cleared.

[0082] In the above embodiments, when an application exits to a background running state (i.e., switches from a foreground running state to a background running state) and releases video memory, the application process buffer of the application can be added to the video memory pool associated with the application. This allows the application to reuse the buffer in the video memory pool when it re-enters the application, without needing to request video memory allocation from the underlying system. This effectively reduces the response time of application warm starts, reduces the number of dropped frames during application switching, and improves the smoothness of the experience. Furthermore, by using a risk handling mechanism to pool the video memory pool, the application can avoid excessive consumption of video memory resources, thus solving the problem of wasted memory resources or insufficient video memory allocation in certain scenarios.

[0083] Figure 7 This is a block diagram illustrating a video memory processing device according to an exemplary embodiment. (Refer to...) Figure 7 The device includes a monitoring module 701, a first determination module 702, and a multiplexing module 703.

[0084] The monitoring module 701 is used to monitor when the application switches from a background running state to a foreground running state.

[0085] The first determining module 702 is used to determine whether there is an available buffer in the video memory pool associated with the application. The video memory pool stores application process buffers that meet the conditions for joining the video memory pool; these application process buffers are buffers that the application intends to release when it enters a background running state.

[0086] The reuse module 703 is used to reuse available buffers.

[0087] In some embodiments, such as Figure 8 As shown, the video memory processing device may further include: a receiving module 804, a second determining module 805, a third determining module 806, an adding module 807, and a releasing module 808. The receiving module 804 is used to receive a video memory release request sent when an application enters a background running state; the second determining module 805 is used to determine the application process buffer used by the application based on the video memory release request; the third determining module 806 is used to determine whether the application process buffer meets the video memory pool adding conditions based on the parameter information of the application process buffer; the adding module 807 is used to add the application process buffer to the video memory pool when the application process buffer meets the video memory pool adding conditions; and the releasing module 808 is used to release the application process buffer when the application process buffer does not meet the video memory pool adding conditions. Figure 8 801-803 and Figure 7 The 701-703 series have the same function and structure.

[0088] In some embodiments, the third determining module 806 is specifically configured to: determine that the application process buffer meets the memory pool addition condition if the parameter information of the application process buffer satisfies the parameter information of the target buffer; or, determine that the application process buffer does not meet the memory pool addition condition if the parameter information of the application process buffer does not satisfy the parameter information of the target buffer. In some embodiments, the target buffer includes at least a texture-related buffer.

[0089] In some embodiments, such as Figure 9 As shown, the video memory processing device may further include a pooling operation module 909. The pooling operation module 909 is used to perform pooling operations on the video memory pool based on a risk handling mechanism when an application process buffer is added to the video memory pool; wherein the risk handling mechanism includes at least one of the following: a dynamic capacity control mechanism; a specific application optimization mechanism; and a timeout release mechanism. Figure 9 901-908 and Figure 8 The 801-808 series have the same function and structure.

[0090] In some embodiments, the pooling operation module 909 may perform pooling operations on the video memory pool based on the capacity dynamic control mechanism in the following ways: determining the current number of buffers in the video memory pool after adding the application process buffer; determining the total memory size of the current buffers in the video memory pool after adding the application process buffer; determining the current remaining free memory size; determining whether the capacity dynamic control mechanism is satisfied based on the current number of buffers, the current total memory size of the buffers, and the current remaining free memory size; and performing a eviction operation on the buffers in the video memory pool.

[0091] In some embodiments, the pooling operation module 909 may perform pooling operations on the video memory pool based on a specific game optimization mechanism in the following ways: upon detecting the launch of a specific application, the video memory pool is cleared.

[0092] In some embodiments, the pooling operation module 909 may perform pooling operations on the video memory pool based on the timeout release mechanism in the following ways: determining the duration of the application running in the background; if the duration is greater than or equal to a preset duration, clearing the buffer associated with the application in the video memory pool.

[0093] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0094] Figure 10 This is a block diagram illustrating an electronic device 1000 according to an exemplary embodiment. For example, the electronic device 1000 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0095] Reference Figure 10 The electronic device 1000 may include one or more of the following components: a processing component 1002, a memory 1004, a power supply component 1006, a multimedia component 1008, an audio component 1010, an input / output (I / O) interface 1012, a sensor component 1014, and a communication component 1016.

[0096] Processing component 1002 typically controls the overall operation of electronic device 1000, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1002 may include one or more processors 1020 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1002 may include one or more modules to facilitate interaction between processing component 1002 and other components. For example, processing component 1002 may include a multimedia module to facilitate interaction between multimedia component 1008 and processing component 1002.

[0097] Memory 1004 is configured to store various types of data to support the operation of electronic device 1000. Examples of this data include instructions for any application or method operating on electronic device 1000, contact data, phonebook data, messages, pictures, videos, etc. Memory 1004 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0098] Power supply component 1006 provides power to various components of electronic device 1000. Power supply component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 1000.

[0099] Multimedia component 1008 includes a screen that provides an output interface between the electronic device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1008 includes a front-facing camera and / or a rear-facing camera. When the electronic device 1000 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0100] Audio component 1010 is configured to output and / or input audio signals. For example, audio component 1010 includes a microphone (MIC) configured to receive external audio signals when electronic device 1000 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1004 or transmitted via communication component 1016. In some embodiments, audio component 1010 also includes a speaker for outputting audio signals.

[0101] I / O interface 1012 provides an interface between processing component 1002 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0102] Sensor assembly 1014 includes one or more sensors for providing state assessments of various aspects of electronic device 1000. For example, sensor assembly 1014 may detect the on / off state of electronic device 1000, the relative positioning of components such as the display and keypad of electronic device 1000, changes in position of electronic device 1000 or a component of electronic device 1000, the presence or absence of user contact with electronic device 1000, the orientation or acceleration / deceleration of electronic device 1000, and temperature changes of electronic device 1000. Sensor assembly 1014 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1014 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1014 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0103] Communication component 1016 is configured to facilitate wired or wireless communication between electronic device 1000 and other devices. Electronic device 1000 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 1016 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1016 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0104] In an exemplary embodiment, the electronic device 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0105] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1004 including instructions, which can be executed by a processor 1020 of an electronic device 1000 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0106] In an exemplary embodiment, a computer program product is also provided, including a computer program that is executed by the processor 1020 of the electronic device 1000 to perform the above-described method.

[0107] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0108] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for processing a video memory, the method comprising: The method comprises: monitoring that an application program switches from a background running state to a foreground running state; determining that there is an available buffer in a video memory pool associated with the application program, and reusing the available buffer; wherein the video memory pool is used to store application process buffers that meet a video memory pool joining condition, and the application process buffer is a buffer to be released by the application program when entering the background running state.

2. The method of claim 1, wherein, The method further comprises: receiving a release video memory request sent when the application program enters the background running state; determining an application process buffer used by the application program according to the release video memory request; determining whether the application process buffer meets the video memory pool joining condition according to parameter information of the application process buffer; if the application process buffer meets the video memory pool joining condition, adding the application process buffer to the video memory pool; or if the application process buffer does not meet the video memory pool joining condition, releasing the application process buffer.

3. The method of claim 2, wherein, The determination of whether the application process buffer meets the video memory pool joining condition according to the parameter information of the application process buffer comprises: if the parameter information of the application process buffer meets the parameter information of a target buffer, it is determined that the application process buffer meets the video memory pool joining condition; or if the parameter information of the application process buffer does not meet the parameter information of the target buffer, it is determined that the application process buffer does not meet the video memory pool joining condition.

4. The method of claim 3, wherein, The target buffer at least includes a texture-related buffer.

5. The method of claim 2, wherein, The method further comprises: in the case of adding the application process buffer to the video memory pool, performing a pool operation on the video memory pool based on a risk handling mechanism, wherein the risk handling mechanism comprises at least one of the following: a capacity dynamic control mechanism; a specific application program optimization mechanism; a timeout release mechanism.

6. The method of claim 5, wherein, Performing the pool operation on the video memory pool based on the capacity dynamic control mechanism comprises: determining the number of current buffers in the video memory pool after adding the application process buffer; determining the total memory size of the current buffers in the video memory pool after adding the application process buffer; determining the current remaining idle memory size; determining whether the capacity dynamic control mechanism is met according to the number of current buffers, the total memory size of current buffers, and the current remaining idle memory size; performing a pruning operation on the buffers in the video memory pool.

7. The method of claim 5, wherein, Performing the pool operation on the video memory pool based on the specific game optimization mechanism comprises: listening to the start of a specific application program, and emptying the video memory pool.

8. The method of claim 5, wherein, Performing the pool operation on the video memory pool based on the timeout release mechanism comprises: determining the duration of the application program in the background running state; if the duration is greater than or equal to a preset duration, emptying the buffers in the video memory pool associated with the application program.

9. A video memory processing device, characterized by comprising: The method comprises: a monitoring module configured to monitor that an application program switches from a background running state to a foreground running state; a first determining module configured to determine that there is an available buffer in a video memory pool associated with the application program; a reuse module configured to reuse the available buffer. The application discloses a graphics memory processing method and device, and a computer readable storage medium.

10. An electronic device, comprising: Comprise: One or more processors; The electronic device is configured to perform the graphics memory processing method of any one of claims 1-8.

11. A storage medium, the storage medium storing instructions, wherein, The instructions, when executed on the electronic device, cause the electronic device to perform the graphics memory processing method of any one of claims 1-8.

12. A computer program product comprising a computer program, characterized in that, The computer program, when executed on the electronic device, implements the steps of the method of any one of claims 1-8.