Method, system and device for implementing multi-process switching display and medium

Abstract

The application provides a multi-process switching display implementation method, system, device and medium, and belongs to the small screen device control field. The method comprises the following steps: during the running of a process manager, it is listened whether a starting request of a target application program is received; if the starting request is received, the process manager is controlled to pause the picture rendering output of itself and save the interface state of the process manager, a sub-process of the target application program is created and run, and the sub-process is enabled to obtain the display output control right; when it is detected that the target application program exits the running, the display output control right of the process manager is restored, and the picture rendering output is continued based on the interface state. The application efficiently and stably switches the picture, and improves the use experience.

Description

Technical Field

[0001] This invention relates to the field of small-screen device control, specifically to a method, system, device, and medium for implementing multi-process switching display. Background Technology

[0002] With the widespread use of embedded devices and mobile terminals, the demand for small-screen devices is growing. Users are placing higher demands on the interactive experience of the graphical user interface (UI) of small-screen devices. Although many low-cost small-screen devices are equipped with touch displays, their low-cost embedded Linux systems are generally limited by hardware resources (such as CPU clock speed and memory capacity) and cannot run multi-window display server protocols commonly used in desktop Linux systems, such as X11 and Wayland.

[0003] To address the aforementioned hardware limitations, the "single-process, single-UI" approach has become the mainstream development choice for low-cost embedded Linux systems. This approach runs only one UI process at a time, with all system functions implemented through "page switching" within this process. Global resources such as fonts, input devices, and cache rendering are shared uniformly, eliminating the overhead of inter-process communication and scheduling, and placing extremely low demands on embedded hardware resources. Another common approach is the "process completion exit + restart" approach, which uses a script as a unified scheduler. The startup and exit of all UI programs are managed by the script, thereby reducing the coupling between functional modules.

[0004] However, these solutions still have significant shortcomings: the "single-process, single-UI" solution highly couples all functional modules to a single process, meaning that a failure in any module could cause the entire UI system to crash, posing a single point of failure risk, and it is difficult to integrate third-party UI programs developed by different teams and with different technology stacks. While the "process exit + restart" solution achieves decoupling at the process level, each switch requires completely terminating the current program and restarting the target program, resulting in repeated initialization of UI graphics context, control resources, etc. This not only causes significant startup delays and consumes additional resources, but also leads to the loss of user operation state and interface context information, seriously impairing the continuity of interaction and user experience. Summary of the Invention

[0005] In view of this, it is necessary to provide a method, system, device and medium for multi-process switching display to solve the technical problems of untimely response and resource waste when switching between different UI programs in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a method for implementing multi-process switching display, comprising: While the process manager is running, it listens for whether a startup request from the target application is received; If the startup request is received, the process manager is controlled to pause its own screen rendering output and save the interface state of the process manager, and a child process of the target application is created and run, so that the child process obtains control over the display output. Upon detecting the exit of the target application, the process manager regains control of the display output and continues to render and output the screen based on the interface state.

[0007] One possible implementation also includes: When a change in the state of a control on the main interface of the process manager is detected, the screen area where the changed control is located is marked as an invalid area; When updating the screen of the process manager, the rendering data for the invalid area is submitted to the display buffer to redraw the invalid area.

[0008] In one possible implementation, controlling the process manager to pause its own screen rendering output and save the process manager's interface state includes: By switching the invalid region marker to disabled through the process manager, the process manager stops submitting new rendering data to the display buffer, thus pausing its screen rendering output, while running in the background and storing the interface state in the running memory.

[0009] In one possible implementation, the process of launching the target application includes: The process manager is controlled to create a full-screen overlay control to block input events to the main interface of the process manager during the execution of the target application.

[0010] One possible implementation also includes: When the full-screen overlay control detects a preset return gesture, it controls the process manager to send a termination signal to the target application, causing the target application to exit.

[0011] In one possible implementation, restoring the process manager's control over display output and continuing screen rendering based on the interface state includes: Control the process manager to delete the full-screen overlay control; The process manager is controlled to restore the invalid area marking function, marking the entire display area of ​​the main interface as invalid, and the screen of the main interface is redrawn based on the interface state.

[0012] One possible implementation also includes: If the target application fails to start, the process manager is controlled to abort the process of switching display control.

[0013] Secondly, the present invention also provides a system for implementing multi-process switching display, comprising: The monitoring and judgment module is used to listen for whether a startup request from the target application is received during the operation of the process manager; The processing module is used to, upon receiving the startup request, control the process manager to pause its own screen rendering output and save the interface state of the process manager, create and run the child process of the target application, and enable the child process to obtain display output control. The control module is used to detect when the target application exits runtime, restore the display output control of the process manager, and continue to render and output the screen based on the interface state.

[0014] Thirdly, the present invention also provides a small-screen device, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the multi-process switching display implementation method described in any of the above implementations.

[0015] Fourthly, the present invention also provides a computer-readable storage medium for storing a computer-readable program or instructions, wherein when the program or instructions are executed by a processor, they are able to implement the steps in the multi-process switching display implementation method described in any of the above implementations.

[0016] The beneficial effects of this invention are as follows: The multi-process switching display implementation method provided by this invention pauses its own screen rendering output and saves the interface state of the process manager. Since all interface states of the process manager (control tree, attributes, variables) are completely saved throughout the process, after the child process ends, the process manager will quickly and accurately render its main interface into the frame buffer based on these saved interface state data, thereby seamlessly restoring display control of the screen. The user will visually perceive an instant switch from the target application interface back to the main interface of the process manager, and the main interface will maintain the state before the switch, eliminating the lag when switching interfaces between multiple UI processes and providing a smooth user experience. Moreover, since all interface states of the process manager are completely preserved, the main interface of the process manager seen by the user after returning from the target application interface is exactly the same as when leaving, allowing for direct execution of the next operation. This ensures the continuity and efficiency of multitasking operations on small-screen devices and significantly improves the user experience. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic flowchart of an embodiment of the multi-process switching display method provided by the present invention; Figure 2 A flowchart illustrating another embodiment of the multi-process switching display method provided by the present invention; Figure 3 This is a schematic diagram of an embodiment of the process manager of the present invention, showing the process from touch screen input to display screen output. Figure 4 This is a schematic diagram of an invalid region of the present invention; Figure 5 This is a schematic diagram of the full-screen coverage control of the present invention; Figure 6 A flowchart illustrating another embodiment of the multi-process switching display method provided by the present invention; Figure 7 A flowchart illustrating another example of the multi-process switching display implementation method provided by the present invention; Figure 8 This is a schematic diagram of an embodiment of the small-screen device provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0020] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] With the widespread adoption of applications such as the Internet of Things (IoT), industrial control, and smart terminals, users are placing higher demands on the UI interaction experience of embedded small-screen devices (such as POS machines and printers). While low-cost embedded small-screen devices generally feature touchscreens, improvements in their interactive experience are limited by significant hardware shortcomings: low CPU clock speeds, small memory capacity, and a lack of high-performance graphics cards. These limitations prevent them from meeting the operational requirements of independent display server processes and from supporting the rendering of multi-window UI programs. To address this hardware limitation, low-cost embedded platforms generally adopt a "single-process, single-UI" approach, meaning only one UI process is launched at a time. Even if the front end presents a multi-window or multi-functional page, the background logic is maintained and rendered uniformly by this single process. To further reduce resource consumption, the UI process of these devices typically accesses the display hardware frame buffer directly to reduce the performance overhead of data copying. If multiple UI processes update the display buffer simultaneously, it can lead to problems such as screen flickering and display errors; simultaneously, touchscreen input events may be received by multiple UI processes at the same time, causing errors in the interaction logic. Therefore, in low-cost embedded systems, the essence of "single-process, single-UI" is to force only one UI process to run at a time at the hardware level to ensure the stability of display and interaction. However, a completely single-process, multi-interface switching mode, which highly couples all functional modules into a single process and implements different functions through internal page switching, has low resource consumption and low switching latency, but it has a single point of failure risk. That is, the crash of any module will cause the entire process to exit, and it has poor scalability, making it difficult to integrate third-party UI programs developed from different technology stacks. The process exit + restart mode manages the process lifecycle of multiple independent UI applications through an external script scheduler. In this mode, the currently running program A will completely exit when the target program B is launched. After program B finishes running, program A will be restarted to restore the interface. Although process decoupling is achieved, program A needs to reinitialize common basic resources such as UI graphics context, frame buffer, and control resource pool every time it starts. The creation of these resources not only consumes valuable CPU computing power and memory, but also significantly prolongs the program startup time. The repeated creation of resources leads to low startup efficiency, which can easily cause poor user experience such as interface switching lag and response delay on low-cost embedded platforms with limited hardware resources. Moreover, the scenario where program A triggers program B to start (such as when a user clicks a specific button to jump) often depends on a specific interface context (such as the currently displayed parameter value, the selected state of a control, the page jump path, etc.). After program A completely exits, its runtime interface state and user operation context will be completely lost. The loss of state leads to a break in the continuity of interaction. Even if it is restarted later, it cannot be restored to the state before the switch, causing the user to need to perform operations again to return to the target interface.In summary, the process exit + restart mode suffers from repeated resource initialization, startup delays, and state loss, which affect system performance and user experience.

[0024] To address the aforementioned problems, this invention provides a method, system, device, and medium for implementing multi-process switching display, which will be described below.

[0025] Before demonstrating the embodiments, the following terms will be explained.

[0026] LVGL (Light and Versatile Graphics Library) is a free and open-source embedded graphics library specifically designed for creating beautiful, high-performance graphical user interfaces (GUIs) on resource-constrained microcontrollers (MCUs) and microprocessors (MPUs).

[0027] UI (User Interface) is the interface through which people exchange information with machines, systems, software, or applications.

[0028] Figure 1 A flowchart illustrating an embodiment of the multi-process switching display method provided by the present invention is shown below. Figure 1 As shown, the implementation methods for multi-process switching display include: S101. While the process manager is running, listen for whether a startup request from the target application is received.

[0029] Specifically, this invention applies to small-screen devices in low-cost embedded systems. Small-screen devices include POS machines, printers, smartwatches, etc. The process manager (i.e., UI launcher) is a lightweight, LVGL-based system-level management framework that implements a single-process, single-UI architecture, running persistently in the background. The target application refers to the UI application launched and managed by the process manager (UI launcher). Taking a handheld printer as an example, the target application includes a print job management app and a printer testing app on the handheld printer. The process manager supports a configurable double-buffering mechanism and partial refresh functionality. The process manager and the target application are completely independent applications.

[0030] S102. If the startup request is received, control the process manager to pause its own screen rendering output and save the interface state of the process manager, create and run the child process of the target application, and enable the child process to obtain display output control.

[0031] Specifically, users can initiate a launch request for the target application by clicking its icon. Alternatively, the launch request can be automatically initiated when preset trigger conditions are met (such as a preset fault type). For example, with a handheld printer, if a fault occurs during printing, a pop-up window for the printer test app (as the target application) can be automatically displayed to initiate a launch request.

[0032] When the process manager receives a launch request from the target application, it pauses its own screen rendering, effectively "freezing" the current main interface on the screen and saving the state of the already loaded interface. Next, the process manager creates a subroutine to independently launch and run the target application. The process manager relinquishes its control over the display output and transfers this control to the target application's subroutine, granting it control over the display output. Once in control, the subroutine independently reads touch input events, writes rendering data about the target application to the frame buffer, and performs screen rendering. This switches the user's view from the process manager's main interface to the target application's interface.

[0033] S103. Upon detecting the exit of the target application, restore the display output control of the process manager and continue to render and output the screen based on the interface state.

[0034] Specifically, during the target application's execution, the process manager monitors whether the target application has exited. Once exit is detected, the process manager regains control of the display output and rewrites its rendering data to the frame buffer. Starting from the saved interface state, it continues rendering and displaying the screen based on the rendering data. During system operation, only one program can update the display buffer at any given time, ensuring that the screen is fully controlled by the currently running program. Furthermore, since embedded devices generally do not dynamically adjust display parameters, the process manager needs to read relevant parameters from the driver and adapt them during startup to match the display parameters (such as color depth and resolution) of the small-screen device.

[0035] In this embodiment, the present invention pauses its own screen rendering output and saves the interface state of the process manager. Since all interface states of the process manager (control tree, attributes, variables) are completely saved throughout the process, after the child process ends, the process manager will quickly and accurately render its main interface to the frame buffer based on these saved interface state data, thereby seamlessly restoring display control of the screen. The user will visually perceive an instant switch from the target application interface back to the main interface of the process manager, and the main interface will maintain the state before the switch, eliminating the lag when switching interfaces between multiple UI processes and providing a smooth user experience. Moreover, since all interface states of the process manager are completely preserved, the main interface of the process manager seen by the user after returning from the target application interface is exactly the same as when leaving, allowing for direct execution of the next operation. This ensures the continuity and efficiency of multitasking operations on small-screen devices, greatly improving the user experience.

[0036] In some embodiments of the present invention, such as Figure 2 As shown, it also includes: S201. When a change in the state of a control on the main interface of the process manager is detected, the screen area where the changed control is located is marked as an invalid area. S202. When updating the screen of the process manager, the rendering data for the invalid area is submitted to the display buffer to redraw the invalid area.

[0037] Specifically, the process manager is an LVGL program developed based on the LVGL graphics library. The native capabilities of LVGL programs only support rendering and interaction for a single target UI application, lacking application state saving and fast switching functionality. The complete process of the process manager from touchscreen input to display screen output is as follows: Figure 3 As shown, the touchscreen captures user touch operations, which are then converted into standard input events by the touchscreen driver. These input events are transmitted to the process manager and received. The process manager performs action recognition on the input events, parsing them into specific interactive actions such as button clicks or double clicks, and interface swipes, and calls the corresponding control's callback function for logical processing. The callback function executes the business logic corresponding to the touchscreen operation. If the operation involves changes to the display of page controls (such as text updates, button press animations, etc.), the relevant layer content and control properties are updated synchronously. Figure 4As shown, the process manager marks the display area that needs updating as an invalid area. When the state of a control in the main interface of the process manager changes, it only marks a local area of ​​the screen where the control is located as an invalid area and enables the invalid area marking function, making this invalid area valid. In this way, the display device only redraws the invalid area (instead of the entire screen), thereby saving hardware resources. For example, when button 1 is pressed, the system marks a rectangular area slightly larger than button 1 as an invalid area. In subsequent refreshes, only this area is re-rendered to update the display state of the control, such as color and size. The invalid area is related to the control and can be estimated based on the display effect. For example, when a button is pressed, the button's color or style changes, giving the user the UI effect of the button being operated. In this case, the invalid area is a rectangle slightly larger than the actual size of the button. For example, if the input content of a text box changes, the invalid area is the rectangular area inside the text box where the text changes. This area may be smaller than the size of the text box. Simply put, the invalid area is the area of ​​the screen that needs to change in the next frame. The process manager only redraws the invalid area, that is, it only performs a partial refresh of the invalid area of ​​the entire screen area to reduce the amount of data operation. The process manager periodically checks for invalid region markers using a timer, re-renders invalid regions that need updating, and writes them to the display cache, ultimately completing the interface update.

[0038] In this embodiment, only a small portion of local areas that need to change are marked as invalid areas, and image rendering and redrawing are only performed on invalid areas, which greatly reduces the amount of data processing and bandwidth usage, and improves rendering efficiency.

[0039] In some embodiments of the present invention, controlling the process manager to pause its own screen rendering output and saving the interface state of the process manager includes: By switching the invalid region marker to disabled through the process manager, the process manager stops submitting new rendering data to the display buffer, thus pausing its screen rendering output, while running in the background and storing the interface state in the running memory.

[0040] Specifically, by disabling the invalid region marker in the process manager, even if the control state of the main interface of the process manager changes, the screen will not refresh. The last complete frame of the main interface appears static to the user, as if "frozen." Crucially, disabling the invalid region marker does not affect the process manager's running state in memory. The process manager continues to run normally, thus fully and dynamically preserving its interface state (including the control tree data structure, all control attribute values, variable context, and unfinished logic processing tasks). All internal calculations and logic of the process manager occur quietly in the background; only the final calculation result (the new screen) is no longer submitted to the display buffer, thus stopping the output of the process manager's rendering data to the physical screen for display. In other words, all UI changes are calculated and updated in the background in memory, but there are no visual changes on the screen.

[0041] In this embodiment, by disabling the invalid region marker and keeping the process manager's interface state unchanged in memory, when regaining control of the process manager's display output, there is no need to re-execute the process manager's initialization process. Simply re-enabling the disabled invalid region marker and triggering a full-screen redraw allows for an efficient and smooth transition from the target application's interface back to the process manager's main interface. Because the process manager's interface state is completely saved in memory during the restoration of display output control, the user's interface after restoration is identical to when leaving the process manager. All unfinished operations related to the process manager can be seamlessly continued. This is particularly suitable for embedded small-screen devices that require frequent switching between different functions (such as POS machines switching between different business functions). It achieves smooth and continuous process screen switching on resource-constrained hardware platforms, improving the efficiency and user satisfaction of embedded small-screen devices.

[0042] In some embodiments of the present invention, the process of launching the target application includes: The process manager is controlled to create a full-screen overlay control to block input events to the main interface of the process manager during the execution of the target application.

[0043] Specifically, such as Figure 5As shown, the full-screen overlay control M1 (i.e., the full-screen background curtain) is a rectangular UI control located at the top layer. Its size matches the full-screen resolution of the monitor, and it features a borderless, non-rounded corner design, completely covering all controls at the bottom layer of the screen. The full-screen overlay control M1 has the highest event response priority. The visual appearance of the full-screen overlay control M1 does not require special settings; it can use a transparent layer or the default color. This is because the full-screen overlay control M1 works in conjunction with the invalid region flag disabling mechanism of the process manager. In this mode, the full-screen overlay control M1 is not rendered or displayed on the screen by the process manager. The full-screen overlay control M1 and the disabled invalid region flag work simultaneously. The full-screen overlay control M1 appears in a state where refresh is disabled. Although the full-screen overlay control M1 is visually invisible, it is located at the top layer, its function being to obscure the functional controls of the process manager's main interface. This ensures that any touch operations by the user during the target application's runtime will not be misrecognized and responded to by the controls in the process manager's background, thus completely avoiding interaction conflicts. The full-screen overlay control M1 is essentially a basic rectangular control (lv_obj) in LVGL. While the full-screen overlay control M1 is active, touch event input is no different from other ordinary controls, and multi-touch gestures are also supported. Because the full-screen overlay control M1 is located on the topmost layer, it will obscure the touch events of all other controls. Switching between layers does not require clearing video memory. In terms of timing, only one program is updating the screen at any given time, preventing screen flickering.

[0044] Because the full-screen overlay control M1 is located at the top layer and covers the entire screen, all raw input events from the touchscreen will be captured by the full-screen overlay control M1 first. During the running of the target application, input events to the main interface of the process manager can be blocked. In this way, all function buttons, list items and other lower-level controls on the process manager's own interface are isolated or blocked and can no longer receive any touch input. This completely avoids the risk of users accidentally triggering the background logic of the process manager due to accidental touches during the running of the target application, and avoids erroneous responses to touch actions in the controls of the process manager after switching to the target application.

[0045] In this embodiment, the present invention uses a full-screen overlay control M1 to block input events to the main interface of the process manager during the target application's runtime, ensuring that the foreground target application responds exclusively and without interference to user interaction intentions, thus improving the determinism and reliability of interaction when switching between different processes. By creating a full-screen overlay control M1 during the target application's runtime, there is no need to modify the input driver of the small-screen device's operating system or improve the target application, reducing the cost of small-screen devices. Furthermore, since concurrent operations of multiple UI processes on the Frame Buffer (display buffer) can cause screen flickering and display errors, and touch events may be responded to by multiple programs simultaneously, the present invention uses a full-screen overlay control M1 with invalid area markers disabled, effectively employing a time-sharing switching mechanism to achieve UI process switching. Based on the process manager, the switching process is ensured to be stable and fast, achieving smooth and consistent process screen switching on resource-constrained hardware platforms, improving the efficiency and user satisfaction of embedded small-screen devices.

[0046] In some embodiments of the present invention, it further includes: When the full-screen overlay control M1 detects a preset return gesture, it controls the process manager to send a termination signal to the target application, causing the target application to exit.

[0047] Specifically, the full-screen overlay control M1 is essentially a basic rectangular control (lv_obj) in LVGL. By enabling the LVGL gesture recognition component (lv_gesture) for the full-screen overlay control M1, listeners for touch events can be registered. These listeners monitor whether a preset back gesture (such as a long press or a specific swipe gesture) is detected as a trigger condition for returning to the task manager from the target application. Developers can also extend this with custom gestures (such as a three-finger swipe down) as a trigger condition for returning to the task manager from the target application.

[0048] During the target application's execution, the full-screen overlay control M1 only monitors and listens for preset back gestures. These gestures are monitored and responded to by the full-screen overlay component. If the full-screen overlay control M1 detects a preset back gesture, it sends a termination signal to the target application via the process manager. Upon receiving the termination signal, the target application actively exits. It's important to note that other gestures or interactions within the target application (only one target application is supported at a time) are monitored and implemented internally by the target application itself, unaffected by the UI display. The screen input devices (display buffer, display screen) are shared read-only resources for all UI programs (including the process manager and the target application). The full-screen overlay control M1 does not affect or rewrite the underlying system input event propagation path or read / write logic. All UI programs, including the process manager and the target application, independently open and monitor the same physical input device / dev / input / eventX (where X is a sequence number 0, 1, 2, etc.) in read-only mode, concurrently receiving the raw input event stream.

[0049] In this embodiment, by combining the full-screen coverage control M1 with the return gesture recognition, the process manager (current process) actively sends a termination signal to the target application (child process) after detecting the return gesture. This provides a channel for returning from the target application's interface to the process manager's main interface, significantly improving the availability and reliability of small-screen devices. Furthermore, it ensures that all system resources (memory, file descriptors, etc.) occupied by the target application are promptly reclaimed when the user intends to exit or when the target application malfunctions, thereby improving the long-term stability and resource utilization of small-screen devices.

[0050] In some embodiments of the present invention, such as Figure 6 As shown, restoring the display output control of the process manager and continuing screen rendering output based on the interface state includes: S601. Control the process manager to delete the full-screen overlay control M1; S602. Control the process manager to restore the invalid area marking function, mark the entire display area of ​​the main interface as invalid, and redraw the screen of the main interface based on the interface state.

[0051] Specifically, there are three trigger scenarios for the exit of a child process of the target application and its return to the process manager: The first is normal exit, where the user clicks the "Exit" button on the target application interface. The second is abnormal exit, where the child process of the target application crashes due to memory errors or other issues. The third is active termination, where the user triggers a custom back gesture (such as swiping or long-pressing) or presses the physical back button, and the process manager sends a termination signal (such as SIGKILL) to the target application process. After the target application process exits, the process manager performs the following recovery operations: It captures the exit status of the target application's child process through a listening thread; after confirming that the child process has terminated, it deletes the full-screen overlay control M1 to restore the touchscreen responsiveness of the process manager's interface controls and restores the "invalid area marker" function. Additionally, it marks the entire display area of ​​the process manager's main interface as completely invalid and restarts the LVGL automatic redraw mechanism based on the previously stored interface state to initiate a complete redraw. In this process, the interface state used for redrawing is all the data stored in the runtime memory when the interface was "frozen" in the previous embodiment. After the rendering engine completes the pixel calculations for the entire screen based on the previously stored interface state, it submits the generated complete frame image data and writes it to the frame buffer. In this way, the screen display content is completely and quickly replaced from the last frame of the target application to the process manager's main interface, which is exactly the same as when the user left. At this point, the display output control is returned to the process manager. It should be noted that during the restoration of the display cache from the target application state to the process manager's interface state, since the process manager is always running in the background, the complete information of its LVGL layers and controls is preserved. When returning to the process manager's main interface, the page can be quickly rendered and restored based on the existing control data. At the same time, the process manager's parent thread continues to work normally in the background, and the process manager's functions that rely on the LVGL timer are not affected in any way.

[0052] In this embodiment, the present invention, through restoration operations such as deleting the full-screen overlay control M1, marking the entire area of ​​the main interface as invalid, and redrawing the main interface screen based on the interface state, can instantly restore the process manager main interface based on the precise state saved before freezing. Users will not perceive any black screen, white screen, or loading delay, achieving a seamless transition visually and in terms of application interaction, greatly improving the user experience and smoothness. Because the restored interface state is a precise snapshot of the state at the time of exit, all user interaction contexts are completely preserved. This not only achieves a seamless transition visually and in terms of application interaction, avoiding the need for users to re-operate, but also greatly improves operational efficiency and fault tolerance.

[0053] In some embodiments of the present invention, it further includes: If the target application fails to start, the process manager is controlled to abort the switching process, and the process manager's display output control is restored, and the screen rendering output continues based on the interface state.

[0054] Specifically, if the executable file of the target application is corrupted, missing, or lacks sufficient permissions, the target application will fail to start. A notification message of the target application's startup failure will be sent to the process manager. Upon receiving the notification message, the process manager will immediately stop the subsequent switching process in S102 (including controlling the process manager to pause its own screen rendering output and saving the process manager's interface state, creating and running the child process of the target application, and giving the child process display output control). Then, referring to S601 to S602, the process manager will restore the display output control and continue screen rendering output based on the interface state.

[0055] In the traditional model, the process manager (parent process) needs to completely exit and wait for the target application's child processes to finish before starting it. For example, Figure 7 This is a schematic diagram of the process manager's processing flow based on LVGL. For example... Figure 7As shown, the initialization phase involves: starting the process manager, initializing and rendering the main interface, and responding to touch events. The target application launch phase involves clicking the target application's icon, disabling the invalid region marker, launching a full-screen background and recognizing touch actions, creating a child process and monitoring its status, launching the target application through the child process, initializing its interface, rendering it, and responding to touch events automatically. The return to the process manager's main interface phase involves triggering a return gesture, sending a termination signal to terminate the target application, exiting the child process, obtaining the child process's exit status, deleting the full-screen background, restoring the invalid region marker, marking the full screen as an invalid region, and restoring the main interface. In summary, the initialization phase only starts the process manager, completes its own interface initialization and full-screen display, and enters touch event listening mode, waiting for user input. When the user clicks on the target application's identifier (such as an icon or list item) in the process manager interface, triggering the target application's launch process, the process manager performs the following operations: disabling the invalid region marker function for the current page, pausing LVGL's timed redrawing and display cache refresh operations (background program operation is unaffected). Create a full-screen overlay control M1 to obscure underlying controls and listen for custom touch gestures (for subsequent return to the process manager) to determine if the touch action matches a preset return gesture. The process manager launches the target application as a child process and monitors its status via a separate thread. The target application can independently listen for and handle touch events, updating video memory to change the screen display. The process manager (parent process) can detect when a child process of the target application exits by capturing a termination signal.

[0056] As a mainstream lightweight GUI library in the embedded field, LVGL has become the preferred choice for embedded UI development on low-configuration hardware platforms due to its core advantages such as low resource consumption, strong portability, and rich components. The native function of LVGL only supports the rendering and interaction of a single UI program and does not have the ability to switch and return between different target applications. To this end, this invention proposes an embedded Linux system process manager based on LVGL. With the technical mechanism provided by LVGL, the process manager can be quickly switched and returned between various UI programs in a simple and efficient manner. This invention is applicable to low-cost, low-hardware-configuration embedded systems. The core implementation points of this invention when switching multiple UI processes are as follows: (1) Disable invalid area markers: Stop the display cache refresh of the UI process manager when switching, while retaining the complete data state of LVGL layers and controls. When the process manager interface is restored, it can be rendered directly and quickly without re-initializing the LVGL graphics context, controls and event registration, which greatly shortens the recovery time. (2) Full-screen coverage of control M1: On the one hand, it covers the lower layer controls to avoid accidental triggering of touch screen operations; on the other hand, it supports full-screen touch gesture monitoring, and developers can define exclusive gestures to return from the UI application to the process manager as needed. (3) Real-time monitoring of process status: The UI process manager continuously monitors the running status of the UI application. Regardless of whether the application exits normally or crashes abnormally, it can quickly switch back to the main page of the process manager to ensure the continuity and stability of system interaction.

[0057] This invention is built upon the lightweight LVGL GUI library, achieving the goals of rapid switching of target applications, lossless preservation of process manager state, and return to touch screen event responses in scenarios with low hardware resource constraints. This invention proposes a process manager adapted to low-cost embedded Linux systems, implemented based on LVGL. Its advantage lies in its independence from resource-intensive multi-window display protocols, enabling flexible switching between the process manager and the target application in a lightweight and efficient manner. Specifically, it achieves the following effects: the process manager and the target application reuse the display screen's Frame Buffer device node and the touchscreen device node, both displaying the interface in full-screen mode, without relying on multi-process window compositing protocols such as X11 and Wayland. When the process manager needs to launch the target application, it first disables the invalid region flag and creates a full-screen overlay control M1 to actively stop any writing to the Frame Buffer (pausing rendering output), thereby relinquishing its own display output control. Then, the process manager launches the target application as a child process to transfer display output control to the target application and continuously monitors the exit status of the target application. Finally, only after the target application exits can the process manager restore the invalid region flag and mark the entire main interface as invalid and redraw it, thus regaining display output control. This method of using time-sharing updates to the Frame Buffer cache to achieve process switching supports only one process running for screen rendering output at a time, avoiding resource conflicts caused by concurrent operations of multiple UI processes. Moreover, the process manager is responsible for starting, stopping, and monitoring the status of the target application, supports switching from the process manager to the target application, and automatically returns to the process manager interface after the target application stops. The scheduled target application is not restricted by the process manager framework and does not require additional development of inter-process communication and special management logic, reducing the integration threshold.

[0058] For example, the application scenario of this invention is limited to POS printers adapted to low-cost embedded Linux systems, which can be used to print receipts, express delivery slips, etc. The main body of the process execution is the process manager. Due to the limitation of adapting to low-cost embedded Linux systems, the system only runs one target application. If the POS machine causes a printing error due to some malfunction, it needs to switch from the current target application (such as the printing function APP) to the print management target application (i.e., the target application, such as the test function APP). The process manager will retain the process of the current target application while switching to run the test function APP. After the test function APP confirms and troubleshoots the cause of the printing error, it will close the test function APP and switch back to run the printing function APP to continue printing, without waiting for the printing function APP to restart and re-update the corresponding screen, saving waiting time and improving the printing user experience.

[0059] To better implement the multi-process switching display method in the embodiments of the present invention, based on the multi-process switching display implementation method, the embodiments of the present invention also provide a multi-process switching display implementation system, including: The monitoring and judgment module is used to listen for whether a startup request from the target application is received during the operation of the process manager; The processing module is used to, upon receiving the startup request, control the process manager to pause its own screen rendering output and save the interface state of the process manager, create and run the child process of the target application, and enable the child process to obtain display output control. The control module is used to detect when the target application exits runtime, restore the display output control of the process manager, and continue to render and output the screen based on the interface state.

[0060] The multi-process switching display implementation system provided in the above embodiments can implement the technical solutions described in the above multi-process switching display implementation method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above multi-process switching display implementation method embodiments, which will not be repeated here.

[0061] like Figure 8 As shown, the present invention also provides a small-screen device 800. The small-screen device 800 includes a processor 801, a memory 802, and a display 803. Figure 8 Only some components of the small-screen device 800 are shown, but it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0062] In some embodiments, processor 801 may be a central processing unit (CPU), microprocessor, or other data processing chip, used to run program code stored in memory 802 or process data, such as the multi-process switching display implementation method of the present invention.

[0063] In some embodiments, processor 801 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 801 may be local or remote. In some embodiments, processor 801 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, intranet, multi-cloud, etc., or any combination thereof.

[0064] In some embodiments, memory 802 may be an internal storage unit of the small-screen device 800, such as a hard disk or memory of the small-screen device 800. In other embodiments, memory 802 may also be an external storage device of the small-screen device 800, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the small-screen device 800.

[0065] Furthermore, the memory 802 may include both internal storage units and external storage devices of the small-screen device 800. The memory 802 is used to store application software and various types of data installed on the small-screen device 800.

[0066] In some embodiments, display 803 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 803 is used to display information from the small-screen device 800 and to display a visual user interface. Components 801-803 of the small-screen device 800 communicate with each other via a system bus.

[0067] In one embodiment, when the processor 801 executes the implementation program for multi-process switching display in the memory 802, the following steps can be performed: While the process manager is running, it listens for whether a startup request from the target application is received; If the startup request is received, the process manager is controlled to pause its own screen rendering output and save the interface state of the process manager, and a child process of the target application is created and run, so that the child process obtains control over the display output. Upon detecting the exit of the target application, the process manager regains control of the display output and continues to render and output the screen based on the interface state.

[0068] It should be understood that when the processor 801 executes the multi-process switching display implementation program in the memory 802, in addition to the functions mentioned above, it can also implement other functions, as can be found in the description of the corresponding method embodiments above.

[0069] Furthermore, this embodiment of the invention does not specifically limit the type of the small-screen device 800 mentioned. The small-screen device 800 can be a portable small-screen device such as a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, or laptop computer. Exemplary embodiments of portable small-screen devices include, but are not limited to, portable small-screen devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable small-screen device can also be other portable small-screen devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the invention, the small-screen device 800 may not be a portable small-screen device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0070] Accordingly, this application also provides a computer-readable storage medium for storing a computer-readable program or instruction. When the program or instruction is executed by a processor, it can implement the steps or functions of the multi-process switching display implementation method provided in the above-described method embodiments.

[0071] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0072] The above provides a detailed description of the implementation method, system, device, and medium for multi-process switching display provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are 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 method for implementing multi-process switching display, characterized in that, include: While the process manager is running, it listens for whether a startup request from the target application is received; If the startup request is received, the process manager is controlled to pause its own screen rendering output and save the interface state of the process manager, and a child process of the target application is created and run, so that the child process obtains control over the display output. Upon detecting the exit of the target application, the process manager regains control of the display output and continues to render and output the screen based on the interface state.

2. The method for implementing multi-process switching display according to claim 1, characterized in that, Also includes: When a change in the state of a control on the main interface of the process manager is detected, the screen area where the changed control is located is marked as an invalid area; When updating the screen of the process manager, the rendering data for the invalid area is submitted to the display buffer to redraw the invalid area.

3. The method for implementing multi-process switching display according to claim 2, characterized in that, The step of controlling the process manager to pause its own screen rendering output and save the interface state of the process manager includes: By switching the invalid region marker to disabled through the process manager, the process manager stops submitting new rendering data to the display buffer, thus pausing its screen rendering output, while running in the background and storing the interface state in the running memory.

4. The method for implementing multi-process switching display according to claim 3, characterized in that, The process of launching the target application includes: The process manager is controlled to create a full-screen overlay control to block input events to the main interface of the process manager during the execution of the target application.

5. The method for implementing multi-process switching display according to claim 4, characterized in that, Also includes: When the full-screen overlay control detects a preset return gesture, it controls the process manager to send a termination signal to the target application, causing the target application to exit.

6. The method for implementing multi-process switching display according to claim 4, characterized in that, Restoring the display output control of the process manager and continuing screen rendering output based on the interface state includes: Control the process manager to delete the full-screen overlay control; The process manager is controlled to restore the invalid area marking function, marking the entire display area of ​​the main interface as invalid, and the screen of the main interface is redrawn based on the interface state.

7. The method for implementing multi-process switching display according to any one of claims 1 to 6, characterized in that, Also includes: If the target application fails to start, the process manager is controlled to abort the process of switching display control.

8. A system for implementing multi-process switching display, characterized in that, include: The monitoring and judgment module is used to listen for whether a startup request from the target application is received during the operation of the process manager; The processing module is used to, upon receiving the startup request, control the process manager to pause its own screen rendering output and save the interface state of the process manager, create and run the child process of the target application, and enable the child process to obtain display output control. The control module is used to detect when the target application exits runtime, restore the display output control of the process manager, and continue to render and output the screen based on the interface state.

9. A small-screen device, characterized in that, Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the multi-process switching display implementation method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer-readable programs or instructions, which, when executed by a processor, can implement the steps in the multi-process switching display implementation method according to any one of claims 1 to 7.

Images