Mobile device desktop multi-application exclusive window display method based on shared memory
By configuring a contiguous shared memory region and managing state properties on mobile devices, the problem of insufficient memory when displaying multiple application windows is solved, resulting in a smoother display effect.
Patent Information
- Application Number
- CN202511133135.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-13
- Publication Date
- 2025-11-04
AI Technical Summary
When multiple application windows are displayed on mobile devices with limited memory, the existing technology may lead to insufficient resources due to unreasonable memory allocation, resulting in stuttering and screen tearing.
By using a contiguous shared memory region in logical space and configuring its state properties, stored form data is used sequentially by display requests, reducing the memory footprint of each application.
It saves RAM resources, ensures system smoothness, and reduces screen tearing and stuttering when switching applications.
Smart Images
Figure CN120892129A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of window display, in particular to a mobile device desktop multi-application exclusive window display method based on shared memory. BACKGROUND
[0002] A plurality of applications (APPs) such as WeChat, Alipay, etc. can be installed in the operating system of a mobile device, and when an application is started, it needs to be displayed on the screen. This process usually requires a series of interactions between the application, memory, CPU and GPU. The usual interaction process is as follows: when the application is started, the operating system needs to allocate a block of memory space for the application window to store its attribute data (position, layout, etc.); then the CPU obtains the window attribute data from this block of memory, performs related calculations for the initialization of the window, and sends the drawing instructions to the GPU for graphic rendering (frame rendering); after rendering, the GPU stores the rendering results in the frame buffer area of the memory, and finally the display controller refreshes them to the screen for display.
[0003] In the entire process, memory serves as the hub for data transfer and storage, CPU performs logical calculations and instruction generation, and GPU is responsible for graphic rendering. The three work closely together, and any delay in any link can cause display lag. In addition, the frame buffer area, as an area in memory for storing window rendering results, is separate from the storage of application window attribute data.
[0004] In the application window display process, the reasonable allocation of memory (especially the frame buffer area) is one of the main factors affecting the display effect. In reality, due to limited memory resources, when a single application needs to be displayed, the resources are sufficient, and the display of the application window generally does not have problems, but when multiple applications need to be displayed (i.e. in the case of multiple applications), the calculation of each application window needs to go through the interaction process of memory, CPU and GPU, and the results after GPU rendering of each application window need to be stored separately in the respective frame buffer area, which will result in a larger frame buffer area being occupied as the number of application windows increases. This situation does not need to worry about for mobile devices with large memory (smartphones, tablets, etc.), but for mobile devices with small memory (such as Internet of Things devices), if the memory is not allocated reasonably, it will easily cause a problem of insufficient memory. SUMMARY
[0005] To solve the above technical problems, the present application provides a mobile device desktop multi-application exclusive window display method based on shared memory.
[0006] A mobile device desktop multi-application exclusive window display method based on shared memory, comprising the steps of: S100, configure a first memory region and a second memory region which are continuous in logical space, and take the two memory regions as shared memory; S200, configure state attributes for the first memory region and the second memory region respectively; S300, when displaying a window of an application, first initiate a display request to a window manager, and check state attributes of shared memory according to the display request; S400, if the shared memory has a free state, configure a memory region in the free state to a window of an application corresponding to the display request, and mark state attributes of the memory region correspondingly; otherwise, put the display request into an application waiting queue; S500, display a processed window in a memory region, and mark state attributes of the memory region correspondingly.
[0007] Preferably, in step S200, the state attributes include a holding state, an active state and a free state, wherein the holding state indicates that the shared memory has been occupied, and an application window data stored in the shared memory is currently displayed on a screen; the active state indicates that the shared memory has been occupied, and data in the shared memory is waiting to be displayed on the screen by a display controller; and the free state indicates that no application window data is stored in the shared memory.
[0008] Preferably, in step S400, if state attributes of the first memory region are in a free state, the first memory region is configured to a window of an application corresponding to the display request, and the state attributes of the first memory region are marked as an active state.
[0009] Preferably, if the state attributes of the first memory region are in a non-free state, state attributes of the second memory region are checked, if the state attributes of the second memory region are in a free state, the second memory region is configured to a window of an application corresponding to the display request, and the state attributes of the second memory region are marked as an active state.
[0010] Preferably, if the state attributes of the first memory region and the second memory region are both in a non-free state, the display request is put into an application waiting queue.
[0011] Preferably, in step S500, when a processed window in a memory region in an active state is displayed, the state attributes of the memory region are marked as a holding state.
[0012] Preferably, step S600 is included, after switching an application, data in a memory region in a holding state is emptied, and the state attributes of the memory region are marked as a free state.
[0013] Preferably, the memory region whose state attribute is changed from holding state to idle state is configured to the window of the application at the first position in the application waiting queue, and the state attribute of the memory region is marked as active state.
[0014] The application has the advantages that: the application initiates display request for all applications first, and then uses the available shared memory in sequence according to the request order, and the data after rendering can be displayed only after being stored in one of the two shared memories, so that the application not only saves the RAM resource occupation, but also guarantees the fluency of the system and reduces the screen tearing and lag phenomenon during application switching. BRIEF DESCRIPTION OF DRAWINGS
[0015] The application will be further described below with reference to the drawings; Figure 1 is a system flowchart of the application. DETAILED DESCRIPTION
[0016] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the application.
[0017] As shown in Figure 1 , the application aims to provide a mobile device desktop multi-application exclusive window display method based on shared memory, which can save the RAM resource occupation, guarantee the fluency of the system, and reduce the screen tearing and lag phenomenon during application switching when the desktop operating system of the mobile device switches and displays the multi-application window.
[0018] Specifically, When the application is started, the application window needs to be displayed on the screen. In this embodiment, the system allocates a two-piece memory region which is continuous in logical space, i.e., a first memory region and a second memory region, to the window manager, and uses the first memory region and the second memory region as two shared memories, both of which are used to store the data after rendering of the application window.
[0019] The state attribute is configured for the first memory region and the second memory region, and in this embodiment, the state attribute has three types: (1) holding state, indicating that the shared memory is occupied, and the application window data stored in the shared memory is displayed on the screen; (2) active state, indicating that the shared memory is occupied, and the data is waiting to be displayed on the screen by the display controller; and (3) idle state, indicating that the shared memory can be used to store the application window data.
[0020] When the screen displays the window of the application 1, the display request is first sent to the window manager. After receiving the display request, the window manager first checks the use state of the first memory region. If the use state of the first memory region is the idle state, the window manager sends the address of the first memory region to the application 1. After receiving the address, the application window 1 stores the window data rendered by the GPU or the CPU in the first memory region. If the use state of the first memory region is not the idle state, that is, the holding state or the active state, indicating that the first memory region is occupied by other applications, the window manager checks the state attribute of the second memory region.
[0021] If the state of the second memory region is the idle state, the window manager sends the address of the second memory region to the application 1. After receiving the address, the application window 1 stores the window data rendered by the GPU or the CPU in the second memory region. If the use state of the second memory region is also not the idle state, that is, the holding state or the active state, indicating that the second memory region is occupied by other applications, the window manager rejects the display of the window of the application 1, and puts the display request of the application 1 into the application queue for queuing and waiting (it should be noted that the queue is required by any operating system, and is used for inter-process communication. The memory occupation solved in this embodiment is mainly the memory occupied by the window application, and is not the same as the queue memory occupation problem).
[0022] After the above steps, the system displays the window of the application 1 on the screen through the display controller, or puts the display request of the application 1 into the application queue for queuing and waiting. When the application 2 needs to be displayed, the window manager repeats the above steps.
[0023] It should be noted that when the shared memory is empty, the state attribute is marked as the idle state. If the window data is stored in the shared memory, the state attribute of the shared memory is synchronously marked as the active state. If the window data in the shared memory is displayed on the screen, the state attribute of the shared memory is synchronously marked as the holding state. Similarly, if the window data in the shared memory is emptied, the state attribute of the shared memory is synchronously marked as the idle state.
[0024] If the application 1 occupies the first memory region, the first memory region is in the holding state, and the screen displays the window of the application 1; at this time, the application 2 occupies the second memory region, and the second memory region is in the active state. When the application 3 sends a display request to the window manager, the window manager repeats the above steps of querying the shared memory state attribute; at this time, since the first memory region and the second memory region are both occupied, the window manager rejects the display request of the application 3 and puts it into the application waiting queue.
[0025] When the display of the application 1 is switched to the display of the application 2, the display controller receives the memory address of the second memory region sent by the window manager, obtains the data of the application 2 from the memory address, and modifies the state attribute of the second memory region from the active state to the holding state. After the window of the application 2 is displayed on the screen, the window manager cleans up the data in the first memory region and sets the state of the first memory region to the idle state. Then, the window manager sends the address of the first memory region to the application 3 in the application waiting queue; after the application 3 receives the address of the first memory region sent by the window manager, the application 3 writes the window rendering data of the application 3 into the first memory region.
[0026] In the embodiment, the application window displayed on the screen always occupies only the first memory region and the second memory region, and the two memory regions are shared and used alternately, so that the display of multiple applications is realized, and the situation that each application occupies memory to cause insufficient memory is avoided. Therefore, the application saves the occupation of RAM resources and ensures the fluency of the system and reduces the tearing and lag phenomenon during application switching.
[0027] It is apparent for those skilled in the art that the present application is not limited to the details of the above exemplary embodiments, but can be implemented in other concrete forms without departing from the spirit or essential characteristics of the present application. Therefore, the embodiments should be considered in all aspects as illustrative and not restrictive, and the scope of the present application is defined by the appended claims rather than the above description, and all changes falling within the meaning and range of equivalents of the claims are intended to be embraced therein.
Claims
1. A method for displaying multiple application-specific windows on a mobile device desktop based on shared memory, characterized in that, Including the following steps: S100: Configure a first memory region and a second memory region that are contiguous in the logical space, and treat the two memory regions as shared memory; S200: Configure status attributes for the first memory region and the second memory region respectively; S300. When displaying the application's form, first send a display request to the window manager, and check the status attributes of the shared memory according to the display request; S400. If the shared memory is in a free state, the free memory area is configured to the window of the application corresponding to the display request, and the status attribute of the memory area is marked accordingly. Otherwise, place the display request in the request waiting queue; S500: Display the processed form in the memory area, and mark the status attributes of the memory area accordingly.
2. The method for displaying multiple applications' dedicated windows on a mobile device desktop based on shared memory according to claim 1, characterized in that: In step S200, the status attributes include a held state, an active state, and an idle state. The held state indicates that the shared memory has been occupied and the current screen display is the application window data stored in the shared memory. The active state indicates that the shared memory has been occupied and is waiting for the display controller to display the data in the shared memory on the screen. The idle state indicates that there is no application window storing data in the shared memory.
3. The method for displaying multiple applications with a dedicated window on a mobile device desktop based on shared memory, as described in claim 1, is characterized in that: In step S400, if the status attribute of the first memory region is idle, the first memory region is configured to the window of the application corresponding to the display request, and the status attribute of the first memory region is marked as active.
4. The method for displaying multiple applications with a dedicated window on a mobile device desktop based on shared memory, as described in claim 1, is characterized in that: If the status attribute of the first memory region is non-idle, then check the status attribute of the second memory region. If the status attribute of the second memory region is idle, then configure the second memory region to the window of the application corresponding to the display request, and mark the status attribute of the second memory region as active.
5. The method for displaying multiple applications' dedicated windows on a mobile device desktop based on shared memory according to claim 1, characterized in that: If both the first memory region and the second memory region are in a non-idle state, then the display request is placed in the request waiting queue.
6. The method for displaying multiple applications' dedicated windows on a mobile device desktop based on shared memory according to claim 1, characterized in that: In step S500, when the processed form in the active memory area is displayed, the state attribute of the memory area is marked as held.
7. The method for displaying multiple applications with a dedicated window on a mobile device desktop based on shared memory, as described in claim 1, is characterized in that: Including step S600, after switching applications, the data in the memory area with the holding state is cleared and the state attribute of the memory area is marked as idle.
8. A method for displaying multiple applications' dedicated windows on a mobile device desktop based on shared memory, as described in claim 7, characterized in that: Configure the memory region whose status attribute has been changed from held to idle to the form of the application that is first in the application waiting queue, and mark the status attribute of the memory region as active.