Multi-terminal heterogeneous equipment-oriented dynamic rendering optimization method and equipment for swan UI (User Interface) framework

Abstract

The invention discloses a multi-terminal heterogeneous equipment-oriented dynamic rendering optimization method and equipment for a swan UI (User Interface) frame, and relates to the technical field of computers. The method comprises the following steps: receiving a rendering request for each heterogeneous device, and constructing an initial UI component tree corresponding to each heterogeneous device according to UI interface data in the rendering request; obtaining performance parameters and state parameters of each heterogeneous device, wherein the state parameters at least comprise a memory available space, ambient light intensity, device surface temperature and touch interference resistance; calculating a GPU capability index based on the performance parameters; performing differentiation processing on each initial UI component tree in combination with the state parameter and the GPU capability index to generate a target UI component tree corresponding to each heterogeneous device; and performing rendering pipeline adaptation on each target UI component tree, generating a rendering instruction corresponding to each heterogeneous device, and controlling each heterogeneous device to perform interface rendering according to the corresponding rendering instruction. By implementing the technical scheme provided by the invention, the rendering performance of the heterogeneous equipment is improved while the development and maintenance cost is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method and device for dynamic rendering optimization of the HarmonyOS UI framework for multi-device heterogeneous devices. Background Technology

[0002] With the development of industrial automation, industrial sites are placing higher demands on equipment monitoring and operation interfaces. Industrial operation interfaces need to run simultaneously on various heterogeneous devices such as industrial PCs, industrial tablets, and handheld terminals to meet the monitoring needs of different scenarios. Currently, mainstream industrial interface development frameworks such as ArkUI can support basic cross-device interface development.

[0003] In existing technologies, developers typically need to develop separate interface code for different types of terminal devices. For example, in a factory's production line monitoring system, a full-version monitoring interface runs on an industrial PC, a simplified version runs on an industrial tablet, and a streamlined version runs on a handheld terminal. These three interfaces need to be written and maintained separately. This approach leads to redundant development of interface code, which not only increases the workload but also easily causes problems such as interface response delays and operational lag due to differences in rendering performance between different heterogeneous devices, thus affecting operational efficiency in the industrial field. Summary of the Invention

[0004] In view of this, this application provides a method and device for dynamic rendering optimization of the HarmonyOS UI framework for multi-terminal heterogeneous devices.

[0005] Firstly, this application provides a method for optimizing dynamic rendering of the HarmonyOS UI framework for multi-device heterogeneous devices, the method comprising: Receive rendering requests for each heterogeneous device, and construct an initial UI component tree corresponding to each heterogeneous device based on the UI interface data in the rendering request; The performance parameters and status parameters of each of the heterogeneous devices are obtained, and the status parameters include at least the available memory space, ambient light intensity, device surface temperature, and tactile interference resistance. Calculate the GPU capability index based on the aforementioned performance parameters; The initial UI component trees are differentiated by combining the state parameters and the GPU capability index to generate target UI component trees corresponding to each heterogeneous device; The rendering pipeline is adapted for each target UI component tree to generate rendering instructions for each heterogeneous device, and each heterogeneous device is controlled to render the interface according to the corresponding rendering instructions.

[0006] By adopting the above technical solution, rendering requests from heterogeneous devices are received and an initial UI component tree is constructed. The GPU capability index is calculated by combining real-time acquired device performance and status parameters. The initial UI component tree is then differentiated to generate a target UI component tree. Finally, the rendering pipeline is adapted to generate targeted rendering instructions. This achieves adaptive rendering optimization for different heterogeneous devices, eliminating the need to develop separate interface code for different types of terminal devices, thus reducing development and maintenance costs. Simultaneously, by sensing device status in real-time and performing differentiated processing, the interface rendering can be dynamically adjusted according to the actual performance of the device and the working environment. This effectively solves problems such as interface response delays and operational lag caused by performance differences in heterogeneous devices, improving operational efficiency in industrial settings.

[0007] Optionally, calculating the GPU capability index based on the performance parameters includes: Extract the GPU's floating-point operations per second, memory bandwidth, and thermal throttling coefficient from the performance parameters. Substitute the performance parameters into the first calculation formula to obtain the GPU capability index; The first calculation formula is: In the formula, GCI represents the GPU capability index, GFLOPS represents the GPU's floating-point operations per second, and VRAM represents the GPU's floating-point operations per second. Bandwidth This represents the memory bandwidth, and Thermal_Throttle_Factor represents the thermal throttling factor, which is equal to the GPU's rated frequency divided by the GPU's current actual frequency.

[0008] Optionally, the step of combining the state parameters and the GPU capability index to differentiate each initial UI component tree and generate a target UI component tree corresponding to each heterogeneous device includes: The GPU computing power level of each heterogeneous device is determined based on the GPU capability index. The GPU computing power level, available memory space, ambient light intensity, device surface temperature, and tactile interference resistance in the status parameters are compared with the corresponding trigger threshold conditions. When any state parameter satisfies the corresponding trigger threshold condition, the initial UI component tree of the corresponding heterogeneous device is optimized according to the preset degradation rules to obtain the target UI component tree.

[0009] Optionally, when any state parameter satisfies the corresponding trigger threshold condition, the initial UI component tree of the corresponding heterogeneous device is optimized according to preset degradation rules, including: When the GPU computing power level is lower than the preset computing power level, the dynamic components in the initial UI component tree of the corresponding heterogeneous device are downgraded to static components and the drawing batches are merged. When the available memory space is lower than a preset memory space threshold, the special effects rendering component of the initial UI component tree of the corresponding heterogeneous device is removed; When the surface temperature of the device reaches different preset temperature thresholds, the initial UI component tree of the corresponding heterogeneous device is optimized according to the temperature classification control strategy corresponding to the different preset temperature thresholds. When the ambient light intensity is higher than the preset light intensity threshold, the components in the initial UI component tree of the corresponding heterogeneous device are switched to a high contrast display mode. The high contrast display mode is a display mode that uses color channel weighted calculation and light and dark mapping with preset brightness weight coefficient. When the touch resistance to interference is higher than a preset interference threshold, it is determined that a touch event has been detected, and the initial UI component tree of the corresponding heterogeneous device is controlled to enable signal filtering processing and adjacent touch points are merged.

[0010] Optionally, when the surface temperature of the device reaches different preset temperature thresholds, the initial UI component tree of the corresponding heterogeneous device is optimized according to the temperature grading control strategy corresponding to the different preset temperature thresholds, including: When the surface temperature of the device reaches the first preset temperature threshold, unnecessary rendering effects in the initial UI component tree of the corresponding heterogeneous device are disabled. When the surface temperature of the device reaches the second preset temperature threshold, the processor operating frequency is reduced and the three-dimensional transformation effect in the initial UI component tree is disabled. When the surface temperature of the device reaches the third preset temperature threshold, the system protection mechanism is activated, wherein the first preset temperature threshold is less than the second preset temperature threshold, and the second preset temperature threshold is less than the third preset temperature threshold.

[0011] Optionally, when the touch interference resistance is higher than a preset interference threshold, a touch event is detected, and the initial UI component tree of the corresponding heterogeneous device is controlled to enable signal filtering processing, and adjacent touch points are merged, including: When the touch resistance to interference is higher than a preset interference threshold, it is determined that a touch event has been detected, and the original touch point coordinate sequence of the touch event is collected; Perform Kalman filtering on the original touch point coordinate sequence to obtain the filtered touch point coordinate sequence; Based on a preset distance threshold, adjacent touch points in the filtered touch point coordinate sequence are clustered and merged to generate a merged touch point sequence. The merged touch point sequence is subjected to cubic spline interpolation to generate a smooth touch trajectory; The touch trajectory is mapped to the touch response area corresponding to the initial UI component tree of the heterogeneous device, and the corresponding interface interaction event is triggered.

[0012] Optionally, the rendering pipeline is adapted for each of the target UI component trees to generate rendering instructions corresponding to each of the heterogeneous devices, including: The rendering pipeline is adapted for each of the target UI component trees to obtain the final UI component tree; The final UI component tree is converted into a linear operation instruction list, wherein each operation instruction in the linear operation instruction list corresponds to a component operation and contains a unique sequence identifier; By comparing the differences between the linear operation instruction lists of the initial UI component tree and the final UI component tree of each heterogeneous device, a minimized opcode sequence is generated. The opcode sequence contains information on component movement, attribute updates, and subtree additions and deletions. The opcode sequence is then compressed and encrypted to generate a difference data packet. Rendering instructions for each of the heterogeneous devices are generated based on the difference data packets.

[0013] A second aspect of this application provides an electronic device optimized for dynamic rendering of the HarmonyOS UI framework for multi-device heterogeneous devices. The electronic device includes: one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic device optimized for dynamic rendering of the HarmonyOS UI framework for multi-device heterogeneous devices to perform the method described in the first aspect and any possible implementation thereof.

[0014] A third aspect of this application provides a computer program product containing instructions that, when run on an electronic device dynamically rendered and optimized for multi-device heterogeneous devices using the HarmonyOS UI framework, causes the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0015] A fourth aspect of this application provides a computer-readable storage medium including instructions that, when executed on an electronic device dynamically rendered and optimized for multi-device heterogeneous devices using the HarmonyOS UI framework, cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0016] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: This application receives rendering requests from heterogeneous devices and constructs an initial UI component tree, calculates the GPU capability index by combining real-time acquired device performance parameters and status parameters, then performs differentiated processing on the initial UI component tree to generate a target UI component tree, and finally performs rendering pipeline adaptation to generate targeted rendering instructions, thereby achieving adaptive rendering optimization for different heterogeneous devices. This eliminates the need to develop separate interface code for different types of terminal devices, reducing development and maintenance costs. Simultaneously, by sensing device status in real time and performing differentiated processing, the interface rendering can be dynamically adjusted according to the actual performance of the device and the working environment, effectively solving problems such as interface response delay and operation lag caused by performance differences in heterogeneous devices, and improving operational efficiency in industrial settings. Attached Figure Description

[0017] Figure 1 This is a system architecture diagram of HarmonyOS UI framework dynamic rendering optimization for multi-terminal heterogeneous devices provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a dynamic rendering optimization method for HarmonyOS UI framework for multi-terminal heterogeneous devices provided in an embodiment of this application. Figure 3 This is a schematic diagram of a dynamic rendering decision-making process provided in an embodiment of this application; Figure 4 This is an exemplary UI component tree degradation mapping diagram provided in an embodiment of this application; Figure 5 This is a schematic diagram of an exemplary hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0019] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0020] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0021] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0022] Please see Figure 1 This is a system architecture diagram for dynamic rendering optimization of the HarmonyOS UI framework for multi-terminal heterogeneous devices, provided in an embodiment of this application.

[0023] like Figure 1 As shown, the system architecture includes five main modules: dynamic rendering decision engine, HarmonyOS rendering engine interface, application layer, hardware abstraction layer, and industrial adaptation extension.

[0024] The dynamic rendering decision engine is responsible for formulating the overall rendering strategy, comprising three sub-modules: a degradation rule base, a device performance analysis module, and a pipeline reorganization strategy. The degradation rule base stores various rendering degradation schemes, the device performance analysis module evaluates device status in real time, and the pipeline reorganization strategy dynamically adjusts the rendering pipeline based on performance analysis results. The HarmonyOS rendering engine interface module is responsible for the specific rendering implementation, including three core functions: skipping shadow calculations, batch rendering, and animation degradation. This module receives control commands from the decision engine and returns feedback information based on the actual rendering effect, achieving dynamic optimization of the rendering process. The application layer adopts the ArkUI component tree structure, responsible for managing interface layout and interaction logic. The hardware abstraction layer includes GPU drivers and light-sensing data sensors, providing underlying hardware support. The industrial adaptation extension module provides strong light color compensation and oil-resistant touch optimization functions, specifically optimized for industrial environments. The modules communicate bidirectionally through control flow and feedback flow. The control flow transmits rendering decisions and commands from top to bottom, while the feedback flow returns execution status and performance data from bottom to top, forming a closed-loop optimization system. This architecture design ensures that the system can dynamically adjust its rendering strategy based on device capabilities and operating status, optimizing resource usage while maintaining interface responsiveness.

[0025] Please refer to Figure 2This is a flowchart illustrating a dynamic rendering optimization method for HarmonyOS UI framework for multi-device heterogeneous devices, provided in an embodiment of this application. This method can be implemented using a computer program, a microcontroller, or run on a HarmonyOS UI framework dynamic rendering optimization system for multi-device heterogeneous devices. The computer program can be integrated into the computer device or run as a standalone utility application. Specifically, the method includes steps 10 to 50, as follows: Step 10: Receive rendering requests for each heterogeneous device, and construct the initial UI component tree corresponding to each heterogeneous device based on the UI interface data in the rendering request.

[0026] In this application embodiment, heterogeneous devices refer to terminal devices that use different hardware architectures, operating systems, or processor types, such as industrial control computers, industrial tablets, and handheld terminals. These devices have significant differences in computing power, display characteristics, and interaction methods.

[0027] The initial UI component tree refers to a tree-shaped data structure built based on the UI interface data in the rendering request. Each node in this tree structure represents a UI component (such as a button, text box, chart, etc.). The parent-child relationship between nodes represents the hierarchical nesting relationship of the components. Each component node contains attribute information such as position, style, and event handling, which is used to describe the complete layout and interaction logic of the interface.

[0028] Specifically, due to the varying interface rendering requirements of different heterogeneous devices, it is necessary to first uniformly receive and process these rendering requests. The system receives rendering requests from various heterogeneous devices (such as industrial PCs, industrial tablets, and handheld terminals), each containing UI interface data to be displayed. The rendering request acquisition module parses this UI interface data, extracting component types, attribute information, layout relationships, etc., and constructs a tree-like data structure, i.e., the initial UI component tree. During the construction process, a root node is first created as the container for the entire interface. Then, the component information in the UI interface data is parsed layer by layer, creating each UI component (such as buttons, text boxes, charts, etc.) as a node in the tree, and setting its position, style, event handling, and other attributes. For components with parent-child relationships, their hierarchical nesting relationship is represented by establishing reference relationships between nodes. For example, when a panel component contains multiple child controls, the node corresponding to the panel becomes the parent node of these child control nodes. In this way, the complete structure of the UI interface is converted into a tree-like data structure that can be uniformly processed by the system, providing a foundation for subsequent differentiated processing based on device capabilities. This unified representation based on a tree structure makes it easier for the system to perform CRUD operations on components, and also facilitates subsequent rendering optimization and differentiation processing, thereby improving the efficiency of interface rendering.

[0029] Step 20: Obtain the performance parameters and status parameters of each heterogeneous device. The status parameters include at least the available memory space, ambient light intensity, device surface temperature, and tactile interference resistance.

[0030] Specifically, the system obtains performance parameters by calling the device driver's query interface, including hardware configuration information such as CPU clock speed, number of cores, GPU model, video memory size, rendering pipeline type, screen resolution, and refresh rate. These performance parameters reflect the device's basic hardware capabilities.

[0031] The system acquires state parameters by monitoring various sensor data from the device in real time. It obtains the current available memory space through the memory management interface to determine whether to reduce the resource consumption of interface rendering; it acquires ambient light intensity values ​​through the light sensor to adjust the brightness and contrast of the interface to ensure display effects under different lighting conditions; it acquires the device surface temperature through the temperature sensor to reduce the rendering load when the device temperature is too high; and it acquires touch signal quality parameters from the touchscreen controller to characterize touch interference resistance, adjusting the response sensitivity of interactive components when the touch signal is interfered with. By periodically collecting these state parameters, the system provides a basis for decision-making regarding subsequent rendering optimization strategies.

[0032] Step 30: Calculate the GPU capability index based on performance parameters.

[0033] Specifically, to accurately assess the differences in graphics processing capabilities among heterogeneous devices, the system acquires performance parameters such as GPU floating-point operations per second (GFLOPS), video memory bandwidth (VRAM_Bandwidth), and thermal throttling factor (Thermal_Throttle_Factor). These performance parameters are then substituted into the first calculation formula to obtain the GPU capability index. The first calculation formula is as follows: In the formula, GCI represents the GPU capability index; GFLOPS represents the GPU's floating-point operations per second, reflecting the processing power of the GPU's computing cores. A higher value indicates a stronger ability to handle complex rendering, physics simulation, and vector animation; VRAM... Bandwidth`GCI` represents the video memory bandwidth, indicating the data transfer capability between the GPU and video memory, and determines the speed of texture mapping, frame buffer read / write, and geometric data exchange. `Thermal_Throttle_Factor` represents the thermal throttling factor, which is calculated as the GPU's rated frequency divided by its current actual frequency. In one optional embodiment, heterogeneous devices can be categorized into three levels based on the calculated GCI value: GCI < 5 is defined as Level 1 devices (low-end industrial equipment), 5 ≤ GCI < 15 is defined as Level 2 devices (mid-range mobile chips), and GCI ≥ 15 is defined as Level 3 devices (high-end processors). This method allows the system to quantitatively evaluate the graphics processing capabilities of different heterogeneous devices, providing a basis for implementing differentiated rendering strategies.

[0034] Step 40: Combine state parameters and GPU capability index to differentiate each initial UI component tree and generate the target UI component tree corresponding to each heterogeneous device.

[0035] The target UI component tree refers to the hierarchical structure tree representation of the user interface elements that need to be rendered and displayed on the device. It describes the parent-child relationships, layout methods, and nesting levels between various UI components (such as buttons, text boxes, images, etc.) in the interface, and is the basic data structure for interface rendering and interaction processing.

[0036] Specifically, to adapt the UI component tree to the performance differences of various heterogeneous devices, the system performs differential processing on each initial UI component tree to generate a target UI component tree adapted to each heterogeneous device. First, the device level is determined based on the calculated GCI value: GCI < 5 is Level 1, 5 ≤ GCI < 15 is Level 2, and GCI ≥ 15 is Level 3. Then, combining the status parameters of each heterogeneous device (such as current CPU utilization, memory utilization, network status, etc.), the system performs differential processing on the components in the initial UI component tree. For example, for Level 1 devices, component animation effects are simplified, rendering resource consumption is reduced, and component nesting levels are decreased; for Level 2 devices, basic animation effects and component structure are maintained, and rendering quality is appropriately adjusted; for Level 3 devices, complete animation effects and interactive features are retained. Through this differential processing method, the system can generate a target UI component tree that matches the device performance, ensuring both basic interface functionality and user experience while avoiding performance overload, achieving dynamic optimization of UI rendering.

[0037] Please see Figure 3This is a schematic diagram of a dynamic rendering decision process according to an embodiment of this application. This process achieves differentiated processing of the UI component tree through device performance detection. When the system receives a UI rendering request, it first performs device performance detection and classifies the device into three categories based on the calculated GCI value: low-end devices (GCI<5), mid-range devices (5≤GCI<15), and flagship devices (GCI≥15).

[0038] For low-end devices, the system employs the most stringent optimization strategy: downgrading animation effects and merging rendering batches. This includes converting dynamic components to static components, merging rendering operations for adjacent components, and reducing GPU rendering calls to lower device load. For mid-range devices, the system adopts a more moderate optimization strategy: preserving basic effects. This means maintaining basic animation effects and component structure, but may appropriately adjust rendering quality, such as reducing the detail or complexity of effects. For flagship devices, the system enables all effects, maintaining complete animation effects and interactive features, fully utilizing the device's powerful performance to provide the best visual experience. After determining the specific rendering strategy, the system executes optimized rendering operations, ultimately presenting the optimized interface to the user. This dynamic optimization mechanism based on device performance ensures a smooth user experience across devices of different performance levels, while fully leveraging the hardware advantages of high-performance devices.

[0039] As an optional implementation, the step of differentiating each initial UI component tree by combining state parameters and GPU capability index to generate the target UI component tree corresponding to each heterogeneous device may further include the following steps: Step 101: Determine the GPU computing power level of each heterogeneous device based on the GPU capability index.

[0040] Specifically, to accurately assess the actual processing capabilities of heterogeneous devices, the system determines the device's GPU computing power level based on the aforementioned calculated GPU Capability Index (GCI). The system compares the GCI value with preset level classification thresholds: when GCI < 5, the device is classified as Level 1, suitable for low-end industrial equipment; when 5 ≤ GCI < 15, the device is classified as Level 2, suitable for mid-range mobile chips; and when GCI ≥ 15, the device is classified as Level 3, suitable for high-end processors. Through this classification method, the system establishes a correspondence between device performance and UI rendering strategies, providing a foundation for subsequent differentiated processing.

[0041] Step 102: Compare the GPU computing power level, available memory space, ambient light intensity, device surface temperature, and tactile interference resistance in the status parameters with the corresponding trigger threshold conditions.

[0042] Specifically, to comprehensively assess the device's operational status, the system compares various status parameters with preset trigger thresholds. The system detects the following parameters: comparing the GPU computing power level to a baseline level 3; if it falls below level 3, optimization is triggered; checking if available memory is less than a preset threshold (e.g., 30% of total system memory); using a light sensor to detect if ambient light intensity is less than a preset threshold (e.g., 200 lumens); using a temperature sensor to detect if the device surface temperature exceeds a preset threshold (e.g., 45°C); and checking if the touch input's anti-interference capability is less than a preset threshold. Through this multi-dimensional status monitoring, the system can promptly identify performance bottlenecks that may affect user experience.

[0043] Step 103: When any state parameter satisfies the corresponding trigger threshold condition, optimize the initial UI component tree of the corresponding heterogeneous device according to the preset degradation rules to obtain the target UI component tree.

[0044] Specifically, when any state parameter is detected to meet the corresponding trigger threshold condition, the system optimizes the initial UI component tree according to preset degradation rules. The system employs corresponding optimization strategies for different trigger conditions: when GPU computing power is low, animation effects are simplified and rendering precision is reduced; when memory is insufficient, the number of component caches is reduced and resource preloading is decreased; when ambient light is dim, the interface color scheme is adjusted and brightness and contrast are reduced; when device temperature is too high, the rendering frame rate is reduced to decrease GPU workload; when touch anti-interference is low, the touch hot zone is increased and interaction response logic is optimized. The system applies these optimization strategies to the initial UI component tree, removing or adjusting corresponding component attributes and hierarchical structures, ultimately generating a target UI component tree adapted to the current device state. Through this rule-based dynamic optimization, the system ensures both basic interface functionality and user experience while avoiding device performance overload.

[0045] Please see Figure 4 This is an exemplary UI component tree degradation mapping diagram provided in this application embodiment, exemplarily describing how the system degrades high-performance UI components to low-performance components based on different state parameters. Combined with... Figure 4When insufficient GPU performance is detected, the system maps the Lottie animation component, which was originally rendered at 60FPS, to a static first-frame image component. When device memory is critically low, the shadow effect component containing Gaussian blur and alpha channels is mapped to a simplified component with the shadow effect removed. When refresh rate optimization is needed, a complex text view with dynamic fonts and gradient colors is mapped to a simplified text view using a uniform font and solid color background. When device temperature rises, 3D transformation layer effects that require matrix operations are mapped to a normal 2D background. This component degradation mapping mechanism based on different state parameters establishes a correspondence between high-performance components and low-performance components, achieving dynamic optimization of UI rendering and effectively controlling device resource consumption while ensuring basic interface functionality.

[0046] As an optional embodiment, when any state parameter satisfies the corresponding trigger threshold condition, the step of optimizing the initial UI component tree of the corresponding heterogeneous device according to the preset degradation rules to obtain the target UI component tree may further include the following steps: Step 201: When the GPU computing power level is lower than the preset computing power level, the dynamic components in the initial UI component tree of the corresponding heterogeneous device are downgraded to static components and the drawing batches are merged.

[0047] Specifically, to reduce GPU computing load, when the system detects that the device's GPU computing power level is lower than the preset level 3, it downgrades dynamic components in the initial UI component tree. The system first identifies dynamic components in the initial UI component tree (such as components with animation effects or real-time updates) and converts them into corresponding static components: for example, replacing dynamically rotating loading animations with static icons, changing smooth scrolling effects to pagination navigation, and changing dynamic ripple button effects to normal click feedback. Simultaneously, the system optimizes and merges rendering batches, combining multiple adjacent static components into a single batch, reducing the number of GPU rendering calls. Through this downgrading and merging process, the computational pressure on the GPU is significantly reduced, improving interface rendering efficiency.

[0048] Step 202: When the available memory space is lower than the preset memory space threshold, remove the special effects rendering components of the initial UI component tree of the corresponding heterogeneous device.

[0049] Specifically, when the system detects that the device's available memory is below a preset threshold (e.g., 30% of the total system memory), it needs to reduce memory usage. The system identifies and removes special effects rendering components from the initial UI component tree: first, it removes memory-intensive rendering effects such as Gaussian blur and particle effects; then, it reduces or removes secondary visual elements such as shadow effects and gradient effects; finally, it adjusts the caching strategy for image resources to reduce the number of preloaded resources. This removal strategy for special effects components prioritizes them according to their impact on user experience, ensuring that the usability of the interface is maintained to the greatest extent while reducing memory usage.

[0050] Step 203: When the surface temperature of the device reaches different preset temperature thresholds, the initial UI component tree of the corresponding heterogeneous device is optimized according to the temperature classification control strategy corresponding to the different preset temperature thresholds.

[0051] Specifically, to prevent overheating from impacting performance and user experience, the system implements a tiered control strategy based on the detected device surface temperature. The system sets three temperature thresholds for tiered processing: when the temperature reaches the first threshold (e.g., 40℃), the animation frame rate and rendering precision are reduced; when the temperature reaches the second threshold (e.g., 43℃), in addition to reducing the frame rate, some animation effects and special effects rendering are disabled; when the temperature reaches the third threshold (e.g., 45℃), all dynamic effects are downgraded to static display, and the overall interface refresh rate is reduced. Based on the current temperature level, the system optimizes the initial UI component tree accordingly: adjusting the update frequency of animation components, simplifying the rendering pipeline, reducing texture precision, and reducing rendering channels. Through this tiered temperature control mechanism, the system can effectively reduce device heat generation and avoid performance degradation while ensuring basic interactive functions.

[0052] As an optional embodiment, when the device surface temperature reaches different preset temperature thresholds, the step of optimizing the initial UI component tree of the corresponding heterogeneous device according to the temperature grading control strategy corresponding to the different preset temperature thresholds may also include the following steps: Step 301: When the surface temperature of the device reaches the first preset temperature threshold, disable unnecessary rendering effects in the initial UI component tree of the corresponding heterogeneous device.

[0053] Specifically, when the device temperature reaches the first preset temperature threshold T_warn (65℃), the system immediately initiates a first-level degradation strategy. The system first scans the initial UI component tree, identifying and disabling unnecessary rendering effects, including GPU-intensive rendering effects such as real-time shadow calculations and gradient fills. While these effects can enhance visual performance, they cause the GPU to operate under continuous high load, exacerbating the electromigration effect. By disabling these effects in a timely manner, GPU power consumption can be reduced, controlling the temperature rise.

[0054] Step 302: When the device surface temperature reaches the second preset temperature threshold, reduce the processor operating frequency and disable the 3D transformation effect in the initial UI component tree.

[0055] Specifically, when the temperature rises to the second preset temperature threshold T_critical (75℃), the system triggers more stringent degradation measures. First, the processor's operating frequency is reduced to 50% of its nominal frequency through the processor frequency adjustment mechanism, significantly reducing its power consumption and heat generation. At the same time, the system disables all 3D transformation effects, including 3D rotation, perspective projection, and other rendering operations that require a large amount of matrix calculations, replacing them with simple 2D transformations. This proactive frequency reduction and function limitation strategy effectively breaks the positive feedback loop of temperature rise.

[0056] Step 303: When the surface temperature of the equipment reaches the third preset temperature threshold, the system protection mechanism is activated, wherein the first preset temperature threshold is less than the second preset temperature threshold, and the second preset temperature threshold is less than the third preset temperature threshold.

[0057] Specifically, when the temperature continues to rise and reaches the third preset temperature threshold T_emergency (85℃), the system immediately activates an emergency protection mechanism to prevent permanent damage to the silicon wafer and solder joint detachment. This includes: forcibly terminating all non-critical rendering processes, reducing the GPU frequency to the minimum safe value, and initiating an emergency cooling procedure if necessary. Simultaneously, the system sends an over-temperature warning signal to the host computer, advising operators to suspend relevant industrial processes and wait for the equipment to cool down.

[0058] Step 204: When the ambient light intensity is higher than the preset light intensity threshold, the components in the initial UI component tree of the corresponding heterogeneous device are switched to high contrast display mode. The high contrast display mode is a display mode that uses color channel weighted calculation and light and dark mapping with preset brightness weight coefficient.

[0059] Specifically, to address the issue of unclear interface content display in strong light environments, the system monitors the ambient light intensity of the device in real time by registering a sensor listener. The system first activates the light sensor to continuously collect ambient light data at a fixed sampling frequency (e.g., 10 times per second). When the ambient light intensity exceeds a preset threshold (e.g., 10,000 lux), the system switches the display components in the initial UI component tree to a high-contrast display mode based on brightness perception. In this display mode, the system uses the Luma algorithm defined by the ITU-R BT.709 standard to process the interface content. Specifically, the pixels of each display component in the UI component tree are processed as follows: First, the pixel's brightness value Luma is calculated as Luma = 0.2126*R + 0.7152*G + 0.0722*B, where R, G, and B are the red, green, and blue channel values ​​of the pixel, respectively. Then, an intermediate brightness threshold L_mid (e.g., 0.5) is set, mapping pixels with Luma values ​​higher than L_mid to white and pixels with Luma values ​​lower than L_mid to black. This perception-based binarization process preserves the main information and outline features of the content while maximizing contrast. To optimize energy consumption, the system only increases backlight brightness when high-light environments are detected, rather than always maintaining maximum brightness. When the ambient light intensity drops below a threshold, the system automatically reverts to normal display mode. Furthermore, the system records and analyzes user behavior under different lighting conditions, dynamically adjusting brightness thresholds and mapping strategies to provide better adaptation.

[0060] Step 205: When the touch interference resistance is higher than the preset interference threshold, it is determined that a touch event has been detected, the initial UI component tree of the corresponding heterogeneous device is controlled to enable signal filtering processing, and adjacent touch points are merged.

[0061] Specifically, to improve the accuracy and anti-interference capability of touch operations, the system monitors the interference level of the touch signal in real time. When the detected touch interference exceeds a preset threshold (e.g., signal-to-noise ratio below 20dB), the system activates a signal filtering mechanism. First, the touch signal is subjected to median filtering to remove instantaneous noise interference; then, a Kalman filter algorithm is applied to smooth the touch trajectory, predicting and correcting the actual position of the touch point. For adjacent touch points, the system sets a time window (e.g., 50ms) and a distance threshold (e.g., 15 pixels). When the distance between multiple detected touch points within this time window is less than the threshold, these touch points are merged into a single valid touch point, whose position is the weighted average of these points. Through this signal processing mechanism, the accuracy and smoothness of touch operations are effectively improved, false triggers and jump phenomena are reduced, and the user interaction experience is enhanced.

[0062] As an optional embodiment, when the touch interference resistance is higher than a preset interference threshold, the step of determining that a touch event has been detected, controlling the initial UI component tree of the corresponding heterogeneous device to enable signal filtering processing, and merging adjacent touch points may further include the following steps: Step 401: When the touch resistance to interference is higher than the preset interference threshold, it is determined that a touch event has been detected, and the original touch point coordinate sequence of the touch event is collected.

[0063] Specifically, when the system detects that the touch interference (signal-to-noise ratio SNR) is lower than a preset threshold (e.g., 20dB), it determines that a touch event has been detected and initiates the enhanced touch signal processing flow. The system collects raw data of the touch event through the touch sensor at a fixed frequency (e.g., 120Hz). Each sampling point contains coordinate values ​​(x, y) and a timestamp t, forming a raw touch point coordinate sequence {(x1, y1, t1), (x2, y2, t2), ..., (x, y, t)}. This raw data will be used as input for subsequent signal processing.

[0064] Step 402: Perform Kalman filtering on the original touch point coordinate sequence to obtain the filtered touch point coordinate sequence.

[0065] Specifically, the system applies the Kalman filter algorithm to the original touch point sequence, first modeling the touch points as a four-dimensional state vector X. k = [px,vx,py,vy]T, where (px,py) are position coordinates and (vx,vy) are velocity components. The current state is predicted based on the optimal state of the previous moment, using a priori estimates. F is the state transition matrix based on a uniform motion model, in the form F = [1,Δt,0,0; 0,1,0,0; 0,0,1,Δt; 0,0,0,1]. The state is mapped to the observation space through the observation matrix H = [1,0,0,0; 0,0,1,0]. The error covariance matrix is ​​calculated as =F*Pk⁻¹*FT + Q, where Q is the process noise covariance matrix. The predicted value is corrected using the actual sensor observations (including noise) to obtain the optimal estimate. The system dynamically adjusts the observation noise covariance matrix R based on the current SNR and calculates the Kalman gain. Finally, a sequence of touch point coordinates after noise suppression is obtained.

[0066] Where H is the observation matrix, used to map the state vector to the observation space. Since only position can be observed, H = [1,0,0,0; 0,0,1,0]. R is the observation noise covariance matrix, determined by the touch signal-to-noise ratio (SNR). The more severe the oil contamination, the lower the SNR and the larger the R value. When the oil contamination is severe and the observation noise R is large, K... kThe value will decrease, and the algorithm will place more trust in the predicted value, thus effectively filtering out noise. When the screen is clean and the observation noise R is very small, K... k As the value increases, the algorithm places greater trust in the observed value Zk (Zk is the original coordinates [zx, zy] actually read by the sensor), ensuring agile response.

[0067] Step 403: Cluster and merge adjacent touch points in the filtered touch point coordinate sequence according to the preset distance threshold to generate a merged touch point sequence.

[0068] Specifically, the system performs clustering and merging processing on the filtered touch point sequence. A time window (50ms) and a distance threshold (15 pixels) are set, and adjacent touch points in the sequence are scanned. When multiple touch points are found to have an Euclidean distance less than the threshold within the time window, the weighted average position of these points is calculated: P_merged = Σ(wi*Pi) / Σwi, where the weight wi is proportional to the signal strength of each point. This effectively eliminates false triggers caused by oil contamination.

[0069] Step 404: Perform cubic spline interpolation on the merged touch point sequence to generate a smooth touch trajectory.

[0070] Specifically, the system uses a cubic spline interpolation algorithm to smooth the merged discrete touch point sequence. For example, for adjacent touch points Pi and Pi+1, at the sampling time t of the i-th touch point, a cubic polynomial Si(t) is constructed that satisfies the following conditions: 1) Si(ti) = Pi, Si(ti+1) = Pi+1; 2) The first derivative S'i(ti+1) = S'i+1(ti+1) and the second derivative S”i(ti+1) = S”i+1(ti+1) of adjacent spline segments are continuous. By solving this piecewise cubic polynomial system, a smooth touch trajectory curve is obtained.

[0071] Step 405: Map the touch trajectory to the touch response area corresponding to the initial UI component tree of the heterogeneous device, and trigger the corresponding interface interaction event.

[0072] Specifically, the system maps the processed touch trajectory to touch response areas in the UI component tree. First, it determines the trajectory's characteristic parameters, including the start point, end point, direction vector, instantaneous velocity, and acceleration. Based on these parameters, it identifies user intent, such as a click (touch time < 200ms and displacement < 10 pixels) or a swipe (displacement > 50 pixels and velocity within a specific range). Then, it triggers corresponding interaction events on the relevant UI components and dynamically adjusts the size of the touch response area based on the current level of interference, improving operational fault tolerance.

[0073] It should be noted that in industrial human-machine interaction systems, critical components such as alarm information and emergency shutdown are directly related to industrial safety and equipment operation. Therefore, when a touch event targeting these critical components is detected, the system directly skips the signal degradation processing procedure.

[0074] Step 50: Adapt the rendering pipeline for each target UI component tree, generate rendering instructions for each heterogeneous device, and control each heterogeneous device to render the interface according to the corresponding rendering instructions.

[0075] Specifically, because different heterogeneous devices have different rendering capabilities and display characteristics, directly distributing a unified UI component tree to each device may lead to inconsistent rendering effects or performance issues. Therefore, the system needs to adapt the target UI component tree to the rendering pipeline to ensure consistent visual effects and interactive experiences across heterogeneous devices. The system first obtains the rendering capability parameters of each heterogeneous device, including hardware parameters such as display resolution, color space, and refresh rate, as well as software parameters such as GPU rendering pipeline type and shader version. Then, the system traverses and analyzes the UI component tree based on these parameters, generating adapted rendering instructions for each UI component. For basic graphic elements, the system generates corresponding geometric data and material parameters; for complex components, the system decomposes them into combinations of basic graphic elements and optimizes the rendering order to improve performance. During the rendering instruction generation process, the system performs targeted optimizations. For example, for devices supporting hardware acceleration, the system generates rendering instructions that utilize GPU features, such as using vertex shaders to handle animation effects; for performance-constrained devices, the system generates simplified rendering instructions, such as reducing shadow quality and simplifying geometric details. Simultaneously, the system performs color mapping based on the device's color space characteristics to ensure consistent visual effects across different display devices. After generating rendering instructions, the system sends these instructions to various heterogeneous devices via the device driver interface and controls the devices to execute rendering operations in the order of the instructions. The system monitors rendering performance in real time, and when a drop in frame rate is detected, it automatically adjusts rendering parameters, such as reducing the quality of special effects and simplifying geometric details, to maintain a smooth interactive experience.

[0076] As an optional embodiment, the step of adapting the rendering pipeline for each target UI component tree and generating rendering instructions corresponding to each heterogeneous device may further include the following steps: Step 501: Adapt the rendering pipeline for each target UI component tree to obtain the final UI component tree.

[0077] Specifically, when a user modifies the interface layout, the system first needs to adapt the target UI component tree through the rendering pipeline to generate the final UI component tree. In practice, the system organizes the interface layout structure into a component-based tree structure, where each node contains information such as component type, attribute set, and child node list. The system assigns a globally unique component identifier (UUID) to each component node, which remains unchanged throughout the component's lifecycle. Then, the system traverses each node of the component tree, performing adaptation processing based on the device's rendering capability parameters (such as GPU model and video memory size), such as adjusting image resolution and simplifying rendering effects. The adapted component tree serves as the final UI component tree, used for subsequent difference calculations.

[0078] Step 502: Convert the final UI component tree into a linear operation instruction list, where each operation instruction in the linear operation instruction list corresponds to a component operation and contains a unique sequence identifier.

[0079] Specifically, the system employs a depth-first traversal algorithm to transform the final UI component tree into a linear list of operation instructions. Each operation instruction corresponds to the creation or update operation of a component and includes the following fields: sequence identifier (using a 64-bit integer, consisting of a 32-bit timestamp and a 32-bit incrementing counter), component UUID, operation type (CREATE / UPDATE), component type, attribute set (including key rendering parameters such as position, size, and style), and parent component UUID. This flat instruction list structure facilitates subsequent comparisons and maintains the hierarchical relationship between components through UUID association.

[0080] Step 503: Compare the differences between the linear operation instruction lists of the initial UI component tree and the final UI component tree of each heterogeneous device, and generate a minimized opcode sequence. The opcode sequence contains information on component movement, attribute updates, and subtree additions and deletions.

[0081] Specifically, the system generates a minimal sequence of opcodes by comparing the operation instruction lists of the initial and final UI component trees. In its implementation, the system first establishes a fast index based on UUIDs, then uses the Myers difference algorithm to calculate the minimum edit distance between the two instruction lists. For each difference, the system generates a corresponding opcode: MOVE: Component position change, including source and target position coordinates; UPDATE: Property update, including the changed property key-value pairs; ADD: Add subtree, including the complete subtree structure; DELETE: Delete subtree, including only the root node UUID. Each opcode carries a monotonically increasing sequence number (Seq) and a version number (Version) to support conflict detection and resolution in distributed editing.

[0082] Step 504: Compress and encrypt the opcode sequence to generate a difference data packet.

[0083] Specifically, the system uses industrial-grade compression and encryption algorithms to process the opcode sequence. First, the zlib algorithm is used to compress the opcode sequence, achieving a good balance between compression ratio and performance. Then, the national standard SM4 algorithm is used to encrypt the compressed data to ensure transmission security. The final difference data packet contains: the encrypted opcode sequence, sequence number Seq, base version number Version, and data packet checksum. The system also stores these data packets in a local cache to support offline editing and conflict recovery.

[0084] Step 505: Generate rendering instructions for each heterogeneous device based on the difference data package.

[0085] Specifically, the system generates device-specific rendering instructions based on the differential data packets. First, it verifies the integrity and version consistency of the data packets, ensuring the Version matches the current device state. Then, it decrypts and decompresses the data packets to restore the opcode sequence. The system converts the opcodes into the device's native rendering instructions, such as OpenGL ES command sequences or Vulkan command buffers. After application, the device sends an ACK confirmation to the cloud, containing the latest applied Seq number. If a version conflict occurs, the device requests the complete baseline template and incremental update sequence to ensure eventual consistency. This mechanism ensures a consistent final layout state for all heterogeneous devices, avoiding data discrepancies caused by network issues; and it allows any layout change to be tracked and audited, meeting the requirements of industrial quality management systems.

[0086] This application also provides a computer storage medium that can store multiple instructions. The instructions are adapted to be loaded and executed by a processor. The above embodiment provides a dynamic rendering optimization method for HarmonyOS UI framework for multi-terminal heterogeneous devices. For the specific execution process, please refer to the detailed description of the above embodiment, which will not be repeated here.

[0087] The following describes an electronic device for which a dynamic rendering optimization method for the HarmonyOS UI framework is provided in an embodiment of this application for multi-terminal heterogeneous devices. Figure 5 This is a schematic diagram of an exemplary hardware structure of an electronic device provided in an embodiment of this application.

[0088] In some embodiments, the HarmonyOS UI framework dynamically rendered optimized electronic device for multi-device heterogeneous devices is a computer device, or the HarmonyOS UI framework dynamically rendered optimized electronic device for multi-device heterogeneous devices includes a computer device. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The network interface of the computer device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of this application.

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

[0090] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0091] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0092] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for optimizing dynamic rendering of the HarmonyOS UI framework for multi-device heterogeneous devices, characterized in that, The method includes: receiving rendering requests for each heterogeneous device, and constructing an initial UI component tree corresponding to each heterogeneous device based on UI interface data in the rendering requests; The performance parameters and status parameters of each of the heterogeneous devices are obtained, and the status parameters include at least the available memory space, ambient light intensity, device surface temperature, and tactile interference resistance. Calculate the GPU capability index based on the aforementioned performance parameters; The initial UI component trees are differentiated by combining the state parameters and the GPU capability index to generate target UI component trees corresponding to each heterogeneous device; The rendering pipeline is adapted for each target UI component tree to generate rendering instructions for each heterogeneous device, and each heterogeneous device is controlled to render the interface according to the corresponding rendering instructions.

2. The HarmonyOS UI framework dynamic rendering optimization method for multi-terminal heterogeneous devices according to claim 1, characterized in that, The calculation of the GPU capability index based on the performance parameters includes: Extract the GPU's floating-point operations per second, memory bandwidth, and thermal throttling coefficient from the performance parameters. Substitute the performance parameters into the first calculation formula to obtain the GPU capability index; The first calculation formula is: In the formula, GCI represents the GPU capability index, GFLOPS represents the GPU's floating-point operations per second, and VRAM represents the GPU's floating-point operations per second. Bandwidth This represents the memory bandwidth, and Thermal_Throttle_Factor represents the thermal throttling factor, which is equal to the GPU's rated frequency divided by the GPU's current actual frequency.

3. The HarmonyOS UI framework dynamic rendering optimization method for multi-terminal heterogeneous devices according to claim 1, characterized in that, The step of combining the state parameters and the GPU capability index to perform differential processing on each of the initial UI component trees to generate the target UI component tree corresponding to each of the heterogeneous devices includes: The GPU computing power level of each heterogeneous device is determined based on the GPU capability index. The GPU computing power level, available memory space, ambient light intensity, device surface temperature, and tactile interference resistance in the status parameters are compared with the corresponding trigger threshold conditions. When any state parameter satisfies the corresponding trigger threshold condition, the initial UI component tree of the corresponding heterogeneous device is optimized according to the preset degradation rules to obtain the target UI component tree.

4. The HarmonyOS UI framework dynamic rendering optimization method for multi-terminal heterogeneous devices according to claim 3, characterized in that, When any state parameter satisfies the corresponding trigger threshold condition, the initial UI component tree of the corresponding heterogeneous device is optimized according to the preset degradation rules, including: When the GPU computing power level is lower than the preset computing power level, the dynamic components in the initial UI component tree of the corresponding heterogeneous device are downgraded to static components and the drawing batches are merged. When the available memory space is lower than a preset memory space threshold, the special effects rendering component of the initial UI component tree of the corresponding heterogeneous device is removed; When the surface temperature of the device reaches different preset temperature thresholds, the initial UI component tree of the corresponding heterogeneous device is optimized according to the temperature classification control strategy corresponding to the different preset temperature thresholds. When the ambient light intensity is higher than the preset light intensity threshold, the components in the initial UI component tree of the corresponding heterogeneous device are switched to a high contrast display mode. The high contrast display mode is a display mode that uses color channel weighted calculation and light and dark mapping with preset brightness weight coefficient. When the touch resistance to interference is higher than a preset interference threshold, it is determined that a touch event has been detected, and the initial UI component tree of the corresponding heterogeneous device is controlled to enable signal filtering processing and adjacent touch points are merged.

5. The HarmonyOS UI framework dynamic rendering optimization method for multi-terminal heterogeneous devices according to claim 4, characterized in that, When the surface temperature of the device reaches different preset temperature thresholds, the initial UI component tree of the corresponding heterogeneous device is optimized according to the temperature grading control strategy corresponding to the different preset temperature thresholds, including: When the surface temperature of the device reaches the first preset temperature threshold, unnecessary rendering effects in the initial UI component tree of the corresponding heterogeneous device are disabled. When the surface temperature of the device reaches the second preset temperature threshold, the processor operating frequency is reduced and the three-dimensional transformation effect in the initial UI component tree is disabled. When the surface temperature of the device reaches the third preset temperature threshold, the system protection mechanism is activated, wherein the first preset temperature threshold is less than the second preset temperature threshold, and the second preset temperature threshold is less than the third preset temperature threshold.

6. The HarmonyOS UI framework dynamic rendering optimization method for multi-terminal heterogeneous devices according to claim 4, characterized in that, When the touch resistance to interference is higher than a preset interference threshold, a touch event is detected. The system then controls the initial UI component tree of the corresponding heterogeneous device to enable signal filtering processing and merges adjacent touch points, including: When the touch resistance to interference is higher than a preset interference threshold, it is determined that a touch event has been detected, and the original touch point coordinate sequence of the touch event is collected; Perform Kalman filtering on the original touch point coordinate sequence to obtain the filtered touch point coordinate sequence; Based on a preset distance threshold, adjacent touch points in the filtered touch point coordinate sequence are clustered and merged to generate a merged touch point sequence. The merged touch point sequence is subjected to cubic spline interpolation to generate a smooth touch trajectory; The touch trajectory is mapped to the touch response area corresponding to the initial UI component tree of the heterogeneous device, and the corresponding interface interaction event is triggered.

7. The HarmonyOS UI framework dynamic rendering optimization method for multi-terminal heterogeneous devices according to claim 1, characterized in that, The rendering pipeline is adapted for each of the target UI component trees to generate rendering instructions corresponding to each of the heterogeneous devices, including: The rendering pipeline is adapted for each of the target UI component trees to obtain the final UI component tree; The final UI component tree is converted into a linear operation instruction list, wherein each operation instruction in the linear operation instruction list corresponds to a component operation and contains a unique sequence identifier; By comparing the differences between the linear operation instruction lists of the initial UI component tree and the final UI component tree of each heterogeneous device, a minimized opcode sequence is generated, which includes component movement, attribute update, and subtree addition / deletion information; The opcode sequence is compressed and encrypted to generate a differential data packet; Rendering instructions for each of the heterogeneous devices are generated based on the difference data packets.

8. An electronic device with dynamic rendering optimization of the HarmonyOS UI framework for multi-terminal heterogeneous devices, characterized in that, The electronic device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer program product containing instructions, characterized in that, When the computer program product is run on an electronic device that is dynamically rendered and optimized for multi-terminal heterogeneous devices using the HarmonyOS UI framework, the electronic device performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on an electronic device that is dynamically rendered and optimized for multi-device heterogeneous devices using the HarmonyOS UI framework, the electronic device performs the method as described in any one of claims 1-7.

Images