Unified scheduling method and device for multi-scene system display of wearable device

Abstract

The application provides a multi-scene system display unified scheduling method and device for a wearable device, applied to the technical field of intelligent wearable device display control, by constructing a synthetic display scheduling module independent of a conventional view tree, binding it to a root view, and using a top-level entry reserved by the root view to superimpose and draw the to-be-displayed content to the same screen buffer after the conventional view tree is drawn, unified scheduling and high-priority output of multiple scenes such as boot and shutdown animations, micro-light modes and system transient prompt animations are achieved, not only avoiding the rendering path coupling and resource competition problems caused by the scattered implementation of each scene, effectively reducing the complexity and maintenance cost of the system architecture, but also ensuring that the animation playing and input events do not interfere with each other through preset priority rules and event distribution strategies, thereby significantly improving the rendering efficiency, interface display flexibility and scalability while ensuring the system performance and stability, and reducing power consumption.

Description

Technical Field

[0001] This application relates to the field of display control technology for smart wearable devices, specifically to a unified scheduling method and apparatus for multi-scene system display of wearable devices. Background Technology

[0002] In recent years, smartwatches, as an important form of wearable smart devices, have been widely used in scenarios such as health monitoring, exercise recording, communication reminders, and multimedia interaction. Due to their small size, limited power consumption, and limited hardware resources, smartwatch system software is usually built on a lightweight embedded operating system to achieve a balance between high performance, low power consumption, and real-time response. Among them, the LiteOS kernel system based on the OpenHarmony architecture has become a common system solution on smartwatch platforms due to its modularity, lightweight nature, and real-time performance. The LiteOS discussed in this article specifically refers to the LiteOS-M kernel branch of OpenHarmony (for MCU / ultra-lightweight terminal forms), and completes interface refresh and output through the root view RootView, rendering management components, etc., within its lightweight graphics subsystem / lightweight UI framework.

[0003] In lightweight graphics systems based on LiteOS-M, the graphics display system typically employs a single rendering loop and a lightweight view management mechanism. The UI refresh is driven by the UiMain main task, and all visible content is uniformly output through the RenderManager rendering engine. While this architecture enables simple, fast, and low-memory-overhead UI rendering, meeting the display needs of typical application scenarios, the increasing functionality of smartwatches has led to a growing demand for multi-layered and multi-scene display control. For example, in power-on / off animation scenarios, the animation still needs to play even when the system is not fully booted or about to shut down; in low-light displays, only partially changing time or status information needs to be displayed for low power consumption; and in system-level transient notification interfaces, notification information, animations, or status cards, such as incoming call, alarm clock, or music playback notifications, need to be dynamically displayed above the application layer.

[0004] To meet the aforementioned multi-scenario display requirements, existing methods often involve modifying the system rendering process, temporarily switching buffers, or directly accessing the underlying frame buffer. While these methods can achieve the desired functionality to some extent, they lead to complex system architecture, increased resource contention, and chaotic display logic. They may also cause issues such as animation stuttering, refresh delays, or screen ghosting. Furthermore, unified management and scheduling across different scenarios are difficult, resulting in high maintenance costs and compromised system stability and scalability.

[0005] Therefore, a new unified scheduling scheme for multi-scenario system displays for wearable devices is needed. Summary of the Invention

[0006] In view of this, the embodiments of this specification provide a unified scheduling method and apparatus for multi-scene system display of wearable devices, which can solve the problems of rendering path coupling, high resource consumption, animation and input event conflicts and maintenance complexity caused by the scattered implementation of various scenes in the existing solutions without intruding on the application layer interface structure. While ensuring performance and stability, it improves the flexibility and scalability of system interface display.

[0007] The embodiments in this specification provide the following technical solutions: This specification provides an embodiment of a unified scheduling method for multi-scenario system display in wearable devices, including: During the system startup phase, the composite display layer is initialized and bound to the system's root view to construct the composite display scheduling module; wherein, the composite display scheduling module is a display scheduling module independent of the regular view tree and is not mounted to the root view as a subview; When the root view performs an interface refresh, the regular view tree is first drawn to the screen buffer. After the regular view tree is drawn, the content to be displayed in the composite display scheduling module is drawn to the same screen buffer in an overlay manner through the top-level entry reserved by the root view. The composite display scheduling module is used to uniformly schedule different types of scenes, including: In response to a scene switching request, the corresponding display content is loaded within the compositing display scheduling module according to the type of the target scene, and the display content is rendered and output on the top layer of the screen. The display status of the scene is managed according to preset priority rules; According to the preset event distribution strategy, the input event is passed to the synthesis and display scheduling module. If the synthesis and display scheduling module does not process the input event, the input event is passed to the application layer or the system interface layer. The scenarios include at least two of the following: power on / off animation scenario, low-light mode scenario, and system transient notification animation scenario.

[0008] This specification also provides an embodiment of a unified scheduling device for multi-scenario system display of wearable devices, comprising: The composite display scheduling module construction unit is used to initialize the composite display layer during the system startup phase and bind the composite display layer to the root view of the system to construct the composite display scheduling module; wherein, the composite display scheduling module is a display scheduling module independent of the regular view tree and is not mounted to the root view as a subview; The overlay drawing control unit is used to first draw the content to be displayed in the composite display scheduling module to the same screen buffer by drawing the content from the regular view tree to the screen buffer in an overlay manner during the interface refresh process of the root view. The scene scheduling unit is used to uniformly schedule different types of scenes using the composite display scheduling module, including: The scene switching unit is used to respond to the scene switching request, load the corresponding display content inside the compositing display scheduling module according to the type of the target scene, and control the display content to be rendered and output on the top layer of the screen; The priority management unit is used to manage the display status of the scene according to preset priority rules; An event distribution unit is used to transmit input events to the synthesis and display scheduling module according to a preset event distribution strategy. If the synthesis and display scheduling module does not process the input event, it transmits the input event to the application layer or the system interface layer. The scenarios include at least two of the following: power on / off animation scenario, low-light mode scenario, and system transient notification animation scenario.

[0009] Compared with the prior art, the beneficial effects that at least one technical solution adopted in the embodiments of this specification can achieve include at least: By constructing a composition display scheduling module independent of the regular view tree and not mounted to the root view as a subview, and utilizing the top-level entry reserved in the root view to overlay the content to be displayed onto the same screen buffer after the regular view tree is drawn, unified scheduling and high-priority output for various scenarios such as power-on / off animations, low-light mode, and system transient prompt animations are achieved. This not only avoids the rendering path coupling and resource contention problems caused by the decentralized implementation of each scenario, effectively reducing the complexity of the system architecture and maintenance costs, but also ensures that animation playback and input events do not interfere with each other through preset priority rules and event distribution strategies. Thus, while ensuring system performance and stability, rendering efficiency, interface display flexibility and scalability are significantly improved, and power consumption is reduced. Attached Figure Description

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

[0011] Figure 1 This application describes a unified scheduling method for multi-scenario system display of wearable devices. Figure 1 ; Figure 2 This application describes a unified scheduling method for multi-scenario system display of wearable devices. Figure 2 ; Figure 3 This is a flowchart of the power-on / off animation display in this application; Figure 4 This is a flowchart of the low-light mode display in this application; Figure 5 This is a flowchart of the transient prompt animation display process in this application; Figure 6 This is a flowchart of scene switching and collaborative control in this application. Detailed Implementation

[0012] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0013] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0015] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0016] Additionally, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that practice can be carried out without these specific details.

[0017] Currently, most smartwatches on the market use a lightweight graphics system based on OpenHarmony LiteOS-M. This graphics system uses a single rendering loop (UiMain main task driven) and lightweight view management (RootView), which can efficiently and with low overhead handle routine interface display tasks.

[0018] However, as smartwatches become increasingly feature-rich, the system's demand for multi-layered and multi-scene display control is gradually increasing. For example, it needs to support diverse scenarios such as power-on / off animations, ambient light mode (AOD), and system-level transient alerts (such as incoming call pop-ups). In power-on / off animation scenarios, animations still need to play even when the system is not fully booted up or about to shut down. This requires the display module to run independently of the application framework. In the early stages of system startup, during shutdown, or in low-power states, the application framework may not have started or its rendering may be limited, but the system still needs to complete the necessary display output. In low-light displays, to display only partially changing time or status information with low power consumption, an independent display layer is needed to avoid interfering with the main UI. In system-level transient notification interface scenarios, the system needs to dynamically display notification information, animations, or status cards above the application layer, such as incoming call, alarm clock, or music playback notifications. These interfaces require the highest display priority and unified management. In addition, in specific states such as when the screen is locked or charging, the screen content also needs to be under unified system control. However, in the existing LiteOS graphics architecture, all drawing tasks are executed through a unified rendering pipeline, lacking an overlay and compositing display scheduling module independent of the system UI and application UI.

[0019] In view of this, the inventors discovered through research and improvement that existing solutions typically require developers to modify the system rendering process, temporarily switch frame buffers, or directly access the underlying frame buffer to meet multi-scene display requirements. While these solutions can achieve the target functionality to some extent, they not only lead to a complex and bloated system architecture, increased resource contention, and even chaotic display logic, but may also cause a series of problems such as animation stuttering, refresh delays, or screen ghosting. At the same time, it is difficult to manage and schedule different display scenarios in a unified manner, resulting in high maintenance costs and making it difficult to guarantee system stability and scalability.

[0020] Based on this, the embodiments of this specification propose a unified scheduling method for multi-scene system displays. The core idea is to logically decouple special display scenes from ordinary application interfaces and assign them higher rendering priority. Specifically, at system startup, an independent composite display layer is initialized and bound to the root view, constructing a composite display scheduling module that is not mounted under the root view as a subview. During each frame refresh, the screen is first drawn by the regular view tree, and then the content to be displayed in the composite display scheduling module is superimposed and drawn onto the same screen buffer through the top-level entry reserved by the root view, thereby ensuring that it is always at the top level of the display. Subsequently, the composite display is used... The scheduling module performs unified scheduling for multiple display scenarios, including loading target scene content within the module and controlling top-level rendering based on switching requests, managing scene display status according to priority rules, and implementing an event distribution strategy that prioritizes input events to the compositing display scheduling module and then passes them through to the application layer or system interface layer if unprocessed. This enables unified management and high-priority display of various display scenarios, such as power-on / off animations, low-light modes, and system transient prompt animations, without intruding on the application layer interface structure. This significantly improves rendering efficiency, reduces power consumption, ensures that animation playback and system input events do not interfere with each other, and facilitates system expansion and maintenance.

[0021] The technical terms used in the embodiments of this specification are explained as follows: Application framework: A collection of lightweight application runtime environments and UI frameworks used to support the lifecycle of an application (App), page management, application interface (UI) construction and updates.

[0022] RootView: The root view, the root rendering view / root container in the LiteOS lightweight graphics system, is responsible for managing the drawing and input event distribution of the entire screen. All drawing of the application layer (App Layer) and system UI layer (System UI Layer) is ultimately refreshed onto the screen through the RootView.

[0023] Subviews: View nodes that are mounted in the view tree managed by the RootView, such as container views and various controls. The RootView usually completes drawing and event dispatch by traversing the view tree.

[0024] TE: Tick Engine, is a system-level timed event mechanism provided by LiteOS, used to periodically trigger task execution.

[0025] The technical solutions provided by the various embodiments of this application are described below with reference to the accompanying drawings.

[0026] like Figure 1As shown in the embodiments of this specification, a unified scheduling method for multi-scenario system display for wearable devices is provided, including: Step S100: During the system startup phase, initialize the composite display layer and bind the composite display layer to the root view of the system to construct the composite display scheduling module; wherein, the composite display scheduling module is a display scheduling module independent of the regular view tree and is not mounted to the root view in the form of a subview.

[0027] In practice, this application is based on the OpenHarmony LiteOS system. To cope with various display scenarios such as power-on and power-off animations, dim light animations, and system transient prompt animations, this application builds an independent compositing display scheduling module on top of the system rendering pipeline. This module is used to uniformly schedule various special display contents, thereby achieving high-priority rendering and collaborative control of input events, as well as unified resource management.

[0028] Specifically, during the system startup phase, the compositing display layer initialization interface is first called to bind the compositing display layer to the system's root view to ensure that it can be refreshed during the system rendering loop.

[0029] It should be noted that the application layer and the system UI layer are logically distinct layers, but their interface content is usually mounted under the RootView in the form of a view tree. It can be a direct or indirect subview of the RootView (a child node under a multi-level container). Finally, it is output to the screen through the unified refresh of the RootView. Unlike the conventional "view tree" mounting method, the composite display scheduling module of this application is an independent display scheduling module. It is logically isolated from the application layer / system UI layer. In implementation, it is not mounted to the conventional view tree of the RootView in the form of a RootView subview. Therefore, it does not participate in the measurement, layout and traversal drawing process of the RootView subview tree.

[0030] Step S200: When the root view executes the interface refresh, the regular view tree is first drawn to the screen buffer. After the regular view tree is drawn, the content to be displayed in the composite display scheduling module is drawn to the same screen buffer in an overlay manner through the top-level entry reserved by the root view.

[0031] In practice, during the rendering of a frame, the regular view tree first completes the drawing of the screen buffer. Then, at the end of the drawing phase of the same frame, the compositing display layer in the compositing display scheduling module is triggered to perform drawing operations through the reserved top-level drawing / refresh entry (such as DrawTop). The content to be displayed is drawn onto the same screen buffer in an overlay manner. By performing top-level overlay drawing on the existing buffer, it is ensured that its display content is always on the top layer, thereby achieving low coupling and isolation with the application layer and system interface layer, and ensuring the highest display priority.

[0032] To support the aforementioned overlay rendering, the compositing layer (i.e., the top layer, TopLayer) has completed the relevant configuration during the initialization phase: the system sets the clipping area and display position for overlay rendering (e.g., top-left corner coordinates, width, and height) for the compositing layer, and creates an internal control management structure to store and manage subsequently added controls, animations, or container views. Furthermore, the compositing layer registers itself as a global singleton to ensure a unique instance within the system, facilitating unified access and management across different modules or scenarios.

[0033] Step S300: Using the composite display scheduling module, perform unified scheduling for different types of scenes, including: In response to a scene switching request, the corresponding display content is loaded within the compositing display scheduling module according to the type of the target scene, and the display content is rendered and output on the top layer of the screen. The display status of the scene is managed according to preset priority rules; According to the preset event distribution strategy, the input event is passed to the synthesis and display scheduling module. If the synthesis and display scheduling module does not process the input event, the input event is passed to the application layer or the system interface layer. The scenarios include at least two of the following: power on / off animation scenario, low-light mode scenario, and system transient notification animation scenario.

[0034] During implementation, the synthetic display scheduling module supports switching between various high-priority display scenarios, such as power-on / off animation, low-light mode, and system transient prompt animation, while the smartwatch is running. To ensure user experience and system stability, the synthetic display scheduling module first identifies the current activity scenario and determines the target scenario type when switching scenarios.

[0035] Taking the transition from the power-on / off animation to the low-light mode as an example, the system will perform the following operations in sequence: Stop the display of controls and animations in the current scene, and release the occupied control, image, and sequence frame animation resources by calling the scene end interface; Initialize a new control tree and resources according to the needs of the target scenario, such as loading the display controls required for the dim light mode, and setting the display position, size and animation parameters; The control tree corresponding to the new scene is registered to the control management structure of the composite display scheduling module, and the first global refresh is performed through the refresh interface of RootView to ensure that the screen is displayed completely.

[0036] The composite display scheduling module coordinates the display order of different scenes through scene scheduling and priority arbitration mechanisms, and maintains the status information of the current active scene.

[0037] Regarding input event coordination, the Composite Display Scheduling Module employs a unified event distribution strategy: input events are preferentially passed to the Composite Display Scheduling Module. If the Module has not processed the event or it is not currently visible, the event is then passed down to the application layer / system interface layer. In specific scenarios, an event blocking or whitelist-based pass-through strategy can be switched. For example, during power-on / off animations, the Composite Display Scheduling Module temporarily blocks touch and button events to prevent accidental user actions from affecting animation playback. In low-light mode or system transient prompt animations, the Module captures touch events and custom triggers, prioritizing the processing of unprocessed events within its own controls before passing them down to the application layer. This ensures secure input event coordination, guaranteeing that interactions in different scenarios on the same screen do not conflict, while simultaneously meeting user operation needs.

[0038] It should be noted that "unprocessed" is usually determined based on the following circumstances: Interactive object not found: The event coordinates do not match any interactive display object within the Composite Display Scheduling Module. Hit but not consumed: After the event hits the object, the object and its associated processing chain do not return the "processed / consumed" flag (e.g., return false); Strategic non-processing: Based on preset rules (such as event type filtering, priority arbitration, whitelist pass-through, etc.), it is determined that the content will not be consumed by the synthesis and display scheduling module.

[0039] "Invisible" means that the composite display scheduling module does not participate in the event hit and processing in terms of space or state, mainly including: Overall Hidden / Inactive: The composition display scheduling module is hidden or inactive; The object does not exist or has been removed: The interactive object has been removed, destroyed, or no longer exists due to automatic hiding; Location not within valid visible area: Event coordinates are not within the valid display range of the composite display scheduling module, resulting in a failed hit.

[0040] In summary, this application, by adding a compositing and display scheduling module to the LiteOS system, enables top-level overlay rendering and compositing capabilities that can be started and stopped according to the scene without intruding on the application layer interface structure. It can support diverse scenes such as system-level animation, low-light animation, and system transient prompt animation, thereby significantly improving rendering efficiency, reducing power consumption, and ensuring the continuity of interaction while ensuring performance and stability. It is especially suitable for resource-constrained embedded LiteOS environments.

[0041] In some embodiments, the rendering scheduling method of the composite display scheduling module includes: autonomous scheduling and system tick-driven scheduling; In the autonomous scheduling mode, the composite display scheduling module maintains refresh logic internally and updates the display content as needed through an internal timer or event triggering mechanism, including: traversing the control management list before each refresh, calculating the visibility and display area of ​​each control, determining the area to be updated, and submitting the area to be updated to the root view for local refresh; In the system beat-driven mode, the composite display scheduling module receives system timed events, recalculates the area to be updated based on the current scene and control state during refresh, and submits the area to be updated to the root view for partial refresh.

[0042] Specifically, the compositing display scheduling module supports two rendering scheduling methods: autonomous scheduling and system tick engine (TE).

[0043] In autonomous scheduling mode, the composition display scheduling module maintains refresh logic internally, updating the displayed content as needed through internal timers or event triggering mechanisms. Before each refresh, the composition display scheduling module traverses the control management list, calculates the visibility and display area of ​​each control, and submits the changed areas (such as rectangular areas) to the RootView. The RootView calls the drawing interface (such as DrawTop) based on the submitted rectangular areas to draw the controls onto the screen buffer, achieving partial refresh and effectively avoiding unnecessary full-screen redraws, thereby reducing GPU and CPU load.

[0044] In TE-driven mode, the compositing display layer (i.e., the top layer, TopLayer) in the compositing display scheduling module receives system timed events. Whenever the Tick Engine generates a refresh signal, the compositing display scheduling module recalculates the rectangular area that needs to be updated based on the current scene and control state, and calls the RootView interface to complete the drawing operation. Through TE callbacks, the compositing display scheduling module can achieve high frame rate animation playback and timed control updates, while avoiding system overhead caused by frequent startup of the autonomous timer.

[0045] In some embodiments, a corresponding driving strategy is selected based on the type of the current scenario, including: If the current scene is a power-on / off animation scene, the autonomous scheduling mode is adopted to ensure continuous frame updates; If the current scene is a low-light mode scene, the system clock drive mode is adopted to reduce system power consumption; If the current scenario is a transient prompt animation scenario of the system, then the autonomous scheduling mode or the system beat-driven mode is selected according to the interaction requirements of the animation.

[0046] In implementation, autonomous scheduling and TE driving are not fixed. The composite display scheduling module can select an appropriate driving strategy according to the scene type. Specifically: The power-on and power-off animations are autonomously scheduled to ensure continuous frame updates; In Alternate Distance (AOD) scenarios, a low-frequency or event-triggered TE mechanism is used to reduce power consumption. The system's transient prompt animation scenarios can flexibly choose between TE-driven or self-scheduled refresh to achieve on-demand refresh based on interaction and animation requirements. For parts containing continuous animation content (such as sequence frame animation controls), the module adopts TE-driven mode. According to the playback parameters defined in the JSON protocol file (such as frame interval of 50ms, loop mode, etc.), the current frame of the control is refreshed periodically through TE callbacks to ensure smooth animation playback while avoiding the additional system overhead caused by frequent startup of the self-scheduled timer. For static content (such as text controls), self-scheduled refresh is adopted, and partial refresh is only performed when the event is triggered. This can ensure timely interaction response while minimizing the power consumption overhead caused by invalid refreshes.

[0047] In some embodiments, the refresh strategy of the composite display scheduling module includes: Perform a global refresh upon first display or scene switch; When performing a partial refresh, the changed areas of multiple controls are merged and clipped, and the merged changed areas are submitted to the root view for partial refresh. When the area of ​​the merged changed region exceeds a preset threshold, it degrades to a full-screen refresh to ensure screen consistency.

[0048] During implementation, such as Figure 2 As shown, during the first display after the system startup initialization is completed, or when a scene changes, such as switching from the power-on / off animation to the low-light mode, the composite display scheduling module performs a global refresh to ensure that all controls are drawn completely onto the screen at once, avoiding problems such as incomplete images or inconsistent displays caused by partial updates.

[0049] During normal operation, to reduce GPU and CPU load, the composite display scheduling module adopts a partial refresh mechanism. During partial refresh, since the changing areas of multiple controls may overlap or be scattered, multiple adjacent or overlapping changing areas can be merged into one or more larger areas, thereby reducing the number of calls to the subsequent drawing interface. It can also identify redundant parts in the area that do not need to be actually updated. Finally, the optimized changing areas are submitted to the root view, and these areas are drawn through the reserved top-level drawing / refresh entry, thereby effectively avoiding the unnecessary overhead caused by full-screen redraw.

[0050] When the area of ​​the merged change region exceeds a preset threshold, the composite display scheduling module automatically degrades to full-screen refresh to ensure screen consistency.

[0051] By employing a layered refresh strategy, we can ensure complete rendering of the scene during scene transitions, significantly reduce the rendering load during daily operation through region merging, and prevent over-optimization through threshold judgment, thereby achieving efficient and stable rendering output in resource-constrained embedded environments.

[0052] In some embodiments, the multi-scenario system display unified scheduling method further includes at least one of the following optimization mechanisms: A preset hiding time is set for controls that need to be automatically hidden. When the control reaches the preset hiding time, the control is removed from the control tree and the resources occupied by the control are released. Based on the lazy loading mechanism, for controls that enter the visible area of ​​the screen for the first time, an image buffer or animation frame resource is allocated to the control when the drawing operation is performed; Centralized resource management is performed based on the lifecycle of controls, including: requesting resources when adding controls to the composite display scheduling module, reclaiming resources when removing controls from the composite display scheduling module or switching scenes, and reusing reusable resources.

[0053] In implementation, to reduce power consumption and save screen resources, the composite display scheduling module integrates several optimization mechanisms, including: Automatic control hiding mechanism: The composition display scheduling module uses the HALTick timer to preset the autohide event for controls. When the preset hiding time is reached, the composition display scheduling module automatically removes the control from the control tree and releases the image, animation frame and other related resources it occupies. It is suitable for scenarios such as temporary display of prompt bars and status cards in system transient prompt animations, avoiding invalid refresh and resource occupation caused by controls staying on the screen for a long time.

[0054] Lazy loading mechanism: Resource management unifies the loading, path copying and release of controls, supports lazy loading of controls or animation frames, and only allocates resources when the control is first displayed, effectively avoiding unnecessary memory occupation and improving system startup speed and running efficiency.

[0055] Centralized resource management mechanism: The compositing display scheduling module centrally manages the lifecycle of controls, allocates resources when adding controls to the compositing display scheduling module, and releases controls and resources when deleting or switching scenes, ensuring memory safety and system stability.

[0056] Through the above mechanisms, the composite display scheduling module achieves independent rendering across scenes with high priority, and avoids conflicts with application layer rendering. At the same time, it provides standard interfaces to support subsequent power-on and power-off animations, low-light mode, or system transient prompt animations, achieving unified management and efficient scheduling.

[0057] In some embodiments, the power-on / off animation scene includes: During the power-on or restart phase of the device, the synthetic display scheduling module is initialized, power-on and power-off animation resources are loaded, memory is allocated for each frame of image, and display position and animation playback parameters are set. During animation playback, input devices and application-layer rendering are disabled until the animation finishes playing or the user actively triggers an exit.

[0058] like Figure 3 As shown, during the device power-on or restart phase, the system first calls the `power_animation_start` interface to initialize the composite display layer and load the power-on / off animation resources. These animation resources include sequence frame image information and a background display container. The sequence frame images are used to represent dynamic effects, while the background display container is used to hold animation controls and provide a unified background. The composite display layer, as an independent top-level view, draws the animation content onto the screen and displays the image through the `RootView`'s refresh interface.

[0059] To ensure the priority and stability of animation playback, the system temporarily disables input devices and application-layer rendering during animation playback. Input device disabling is controlled by InputDeviceManager, preventing user actions from interfering with animation playback. Simultaneously, disabling application-layer rendering prevents background applications from drawing on the screen buffer, thus avoiding screen overwriting. When the animation finishes playing or the user actively exits, the system re-enables input devices and resumes application-layer rendering, ensuring normal system interaction.

[0060] When an animation loads, the system allocates memory for each frame and manages playback through UIImageAnimatorView. If centered display is required, the composition display scheduling module obtains the image's width and height through CacheManager, calculates the center position, and sets the display area. Animation state management includes inter-frame update interval (SetTimeOfUpdate), loop playback (SetRepeat), and size fixation (SetSizeFixed).

[0061] Frame refresh is controlled by the internal mechanism of the compositing display scheduling module, independent of the TE. Instead, it continuously calls power_animation_handle to calculate the refresh rectangle and draws it using RootView's DrawTop, while simultaneously calling BaseGfxEngine to update the frame buffer, ensuring that the animation is synchronized with the screen and avoiding ghosting or flickering. A full-screen refresh is performed on the first display, while partial refreshes are used at other times to reduce system load.

[0062] When the animation ends, power_animation_stop is called to release the control, image, and background display containers, and to restore the input device and application layer rendering, ensuring that the system enters a normal working state. This achieves low-power, high-priority, and smooth power-on / off animation playback, while also supporting looping, frame rate control, and centered display.

[0063] In some embodiments, the low-light mode scenario includes: In response to the command to enter low-light mode, the control and image resources required for low-light mode are loaded through the composite display scheduling module and added to the internal management structure of the composite display scheduling module; The composite display scheduling module adjusts the refresh rate according to energy-saving strategies, screen status, or user settings. When the content of the control changes, it calculates the changed area and performs a local refresh. In the low-light mode, the display priority of controls is higher than that of the application layer. When a system event is detected, the corresponding controls are updated or the animation is activated according to the event type, while keeping the state of other controls unchanged.

[0064] like Figure 4 As shown, when the smartwatch enters low-light mode, the composite display scheduling module takes over the low-power display control of the screen, enabling continuous display of core information (such as time, notification icons, or status indicators) without activating the entire application interface. The composite display scheduling module first loads the controls and image resources required for low-light mode through the AOD initialization interface, including clock controls, status icons, background colors, or transparent containers, and adds these controls to the internal management structure of the composite display scheduling module to uniformly manage their lifecycle and refresh logic.

[0065] The composite display scheduling module dynamically adjusts the refresh rate based on the screen's static state, energy-saving strategies, or user settings, performing partial refreshes only when control content changes, such as a second hand movement or notification updates, reducing CPU / GPU load. Controls in low-light mode have higher priority than the application layer, ensuring the display is not obscured. When system events are triggered (alarms, notifications, or user wake-up), the composite display scheduling module can update controls or activate animations while maintaining the state of other controls. Controls and resources are allocated and released uniformly, using lazy loading and reference counting mechanisms to ensure stability and performance in low-power environments.

[0066] In some embodiments, the system transient cue animation scene includes: In response to the command to enter the system transient prompt animation, the preset protocol file is parsed by the synthesis display scheduling module, and a control tree is dynamically generated according to the layout and control attributes described in the protocol file; Each control in the control tree is instantiated as a corresponding UI control object, and the display parameters of each control are set according to the attributes defined in the protocol file; If it is an animated control, the playback speed, loop mode and frame rate are set according to the playback parameters specified in the protocol file, and the control frame is refreshed periodically through an internal timer.

[0067] like Figure 5 As shown, in the system's transient tooltip animation display scenario, the composition display scheduling module is responsible for parsing the JSON protocol file and dynamically generating a control tree from the described layout and control attributes to achieve the interactive tooltip display at the top level of the screen. The JSON protocol contains information such as control type, position, size, style, and animation. The composition display scheduling module provides a parsing module that instantiates each control into a corresponding UI control object, including static image controls (image), text label controls (label), and sequence frame animation controls (image_animator). Each control reads the attributes defined in the JSON during generation, such as position (X, Y coordinates), size (width, height), corner radius, background color, font, and text color, thereby accurately presenting the design layout on the screen.

[0068] For the animation control (image_animator), the composition display scheduling module sets the playback speed, loop mode and frame rate according to the playback parameters specified in the JSON, and refreshes the current frame of the control periodically through an internal timer to ensure smooth animation.

[0069] The Composite Display Scheduling Module supports touch events, gesture recognition, and custom triggers, such as double-tap activation or swipe trigger. The event distribution mechanism follows a priority delivery principle: it is first delivered to controls within the Composite Display Scheduling Module. If the control is not processed or the Composite Display Scheduling Module is not currently visible, the event continues to be passed down to the application layer, achieving secure collaboration of input events.

[0070] Through the above mechanism, when the system's transient prompt animation is displayed on the top layer of the screen, it can simultaneously ensure the responsiveness of user interaction and the normal transmission of application layer events. Resource management uniformly handles control loading, path copying, and release, supports lazy loading of controls or animation frames, and only allocates resources when the control is first displayed, avoiding unnecessary memory occupation.

[0071] In some embodiments, managing the display state of the scene according to a preset priority rule includes: Assign a unique scene identifier and corresponding priority to each scene; When a higher priority scene with a higher priority than the current scene is detected, the synthesis display scheduling module performs a suspension operation on the current scene according to a preset arbitration rule. The suspension operation includes: hiding, pausing refresh, or releasing resources. When the high-priority scene exits, the suspended scene is restored or the controls and resources of the suspended scene are rebuilt, and the first global refresh is triggered.

[0072] like Figure 6 As shown, the composite display scheduling module coordinates the display order of different scenes through scene scheduling and priority arbitration mechanisms, and maintains the status information of the currently active scene. When a high-priority scene enters, the composite display scheduling module performs operations such as hiding, pausing refresh, or releasing resources for low-priority scenes according to preset arbitration rules. When a high-priority scene exits, the composite display scheduling module restores the suspended scene or rebuilds its controls and resources, and triggers the first global refresh to ensure display consistency. Each scene is assigned a unique scene identifier and priority in the composite display scheduling module. The composite display scheduling module automatically determines the display order and executes the scene switching process based on the scene identifier, priority, and system status.

[0073] The compositing display scheduling module of this application provides unified resource management capabilities across scenes. It centrally requests and releases control, image, and animation data according to the control's lifecycle, and executes resource reclamation and reuse strategies during scene switching. This avoids memory spikes and resource contention caused by different display scenes requesting display buffers separately or repeatedly loading animation frame resources. The compositing display scheduling module combines a local refresh rectangle strategy to draw only the changing areas and works in conjunction with scene priority arbitration to determine the rendering order, thereby reducing CPU / GPU load and lowering power consumption.

[0074] This application's modular interface supports dynamic control tree loading, on-demand initialization, and automatic control release, enabling cross-scene high-priority display and input event collaboration while maintaining high performance and low power consumption. Through the above mechanism, the composite display scheduling module achieves unified management, high-priority rendering, and event collaboration across multiple smartwatch scenarios, significantly improving rendering efficiency, reducing power consumption, and ensuring user interaction continuity. It is suitable for resource-constrained LiteOS embedded environments.

[0075] Based on the same inventive concept, this application also provides a unified scheduling device for multi-scene system display of wearable devices, comprising: The composite display scheduling module construction unit is used to initialize the composite display layer during the system startup phase and bind the composite display layer to the root view of the system to construct the composite display scheduling module; wherein, the composite display scheduling module is a display scheduling module independent of the regular view tree and is not mounted to the root view as a subview; The overlay drawing control unit is used to first draw the content to be displayed in the composite display scheduling module to the same screen buffer by drawing the content from the regular view tree to the screen buffer in an overlay manner during the interface refresh process of the root view. The scene scheduling unit is used to uniformly schedule different types of scenes using the composite display scheduling module, including: The scene switching unit is used to respond to the scene switching request, load the corresponding display content inside the compositing display scheduling module according to the type of the target scene, and control the display content to be rendered and output on the top layer of the screen; The priority management unit is used to manage the display status of the scene according to preset priority rules; An event distribution unit is used to transmit input events to the synthesis and display scheduling module according to a preset event distribution strategy. If the synthesis and display scheduling module does not process the input event, it transmits the input event to the application layer or the system interface layer. The scenarios include at least two of the following: power on / off animation scenario, low-light mode scenario, and system transient notification animation scenario.

[0076] This invention achieves unified management and high-priority display of various display scenarios, such as power-on / off animations, low-light animations, and system transient prompt animations, by adding a composite display scheduling module to the LiteOS system. At the same time, it improves rendering efficiency, reduces power consumption, ensures that animation playback and system input events do not interfere with each other, and facilitates system expansion and maintenance.

[0077] In this specification, the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the descriptions of the embodiments described later are relatively simple, and relevant parts can be referred to the descriptions of the foregoing embodiments.

[0078] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A unified scheduling method for multi-scene system display in wearable devices, characterized in that, include: During the system startup phase, the composite display layer is initialized and bound to the system's root view to construct the composite display scheduling module; wherein, the composite display scheduling module is a display scheduling module independent of the regular view tree and is not mounted to the root view as a subview; When the root view performs an interface refresh, the regular view tree is first drawn to the screen buffer. After the regular view tree is drawn, the content to be displayed in the composite display scheduling module is drawn to the same screen buffer in an overlay manner through the top-level entry reserved by the root view. The composite display scheduling module is used to uniformly schedule different types of scenes, including: In response to a scene switching request, the corresponding display content is loaded within the compositing display scheduling module according to the type of the target scene, and the display content is rendered and output on the top layer of the screen. The display status of the scene is managed according to preset priority rules; According to the preset event distribution strategy, the input event is passed to the synthesis and display scheduling module. If the synthesis and display scheduling module does not process the input event, the input event is passed to the application layer or the system interface layer. The scenarios include at least two of the following: power on / off animation scenario, low-light mode scenario, and system transient notification animation scenario.

2. The unified scheduling method for multi-scene system display according to claim 1, characterized in that, The rendering scheduling methods of the composite display scheduling module include: autonomous scheduling and system beat-driven scheduling; In the autonomous scheduling mode, the composite display scheduling module maintains refresh logic internally and updates the display content as needed through an internal timer or event triggering mechanism, including: traversing the control management list before each refresh, calculating the visibility and display area of ​​each control, determining the area to be updated, and submitting the area to be updated to the root view for local refresh; In the system beat-driven mode, the composite display scheduling module receives system timed events, recalculates the area to be updated based on the current scene and control state during refresh, and submits the area to be updated to the root view for partial refresh.

3. The unified scheduling method for multi-scene system display according to claim 2, characterized in that, Select the appropriate driving strategy based on the type of the current scenario, including: If the current scene is a power-on / off animation scene, the autonomous scheduling mode is adopted to ensure continuous frame updates; If the current scene is a low-light mode scene, the system clock drive mode is adopted to reduce system power consumption; If the current scenario is a transient prompt animation scenario of the system, then the autonomous scheduling mode or the system beat-driven mode is selected according to the interaction requirements of the animation.

4. The unified scheduling method for multi-scene system display according to claim 2, characterized in that, The refresh strategy of the composite display scheduling module includes: Perform a global refresh upon first display or scene switch; When performing a partial refresh, the changed areas of multiple controls are merged and clipped, and the merged changed areas are submitted to the root view for partial refresh. When the area of ​​the merged changed region exceeds a preset threshold, it degrades to a full-screen refresh to ensure screen consistency.

5. The unified scheduling method for multi-scene system display according to claim 2, characterized in that, The unified scheduling method for multi-scenario system display also includes at least one of the following optimization mechanisms: A preset hiding time is set for controls that need to be automatically hidden. When the control reaches the preset hiding time, the control is removed from the control tree and the resources occupied by the control are released. Based on the lazy loading mechanism, for controls that enter the visible area of ​​the screen for the first time, an image buffer or animation frame resource is allocated to the control when the drawing operation is performed; Centralized resource management is performed based on the lifecycle of controls, including: requesting resources when adding controls to the composite display scheduling module, reclaiming resources when removing controls from the composite display scheduling module or switching scenes, and reusing reusable resources.

6. The unified scheduling method for multi-scene system display according to claim 1, characterized in that, The power-on / off animation scenes include: During the power-on or restart phase of the device, the synthetic display scheduling module is initialized, power-on and power-off animation resources are loaded, memory is allocated for each frame of image, and display position and animation playback parameters are set. During animation playback, input devices and application-layer rendering are disabled until the animation finishes playing or the user actively triggers an exit.

7. The unified scheduling method for multi-scene system display according to claim 1, characterized in that, The low-light mode scenarios include: In response to the command to enter low-light mode, the control and image resources required for low-light mode are loaded through the composite display scheduling module and added to the internal management structure of the composite display scheduling module; The composite display scheduling module adjusts the refresh rate according to energy-saving strategies, screen status, or user settings. When the content of the control changes, it calculates the changed area and performs a local refresh. In the low-light mode, the display priority of controls is higher than that of the application layer. When a system event is detected, the corresponding controls are updated or the animation is activated according to the event type, while keeping the state of other controls unchanged.

8. The unified scheduling method for multi-scene system display according to claim 1, characterized in that, The system's transient notification animation scenarios include: In response to the command to enter the system transient prompt animation, the preset protocol file is parsed by the synthesis display scheduling module, and a control tree is dynamically generated according to the layout and control attributes described in the protocol file; Each control in the control tree is instantiated as a corresponding UI control object, and the display parameters of each control are set according to the attributes defined in the protocol file; If it is an animated control, the playback speed, loop mode and frame rate are set according to the playback parameters specified in the protocol file, and the control frame is refreshed periodically through an internal timer.

9. The unified scheduling method for multi-scene system display according to claim 1, characterized in that, Managing the display state of the scene according to a preset priority rule includes: Assign a unique scene identifier and corresponding priority to each scene; When a higher priority scene with a higher priority than the current scene is detected, the synthesis display scheduling module performs a suspension operation on the current scene according to a preset arbitration rule. The suspension operation includes: hiding, pausing refresh, or releasing resources. When the high-priority scene exits, the suspended scene is restored or the controls and resources of the suspended scene are rebuilt, and the first global refresh is triggered.

10. A unified scheduling device for multi-scene system display of wearable devices, characterized in that, include: The composite display scheduling module construction unit is used to initialize the composite display layer during the system startup phase and bind the composite display layer to the root view of the system to construct the composite display scheduling module; wherein, the composite display scheduling module is a display scheduling module independent of the regular view tree and is not mounted to the root view as a subview; The overlay drawing control unit is used to first draw the content to be displayed in the composite display scheduling module to the same screen buffer by drawing the content from the regular view tree to the screen buffer in an overlay manner during the interface refresh process of the root view. The scene scheduling unit is used to uniformly schedule different types of scenes using the composite display scheduling module, including: The scene switching unit is used to respond to the scene switching request, load the corresponding display content inside the compositing display scheduling module according to the type of the target scene, and control the display content to be rendered and output on the top layer of the screen; The priority management unit is used to manage the display status of the scene according to preset priority rules; An event distribution unit is used to transmit input events to the synthesis and display scheduling module according to a preset event distribution strategy. If the synthesis and display scheduling module does not process the input event, it transmits the input event to the application layer or the system interface layer. The scenarios include at least two of the following: power on / off animation scenario, low-light mode scenario, and system transient notification animation scenario.

Images