Resource allocation method and device, electronic equipment and computer readable storage medium

Abstract

The embodiment of the invention discloses a resource allocation method and device, electronic equipment and a computer readable storage medium, and belongs to the technical field of computers. The method comprises the following steps: when a target process is started for the first time, distributing an image buffer area for the target process in a system memory pool, caching the image buffer area into an image buffer pool, and when the target process is started again, distributing the image buffer area for the target process in the image buffer pool. Therefore, by creating the independent image buffer pool for the target process, when the target process is restarted, the allocated image buffer area can be directly reused from the image buffer pool, so that a tedious physical memory repeated application process is effectively avoided, the display delay of an equipment picture is remarkably reduced, and the operation fluency is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, in particular to a resource allocation method and device, electronic equipment and computer readable storage medium. BACKGROUND

[0002] For mobile devices with limited RAM (Random Access Memory) resources, especially in multitasking heavy scenarios, when an application exits and returns to the desktop, it is easy to cause device screen freezing and other situations, which seriously affects the user experience. SUMMARY

[0003] Embodiments of the present application provide a resource allocation method and device, electronic equipment and computer readable storage medium, which can significantly reduce the display delay of the device screen and improve the operation fluency.

[0004] In a first aspect, embodiments of the present application provide a resource allocation method, comprising: allocating an image buffer for a target process in a system memory pool when the target process is started for the first time, and caching the image buffer in an image buffer pool; allocating the image buffer for the target process in the image buffer pool when the target process is started again.

[0005] In one of the embodiments, the method further comprises: obtaining target quantity information; updating a quantity attribute of the image buffer pool based on the target quantity information; the quantity attribute represents the maximum number of image buffers allowed to be used by the target process.

[0006] In one of the embodiments, the updating the quantity attribute of the image buffer pool based on the target quantity information comprises: updating the quantity attribute of the image buffer pool to the target quantity information through a target interface.

[0007] In one of the embodiments, the target quantity information comprises first quantity information and second quantity information; the quantity attribute comprises first quantity attribute and second quantity attribute, the first quantity attribute represents the maximum number of buffers that producers can simultaneously dequeue and use, and the second quantity attribute represents the maximum number of buffers that consumers can simultaneously acquire and hold; updating the quantity attribute of the image buffer pool based on the target quantity information comprises: updating the first quantity attribute of the image buffer pool based on the first quantity information; update the second quantity attribute of the image buffer pool based on the second quantity information.

[0008] In one of the embodiments, the allocating the image buffer to the target process when the target process is started again comprises: determining whether the image buffer in the image buffer pool meets an update condition when the target process is started again; allocating the image buffer to the target process in the image buffer pool in a case that the image buffer in the image buffer pool is determined not to meet the update condition.

[0009] In one of the embodiments, the method further comprises: allocating a new image buffer to the target process in the system memory pool in a case that the image buffer in the image buffer pool is determined to meet the update condition; updating the image buffer in the image buffer pool based on the new image buffer.

[0010] In one of the embodiments, the determining whether the image buffer in the image buffer pool meets an update condition comprises: obtaining a request parameter of the target process; the request parameter comprises one or more of height, width and pixel format; determining that the image buffer does not meet the update condition in a case that the request parameter matches a parameter of the image buffer; determining that the image buffer in the image buffer pool meets the update condition in a case that the request parameter does not match the parameter of the image buffer.

[0011] In a second aspect, the embodiments of the present application provide a resource allocation apparatus, which comprises: a caching module, configured to allocate an image buffer to a target process in a system memory pool when the target process is started for the first time, and cache the image buffer into an image buffer pool; an allocating module, configured to allocate the image buffer to the target process in the image buffer pool when the target process is started again.

[0012] In one of the embodiments, the resource allocation apparatus further comprises: an information obtaining module, configured to obtain target quantity information; a quantity updating module, configured to update a quantity attribute of the image buffer pool based on the target quantity information; the quantity attribute represents a maximum number of image buffers allowed to be used by the target process.

[0013] In one of the embodiments, the quantity updating module is specifically configured to update the quantity attribute of the image buffer pool to the target quantity information through a target interface.

[0014] In one of the embodiments, the target quantity information comprises first quantity information and second quantity information; and the quantity attribute comprises first quantity attribute and second quantity attribute, the first quantity attribute representing the maximum number of buffer zones that a producer can simultaneously dequeue and use, and the second quantity attribute representing the maximum number of buffer zones that a consumer can simultaneously acquire and hold. The quantity updating module comprises: a first updating submodule configured to update the first quantity attribute of the image buffer pool based on the first quantity information; a second updating submodule configured to update the second quantity attribute of the image buffer pool based on the second quantity information.

[0015] In one of the embodiments, the allocation module comprises: a condition determining submodule configured to determine whether an image buffer zone in the image buffer pool meets an updating condition when the target process is started again; an allocation submodule configured to allocate the image buffer zone for the target process in the image buffer pool in a case where it is determined that the image buffer zone in the image buffer pool does not meet the updating condition.

[0016] In one of the embodiments, the resource allocation apparatus further comprises: a reallocation module configured to allocate a new image buffer zone for the target process in the system memory pool in a case where it is determined that the image buffer zone in the image buffer pool meets the updating condition; an image buffer zone updating module configured to update the image buffer zone in the image buffer pool based on the new image buffer zone.

[0017] In one of the embodiments, the condition determining submodule comprises: a parameter acquisition unit configured to acquire a request parameter of the target process; the request parameter comprises one or more of height, width and pixel format; a first condition determining unit configured to determine that the image buffer zone does not meet the updating condition in a case where the request parameter matches a parameter of the image buffer zone; a second condition determining unit configured to determine that the image buffer zone in the image buffer pool meets the updating condition in a case where the request parameter does not match the parameter of the image buffer zone.

[0018] In a third aspect, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program, when executed by the processor, implements the steps of the resource allocation method described above.

[0019] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program, when executed by a processor, implements the steps of the resource allocation method described above.

[0020] In a fifth aspect, a computer program product or computer program is provided, which includes computer instructions stored in a computer readable storage medium, and a processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in various optional implementation manners described in the embodiments of the present application.

[0021] To sum up, in the embodiments of the present application, the image buffer area is allocated to the target process in the system memory pool when the target process is started for the first time, and the image buffer area is cached to the image buffer pool, and the image buffer area is allocated to the target process in the image buffer pool when the target process is started again. In this way, by creating an independent image buffer pool for the target process, the target process can directly reuse the allocated image buffer area from the image buffer pool when started for the second time and subsequent times, completely avoiding the lengthy physical memory repeated application process, and thus significantly reducing the display delay of the device picture and improving the operation fluency. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0023] Figure 1 is a schematic diagram of the steps of the resource allocation method provided by an embodiment of the present application; Figure 2 is an architecture diagram of an Android graphics system provided by an embodiment of the present application; Figure 3 is a schematic diagram of module interaction provided by an embodiment of the present application; Figure 4 is a schematic diagram of a specific embodiment of the resource allocation method provided by an embodiment of the present application; Figure 5 is a structural schematic diagram of a resource allocation device provided by an embodiment of the present application; Figure 6 FIG. 1 is a structural schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] The technical solutions in the present application will be clearly and completely described in combination with the drawings in the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0025] It should be noted that in the Android system graphical display architecture, the application layer needs to apply for a graphic buffer (GraphicBuffer) to the system through the dequeueBuffer() interface to complete interface rendering, the graphic buffer is used to store graphic data and serves as a carrier for data transmission between the application and the system display service (such as SurfaceFlinger). Each graphic buffer usually needs to occupy 4MB to 10MB of continuous physical memory according to the screen resolution and different application application parameters.

[0026] For example, in the heavy load case of a low-RAM device, when a user exits from a large application back to the Launcher (desktop), the Launcher process needs to re-apply and allocate multiple graphic buffers to complete interface drawing. Since the single memory allocation operation itself has a non-negligible time overhead (up to tens of milliseconds), and the number of graphic buffers required by a regular application is usually 2 to 7 or more, the total time consumption of the allocation operation is very significant. The repeated allocation of such a large number of graphic buffers will significantly increase the time overhead, causing the display period of a frame of image to be prolonged, thereby making the process of exiting the application to the desktop become laggy.

[0027] In the related art, the system's original memory management mechanism is usually relied on, and there is a lack of targeted optimization strategy for key processes (such as the Launcher process). The application and release of the graphic buffer completely follow the default life cycle, thereby inevitably introducing repeated memory allocation overhead and performance loss in frequent foreground and background switching, causing the user to perceive screen lag and unsmoothness, and seriously affecting the user experience.

[0028] In view of the problem that frequent application of image buffer causes device picture display to be stuck, the present application aims to provide a resource allocation method, which creates an independent image buffer pool for the target process when it is started for the first time, so that the target process can directly reuse the allocated image buffer when it is started for the second time and subsequent times. In this way, the lengthy physical memory reapplication process can be completely avoided, and the display delay of the device picture is significantly reduced, and the operation fluency is improved.

[0029] The terms related to the embodiments of the present application are explained as follows.

[0030] APP: Application, application program. It does not directly draw graphics by itself, but defines the content to be drawn by calling various graphic APIs.

[0031] Surface: Surface. It is an interface through which the application interacts with the system graphics system. It is connected with a BufferQueue behind it. The application applies (dequeueBuffer) and submits (queueBuffer) the image buffer through it.

[0032] GraphicBuffer: GraphicBuffer. A block of memory buffer specially used for storing image data (pixels). The image data drawn by the application program is finally stored in the image buffer.

[0033] queueBuffer: queueBuffer. Apply for an idle GraphicBuffer from the queue for drawing.

[0034] dequeueBuffer: dequeueBuffer. Put the GraphicBuffer with the drawn content back into the queue and notify the consumer (such as SurfaceFlinger) to take it.

[0035] BLASTBufferQueue: Buffer Layout and Surface Tiling. A modern and more flexible implementation of BufferQueue, used to manage Surface and its underlying buffer queue. It improves the performance in scenarios such as split screen, free window, etc.

[0036] BufferQueueCore: BufferQueueCore. It is the brain of BufferQueue, which internally maintains a fixed-size array, Buffer slots, to store all GraphicBuffers. It manages the state of the buffer (such as idle, dequeued, queued, acquired).

[0037] BufferQueueProducer: Buffer Queue Producer interface. It encapsulates the API of BufferQueueCore, and is specifically provided for the producer (i.e. the upper layer APP) to call. The dequeueBuffer and queueBuffer invoked by the application are finally handled by it.

[0038] BufferQueueConsumer: Buffer Queue Consumer interface. It encapsulates the API of BufferQueueCore, and is specifically provided for the consumer to call.

[0039] SurfaceFlinger: Surface Flinger / Compositor. It is the core service of the Android graphics system, and is the most important consumer in the system. Its responsibility is to receive the Surface data (i.e. GraphicBuffer) from various applications (producers), compose them into a final image frame, and then send it to the display for display.

[0040] Gralloc: Graphics Memory Allocator module. It is the actual allocator of the physical memory of GraphicBuffer. When BufferQueueProducer calls dequeueBuffer, if there is no available buffer in the slot, a new, continuous piece of physical memory will be allocated through Gralloc.

[0041] DMA / ION: Memory Management Driver. Gralloc module allocates and manages continuous physical memory blocks through them for GPU (Graphics Processing Unit, graphics processor), display and other hardware to access directly.

[0042] The following will be described in detail. It should be noted that the order of the following embodiments is not limited as the priority order of the embodiments.

[0043] Figure 1 A flowchart of a resource allocation method according to an embodiment of the present application is schematically shown. The execution subject of the resource allocation method can be a resource allocation apparatus, which can be integrated in an electronic device with image drawing function. The electronic device can be a server, a terminal or the like.

[0044] The server can be a stand-alone physical server, a server cluster or a distributed system composed of multiple physical servers, a cloud server providing cloud services, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, network acceleration service (Content Delivery Network, CDN), and basic cloud computing services such as big data and artificial intelligence platform.

[0045] The terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart watch, and the like, but is not limited thereto.

[0046] In this embodiment, the resource allocation device will be described from the perspective of a resource allocation device, which can be integrated in a server or a terminal or the like. For the convenience of describing the resource allocation method of the present application, the resource allocation device will be described in detail below, that is, the terminal will be taken as the execution subject.

[0047] Referring to Figure 1 , a resource allocation method of the present application is shown, which can specifically include the following steps: S101: When a target process is started for the first time, an image buffer area is allocated for the target process in a system memory pool, and the image buffer area is cached in an image buffer pool.

[0048] In this embodiment, the target process represents a process that needs to build an image buffer pool separately. The target process can be a frequently used process, for example, a process with a usage frequency greater than a frequency threshold can be determined as a target process.

[0049] Specifically, the target process can be one or more of a Launcher (desktop) process, a SystemUI (system UI) process, an IME (Input Method Editor) process, and a target application process; wherein the target application includes a system pre-installed application and a third-party application, the system pre-installed application includes but is not limited to a camera, a gallery, a phone, a message, a file manager, an application store, and the like, and the third-party application includes but is not limited to WeChat, QQ, and audio and video software, and the like.

[0050] In this embodiment, the image buffer pool represents a memory pool for caching the image buffer area of the target process.

[0051] In this embodiment, referring to Figure 2The diagram illustrates the architecture of the Android graphics system. When the terminal boots up and runs an application for the first time, the target process of the application calls the Surface.dequeueBuffer() interface to request a free GraphicBuffer from the Surface. The Surface then passes the dequeueBuffer request to its underlying BufferQueueProducer. The BufferQueueProducer then allocates an image buffer for the target process from the system memory pool, following the original allocation process. Here, the system memory pool represents the memory resources managed by Gralloc.

[0052] In this embodiment, refer to Figure 2 The original allocation process specifically includes: BufferQueueProducer calls the Gralloc module's interface to request the allocation of an image buffer of a specified size and format. The Gralloc module then calls the DMA / ION driver in the kernel to allocate physical memory. After the DMA / ION driver successfully allocates physical memory, it returns a memory handle. This handle is returned through Gralloc layer by layer and is encapsulated into a GraphicBuffer object and placed in an idle slot of BufferQueueCore. The GraphicBuffer is finally returned to the target process through the original path.

[0053] In this implementation, after the target process obtains the GraphicBuffer, it can use graphics libraries such as Skia or OpenGL ES to draw on the GraphicBuffer. After drawing is completed, it calls Surface.queueBuffer() to return the buffer full of image data to the queue and notifies the consumer, such as SurfaceFlinger, to obtain it. SurfaceFlinger then renders and composites the data using EGL or HardWare Composer (HWC) and finally displays it on the display interface.

[0054] In this embodiment, after drawing is completed on the image buffer, the image buffer is not released immediately. Instead, an image buffer pool is created for the target process, and the allocated image buffer is cached in the image buffer pool and waits for the next allocation.

[0055] S102: When the target process restarts, allocate an image buffer for the target process in the image buffer pool.

[0056] In this implementation, upon the second and subsequent startups of the target process, instead of reallocating a new image buffer from the underlying system memory pool according to the original allocation process, the target process will directly allocate an image buffer from the image buffer pool. This completely avoids the most time-consuming underlying memory allocation process, significantly reducing the call time of `dequeueBuffer()`.

[0057] For example, when the target process is the Launcher process, after the desktop application starts on the terminal, the Launcher process calls the `dequeueBuffer()` interface to pass the dequeueBuffer request to its underlying `BufferQueueProducer`. The `BufferQueueProducer` then follows the original allocation process, requesting an image buffer from the underlying system memory pool to draw and display the desktop image. Subsequently, when the user clicks on an application, the Launcher process switches from the foreground to the background. At this time, the image buffer is not released but cached in the image buffer pool. When the application exits, the Launcher process switches from the background to the foreground and needs to draw the desktop image again. This time, the Launcher process calls the `dequeueBuffer()` interface to pass the dequeueBuffer request to its underlying `BufferQueueProducer`. The `BufferQueueProducer` detects that an available image buffer exists in the image buffer pool and, instead of following the original allocation process, directly allocates an image buffer for the target process from the image buffer pool. Because the image buffer does not need to be repeatedly requested, the target process can complete the drawing and display of the desktop image in a very short time, thus significantly speeding up the application's exit to the desktop and improving operational smoothness.

[0058] In this embodiment, the stuttering rate of 10 apps was tested on a 4GB low-memory Android phone, and the stuttering rate test results of the 10 apps shown in Table 1 can be obtained.

[0059] Table 1 Comparison of App Lag Rate Tests

[0060] As shown in Table 1, the stuttering rates for the disabled and enabled schemes are 6.53% and 2.24%, respectively, indicating an improvement in stuttering rates. In other words, the enabled scheme effectively reduces the repeated allocation of GraphicBuffer during the dequeueBuffer stage, thereby speeding up the rendering process. This is especially noticeable in heavy-load and low-memory environments, significantly reducing stuttering when large applications exit.

[0061] In this embodiment, by creating an independent image buffer pool for the target process upon its first launch, the target process can directly reuse the allocated image buffer from the image buffer pool upon subsequent launches. This completely avoids the lengthy process of repeatedly allocating physical memory, thereby significantly reducing display latency when switching between applications or exiting to the desktop, and improving operational smoothness.

[0062] In one feasible implementation, the resource allocation method may further include the following steps: S201: Obtain target quantity information.

[0063] In this embodiment, the target quantity information can be user-output quantity information, which represents the maximum number of image buffers that the target process is allowed to use, as set by the user.

[0064] In this embodiment, considering that the image buffer in the image buffer pool will not be released, it means that the image buffer will occupy a part of the memory. Therefore, in order to achieve an efficient balance between performance and memory usage, the image buffer pool is set with a quantity attribute, and users are allowed to customize the value corresponding to the quantity attribute of the image buffer pool.

[0065] In this embodiment, the target quantity information can also be determined based on the terminal's performance parameters. These performance parameters may include one or more of the following: screen refresh rate, GPU performance, memory capacity, and the interface complexity of the target process.

[0066] In this embodiment, the target quantity information is positively correlated with the screen refresh rate. For example, for terminals with high refresh rate screens, the target quantity information can be increased to ensure that rendering can keep up with the refresh. The target quantity information is negatively correlated with GPU performance. For example, for terminals with high-end GPUs, a smaller image buffer can be allocated. The target quantity information is positively correlated with memory capacity. For example, for large memory devices (e.g., RAM > 8GB), the target quantity information can be increased to improve the redundancy of the experience. The target quantity information is positively correlated with interface complexity. For example, if the Launcher process has very complex dynamic effects (such as real-time blur, 3D rendering), the target quantity information is increased to meet the rendering effect.

[0067] In a practical implementation, the target quantity information can be obtained by weighting the screen refresh rate, GPU performance, memory capacity, and the interface complexity of the target process; or, the target quantity information can be obtained by inputting the screen refresh rate, GPU performance, memory capacity, and the interface complexity of the target process into a pre-trained recognition model.

[0068] In this embodiment, the step of weighted calculation of screen refresh rate, GPU performance, memory capacity, and target process interface complexity to obtain target quantity information may specifically include: determining a first quantity corresponding to screen refresh rate based on a first mapping relationship between screen refresh rate and quantity; determining a second quantity corresponding to GPU performance based on a second mapping relationship between GPU performance and quantity; determining a third quantity corresponding to memory capacity based on a third mapping relationship between memory capacity and quantity; determining a fourth quantity corresponding to interface complexity based on a fourth mapping relationship between interface complexity and quantity; and performing a weighted summation of the first, second, third, and fourth quantities to obtain target quantity information.

[0069] S202: Update the quantity attribute of the image buffer pool based on the target quantity information.

[0070] It should be noted that the quantity attribute indicates the maximum number of image buffers allowed to be used by the target process. This quantity attribute limits the maximum number of image buffers in the image buffer pool.

[0071] In this embodiment, by updating the quantity attribute of the image buffer pool based on the target quantity information, the display performance of the terminal can be improved while minimizing memory usage, thus achieving an efficient balance between performance and memory usage.

[0072] In the specific implementation, to update the quantity attribute, the quantity attribute of the image buffer pool can be updated to the target quantity information through the target interface. The target interface is a customized interface for the GraphicBuffer quantity, developed specifically for the image buffer pool.

[0073] In this embodiment, by providing a GraphicBuffer quantity customization interface, the number of GraphicBuffers used by the target process can be customized, thereby achieving flexible and stable updates of the quantity attribute.

[0074] In this embodiment, taking a 4GB low-memory Android phone as an example, the number of image buffer pools is set to 3. The memory usage of the Launcher process in the foreground and background is detected, and the memory usage comparison table of Launcher shown in Table 2 can be obtained.

[0075] Table 2 Memory Usage Comparison Table

[0076] When the Launcher is in the foreground: After enabling the scheme, the total number of GraphicBuffers used by the Launcher decreased from 7 to 3. With all GraphicBuffers being used, memory usage showed a decreasing trend (i.e., 140Mb→127Mb), which is in line with expectations.

[0077] When the Launcher is running in the background: Since the GraphicBuffer used is not released, memory usage tends to increase after the scheme is enabled (i.e., 96Mb→105Mb), which is in line with expectations.

[0078] Overall, although caching GraphicBuffer increases the memory usage of the Launcher process, this solution can effectively reduce overall memory usage by customizing the number of GraphicBuffers to rotate.

[0079] In this embodiment, the target quantity information includes first quantity information and second quantity information; the quantity attribute includes a first quantity attribute and a second quantity attribute, wherein the first quantity attribute represents the maximum number of buffers that producers can simultaneously delist and use, and the second quantity attribute represents the maximum number of buffers that consumers can simultaneously acquire and hold; the step of updating the quantity attribute of the image buffer pool based on the target quantity information may specifically include the following steps: updating the first quantity attribute of the image buffer pool based on the first quantity information; updating the second quantity attribute of the image buffer pool based on the second quantity information.

[0080] In this implementation, the producer is typically the target process, and the consumer is typically the system display service, such as SurfaceFlinger.

[0081] It's important to note that the first attribute, `MaxDequeueBufferCount`, refers to the maximum number of buffers that a `BufferQueue` can simultaneously dequeue in the Android system. This parameter limits the number of buffers a target process can acquire at the same time to prevent excessive resource consumption and system crashes. The second attribute, `MaxAcquireBufferCount`, refers to the maximum number of buffers allowed to be acquired from the `BufferQueue`. In the Android system, `BufferQueue` is a crucial component connecting producers and consumers, primarily used for transmitting graphics data. Producers put data into the `BufferQueue`, and consumers retrieve data from it for processing or display. `MaxAcquireBufferCount` defines the maximum number of buffers a consumer can simultaneously acquire from the `BufferQueue`.

[0082] In this implementation, the target quantity information is the sum of the first quantity information and the second quantity information. For example, for the Launcher process, the number of rotating GraphicBuffers can be reduced to 3 to minimize the usage of the GraphicBufferPool (image buffer pool). For instance, MaxDequeueBufferCount can be set to 2, MaxAcquireBufferCount to 1, for a total of 3. This means that the Launcher process can request a maximum of 2 GraphicBuffers for drawing simultaneously, while the consumer can extract a maximum of 1 GraphicBuffer simultaneously.

[0083] In this embodiment, by setting a first quantity attribute and a second quantity attribute for the image buffer pool, users can adjust MaxAcquireBufferCount and MaxAcquireBufferCount according to actual needs, thereby improving the fineness of quantity customization, minimizing memory usage, and achieving an efficient balance between performance and memory usage.

[0084] In one feasible implementation, the step of allocating an image buffer for the target process in the image buffer pool when the target process restarts may specifically include the following sub-steps: S102-1: When the target process restarts, determine whether the image buffer in the image buffer pool meets the update conditions.

[0085] In this embodiment, considering that the image to be drawn by the target process may change, the image buffer cached in the image buffer pool may not be able to meet the drawing requirements of the new image. Therefore, whenever the target process reuses the image buffer in the image buffer pool, the image buffer in the image buffer pool will be updated.

[0086] S102-2: If it is determined that the image buffer in the image buffer pool does not meet the update conditions, allocate an image buffer for the target process in the image buffer pool.

[0087] In this embodiment, if the image buffer is found to be not satisfied with the update condition, it means that the image to be drawn by the target process has not changed. At this time, an image buffer can be directly allocated to the target process in the image buffer pool for image drawing.

[0088] In this embodiment, by updating and verifying the image buffer in the image buffer pool when the target process restarts, the blind reuse of the image buffer in the image buffer pool can be effectively avoided, thereby preventing rendering errors, screen tearing, or even application crashes.

[0089] In a specific implementation, the step of determining whether the image buffer in the image buffer pool meets the update conditions may include: obtaining the request parameters of the target process; if the request parameters and the parameters of the image buffer match, determining that the image buffer does not meet the update conditions; if the request parameters and the parameters of the image buffer do not match, determining that the image buffer in the image buffer pool meets the update conditions.

[0090] In this implementation, the request parameters include one or more of height, width, and pixel format. The width and height are the resolution of the image buffer and must match the size of the image content or layer to be rendered. The pixel format defines how each pixel is stored in memory, such as RGBA_8888, RGBX_8888, RGB_565, etc.

[0091] In this implementation, if the application's (such as the Launcher's) interface changes—for example, switching between portrait and landscape modes, resizing the window, or loading images of different formats—the parameters of its required GraphicBuffer may also change. In this case, parameters can be compared across three dimensions: height, width, and pixel format to determine whether the image buffer in the image buffer pool meets the update conditions. Specifically, if the requested parameters and the image buffer parameters are consistent, it can be determined that the image buffer does not meet the update conditions; conversely, if the requested parameters and the image buffer parameters are inconsistent, it can be determined that the image buffer meets the update conditions.

[0092] In this embodiment, by comparing the request parameters of the target process with the parameters of the image buffer, the update conditions can be accurately determined, thereby ensuring the stability of image rendering.

[0093] In this embodiment, the resource allocation method may further include the following steps: if it is determined that the image buffer in the image buffer pool meets the update conditions, allocate a new image buffer for the target process in the system memory pool; update the image buffer in the image buffer pool based on the new image buffer.

[0094] In this implementation, if the request parameters and the image buffer parameters are found to be inconsistent, it indicates that the image to be drawn by the target process may have changed. In this case, the old image buffer cannot be used to draw the new image. For example, attempting to render a 1080x1920 image into a 720x1280 buffer, or interpreting RGB_565 data using RGBA_8888 format, will inevitably lead to problems. Therefore, allocating a new image buffer for the target process in the system memory pool can effectively accommodate the drawing requirements of new images.

[0095] In this embodiment, after a new image buffer is allocated, the old image buffer in the image buffer pool is released to avoid unnecessary memory occupation. At the same time, the new image buffer replaces the old image buffer to ensure that the target process can continue to reuse the new image buffer in the image buffer pool when it starts up again.

[0096] In this embodiment, by triggering the image buffer update mechanism in the image buffer pool when the request parameters of the target process change, the dynamic and flexible updating of the image buffer can be achieved while ensuring the image drawing needs of the target process for each time.

[0097] It should be noted that in most cases, the interface layout and rendering parameters of the target process are usually stable, with a very high matching success rate, thus resulting in huge performance gains. When the request parameters of the target process change, the image buffer update mechanism can automatically adapt to the parameter changes without developer intervention or process restart.

[0098] Reference Figure 3 This illustrates a schematic diagram of module interaction provided in an embodiment of this application. (Refer to...) Figure 4This diagram illustrates a specific embodiment of the resource allocation method provided in this application. The application (APP), as the initiator of image rendering, can call the BLASTBufferQueue interface to request and submit image buffers. BLASTBufferQueue manages the Surface and the underlying BufferQueue, and is responsible for initializing the entire queue, including setting the maximum number of rotating buffers in the image buffer pool, for example, setting MaxDequeueBufferCount to 2 and MaxAcquireBufferCount to 1. BLASTBufferQueue passes the APP's request to BufferQueueProducer. BufferQueueProducer finds or allocates an available slot in its internal BufferQueueCore. If it detects that the current process is another process besides the Launcher process, it performs physical memory allocation according to the original allocation path by calling the Gralloc module, penetrating the HAL layer and the driver layer (ION / DMA). If the current process is detected as the Launcher process, Gralloc is not called directly. Instead, a request is sent to the GraphicBuffer Pool. The GraphicBuffer Pool uses the getBuffer interface to check in its unordered_map whether the GraphicBuffer corresponding to the slot already exists. If the GraphicBuffer does not exist, it means that the Launcher process is starting for the first time. In this case, the Gralloc module is called to allocate a GraphicBuffer from the system memory pool and cache it in the GraphicBuffer Pool. If the GraphicBuffer exists, it is checked whether the GraphicBuffer in the GraphicBuffer Pool meets the update conditions. If an update is needed, the Gralloc module is called to allocate a new GraphicBuffer from the system memory pool. If no update is needed, the cached GraphicBuffer object is returned directly to the BufferQueueProducer. The BufferQueueProducer returns the allocated GraphicBuffer to the application and enters the rendering, compositing, and display process. Finally, the desktop image corresponding to the Launcher process is displayed on the human-computer interaction interface.

[0099] It should be noted that, continue to refer to Figure 3The static singleton mInstance indicates that there is only one cache pool instance in each process, ensuring global accessibility and management; unordered_map is the data structure of the cache pool, which uses the slot index as the key and the cached GraphicBuffer object pointer as the value. unordered_map is used to represent the one-to-one binding of GraphicBuffer in the image buffer pool with the slot of BufferQueue; the status statistics represent the management module of the image buffer pool. The management module can track the type and quantity of caches and trigger reallocation when necessary (such as when the Buffer parameter changes).

[0100] In this implementation, by creating an independent image buffer pool for the Launcher process, the Launcher can directly reuse the allocated GraphicBuffer from the pool during its second and subsequent startups, completely avoiding the lengthy process of repeatedly allocating physical memory. This significantly reduces display latency and improves operational smoothness. At the same time, by customizing the number of image buffer pools corresponding to the Launcher process, the number of rotating buffers in its BufferQueue can be effectively reduced. While ensuring display quality, this proactively reduces the maximum memory usage of the Launcher process in the foreground, thereby optimizing memory usage and improving resource utilization efficiency.

[0101] To facilitate better implementation of the resource allocation method of this application, this application also provides a resource allocation apparatus based on the above-described resource allocation method. The meanings of the terms used are the same as in the resource allocation method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0102] Based on the same inventive concept, and referring to Figure 5 This application provides a resource allocation device 500, which includes: The caching module 501 is used to allocate an image buffer for the target process in the system memory pool when the target process is first started, and cache the image buffer in the image buffer pool; The allocation module 502 is used to allocate an image buffer for the target process in the image buffer pool when the target process is restarted.

[0103] In one embodiment, the resource allocation device 500 further includes: The information acquisition module is used to acquire target quantity information; The quantity update module is used to update the quantity attribute of the image buffer pool based on the target quantity information; the quantity attribute represents the maximum number of image buffers that the target process is allowed to use.

[0104] In one embodiment, the quantity update module is specifically used to update the quantity attribute of the image buffer pool to the target quantity information through the target interface.

[0105] In one embodiment, the target quantity information includes first quantity information and second quantity information; the quantity attribute includes a first quantity attribute and a second quantity attribute, wherein the first quantity attribute represents the maximum number of buffers that a producer can delist and use simultaneously, and the second quantity attribute represents the maximum number of buffers that a consumer can acquire and hold simultaneously. The quantity update module includes: The first update submodule is used to update the first quantity attribute of the image buffer pool based on the first quantity information; The second update submodule is used to update the second quantity attribute of the image buffer pool based on the second quantity information.

[0106] In one embodiment, the allocation module includes: The condition determination submodule is used to determine whether the image buffer in the image buffer pool meets the update conditions when the target process restarts. The allocation submodule is used to allocate an image buffer for the target process in the image buffer pool if it is determined that the image buffer in the image buffer pool does not meet the update conditions.

[0107] In one embodiment, the resource allocation device 500 further includes: The reallocation module is used to allocate a new image buffer for the target process in the system memory pool when it is determined that the image buffer in the image buffer pool meets the update conditions. The image buffer update module is used to update the image buffers in the image buffer pool based on the new image buffer.

[0108] In one embodiment, the condition determination submodule includes: The parameter acquisition unit is used to acquire the request parameters of the target process; the request parameters include one or more of the following: height, width, and pixel format. The first condition determination unit is used to determine that the image buffer does not meet the update condition if the request parameters and the parameters of the image buffer match. The second condition determination unit is used to determine whether the image buffer in the image buffer pool meets the update conditions when the request parameters and the parameters of the image buffer do not match.

[0109] The technical solution adopted in this application creates an independent image buffer pool for the target process when it is first launched, allowing the target process to directly reuse the allocated image buffer from the image buffer pool during subsequent launches. This completely avoids the lengthy process of repeatedly allocating physical memory, thereby significantly reducing display latency and improving operational smoothness.

[0110] Specific limitations regarding the resource allocation device 500 can be found in the limitations regarding the resource allocation method described above, and will not be repeated here. Each module in the resource allocation device 500 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0111] In addition, this application also provides an electronic device, such as Figure 6 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically: The electronic device may include components such as a processor 601 with one or more processing cores and a memory 602 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 601 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, thereby providing overall monitoring of the electronic device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0112] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.

[0113] In one feasible implementation, the electronic device further includes a power supply 603 that supplies power to the various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0114] In one feasible implementation, the electronic device may further include an input unit 604, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0115] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 602 according to the following instructions, and the processor 601 runs the applications stored in the memory 602, thereby implementing the steps in any of the resource allocation methods provided in the embodiments of this application.

[0116] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0117] In one feasible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0118] In one feasible implementation, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the methods described in any embodiment of this application.

[0119] In one feasible implementation, a computer program product is also proposed, comprising a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

[0120] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0121] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0122] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the resource allocation methods provided in this application.

[0123] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0124] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0125] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the resource allocation methods provided in this application, the beneficial effects that any of the resource allocation methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0126] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0127] The resource allocation method, apparatus, electronic device, and computer-readable storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A resource allocation method, characterized in that, The method includes: When the target process is first started, an image buffer is allocated for the target process in the system memory pool, and the image buffer is cached in the image buffer pool; When the target process restarts, the image buffer is allocated for the target process in the image buffer pool.

2. The resource allocation method according to claim 1, characterized in that, The method further includes: Obtain target quantity information; Based on the target quantity information, the quantity attribute of the image buffer pool is updated; the quantity attribute represents the maximum number of image buffers that the target process is allowed to use.

3. The resource allocation method according to claim 2, characterized in that, The step of updating the quantity attribute of the image buffer pool based on the target quantity information includes: The quantity attribute of the image buffer pool is updated to the target quantity information through the target interface.

4. The resource allocation method according to claim 2, characterized in that, The target quantity information includes first quantity information and second quantity information; the quantity attribute includes first quantity attribute and second quantity attribute, wherein the first quantity attribute represents the maximum number of buffers that a producer can simultaneously delist and use, and the second quantity attribute represents the maximum number of buffers that a consumer can simultaneously acquire and hold. Based on the target quantity information, the quantity attribute of the image buffer pool is updated, including: Based on the first quantity information, the first quantity attribute of the image buffer pool is updated; Based on the second quantity information, the second quantity attribute of the image buffer pool is updated.

5. The resource allocation method according to claim 1, characterized in that, The step of allocating the image buffer for the target process in the image buffer pool when the target process restarts includes: When the target process restarts, it is determined whether the image buffer in the image buffer pool meets the update conditions. If it is determined that the image buffer in the image buffer pool does not meet the update condition, the image buffer is allocated to the target process in the image buffer pool.

6. The resource allocation method according to claim 5, characterized in that, The method further includes: If it is determined that the image buffer in the image buffer pool meets the update condition, a new image buffer is allocated for the target process in the system memory pool. The image buffer in the image buffer pool is updated based on the new image buffer.

7. The resource allocation method according to claim 6, characterized in that, Determining whether the image buffer in the image buffer pool meets the update conditions includes: Obtain the request parameters of the target process; the request parameters include one or more of height, width, and pixel format; If the request parameters and the parameters of the image buffer match, it is determined that the image buffer does not meet the update condition; If the request parameters and the parameters of the image buffer do not match, it is determined that the image buffer in the image buffer pool meets the update condition.

8. A resource allocation device, characterized in that, The device includes: The caching module is used to allocate an image buffer for the target process in the system memory pool when the target process is first started, and cache the image buffer in the image buffer pool; An allocation module is used to allocate the image buffer for the target process in the image buffer pool when the target process restarts.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the resource allocation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the resource allocation method as described in any one of claims 1 to 7.

Images