Component rendering method, electronic device, and storage medium

Abstract

This application discloses a component rendering method, electronic device, and storage medium. The method involves acquiring component metadata and real-time environment data of a component to be rendered, where the component metadata includes at least the rendering priority of the component. Based on the real-time environment data, environmental characteristics are calculated. The rendering of the component is then determined based on the environmental characteristics and a target rendering prediction model, which is a pre-trained model used to predict rendering time based on the environmental characteristics. A rendering strategy for the component is determined based on the rendering priority, environmental characteristics, and rendering time. Finally, the component is rendered according to the rendering strategy. By predicting rendering time through environmental data acquisition and combining environmental characteristics and component priority, the rendering strategy can be dynamically adjusted, and the strategy adopted based on rendering time can effectively shorten rendering latency.

Description

Technical Field

[0001] This application relates to the field of component rendering technology, and in particular to component rendering methods, electronic devices and storage media. Background Technology

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

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

[0004] This application provides a component rendering method, including: obtaining component metadata and real-time environment data of the component to be rendered, wherein the component metadata includes at least the rendering priority of the component to be rendered;

[0005] Environmental characteristics are calculated based on real-time environmental data;

[0006] Based on environmental characteristics and the target rendering prediction model, the rendering time of the component to be rendered is obtained. The target rendering prediction model is a pre-trained model used to predict the rendering time based on environmental characteristics.

[0007] The rendering strategy for the component to be rendered is determined based on rendering priority, environmental characteristics, and rendering time.

[0008] Render the components to be rendered according to the rendering strategy.

[0009] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described component rendering methods when executing the computer program.

[0010] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described component rendering methods.

[0011] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described component rendering methods.

[0012] This application obtains component metadata and real-time environment data of the component to be rendered, with the component metadata including at least the rendering priority of the component. Based on the real-time environment data, environmental characteristics are calculated. Based on the environmental characteristics and a target rendering prediction model, the rendering time of the component to be rendered is obtained. The target rendering prediction model is a pre-trained model used to predict rendering time based on environmental characteristics. Based on the rendering priority, environmental characteristics, and rendering time, a rendering strategy for the component to be rendered is determined. The component to be rendered is then rendered according to the rendering strategy. In this scheme, rendering time is predicted through environmental data acquisition, and combined with environmental characteristics and component priority, the rendering strategy is dynamically adjusted. Furthermore, the strategy adopted based on the rendering time can effectively shorten rendering latency. Attached Figure Description

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

[0014] Figure 1 An architecture diagram of a component rendering system provided in this application embodiment;

[0015] Figure 2 A flowchart of a component rendering method provided in this application embodiment Figure 1 ;

[0016] Figure 3 A flowchart of a component rendering method provided in this application embodiment Figure 2 ;

[0017] Figure 4 A structural diagram of a component rendering apparatus provided in an embodiment of this application;

[0018] Figure 5 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of 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. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

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

[0021] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0022] With the explosive growth in demand for multi-platform application development, such as Web, iOS, Android, and mini-programs, front-end development faces a host of core challenges:

[0023] The volume and complexity of data have surged: the number of enterprise-level application components exceeds 300, the redundancy of cross-platform adaptation code exceeds 50%, and development efficiency is low.

[0024] Severe device fragmentation: The performance difference between low-end Android devices (with less than 2GB of memory) and high-end models can be more than 10 times, and static optimization strategies cannot cover all scenarios.

[0025] Increased real-time requirements: Scenarios such as financial transactions and real-time data dashboards require rendering latency of <100ms, which traditional passive optimization methods cannot meet.

[0026] Currently, 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-platform rendering, relies on static compilation, and cannot dynamically adjust rendering strategies; React Native uses bridging communication, and the latency 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 increases maintenance costs by 40%-60%.

[0027] 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 according to the device model), compilation-stage optimization (such as TreeShaking) cannot solve runtime problems, monitoring tools (Lighthouse) require manual intervention, and no automated closed loop has been formed; low-end devices have large fluctuations in rendering frame rate (such as complex animations with a frame rate of <20fps on low-end Android devices), and cannot cope with dynamic environments such as network switching.

[0028] The protocol layer is missing and the protocol is not standardized: React Native achieves cross-language communication through JavaScript Bridge, and Vue achieves inter-component state synchronization through a custom event mechanism. The communication between components lacks standardized specifications, and state synchronization and resource scheduling rely on customized implementations, resulting in low collaboration efficiency; component communication rules are fragmented, state synchronization latency is high, and performance monitoring data lacks a unified feedback mechanism.

[0029] To address all or part of the aforementioned technical problems, embodiments of this application provide a component rendering method, electronic device, and storage medium. The method involves acquiring component metadata and real-time environment data of a component to be rendered, where the component metadata includes at least the rendering priority of the component. Based on the real-time environment data, environmental characteristics are calculated. The rendering time of the component to be rendered is obtained based on the environmental characteristics and a target rendering prediction model, where the target rendering prediction model is a pre-trained model used to predict rendering time based on environmental characteristics. A rendering strategy for the component to be rendered is determined based on the rendering priority, environmental characteristics, and rendering time. The component to be rendered is then rendered according to the rendering strategy. In this solution, rendering time is predicted through environmental data acquisition, and combined with environmental characteristics and component priority, the rendering strategy is dynamically adjusted. Furthermore, the strategy adopted based on the rendering time can effectively shorten rendering latency.

[0030] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0031] like Figure 1 As shown, Figure 1 The following is an architecture diagram of the component rendering system provided in the embodiments of this 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. The entire process of protocol definition, environment awareness, intelligent scheduling, and cross-platform rendering is automated through data interaction between the above modules.

[0032] like Figure 2 As shown, Figure 2A flowchart of a component rendering method provided in an embodiment of this application is provided. The method may include the following steps:

[0033] 201. Obtain the component metadata and real-time environment data of the component to be rendered.

[0034] 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 actual component object running in front-end development (such as buttons, charts, forms, etc.). It is the actual manifestation of the component's abstract definition, containing metadata such as unique identifiers, attribute configurations, and cross-platform rules, and is used to complete interactive processes such as registration, communication, and rendering in the system.

[0035] The component metadata of the component to be rendered can be standardized information describing the component's identity, behavior, cross-platform rules, and performance metrics. This component metadata can at least include the rendering priority of the component to be rendered. This priority can be one of the preset metadata when the component is created, pre-set during the component development phase (manually defined when writing code), and serves as the component's identity identifier in the system's resource scheduling. This rendering priority can refer to the execution order priority of the component in the resource scheduling and rendering process, used to determine the order in which the system allocates computing resources, network bandwidth, and rendering computing 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 according to personal experience or project requirements) will be loaded and rendered first to ensure the immediate availability of core functions; low-priority components (such as ad pop-ups and secondary data charts, defined as priority ≤ 3) will be processed after the core components are loaded to avoid consuming critical resources.

[0036] 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, it includes a preset "priority" field (e.g., priority=6) 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 (e.g., priority queue sorting).

[0037] For example, suppose the component metadata of the component to be rendered is a line chart component instance (cid="chart_line"):

[0038] {

[0039] "cid": "chart_line", / / Unique identifier for the component (e.g., the ID of a "line chart");

[0040] "dependencies": ["echarts.min.js", "theme.css"], / / Dependent resources (chart library, style file);

[0041] "priority":6, / / Scheduling priority (1-10);

[0042] "platform_rules": { / / Cross-platform rendering rules;

[0043] "web": { "render_engine": "svg", "event_bind": "mouseenter"}, / / Render using SVG on the web side, bind mouse entry event;

[0044] "weapp": { "render_engine": "canvas", "event_bind": "touchstart"}, / / The mini-program uses Canvas for rendering and binds the touch start event;

[0045] },

[0046] "metrics": { / / Performance metric thresholds;

[0047] "max_render_time": 150, / / unit ms, maximum rendering time is 150ms;

[0048] "memory_threshold": 512, / / unit KB, maximum memory usage 512KB;

[0049] }

[0050] As can be seen, the component's metadata may also include: a unique identifier (cid="chart_line"): used to uniquely identify the component within the system; dependencies (dependencies=["echarts.min.js", etc.]): external resources required for the component to run; cross-platform rules (platform_rules): such as using SVG rendering on the web client and Canvas rendering on the mini-program client; and performance thresholds (metrics): such as a maximum rendering time of 150ms and a memory threshold of 512KB.

[0051] In this embodiment of the 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 acquisition" sub-node.

[0052] 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, which 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.

[0053] 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 message of successful registration to the component to be rendered through the protocol mechanism; and after the dynamic resource scheduling module successfully obtains the metadata of the component to be rendered (for subsequent resource scheduling calculations) from the MCP protocol core layer, it can confirm that the component metadata of the component to be rendered has been correctly registered and stored.

[0054] 202. Based on real-time environmental data, environmental characteristics are calculated.

[0055] In this embodiment of the application, after obtaining the real-time environmental data of the component to be rendered, the real-time environmental data can be analyzed to calculate the environmental characteristics.

[0056] 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, and therefore the environment feature may be obtained by weighted calculation of the above data.

[0057] In some embodiments, environmental characteristics are calculated based on real-time environmental data, which may specifically include: acquiring 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 device index values ​​and bandwidth index values ​​based on the device data and bandwidth data, respectively; determining a platform correction coefficient based on the platform data; and calculating environmental characteristics based on the device index values, bandwidth index values, and platform correction coefficient.

[0058] It should be noted that the rendering speed data can refer to GPU computing power, which can be obtained through WebGL benchmark tests; memory usage data (performance.memory) can refer to the current memory usage of the device; bandwidth data can refer to the device's real-time bandwidth, which can be obtained through WebRTC speed tests; 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), etc.

[0059] After obtaining the aforementioned device data and bandwidth data, their respective indicator values ​​can be calculated. The device indicator values ​​corresponding to the device data can include rendering speed indicator values ​​and memory usage indicator values. Specifically, the aforementioned indicator values ​​can all be obtained by normalizing specific values.

[0060] For rendering speed metrics, a testing program can be used to measure the rendering speed of the component being rendered (e.g., how many frames per second it can draw). Then, the rendering speed level can be determined, for example: high-end (fast rendering speed, ≥50 frames per second), mid-range (medium rendering speed, 30-50 frames per second), and low-end (slow rendering speed, <30 frames per second). Each level is then scored, for example: high-end 80-100 points, mid-range 40-80 points, and low-end 0-40 points. The specific score is mapped to the ratio of the actual rendering speed within the corresponding level range, and this score is the rendering speed metric value, ensuring that the score reflects performance differences within the same level. Other data (memory usage data, bandwidth data, etc.) are calculated using the same method to obtain memory usage and bandwidth metrics values ​​respectively.

[0061] For platform data, a platform correction coefficient can be determined. Platform-level parameters (such as operating system, browser kernel, and terminal type, such as "Mini Program" and "low-end Android device") do not participate in the calculation of indicator values, but serve as supplementary correction items for environmental differences. These environmental characteristics are adjusted using δ (the platform correction coefficient). Platform-level characteristics (such as the sandbox environment of Mini Programs and insufficient system optimization on low-end Android devices) are environmental attributes that are not performance indicators and cannot be directly measured by quantifiable "computing power / bandwidth," but they significantly affect component rendering effects. Therefore, a fixed correction coefficient is used to quickly adapt to platform differences. This platform correction coefficient is a pre-set fixed value based on the inherent characteristics (such as rendering mechanisms and hardware limitations) of different platforms (such as Mini Programs and low-end Android devices). It is used to quickly correct the calculation results of environmental characteristics to adapt to the impact of platform differences on performance, without requiring real-time dynamic calculation. For example: δ=5 for Mini Programs, δ=-8 for low-end Android devices, etc.

[0062] In some embodiments, after obtaining device metric values ​​(rendering speed metric value and memory usage metric value), bandwidth metric value and platform correction coefficient, environmental characteristics can be calculated. Since different parameters have different effects on the rendering component, weights can be assigned to the device metric value and bandwidth metric value respectively. These metric weights can be obtained based on regression analysis of a large number of device datasets. For example, the metric weight of the rendering speed metric value is 0.4, the metric weight of the memory usage metric value is 0.3, and the metric weight of the bandwidth metric value is 0.3.

[0063] In some embodiments, the formula for calculating environmental characteristics may be:

[0064]

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

[0066] As can be seen, the rendering speed index, memory usage index, and bandwidth index were obtained through the above calculations. Therefore, n is 3. That is, the environmental characteristics can be obtained by calculating the product of the rendering speed index, memory usage index, bandwidth index and the corresponding index weight value, and then summing them with the platform correction coefficient.

[0067] In this embodiment, multi-dimensional environmental data collection and intelligent weighting algorithms are used to achieve dynamic resource scheduling and strategy configuration driven by environmental features, which effectively improves the efficiency and effect of component rendering.

[0068] 203. Based on environmental characteristics and the target rendering prediction model, obtain the rendering time of the component to be rendered.

[0069] In this embodiment of the 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).

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

[0071] The target rendering prediction model is a pre-trained model used to predict rendering time based on environmental characteristics. This model can be continuously iterated and optimized. Predicting rendering time is the core of achieving "proactive optimization," aiming to solve the problem of "passive static optimization" in existing technologies. Specifically, it can identify performance bottlenecks in advance. By using an LSTM model (i.e., the target rendering prediction model) to predict the rendering time of the component to be rendered in the current environment (e.g., a mid-range device with an EF value of 65), it can determine in advance whether it may exceed the performance threshold (e.g., max_render_time=150ms defined in the component metadata), avoiding situations where latency exceeds the standard during actual rendering (e.g., latency <100ms is required in financial transaction scenarios). In addition, it can also support intelligent decision-making: the prediction results are combined with real-time monitoring data (e.g., frame rate <30fps) to provide a basis for the reinforcement learning engine to generate optimization strategies (e.g., "switching rendering engines" or "compressing resources"), forming a closed loop of "prediction-execution-feedback," ensuring stable operation even on low-end devices (e.g., devices with an EF <50).

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

[0073] In the embodiments of this 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 is mainly related to three data: rendering priority, environmental characteristics, and rendering time. Of course, other data may also be included, and it is not specifically limited.

[0074] In some embodiments, this rendering strategy primarily aims to improve screen smoothness (FPS) and reduce memory usage. The rendering strategy dynamically performs the following operations based on the device's hardware performance (GPU, memory), network status (bandwidth), and platform characteristics:

[0075] Rendering engine switching: Dynamically select the rendering engine based on environment characteristics (EF). For example, when EF < 50 (low-end devices), switch the chart component from SVG rendering to Canvas rendering (to reduce performance consumption and rendering time).

[0076] 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 load simplified components (such as no animations or low-resolution resources).

[0077] Performance parameter tuning: In simple scenarios (such as EF<40), preset rules are triggered, such as disabling animated shadows and compressing image resources; in complex scenarios (such as EF≥40), CPU / GPU resources are dynamically allocated through reinforcement learning to prioritize the operation of high-priority components (such as the payment module);

[0078] Emergency intervention: When memory usage exceeds the limit (e.g., 550KB > 512KB threshold), immediately perform forced degradation loading (e.g., shut down unnecessary components, release cache).

[0079] In some embodiments, a priority rendering queue can be determined for rendering priority, thereby determining the rendering order and resource allocation of the components to be rendered.

[0080] 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 time exceeds the threshold (e.g., predicted 180ms > 150ms), strategies such as "switching rendering engines" or "compressing resources" are generated. If the predicted time is within a safe range, the current strategy is maintained to avoid over-optimization and resource waste. This "prediction-decision" linkage is the key to achieving "from passive optimization to proactive intervention" (solving the problem of "lagging static optimization strategies").

[0081] Therefore, the optimal rendering strategy for the component to be rendered can be determined by comprehensively considering rendering priority, environmental characteristics, and rendering time.

[0082] 205. Render the components to be rendered according to the rendering strategy.

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

[0084] In this embodiment, component metadata and real-time environment data of the component to be rendered are obtained. The component metadata includes at least the rendering priority of the component to be rendered. Environmental characteristics are calculated based on the real-time environment data. The rendering time of the component to be rendered is obtained based on the environmental characteristics and a target rendering prediction model, which is a pre-trained model used to predict rendering time based on environmental characteristics. A rendering strategy for the component to be rendered is determined based on the rendering priority, environmental characteristics, and rendering time. The component to be rendered is then rendered according to the rendering strategy. In this scheme, rendering time is predicted through environmental data acquisition, and combined with environmental characteristics and component priority, the rendering strategy is dynamically adjusted. Furthermore, the strategy adopted based on the rendering time can effectively shorten rendering latency.

[0085] like Figure 3 As shown, Figure 3 Another flowchart of a component rendering method provided for embodiments of this application, the method may include the following steps:

[0086] 301. Obtain the component metadata and real-time environment data of the component to be rendered.

[0087] 302. Based on real-time environmental data, environmental characteristics are calculated.

[0088] In the embodiments of this application, the description of steps 301 to 302 is the same as the detailed description of steps 201 to 202 in the above embodiments, and will not be repeated in the embodiments of this application.

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

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

[0091] 304. Perform data aggregation and feature extraction on user behavior data to obtain behavioral feature data.

[0092] In this embodiment of the application, user behavior data needs to be preprocessed before model training. This 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 processed behavior feature data is transmitted to the intelligent decision center through the core layer of the MCP protocol for model training.

[0093] It should be noted that edge computing nodes process real-time data generated during front-end operation, which includes: user behavior logs, such as user clicks, swipes, and dwell time; real-time state fragments of devices and the environment, such as short-term fluctuations in GPU computing power, changes in network bandwidth, and rendering frame rate snapshots; and historical performance fragments of component operation, such as short-term statistics on rendering time and memory usage of a component at a specific EF value. These are not full historical data, but rather incremental data generated in real time.

[0094] 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, and the amount of data is reduced (e.g., aggregation rate = 90%, which means the amount of data 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 transmitted and reduce the communication pressure between the front end and the intelligent decision center.

[0095] In some embodiments, user behavior logs are aggregated: high-frequency, repetitive user interactions (such as multiple clicks of the same button or page swiping trajectories) are statistically merged by time windows (e.g., 1 minute), retaining core features such as "behavior type + frequency + average interval," while removing repetitive details from the original logs (such as the precise millisecond-level timestamps of each click). Device / performance data is aggregated: real-time collected device status (such as GPU computing power and memory fluctuations) and network metrics (such as bandwidth and RTT) are calculated using a sliding window to obtain average, peak, or trend values ​​(such as average memory usage and bandwidth fluctuation within 5 seconds), replacing the high-frequency sampled raw data points and retaining trend features valuable for model training.

[0096] In some embodiments, feature filtering and redundancy removal can retain only key fields related to intelligent decision-making (such as "component ID + operation type" in user behavior and "EF value related indicators" in device data), while removing irrelevant and redundant information (such as duplicate device unique identifiers and meaningless log notes), thereby further compressing the data volume.

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

[0098] In this way, edge computing nodes reduce data transmission pressure while retaining the core information needed to train LSTM prediction models and reinforcement learning decision engines, supporting model iteration and policy optimization in the intelligent decision center. "Preprocessing" is a combination of "aggregation (reducing data volume) + lightweight LSTM (extracting effective features)," which solves the problem of raw data redundancy and provides high-quality input for model training in the intelligent decision center, making it a core component of "edge computing collaborative optimization."

[0099] 305. Based on component metadata, historical rendering data, and behavioral feature data, train the preset model to obtain the target rendering prediction model.

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

[0101] In this embodiment, the model is trained in advance using historical rendering data and user behavior, which solves the problem of raw data redundancy and provides high-quality data input for model training, effectively improving the model's prediction accuracy.

[0102] In some embodiments, when training a model, the training data can come from multi-dimensional information collected during system operation and preprocessed by edge computing nodes, specifically including: environmental and device data, component metadata, historical performance data, and user behavior data.

[0103] The environmental and equipment data can include: historical calculation results of environmental characteristics (including indicators such as GPU computing power, memory usage, network bandwidth, and platform correction coefficient); real-time status segments of devices / networks (such as GPU fluctuations and bandwidth change trends within a certain period of time), which are aggregated by edge computing nodes and retain key information such as "average value, peak value, and trend characteristics".

[0104] The component metadata can include: metadata submitted during component registration (such as component ID, priority, cross-platform rules, performance thresholds, etc.); and component dependencies (such as "chart_line" depending on "echarts.min.js"), which are used for correlation analysis between resource loading strategies and rendering performance.

[0105] Historical performance data may include: historical rendering time; performance monitoring metrics (such as historical frame rate, memory usage, network latency, etc., which can be collected in real time through the monitoring system); and 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 are used for calculating the reward function of reinforcement learning).

[0106] User behavior data may include user interaction logs aggregated by edge computing nodes (such as the number of clicks and dwell time of a component), which are used to analyze the correlation between "user behavior-component load-performance requirements" (such as high-frequency interactive components needing to prioritize rendering performance).

[0107] After these data are preprocessed by edge computing nodes (aggregating redundant information + lightweight LSTM preliminary feature extraction), they provide training samples for the LSTM model ("EF value + component metadata → rendering time") and reward calculation basis for the reinforcement learning engine ("policy → performance feedback"), ultimately supporting the model to dynamically optimize prediction accuracy and policy effectiveness.

[0108] 306. Based on environmental characteristics and the target rendering prediction model, obtain the rendering time of the component to be rendered.

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

[0110] In the embodiments of this application, the description of steps 306 to 307 is the same as the detailed description of steps 203 to 204 in the above embodiments, and will not be repeated in the embodiments of this application.

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

[0112] When determining a rendering strategy, it can include the rendering engine and loading rules. The rendering engine can be determined based on environmental characteristics, while the loading rules can be determined based on rendering priority and environmental characteristics.

[0113] Environmental characteristics are quantitative indicators that comprehensively consider device performance, network status, and platform type. Their core logic is to indirectly reflect device characteristics through EF values, achieving more accurate dynamic adaptation, rather than directly hard-coding rules based on device type (such as low-end Android devices). The calculation of environmental characteristics already includes device information (such as GPU computing power and memory) and platform correction coefficients (such as δ=-8 for low-end Android devices). Therefore, selecting a rendering engine based on environmental characteristics essentially integrates the influence of device type, but is more flexible. For example, the environmental characteristics of the same device may differ under different network conditions, and the corresponding strategies will also differ.

[0114] It should be noted that the loading rule refers to the resource loading rule formulated by the dynamic resource scheduling module based on environmental characteristics and rendering priority. The dynamic resource scheduling module adjusts the loading method and order of component resources according to the optimization strategy issued by the intelligent decision center. The loading strategy is a sub-strategy of the rendering strategy, and is a specific rule that transforms the rendering strategy into an executable resource loading action.

[0115] In some embodiments, the loading rule can be determined by a three-level loading strategy, which can be represented by the following Table 1:

[0116] Table 1. Three-level loading strategy table

[0117]

[0118] As can be seen from Table 1 above, loading rules can be determined based on environmental characteristics and priorities.

[0119] It should be noted that the preset mapping relationship is a pre-stored mapping relationship between 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 mapping relationship. For example, when EF < 50, the chart component is mapped to Canvas rendering to reduce performance consumption.

[0120] In this embodiment, 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 by combining priority and rendering time. By determining the rendering strategy from multiple perspectives, the rendering strategy can be more suitable for the current scene and the current component, effectively improving the rendering effect.

[0121] In some embodiments, the rendering instructions received by the cross-platform rendering engine serve as the initial rendering basis, generated based on the environmental characteristics and component metadata at that time (e.g., SVG rendering is used on the web when EF>50). Switching rendering modes is a dynamic adjustment to this initial rendering instruction. When the intelligent decision center generates an optimization strategy based on new monitoring data (e.g., frame rate drop, memory limit exceedance) or prediction results (e.g., rendering time will exceed the limit), the cross-platform rendering engine will modify the core parameters in the original rendering instruction (e.g., rendering engine type, resource loading level) based on the new strategy, realizing the iteration from "initial rendering" to "optimized rendering".

[0122] Switching rendering modes refers to cross-platform rendering engines changing the technical solutions or parameters that rendering depends on based on optimization strategies. The core is dynamic adjustment to adapt to changes in the environment. Specifically, this includes: switching rendering engines, such as switching from an SVG engine to a Canvas engine (reducing performance consumption when EF<50); adjusting rendering precision, such as switching from high-definition rendering (high resolution, complex animation) to degraded rendering (low resolution, no animation, suitable for low-end devices); and switching resource loading levels, such as switching from loading full component resources to loading simplified resources (such as lightweight components that only retain core functions).

[0123] In some embodiments, the rendering strategy is transmitted through a bidirectional communication link sub-node built into the core layer of the MCP protocol. This is a standardized information exchange channel between system modules. The specific process is as follows: After the intelligent decision center extracts the strategy, it encapsulates it into instructions that conform to the MCP protocol specification (such as including strategy type, target module, execution parameters, etc., for example: performing Canvas rendering switching on the component with cid=chart_line); the instructions are bidirectionally transmitted to the core layer of the MCP protocol through the bidirectional communication link, which supports uplink status reporting and downlink strategy push; the core layer of the MCP protocol receives and parses the instructions, and then forwards them to the dynamic resource scheduling module and the cross-platform rendering engine to drive the strategy execution, such as: updating the loading order and switching the rendering engine.

[0124] 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 the at least one initial rendering strategy is filtered based on the monitoring data of the rendering component to determine the rendering strategy of the component to be rendered.

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

[0126] In some embodiments, monitoring data can be collected through a monitoring system. The monitoring data consists of two parts: performance data reported by the cross-platform rendering engine (e.g., after completing component rendering, the engine 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); and real-time status data directly collected by the monitoring system (e.g., GPU computing power, memory usage), network environment (e.g., bandwidth, RTT latency), rendering stability (e.g., frame rate fluctuations). For example, it might detect that a low-end device's memory usage exceeds the limit (550KB > 512KB threshold).

[0127] The monitoring data focuses on key metrics affecting front-end performance, specifically including: rendering performance: rendering time (time from component start-up to display), frame rate (FPS, a metric for smoothness); resource usage: memory usage, CPU / GPU load; network status: real-time bandwidth, network latency (RTT), used to determine resource loading strategies (such as preloading / degradation loading); device and platform characteristics: device model, operating system version, browser / mini-program kernel, to help verify cross-platform adaptation. This monitoring data is the core basis for the intelligent decision center to generate optimization strategies, ensuring that the system can perceive performance bottlenecks in real time and proactively intervene.

[0128] In this embodiment, the final rendering strategy is determined from at least one initial strategy by real-time monitoring of frame rate and / or memory data. This allows for the selection of rendering strategies based on intuitive rendering results, effectively improving the rendering performance.

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

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

[0131] In this embodiment, Virtual Render Tree (VRT) data is a platform-independent intermediate representation of the front-end components after abstraction, used to achieve cross-platform rendering adaptation. VRT data is a standardized description of the component's structure, attributes, behavior, and dynamic rendering rules. This data is completely independent of specific platform syntax (such as HTML for the Web and WXML for mini-programs), retaining only the component's abstract logic, and providing a unified input for cross-platform conversion.

[0132] For example, virtual render tree data can be represented as:

[0133] {

[0134] "type": "Button",

[0135] "props": {

[0136] "onClick": "handleClick",

[0137] "style": { "backgroundColor": "#4A90E2"},

[0138] "renderEngine": "${EF>50 ? 'svg' : 'canvas'}"},

[0139] "children": ["Submit"];

[0140] }

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

[0142] In some embodiments, VRT data is obtained by parsing and transforming 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 or Vue's template syntax) is used as input and enters the VRT generator; the VRT generator processes the data through AST (Abstract Syntax Tree) parsing and logical abstraction to strip away platform-specific syntax and extract core information such as the component's type, attributes, and sub-components; it generates JSON-formatted VRT data conforming to the MCP protocol specification (as in the example above) and passes it to the MCP protocol core layer as input to the cross-platform rendering engine.

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

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

[0145] In this embodiment, the platform mapping rules are pre-stored in the platform mapping rule library of the cross-platform rendering engine. However, the rule content is dynamic and will be adjusted according to environmental changes (such as EF value and device type) rather than being fixed. 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 by default on the Web side and to a cover-view component on the mini-program side.

[0146] Dynamic features: Rules are adjusted in real time based on environmental characteristics. For example, the rendering engine is dynamically selected based on the EF value. If EF < 50, the chart component is mapped to Canvas rendering to reduce performance consumption. The basic template in the rule base can be overridden by dynamic logic triggered by the EF value, realizing a combination of "pre-stored templates + dynamic conditions".

[0147] In some embodiments, generating target platform code data is to address the differences in syntax and rendering mechanisms across different platforms. It converts the platform-independent Virtual Render Tree (VRT) into platform-specific executable code, ensuring that components can be correctly parsed and displayed on the target platform (e.g., web, mini-program, app). Different platforms have their own development syntax (e.g., HTML / CSS for web, WXML / WXSS for mini-programs, Swift / Java for apps) and rendering engines (e.g., SVG / Canvas for web, native rendering engines for mini-programs). Directly using a unified codebase will not allow cross-platform operation. Cross-platform rendering engines utilize the pre-stored correspondence between component types and platform syntax in a platform mapping rule base. For example, the Button component is mapped to... <button>The tag is mapped to the following in the mini-program: <cover-view>Tags convert VRT data (platform-independent intermediate representation) into native code for the target platform, enabling one-time definition and multi-platform adaptation.

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

[0149] In this embodiment, 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 target platform's native rendering capabilities to complete component drawing. The specific steps are as follows:

[0150] Code Conversion: The cross-platform rendering engine reads VRT data (such as {type: "Button", props: {...}}) and platform mapping rules (such as SVG rendering on the web when EF>50) issued by the core layer of the MCP protocol, and generates target platform code through the platform mapping rule library: Web: Generate HTML / CSS code (such as...) < / button> <button style="background-color:#4A90E2"> Submit< / button> ), compatible with SVG or DOM rendering engines; Mini Program side: generates WXML code (such as... <cover-view bindtap="handleClick" style="background-color:#4A90E2"> Submit< / cover-view> It adapts to the native Canvas engine of WeChat Mini Programs; On the APP side: it generates Swift (iOS) or Java (Android) code and calls the native control rendering interface.

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

[0152] 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 core layer of the MCP protocol (for subsequent optimization strategy iteration).

[0153] In this embodiment, a Virtual Render Tree (VRT) and a dynamic platform mapping engine are designed. By abstracting the intermediate representation of components and cross-platform conversion rules, the amount of cross-platform adaptation code is reduced by 61.6%. The platform-independent Virtual Render Tree (VRT) is converted into platform-specific executable code, ensuring that components can be correctly parsed and displayed.

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

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

[0156] 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. The reward function can evaluate the effect of the rendering strategy and perform iterative optimization of the strategy, optimizing resource allocation. The primary goal is to improve screen smoothness (FPS) while strictly controlling memory growth. Among these, FPS (Frames Per Second) and Memory Usage are the most directly related core indicators. Using the variables ΔFPS and Δmemory can better reflect the real-time effect of the strategy.

[0157] Specifically, an increase in ΔFPS corresponds to an increase in reward (encouragement), while an increase in Δmemory corresponds to a decrease in reward (penalty). Based on historical data and experience, the range of metric changes is estimated. Then, through experiments (such as testing weight combinations of 0.6 / 0.4, 0.8 / 0.2, 0.75 / 0.25), the balance between FPS improvement and memory control is evaluated, and finally, the weight that best represents the business objective in the current scenario is selected.

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

[0159]

[0160] in, That is, the reward function value. The change in screen smoothness is a core reward item, and its high weight highlights the primary goal of performance improvement. This represents the change in memory usage and serves as a constraint / penalty factor. A lower weight ensures that memory growth remains within an acceptable range. and For weight values, + =1, generally speaking > .

[0161] 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.

[0162] 314. If the reward function value is detected to be greater than or equal to the preset score within the preset time period, the component metadata, real-time environment data and rendering strategy will be stored accordingly.

[0163] In this embodiment, if the reward function value is less than a preset score, it indicates that the current rendering strategy is not effective for the component being rendered. Therefore, the rendering strategy can be adjusted, and the reward function value can continue to be monitored until it 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 component being rendered. Therefore, the rendering strategy can continue to be used, and the component metadata, real-time environment data, and rendering strategy can be stored accordingly.

[0164] The reward function is a standard for quantitatively evaluating the performance of a rendering strategy. It calculates a weighted average of these two metrics and outputs a comprehensive score: a higher score indicates a better strategy in improving smoothness (FPS) and controlling memory usage. After obtaining the reward function result, the system adjusts and optimizes the strategy based on the score, forming a closed-loop iteration: if the reward value is high (good strategy performance), the strategy is retained and stored in the "strategy knowledge base," and will be reused preferentially in similar scenarios in the future (e.g., with the same EF value and component type); if the reward value is low (poor strategy performance), the reinforcement learning engine will modify the strategy generation logic based on the result (e.g., adjusting resource allocation weights, changing rendering engine selection rules) until a better strategy is found.

[0165] In the embodiments of this application, the reward function is a scorer for the effectiveness of the optimization strategy, and the iterative adjustment of the strategy depends on this score. Together, they constitute the core feedback mechanism for reinforcement learning decision-making, ensuring that the optimization strategy can continuously adapt to the dynamic environment.

[0166] In this application embodiment, a standardized component communication architecture based on the MCP protocol is proposed. A metadata model is defined that includes a unique component identifier, cross-platform rules, and performance monitoring fields. Lightweight communication is achieved through the MessagePack binary protocol, which significantly reduces the amount of data transmitted and greatly reduces response latency.

[0167] We constructed a dynamic resource scheduling system driven by environmental characteristics. Through multi-dimensional environmental data collection and intelligent weighting algorithms, we implemented a three-level loading strategy (preloading / on-demand loading / degradation loading) and priority queue optimization, which reduced memory usage on low-end devices by 40.1% and shortened the first screen loading time by 50%.

[0168] By designing a Virtual Render Tree (VRT) and a dynamic platform mapping engine, and by abstracting intermediate component representations and cross-platform conversion rules, the amount of cross-platform adaptation code is reduced by 61.6%, and automatic switching of rendering engines (such as SVG→Canvas) is supported on low-end devices, reducing rendering time by 58%.

[0169] By introducing an LSTM prediction model and a reinforcement learning decision engine, a closed loop of "monitoring-prediction-optimization" is constructed. The performance bottleneck prediction error rate (MAE) is less than 10%, the resource allocation efficiency in complex scenes is improved by 40% compared with traditional algorithms, and the frame rate stability of animation rendering is improved by 100%.

[0170] It can effectively solve the core problems in existing technologies, such as high code redundancy in cross-platform development (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.

[0171] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0172] like Figure 4 As shown, embodiments of this application also provide a component rendering apparatus, which may include:

[0173] The acquisition module 401 is used to acquire the component metadata and real-time environment data of the component to be rendered. The component metadata includes at least the rendering priority of the component to be rendered.

[0174] The processing module 402 is used to calculate environmental characteristics based on real-time environmental data;

[0175] The processing module 402 is also used to obtain the rendering time of the component to be rendered based on environmental features and the target rendering prediction model. The target rendering prediction model is a pre-trained model used to predict the rendering time based on environmental features.

[0176] The processing module 402 is also used to determine the rendering strategy of the component to be rendered based on the rendering priority, environmental characteristics and rendering time.

[0177] The processing module 402 is also used to render the component to be rendered according to the rendering strategy.

[0178] In some embodiments, the acquisition module 401 is specifically used to acquire 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.

[0179] The processing module 402 is specifically used to determine the device index value and the bandwidth index value based on the device data and the bandwidth data, respectively.

[0180] Processing module 402 is specifically used to determine the platform correction coefficient based on platform data;

[0181] The processing module 402 is specifically used to calculate environmental characteristics based on equipment index values, bandwidth index values, and platform correction coefficients.

[0182] In some embodiments, the acquisition module 401 is specifically used to acquire virtual rendering tree data corresponding to the component to be rendered.

[0183] Processing module 402 is specifically used to generate target platform code data based on component metadata, virtual rendering tree data, and platform mapping rules;

[0184] The processing module 402 is specifically used to execute target platform code data according to the rendering strategy in order to render the component to be rendered.

[0185] In some embodiments, the processing module 402 is specifically used to determine the target rendering engine based on environmental features and a preset correspondence, wherein the preset correspondence is a pre-stored correspondence between environmental features and rendering engines;

[0186] The processing module 402 is specifically used to select a target loading rule from a pre-stored loading rule library based on rendering priority and environmental characteristics.

[0187] The processing module 402 is specifically used to determine the rendering strategy of the component to be rendered based on the rendering priority, the target rendering engine, the target loading rules, and the rendering time.

[0188] In some embodiments, the processing module 402 is specifically configured to determine at least one initial rendering strategy based on rendering priority, environmental characteristics, and rendering time.

[0189] The acquisition module 401 is specifically used to collect monitoring data of the component to be rendered in real time. The monitoring data includes real-time frame rate and / or memory data.

[0190] The processing module 402 is specifically used to filter at least one initial rendering strategy based on the monitoring data of the rendering component, and determine the rendering strategy of the component to be rendered.

[0191] In some embodiments, the acquisition module 401 is further configured to acquire real-time smoothness and real-time memory usage data of the component to be rendered;

[0192] The processing module 402 is also used to determine the reward function value corresponding to the rendering strategy based on real-time smoothness and real-time memory usage data;

[0193] The processing module 402 is also used to adjust the rendering strategy when the reward function value is less than the preset score, so that the reward function value is greater than or equal to the preset score.

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

[0195] In some embodiments, the acquisition module 401 is further configured to acquire historical rendering data and user behavior data;

[0196] Processing module 402 is also used to perform data aggregation and feature extraction on user behavior data to obtain behavioral feature data;

[0197] The processing module 402 is also used to train the preset model based on component metadata, historical rendering data and behavioral feature data to obtain the target rendering prediction model.

[0198] In the embodiments of this application, the description of the features corresponding to the component rendering apparatus in the embodiments can be found in the relevant description of the component rendering method in the embodiments, and will not be repeated here.

[0199] like Figure 5 As shown, embodiments of this application also provide 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 perform the steps in any of the above-described component rendering method embodiments.

[0200] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described component rendering method embodiments at runtime.

[0201] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0202] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described component rendering method embodiments.

[0203] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described component rendering method embodiments.

[0204] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.

[0205] The foregoing has provided a detailed description of the process monitoring of a storage system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A component rendering method, characterized in that, The method includes: Obtain the component metadata and real-time environment data of the component to be rendered, wherein the component metadata includes at least the rendering priority of the component to be rendered; Obtain the 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; Based on the device data and the bandwidth data, determine the device index value and the bandwidth index value respectively; Based on the platform data, determine the platform correction coefficient; The environmental characteristics are calculated based on the device index value, the bandwidth index value, and the platform correction coefficient. Based on the environmental features and the target rendering prediction model, the rendering time of the component to be rendered is obtained. The target rendering prediction model is a pre-trained model used to predict the rendering time based on environmental features. The target rendering engine is determined based on the environmental features and the preset correspondence, where the preset correspondence is a pre-stored correspondence between environmental features and rendering engines; Based on the rendering priority and the environmental characteristics, a target loading rule is selected from a pre-stored loading rule library; the target loading rule includes loading method and order, and the target loading rule is determined by a three-level loading strategy, which includes: the correspondence between environmental characteristics, loading strategy, queue algorithm and scene; The rendering strategy for the component to be rendered is determined based on the rendering priority, the target rendering engine, the target loading rule, and the rendering time. The component to be rendered is rendered according to the rendering strategy.

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

3. 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: Obtain the real-time smoothness and real-time memory usage data of the component to be rendered; Based on the real-time smoothness and the real-time memory usage data, determine the reward function value corresponding to the rendering strategy; 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.

4. The method according to claim 3, characterized in that, After determining the reward function value corresponding to the rendering strategy based on the real-time smoothness and the real-time memory usage data, the method further includes: If it is detected that the reward function value is greater than or equal to the preset score within a preset time period, then the component metadata, the real-time environment data, and the rendering strategy are stored accordingly.

5. The method according to claim 1, characterized in that, Before obtaining the rendering time of the component to be rendered based on the environmental characteristics and the target rendering prediction model, the method further includes: Acquire historical rendering data and user behavior data; The user behavior data is aggregated and features are extracted to obtain behavioral feature data; The target rendering prediction model is obtained by training the preset model based on the component metadata, the historical rendering data, and the behavioral feature data.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the component rendering method as described in any one of claims 1 to 5.

7. 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 as described in any one of claims 1 to 5.

Images