Rendering task cooperative control method

Abstract

The invention provides a rendering task cooperative control method. By monitoring the updating condition of the document object model, the drawing delay state starting instruction is actively sent to the rendering process of the browser when the preset condition is met, and the corresponding rendering task process is adjusted, so that the problem of frame breakage in a high-frequency updating scene is solved. The cross-process communication interface adopts an encoding instruction message to ensure the accuracy and high efficiency of communication, and a rendering barrier is created and a drawing delay state is maintained before the next task queue is emptied, so that the browser can be prevented from executing partial drawing in an unfinished frame. The maximum duration of the drawing delay state is dynamically determined according to the remaining time of the current rendering frame, so that the task execution completeness is ensured, and unnecessary performance waste is avoided. Finally, the browser can smoothly execute the adjusted rendering task process by sending the drawing delay state relieving instruction, and the stability and smoothness of the rendering process are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of front-end rendering, and in particular to a rendering task cooperative control method. BACKGROUND

[0002] In the field of front-end rendering, modern front-end frameworks use asynchronous update strategies to optimize rendering performance, but there are two major bottlenecks in high-frequency update scenarios. On the one hand, there is a frame break phenomenon. When the interface update task spans multiple rendering frames, the browser will perform partial drawing in the unfinished frame, causing the interface to flicker. Actual measurements show that single-page updates can trigger multiple redundant drawing tasks on devices with lower performance. On the other hand, there is a scheduling blind area. The existing framework scheduler cannot perceive the state of the browser rendering pipeline, and when the execution time of macro tasks / micro tasks exceeds a certain time threshold, it will inevitably cause frame loss.

[0003] To optimize these two limitations, interface update tasks can be aligned to the browser rendering cycle, but the drawback is that the drawing timing cannot be controlled, and intermediate drawing will still be triggered when the task queue depth is large. Visual coherence can also be achieved by hiding specific elements, but this is only suitable for graphics rendering and increases memory overhead for interface updates in normal cases. In addition, the rendering thread can be blocked until the task is completed, but this can cause the main thread to freeze and delay touch response on mobile devices. In summary, these optimization methods have the problem of poor flexibility and effectiveness of scheduling during rendering. Therefore, a rendering task cooperative control method is needed to improve the flexibility and effectiveness of resource scheduling during rendering, thereby improving the rendering effect. SUMMARY

[0004] The purpose of the present application is to at least solve one of the above technical defects, in particular the technical defect of insufficient flexibility and effectiveness of resource scheduling during rendering in the prior art, thereby causing poor rendering effect.

[0005] In a first aspect, the present application provides a rendering task cooperative control method, comprising:

[0006] monitoring the document object model update, and when a preset condition is met, sending a drawing delay state start instruction to the browser rendering process through a cross-process communication interface, and adjusting the rendering task flow corresponding to the document object model update;

[0007] The cross-process communication interface is used to send encoded instruction messages to the browser rendering process through a page message communication method or an extension communication mechanism based on the browser kernel, and the instruction messages include an operation code field for identifying the operation type.

[0008] A rendering barrier is created, and the drawing delay state is maintained until the next task queue of the view layer framework is emptied.

[0009] wherein the maximum duration of the rendering delay state is dynamically determined according to the remaining time of the current rendering frame;

[0010] after the next task queue is emptied, a rendering delay state release instruction is sent to the browser rendering process to release the rendering delay state to allow the browser to execute the adjusted rendering task flow.

[0011] As an optional implementation, the method further comprises:

[0012] In the system initialization phase, a device performance fingerprint library is constructed;

[0013] wherein the device performance fingerprint library construction process comprises:

[0014] obtaining hardware environment parameters of the runtime through a browser interface;

[0015] wherein the hardware environment parameters include processor logical core number, device memory capacity information, and graphic processor renderer information;

[0016] According to each of the hardware environment parameters, the device is classified according to a preset classification condition;

[0017] wherein the preset classification condition comprises:

[0018] if the device memory capacity is not less than a preset memory and the processor logical core number is not less than a preset core number, the device is marked as a high-end device, otherwise it is marked as a low-end device;

[0019] independent document object model operation time consumption reference tables are established for high-end devices and low-end devices respectively, and in the reference tables, the same type of document object model operation has different basic time consumption reference values and device adjustment coefficients under different device classification.

[0020] As an optional implementation, the preset condition comprises one or more of the following:

[0021] the number of consecutive document object model update operations exceeds a preset number threshold, or the current document object model update operation complexity parameter exceeds a preset complexity threshold, or the expected time corresponding to the current document object model update operation exceeds a preset time threshold.

[0022] As an optional implementation, the method further comprises:

[0023] According to the three parameters of the total number of document object model nodes involved in the current document object model update operation, the total number of style attribute changes triggering browser recalculation of styles, and the hierarchical distance between the changed nodes and the root rendering layer, the complexity parameter is calculated according to the set weight proportion;

[0024] When the complexity parameter exceeds the preset complexity threshold, it is determined that the current document object model update operation is a high complexity task, and the high complexity task is split into a subtask queue.

[0025] As an optional implementation, the method further comprises:

[0026] The expected time required to perform the current document object model update operation is obtained by summing the weighted calculation results of the actual time consumption of the last frame in which the current document object model update operation is performed and the corresponding historical average time consumption, and a compensation value calculated based on the historical time consumption fluctuation range;

[0027] When the expected time exceeds the preset time threshold, or the current document object model update operation is determined to be a high complexity task, the current document object model update operation is split into a plurality of subtask queues that can be completed within a single frame time window, and each subtask in the subtask queue is sequentially entered into an asynchronous task queue for execution.

[0028] As an optional implementation, the method further comprises real-time load monitoring, specifically including:

[0029] The performance observation interface is used to monitor the execution of the browser rendering process. When a long task with execution time exceeding a set duration is captured, in subsequent continuous rendering frames, a time slicing strategy is forcibly enabled for all view layer update tasks, and all the view layer update tasks are split into subtask queues;

[0030] And / or, the memory usage is detected. When it is detected that the memory usage rate exceeds a set usage rate, it is determined that the memory pressure is too high, and a degradation response measure is automatically triggered;

[0031] The degradation response measure includes suspending unnecessary animation effects in the page and replacing complex gradient backgrounds with solid color backgrounds.

[0032] As an optional implementation, the method further comprises a progressive degradation strategy, specifically including:

[0033] The support of the current browser environment for the rendering delay state interface is determined;

[0034] If the browser environment fully supports the drawing delay state interface, then the full cooperative control mode is enabled;

[0035] If the browser environment does not support the drawing delay state interface but supports the animation callback interface, then a simulated drawing delay strategy is adopted.

[0036] If the browser environment is a traditional browser that does not support the drawing delay state interface and the animation callback interface, then the task is scheduled using a timer-based dynamic time slicing strategy.

[0037] Secondly, this application provides a rendering task collaborative control device, the device comprising:

[0038] The monitoring module is used to monitor updates to the document object model.

[0039] The processing module is used to send a drawing delay state start instruction to the browser rendering process through an inter-process communication interface when preset conditions are met, and to adjust the rendering task flow corresponding to the document object model update.

[0040] The cross-process communication interface is used to send encoded instruction messages to the browser rendering process through a page message communication method or an extended communication mechanism based on the browser kernel. The instruction message includes an opcode field for identifying the operation type.

[0041] The processing module is also used to create a rendering barrier and maintain a drawing delay state until the next task queue of the view layer frame is cleared.

[0042] The maximum duration of the drawing delay state is dynamically determined based on the remaining time of the current rendering frame.

[0043] The processing module is further configured to send a drawing delay state release instruction to the browser rendering process after the next task queue is cleared, thereby releasing the drawing delay state and allowing the browser to execute the adjusted rendering task flow.

[0044] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.

[0045] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.

[0046] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0047] Based on any of the above embodiments, this application effectively solves the problems of frame breakage and task scheduling blind spots faced by front-end frameworks in high-frequency update scenarios by constructing a complete rendering task collaborative control mechanism. By monitoring the update status of the document object model and triggering a drawing delay state when conditions are met, this method can actively control the drawing timing, preventing the browser from performing partial drawing in incomplete frames, thereby eliminating interface flickering. The design of the cross-process communication interface ensures the accuracy and efficiency of instruction transmission, while the creation of rendering barriers and dynamic duration adjustment further enhance the integrity of tasks and performance optimization. The introduction of the device performance fingerprint library enables the system to dynamically adjust the rendering strategy based on hardware environment parameters, improving its adaptability to diverse devices. The multi-condition judgment mechanism and task complexity evaluation model ensure that collaborative control is only enabled in high-load scenarios, reducing unnecessary performance overhead. Real-time load monitoring and progressive degradation strategies further enhance the robustness and compatibility of the system, enabling it to run stably under different browser environments and hardware conditions. In summary, this method, through a multi-layered, adaptive collaborative control mechanism, significantly improves the stability, smoothness, and efficiency of the rendering process, providing an effective solution for front-end rendering performance optimization in high-frequency update scenarios. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art 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.

[0049] Figure 1 A flowchart illustrating a rendering task collaborative control method provided in one embodiment of this application;

[0050] Figure 2 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0051] 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 skilled in the art without creative effort are within the scope of protection of this application.

[0052] First, let's explain the main terms that may be involved:

[0053] PaintHoldingAPI: An experimental API provided by Chromium-based browsers that allows users to actively delay page rendering while waiting for critical rendering tasks to complete.

[0054] Layout jitter: UI stuttering caused by continuous forced layout synchronization operations.

[0055] Rendering pipeline coordination: a timing coordination mechanism between the browser rendering process and the JavaScript execution thread.

[0056] Frame stability guarantee algorithm: A control model that dynamically adjusts task scheduling by predicting rendering time.

[0057] Microtask queue synchronizing mechanism: An execution strategy that synchronizes the framework-level task queue with the browser's microtask queue.

[0058] In modern front-end development, popular frameworks like Vue commonly employ asynchronous update strategies to optimize rendering performance and improve page rendering efficiency. This strategy can significantly improve application responsiveness and user experience in most cases. However, when faced with scenarios involving frequent data updates, this asynchronous update mechanism exposes two significant performance bottlenecks:

[0059] Frame fracturing: Specifically, when Document Object Model (DOM) update tasks are distributed across multiple rendering frames, the browser may perform partial drawing operations before the current frame is fully completed. This incomplete drawing causes flickering in the user interface, severely impacting the user experience. Actual testing revealed that on lower-performance devices, frequent updates to a single page can trigger more than three redundant draws, further exacerbating the performance issue.

[0060] Task scheduling blind spots: Existing front-end framework schedulers, such as Vue's nextTick mechanism, can postpone tasks to the next event loop, but they cannot accurately perceive the browser's rendering pipeline state. When the execution time of macro tasks or micro tasks exceeds 16.6 milliseconds (i.e., the time of one frame), it will inevitably cause the browser to drop frames, thus causing interface stuttering.

[0061] To address the above issues, there are some feasible implementation methods that can solve these two problems to some extent, but each solution has certain limitations:

[0062] (1) requestAnimationFrame batch processing solution: This solution attempts to reduce unnecessary drawing operations by aligning DOM update tasks with the browser's rendering cycle. However, its drawback is that it cannot precisely control the timing of drawing. When the depth of the task queue exceeds 5, intermediate drawing will still be triggered, resulting in the failure to completely solve the problem of screen flickering.

[0063] (2) Double buffering strategy: This strategy achieves visual continuity by using a hidden Canvas layer and is mainly suitable for graphics rendering scenarios. However, for regular DOM update operations, the double buffering strategy will result in a memory overhead of up to 200%, which is particularly uneconomical on resource-constrained devices.

[0064] (3) Web Locks API Synchronization Solution: This solution ensures the integrity of the drawing by blocking the rendering thread until all tasks are completed. However, this approach causes the main thread to freeze for a long time, especially on mobile devices, which can cause touch response delays of more than 300 milliseconds, seriously affecting the user's interactive experience.

[0065] In summary, the following issues in the field of front-end rendering urgently need to be addressed:

[0066] Uncontrolled rendering timing: The current browser triggers rendering operations by default during the intervals of JavaScript execution. This mechanism lacks synchronization and coordination with the update cycle of the front-end framework, making it difficult to accurately control the rendering timing, which in turn leads to instability and timing disorder in interface rendering.

[0067] Pipeline state isolation: The lack of effective coordination primitives between the rendering process and the JavaScript thread makes it impossible for developers to actively delay drawing operations, making it difficult to achieve fine-grained management of the rendering process.

[0068] Lack of scheduling prediction: There is currently no complete frame time prediction model, so there is a lack of scientific basis when dynamically adjusting task fragmentation strategy, and it is impossible to reasonably allocate tasks according to the actual rendering load, resulting in frame rate fluctuations and performance bottlenecks.

[0069] Compatibility flaws: Existing solutions rely heavily on the private APIs of specific browsers. This dependence limits the universality of the technology, makes it impossible to achieve progressive degradation on incompatible browsers, and affects the consistency of user experience.

[0070] Therefore, this application specifically implements the following improvements to solve the corresponding problems:

[0071] We construct a cross-process collaboration channel between the PaintHoldingAPI and the Vue rendering pipeline. Through this channel, we can actively control the drawing latency, ensuring that the drawing operations are closely integrated with the framework update cycle, thereby improving rendering efficiency and interface stability.

[0072] The design employs a frame stability guarantee algorithm that uses dynamic task fragmentation technology to intelligently adjust the execution order and duration of rendering tasks, effectively reducing the frame drop rate to below 5% and ensuring a smooth visual experience for users.

[0073] Develop a rendering state predictor that uses advanced prediction algorithms to achieve millisecond-level accuracy in estimating update task time, providing precise data support for task scheduling and optimizing overall rendering performance.

[0074] Establish a multi-layered degradation strategy, designing multi-layered technical compatibility solutions for browsers with different kernels, especially non-Chromium kernel browsers, to ensure a consistent and high-quality user experience in various environments.

[0075] In summary, the technical concept of this application lies in effectively solving the frame fragmentation and task scheduling blind spots faced by front-end frameworks in high-frequency update scenarios by constructing a complete rendering task collaborative control mechanism. By monitoring the document object model update status and triggering a rendering delay state when conditions are met, this method can proactively control the rendering timing, preventing the browser from performing partial rendering in incomplete frames, thereby eliminating interface flickering. The design of the cross-process communication interface ensures the accuracy and efficiency of command transmission, while the creation of rendering barriers and dynamic duration adjustment further enhance task integrity and performance optimization. The introduction of the device performance fingerprint library enables the system to dynamically adjust the rendering strategy based on hardware environment parameters, improving adaptability to diverse devices. The multi-condition judgment mechanism and task complexity evaluation model ensure that collaborative control is only activated in high-load scenarios, reducing unnecessary performance overhead. Real-time load monitoring and progressive degradation strategies further enhance the robustness and compatibility of the system, enabling it to run stably under different browser environments and hardware conditions. In summary, this method significantly improves the stability, smoothness, and efficiency of the rendering process through a multi-layered, adaptive collaborative control mechanism, providing an effective solution for optimizing front-end rendering performance in high-frequency update scenarios.

[0076] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.

[0077] Figure 1 This is a flowchart illustrating a rendering task collaborative control method provided in one embodiment of this application, as shown below. Figure 1 As shown, this application provides a method for collaborative control of rendering tasks, the method comprising:

[0078] S101. Monitor the document object model update status. When the preset conditions are met, send a drawing delay state start instruction to the browser rendering process through the cross-process communication interface, and adjust the rendering task flow corresponding to the document object model update.

[0079] The cross-process communication interface is used to send encoded instruction messages to the browser rendering process through a page message communication method or an extended communication mechanism based on the browser kernel. The instruction message includes an opcode field for identifying the operation type.

[0080] S102. Create a rendering barrier and maintain the drawing delay state until the next task queue of the view layer frame is emptied.

[0081] The maximum duration of the drawing delay state is dynamically determined based on the remaining time of the current rendering frame.

[0082] S103. After the next task queue is cleared, a drawing delay state release instruction is sent to the browser rendering process to release the drawing delay state, so as to allow the browser to execute the adjusted rendering task flow.

[0083] Specifically, in the actual application scenario corresponding to this application, a rendering pipeline collaborative control system was first established. For the API bridging layer, activation condition detection is performed first. During the Vue beforeUpdate lifecycle phase, the system injects a dedicated pipeline state probe. The main function of this probe is to monitor DOM update operations. When the system detects that the number of consecutive DOM update operations reaches or exceeds 3, it sends a PaintHolding start command to the browser process through the PostMessage mechanism to activate the paint holding state.

[0084] Next, rendering latency control is implemented. To effectively manage the rendering process, the system creates a rendering barrier. This barrier maintains the rendering latency until the nextTick task queue is cleared. The maximum wait time is calculated dynamically using the formula: (16.6 milliseconds - current frame elapsed time) * 1.5 milliseconds. This allows for flexible adjustment of the wait time based on the actual situation of the current frame, ensuring the stability of the rendering process.

[0085] The cross-process coordination protocol, i.e., the aforementioned encoded instruction messages, uses a binary status encoding mechanism defined by the system to transmit status information between different processes. Specifically, 0x01 encoding indicates a draw-ready state, 0x02 encoding indicates a task timeout warning state, and 0x04 encoding indicates a forced release of the draw state. In addition to process status information, the encoding can also be used to transmit timing information. These encodings ensure the accuracy and efficiency of cross-process communication.

[0086] This implementation also includes rewriting the view layer framework's native next task execution method and injecting its callback function task into a special microtask queue created and managed by this method;

[0087] Furthermore, hook functions are used to ensure that tasks in this special microtask queue are cleared and completed before the browser rendering process initiates the next frame drawing, thereby achieving synchronous execution of the frame-level task queue and the browser microtask queue.

[0088] Specifically, the task scheduler implements microtask queue locking. The system rewrites Vue's nextTick mechanism, injecting callback tasks into a special microtask queue. This ensures that the microtask queue is cleared before the browser performs rendering operations, guaranteeing timely task processing. Additionally, lifecycle hooking is implemented, injecting pipeline state synchronization directives into Vue's updated and beforeUnmount lifecycle phases. These directives ensure consistent update timing across components, guaranteeing orderly updates between different components and preventing timing discrepancies.

[0089] Furthermore, this implementation can also be used for microtask queue engagement of multiple nodes, injecting pipeline state synchronization and resource cleanup instructions during the update completion lifecycle phase and the component unloading lifecycle phase of the view layer framework; during the update completion lifecycle phase, the instructions are used to send a final synchronization signal to the browser rendering process to ensure the consistency of update states among multiple components; during the component unloading lifecycle phase, the instructions are used to forcibly release the rendering holding resources occupied by the current component and unregister the associated cross-process communication listeners.

[0090] The rendering task collaborative control method provided in this application effectively solves the frame breakage problem in high-frequency update scenarios by monitoring the document object model update status and proactively sending a drawing delay state start command to the browser rendering process when preset conditions are met, and adjusting the corresponding rendering task flow. The cross-process communication interface uses encoded command messages to ensure the accuracy and efficiency of communication. Creating a rendering barrier and maintaining the drawing delay state until the next task queue is cleared prevents the browser from performing partial drawing in incomplete frames, thus eliminating interface flickering. The maximum duration of the drawing delay state is dynamically determined based on the remaining time of the current rendering frame, ensuring the integrity of task execution while avoiding unnecessary performance waste. Finally, by sending a drawing delay state release command, the browser can smoothly execute the adjusted rendering task flow, significantly improving the stability and smoothness of the rendering process, especially in high-complexity task scenarios.

[0091] As an optional implementation, the method further includes:

[0092] During the system initialization phase, a device performance fingerprint database is constructed.

[0093] The process of constructing the device performance fingerprint database includes:

[0094] Obtain runtime hardware environment parameters through the browser interface;

[0095] The hardware environment parameters include the number of processor logical cores, device memory capacity information, and graphics processor renderer information.

[0096] Based on the hardware environment parameters described above, the devices are classified according to preset classification conditions;

[0097] The preset grading conditions include:

[0098] If the device's memory capacity is not less than a preset memory and the number of processor logical cores is not less than a preset number of cores, it is marked as a high-configuration device; otherwise, it is marked as a low-configuration device.

[0099] Independent reference tables for document object model operation time are established for high-end and low-end devices respectively. In the reference tables, the same type of document object model operation has different basic time benchmark values ​​and device adjustment coefficients under different device levels.

[0100] During the construction of the performance fingerprint database, the core metrics were simplified to four items, namely:

[0101] CPU core count: This is obtained through the `navigator.hardwareConcurrency` property. This metric determines the device's parallel task processing capability. When the number of CPU cores is less than or equal to 4, the system will mark it as a low-performance device and implement appropriate optimization strategies.

[0102] Memory capacity (GB): Obtained via the `navigator.deviceMemory` property in an HTTPS environment. This metric is used to identify memory-sensitive devices. When the memory capacity is less than 4GB, the system will enable memory protection policies to avoid performance issues caused by insufficient memory.

[0103] GPU rendering type: This is obtained through the `gl.getParameter(gl.RENDERER)` method in the WebGL context. This metric is used to detect the device's GPU type. If the system detects that the device is using an integrated graphics card (such as Intel HD Graphics), it will disable some high-load GPU effects to avoid performance bottlenecks.

[0104] Device tiering flag: The generation rules are based on memory capacity and the number of CPU cores. High-end devices are defined as having 4GB or more of memory and 4 or more CPU cores; low-end devices do not meet either of these conditions. The purpose of this flag is to select an appropriate benchmark for latency, allowing for different performance optimization strategies to be applied to different devices.

[0105] The document object model operation time reference table can include parameters such as node operation type, base time, and correction coefficients for different levels of devices. For example, inserting 300 nodes has a base time of 8.2ms, with a correction coefficient of 0.7-1.3 depending on device performance. Or, batch style updates have a base time of 5.1ms, with a correction coefficient of 0.9-1.5 depending on device performance.

[0106] By constructing a device performance fingerprint database during the system initialization phase, this implementation can classify devices based on hardware environment parameters and establish independent document object model operation time reference tables for different device levels. This design enables the system to dynamically adjust rendering strategies based on the actual device performance. High-performance devices can fully leverage their hardware advantages, while low-performance devices can avoid performance bottlenecks through parameter optimization. The construction of the device performance fingerprint database not only improves the accuracy of rendering task scheduling but also enhances the system's adaptability to different hardware environments, thereby achieving high-efficiency rendering performance on diverse devices.

[0107] As an optional implementation, the preset conditions include one or more of the following:

[0108] The document object model update operation occurs more than a preset number of times, or the complexity parameter of the current document object model update operation exceeds a preset complexity threshold, or the expected time corresponding to the current document object model update operation exceeds a preset time threshold.

[0109] Inject state monitoring logic into the lifecycle phase before the view layer framework is updated to achieve corresponding monitoring.

[0110] In practical application scenarios, preset conditions may also include factors such as the degree of matching between real-time system performance and document object model update operations.

[0111] This implementation method provides multiple preset conditions, including the number of consecutive update operations, complexity parameters, and expected time thresholds, enabling it to accurately identify high-load rendering tasks and trigger a collaborative control mechanism. This multi-condition judgment method avoids the limitations of single conditions, ensuring that the rendering delay state is only activated in scenarios where intervention is truly necessary. This reduces unnecessary performance overhead and guarantees timely system response. Through dynamic monitoring and condition judgment, this implementation method can achieve intelligent task scheduling in complex and ever-changing rendering scenarios, significantly improving rendering efficiency.

[0112] As an optional implementation, the method further includes:

[0113] The complexity parameter is calculated based on three parameters: the total number of document object model nodes involved in the current document object model update operation, the total number of style property changes that trigger the browser to recalculate styles, and the hierarchical distance from the changed node to the root rendering layer, according to the set weight ratio.

[0114] When the complexity parameter exceeds the preset complexity threshold, the current document object model update operation is determined to be a high-complexity task, and the high-complexity task is split into a sub-task queue.

[0115] To ensure rendering frame stability, this implementation provides a task fragmentation strategy. The system establishes an update task complexity evaluation model, which includes three core metrics: the number of DOM nodes, the number of style changes, and the layout depth. The number of DOM nodes refers to the total number of DOM nodes that change in a single update task; the number of style changes refers to the number of CSS property changes that trigger the browser to recalculate styles; and the layout depth is the hierarchical distance from the changed nodes to the root rendering layer. The complexity parameter, also known as the task weight, is calculated using the following formula: Task Weight = Number of DOM Nodes × 0.3 + Number of Style Changes × 0.2 + Layout Depth × 0.5. When the calculated task weight value exceeds 15, the system can automatically split the task into multiple sub-task queues to reduce the complexity of a single task.

[0116] By refining the calculation of task complexity parameters, this implementation method can accurately assess the complexity of rendering tasks based on multiple dimensions such as the total number of document object model nodes, the total number of style attribute changes, and hierarchical distance. When the complexity exceeds a preset threshold, the system automatically splits high-complexity tasks into sub-task queues, avoiding frame loss caused by excessively long single task execution times. This not only improves the parallelism and efficiency of task execution but also ensures the stability of the browser rendering pipeline, with particularly significant effects when handling large-scale document object model updates.

[0117] As an optional implementation, the method further includes:

[0118] The expected time required to perform the current document object model update operation is obtained by summing the weighted calculation results of the actual time spent in the most recent frame that has performed the current document object model update operation and the corresponding historical average time spent, as well as the compensation value calculated based on the historical time fluctuation range.

[0119] When the expected time exceeds the preset time threshold, or when the current document object model update operation is determined to be a high-complexity task, the current document object model update operation is split into several sub-task queues that can be completed within a single frame time window, and each sub-task in the sub-task queue is sequentially entered into the asynchronous task queue for execution.

[0120] To ensure rendering frame stability, this implementation provides a dynamic frame allocation method. The system predicts the execution time of the current task based on a regression equation of historical frame latency. The prediction model considers two main factors: the actual latency of the most recent frame (80% weight) and the historical average latency (20% weight). In addition, the system introduces a safety buffer compensation value, which is calculated based on the fluctuation range of historical latency (2.5 times the standard deviation in statistics). For example, if the historical latency fluctuation is within ±3 milliseconds, the compensation value is calculated as 2.5 × 3 = 7.5 milliseconds. The formula for calculating the expected time is: Expected Time = (Recent Frame Latency Time × 80%) + (Historical Average Latency Time × 20%) + Safety Buffer Compensation Value.

[0121] It should be noted that this dynamic frame allocation method can be used for any matching process of rendering frames and document object model update operations, and is not limited to the splitting of highly complex or long-running tasks.

[0122] Based on a weighted calculation of historical rendering time data and real-time frame execution time, this implementation method can accurately predict the expected time required for the current rendering task and automatically split the subtask queue when the time exceeds a threshold. By introducing a compensation value for historical rendering time fluctuations, the system further enhances the accuracy and robustness of the prediction. Subtasks are sequentially entered into the asynchronous task queue and executed in order, ensuring that tasks are completed within a single frame time window. This effectively avoids UI stuttering and frame loss issues caused by excessively long task execution times, thus improving the user experience.

[0123] As an optional implementation, the method further includes real-time load monitoring, specifically including:

[0124] The performance monitoring interface is used to monitor the execution of the browser rendering process. When a long task with an execution time exceeding the set duration is captured, the time slicing strategy is forcibly enabled for all view layer update tasks in the subsequent consecutive rendering frames, and all view layer update tasks are split into sub-task queues.

[0125] And / or, detect memory usage. When the memory usage rate exceeds the set usage rate ratio, it is determined that the memory pressure is too high, and a degradation response measure is automatically triggered.

[0126] The degradation response measures include pausing unnecessary animation effects on the page and replacing complex gradient backgrounds with solid color backgrounds.

[0127] Specifically, the real-time load monitoring mechanism continuously monitors the current running load to ensure that all tasks can be executed efficiently and stably. This monitoring mechanism allows for the timely detection and resolution of potential performance bottlenecks, guaranteeing smooth application operation.

[0128] Main thread blocking event handling: When a main thread blocking event occurs, the system will immediately initiate corresponding countermeasures. Main thread blocking can cause page lag, slow response times, and other problems, severely impacting user experience. Therefore, timely identification and handling of main thread blocking events is crucial.

[0129] Monitoring method: The PerformanceObserver API is used to listen to the main thread, with particular focus on long tasks that take longer than 50 milliseconds. Once a long task is detected, the system will immediately record the relevant information and trigger appropriate response measures.

[0130] Response measures: Upon detecting a main thread blocking event, the system will forcibly enable the time-slicing mechanism for the next 3 frames. Time slicing breaks down long tasks into multiple short tasks, distributing them across multiple frames for execution, thereby avoiding stuttering caused by excessive processing time in a single frame.

[0131] The memory pressure warning mechanism allows the system to monitor memory usage in real time. If excessive memory pressure is detected, an immediate warning will be issued. Excessive memory pressure can cause applications to run slowly or even crash; therefore, timely warnings and intervention are crucial.

[0132] Judgment criteria: Memory usage is determined by the ratio of `performance.memory.usedJSHeapSize` to `performance.memory.jsHeapSizeLimit`. Specifically, when memory usage exceeds 60% (i.e., `performance.memory.usedJSHeapSize > 0.6 * performance.memory.jsHeapSizeLimit`), the system will trigger a memory pressure warning.

[0133] Response Measures: Upon triggering a memory pressure warning, the system will take a series of measures to alleviate memory pressure. These include pausing unnecessary animation effects to reduce memory consumption; and replacing CSS gradient backgrounds with solid color backgrounds to simplify the rendering process and reduce memory usage. These measures effectively reduce memory pressure and ensure stable application operation.

[0134] This implementation method can dynamically respond to changes in system performance through real-time load monitoring. When a long task or excessively high memory usage is detected, the system automatically enables a time-slicing strategy or triggers degradation response measures, such as pausing unnecessary animations and simplifying page elements. This real-time adaptive adjustment mechanism ensures stable system operation under high load scenarios, avoids performance degradation caused by resource contention, and maintains a basic user experience through intelligent degradation.

[0135] As an optional implementation, the method further includes a gradual degradation strategy, specifically including:

[0136] Determine the current browser environment's support for the drawing delay state interface;

[0137] If the browser environment fully supports the drawing delay state interface, then the full cooperative control mode is enabled;

[0138] If the browser environment does not support the drawing delay state interface but supports the animation callback interface, then a simulated drawing delay strategy is adopted.

[0139] If the browser environment is a traditional browser that does not support the drawing delay state interface and the animation callback interface, then the task is scheduled using a timer-based dynamic time slicing strategy.

[0140] Browsers that support the PaintHolding API can adopt the complete collaborative mode provided in any implementation of this application. For browsers that only support requestPostAnimationFrame, a simulated drawing delay can be used. For traditional browsers that do not support any interface, tasks can be scheduled through a timer-based dynamic time slicing strategy.

[0141] For example, the simulated drawing delay strategy may specifically include: setting a flag indicating that the current period is in the simulated delay period in the callback function of the animation callback interface; during this period, intercepting and temporarily storing all direct calls to browser drawing-related instructions; estimating the remaining completion time of the view layer update task through a simplified prediction model; and after the estimated time is reached, clearing the flag and executing all temporarily stored drawing instructions at once.

[0142] For example, dynamic time slicing can refer to the description of the relevant embodiments of this application, or it can monitor the style calculation time and layout calculation time of the browser front-end rendering process to determine the segmentation granularity of the current front-end rendering task, divide the front-end rendering task into multiple sub-tasks according to the segmentation granularity, and schedule the execution of each sub-task according to the preset priority conditions.

[0143] Furthermore, for a gradual degradation strategy, a circuit breaker mechanism can be designed. This mechanism automatically triggers corresponding protective measures when certain key indicators exceed predetermined thresholds during system operation, ensuring system stability and security. In specific implementations, different circuit breaker strategies need to be designed based on different application scenarios and requirements.

[0144] For example, in applications such as image processing or video analysis, situations may arise where the prediction error exceeds a predetermined threshold for multiple consecutive frames. If measures are not taken promptly in such cases, system performance will degrade, and erroneous results may even occur. Therefore, a circuit breaker mechanism needs to be designed. When the prediction error exceeds 25% for three consecutive frames, the system automatically switches to a conservative scheduling mode to reduce system risk.

[0145] Furthermore, in multithreaded programming, situations may arise where the main thread times out due to blocking. This can lead to slower system response and even stuttering. Therefore, a circuit breaker mechanism is needed to forcibly release drawing control when the main thread times out for 300ms, ensuring system smoothness and responsiveness.

[0146] This implementation employs a progressive degradation strategy to dynamically adjust the collaborative control mode based on browser support for the rendering delay state interface. For browsers with full functionality, the full collaborative control mode is enabled to maximize performance advantages; for partially supported browsers, a simulated rendering delay strategy is used; and for traditional browsers, tasks are scheduled using a timer-based dynamic time slicing strategy. This layered design ensures compatibility and consistency across different browser environments, expands the applicable scenarios, and enhances the method's practicality and universality.

[0147] In summary, the key points of this application are: the binding mechanism between the PaintHoldingAPI activation conditions and the Vue lifecycle, specifically specifying how to intelligently activate the PaintHoldingAPI at different lifecycle stages of the Vue framework to optimize rendering performance; the dynamic fragment weight calculation formula in the frame stability algorithm, detailing how to dynamically calculate the weight of each task fragment to ensure frame rate stability; the microtask queue engagement implementation method, specifically introducing the efficient engagement mechanism of the microtask queue to ensure the continuity and efficiency of task processing; and the device capability fingerprint database construction and query system, detailing how to build a comprehensive device capability fingerprint database and providing an efficient query mechanism to support accurate prediction of rendering state.

[0148] This application specifically implements the following improvements: A method for integrating the PaintHolding API into the framework scheduler, including a cross-process communication protocol: It details how to integrate the PaintHolding API into the framework scheduler and covers the specific implementation of the cross-process communication protocol; Task fragmentation strategy and dynamic frame allocation mechanism for the frame stability guarantee algorithm: It elaborates on the task fragmentation strategy in the frame stability guarantee algorithm and the working principle of the dynamic frame allocation mechanism; Construction of the performance fingerprint library and implementation of real-time load monitoring for the rendering state predictor: It details the method for constructing the performance fingerprint library of the rendering state predictor and the specific implementation of real-time load monitoring; Capability grading matrix and circuit breaker rules in the progressive degradation strategy: It specifically explains the design of the capability grading matrix in the progressive degradation strategy and the specific application of the circuit breaker rules. For details, please refer to the relevant implementation methods.

[0149] In practical applications, the method provided in this application has been tested and has achieved the following technical effects:

[0150] Significantly improved rendering performance: By reducing the number of intermediate draws to 0, layout jitter during the update process of complex components is effectively reduced, and rendering efficiency is greatly improved.

[0151] Breakthrough in frame stability: By introducing dynamic fragmentation technology, the frame drop rate can be controlled to below 2% in high frame rate scenarios of 120fps, which is better than traditional technical solutions.

[0152] Significantly optimized resource consumption: Compared to the traditional double buffering scheme, memory usage is reduced, and peak CPU utilization is effectively controlled, thus optimizing overall resource consumption.

[0153] Seamless compatibility guarantee: Through degradation strategies, performance fluctuations are kept within 15% in non-Chromium browser environments, providing a seamless user experience.

[0154] Non-intrusive development process: Implemented through Vue plugins, developers do not need to modify existing business code when applying the application, which greatly simplifies the development process and lowers the technical threshold.

[0155] This application also provides a rendering task collaborative control device, the device comprising:

[0156] The monitoring module is used to monitor updates to the document object model.

[0157] The processing module is used to send a drawing delay state start instruction to the browser rendering process through an inter-process communication interface when preset conditions are met, and to adjust the rendering task flow corresponding to the document object model update.

[0158] The cross-process communication interface is used to send encoded instruction messages to the browser rendering process through a page message communication method or an extended communication mechanism based on the browser kernel. The instruction message includes an opcode field for identifying the operation type.

[0159] The processing module is also used to create a rendering barrier and maintain a drawing delay state until the next task queue of the view layer frame is cleared.

[0160] The maximum duration of the drawing delay state is dynamically determined based on the remaining time of the current rendering frame.

[0161] The processing module is further configured to send a drawing delay state release instruction to the browser rendering process after the next task queue is cleared, thereby releasing the drawing delay state and allowing the browser to execute the adjusted rendering task flow.

[0162] The rendering task collaborative control method provided in this application effectively solves the frame breakage problem in high-frequency update scenarios by monitoring the document object model update status and proactively sending a drawing delay state start command to the browser rendering process when preset conditions are met, and adjusting the corresponding rendering task flow. The cross-process communication interface uses encoded command messages to ensure the accuracy and efficiency of communication. Creating a rendering barrier and maintaining the drawing delay state until the next task queue is cleared prevents the browser from performing partial drawing in incomplete frames, thus eliminating interface flickering. The maximum duration of the drawing delay state is dynamically determined based on the remaining time of the current rendering frame, ensuring the integrity of task execution while avoiding unnecessary performance waste. Finally, by sending a drawing delay state release command, the browser can smoothly execute the adjusted rendering task flow, significantly improving the stability and smoothness of the rendering process, especially in high-complexity task scenarios.

[0163] As an optional implementation, the processing module is further configured to:

[0164] During the system initialization phase, a device performance fingerprint database is constructed.

[0165] The process of constructing the device performance fingerprint database includes:

[0166] Obtain runtime hardware environment parameters through the browser interface;

[0167] The hardware environment parameters include the number of processor logical cores, device memory capacity information, and graphics processor renderer information.

[0168] Based on the hardware environment parameters described above, the devices are classified according to preset classification conditions;

[0169] The preset grading conditions include:

[0170] If the device's memory capacity is not less than a preset memory and the number of processor logical cores is not less than a preset number of cores, it is marked as a high-configuration device; otherwise, it is marked as a low-configuration device.

[0171] Independent reference tables for document object model operation time are established for high-end and low-end devices respectively. In the reference tables, the same type of document object model operation has different basic time benchmark values ​​and device adjustment coefficients under different device levels.

[0172] By constructing a device performance fingerprint database during the system initialization phase, this implementation can classify devices based on hardware environment parameters and establish independent document object model operation time reference tables for different device levels. This design enables the system to dynamically adjust rendering strategies based on the actual device performance. High-performance devices can fully leverage their hardware advantages, while low-performance devices can avoid performance bottlenecks through parameter optimization. The construction of the device performance fingerprint database not only improves the accuracy of rendering task scheduling but also enhances the system's adaptability to different hardware environments, thereby achieving high-efficiency rendering performance on diverse devices.

[0173] As an optional implementation, the preset conditions include one or more of the following:

[0174] The document object model update operation occurs more than a preset number of times, or the complexity parameter of the current document object model update operation exceeds a preset complexity threshold, or the expected time corresponding to the current document object model update operation exceeds a preset time threshold.

[0175] This implementation method provides multiple preset conditions, including the number of consecutive update operations, complexity parameters, and expected time thresholds, enabling it to accurately identify high-load rendering tasks and trigger a collaborative control mechanism. This multi-condition judgment method avoids the limitations of single conditions, ensuring that the rendering delay state is only activated in scenarios where intervention is truly necessary. This reduces unnecessary performance overhead and guarantees timely system response. Through dynamic monitoring and condition judgment, this implementation method can achieve intelligent task scheduling in complex and ever-changing rendering scenarios, significantly improving rendering efficiency.

[0176] As an optional implementation, the processing module is further configured to:

[0177] The complexity parameter is calculated based on three parameters: the total number of document object model nodes involved in the current document object model update operation, the total number of style property changes that trigger the browser to recalculate styles, and the hierarchical distance from the changed node to the root rendering layer, according to the set weight ratio.

[0178] When the complexity parameter exceeds the preset complexity threshold, the current document object model update operation is determined to be a high-complexity task, and the high-complexity task is split into a sub-task queue.

[0179] By refining the calculation of task complexity parameters, this implementation method can accurately assess the complexity of rendering tasks based on multiple dimensions such as the total number of document object model nodes, the total number of style attribute changes, and hierarchical distance. When the complexity exceeds a preset threshold, the system automatically splits high-complexity tasks into sub-task queues, avoiding frame loss caused by excessively long single task execution times. This not only improves the parallelism and efficiency of task execution but also ensures the stability of the browser rendering pipeline, with particularly significant effects when handling large-scale document object model updates.

[0180] As an optional implementation, the processing module is further configured to:

[0181] The expected time required to perform the current document object model update operation is obtained by summing the weighted calculation results of the actual time spent in the most recent frame that has performed the current document object model update operation and the corresponding historical average time spent, as well as the compensation value calculated based on the historical time fluctuation range.

[0182] When the expected time exceeds the preset time threshold, or when the current document object model update operation is determined to be a high-complexity task, the current document object model update operation is split into several sub-task queues that can be completed within a single frame time window, and each sub-task in the sub-task queue is sequentially entered into the asynchronous task queue for execution.

[0183] Based on a weighted calculation of historical rendering time data and real-time frame execution time, this implementation method can accurately predict the expected time required for the current rendering task and automatically split the subtask queue when the time exceeds a threshold. By introducing a compensation value for historical rendering time fluctuations, the system further enhances the accuracy and robustness of the prediction. Subtasks are sequentially entered into the asynchronous task queue and executed in order, ensuring that tasks are completed within a single frame time window. This effectively avoids UI stuttering and frame loss issues caused by excessively long task execution times, thus improving the user experience.

[0184] As an optional implementation, the processing module is also used for real-time load monitoring, specifically including:

[0185] The performance monitoring interface is used to monitor the execution of the browser rendering process. When a long task with an execution time exceeding the set duration is captured, the time slicing strategy is forcibly enabled for all view layer update tasks in the subsequent consecutive rendering frames, and all view layer update tasks are split into sub-task queues.

[0186] And / or, detect memory usage. When the memory usage rate exceeds the set usage rate ratio, it is determined that the memory pressure is too high, and a degradation response measure is automatically triggered.

[0187] The degradation response measures include pausing unnecessary animation effects on the page and replacing complex gradient backgrounds with solid color backgrounds.

[0188] This implementation method can dynamically respond to changes in system performance through real-time load monitoring. When a long task or excessively high memory usage is detected, the system automatically enables a time-slicing strategy or triggers degradation response measures, such as pausing unnecessary animations and simplifying page elements. This real-time adaptive adjustment mechanism ensures stable system operation under high load scenarios, avoids performance degradation caused by resource contention, and maintains a basic user experience through intelligent degradation.

[0189] As an optional implementation, the processing module is further configured to execute a gradual degradation strategy, specifically including:

[0190] Determine the current browser environment's support for the drawing delay state interface;

[0191] If the browser environment fully supports the drawing delay state interface, then the full cooperative control mode is enabled;

[0192] If the browser environment does not support the drawing delay state interface but supports the animation callback interface, then a simulated drawing delay strategy is adopted.

[0193] If the browser environment is a traditional browser that does not support the drawing delay state interface and the animation callback interface, then the task is scheduled using a timer-based dynamic time slicing strategy.

[0194] This implementation employs a progressive degradation strategy to dynamically adjust the collaborative control mode based on browser support for the rendering delay state interface. For browsers with full functionality, the full collaborative control mode is enabled to maximize performance advantages; for partially supported browsers, a simulated rendering delay strategy is used; and for traditional browsers, tasks are scheduled using a timer-based dynamic time slicing strategy. This layered design ensures compatibility and consistency across different browser environments, expands the applicable scenarios, and enhances the method's practicality and universality.

[0195] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0196] Indicatively, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 2 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0197] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

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

[0199] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

[0200] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0201] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0202] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for cooperative control of rendering tasks, characterized in that The method comprises: monitoring the document object model update, when the preset condition is met, sending a drawing delay state start instruction to the browser rendering process through a cross-process communication interface, and adjusting the rendering task flow corresponding to the document object model update; The cross-process communication interface is used to send an encoded instruction message to the browser rendering process through a page message communication method or an extension communication mechanism based on a browser kernel, and the instruction message includes an operation code field for identifying an operation type; A rendering barrier is created, and the drawing delay state is maintained until the next task queue of the view layer framework is emptied; The maximum duration of the drawing delay state is dynamically determined according to the remaining time of the current rendering frame; After the next task queue is emptied, a drawing delay state release instruction is sent to the browser rendering process to release the drawing delay state to allow the browser to execute the adjusted rendering task flow.

2. The method of claim 1, wherein, The method further comprises: In the system initialization phase, a device performance fingerprint library is constructed; The device performance fingerprint library construction process comprises: Obtaining hardware environment parameters of the runtime through a browser interface; The hardware environment parameters include processor logical core number, device memory capacity information, and graphics processor renderer information; According to the preset grading conditions, the device is graded according to the hardware environment parameters; The preset grading conditions include: If the device memory capacity is not less than a preset memory and the processor logical core number is not less than a preset core number, the device is marked as a high-end device, otherwise it is marked as a low-end device; Independent document object model operation time consumption reference tables are established for high-end and low-end devices respectively, and in the reference table, the same type of document object model operation has different basic time consumption reference values and device adjustment coefficients under different device grades.

3. The method of claim 1, wherein, The preset conditions include one or more of the following: The number of consecutive document object model update operations exceeds a preset number threshold, or the current document object model update operation complexity parameter exceeds a preset complexity threshold, or the expected time corresponding to the current document object model update operation exceeds a preset time threshold.

4. The method of claim 3, wherein, The method further comprises: According to the total number of document object model nodes involved in the current document object model update operation, the total number of style attribute changes that trigger browser recalculation of styles, and the hierarchical distance between the changed nodes and the root rendering layer, the complexity parameter is calculated according to the set weight proportion; When the complexity parameter exceeds the preset complexity threshold, it is determined that the current document object model update operation is a high complexity task, and the high complexity task is split into a sub-task queue.

5. The method of claim 4, wherein, The method further comprises: The expected time required to execute the current document object model update operation is obtained by summing the weighted calculation results of the actual time consumption of the last frame in which the current document object model update operation is executed and the corresponding historical average time consumption, and the compensation value calculated based on the historical time consumption fluctuation range. When the expected time exceeds a preset time threshold, or the current document object model update operation is determined as a high complexity task, the current document object model update operation is split into a plurality of subtask queues which can be completed within a single frame time window, and each subtask in the subtask queue is sequentially entered into an asynchronous task queue for execution.

6. The method of claim 4, wherein, The method further comprises real-time load monitoring, specifically comprising: The performance observation interface is used to monitor the execution of the browser rendering process, and when a long task with execution time exceeding a set duration is captured, a time slicing strategy is forcibly enabled for all view layer update tasks in subsequent continuous rendering frames, and all the view layer update tasks are split into subtask queues; and / or, memory usage is detected, and when the memory usage rate exceeds a set usage rate, it is determined that the memory pressure is too high, and a degradation response measure is automatically triggered; The degradation response measure comprises suspending unnecessary animation effects in the page and replacing complex gradient backgrounds with solid color backgrounds.

7. The method according to any one of claims 1 to 6, characterized in that, The method further comprises a progressive degradation strategy, specifically comprising: determining the support of the current browser environment for the rendering delay state interface; if the browser environment fully supports the rendering delay state interface, a complete cooperative control mode is enabled; if the browser environment does not support the rendering delay state interface but supports the animation callback interface, a simulated rendering delay strategy is adopted; if the browser environment is a traditional browser and does not support the rendering delay state interface and the animation callback interface, a dynamic time slicing strategy based on a timer is used to schedule tasks.

8. A rendering task cooperative control apparatus characterized by comprising: The device comprises: a monitoring module for monitoring document object model updates; a processing module for sending a rendering delay state start instruction to the browser rendering process through a cross-process communication interface and adjusting the rendering task flow corresponding to the document object model update when a preset condition is met; The cross-process communication interface is used to send encoded instruction messages to the browser rendering process through a page message communication method or an extension communication mechanism based on a browser kernel, and the instruction messages include an operation code field for identifying the operation type. The processing module is also used to create a rendering barrier and maintain the rendering delay state until the next task queue of the view layer framework is emptied. The maximum duration of the rendering delay state is dynamically determined according to the remaining time of the current rendering frame. The processing module is also used to send a rendering delay state release instruction to the browser rendering process after the next task queue is emptied, release the rendering delay state, and allow the browser to execute the adjusted rendering task flow.

9. A computer device, comprising: One or more processors and a memory are included, and the memory stores computer readable instructions which are executed by the one or more processors to perform the steps of the method of any one of claims 1-7.

10. A storage medium, characterized by The storage medium has stored therein computer readable instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of the method of any one of claims 1-7.

Images