Component rendering method, electronic equipment and storage medium

Abstract

The invention discloses a component rendering method, electronic equipment and a storage medium, component metadata and real-time environment data of a to-be-rendered component are acquired, and the component metadata at least comprises rendering priorities of the to-be-rendered component; according to the real-time environment data, environment characteristics are obtained through calculation; rendering of the to-be-rendered component is obtained according to the environment features and a target rendering prediction model, and the target rendering prediction model is a pre-trained model used for predicting rendering time consumption according to the environment features; determining a rendering strategy of the to-be-shaded part according to the rendering priority, the environment characteristics and the rendering time consumption; and rendering the to-be-rendered component according to the rendering strategy. Rendering time consumption is predicted through environment data collection, dynamic adjustment of a rendering strategy is achieved in combination with environment characteristics and component priorities, and rendering time delay can be effectively shortened through the strategy adopted based on the rendering time consumption.

Description

Technical Field

[0001] The present application relates to the field of component rendering technology, and in particular to a component rendering method, an electronic device, and a storage medium. Background Art

[0002] With the explosive growth in demand for multi-terminal application development (Web, iOS, Android, mini-programs, etc.), rendering requirements for scenarios such as financial transactions and large real-time data screens are becoming higher. Traditional rendering methods mainly rely on static compilation or manual dynamic configuration, which leads to large fluctuations in rendering frame rates, certain state synchronization delays, and an inability to cope with dynamic changes such as network switching. Summary of the Invention

[0003] The present application provides a component rendering method, an electronic device, and a storage medium to at least solve the problems of large fluctuations in rendering frame rate, state synchronization delays, and inability to cope with dynamic changes such as network switching.

[0004] The present application provides a component rendering method, comprising: obtaining component metadata and real-time environment data of a component to be rendered, wherein the component metadata includes at least a rendering priority of the component to be rendered; Calculate environmental characteristics based on real-time environmental data; Obtaining the rendering time of the component to be rendered based on the environmental characteristics and the target rendering prediction model, where the target rendering prediction model is a pre-trained model used to predict the rendering time based on the environmental characteristics; Determine the rendering strategy of the component to be rendered based on rendering priority, environment characteristics, and rendering time; Render the component to be rendered according to the rendering strategy.

[0005] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned component rendering methods when executing the computer program.

[0006] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned component rendering methods are implemented.

[0007] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned component rendering methods when executed by a processor.

[0008] Through this application, the component metadata and real-time environment data of the component to be rendered are obtained, and the component metadata includes at least the rendering priority of the component to be rendered; based on the real-time environment data, the environment characteristics are calculated; based on the environment characteristics and the target rendering prediction model, the rendering time of the component to be rendered is obtained, and the target rendering prediction model is a pre-trained model for predicting rendering time based on environment characteristics; based on the rendering priority, environment characteristics and rendering time, the rendering strategy of the component to be rendered is determined; according to the rendering strategy, the component to be rendered is rendered. In this solution, the rendering time is predicted by collecting environment data, and combined with the environment characteristics and component priority, the rendering strategy is dynamically adjusted, and the strategy adopted based on the rendering time can effectively shorten the rendering delay. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0010] Figure 1 An architectural diagram of a component rendering system provided in an embodiment of the present application; Figure 2 A process of a component rendering method provided in an embodiment of the present application Figure 1 ; Figure 3 A process of a component rendering method provided in an embodiment of the present application Figure 2 ; Figure 4 A structural diagram of a component rendering device provided in an embodiment of the present application; Figure 5 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0011] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0012] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0013] It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0014] With the explosive growth of multi-platform application development needs, such as Web, iOS, Android, and mini-programs, front-end development faces numerous core challenges: Data volume and complexity surge: the number of enterprise-level application components exceeds 300, cross-platform adaptation code redundancy exceeds 50%, and development efficiency is low.

[0015] Severe device fragmentation: The performance difference between low-end Android devices (memory <2GB) and high-end models is more than 10 times, and static optimization strategies cannot take into account all scenarios.

[0016] Increasing real-time requirements: Scenarios such as financial transactions and real-time data screens require rendering delays of less than 100ms, which traditional passive optimization methods cannot meet.

[0017] Among the current related technologies, cross-platform frameworks have certain limitations and high development costs: using native rendering (Flutter) or hybrid development (Cordova). Flutter uses the Skia engine to achieve multi-terminal rendering, relies on static compilation, and cannot dynamically adjust rendering strategies; React Native uses bridged communication, and the delay can reach 50-100ms; Cordova relies on WebView to parse HTML / CSS. Cross-platform adaptation requires writing multiple sets of rendering logic, and code redundancy leads to maintenance costs increased by 40%-60%.

[0018] In addition, there are gaps in performance optimization, and performance is uncontrollable: static optimization methods include code splitting and CDN caching; dynamic optimization relies on manual configuration (such as loading different resources based on device models), and compilation-stage optimization (such as TreeShaking) cannot solve runtime problems. Monitoring tools (Lighthouse) require manual intervention and have not formed an automated closed loop. The rendering frame rate of low-end devices fluctuates greatly (for example, the frame rate of complex animations on low-end Android machines is less than 20fps), and it cannot cope with dynamic environments such as network switching.

[0019] The protocol layer is missing and the protocol is non-standardized: React Native uses JavaScript Bridge to achieve cross-language communication, and Vue uses a custom event mechanism to achieve inter-component state synchronization. There is a lack of standardized specifications for inter-component communication, and state synchronization and resource scheduling rely on customized implementation, resulting in low collaboration efficiency; component communication rules are fragmented, state synchronization latency is high, and performance monitoring data lacks a unified feedback mechanism.

[0020] In order to solve all or part of the above technical problems, the embodiments of the present application provide a component rendering method, an electronic device and a storage medium, which obtain component metadata and real-time environmental data of the component to be rendered, wherein the component metadata includes at least the rendering priority of the component to be rendered; according to the real-time environmental data, the environmental characteristics are calculated; according to the environmental characteristics and the target rendering prediction model, the rendering time of the component to be rendered is obtained, and the target rendering prediction model is a pre-trained model for predicting the rendering time according to the environmental characteristics; according to the rendering priority, the environmental characteristics and the rendering time, the rendering strategy of the component to be rendered is determined; according to the rendering strategy, the component to be rendered is rendered. In this solution, the rendering time is predicted by collecting environmental data, and the rendering strategy is dynamically adjusted in combination with the environmental characteristics and the component priority, and the strategy adopted based on the rendering time can effectively shorten the rendering delay.

[0021] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0022] like Figure 1 As shown, Figure 1 This is an architectural diagram of the component rendering system provided in an embodiment of the present application. The component rendering system may include: a protocol core layer, a dynamic resource scheduling module, a cross-platform rendering engine, and an intelligent decision center. The protocol core layer is the MCP protocol core layer. Through data interaction between the above modules, the full process automation of protocol definition, environment perception, intelligent scheduling, and cross-end rendering is realized.

[0023] like Figure 2 As shown, Figure 2This is a flowchart of a component rendering method provided in an embodiment of the present application. The method may include the following steps: 201. Obtain component metadata and real-time environment data of the component to be rendered.

[0024] It should be noted that the component to be rendered is the component that needs to be rendered. The component to be rendered can be understood as a component instance, specifically referring to the component object (such as buttons, charts, forms, etc.) that is specifically run in front-end development. It is the actual embodiment of the abstract definition of the component, and contains metadata such as unique identification, property configuration, cross-platform rules, etc., which is used to complete registration, communication, rendering and other interactive processes in the system.

[0025] The component metadata of a component to be rendered can be standardized information describing the component's identity, behavior, cross-platform rules, and performance metrics. This component metadata can include at least the rendering priority of the component to be rendered. This priority can be one of the metadata preset when the component to be rendered is created. It is pre-set during the development phase (or manually customized when writing code). It serves as the identity of the component participating in resource scheduling in the system. This rendering priority can refer to the execution order priority of the component during resource scheduling and rendering, which is used to determine the order in which the system allocates computing resources, network bandwidth, and rendering power. High-priority components (such as payment buttons and homepage navigation bars, defined as priority ≥ 7 (this is just an example, and the specific priority is defined based on personal experience or project requirements) will be loaded and rendered first to ensure the immediate availability of core functions. Low-priority components (such as pop-up ads and secondary data charts, defined as priority ≤ 3) will be processed after the core components are loaded to avoid occupying critical resources.

[0026] In some embodiments, the priority of a component during registration is preset during development. In subsequent processes, the system obtains the priority by reading the component metadata submitted during component registration. The specific process includes: when the component to be rendered sends a registration request, the preset "priority" field (such as priority=6) is included in the component metadata; the MCP protocol core layer stores the metadata in the "protocol metadata storage" sub-node, which includes the priority; the dynamic resource scheduling module reads the component metadata of the component to be rendered from the MCP protocol core layer, and directly obtains the value of the "priority" field as the key basis for subsequent resource scheduling (such as priority queue sorting).

[0027] For example, assuming that the component metadata of the component to be rendered is a line chart component instance (cid="chart_line"): { "cid": "chart_line", / / Component unique identifier (such as the ID of "line chart"); "dependencies": ["echarts.min.js", "theme.css"], / / Dependent resources (chart library, style file); "priority": 6, / / scheduling priority (1-10); "platform_rules": { / / Cross-platform rendering rules; "web": { "render_engine": "svg", "event_bind": "mouseenter"}, / / The web side uses SVG rendering and binds the mouse enter event; "weapp": { "render_engine": "canvas", "event_bind": "touchstart"}, / / The mini program uses Canvas to render and bind the touch start event; }, "metrics": { / / performance indicator threshold; "max_render_time": 150, / / Unit: ms, maximum rendering time is 150ms; "memory_threshold": 512, / / unit: KB, maximum memory usage: 512KB; }.

[0028] It can be seen that the component metadata can also include: unique identifier (cid="chart_line"): used to uniquely identify the component within the system; dependencies (dependencies=["echarts.min.js" etc.]): external resources required for component operation; cross-platform rules (platform_rules): such as SVG rendering on the Web side and Canvas rendering on the mini program side; performance thresholds (metrics): such as maximum rendering time of 150ms and memory threshold of 512KB.

[0029] In an embodiment of the present application, the real-time environmental data of the component to be rendered can be used to describe the device performance, network status, device platform and other data of the component to be rendered. The real-time environmental data of the component to be rendered can be collected in real time by the dynamic resource scheduling module through the "environmental data collection" sub-node therein.

[0030] In some embodiments, before obtaining the component metadata and real-time environment data of the component to be rendered, a component registration operation is required. The component to be rendered can send a registration request to the MCP protocol core layer. The registration request includes the component metadata. The MCP protocol core layer stores the component metadata in the "protocol metadata storage" sub-node and notifies the dynamic resource scheduling module. The dynamic resource scheduling module can obtain the component metadata from the MCP protocol core layer for subsequent resource scheduling calculations.

[0031] In some embodiments, the MCP protocol core layer is responsible for receiving and processing registration requests from components to be rendered. After completing metadata storage, the MCP protocol core layer returns a confirmation of successful registration to the component to be rendered through the protocol mechanism. Furthermore, after the dynamic resource scheduling module successfully obtains the metadata of the component to be rendered from the MCP protocol core layer (for subsequent resource scheduling calculations), it can confirm that the component metadata of the component to be rendered has been correctly registered and stored.

[0032] 202. Calculate environmental characteristics based on real-time environmental data.

[0033] In an embodiment of the present application, after obtaining the real-time environmental data of the component to be rendered, the real-time environmental data can be analyzed and the environmental characteristics can be calculated.

[0034] In some embodiments, the real-time environment data may include: device data, bandwidth data and platform data, wherein the device data may include at least: rendering speed data and memory usage data, so the environment characteristics may be obtained by comprehensive weighted calculation of the above data.

[0035] In some embodiments, environmental characteristics are calculated based on real-time environmental data, which may specifically include: obtaining device data, bandwidth data and platform data of the component to be rendered, the device data at least including rendering speed data and memory usage data; determining the device index value and bandwidth index value respectively based on the device data and bandwidth data; determining the platform correction coefficient based on the platform data; and calculating the environmental characteristics based on the device index value, bandwidth index value and platform correction coefficient.

[0036] It should be noted that rendering speed data can refer to GPU computing power, which can be obtained through WebGL benchmarks; memory usage data (performance.memory) can refer to the current device memory usage; bandwidth data can refer to the device's real-time bandwidth, which can be obtained through WebRTC speed testing; platform data can include operating system, browser kernel, screen resolution, etc. In addition, real-time environment data can also include other data, such as RTT latency (navigator.sendBeacon).

[0037] After obtaining the above-mentioned device data and bandwidth data respectively, their index values ​​can be calculated respectively, wherein the device index values ​​corresponding to the device data can include rendering speed index values ​​and memory usage index values. Specifically, the above-mentioned index values ​​can all be index values ​​obtained by normalizing the specific numerical values.

[0038] Among them, for the rendering speed index value, a test program can be used to test the rendering speed of the component to be rendered (for example, how many frames can be drawn per second), and then determine the level of the rendering speed, such as: high-end (fast rendering speed, ≥50 frames), mid-end (medium rendering speed, 30-50 frames), and low-end (slow rendering speed, <30 frames); then score according to different levels, such as: high-end 80-100 points, mid-end 40-80 points, and low-end 0-40 points. Specifically, the proportion of the actual rendering speed in the corresponding level range can be mapped to a specific score. This score is the rendering speed index value, ensuring that the score can reflect the performance differences within the same level. For other data (memory usage data, bandwidth data, etc.), the same calculation method is used to obtain the memory usage index value and bandwidth index value respectively.

[0039] For platform data, a platform correction factor can be determined. Platform-level parameters (such as the operating system, browser kernel, and terminal type, e.g., "mini program end" or "low-end Android device") are not included in the metric calculation. Instead, they serve as supplementary corrections for environmental differences, adjusting environmental characteristics through δ (the platform correction factor). Platform-level characteristics (such as the mini program's sandbox environment and the lack of system optimization on low-end Android devices) are non-performance environmental attributes that cannot be directly measured using quantitative "computing power / bandwidth" metrics. However, they can significantly impact component rendering performance. Therefore, a fixed correction factor is used to quickly adapt to platform differences. This platform correction factor is a pre-set fixed value based on the inherent characteristics of different platforms (e.g., mini programs, low-end Android devices), such as rendering mechanisms and hardware limitations. It is used to quickly correct the calculated environmental characteristics to account for the impact of platform differences on performance, eliminating the need for real-time dynamic calculations. For example, δ = 5 for mini program ends and δ = -8 for low-end Android devices.

[0040] In some embodiments, after obtaining the device index value (rendering speed index value and memory usage index value), bandwidth index value and platform correction coefficient, the environmental characteristics can be calculated. Since different parameters have different effects on the rendering components, the device index value and bandwidth index value can be assigned weights respectively. The index weight value can be obtained based on regression analysis of a large number of device data sets. For example: the index weight value of the rendering speed index value is 0.4, the index weight value of the memory usage index value is 0.3, and the index weight value of the bandwidth index value is 0.3.

[0041] In some embodiments, the calculation formula of the environmental characteristics may be:

[0042] in, That is, the environmental characteristics, is the indicator weight value, is the indicator value, is the platform correction coefficient, and n is the number of indicator values.

[0043] It can be seen that the rendering speed index value, memory usage index value and bandwidth index value are obtained through the above calculations, so n is 3, that is, the product of the rendering speed index value, memory usage index value, bandwidth index value and the corresponding index weight value is calculated respectively, and then summed with the platform correction coefficient to obtain the environmental characteristics.

[0044] In the embodiment of the present application, multi-dimensional environmental data collection and intelligent weighting algorithm are used to realize dynamic resource scheduling and policy configuration driven by environmental characteristics, thereby effectively improving the efficiency and effect of component rendering.

[0045] 203. Obtain the rendering time of the component to be rendered based on the environmental characteristics and the target rendering prediction model.

[0046] In an embodiment of the present application, after obtaining the environmental features, the environmental features can be input into the target rendering prediction model to obtain the rendering time of the component to be rendered output by the target rendering prediction model. The rendering time can be literally understood as the time required for the component to be rendered from the start of rendering to the completion of display (in ms).

[0047] It should be noted that after the dynamic resource scheduling module calculates the environmental features, it can pass the environmental features to the "LSTM prediction model" sub-node of the intelligent decision center to predict the component rendering time.

[0048] The target rendering prediction model is a pre-trained model that predicts rendering time based on environmental characteristics and can be continuously iterated and optimized. Predicting rendering time is a key component in achieving "proactive optimization," addressing the passive static optimization problem found in existing technologies. Specifically, it can proactively identify performance bottlenecks. Using an LSTM model (i.e., the target rendering prediction model), it predicts the rendering time of a component in the current environment (e.g., a mid-range device with an EF value of 65). This allows for early detection of performance thresholds (e.g., max_render_time = 150ms defined in component metadata), preventing actual rendering delays (e.g., financial transaction scenarios requiring latency less than 100ms). Furthermore, this model supports intelligent decision-making: Combining predictions with real-time monitoring data (e.g., frame rate less than 30fps) informs the reinforcement learning engine's generation of optimization strategies (e.g., switching rendering engines or compressing resources). This creates a closed "prediction-execution-feedback" loop, ensuring stable operation even on low-end devices (e.g., those with an EF value less than 50).

[0049] 204. Determine a rendering strategy for the component to be rendered based on the rendering priority, environment characteristics, and rendering time.

[0050] In an embodiment of the present application, after calculating the environmental characteristics and rendering time respectively, the rendering strategy of the component to be rendered can be determined. The rendering strategy can mainly be related to three data: rendering priority, environmental characteristics, and rendering time. Of course, it can also include other data, which is not specifically limited.

[0051] In some embodiments, the rendering strategy is primarily designed to improve frame rate (FPS) and reduce memory usage. Based on the device's hardware performance (GPU, memory), network status (bandwidth), and platform characteristics, the rendering strategy dynamically performs the following operations: Rendering engine switching: Dynamically select a rendering engine based on the environment characteristics (EF). For example, when EF < 50 (low-end devices), the chart component will be switched from SVG rendering to Canvas rendering (reducing performance consumption and rendering time); Resource loading adjustment: Implement a three-level loading strategy: high EF devices preload core components, medium EF devices load non-core components on demand, and low EF devices downgrade to loading simplified components (such as non-animated, low-resolution resources); Performance parameter control: Simple scenarios (e.g., EF < 40) trigger preset rules, such as disabling animated shadows and compressing image resources. Complex scenarios (e.g., EF ≥ 40) dynamically allocate CPU / GPU resources through reinforcement learning, prioritizing the operation of high-priority components (e.g., payment modules). Emergency intervention: When monitoring detects that the memory usage exceeds the limit (for example, 550KB > 512KB threshold), immediately perform forced downgrade loading (such as shutting down non-essential components and releasing the cache).

[0052] In some embodiments, a priority rendering queue may be determined for the rendering priority, thereby determining the rendering order of the components to be rendered and the allocated resources.

[0053] In some embodiments, to reduce latency, the intelligent decision center compares the predicted rendering time with the maximum rendering time threshold (e.g., max_render_time = 150ms) in the component metadata. If the predicted rendering time exceeds the threshold (e.g., 180ms > 150ms), it generates strategies such as switching rendering engines or compressing resources. If the predicted time is within a safe range, it maintains the current strategy to avoid resource waste caused by over-optimization. This "prediction-decision" linkage is the key to achieving the transition from passive optimization to active intervention (solving the problem of "static optimization strategy lag").

[0054] Therefore, the rendering priority, environment characteristics, and rendering time can be comprehensively considered to determine the optimal rendering strategy for the component to be rendered.

[0055] 205. Render the rendering component according to the rendering strategy.

[0056] In the embodiment of the present application, after the rendering strategy is determined, the component to be rendered can be rendered using the rendering strategy.

[0057] In an embodiment of the present application, component metadata and real-time environment data of the component to be rendered are obtained, and the component metadata includes at least the rendering priority of the component to be rendered; based on the real-time environment data, the environment characteristics are calculated; based on the environment characteristics and the target rendering prediction model, the rendering time of the component to be rendered is obtained, and the target rendering prediction model is a pre-trained model for predicting rendering time based on environment characteristics; based on the rendering priority, environment characteristics and rendering time, the rendering strategy of the component to be rendered is determined; according to the rendering strategy, the component to be rendered is rendered. In this solution, the rendering time is predicted by collecting environment data, and combined with the environment characteristics and component priority, the rendering strategy is dynamically adjusted, and the strategy adopted based on the rendering time can effectively shorten the rendering delay.

[0058] like Figure 3 As shown, Figure 3 Another flowchart of a component rendering method provided in an embodiment of the present application, the method may include the following steps: 301. Obtain component metadata and real-time environment data of the component to be rendered.

[0059] 302. Calculate environmental characteristics based on real-time environmental data.

[0060] In the embodiment of the present application, for the description of steps 301 to 302 , please refer to the detailed description of steps 201 to 202 in the above embodiment, which will not be repeated in the embodiment of the present application.

[0061] 303. Obtain historical rendering data and user behavior data.

[0062] In an embodiment of the present application, when training the rendering prediction model, it mainly relies on two parts of data: one is the historical rendering time data (as one of the input features of the LSTM model); the other is the real-time data pre-processed by the edge computing node (such as user behavior logs). These data are transmitted to the intelligent decision center through the MCP protocol core layer for model training.

[0063] 304. Perform data aggregation and feature extraction on the user behavior data to obtain behavior feature data.

[0064] In an embodiment of the present application, before model training, user behavior data needs to be preprocessed, and the preprocessing may include at least data aggregation and feature extraction. The steps of data aggregation and feature extraction of user behavior data can be performed by edge computing nodes, and the behavioral feature data obtained after processing is passed to the intelligent decision center through the MCP protocol core layer for model training.

[0065] It should be noted that edge computing nodes process real-time data generated during the front-end operation process. The core includes: user behavior logs, such as interaction data such as user clicks, slides, and dwell time; real-time status fragments of devices and environments, such as short-term GPU computing power fluctuations, network bandwidth changes, rendering frame rate snapshots, etc.; historical performance fragments of component operation: such as the rendering time and memory usage of a component under a specific EF value. Short-term statistical values ​​are not full historical data, but incremental data generated in real time.

[0066] In some embodiments, data aggregation can be understood as data compression. The higher the aggregation rate, the smaller the compressed data. Redundant information is merged, key features are extracted to reduce the amount of data (for example: aggregation rate = 90%, which means the data volume is compressed to 10% of the original). The specific method can be designed based on the characteristics of the data type to reduce the amount of data transmission and reduce the communication pressure between the front end and the intelligent decision-making center.

[0067] In some embodiments, user behavior logs are aggregated: high-frequency repeated user interaction behaviors (such as multiple clicks on the same button, page scrolling tracks) are statistically merged by time window (such as 1 minute), retaining core features such as "behavior type + number of occurrences + average interval" and removing repeated details in the original log (such as the precise millisecond timestamp of each click). Device / performance data is aggregated: real-time collected device status (such as GPU computing power, memory fluctuations) and network indicators (such as bandwidth, RTT) are calculated through a sliding window. Average, peak or trend values ​​(such as average memory usage within 5 seconds, bandwidth fluctuation range) are used to replace the original data points sampled frequently, retaining trend features that are valuable for model training.

[0068] In some embodiments, features are filtered and redundantly eliminated, and only key fields related to intelligent decision-making (such as "component ID + operation type" in user behavior and "EF value correlation index" in device data) can be retained, and irrelevant redundant information (such as duplicate device unique identifiers and meaningless log notes) can be eliminated to further compress the data volume.

[0069] In some embodiments, based on the aggregated data, preliminary feature extraction or prediction is performed through a lightweight LSTM model (a simplified version of the target rendering prediction model) deployed on the edge node. For example, for the aggregation results of user behavior logs, "correlation features between component interaction frequency and rendering performance" are extracted (such as "a component is clicked a high number of times → its rendering priority needs to be improved"); for device status data, a simplified "short-term performance trend forecast" is generated (such as "memory usage may increase by 10% in the next 10 seconds"), reducing the amount of raw data transmitted to the intelligent decision-making center while retaining high-order information that is valuable for model training.

[0070] Through this approach, edge computing nodes reduce data transmission pressure while retaining the core information required for training LSTM prediction models and reinforcement learning decision engines, supporting model iteration and policy optimization in the intelligent decision center. Preprocessing, a combination of aggregation (data reduction) and lightweight LSTM (feature extraction), resolves raw data redundancy while providing high-quality input for model training in the intelligent decision center. This is the core component of "edge computing collaborative optimization."

[0071] 305. Based on the component metadata, historical rendering data, and behavioral feature data, the preset model is trained to obtain a target rendering prediction model.

[0072] In an embodiment of the present application, a target rendering prediction model can be obtained by performing model training using component metadata, historical rendering data, and behavioral feature data.

[0073] In an embodiment of the present application, model training is performed in advance using historical rendering data and user behavior, which solves the problem of raw data redundancy and also provides high-quality data input for model training, effectively improving the accuracy of model prediction.

[0074] In some embodiments, when performing model training, the training data can come from multi-dimensional information collected during system operation and pre-processed by edge computing nodes, which can specifically include: environmental and device data, component metadata, historical performance data, and user behavior data.

[0075] Among them, environmental and device data can include: historical calculation results of environmental characteristics (including indicators such as GPU computing power, memory usage, network bandwidth, platform correction coefficient, etc.); real-time status fragments of devices / networks (such as GPU fluctuations and bandwidth change trends within a certain period of time), and after aggregation by edge computing nodes, key information such as "average value, peak value, trend characteristics" is retained.

[0076] Component metadata can include: metadata submitted when the component is registered (such as component ID, priority, cross-platform rules, performance thresholds, etc.); component dependencies (such as "chart_line" depends on "echarts.min.js"), which is used to analyze the correlation between resource loading strategies and rendering performance.

[0077] Among them, historical performance data may include: historical rendering time; performance monitoring indicators (such as historical frame rate, memory usage, network latency, etc., which can be collected in real time through the monitoring system); feedback data after strategy execution (such as the change in actual rendering time Δt, frame rate change ΔFPS, memory change Δmemory, etc. after executing the "switch to Canvas rendering" strategy, which is used for reward function calculation of reinforcement learning).

[0078] Among them, user behavior data may include: user interaction logs aggregated by edge computing nodes (such as the number of clicks and dwell time on a component), which are used to analyze the relationship between "user behavior-component load-performance requirements" (for example, high-frequency interaction components need to prioritize rendering performance).

[0079] After being preprocessed by edge computing nodes (aggregating redundant information + lightweight LSTM preliminary feature extraction), this data not only provides training samples for the LSTM model (EF value + component metadata → rendering time), but also provides the reinforcement learning engine with a reward calculation basis for "strategy → performance feedback", ultimately supporting the model's dynamic optimization of prediction accuracy and strategy effectiveness.

[0080] 306. Obtain the rendering time of the component to be rendered based on the environmental characteristics and the target rendering prediction model.

[0081] 307. Determine a rendering strategy for the component to be rendered based on the rendering priority, environment characteristics, and rendering time.

[0082] In the embodiment of the present application, for the description of steps 306 to 307, please refer to the detailed description of steps 203 to 204 in the above embodiment, which will not be repeated in the embodiment of the present application.

[0083] In some embodiments, the rendering strategy of the component to be rendered is determined based on the rendering priority, environmental characteristics and rendering time, which may specifically include: determining the target rendering engine based on the environmental characteristics and the preset correspondence; selecting the target loading rule from the pre-stored loading rule library based on the rendering priority and environmental characteristics; determining the rendering strategy of the component to be rendered based on the rendering priority, target rendering engine, target loading rule and rendering time.

[0084] When determining the rendering strategy, it may specifically include a rendering engine and loading rules, wherein the rendering engine may be mainly determined based on environmental characteristics, and the loading rules may be mainly determined based on rendering priority and environmental characteristics.

[0085] Environmental characteristics are quantitative metrics that combine device performance, network status, and platform type. Their core logic is to indirectly reflect device characteristics through the EF value, enabling more precise dynamic adaptation, rather than hard-coding rules based on device type (such as low-end Android devices). The calculation of environmental characteristics already incorporates device information (such as GPU computing power and memory) and platform correction factors (e.g., δ=-8" for low-end Android devices). Therefore, selecting a rendering engine based on environmental characteristics inherently incorporates the influence of device type, while providing greater flexibility. For example, the same device may have different environmental characteristics under different network conditions, resulting in different corresponding strategies.

[0086] It should be noted that loading rules refer to the resource loading rules formulated by the dynamic resource scheduling module based on environmental characteristics and rendering priorities. The dynamic resource scheduling module adjusts the loading method and order of component resources according to the optimization strategy issued by the intelligent decision-making center. The loading strategy is a sub-strategy of the rendering strategy and is a specific rule for converting the rendering strategy into an executable resource loading action.

[0087] In some embodiments, the loading rule may be determined by a three-level loading strategy, which may be represented by the following Table 1: Table 1 Three-level loading strategy table

[0088] As can be seen from Table 1 above, the loading rules can be determined according to the environmental characteristics and priorities.

[0089] It should be noted that the preset correspondence is the correspondence between pre-stored environmental features and rendering engines. After determining the current environmental features, the target rendering engine corresponding to the environmental features can be directly determined from the preset correspondence. For example, when EF<50, the chart component is mapped to Canvas rendering to reduce performance consumption.

[0090] In an embodiment of the present application, the rendering engine is determined by environmental characteristics, the loading rules are determined by rendering priority and environmental characteristics, and finally the rendering strategy is determined in combination with priority and rendering time. By determining the rendering strategy from parameters from multiple angles, the rendering strategy can be more suitable for the current scene and current component, effectively improving the rendering effect.

[0091] In some embodiments, the rendering instructions received by the cross-platform rendering engine serve as the basis for initial rendering, generated based on the prevailing environmental characteristics and component metadata (e.g., SVG rendering on the web when EF > 50). Switching rendering modes dynamically adjusts these initial rendering instructions. When the intelligent decision center generates an optimization strategy based on new monitoring data (e.g., frame rate drops, memory limits exceeded) or predictions (e.g., rendering time exceeding the target), the cross-platform rendering engine modifies the core parameters in the original rendering instructions (e.g., rendering engine type, resource loading level) based on the new strategy, implementing an iteration from "initial rendering" to "optimized rendering."

[0092] Switching rendering modes means that the cross-platform rendering engine changes the technical solutions or parameters that rendering relies on according to the optimization strategy. The core is the dynamic adjustment to adapt to environmental changes, including: rendering engine switching, such as switching from SVG engine to Canvas engine (when EF<50, reducing performance consumption); rendering accuracy adjustment: such as switching from high-definition rendering (high resolution, complex animation) to degraded rendering (low resolution, no animation, suitable for low-end devices); resource loading level switching: such as switching from loading complete component resources to loading simplified resources (such as lightweight components that only retain core functions).

[0093] In some embodiments, rendering strategies are transmitted via a bidirectional communication link subnode built into the MCP protocol core layer. This serves as a standardized information exchange channel between system modules. The specific process is as follows: After extracting the strategy, the intelligent decision center encapsulates it into instructions that comply with the MCP protocol specification (e.g., including the strategy type, target module, and execution parameters, for example, executing a Canvas rendering switch for the component with cid=chart_line); the instructions are bidirectionally transmitted to the MCP protocol core layer via a bidirectional communication link, which supports upstream status reporting and downstream strategy push; the MCP protocol core layer receives and parses the instructions, and then forwards them to the dynamic resource scheduling module and cross-platform rendering engine to drive strategy execution, such as updating the loading order and switching the rendering engine.

[0094] In some embodiments, at least one initial rendering strategy is determined based on rendering priority, environmental characteristics, and rendering time; monitoring data of the component to be rendered is collected in real time; and based on the monitoring data of the rendering component, at least one initial rendering strategy is screened to determine the rendering strategy of the component to be rendered.

[0095] Since the core purpose of rendering the component to be rendered is to improve the real-time frame rate and reduce memory usage, the monitoring data of the component to be rendered can be collected in real time. The monitoring data may include the real-time frame rate and / or memory data, and the rendering strategy can be screened by the value of the monitoring data. That is, more than one rendering strategy may be determined based on the rendering priority, environmental characteristics and rendering time. The rendering strategy with the best effect on the component to be rendered can be selected from at least one rendering strategy through the monitoring data.

[0096] In some embodiments, monitoring data can be collected by a monitoring system. This monitoring data consists of two parts, aggregated to the monitoring system through a real-time collection and reporting mechanism. Performance data reported by the cross-platform rendering engine: After the cross-platform rendering engine completes component rendering, it automatically collects runtime metrics such as "rendering time" (e.g., 180ms) and "memory usage" (e.g., 450KB) and reports them to the monitoring system through the MCP protocol core layer. Real-time status data directly collected by the monitoring system: The monitoring system actively monitors device operating status (e.g., GPU computing power, memory utilization), network environment (e.g., bandwidth, RTT latency), rendering stability (e.g., frame rate fluctuations), etc. For example, it can detect that the memory usage of a low-end device exceeds the limit (550KB > 512KB threshold).

[0097] Monitoring data focuses on key metrics that impact front-end performance, including: rendering performance: rendering time (the time it takes for a component to be drawn and displayed), frame rate (FPS, an indicator of visual smoothness); resource usage: memory usage and CPU / GPU load; network status: real-time bandwidth and network latency (RTT), used to determine resource loading strategies (such as preloading / downloading); and device and platform characteristics: device model, operating system version, and browser / applet kernel, to assist in verifying cross-platform adaptation. This monitoring data forms the core basis for the intelligent decision-making center to generate optimization strategies, ensuring that the system can detect performance bottlenecks in real time and proactively intervene.

[0098] In an embodiment of the present application, the final rendering strategy is determined from at least one initial strategy by monitoring the frame rate and / or memory data in real time. This allows the rendering strategies to be screened based on intuitive rendering effects, effectively improving the rendering effect.

[0099] In some embodiments, when the monitoring system detects that the memory usage of a low-end device exceeds the limit (such as memory = 550KB > 512KB threshold), it triggers an emergency alarm, and the intelligent decision center immediately generates an emergency strategy (such as forced downgrade loading) and sends it to the dynamic resource scheduling module through the MCP protocol.

[0100] 308. Obtain virtual rendering tree data corresponding to the component to be rendered.

[0101] In the embodiments of this application, Virtual Render Tree (VRT) data is an abstracted, platform-independent intermediate representation of front-end components, used to achieve cross-platform rendering adaptation. VRT data is a standardized description of component structure, properties, behavior, and dynamic rendering rules. This data is completely separated from specific platform syntax (such as HTML for the Web or WXML for applets), retaining only the component's abstract logic, providing a unified input for cross-platform conversion.

[0102] Exemplarily, the virtual rendering tree data can be represented as: { "type": "Button", "props": { "onClick": "handleClick", "style": { "backgroundColor": "#4A90E2"}, "renderEngine": "${EF>50 ? 'svg' : 'canvas'}"}, "children": ["Submit"]; }.

[0103] As you can see, the core VRT fields include: Component type (type): Identifies the basic type of the component (such as a button, chart, input box, etc.). In the example, "type": "Button". Property configuration (props): Interaction behavior: For example, "onClick": "handleClick" (click event binding); Style information: For example, "style": {"backgroundColor":"#4A90E2"} (background color and other styles); Dynamic rendering rules: For example, "renderEngine": "${EF>50 'svg' : 'canvas'}" (dynamically selects a rendering engine based on environmental characteristics). Children: Describes the nested structure of the component. In the example, "children": ["Submit"] (the text content of the button).

[0104] In some embodiments, VRT data is obtained by parsing and converting the original front-end component code through the VRT generator module (in the cross-platform rendering engine). The specific process is as follows: the original component code (such as React's JSX and Vue's template syntax) is used as input and enters the VRT generator; the VRT generator uses AST (abstract syntax tree) parsing, logical abstraction and other processing to strip off the platform-specific syntax and extract the component's type, properties, sub-components and other core information; generates JSON format VRT data that complies with the MCP protocol specification (such as the above example), and passes it to the MCP protocol core layer as input to the cross-platform rendering engine.

[0105] For example, the Web <button style="background:blue" onclick=" handleClick"> Submit< / button> After conversion by the VRT generator, the VRT data in the above example is obtained, realizing the conversion from platform-dependent code to platform-independent intermediate representation.

[0106] 309. Generate target platform code data based on component metadata, virtual rendering tree data, and platform mapping rules.

[0107] In the embodiments of this application, platform mapping rules are pre-stored in the platform mapping rule library of the cross-platform rendering engine. However, the rules are dynamic and adapt to changes in the environment (such as EF value and device type), rather than being fixed and rigid. The rule library stores basic mapping relationships, such as the corresponding templates of component types and platform rendering methods. For example, the Button component is mapped to a DOM element on the web by default and to a cover-view component on the mini-program side.

[0108] Dynamic features: Rules adapt in real time based on environmental characteristics. For example, they dynamically select a rendering engine based on the EF value. For example, when EF < 50, chart components are mapped to Canvas rendering to reduce performance. Basic templates in the rule library can be overwritten by dynamic logic triggered by the EF value, achieving a combination of "pre-existing templates + dynamic conditions."

[0109] In some embodiments, the target platform code data is generated to resolve the differences in syntax and rendering mechanisms between different platforms, converting the platform-independent virtual render tree (VRT) into executable code for a specific platform to ensure that the component can be correctly parsed and displayed on the target platform (such as the Web, mini-program, and APP). Different platforms have their own development syntax (such as HTML / CSS for the Web, WXML / WXSS for mini-programs, and Swift / Java for APPs) and rendering engines (such as SVG / Canvas for the Web and native rendering engines for mini-programs). Directly using unified code cannot run across platforms. The cross-platform rendering engine uses the correspondence between component types and platform syntax pre-stored in the platform mapping rule library. For example, the Button component is mapped to <button>Tags, mapped to <cover-view>Tags convert VRT data (platform-independent intermediate representation) into native code of the target platform, achieving one-time definition and multi-terminal adaptation.

[0110] 310. Execute the target platform code data according to the rendering strategy to render the component to be rendered.

[0111] In the embodiment of the present application, the rendering process is based on the generated target platform code, combined with a dynamically selected rendering engine (such as SVG / Canvas), and calls the native rendering capabilities of the target platform to complete component drawing. The specific steps are as follows: Code conversion: The cross-platform rendering engine reads the VRT data (such as {type: "Button", props: {...}}) and platform mapping rules (such as SVG rendering on the Web side when EF>50) issued by the MCP protocol core layer, and generates the target platform code through the platform mapping rule library: Web side: Generates HTML / CSS code (such as < / button><button style="background-color:#4A90E2"> Submit< / button> ), adapted to SVG or DOM rendering engine; Mini Program side: generate WXML code (such as <cover-view bindtap="handleClick" style="background-color:#4A90E2"> Submit< / cover-view> ), adapt to the native Canvas engine of the mini program; APP side: generate Swift (iOS) or Java (Android) code and call the native control rendering interface.

[0112] Engine execution rendering: The target platform code is passed to the corresponding platform's rendering engine (such as the browser rendering engine on the web side and the WeChat rendering engine on the mini-program side). The engine completes the drawing on the terminal interface based on the component structure, style, and interaction logic described in the code, such as the rendering of the button shape, color, and click response area.

[0113] Performance data collection: After rendering is completed, the cross-platform rendering engine automatically collects performance data (such as rendering time and memory usage) and reports it to the monitoring system and intelligent decision-making center through the MCP protocol core layer (for subsequent optimization strategy iteration).

[0114] In an embodiment of the present application, a virtual render tree (VRT) and a dynamic platform mapping engine are designed to reduce the amount of cross-platform adaptation code by 61.6% by abstracting the intermediate representation of components and cross-platform conversion rules. The platform-independent virtual render tree (VRT) is converted into executable code for a specific platform, ensuring that the components can be correctly parsed and displayed.

[0115] 311. Obtain real-time fluency and real-time memory usage data of the component to be rendered.

[0116] 312. Determine the reward function value corresponding to the rendering strategy based on the real-time fluency and real-time memory usage data.

[0117] In this embodiment, reinforcement learning is required during the rendering process. The core of this reinforcement learning strategy is the design of a reward function. This reward function can evaluate the effectiveness of the rendering strategy and perform iterative optimization of the strategy to optimize resource allocation. The primary goal is to improve the smoothness of the picture (FPS) while strictly controlling memory usage. Among them, FPS (Frame Per Second) and memory usage are the most directly related core indicators. Using the variables ΔFPS and Δmemory can better reflect the immediate effect of the strategy.

[0118] An increase in ΔFPS corresponds to an increase in rewards (an incentive), while an increase in Δmemory corresponds to a decrease in rewards (a penalty). Based on historical data and experience, we estimate the range of indicator changes. Then, through experiments (for example, testing weight combinations of 0.6 / 0.4, 0.8 / 0.2, and 0.75 / 0.25), we evaluate the strategy's balance between FPS improvement and memory control. Ultimately, we select the weights that best represent the business objectives in the current scenario.

[0119] In some embodiments, the reward function can be expressed as:

[0120] in, is the reward function value, The change in screen smoothness is a core reward item, and a high weight highlights the primary goal of performance improvement. is the change in memory usage, which is a constraint penalty term. A lower weight ensures that memory growth is within an acceptable range. and is the weight value, + =1, usually > .

[0121] 313. When the reward function value is less than the preset score, adjust the rendering strategy so that the reward function value is greater than or equal to the preset score.

[0122] 314. If it is detected that the reward function value is greater than or equal to the preset score within the preset time length, the component metadata, real-time environment data and rendering strategy are stored accordingly.

[0123] In this embodiment of the present application, if the reward function value is less than a preset score, it indicates that the current rendering strategy is not effective for the rendering component. Therefore, the rendering strategy can be adjusted and the reward function value can be continuously monitored until the reward function value is greater than or equal to the preset score. If the reward function value is greater than the preset score, it indicates that the current rendering strategy is effective for the rendering component. Therefore, rendering can be continued using this rendering strategy, and the component metadata, real-time environment data, and rendering strategy can be stored accordingly.

[0124] The reward function is a quantitative metric for evaluating the effectiveness of rendering strategy execution. The reward function weights these two metrics to produce a composite score: a higher score indicates a more effective strategy for improving smoothness (FPS) and controlling memory usage. After obtaining the reward function's results, the system adjusts the optimization strategy based on the score, forming a closed-loop iteration loop. If the reward value is high (effective strategy), the strategy is retained and stored in the "Strategy Knowledge Base," where it will be prioritized for future reuse in similar scenarios (e.g., with the same EF value or component type). If the reward value is low (poor strategy), the reinforcement learning engine uses the result to modify the strategy generation logic (e.g., adjusting resource allocation weights or changing rendering engine selection rules) until a more optimal strategy is iterated.

[0125] In the embodiment of the present application, the reward function is the effectiveness scorer of the optimization strategy, and the iterative adjustment of the strategy depends on this scoring result. The two together constitute the core feedback mechanism of reinforcement learning decision-making, ensuring that the optimization strategy can continuously adapt to the dynamic environment.

[0126] In an embodiment of the present application, a standardized component communication architecture based on the MCP protocol is proposed, a metadata model including component unique identification, cross-platform rules, and performance monitoring fields is defined, and lightweight communication is implemented through the MessagePack binary protocol, which significantly reduces the amount of transmitted data and greatly reduces response delays.

[0127] A dynamic resource scheduling system driven by environmental characteristics was built. Through multi-dimensional environmental data collection and intelligent weighting algorithms, a three-level loading strategy (preloading / on-demand loading / downgraded loading) and priority queue optimization were implemented. This reduced memory usage on low-end devices by 40.1% and shortened the first screen loading time by 50%.

[0128] The design of a virtual render tree (VRT) and dynamic platform mapping engine reduces the amount of cross-platform adaptation code by 61.6% by abstracting component intermediate representations and cross-platform conversion rules. It also supports automatic switching of rendering engines (such as SVG to Canvas) on low-end devices, reducing rendering time by 58%.

[0129] The LSTM prediction model and reinforcement learning decision engine are introduced to build a "monitoring-prediction-optimization" closed loop. The performance bottleneck prediction error rate MAE is less than 10%, the resource allocation efficiency in complex scenarios is 40% higher than that of traditional algorithms, and the animation rendering frame rate stability is improved by 100%.

[0130] It can effectively solve core problems in existing technologies, such as high cross-platform development code redundancy (40%-60%), poor performance adaptation of low-end devices (frame rate <20fps), lagging static optimization strategies, and high component communication latency (50-100ms), and realize the paradigm upgrade of front-end development from manual experience-driven to protocol definition and data intelligence.

[0131] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0132] like Figure 4 As shown, an embodiment of the present application further provides a component rendering device, which may include: An acquisition module 401 is configured to acquire component metadata and real-time environment data of a component to be rendered, wherein the component metadata includes at least a rendering priority of the component to be rendered; The processing module 402 is used to calculate the environmental characteristics based on the real-time environmental data; The processing module 402 is further configured to obtain a rendering time of the component to be rendered based on the environmental characteristics and a target rendering prediction model, where the target rendering prediction model is a pre-trained model for predicting rendering time based on environmental characteristics. The processing module 402 is further configured to determine a rendering strategy for the component to be rendered based on the rendering priority, environment characteristics, and rendering time. The processing module 402 is further configured to render the component to be rendered according to the rendering strategy.

[0133] In some embodiments, the acquisition module 401 is specifically used to obtain device data, bandwidth data, and platform data of the component to be rendered, where the device data includes at least rendering speed data and memory usage data; The processing module 402 is specifically configured to determine a device index value and a bandwidth index value based on the device data and the bandwidth data, respectively; The processing module 402 is specifically configured to determine a platform correction coefficient based on the platform data; The processing module 402 is specifically configured to calculate the environmental characteristics according to the device index value, the bandwidth index value and the platform correction coefficient.

[0134] In some embodiments, the acquisition module 401 is specifically used to obtain virtual rendering tree data corresponding to the component to be rendered; Processing module 402 is specifically configured to generate target platform code data based on component metadata, virtual rendering tree data, and platform mapping rules; The processing module 402 is specifically configured to execute the target platform code data according to the rendering strategy to render the component to be rendered.

[0135] In some embodiments, the processing module 402 is specifically configured to determine a target rendering engine based on the environmental characteristics and a preset correspondence relationship, where the preset correspondence relationship is a pre-stored correspondence relationship between environmental characteristics and rendering engines; The processing module 402 is specifically configured to select a target loading rule from a pre-stored loading rule library according to the rendering priority and the environment characteristics; The processing module 402 is specifically configured to determine a rendering strategy for the component to be rendered based on the rendering priority, the target rendering engine, the target loading rule, and the rendering time.

[0136] In some embodiments, the processing module 402 is specifically configured to determine at least one initial rendering strategy based on the rendering priority, the environment characteristics, and the rendering time; Acquisition module 401 is specifically used to collect monitoring data of the component to be rendered in real time, the monitoring data including real-time frame rate and / or memory data; The processing module 402 is specifically configured to screen at least one initial rendering strategy according to the monitoring data of the rendering component, and determine the rendering strategy of the component to be rendered.

[0137] In some embodiments, the acquisition module 401 is further used to obtain real-time fluency and real-time memory usage data of the component to be rendered; The processing module 402 is further configured to determine a reward function value corresponding to the rendering strategy based on the real-time fluency and real-time memory usage data; The processing module 402 is further configured to adjust the rendering strategy when the reward function value is less than a preset score, so that the reward function value is greater than or equal to the preset score.

[0138] In some embodiments, the processing module 402 is further configured to store the component metadata, the real-time environment data, and the rendering strategy accordingly if it is detected that the reward function values ​​within the preset time period are all greater than or equal to the preset score.

[0139] In some embodiments, the acquisition module 401 is further used to acquire historical rendering data and user behavior data; The processing module 402 is further used to aggregate and extract features from the user behavior data to obtain behavior feature data; The processing module 402 is further configured to train a preset model based on component metadata, historical rendering data, and behavioral feature data to obtain a target rendering prediction model.

[0140] In the embodiments of the present application, the description of the features in the embodiment corresponding to the component rendering device can refer to the relevant description of the embodiment corresponding to the component rendering method, and will not be repeated here.

[0141] like Figure 5 As shown, an embodiment of the present application further provides an electronic device, including a memory 501 and a processor 502, wherein the memory 501 stores a computer program, and the processor 502 is configured to run the computer program to execute the steps in any of the above-mentioned component rendering method embodiments.

[0142] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned component rendering method embodiments when running.

[0143] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0144] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned component rendering method embodiments are implemented.

[0145] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned component rendering method embodiments are implemented.

[0146] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The above is a detailed introduction to the process monitoring of a storage system provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core ideas of this application. It should be pointed out that, for those skilled in the art, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A component rendering method, characterized in that: The method comprises: Obtaining component metadata and real-time environment data of the component to be rendered, wherein the component metadata includes at least a rendering priority of the component to be rendered; Calculating environmental characteristics based on the real-time environmental data; Obtaining a rendering time of the component to be rendered according to the environmental features and a target rendering prediction model, wherein the target rendering prediction model is a pre-trained model for predicting rendering time according to environmental features; Determining a rendering strategy for the component to be rendered according to the rendering priority, the environmental characteristics, and the rendering time; Render the component to be rendered according to the rendering strategy.

2. The method according to claim 1, characterized in that The calculating of environmental characteristics according to the real-time environmental data includes: Obtain device data, bandwidth data, and platform data of the component to be rendered, wherein the device data includes at least rendering speed data and memory usage data; Determining a device index value and a bandwidth index value respectively according to the device data and the bandwidth data; determining a platform correction coefficient based on the platform data; The environmental characteristics are calculated based on the device index value, the bandwidth index value, and the platform correction coefficient.

3. The method according to claim 1, characterized in that Rendering the component to be rendered according to the rendering strategy includes: Obtain virtual rendering tree data corresponding to the component to be rendered; Generate target platform code data according to the component metadata, the virtual rendering tree data and platform mapping rules; The target platform code data is executed according to the rendering strategy to render the component to be rendered.

4. The method according to claim 1, wherein The determining of the rendering strategy of the component to be rendered according to the rendering priority, the environmental characteristics, and the rendering time includes: Determining a target rendering engine according to the environmental characteristics and a preset correspondence, wherein the preset correspondence is a pre-stored correspondence between environmental characteristics and rendering engines; Selecting a target loading rule from a pre-stored loading rule library according to the rendering priority and the environment characteristics; A rendering strategy for the component to be rendered is determined according to the rendering priority, the target rendering engine, the target loading rule, and the rendering time.

5. The method according to claim 1, wherein The determining of the rendering strategy of the component to be rendered according to the rendering priority, the environmental characteristics, and the rendering time includes: Determining at least one initial rendering strategy according to the rendering priority, the environment characteristics, and the rendering time; Collecting monitoring data of the component to be rendered in real time, the monitoring data including real-time frame rate and / or memory data; The at least one initial rendering strategy is screened according to the monitoring data of the rendering component to determine the rendering strategy of the component to be rendered.

6. The method according to claim 1, characterized in that After rendering the component to be rendered according to the rendering strategy, the method further includes: Obtaining real-time fluency and real-time memory usage data of the component to be rendered; Determining a reward function value corresponding to the rendering strategy according to the real-time fluency and the real-time memory usage data; When the reward function value is less than a preset score, the rendering strategy is adjusted so that the reward function value is greater than or equal to the preset score.

7. The method according to claim 6, characterized in that After determining the reward function value corresponding to the rendering strategy based on the real-time fluency and the real-time memory usage data, the method further includes: If it is detected that the reward function values ​​within the preset time period are all greater than or equal to the preset score, the component metadata, the real-time environment data, and the rendering strategy are stored correspondingly.

8. The method according to claim 1, characterized in that Before obtaining the rendering time of the component to be rendered according to the environmental characteristics and the target rendering prediction model, the method further includes: Obtain historical rendering data and user behavior data; Performing data aggregation and feature extraction on the user behavior data to obtain behavior feature data; The preset model is trained according to the component metadata, the historical rendering data and the behavior feature data to obtain the target rendering prediction model.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the component rendering method according to any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the component rendering method according to any one of claims 1 to 8.

Images