A method and apparatus for lazy rendering of an embedded system interface
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FUZHOU WECON ELECTRONICS TECH
- Filing Date
- 2025-12-25
- Publication Date
- 2026-05-26
Smart Images
Figure CN122086504A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of invasive systems and human-computer interaction technology, and specifically to a method and apparatus for lazy rendering of an embedded system interface. Background Technology
[0002] Currently, most common GUI frameworks on the market use a synchronous loading mode by default. When a UI engine receives a screen switching instruction, it will perform the following operations in sequence: parse the layout file, create software objects for all UI controls, load all resources required by the controls (including images and fonts), initialize all data structures of the controls (including event callback functions and animation state machines), and finally render the complete interface to the frame buffer all at once.
[0003] The overall synchronous loading mode generates intensive CPU calculations and I / O read operations during the initialization phase, consuming a lot of CPU time and memory. This results in a significant and perceptible delay between user operation and when the interface is fully ready. Furthermore, many interactive resources after initialization are not used during the current interface display cycle, which not only occupies valuable memory space but also wastes the CPU cycles required for initialization. To address the aforementioned issues, this application proposes a method and apparatus for lazy rendering of an embedded system interface. Summary of the Invention
[0004] This application addresses one or more technical deficiencies in the prior art by proposing the following technical solution.
[0005] Based on the first aspect of this application, an apparatus for lazy rendering of an embedded system interface is proposed, including an interface parsing module, a resource classification module, a static rendering engine, a dynamic loading manager, a dynamic element shared pool management module, and an event handling module. In response to user-triggered interface switching, the interface parsing module parses the layout and components of the target interface and generates a component description set. The resource classification module divides the component description set into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. The static rendering engine loads the static rendering list synchronously with high priority, performs graphic composition, quickly renders static images, and outputs them to the display buffer of the target interface; the dynamic list to be loaded is added to the dynamic element sharing pool management module and marked as lazy loading, and dynamic interactive element sharing instances are created for elements of the same type. In response to user input detected by the event handling module, the dynamic loading manager loads and initializes the dynamic interactive elements according to the user's interaction events, obtains shared instances of dynamic interactive elements from the dynamic element sharing pool management module, and applies them to the corresponding elements.
[0006] Furthermore, the dynamic element sharing pool management module handles the binding, unbinding, and scheduling of the dynamic interactive element sharing instance with elements of the same type. The event handling module and the dynamic loading manager work together to determine the dynamic resource status of the target element, load the target element, bind the target element with the dynamic interactive element sharing instance, and load dynamic resources.
[0007] This step associates and decouples dynamic resources and target elements. When the user's focus changes, the system does not need to reload resources. It can switch dynamic effects by quickly binding and unbinding, which greatly improves the speed of interaction response and the system's operating efficiency, and further reduces the performance overhead caused by the repeated creation and destruction of shared instances of dynamic interactive elements.
[0008] Furthermore, the static graphic elements include the glyphs and colors of the label text, the background bitmap, and the border texture; the dynamic interactive elements include event callback function pointers, animation keyframe data, focus state textures, and soft keyboard logic modules.
[0009] Furthermore, the dynamic loading list records the component ID and the dynamic interactive element identifier required by the component, as well as the shareable identifier of the dynamic interactive element; the static rendering list records the static resource path of the static graphic element.
[0010] This step provides a precise data index for subsequent interface rendering, enabling the system to quickly locate target resources and improve the accuracy and efficiency of dynamic resource management processes.
[0011] Based on a second aspect of this application, a method for lazy rendering of an embedded system interface according to any one of the foregoing apparatus is also proposed, comprising: S1: In response to the interface switching command, the system parses the layout description file of the interface, identifies the layout and components of the target interface, generates a set of component descriptions, and the resource classification module divides the set of component descriptions into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. S2: The static rendering engine starts the rendering task, loads static graphics resources according to the static rendering list and performs bitmap compositing, quickly renders the static screen and outputs the static interface image to the display buffer of the target interface; S3: Submit the dynamic list to be loaded to the dynamic loading manager. The dynamic loading manager stores the dynamic list to be loaded in a low-priority background task queue. The dynamic element sharing pool management module analyzes the dynamic list to be loaded, identifies elements with the same dynamic interactive element identifier, and creates dynamic interactive element sharing instances for elements of the same type. S4: In response to user input monitored by the event handling module, when the system detects a user interaction event, it sends a request to the dynamic loading manager. The dynamic loading manager obtains and loads the dynamic interactive element from the dynamic element sharing pool management module according to the interaction event. The event handling module binds the dynamic interactive element sharing instance to the target element and applies the dynamic interactive element sharing instance to the corresponding target element to activate the corresponding visual feedback and logical response.
[0012] This application achieves instant interface opening and efficient resource reuse through a complete lazy rendering pipeline from resource classification, static rendering, shared pool pre-construction to interactive triggering, providing guidance for optimizing the interface rendering performance of various embedded systems.
[0013] Furthermore, the shared instances of the dynamic interactive elements are stored in the dynamic element shared pool and managed using "element type - dynamic element type" as the key.
[0014] This step enables efficient retrieval of shared instances of dynamic interactive elements. When binding shared instances of dynamic interactive elements to components, it avoids full pool traversal, greatly reduces the latency of dynamic resource binding, and ensures the real-time performance of interactive responses.
[0015] Furthermore, after sending a request to the dynamic loading manager, the system queries the loading status of the dynamic interactive elements of the target element. If a unique dynamic interactive element is requested to be loaded, the corresponding task is retrieved from the background task queue to perform resource loading and initialization, and the newly generated shared instance of the dynamic interactive element is bound to the target element. If a request is made to load a shareable dynamic interactive element, the already created shared instance of the dynamic interactive element is retrieved from the dynamic element sharing pool management module and bound to the target element.
[0016] This step optimizes the resource loading strategy, ensuring resource integrity and independence for unique dynamic interactive elements, and maximizing instance reuse for shareable resources, thereby minimizing the consumption of computing and memory resources.
[0017] Furthermore, when a user switches their interaction from the first element to the second element of the same type, the system unbinds the shared instance of the dynamic interactive element from the first element and then rebinds the shared instance of the dynamic interactive element to the second element.
[0018] This step enables "hot switching" of dynamic interactive effects, eliminating any lag or reloading delays during user interaction, thus improving the user experience and completely avoiding the resource waste caused by maintaining an independent state machine for each component.
[0019] Based on a third aspect of this application, a computer program product is also proposed, having one or more computer programs thereon that, when executed by a computer processor, perform the method as described in any of the above.
[0020] The technical advantages of this application are as follows: This application realizes instance-level sharing of dynamic resources and lazy rendering of the interface. Users can see the complete static interface in a very short time, eliminating the "white screen" or "lag" phenomenon caused by waiting for all interactive resources to initialize, which greatly improves the perceived switching speed. It avoids loading redundant interactive resources that are not used by the user during interface initialization, and eliminates the duplicate overhead of dynamic resources of similar components through a shared pool of dynamic interactive elements, achieving extreme optimization of memory usage. Through precise on-demand loading, it avoids the resource waste problem of multi-screen preloading. Furthermore, this application does not rely on specific hardware acceleration or UI frameworks and can be widely used in various resource-constrained embedded devices. Attached Figure Description
[0021] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.
[0022] Figure 1 This is a block diagram of an embedded system interface lazy rendering apparatus provided according to an embodiment of this application.
[0023] Figure 2 This is a processing logic diagram of an embedded system interface lazy rendering device provided according to an embodiment of this application.
[0024] Figure 3 This is a flowchart of a method for lazy rendering of an embedded system interface according to an embodiment of this application.
[0025] Figure 4 This is a processing logic diagram of an embodiment of a method for lazy rendering of an embedded system interface provided according to an embodiment of this application.
[0026] Figure 5 This is a schematic diagram of the structure of a computer system suitable for implementing the electronic devices of the present application embodiments. Detailed Implementation
[0027] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.
[0028] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0029] Figure 1 This application illustrates an apparatus for lazy rendering of an embedded system interface, including an interface parsing module a, a resource classification module b, a static rendering engine c, a dynamic loading manager d, a dynamic element shared pool management module e, and an event handling module f; In response to user-triggered interface switching, the interface parsing module a parses the layout and components of the target interface and generates a set of component descriptions. The resource classification module b divides the set of component descriptions into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. The static rendering engine c loads the static rendering list synchronously with high priority, performs graphic composition, quickly renders static images, and outputs them to the display buffer of the target interface; it adds the dynamic list to be loaded to the dynamic element sharing pool management module and marks it as lazy loading, and creates dynamic interactive element sharing instances for elements of the same type. In response to user input monitored by the event handling module f, the dynamic loading manager d loads and initializes the dynamic interactive elements according to the user's interaction events, obtains shared instances of dynamic interactive elements from the dynamic element sharing pool management module e, and applies them to the corresponding elements.
[0030] It should be noted that the dynamic element sharing pool management module handles the binding, unbinding, and scheduling of the dynamic interactive element sharing instance with elements of the same type. The event handling module and the dynamic loading manager work together to determine the dynamic resource status of the target element, load the target element, bind the target element with the dynamic interactive element sharing instance, and load dynamic resources.
[0031] It should be noted that this step associates and decouples dynamic resources and target elements. When the user's interaction focus changes, the system does not need to reload resources. It can switch dynamic effects by quickly binding and unbinding, which greatly improves the speed of interaction response and the system's operating efficiency, and further reduces the performance overhead caused by the repeated creation and destruction of shared instances of dynamic interactive elements.
[0032] It should be noted that the static graphic elements include the font and color of the label text, the background bitmap, and the border texture; the dynamic interactive elements include event callback function pointers, animation keyframe data, focus state textures, and soft keyboard logic modules.
[0033] It should be noted that the dynamic loading list records the component ID and the dynamic interactive element identifier required by the component, as well as the shareable identifier of the dynamic interactive element; the static rendering list records the static resource path of the static graphic element.
[0034] It should be noted that this step provides a precise data index for subsequent interface rendering, enabling the system to quickly locate target resources and improve the accuracy and efficiency of dynamic resource management processes.
[0035] The following is for reference. Figure 2 It illustrates the processing logic flow of the device as described above, including: S201: In response to the interface switching command, the interface parsing module parses the layout and components of the target interface and generates a set of component descriptions; S202: The resource classification module divides the element description set into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. S203: The static rendering engine loads all static graphic elements in the static rendering list in a high-priority synchronous manner, quickly renders the static image, and outputs it to the display buffer of the target interface, and the interface camera image opens and displays instantly. S204: Add the dynamic list to be loaded to the dynamic element sharing pool management module and mark it as lazy loading; create dynamic interactive element sharing instances for elements of the same type. S205: The event handling module listens for user interaction actions. If the user generates an interaction action, it checks whether the dynamic interactive elements of the target element are loaded. S206: If the dynamic interactive elements of the target element have been loaded, respond directly to the user interaction; otherwise, if the dynamic interactive elements of the target element have not been loaded, load and initialize the dynamic interactive elements of the element immediately.
[0036] It should be noted that during the interface parsing process, not only are all components identified, but a component resource description item is also constructed for each component, recording the type identifier, position, size and state attributes. Static graphic elements can be directly sent to the graphics processor GPU or frame buffer for compositing, while dynamic interactive elements are initialized and maintained in runtime state by the CPU. After classification, the system generates a static rendering list that lists all static resource paths that need to be loaded immediately; and a dynamic list to be loaded, which uses a data structure (such as a hash table) to record each element ID and its required dynamic element identifier, as well as a flag indicating whether it is a shareable element.
[0037] It should be noted that the static rendering engine starts a rendering task with high priority. Based on the static rendering manifest, it loads images and font resources from the storage system and performs only bitmap compositing operations. During this process, no UI control software objects are created, and no event listeners, animation state machines, or any data structures related to interaction are initialized. The rendering task outputs the final composited complete static interface image to the back buffer and performs a buffer switch, which is then immediately presented to the user on the display screen. The goal of this step is extreme speed, so that users can experience the interface opening "instantly".
[0038] It should be noted that the resource allocation object of this application is the visual and logical composition of a single UI element (static graphic elements and dynamic interactive elements), rather than the data or resource package of the entire page, which belongs to the element-level rendering optimization. The loading of dynamic resources is not a timed or predictive background task, but is directly driven by the user's real-time interactive behavior (such as clicking and focusing). The system only loads and initializes the dynamic resources required by a specific element when the user interacts with that element. There is a further improvement in the resource sharing level. The dynamic element sharing pool realizes the reuse of resources at the software instance level. The same dynamic effect of the same type of UI element exists only once in memory, which can be bound and unbound on demand for all similar elements. This is fundamentally different from simple data caching or functional logic grouping.
[0039] The following is for reference. Figure 3 It illustrates a method for lazy rendering of an embedded system interface according to any of the apparatuses described above, comprising: S1: In response to the interface switching command, the system parses the layout description file of the interface, identifies the layout and components of the target interface, generates a set of component descriptions, and the resource classification module divides the set of component descriptions into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. S2: The static rendering engine starts the rendering task, loads static graphics resources according to the static rendering list and performs bitmap compositing, quickly renders the static screen and outputs the static interface image to the display buffer of the target interface; S3: Submit the dynamic list to be loaded to the dynamic loading manager. The dynamic loading manager stores the dynamic list to be loaded in a low-priority background task queue. The dynamic element sharing pool management module analyzes the dynamic list to be loaded, identifies elements with the same dynamic interactive element identifier, and creates dynamic interactive element sharing instances for elements of the same type. S4: In response to user input monitored by the event handling module, when the system detects a user interaction event, it sends a request to the dynamic loading manager. The dynamic loading manager obtains and loads the dynamic interactive element from the dynamic element sharing pool management module according to the interaction event. The event handling module binds the dynamic interactive element sharing instance to the target element and applies the dynamic interactive element sharing instance to the corresponding target element to activate the corresponding visual feedback and logical response.
[0040] It should be noted that this application presents a complete lazy rendering pipeline, from resource classification, static rendering, shared pool pre-construction to interactive triggering, achieving instant interface opening and efficient resource reuse, providing guidance for optimizing the interface rendering performance of various embedded systems.
[0041] It should be noted that the shared instances of the dynamic interactive elements are stored in the dynamic element sharing pool and managed using "element type - dynamic element type" as the key.
[0042] It should be noted that this step enables efficient retrieval of shared instances of dynamic interactive elements. When binding shared instances of dynamic interactive elements to components, it avoids full pool traversal, greatly reduces the latency of dynamic resource binding, and ensures the real-time performance of interactive responses.
[0043] It should be noted that after sending a request to the dynamic loading manager, the system queries the loading status of the dynamic interactive elements of the target element. If a unique dynamic interactive element is requested to be loaded, the corresponding task is retrieved from the background task queue to perform resource loading and initialization, and the newly generated shared instance of the dynamic interactive element is bound to the target element. If a request is made to load a shareable dynamic interactive element, the already created shared instance of the dynamic interactive element is retrieved from the dynamic element sharing pool management module and bound to the target element.
[0044] It should be noted that this step optimizes the resource loading strategy, ensuring the integrity and independence of unique dynamic interactive element resources, maximizing instance reuse for shareable resources, and minimizing the consumption of computing and memory resources.
[0045] It should be noted that when a user switches their interaction from the first element to the second element of the same type, the system will unbind the shared instance of the dynamic interactive element from the first element and then rebind the shared instance of the dynamic interactive element to the second element.
[0046] It should be noted that this step achieves "hot switching" of dynamic interactive effects, so that there is no lag or reloading delay during user interaction, which improves the user's interactive experience and completely avoids the waste of resources caused by maintaining an independent state machine for each component.
[0047] In a specific embodiment, taking the setting interface of an embedded smart temperature controller as an example, the interface includes a background image, title text, multiple temperature setting input boxes with labels, and a "Save" button. When the user clicks to enter the setting interface, the interface parsing module parses the layout file, and the interface has 1 background, 1 title, 3 input boxes, and 1 button. The resource classification module performs resource classification, and the results are as follows: The input box has the following static graphic elements: a white rectangular background, a gray border, and the text "Set Temperature" label. Dynamic interactive elements of the input box: a blue highlighted border when focused, a blinking cursor animation, and a pop-up numeric keyboard logic; The button's static graphic elements: a blue rectangular background and the text "Save"; Dynamic interactive elements of buttons: scaling animation when pressed and click event handling functions; The static rendering engine prioritizes rendering static images. The system immediately loads the background image, all text, static borders and backgrounds of all input boxes, and static appearance of buttons. It then synthesizes a complete static settings interface image in the back buffer and displays it to the user in one switch. At this time, the user feels that the interface has opened "instantly". The CPU usage is 10% and the memory usage is 30M. For lazy loading of dynamic resources, the system puts the cursor and keyboard logic of the input box and the click animation of the button into the background queue. When the user clicks the first input box, the system responds to the interaction as needed. The system detects that the dynamic elements of the input box have not been loaded, and immediately loads the cursor animation and soft keyboard logic. The cursor starts to blink, the soft keyboard pops up, the CPU usage is 15%, the memory usage is 35M, and the response time is 10ms.
[0048] In one specific embodiment, a dynamic element sharing pool is introduced to optimize the three input boxes based on the previous embodiment. After resource classification, the system identifies the three input boxes as similar elements, creates a shared cursor animation instance and a shared focus highlight border instance for the "input box" category, and puts them into the dynamic element sharing pool. When the user focuses on input box A for the first time, the system does not load from scratch, but directly obtains the shared cursor animation instance and focus highlight instance from the dynamic element sharing pool and binds them to input box A. The visual effect appears immediately, with CPU usage of 15%, memory usage of 35M, and a response time of 10ms. The user then switches the focus to input box B. The system performs a "switch" operation: the cursor animation instance and the focus highlight instance are unbound from input box A respectively. The cursor and focus of input box A disappear. Then, it is bound to input box B. The cursor and focus appear in input box B. At this time, the CPU usage is 15%, the memory usage is 35M, and the response time is 10ms. Throughout the process, regardless of how many input boxes there are on the screen, there is always only one instance of cursor animation and focus highlight in memory. Compared to creating a separate instance of cursor animation and focus highlight for each input box, this saves a huge amount of memory and provides a faster switching response.
[0049] In a specific embodiment, scrolling lazy rendering and instance reuse in the list interface are as follows: Figure 4 As shown, an embedded device's file management list interface contains a vertically scrollable long list. Each list item includes a file icon, name, size, and modification date. The system performs the following steps: S401: The interface parsing module parses the long list, and the resource classification module classifies it, identifying static graphic elements (the border of the list container, the background of the scroll bar, the bitmap of each item's icon, the shape and static color of the file name, and the text style of the size and date) and dynamic interactive elements (the press highlight effect when each item is clicked, the check animation when selected, and the context menu logic triggered when long-pressed). The static rendering engine prioritizes rendering static images, that is, it only renders the static content of all list items within the currently visible area of the Viewport. A complete static view of the file list is immediately presented before the user scrolls, with CPU usage at 10% and memory usage at 33M. S402: The system recognizes all list items as ListItem of the same type. The dynamic element shared pool management module creates a shared animation instance for "press highlight effect" and "selection check animation" and puts them into the dynamic element shared pool respectively. S403: When a user clicks on a list item X, the event handling module captures the click coordinates and locates the list item X. If the dynamic element of list item X is not bound, the dynamic loading manager obtains a shared instance of "press highlight effect" from the shared pool and binds it to list item X. The press effect is immediately displayed visually. At this time, the CPU usage is 15%, the memory usage is 35M, and the response time is 10ms. If the dynamic element of list item X is already bound at this time, the visual effect is displayed directly. S404: After the user releases the button, the "press highlight effect" instance is unbound from list item X, the highlight disappears, and when the user scrolls the list, the list item Y that enters the new visible area directly reuses the existing shared instance of dynamic interactive elements in the pool for binding. This process does not require reloading animation resources or initializing logic for each new item. At this time, the CPU usage is 15%, the memory usage is 35M, and the response time is 10ms. No matter how long the list is, there is only one instance of each of the "press highlight effect" and "selection check animation" in memory, resulting in smooth scrolling and no additional memory growth, achieving high-performance rendering of complex list interfaces.
[0050] It should be noted that this application implements instance-level sharing of dynamic resources and lazy rendering of the interface. Users can see the complete static interface in a very short time, eliminating the "white screen" or "lag" phenomenon caused by waiting for all interactive resources to initialize. This greatly improves the perceived switching speed, avoids loading redundant interactive resources that are not used by the user during interface initialization, and eliminates the duplicate overhead of dynamic resources of similar components through a shared pool of dynamic interactive elements, achieving ultimate optimization of memory usage. Through precise on-demand loading, it avoids the resource waste problem of multi-screen preloading, and does not rely on specific hardware acceleration or UI frameworks, so it can be widely used in various resource-constrained embedded devices.
[0051] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0052] like Figure 5As shown, the computer system includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for system operation. CPU 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.
[0053] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a liquid crystal display (LCD) and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card and a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.
[0054] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined in the methods of this application. It should be noted that the computer-readable storage medium of this application can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0055] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof. Programming languages include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0056] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0057] The modules described in the embodiments of this application can be implemented in software or in hardware.
[0058] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the electronic device, the electronic device comprises: an interface parsing module, a resource classification module, a static rendering engine, a dynamic loading manager, a dynamic element sharing pool management module, and an event handling module; in response to a user-triggered interface switch, the interface parsing module parses the layout and components of the target interface and generates a component description set; the resource classification module divides the component description set into static graphic elements and dynamic interactive elements according to preset rules, obtaining a static rendering list and a dynamic loading list; the static rendering engine synchronously loads the static rendering list with high priority, performs graphic composition, quickly renders static images, and outputs them to the display buffer of the target interface; the dynamic loading list is added to the dynamic element sharing pool management module and marked as lazy loading, creating shared instances of dynamic interactive elements for components of the same type; in response to user input monitored by the event handling module, the dynamic loading manager loads and initializes the dynamic interactive elements according to the user's interaction events, obtains shared instances of dynamic interactive elements from the dynamic element sharing pool management module, and applies them to the corresponding components.
[0059] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.
[0060] Finally, it should be noted that the above embodiments are for illustration only and not for limiting the technical solutions of the present invention. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention without departing from the spirit and scope of the present invention. Any modifications or partial substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A device for lazy rendering of an embedded system interface, characterized in that, It includes an interface parsing module, a resource classification module, a static rendering engine, a dynamic loading manager, a dynamic element shared pool management module, and an event handling module; In response to user-triggered interface switching, the interface parsing module parses the layout and components of the target interface and generates a component description set. The resource classification module divides the component description set into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. The static rendering engine loads the static rendering list synchronously with high priority, performs graphic compositing, quickly renders static images, and outputs them to the display buffer of the target interface. Add the dynamic list to be loaded to the dynamic element sharing pool management module and mark it as lazy loading, and create dynamic interactive element sharing instances for elements of the same type; In response to user input detected by the event handling module, the dynamic loading manager loads and initializes the dynamic interactive elements according to the user's interaction events, obtains shared instances of dynamic interactive elements from the dynamic element sharing pool management module, and applies them to the corresponding elements.
2. The apparatus according to claim 1, characterized in that, The dynamic element sharing pool management module handles the binding, unbinding, and scheduling of the dynamic interactive element sharing instance with elements of the same type. The event handling module and the dynamic loading manager work together to determine the dynamic resource status of the target element, load the target element, bind the target element with the dynamic interactive element sharing instance, and load dynamic resources.
3. The apparatus according to claim 1, characterized in that, The static graphic elements include the font and color of the label text, the background bitmap, and the border texture; the dynamic interactive elements include event callback function pointers, animation keyframe data, focus state textures, and soft keyboard logic modules.
4. The apparatus according to claim 1, characterized in that, The dynamic loading list records the component ID and the identifier of the dynamic interactive element required by the component, as well as the shareable identifier of the dynamic interactive element; the static rendering list records the static resource path of the static graphic element.
5. A method for lazy rendering of an embedded system interface according to the apparatus of any one of claims 1-4, characterized in that, include: S1: In response to the interface switching command, the system parses the layout description file of the interface, identifies the layout and components of the target interface, generates a set of component descriptions, and the resource classification module divides the set of component descriptions into static graphic elements and dynamic interactive elements according to preset rules, and obtains a static rendering list and a dynamic loading list. S2: The static rendering engine starts the rendering task, loads static graphics resources according to the static rendering list and performs bitmap compositing, quickly renders the static screen and outputs the static interface image to the display buffer of the target interface; S3: Submit the dynamic list to be loaded to the dynamic loading manager. The dynamic loading manager stores the dynamic list to be loaded in a low-priority background task queue. The dynamic element sharing pool management module analyzes the dynamic list to be loaded, identifies elements with the same dynamic interactive element identifier, and creates dynamic interactive element sharing instances for elements of the same type. S4: In response to user input monitored by the event handling module, when the system detects a user interaction event, it sends a request to the dynamic loading manager. The dynamic loading manager obtains and loads the dynamic interactive element from the dynamic element sharing pool management module according to the interaction event. The event handling module binds the dynamic interactive element sharing instance to the target element and applies the dynamic interactive element sharing instance to the corresponding target element to activate the corresponding visual feedback and logical response.
6. The method according to claim 5, characterized in that, The shared instances of the dynamic interactive elements are stored in the dynamic element shared pool and managed using "element type - dynamic element type" as the key.
7. The method according to claim 5, characterized in that, After sending a request to the dynamic loading manager, the system queries the loading status of the dynamic interactive elements of the target element. If a unique dynamic interactive element is requested to be loaded, the corresponding task is retrieved from the background task queue to perform resource loading and initialization, and the newly generated shared instance of the dynamic interactive element is bound to the target element. If a request is made to load a shareable dynamic interactive element, the already created dynamic interactive element sharing instance is obtained from the dynamic element sharing pool management module and bound to the target element.
8. The method according to claim 5, characterized in that, When a user switches their interaction from the first element to the second element of the same type, the system unbinds the shared instance of the dynamic interactive element from the first element and then rebinds the shared instance of the dynamic interactive element to the second element.
9. A computer program product having one or more computer programs thereon, characterized in that, When the computer program is executed by a computer processor, the method described in any one of claims 5-8 is performed.