Method for allocating front-end resources and electronic device

Abstract

The application discloses a front-end resource allocation method and an electronic device. The method comprises the following steps: collecting performance index data and user interaction event stream data of a front-end runtime, wherein the performance index data comprises time series data of at least one target performance index within a preset time window; performing trend prediction on the target performance index based on a preset time series prediction model and the time series data of the target performance index within the preset time window, to determine a performance prediction value corresponding to the target performance index; determining a front-end health degree according to the performance prediction value corresponding to the target performance index; generating a corresponding resource demand package according to the user interaction event stream data; determining a resource allocation strategy according to the front-end health degree and the resource demand package; and executing the resource allocation strategy to allocate front-end resources. The front-end resource allocation method provided by the application can improve the performance of front-end application running.

Description

Technical Field

[0001] This application relates to the field of front-end development technology, and in particular to a method for allocating front-end resources and an electronic device. Background Technology

[0002] With the increasing prevalence of single-page applications (SPAs) and complex front-end architectures, the business logic and interaction complexity of front-end applications are constantly shifting forward. These applications typically contain numerous dynamic components, resulting in highly dynamic and uncertain resource requirements. This leads to issues such as memory leaks, main thread blocking, and interaction stuttering during long-term operation. Related technologies cannot detect the dynamically generated resource pressure during front-end application runtime and cannot allocate additional resources as needed in a timely manner, resulting in insufficient resources for front-end application operation and consequently, poor performance. Summary of the Invention

[0003] This application provides a method and electronic device for allocating front-end resources, which can improve the timeliness of resource allocation and thus improve the performance of front-end applications.

[0004] This application provides a method for allocating front-end resources, including:

[0005] Collect performance metrics data and user interaction event stream data during front-end runtime. The performance metrics data includes time-series data of at least one target performance metric within a preset time window.

[0006] Based on the preset time series prediction model and the time series data of the target performance index within the preset time window, the trend of the target performance index is predicted to determine the performance prediction value corresponding to the target performance index.

[0007] Determine the front-end health based on the predicted performance values ​​corresponding to the target performance indicators;

[0008] Generate corresponding resource requirement packages based on user interaction event stream data;

[0009] Determine the resource allocation strategy based on the front-end health status and resource requirement package;

[0010] Implement resource allocation strategies to allocate front-end resources.

[0011] This application also provides a front-end resource allocation device, including:

[0012] The acquisition module is used to collect performance indicator data and user interaction event stream data during front-end runtime. The performance indicator data includes time-series data of at least one target performance indicator within a preset time window.

[0013] The processing module is used to perform trend prediction on the target performance indicator based on the preset time series prediction model and the time series data of the target performance indicator within a preset time window, so as to determine the performance prediction value corresponding to the target performance indicator.

[0014] The processing module is also used to determine the front-end health based on the performance prediction value corresponding to the target performance index;

[0015] The processing module is also used to generate corresponding resource requirement packages based on user interaction event stream data;

[0016] The processing module is also used to determine resource allocation strategies based on the front-end health status and resource requirement packages;

[0017] The processing module is also used to execute resource allocation strategies to allocate front-end resources.

[0018] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the above-described front-end resource allocation method when executing the computer program.

[0019] 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 the above-described front-end resource allocation method.

[0020] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned front-end resource allocation method.

[0021] The front-end resource allocation method and electronic device provided in this application collect time-series data of target performance indicators to predict their trends and obtain predicted performance values. Based on these predicted values, the front-end health can be determined, allowing for early detection of front-end resource pressure. Furthermore, based on user interaction event stream data, corresponding resource requirement packages are determined to understand user resource needs in advance. By implementing the resource allocation strategy determined based on the front-end health and resource requirement packages, and by promptly allocating resources according to front-end resource pressure and user resource needs, the timeliness of resource allocation is improved. This ensures that the front-end application has sufficient resources during runtime, thereby improving its performance. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of a scenario provided for an embodiment of this application;

[0024] Figure 2 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 1 ;

[0025] Figure 3 This is a schematic diagram of the system architecture as an example in this application;

[0026] Figure 4 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 2 ;

[0027] Figure 5 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 3 ;

[0028] Figure 6 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 4 ;

[0029] Figure 7 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 5 ;

[0030] Figure 8 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 6 ;

[0031] Figure 9 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 7 ;

[0032] Figure 10 A schematic diagram of the decision-making logic as an example;

[0033] Figure 11 Here is a list of candidate components for the example;

[0034] Figure 12 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 8 ;

[0035] Figure 13 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 9 ;

[0036] Figure 14 This is a schematic diagram illustrating the process of component sleep and component wake-up;

[0037] Figure 15A sequence diagram of visual snapshot generation and recovery as an example;

[0038] Figure 16 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 10 ;

[0039] Figure 17 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 10 one;

[0040] Figure 18 A schematic diagram of the structure of the front-end resource allocation device provided in the embodiments of this application;

[0041] Figure 19 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

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

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

[0044] It should also be noted that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. The terms "installed," "connected," and "linked" should be interpreted broadly, for example, they can be fixed connections, detachable connections, or integral connections; they can be mechanical connections or electrical connections; they can be direct connections or indirect connections through an intermediate medium; they can be internal connections between two elements. The terms "parallel," "perpendicular," and "equal" include the described situation and situations similar to the described situation, the range of which is within an acceptable deviation range, wherein the acceptable deviation range is determined by those skilled in the art taking into account the measurement under discussion and the error associated with the measurement of a particular quantity (i.e., the limitations of the measurement system). For example, "parallel" includes absolute parallelism and approximate parallelism, where an acceptable deviation range for approximate parallelism can be, for example, within 5°; "perpendicular" includes absolute perpendicularity and approximate perpendicularity, where an acceptable deviation range for approximate perpendicularity can also be, for example, within 5°. "Equal" includes absolute equality and approximate equality, where an acceptable deviation range for approximate equality can be, for example, the difference between the two equal items being less than or equal to 5% of either one. Those skilled in the art will understand the specific meaning of the above terms in this application based on the specific circumstances.

[0045] Figure 1 This is a schematic diagram of a scenario provided in an embodiment of this application. Figure 1 The example demonstrates a Single Page Application (SPA), where the entire application loads only one Hypertext Markup Language (HTML) page. For example... Figure 1 As shown, in Figure 1 The SPA instance in the example comprises multiple blocks, including "Notification Bar," "Recommended Content," "Homepage," "Settings," and "My Profile." The recommended content block includes multiple sample contents, such as the first content, the second content, and so on up to the nth content. Switching content does not refresh the entire page; only a specific block is updated.

[0046] In the field of front-end development technology, with the popularization of single-page applications and complex front-end architectures, the business logic and interaction complexity of front-end applications are constantly moving forward. Moreover, such applications usually contain a large number of dynamic components, and their resource requirements are highly dynamic and uncertain, which leads to problems such as memory leaks, main thread blocking, and interaction lag in the long-term operation of front-end applications.

[0047] Currently, optimizations for front-end performance in related technologies typically employ static strategies such as code splitting and lazy loading, which allocate necessary resources during front-end application initialization. However, these technologies cannot detect dynamic resource pressures generated during front-end application runtime, such as sudden data bursts or complex computational tasks. Consequently, these technologies cannot allocate additional resources to the front-end application in a timely manner, leading to insufficient runtime resources and consequently, poor performance.

[0048] The front-end resource allocation method provided in this application collects time-series data of target performance indicators to predict their trends, thereby obtaining predicted performance values. Based on these predicted values, front-end health can be determined, allowing for early detection of resource pressure. Furthermore, user interaction event stream data is used to determine corresponding resource requirement packages, providing advance understanding of user resource needs. By implementing a resource allocation strategy determined based on front-end health and resource requirement packages, and by promptly allocating resources according to front-end resource pressure and user resource demands, the timeliness of resource allocation is improved. This ensures sufficient resources for the front-end application during runtime, thereby enhancing its performance.

[0049] The embodiments of this application provide a method for allocating front-end resources, and the system is described in detail below: Figure 2 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, it includes:

[0050] S201. Collect performance metrics data and user interaction event stream data during front-end runtime, wherein the performance metrics data includes time-series data of at least one target performance metric within a preset time window.

[0051] Combined with scenario examples, Figure 3This is a schematic diagram of the system architecture for this application example. The front-end application container is the "environment / carrier" that hosts and runs the front-end code, comprising three core modules: a runtime monitoring and trend prediction module, a user intent parsing and resource mapping module, and an autonomous resource scheduler. The runtime monitoring and trend prediction module is responsible for collecting performance metric data, trend prediction, and front-end health calculation. The user intent parsing and resource mapping module is responsible for collecting user interaction event stream data, application intent prediction, and quantifying resource demand packages. The autonomous resource scheduler includes a decision engine, an executor, and a component hibernation pool. The decision engine determines a decision tree based on a cost-benefit model. The decision tree includes components that need to be hibernated and components that need to be woken up. The executor is mainly used to execute hibernation or wake-up of components according to the decision tree and to process visual snapshots. The component hibernation pool is a cache area used to store serialized state data and visual snapshots of unloaded or hibernated components; it can be memory storage or a browser. The runtime monitoring and trend prediction module, the user intent parsing and resource mapping module, and the autonomous resource scheduler work together to achieve resource allocation.

[0052] For example, the performance metrics collected by the runtime monitoring and trend prediction module include target performance metrics such as memory usage, duration of long-running tasks, and frame rate. Memory usage reflects memory pressure and can be obtained through the browser's performance memory interface. The duration and frame rate of long-running tasks reflect the health of the main thread and can be monitored through a preset performance observer interface to determine their frequency and total time consumption, thus obtaining the duration of long-running tasks. The actual frame rate can be determined through a preset animation frame callback interface to obtain the corresponding frame rate data. The preset time window can be determined based on actual conditions, for example, it can be 10 seconds. Therefore, the performance metric data includes time-series data on memory usage within 10 seconds, time-series data on long-running task duration within 10 seconds, and time-series data on frame rate within 10 seconds.

[0053] Optional, Figure 4 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 2 ,like Figure 4 As shown, S201 includes:

[0054] S401. Within the preset time window, collect performance data corresponding to the target performance indicators according to the preset collection cycle.

[0055] Based on the scenario example, the data collection period can be determined according to the actual situation, such as 2 seconds. Therefore, within a time window, performance data corresponding to the target performance metric is collected every two seconds. For example, taking memory usage as an example, the collected memory usage values ​​are u1, u2, u3, u4, and u5.

[0056] S402. Arrange the performance data according to the corresponding acquisition order to obtain the time-series data of the target performance index within the preset time window.

[0057] With a scenario example, time-series data can be represented as M = {m1, m2, m3, ..., mq}, where M can be replaced according to the actual target performance metric type. For example, memory usage can be denoted as "U", duration as "T", frame rate as "F", and q is the number of data.

[0058] The collected memory usage data is combined according to the order of collection, and the resulting time-series data of memory usage can be denoted as U = {u1, u2, u3, u4, u5}. Similarly, the processing time and frame rate of long tasks can be obtained in the same way as the memory usage data collection, respectively obtaining the time-series data corresponding to the processing time of long tasks and the time-series data corresponding to the frame rate. The time-series data corresponding to the processing time of long tasks can be denoted as T = {t1, t2, t3, t4, t5}, and the time-series data corresponding to the frame rate can be denoted as F = {f1, f2, f3, f4, f5}.

[0059] Based on the method provided in this example, by using a fixed acquisition period, real-time performance data of the target performance index at multiple times can be obtained. Therefore, the obtained time-series data can accurately reflect the dynamic performance changes of the target performance index and improve the accuracy of performance prediction of the target performance index.

[0060] S202. Based on the preset time series prediction model and the time series data of the target performance index within the preset time window, perform trend prediction on the target performance index to determine the performance prediction value corresponding to the target performance index.

[0061] Based on the scenario example, the time series forecasting model can be selected as the Weighted Moving Average (WMA) model.

[0062] Optional, Figure 5 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 3 ,like Figure 5 As shown, S202 includes:

[0063] S501. Determine the first weight of the performance data corresponding to the target performance index.

[0064] Based on the scenario example, the first weight can be determined using the following formula:

[0065]

[0066] Where n is the size of the time window, for example, it can be 10 seconds; This represents a weight vector that decreases in time from most recent to oldest. =1, 2, 3, ..., q.

[0067] S502. Based on the first weight corresponding to the performance data and the prediction formula corresponding to the time series prediction model, perform trend prediction on the target performance index to obtain the performance prediction value corresponding to the target performance index.

[0068] With a scenario example, the prediction formula for the WMA model is:

[0069]

[0070] in, This represents the predicted performance value; similarly, The value can be replaced according to the actual target performance metric type. For example, the predicted value of memory usage can be denoted as "". The predicted duration can be denoted as "". The predicted frame rate can be denoted as "". ".

[0071] so,

[0072]

[0073]

[0074]

[0075] Based on the prediction formulas provided above, the predicted values ​​for memory usage, processing time for long tasks, and frame rate can be obtained respectively. Therefore, based on the method provided in this example, the weight corresponding to data collected more recently can be increased. In this way, the trend of data changes can be reflected more sensitively, and the performance prediction values ​​obtained by using the WMA model are more accurate.

[0076] S203. Determine the front-end health based on the performance prediction values ​​corresponding to the target performance indicators.

[0077] With a scenario example, the Frontend Health Score (FHS) is a quantitative score determined by combining historical data (which can be time-series data within the collected time window) and predicted values ​​of multiple performance indicators during frontend runtime. It can be a scalar between 0 and 1. The lower the frontend health score, the closer the frontend application's performance is to its bottleneck.

[0078] Optional, Figure 6 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 4 ,like Figure 6 As shown, S203 includes:

[0079] S601. Determine the performance health status corresponding to the target performance index based on the performance prediction value corresponding to the target performance index.

[0080] Based on a scenario example, for memory usage, the growth rate of memory usage within a corresponding time window is determined using the collected time-series data. For instance, the growth rate between any two memory usage values ​​in the time-series data is determined, and then the average of these two growth rates is calculated to obtain the growth rate of memory usage within the corresponding time window. The performance health level corresponding to memory usage is determined using the following formula:

[0081]

[0082] in, This indicates the performance health status corresponding to memory usage. This represents the performance prediction value corresponding to memory usage. This represents the growth rate of memory usage. α is an adjustment coefficient used to control the impact of the growth rate on performance health, and can be a preset value.

[0083] The performance health of a long-running task is determined using the following formula:

[0084]

[0085] in, This indicates the performance health status corresponding to the processing time of long tasks. This represents the predicted performance value corresponding to the duration, where n is the size of the time window.

[0086] The performance health of the frame rate is determined using the following formula:

[0087]

[0088] in, This indicates the performance health status corresponding to the frame rate. The predicted value representing the frame rate. This indicates the preset frame rate target value, which can be 60fps.

[0089] S602. Determine the second weight corresponding to the target performance index.

[0090] Based on scenario examples, the second weights corresponding to memory usage, processing time for long tasks, and frame rate can be denoted as w1, w2, and w3, respectively. w1, w2, and w3 are adjustable weight coefficients that can be adjusted according to actual conditions, and w1 + w2 + w3 = 1. Different values ​​of w1, w2, and w3 are used to reflect the relative importance of memory usage, processing time for long tasks, and frame rate in the business scenario. For example, in memory-intensive application scenarios, such as monitoring dashboards, recommended values ​​are: w1 = 0.5, w2 = 0.3, w3 = 0.2, indicating memory priority; in interaction-intensive application scenarios, such as real-time collaboration tools, recommended values ​​are w1 = 0.3, w2 = 0.4, w3 = 0.3, indicating main thread priority for processing long tasks.

[0091] S603. The performance health of the target performance index is weighted and summed according to the second weight corresponding to the target performance index to obtain the corresponding front-end health.

[0092] Based on the scenario example, the front-end health score (FHS) can be determined using the following formula:

[0093] FHS=w1× +w2× +w3×

[0094] Based on the method provided in this example, the current front-end health is obtained by weighted summation according to the health and weight corresponding to the target performance index. Since the determination of the front-end health incorporates multiple performance indicators, the determined front-end health can comprehensively reflect the front-end performance.

[0095] S204. Generate the corresponding resource requirement package based on the user interaction event stream data.

[0096] In conjunction with the scenario example, the user interaction event stream data is collected by the user intent parsing and resource mapping module. The user intent parsing and resource mapping module is a bridge connecting user behavior and system resource decision-making. Its core objective is to parse the user's micro-level and continuous interactive behavior in real time into future operational intents with clear intents and quantified resource requirements, thereby obtaining the corresponding resource requirement package based on the obtained user intents and quantified resource requirements.

[0097] Optional, Figure 7 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 5 ,like Figure 7 As shown, S204 includes:

[0098] S701. Based on the user interaction event stream data, perform user intent recognition to determine the target component corresponding to the user intent.

[0099] With scenario examples, a low-intrusive event detector can collect raw user interaction event stream data in real time. This data includes pointer movement trajectory, hover duration, scrolling speed and direction, and click and focus switching history. The collected user interaction event stream data can be input into a preset intent recognition state machine for processing. The core of this intent recognition state machine is a configurable rule base, where each rule defines a mapping relationship from a specific behavior pattern to a preset intent state. The intent recognition state machine dynamically matches the rule base based on the input user interaction event stream data, thereby determining and outputting the most likely short-term user intent state. For example, if the user interaction event stream data indicates that the user is continuously scrolling down at high speed in the "Big Data Table" area, the intent state can be determined as "More table rows will be rendered soon." Or, if the user interaction event stream data indicates that the mouse hovers over the "3D Model View" component for more than a set duration, the intent state can be determined as "Interacting with or rotating the 3D model is about to occur." When the intent state is "more table rows are about to be rendered", the target component is the table component. When the intent state is "interaction or rotation of the 3D model is about to occur", the target component is the 3D model component.

[0100] S702. Determine the target resource consumption data corresponding to the target component.

[0101] Based on a scenario example, the user intent parsing and resource mapping module can maintain a local resource consumption archive. The initial data for this archive can be derived from performance benchmark tests during development. During runtime, the archive can be dynamically updated using a sliding window exponential weighted average algorithm. Specifically, after each component completes rendering or loading, actual resource consumption data (such as memory increment and rendering time) can be collected, and the corresponding archive entry can be updated according to the following formula:

[0102]

[0103] in, This represents the number of archive entries updated in the resource consumption archive. The current number of entries stored in the resource consumption archive. The values ​​are the measured values, and λ is the smoothing coefficient (range 0~1, default 0.7). A larger λ indicates higher weighting of historical data and smoother updates, while a smaller λ indicates greater sensitivity to new data. Adjusting λ achieves a balance between stability and sensitivity. For components loaded for the first time (without a corresponding entry in the resource consumption archive), the system automatically creates a new entry and initializes it with the measured values. Simultaneously, it dynamically updates the archives of each component by combining the component's lifecycle and performance monitoring data. For example, performance monitoring data can include: memory increment during loading (bytes), average rendering time (ms), loading network overhead (bytes), and component sleep / wake-up operation overhead coefficients. When the intent state machine recognizes the intent state, which includes a unique identifier for the target component, it matches the identifier of the target component with the resource consumption archive to determine the latest resource consumption archive for that target component. The data recorded in the latest resource consumption archive is then used as the target resource consumption data.

[0104] For example, the latest resource consumption profile for the target component includes: memory increment during loading: 50,000,000 (bytes), average rendering time: 120 (ms), network overhead during loading: 200,000 (bytes), and component sleep / wake-up operation overhead coefficient: 0.5.

[0105] S703. Determine the corresponding user behavior data based on the user interaction event stream data.

[0106] In conjunction with scenario examples, user behavior data refers to the actual actions performed by the user during interactive events. For example, user behavior data can be hovering behavior (including the actual hovering duration) or scrolling behavior (including the actual scrolling speed).

[0107] S704. Based on user behavior data and a preset quantification formula, quantify the intensity of the user's intent to obtain the corresponding target intensity value.

[0108] With specific scenario examples, different quantification formulas can be used to convert user behavior data into an intensity value between 0 and 1 for different behavior types. For example, the corresponding quantification formula for hovering behavior is:

[0109] Intensity value = min(1, actual hovering time / preset maximum judgment time)

[0110] For scrolling behavior, the corresponding quantification formula is:

[0111] Intensity value = min(1, actual rolling speed / preset speed threshold)

[0112] The preset maximum judgment time and preset speed threshold can be determined according to the actual situation.

[0113] S705. Determine the urgency of activating the target component based on the target intensity value.

[0114] Based on scenario examples, the urgency level is derived by linearly mapping the intensity value to a preset intensity value threshold range. The urgency level value is between 0 and 1, and the higher the urgency level value, the more urgent the user's intention.

[0115] Optional, Figure 8 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 6 ,like Figure 8 As shown, S705 includes:

[0116] S801. If the target intensity value is less than or equal to the preset first intensity threshold, then the preset lower limit threshold of urgency is determined as the target urgency.

[0117] Based on the scenario example, the first intensity threshold can be determined according to the actual situation. For example, if the first intensity threshold is 0.2, and the target intensity value is ≤0.2, the preset lower limit threshold of urgency can be determined as the target urgency. As mentioned above, the value of urgency is between 0 and 1, so when the target intensity value is ≤0.2, the target urgency = 0.

[0118] S802. If the target intensity value is greater than or equal to the preset second intensity threshold, then the preset upper limit threshold of urgency is determined as the target urgency, wherein the second intensity threshold is greater than the first intensity threshold.

[0119] Based on the scenario example, the second intensity threshold can be determined according to the actual situation. For example, if the second intensity threshold is 0.8, and the target intensity value is ≥0.8, the preset upper limit threshold of urgency can be determined as the target urgency. As mentioned above, the value of urgency is between 0 and 1, so when the target intensity value is ≥0.8, the target urgency = 1.

[0120] S803. If the target intensity value is greater than the first intensity threshold and less than the second intensity threshold, the target urgency is obtained according to the preset linear mapping formula between the intensity value and the urgency.

[0121] Based on a scenario example, the preset linear mapping formula between intensity value and urgency is:

[0122] Urgency = Lower threshold of urgency + (Upper threshold of urgency - Lower threshold of urgency) × (Intensity value - First intensity threshold) / (Second intensity threshold - First intensity threshold). When 0.2 < target intensity value < 0.8, the target intensity value can be substituted into this linear mapping formula to obtain the corresponding target urgency. Based on the method provided in this example, it can be ensured that the higher the intensity value, the higher the corresponding urgency value. The higher the urgency value, the more urgent the user's intention. The order of executing user intentions can be flexibly adjusted according to urgency to complete user intentions with high urgency in a timely manner.

[0123] S706. Integrate the target resource consumption data and target urgency to generate a resource requirement package.

[0124] By combining the target resource consumption data and the user's intended urgency with the scenario examples, a corresponding resource requirement package is obtained.

[0125] For example, the resource requirements include: the target resource consumption data is 50,000,000 bytes of memory for running / loading the target component ("3D Model View" component); the target urgency is 0.8.

[0126] Based on the method provided in this example, by identifying user intents and quantifying the strength of user intents, user intents with higher strength values ​​can be prioritized for execution, thereby improving the targeting of resource allocation decisions.

[0127] S205. Determine the resource allocation strategy based on the front-end health status and resource requirement package.

[0128] Based on scenario examples, the resource allocation strategy can be determined by the autonomous resource scheduler, which is the decision-making and execution hub module at the front end. It can autonomously make decisions and execute fine-grained resource allocation based on the FHS and quantified resource demand packages.

[0129] Optional, Figure 9 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 7 ,like Figure 9 As shown, S205 includes:

[0130] S901. Determine the target resources required by the target component based on the target resource consumption data in the resource requirement package.

[0131] Based on the example scenario, the resource requirements package could include: the target resource consumption is 50,000,000 bytes of memory for running / loading the target component ("3D Model View" component); the target urgency is 0.8. Therefore, according to the example resource requirements package, the target resources required to load the target component ("3D Model View" component) are 50,000,000 bytes, approximately 48.8 MB.

[0132] S902. If the front-end health is less than or equal to the preset lower health threshold and there is a target component, the resource allocation strategy is determined as follows: control some components to hibernate according to the target resources to release the resources corresponding to some components; start the target component according to the target urgency and allocate the released resources to the target component, wherein the resources corresponding to some components are not less than the target resources.

[0133] Based on scenario examples, both the lower and upper health thresholds can be determined according to actual conditions. For instance, the lower health threshold can be 0.5, and the upper health threshold can be between 0.3 and 0.8, such as 0.7. These thresholds can be fine-tuned according to specific scenarios. For example, for low-end devices with more limited resources, the lower health threshold can be increased to 0.6 to trigger preventative scheduling earlier. The system recognizes the user's current operational intent when the target component is present; otherwise, it does not.

[0134] Figure 10 A schematic diagram of the decision logic for example, such as Figure 10 As shown, the front-end health score is first compared with the lower and upper health thresholds, resulting in three front-end health score scenarios: front-end health score is less than the lower health threshold, front-end health score is greater than the upper health threshold, and front-end health score is between the lower and upper health thresholds. For each front-end health score scenario, it can be further divided into two categories: user intent is recognized and user intent is not recognized. Therefore, in summary, there are a total of six different scenarios.

[0135] It's worth noting that if resource allocation strategies are determined solely based on front-end health, the autonomous resource scheduler cannot distinguish between "target components that are about to be used by users" and "components that can be safely released." This can lead to repeated fluctuations, such as newly dormant components being accessed by users immediately afterward. Therefore, user intent prediction, or user behavior perception, can be combined to jointly determine resource allocation strategies. Figure 10 In the first scenario, where the front-end health is less than or equal to a preset lower health threshold, and a target component exists, the front-end health is poor, and the user wants to enable additional target components. Therefore, it's necessary to control some components to hibernate, allowing these hibernating components to release the resources required by the target components. Specifically, the resources released by the hibernating components should be no less than 48.8MB. These released resources are then allocated to the target components, which are loaded sequentially. If multiple target components exist, the resources released by the hibernating components must be no less than the total resources of the target components. Then, the target components are loaded sequentially according to their urgency, from highest to lowest.

[0136] For example, the components that need to be dormant can be determined based on their corresponding revenue-cost ratio. Figure 11 For example, a list of candidate components, such as Figure 11 As shown, multiple candidate hibernation components are identified, and the corresponding benefits, costs, and ratios for each component are determined. Benefit refers to the amount of memory released after the component hibernates (which can be determined through a resource archive or real-time monitoring data of the component). Cost consists of two parts: one is the relative overhead cost of the component's hibernation / wake-up operation, which can be determined through the resource archive and is typically between 0 and 1. The other part is the user experience cost, which can be dynamically determined based on the component's current state. For example, if the component is in the visible window and the user has recently interacted with it (e.g., within 10 seconds), the user experience cost is determined to be the highest value, i.e., user experience cost = 1; if the component is in the visible window but there has been no interaction for more than 10 seconds, the user experience cost is determined to be 0.5; if the component is not in the visible window, the user experience cost is determined to be 0.1. The weight for determining the relative overhead cost of the component's hibernation / wake-up operation is α, and the weight for determining the user experience cost is β. The final cost value of the component is obtained by weighted summation. α and β can be determined based on the actual situation, α + β = 1. The ratio refers to the benefit-cost ratio, which is the ratio between benefit and cost. Candidate components with ratios exceeding a threshold, or the candidate component with the highest ratio, are identified as components that need to be dormant. The ratio threshold can be 100. Figure 11 As shown, the ratio of component A is 600, the ratio of component B is 20, and the ratio of component C is 20. Therefore, component A can be identified as a component that can be safely released, which is the component that needs to hibernate. Components B and C do not hibernate.

[0137] S903. If the front-end health is less than or equal to the preset lower health threshold and there is no target component, the resource allocation strategy is determined as follows: control some components to hibernate in order to release the resources corresponding to some components.

[0138] Combination Figure 10 In the second scenario, where the front-end health is less than or equal to the preset lower health threshold but no target component exists, the front-end health is poor. However, since the user does not want to enable any additional target component, some components can be put into hibernation in advance to release some resources and improve the front-end health, thereby preventing the front-end application from malfunctioning due to poor front-end health.

[0139] S904. If the front-end health is greater than or equal to the preset health upper limit threshold, and there is a target component, the resource allocation strategy is determined as follows: the target component is activated according to the target urgency, and the corresponding target resources are allocated to the target component; the dormant component is awakened.

[0140] Combination Figure 10 In the third scenario, where the front-end health is greater than or equal to the preset health threshold and a target component exists, the front-end health is good. The required target resources can be directly allocated to the target component, loading it sequentially. If multiple target components exist, they are loaded in descending order of their urgency. Simultaneously, dormant components can be activated. When the front-end health is good, target components can be activated in advance upon detection to improve their responsiveness in actual use.

[0141] S905. If the front-end health is greater than or equal to the preset health upper limit threshold, and there is no target component, then the resource allocation strategy is determined to be: maintain the status quo or wake up the dormant component.

[0142] Combination Figure 10 In the fourth case, when the front-end health is greater than or equal to the preset upper limit threshold but there is no target component, the front-end health is good and the current front-end operation can continue, or the dormant component can be started.

[0143] S906. If the front-end health is greater than the preset lower health threshold and less than the preset upper health threshold, and a target component exists, then the resource allocation strategy is determined as follows: the target component is activated according to its target urgency, and the corresponding target resources are allocated to the target component.

[0144] Combination Figure 10 In the fifth scenario, where the front-end health is between the preset lower and lower health thresholds, and a target component exists, the front-end health is generally good, typically possessing sufficient resources to support the target component's startup. Therefore, the necessary target resources can be directly allocated to the target component, loading it sequentially. If multiple target components exist, they are loaded in descending order of their urgency. To maintain stable front-end application operation, it is unnecessary to wake up dormant components in this situation.

[0145] S907. If the front-end health is greater than the preset lower health threshold and less than the preset upper health threshold, and there is a target component, then the resource allocation strategy is determined to be: maintain the status quo.

[0146] Combination Figure 10In the sixth case, where the front-end health is greater than or less than the preset lower health threshold and there is no target component, the front-end health is good. However, in order to maintain the stable operation of the front-end application, it is not necessary to wake up the dormant component in this case, and the status quo can be maintained.

[0147] Based on the method provided in this example, resource allocation strategies are offered in various scenarios according to the actual front-end health and the target resource requirements of the target components. This ensures that the resource allocation strategy adopted is consistent with the actual situation of the front-end, thereby improving the matching between the resource allocation strategy and the actual situation.

[0148] S206. Execute the resource allocation strategy to allocate front-end resources.

[0149] Based on the scenario example, the executor in the autonomous resource scheduler can execute the corresponding content in the resource allocation strategy determined above, including controlling component hibernation, waking up hibernating components, and allocating resources to target components, so as to achieve the smooth operation of target components.

[0150] Based on the method provided in this example, the resource allocation strategy determined by the front-end health and resource requirement package can be executed in a timely manner according to the resource pressure of the front-end and the resource needs of users. This can improve the timeliness of resource allocation, ensure that the front-end application has sufficient resources at runtime, and thus improve the performance of the front-end application.

[0151] Optional, Figure 12 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 8 ,like Figure 12 As shown, S205 includes:

[0152] S1201. Based on the front-end health and the urgency of the target, adjust the resource balance weight coefficient of the preset revenue-cost model to obtain the target resource balance weight coefficient.

[0153] Resource balancing weight coefficients, illustrated with scenario examples. The dynamic adjustment formula is:

[0154]

[0155] in, This is the baseline weighting coefficient, which can be 0.5. This is the FHS response sensitivity coefficient, which can be set to 1. The urgency response sensitivity coefficient can be set to 0.8; the urgency mean is the urgency-weighted mean of all current active intent predictions. The urgency response threshold can be set to 0.7; the value of β is constrained within the interval [βmin, βmax], where βmin can be 0.2, βmax can be 1, and β takes the boundary value when it exceeds the interval boundary. This dynamic adjustment can achieve a balance between performance assurance and functional availability. When a continuous decline in front-end health is detected, the autonomous resource scheduler needs to increase the resource balancing weight coefficient. To obtain the target resource balance weight coefficient, the autonomous resource scheduler tends to release more resources; conversely, when the target urgency is high, meaning the user intends to continuously output a high urgency signal, the autonomous resource scheduler needs to reduce the resource balance weight coefficient. To obtain the target resource balance weight coefficient, it tends to retain key interactive components.

[0156] S1202. Input the front-end health and target urgency into the preset revenue-cost model. Based on the target resource balance weight coefficient of the revenue-cost model, balance the front-end health and the target urgency of activating the target component to obtain the resource allocation strategy.

[0157] Based on scenario examples, when the target resource balance weight coefficient is close to βmax, it indicates that the target resource balance weight coefficient is increased due to a decrease in front-end health. The resulting resource allocation strategy can be: identify all components except the target component as components that can be safely released (i.e., components that need to be dormant) to release as many resources as possible and improve front-end health. When the target resource balance weight coefficient is close to βmin, it indicates that the target resource balance weight coefficient is decreased due to a continuous high urgency signal from user intent. The resulting resource allocation strategy can be: identify key interactive components, maintain the operation of key interactive components, and enable the target component involved in the user intent to ensure the component's functional viability. Optionally... Figure 13 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 9 ,like Figure 13 As shown, the process of controlling some components to enter sleep mode includes:

[0158] S1301. Identify the components to be hibernated.

[0159] Based on the scenario example, component A, which was determined above, is identified as the component to be put into hibernation.

[0160] S1302. Obtain the internal state data of the component to be hibernated and the root node of the component to be hibernated.

[0161] Combined with scenario examples, Figure 14 This is a schematic diagram illustrating the process of component sleep and component wake-up. Figure 15 For example, a visual snapshot generation and recovery timeline diagram is shown. Figure 14 and Figure 15 As shown, when making a hibernation decision for a component to be hibernated, specifically for component A, the corresponding programming method for "capturing a snapshot / screenshot" (such as `capture Snapshot`) of component A is called to determine the serialization state of component A, thereby obtaining the complete internal state data of component A. The root node corresponding to the component to be hibernated is the root node of the Document Object Model (DOM).

[0162] S1303. Based on the internal state data of the component to be hibernated, generate a serializable object corresponding to the component to be hibernated.

[0163] By combining scenario examples, the internal state data of the component, including props, state, form data, scroll position, etc., can be generated into a serializable object in JavaScript Object Notation (JSON) format.

[0164] S1304. Based on the root node corresponding to the component to be hibernated, generate a visual snapshot of the component to be hibernated.

[0165] With a scenario example, a visual snapshot of the DOM root node can be generated using a preset screenshot tool or the browser's built-in DOM screenshot function. The preset screenshot tool can be an open-source JavaScript library whose core function is to render a specified HTML element (such as an entire webpage or form) as a Canvas on the browser side, which can then be exported as an image. The browser's built-in DOM screenshot function can perform rasterization rendering of the DOM subtree through the Capture Application Programming Interface (Capture API) to obtain a visual snapshot of the DOM root node. The Autonomous Resource Scheduler sends a request to the screenshot tool to generate the visual snapshot. The screenshot tool generates the snapshot and converts it into a string in a preset format, such as a Uniform Resource Locator (URL), which is a Data URL string. This visual snapshot is a low-resolution bitmap snapshot; for example, the image can be scaled to 1 / 4 of its original size and compressed using a preset image format.

[0166] S1305. Remove the root node from the corresponding parent node, insert a placeholder component in the original position of the component to be hibernated, and store the serializable object and visual snapshot of the component to be hibernated to the preset hibernation pool to complete the hibernation of the component to be hibernated.

[0167] Using a scenario example, the DOM node of this component is removed from its parent node, and a very lightweight placeholder component is inserted in the original position of this component on the page. Simultaneously, the serializable object and visual snapshot obtained above are stored as a record in the component sleep pool, and a component-specific identifier can be added to this record. For example, a custom data attribute (such as data-sleeping-id) can be added to the placeholder, with its value set as a unique identifier for component A.

[0168] Based on the method provided in this example, the hibernation component retains its visual existence through visual snapshots and placeholders, and ensures the lossless nature of component hibernation and resumption through state serialization.

[0169] Optional, Figure 16 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 10 ,like Figure 16 As shown, the process of waking up a dormant component includes:

[0170] S1601. Extract the serializable object and visual snapshot corresponding to the hibernation component from the preset hibernation pool.

[0171] Combined with scenario examples, such as Figure 14 As shown, when making a wake-up decision for a component, the corresponding serializable object and visual snapshot are retrieved from the component hibernation pool based on the hibernation component identifier.

[0172] S1602. Update the placeholder component corresponding to the hibernation component to the visual snapshot corresponding to the hibernation component.

[0173] Based on the scenario example, the image of the placeholder component is a visual snapshot of the hibernation component retrieved from the hibernation pool, so as to quickly restore the visual appearance of the hibernation component, achieve "instant" visual restoration, and avoid blank screens.

[0174] S1603. Load the code package corresponding to the hibernation component to create a new instance of the hibernation component. Inject the serializable object corresponding to the hibernation component into the new instance of the hibernation component to restore the internal state of the hibernation component. The new instance includes the new root node corresponding to the hibernation component.

[0175] With a scenario example, the code package corresponding to the dormant component can be dynamically loaded using the `import()` directive to create a new instance of the dormant component. Calling the `restore From Snapshot(snapshot)` directive of the new instance injects the internal state data of the dormant component, included in the serializable object, into the new instance, thus restoring the component's internal state.

[0176] S1604. Replace the placeholder node at the visual snapshot with the new root node corresponding to the hibernation component to complete the wake-up of the hibernation component.

[0177] Using a scenario example, the newly generated DOM node replaces the image placeholder node, achieving a seamless switch and fully restoring the user's state.

[0178] Based on the method provided in this example, UI flickering is avoided by using a component sleep pool and asynchronous state recovery after wake-up. By combining state serialization and visual snapshots, the continuity and smoothness of user experience are significantly improved, while ensuring a seamless transition between resource reclamation and recovery.

[0179] Optional, Figure 17 A flowchart illustrating the front-end resource allocation method provided in this application embodiment. Figure 10 First, such as Figure 17 As shown, it also includes:

[0180] S1701, Detect the number of times the state of the component changes within a preset time period.

[0181] Based on the scenario example, the preset time period can be determined according to the actual situation, such as 1 hour. State switching refers to a component being woken up from a dormant state or going from an active running state to a dormant state. The number of times each component is woken up and put to sleep within 1 hour is detected to determine the number of state switching times of the component.

[0182] S1702. If the number of state transitions of a component within a preset time period exceeds a preset threshold, then the hibernation operation of the component shall be stopped.

[0183] Based on the scenario example, the preset number of times can be determined according to the actual situation, such as 10 times. If the component switches states more than 10 times within 1 hour, it means that the component is both the target component that the user wants to enable and a component with high cost-benefit ratio when the front-end health is low. In other words, the component is a component that can be safely released and will be put into hibernation first. Therefore, in this case, the user's intention should be taken into account, and the component should be kept running.

[0184] Based on the method provided in this example, if the component that needs to be put to sleep is the target component, it is not necessary to release the resources occupied by the target component. Instead, other components with low urgency can be released, which can avoid the situation where the target component is immediately woken up after being put to sleep, and can reduce unnecessary operations on the component.

[0185] The following is a specific example for illustration:

[0186] For example, consider a long-running emergency monitoring dashboard that needs to operate continuously for several days, displaying a real-time alarm list, topology map, multiple data trend charts, and event timelines. After 48 hours of continuous operation, memory usage slowly increases due to data accumulation and the growing number of DOM nodes. If a sustained upward trend in memory is detected (e.g., FHS gradually decreasing from 0.8 to 0.4 over several hours), preventative hibernation is triggered. Components with higher cost-benefit ratios are hibernated sequentially to release accumulated memory. For instance, panels such as the "Historical Event Timeline" and "Recovered Fault Details" that users are not currently viewing are hibernated sequentially. When maintenance personnel click on an alarm to view details, the scheduler recognizes the intention and wakes up the corresponding details panel in advance, using snapshots for instant visual recovery. This ensures stable memory usage for the dashboard application during long-term continuous operation, preventing browser crashes caused by continuous memory growth. Historical information that maintenance personnel need to view can be restored instantly, without affecting emergency response efficiency.

[0187] Without the method described in this example, such large-screen applications typically crash or freeze due to memory overflow after running continuously for 24 to 48 hours, requiring manual refresh and recovery by maintenance personnel (e.g., 2 to 3 times per day on average). Each refresh necessitates reloading all data, with a recovery cycle of approximately 3 to 5 minutes. Using the method described in this example, such large-screen applications can run continuously for more than 7 days without manual intervention. Furthermore, the component's sleep / wake-up mechanism reduces historical data recovery time to milliseconds. Since resource scheduling is completed at the component level, applications that originally required high memory configurations can run normally on low-end terminal devices with limited memory.

[0188] Based on the method provided in this embodiment, by collecting time-series data of target performance indicators, trend prediction of the target performance indicators is achieved to obtain the predicted performance values ​​of the target performance indicators. The front-end health can be obtained based on the predicted performance values ​​of the target performance indicators, allowing for early detection of front-end resource pressure. Furthermore, based on user interaction event stream data, corresponding resource requirement packages are determined to understand user resource needs in advance. By implementing the resource allocation strategy determined based on the front-end health and resource requirement packages, and by promptly allocating resources according to the front-end resource pressure and user resource needs, the timeliness of resource allocation can be improved, ensuring that the front-end application has sufficient resources during runtime, thereby improving the performance of the front-end application.

[0189] Figure 18 This is a schematic diagram of the structure of the front-end resource allocation device provided in the embodiments of this application, as shown below. Figure 18 As shown, it includes:

[0190] The acquisition module 181 is used to acquire performance index data and user interaction event stream data during front-end runtime. The performance index data includes time-series data of at least one target performance index within a preset time window.

[0191] The processing module 182 is used to perform trend prediction on the target performance indicator based on the preset time series prediction model and the time series data of the target performance indicator within a preset time window, so as to determine the performance prediction value corresponding to the target performance indicator.

[0192] The processing module is also used to determine the front-end health based on the performance prediction value corresponding to the target performance index;

[0193] The processing module 182 is also used to generate corresponding resource requirement packages based on user interaction event stream data;

[0194] The processing module 182 is also used to determine the resource allocation strategy based on the front-end health status and resource requirement package;

[0195] The processing module 182 is also used to execute resource allocation strategies to allocate front-end resources.

[0196] For a description of the features of the front-end resource allocation device provided in this embodiment, please refer to the relevant description of the front-end resource allocation method embodiment, which will not be repeated here.

[0197] Figure 19 A schematic diagram of the structure of the electronic device provided in this application. Figure 19As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0198] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to execute the aforementioned front-end resource allocation method embodiment.

[0199] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0200] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0201] The memory may include random access memory (RAM) and non-volatile memory (NVM), such as at least one disk storage device.

[0202] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0203] 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 front-end resource allocation method embodiments when running.

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

[0205] 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 front-end resource allocation method embodiments.

[0206] 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 front-end resource allocation method embodiments.

[0207] It should be noted that the division of units is merely a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0208] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0209] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0210] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to related technologies, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0211] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0212] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0213] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation.

[0214] The foregoing has provided a detailed description of a front-end resource allocation method and electronic device 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 method for allocating front-end resources, characterized in that, include: Collect performance metrics data and user interaction event stream data during front-end runtime, wherein the performance metrics data includes time-series data of at least one target performance metric within a preset time window; Based on a preset time-series prediction model and time-series data of the target performance index within a preset time window, trend prediction is performed on the target performance index to determine the performance prediction value corresponding to the target performance index. The front-end health is determined based on the predicted performance values ​​corresponding to the target performance indicators; User intent is identified based on the user interaction event stream data to determine the target component corresponding to the user intent; target resource consumption data corresponding to the target component is determined; corresponding user behavior data is determined based on the user interaction event stream data; the intensity of the user intent is quantified based on the user behavior data and a preset quantification formula to obtain the corresponding target intensity value; the target urgency of activating the target component is determined based on the target intensity value; the target resource consumption data and the target urgency are integrated to generate a resource requirement package. Based on the front-end health status and resource requirement package, a resource allocation strategy is determined; wherein, the resource allocation strategy includes determining whether to put some components into hibernation to release resources based on the front-end health status, and determining whether to start the corresponding target component based on the target urgency; the resource allocation strategy is executed to allocate front-end resources.

2. The method according to claim 1, characterized in that, The step of performing trend prediction on the target performance indicator based on a preset time-series prediction model and time-series data of the target performance indicator within a preset time window, to determine the predicted performance value corresponding to the target performance indicator, includes: Determine the first weight of the performance data corresponding to the target performance index; Based on the first weight corresponding to the performance data and the prediction formula corresponding to the time series prediction model, the target performance index is trend-predicted to obtain the performance prediction value corresponding to the target performance index.

3. The method according to claim 1, characterized in that, The step of determining the front-end health based on the performance prediction value corresponding to the target performance indicator includes: Based on the predicted performance value corresponding to the target performance indicator, determine the performance health of the target performance indicator. Determine the second weight corresponding to the target performance index; The performance health scores corresponding to the target performance index are weighted and summed according to the second weight corresponding to the target performance index to obtain the corresponding front-end health score.

4. The method according to claim 1, characterized in that, The step of determining the resource allocation strategy based on the front-end health status and resource requirement package includes: The target resources required by the target component are determined based on the target resource consumption data in the resource requirement package. If the front-end health is less than or equal to a preset lower health threshold and a target component exists, then the resource allocation strategy is determined as follows: control some components to hibernate according to the target resource to release the resources corresponding to the some components; start the target component according to the target urgency, and allocate the released resources to the target component, wherein the resources corresponding to the some components are not less than the target resource; If the front-end health is less than or equal to a preset lower health threshold and there is no target component, then the resource allocation strategy is determined to be: control some components to hibernate in order to release the resources corresponding to the some components; If the front-end health is greater than or equal to the preset health upper limit threshold, and a target component exists, then the resource allocation strategy is determined as follows: activate the target component according to the target urgency, allocate the corresponding target resources to the target component, and wake up the dormant component; If the front-end health is greater than or equal to the preset health upper limit threshold, and there is no target component, then the resource allocation strategy is determined to be: maintain the status quo or wake up the dormant component. If the front-end health is greater than the preset lower health threshold and less than the preset upper health threshold, and a target component exists, then the resource allocation strategy is determined to be: to activate the target component according to the target urgency and allocate the corresponding target resources to the target component; If the front-end health status is greater than the preset lower health threshold and less than the preset upper health threshold, and a target component exists, then the resource allocation strategy is determined to be: maintain the status quo.

5. The method according to claim 1, characterized in that, The step of determining the resource allocation strategy based on the front-end health status and resource requirement package includes: Based on the front-end health and the target urgency, the resource balance weight coefficient of the preset revenue-cost model is adjusted to obtain the target resource balance weight coefficient. The front-end health and the target urgency are input into a preset revenue-cost model. Based on the target resource balance weight coefficient of the revenue-cost model, the front-end health and the target urgency of activating the target component are balanced to obtain the resource allocation strategy.

6. The method according to claim 4, characterized in that, The process of controlling certain components to enter sleep mode includes: Identify the components to be hibernated; Obtain the internal state data of the component to be hibernated and the root node of the component to be hibernated; Based on the internal state data of the component to be hibernated, a serializable object corresponding to the component to be hibernated is generated; Based on the root node corresponding to the component to be hibernated, generate a visual snapshot of the component to be hibernated; Remove the root node from its corresponding parent node, insert a placeholder component at the original position of the component to be hibernated, and store the serializable object and visual snapshot corresponding to the component to be hibernated into a preset hibernation pool to complete the hibernation of the component to be hibernated.

7. The method according to claim 4, characterized in that, The process of waking up a dormant component includes: Extract the serializable object and visual snapshot corresponding to the hibernation component from the preset hibernation pool; Update the placeholder component corresponding to the hibernation component to the visual snapshot corresponding to the hibernation component; Load the code package corresponding to the hibernation component to create a new instance of the hibernation component, and inject the serializable object corresponding to the hibernation component into the new instance of the hibernation component to restore the internal state of the hibernation component, wherein the new instance includes a new root node corresponding to the hibernation component; The placeholder node at the visual snapshot is replaced with the new root node corresponding to the hibernation component to complete the wake-up of the hibernation component.

8. The method according to claim 1, characterized in that, Also includes: The number of times the detection component switches states within a preset time period; If the number of state transitions of the component within a preset time period exceeds a preset threshold, the sleep operation of the component will be stopped.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the front-end resource allocation method as described in any one of claims 1 to 8 when executing the computer program.

Images