View multiplexing component development method for realizing local rendering on guLiteOs platform

Abstract

The invention provides a view multiplexing component development method for realizing local rendering on a guLiteOS platform, and aims to optimize resource utilization and improve system response speed through dynamic loading, event-driven local updating and a view multiplexing technology. The method comprises the following steps of: firstly, dynamically loading a core operation component according to user interaction and a system state, marking a non-core component as a'to-be-loaded 'state, and delaying loading until a specific demand is triggered; and secondly, through an event-driven mechanism, user operation is captured, an influence area is calculated, and only an influenced interface part is locally rendered, so that resource waste caused by global rendering is avoided. And finally, through a view multiplexing mechanism, storing a component state after first rendering, and dynamically adjusting a caching and multiplexing strategy according to user operation frequency and importance. According to the method, repeated rendering can be reduced, memory use is optimized, and the overall performance of the system and the user experience are improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method for developing a view reuse component for realizing local rendering on a guLiteOs platform. Background Art

[0002] With the widespread use of mobile devices and embedded platforms, applications have gradually increased their demands for user interaction experience, especially in resource-limited environments. How to save resources while ensuring system fluency has become a key challenge. Traditional global rendering mechanisms usually lead to resource waste and performance bottlenecks, especially when users only operate on part of the interface, global rendering appears inefficient. In addition, frequently operated interfaces need to respond quickly to avoid unnecessary rendering delays, which puts higher requirements on system resource management and optimization of dynamic rendering.

[0003] At present, although some technologies based on lazy loading and dynamic loading have optimized resource allocation to a certain extent, they still have limitations when dealing with complex interactive operations and multi-scenario adaptation, and cannot achieve accurate management of resources. At the same time, although view reuse technology can avoid repeated rendering, how to more intelligently combine user operation behavior and event-driven mechanism to achieve efficient component reuse is still a technical problem that needs to be solved. Therefore, in response to these problems, it is urgent to propose an efficient and intelligent local rendering and view reuse method to improve system performance and resource utilization.

[0004] The present invention provides a method for developing a view reuse component for local rendering on a guLiteOS platform, aiming to solve the problems of resource waste, response delay, etc. in the prior art through dynamic loading, event-driven local update mechanism and view reuse technology, thereby improving system performance and user experience. Summary of the invention

[0005] The present invention provides a method for developing a view reuse component for realizing local rendering on a guLiteOs platform, which solves the above technical problems.

[0006] The present invention provides a method for developing a view reuse component for implementing local rendering on a guLiteOs platform, comprising:

[0007] Step S1: Dynamically load and lazy load components related to core operations based on user interaction and system status;

[0008] Step S2: controlling the scope of interface update according to the event-driven local update mechanism;

[0009] Step S3: Comprehensively control interface updates, resource allocation, and operation responses through the view reuse mechanism.

[0010] Specifically, step S1 includes the following sub-steps:

[0011] Step S11: only necessary components related to core operations are loaded at startup, and non-core components are marked as "pending loading" and their loading is postponed until user interaction or specific demand triggers;

[0012] Step S12: Capturing the user's current operation position in real time by monitoring the user's interaction events;

[0013] Step S13: Based on the user's interaction position, the relative distance to the component, the weight of the component and the current resource status, the priority of each component to be loaded is calculated to determine the loading order of the components;

[0014] Step S14: Select components to load in descending order according to priority.

[0015] Specifically, step 2 includes the following sub-steps:

[0016] Step S21: improving the accuracy of event capture by analyzing the user's interactive operation parameters;

[0017] Step S22: Calculate the impact radius of the event according to the captured operation information;

[0018] Step S23: determining the impact area based on the event impact radius calculated in step S22, and performing local rendering according to the components in the area;

[0019] Step S24: Adjust rendering priority and resource allocation through a dynamic feedback mechanism and scene adaptation strategy.

[0020] Specifically, the interactive operation parameters in step S21 include: operation intensity, operation frequency, operation duration, application scenario and combined operation.

[0021] Specifically, the affected area in step S23 is circular or elliptical.

[0022] Specifically, step S24 includes the following sub-steps:

[0023] Step S241: when the user continues to operate or a new operation event occurs, the range of the local rendering is adjusted according to the calculated affected area;

[0024] Step S242: timely calculate the affected area and trigger local update according to the change of external data;

[0025] Step S243: adjusting the event capture and rendering strategy according to the current usage scenario (such as reading, gaming, video playback, etc.);

[0026] Step S244: Analyze the user's operation trajectory and historical operation behavior, predict the user's subsequent operation area, and pre-render the relevant area in advance.

[0027] Specifically, the view reuse mechanism includes the following sub-steps:

[0028] S31: When rendering for the first time, save the state, layout and related data of the component, and extract the relevant information from the cache for reuse when the component or area needs to be rendered again later;

[0029] S32: Dynamically adjust component reuse strategy according to user operation frequency;

[0030] S33: By linking with the event-driven local rendering mechanism, it is determined whether the component needs to be reused based on the user operation intensity, frequency and duration;

[0031] S34: predicting a possible operation area based on the user's historical behavior, and pre-rendering the area in advance;

[0032] S35: Automatically adjust the cache based on the usage frequency and importance of the components to retain key components.

[0033] The present invention provides a method for developing a view reuse component for implementing local rendering on a guLiteOS platform, which has the following beneficial effects:

[0034] 1. Improve system response speed: Through dynamic loading and lazy loading mechanisms, components are loaded according to user interaction and system status, core operation components are loaded first, and the loading of non-core components is postponed, which significantly reduces resource consumption and loading time at startup, and improves the system startup speed and the smoothness of user interaction experience.

[0035] 2. Resource utilization optimization: Through the event-driven local update mechanism, the scope of interface updates is accurately controlled, and only local rendering is performed on the areas affected by user operations, avoiding the waste of global rendering resources. This mechanism optimizes the use of system memory and processor resources, and is particularly suitable for devices with limited resources.

[0036] 3. Reduce repeated calculations: Adopt a view reuse mechanism to save the status and layout of components during the first rendering. When the same area needs to be rendered later, it is directly read from the cache to avoid repeated rendering, reduce the burden on memory and processors, and improve rendering efficiency, especially in frequently updated operation interfaces.

[0037] 4. Intelligent scene adaptation: Through dynamic feedback mechanism and scene adaptation strategy, it can adjust event capture and rendering strategies in real time according to different application scenarios (such as reading, games, video playback, etc.) to ensure the smoothness and efficiency of the system in various scenarios.

[0038] 5. Advance prediction and pre-rendering: By analyzing the user's operation trajectory and historical behavior, the system can predict the user's subsequent operation area and pre-render in advance, further reducing the delay during user operation and improving the interface's instant responsiveness.

[0039] 6. Intelligent cache management: Automatically adjust the cache according to the frequency and importance of component use, prioritize the data of key components, effectively release memory resources, avoid unnecessary occupation, and improve the system's resource utilization and overall performance.

[0040] This method combines multiple optimization strategies to not only improve the rendering efficiency and response speed of the system, but also effectively optimizes the use of memory and processor, greatly improving the user's operating experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0042] Figure 1 This is a schematic diagram of the structure of Embodiment 1 of the present invention;

[0043] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the present invention;

[0044] Figure 3 This is a schematic diagram of the structure of Embodiment 3 of the present invention;

[0045] Figure 4 This is a structural diagram of embodiment 4 of the present invention. DETAILED DESCRIPTION

[0046] In order to facilitate the understanding of the present invention, the present invention will be described more fully below with reference to the relevant drawings. Preferred embodiments of the present invention are provided in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present invention more thorough and comprehensive.

[0047] Embodiment 1

[0048] See also Figure 1 The embodiment of the present invention provides a method for developing a view reuse component for implementing local rendering on a guLiteOs platform, comprising:

[0049] Step S1: Dynamically load and lazy load components related to core operations based on user interaction and system status;

[0050] Step S2: controlling the scope of interface update according to the event-driven local update mechanism;

[0051] Step S3: Comprehensively control interface updates, resource allocation, and operation responses through the view reuse mechanism.

[0052] This embodiment implements a view reuse component development method for local rendering on the guLiteOS platform.

[0053] Through dynamic loading and lazy loading mechanisms, core components can be loaded first based on user interaction and system status, reducing unnecessary initial resource consumption and waiting time, and improving the overall response speed of the system.

[0054] The event-driven local update mechanism can accurately control the scope of interface updates and only render the affected parts, avoiding resource waste caused by global rendering. This can more effectively allocate processor and memory resources, especially in complex interfaces or resource-limited environments, improving resource utilization efficiency.

[0055] Through the view reuse mechanism, the component state is cached after the first rendering, and the subsequent rendering directly reuses the data from the cache without recalculation. This method not only reduces the burden on memory and processors, but also significantly improves the processing speed of frequently operated interfaces.

[0056] This method combines the comprehensive control of view reuse, resource allocation and operation response to achieve more intelligent resource management. The system automatically adjusts rendering and resource allocation according to different operation scenarios and data changes, improving the flexibility and responsiveness of the system.

[0057] Embodiment 2

[0058] See also Figure 2 In this embodiment, a method for developing a view reuse component for local rendering on the guLiteOs platform is provided, step S1 - dynamic loading and lazy loading mechanism, which aims to improve the efficiency of system resource utilization and reduce unnecessary memory usage, ensure the smoothness of user operations and system response speed, and step S1 includes the following sub-steps.

[0059] Step S11: Initialize loading

[0060] At startup, only the necessary components related to core operations are loaded. Non-core components are not loaded immediately during the initial stage, but are marked as "pending" to postpone their loading until triggered by user interaction or specific needs. In this way, the system prioritizes the rapid response of key functions during the startup process, reducing the initial memory usage and processor load.

[0061] Step S12: User interaction monitoring

[0062] By monitoring user interaction events, such as clicks, slides, scrolls, etc., the user's current operation position (xu, yu) is captured in real time. When the user's interaction in a specific area is detected, the system calculates the components that may need to be loaded based on the user's operation trajectory.

[0063] Step S13: Priority calculation

[0064] Based on the user's interaction position, relative distance to the component, component weight, and current resource status, the priority of each component to be loaded is calculated. The priority formula is as follows:

[0065]

[0066] L(t): represents the loading priority of component i at time t.

[0067] P u (x,y,t): represents the interaction priority of the user at coordinate (x,y) at time t. It reflects the frequency and importance of the user's operation. The user's operation at different locations will have different effects on the priority.

[0068] (x u ,y u ) and (x i ,y i ): is the user's current operation position, (xi,yi) is the coordinate position of the component i to be loaded. The distance between the two is used to calculate the relative importance of the component and the user's operation position.

[0069] is a Gaussian decay function used to adjust the component position (x i ,y i ) and the user operation position (x u ,y u ) to adjust the priority of the component. The farther the distance, the lower the priority. The parameter σ controls the range of attenuation. The larger the value, the larger the impact range.

[0070] M(t): represents the resource status or available resource situation of the system at the current time t. It is used to balance resource allocation and ensure that high-priority components are loaded first when resources are limited.

[0071] By dynamically calculating the priority of each component through a formula, it is possible to more intelligently decide which components should be lazy loaded. When a user operates in a specific area, components with lower priority will be loaded later, thereby reducing unnecessary resource consumption. Prioritize the loading of key components to ensure fast response of operations and avoid loading irrelevant components in the initial stage. This improves the efficiency of subsequent lazy loading and only loads minor components when necessary. The overall loading time is shortened, the initial resource usage is reduced, and the operation fluency is improved.

[0072] The resource status parameter M(t) introduced in the formula can be used to monitor resource status and dynamically adjust loading decisions. When resources are tight, low-priority components will be delayed in loading, and high-priority components will be given priority in processing resources. This dynamic adjustment mechanism reduces unnecessary resource waste during the loading process.

[0073] By monitoring resource usage, the loading order is optimized to ensure that key components are processed first when resources are tight, reducing delays and improving overall performance.

[0074] Based on the dynamic calculation mechanism of priority, view reuse becomes more intelligent. When components in high-priority areas are frequently used, these components are reused first to reduce repeated rendering and loading. Low-priority components will be reused later or processed when resources are sufficient. The efficiency of the view reuse mechanism is greatly improved, meaningless rendering operations are reduced, and memory utilization is optimized. Through intelligent reuse, unnecessary performance consumption is avoided, making operations smoother.

[0075] The priority data calculated by the formula can analyze the user's interaction trajectory and predict behavior, determine the user's next operation area, and load or render the corresponding components in advance. The accuracy of pre-rendering has been greatly improved because high-frequency areas have higher priority, so they can respond in advance. The improved accuracy of pre-rendering makes the user experience smoother. The ability to load and render key components before the user operates reduces user waiting time and provides more immediate feedback.

[0076] When processing external data changes, the priority data provided by the formula ensures that only key areas are updated without the need for global rendering. Changes caused by external data will affect specific areas, and the formula will determine the priority areas and components based on the interaction frequency and resource status. Through local update optimization, the overhead of global rendering is avoided, and only the affected parts are updated, ensuring the real-time operation and the accuracy of the update, improving the overall processing efficiency.

[0077] Step S14: Select components to load in descending order according to priority. Load components involved in user operations step by step according to the current resource status and calculated priority to ensure maximum utilization of resources when resources are limited. Dynamic adjustment of loading order ensures priority response of key components while reducing memory usage of non-key components.

[0078] This embodiment uses dynamic loading and lazy loading mechanisms to minimize resource usage at startup and flexibly loads required components according to needs during user operations. Through priority calculation and resource management, efficient memory management can be achieved to ensure smooth user experience and optimized system performance.

[0079] Embodiment 3

[0080] See also Figure 3 , this embodiment provides step 2: Through the event-driven local update mechanism, the system can dynamically identify the key points of user interaction or data change, accurately control the scope of interface update, and thus avoid the cost of global rendering. This mechanism optimizes resource utilization, prioritizes the affected interface area, improves the overall interface response efficiency, and reduces unnecessary system resource consumption. This step includes the following sub-steps:

[0081] S21: Event Capture

[0082] By real-time monitoring of user interaction operations (such as clicking, sliding, scrolling, etc.), the time t and location (x u ,y u ) to determine the user's operation position. At the same time, the accuracy of event capture is further optimized by combining the strength of the user's operation (such as light touch, heavy press), the duration of the operation, and the frequency of the operation.

[0083] Operation force detection: Determine the specific interaction type based on the strength of the user's operation, such as light touch and heavy press. Operations of different strengths will trigger different levels of events. Light touch may trigger a smaller rendering area, while heavy press will cause a wider area to be updated.

[0084] Operation frequency monitoring: By analyzing the user's operation frequency, the user's interactive activity in a specific area can be dynamically determined. High-frequency operation areas will be marked as high-priority areas, and components will be loaded or updated in these areas first to optimize the interface response speed.

[0085] Analysis of operation duration: For operations such as dragging or long pressing, determine the scope of influence based on the duration of the operation. Operations with longer durations usually mean that the user pays more attention to the area, thus triggering more extensive interface updates.

[0086] Scenario Adaptive Adjustment: Dynamically adjust the event capture strategy according to the current application scenario. For example, in the reading scenario, the capture accuracy of the scrolling operation will be enhanced to ensure smooth page scrolling, while in the game scenario, the response speed of click and slide operations will be given priority.

[0087] Recognition of combined operations: Not only can it capture a single operation type, but it can also recognize continuous or combined operation behaviors, such as quick double-clicks or multi-finger operations. The rendering area is adjusted according to the complexity of the combined operation to meet higher interaction requirements.

[0088] S22: Impact area calculation

[0089] Based on the captured operation information, combined with the user's interaction intensity (such as light touch, heavy press) and operation frequency, the impact radius R of the event is dynamically calculated. u (t). This radius depends on the type of event, the intensity of the operation, and the frequency of the operation to ensure that the affected interface area is accurately delineated. For events with greater intensity, the affected area is larger, while for lighter operations, the affected area is relatively smaller. Through dynamic adjustment, it can ensure that system resources are only used for rendering necessary areas, optimizing resource utilization efficiency. The affected area calculation formula is:

[0090] Among them, R u (t): The impact radius of the event at time t, which determines the specific impact area.

[0091] λ: controls the proportional coefficient of the impact radius and adjusts the sensitivity of the overall impact range, suitable for different application scenarios and system performance.

[0092] L u : Operation force coefficient, which indicates the intensity of user interaction (such as light touch or heavy press). The greater the force, the wider the impact range.

[0093] F u : Operation frequency coefficient, which indicates the frequency of user operations in a specific area. The higher the frequency, the larger the affected area, and the components in this area are rendered first.

[0094] T u : Operation duration. The longer the duration, the more attention users pay to the area, and the wider the impact range. A logarithmic function is used to balance the expansion speed.

[0095] x u ,y u and x e ,y e :User operation point (x u ,u) and the event location (x e ,ye ) coordinates and calculate the distance between the event and the user action. The greater the distance, the smaller the impact.

[0096] d max : The maximum allowed interaction distance limits the maximum range of the impact radius to prevent the event from affecting too many irrelevant areas.

[0097] The necessity of calculating the impact radius is to ensure that the system only renders and updates the local area affected by the event, rather than the entire interface. The reasons for calculating the radius include the following key aspects:

[0098] (1) Optimizing resource utilization

[0099] By calculating the impact radius Ru(t) of an event, it is possible to determine that only those areas affected by the event are updated. Stronger events (such as a hard press or a slide) may affect a wider area, while smaller events such as a tap may affect a smaller area. By determining the size of the affected area, only the parts that need to be updated are rendered, reducing resource waste and avoiding unnecessary global rendering.

[0100] (2) Improve response speed

[0101] Partial rendering significantly improves system response speed. By calculating the impact radius, it can quickly determine which components need to be updated first, thereby reducing waiting time, ensuring that users' operations receive immediate feedback, and improving interaction fluency.

[0102] (3) Determine rendering priority

[0103] Different events have different impacts on the interface, and the calculation radius can dynamically adjust the rendering priority of components. Events with a larger impact range are usually related to high-priority areas (such as interfaces with frequent user operations), while events with a smaller impact range may be associated with secondary areas. By calculating the radius, rendering resources can be reasonably allocated to ensure that key components are updated first.

[0104] (4) Accurate rendering

[0105] The calculation of the impact radius can also be dynamically adjusted according to the intensity of the event, the frequency of operation, etc., to ensure that resources are used in the actual affected area. By accurately defining the affected area, unnecessary resource consumption is avoided and the user experience is improved.

[0106] S23: Partial rendering triggered

[0107] Based on the event impact radius Ru(t) calculated in step S22, this radius is defined as a circular or elliptical impact area, and local rendering is performed based on the components within the area. To ensure efficient and accurate rendering, the rendering priority is determined based on the following factors:

[0108] 1. The distance between the component and the event location: The distance between the component in the impact area and the event center directly affects its priority. Components closer to the event location will be given a higher priority and rendered first. Components farther away will have a lower priority and can be rendered later.

[0109] 2. Component weight: Set the weight value according to the importance of the component. Components with higher weights have higher rendering priority, ensuring fast response of key components. For example, components that users frequently interact with or components that are critical to the interface response will receive higher weights.

[0110] 3. Current resource usage: If current resources are tight, the rendering of low-priority components may be postponed, or the amount of resources allocated to them may be reduced to ensure that components in high-priority areas are updated in a timely manner and avoid excessive consumption of system resources.

[0111] Setting the affected area to a circle or ellipse can bring the following unexpected technical effects, which are mainly reflected in the optimization of rendering efficiency, resource management, and interactive experience:

[0112] Circular impact area: Due to the symmetry and simple geometric properties of the circle, it is possible to quickly determine which components are within the circular range when calculating the components affected by the event. In this way, calculations can be greatly simplified, overhead can be reduced, and the triggering speed of local rendering can be accelerated, thereby significantly improving the responsiveness of user operations. The simple geometric structure of the circular area makes it possible to quickly determine the components inside and outside the boundary, reducing complex calculations and significantly speeding up the response time of rendering.

[0113] Elliptical influence area: The long and short axes of the ellipse can adapt to different types of operations more flexibly. For example, the influence range of linear operations such as sliding and dragging is often long strips rather than evenly spread. The elliptical area can more accurately reflect the directionality and intensity of these operations. The long axis can extend along the direction of the operation, while the short axis can limit the expansion in the vertical direction, thereby achieving more refined rendering control. The elliptical area can dynamically adjust its shape to adapt to different user operations (such as sliding, dragging, etc.). It not only accurately captures the scope of operation, but also reduces the update burden of irrelevant areas and optimizes resource allocation.

[0114] By using circles or ellipses as the affected areas, resource usage can be precisely controlled. Compared to more general area divisions such as rectangles, circles and ellipses can avoid affecting irrelevant edge areas and only update the part of the interface that the user actually operates, thereby reducing unnecessary rendering and resource waste. Moreover, circular and elliptical areas conform to human visual habits, especially during interface interaction, users can more easily understand and perceive changes in these areas. For example, when users click or slide, circular or elliptical feedback areas are more consistent with natural interaction behaviors, providing more intuitive operation feedback. This area setting that conforms to user visual habits makes the association between interface changes and user operations more intuitive and consistent, improving the user's overall interactive experience.

[0115] S24: Dynamic feedback and scene adaptation

[0116] This step ensures that the system can always adapt to the user's interaction needs by monitoring the user's subsequent operations and changes in external data in real time, and dynamically adjusts the rendering strategy according to different application scenarios. It includes the following sub-steps:

[0117] S241: Dynamic feedback of user operations: When the user continues to operate or new operation events occur, these events are captured in real time, and the scope of local rendering is continuously adjusted dynamically according to the affected area calculated in the previous step. According to information such as operation frequency and strength, the rendering priority is adjusted in real time to ensure that high-frequency interaction areas are updated first. By continuously capturing user operations and dynamically updating the affected area, a high degree of synchronization with user operations is maintained, interface lag is reduced, and the immediacy and fluency of interaction are improved.

[0118] S242: Local updates driven by external data: In addition to user operations, the affected areas can be calculated in a timely manner and local updates can be triggered based on changes in external data (such as network data, sensor input, etc.). For changes in external data, the optimal rendering strategy will be selected based on the degree of impact and data priority to ensure that high-priority data is updated in a timely manner. By combining changes in external data with local rendering, the resource overhead of global rendering can be significantly reduced, only the necessary parts are updated, resource utilization is optimized, and the efficiency of processing external data is significantly improved.

[0119] S243 Scenario Adaptive Adjustment: Adjust event capture and rendering strategies according to the current usage scenario (such as reading, gaming, video playback, etc.). For example, in the reading scenario, the capture and response of scrolling operations can be enhanced, while in the gaming scenario, click and slide operations are prioritized. Adjustment of event capture and rendering priorities in different scenarios can effectively improve the user experience. Scene adaptive adjustment ensures the flexible response of the system in different usage scenarios, improves the user's interactive experience and the smoothness of the interface. By adjusting the rendering strategy, resource waste is reduced and performance in different application scenarios is optimized.

[0120] S244: Intelligent prediction of operation trajectory: By analyzing the user's operation trajectory and historical operation behavior, the user's possible subsequent operation area is predicted, and the relevant area is pre-rendered in advance. This intelligent prediction mechanism can significantly reduce the waiting time of the user during the interaction process. Through the prediction and pre-rendering of the operation trajectory, the user's operation area receives a faster response, avoiding possible delays and improving the overall user interaction fluency.

[0121] Embodiment 4

[0122] See also Figure 4 This embodiment provides step S3: combining user operation behavior, pre-rendering strategy and dynamic cache adjustment to implement an efficient view reuse mechanism, thereby greatly improving the system response speed. The view reuse mechanism includes the following sub-steps:

[0123] S31. Component state caching and reuse

[0124] When a component is rendered for the first time, its rendering state, layout, and related data are cached. When the same area or component needs to be rendered again, the component state is read from the cache first instead of re-rendering to ensure that repeated calculations are reduced. By reusing components directly from the cache, repeated allocation of resources is avoided, which greatly reduces the burden on memory and processors, especially in frequently updated operation interfaces, improving rendering efficiency.

[0125] S32. Multiplexing strategy based on operating frequency

[0126] Dynamically adjust component reuse strategies based on user operation frequency. Components in high-frequency interaction areas are first retrieved from the cache to ensure that the area responds quickly. For low-frequency interaction areas, the system can delay reuse or clear the corresponding cache to optimize memory usage. Dynamically adjusting reuse priorities allows the system to maintain smooth response under high load conditions, avoids low-priority areas from occupying too much memory, and improves overall resource utilization.

[0127] S33. Linkage with event-driven local rendering

[0128] This reuse mechanism is linked with the event-driven local rendering mechanism, and determines whether components need to be reused based on the intensity, frequency, and duration of user operations. When users perform high-intensity or long-term operations, the system prioritizes reusing component states to avoid unnecessary rendering operations. Combined with the event-driven mechanism, the system can quickly predict the user's subsequent operations, reduce rendering delays by reusing components in advance, and improve the real-time responsiveness of the overall interface.

[0129] S34. Pre-rendering combined with reuse mechanism

[0130] The possible operation area is predicted based on the user's historical behavior, and the area is pre-rendered in advance. When the user enters the area, the system reuses the pre-rendered results to achieve seamless loading and display, avoiding interface freezes. This mechanism reuses pre-rendered data, and the user's operation is responded to faster, greatly improving the interactive experience, especially in complex operating environments, avoiding obvious interface delays.

[0131] S35. Intelligent resource management

[0132] When resources are tight or memory is close to saturation, the cache is automatically adjusted according to the frequency and importance of component usage, key components are retained, and cache space for low-frequency components is released to avoid memory overflow. This mechanism can run smoothly in a resource-constrained environment by intelligently regulating the cache, greatly improving the system's memory utilization, and is particularly suitable for embedded devices or mobile platforms with limited memory resources.

[0133] The view reuse mechanism in this embodiment achieves efficient component reuse through caching, frequency monitoring, pre-rendering and intelligent resource management, avoiding the common resource waste and performance bottlenecks in traditional view reuse. This mechanism combines user operation behavior prediction to achieve faster response and accurate resource allocation, bringing unexpected technical effects and improving the overall performance of the system and user experience.

[0134] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0135] The above-mentioned embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A method for developing a view reuse component for local rendering on a guLiteOs platform, characterized in that: include: Step S1: Dynamically load and lazy load components related to core operations based on user interaction and system status; Step S2: controlling the scope of interface update according to the event-driven local update mechanism; Step S3: Comprehensively control interface updates, resource allocation, and operation responses through the view reuse mechanism.

2. According to claim 1, a method for developing a view reuse component for implementing local rendering on a guLiteOs platform is characterized in that: The step S1 comprises the following sub-steps: Step S11: only necessary components related to core operations are loaded at startup, and non-core components are marked as "to be loaded" and their loading is postponed until user interaction or specific demand triggers; Step S12: Capturing the user's current operation position in real time by monitoring the user's interaction events; Step S13: Based on the user's interaction position, the relative distance to the component, the weight of the component and the current resource status, the priority of each component to be loaded is calculated to determine the loading order of the components; Step S14: Select components to load in descending order according to priority.

3. According to claim 1, a method for developing a view reuse component for implementing local rendering on a guLiteOs platform is characterized in that: The step 2 includes the following sub-steps: Step S21: improving the accuracy of event capture by analyzing the user's interactive operation parameters; Step S22: Calculate the impact radius of the event according to the captured operation information; Step S23: determining the impact area based on the event impact radius calculated in step S22, and performing local rendering according to the components in the area; Step S24: Adjust rendering priority and resource allocation through a dynamic feedback mechanism and scene adaptation strategy.

4. According to claim 3, a method for developing a view reuse component for implementing local rendering on a guLiteOs platform is characterized in that: The interactive operation parameters in step S21 include: operation intensity, operation frequency, operation duration, application scenario and combined operation.

5. According to claim 3, a method for developing a view reuse component for implementing local rendering on a guLiteOs platform is characterized in that: The affected area in step S23 is circular or elliptical.

6. According to claim 3, a method for developing a view reuse component for implementing local rendering on a guLiteOs platform is characterized in that: Step S24 includes the following sub-steps: Step S241: when the user continues to operate or a new operation event occurs, the range of the local rendering is adjusted according to the calculated affected area; Step S242: timely calculate the affected area and trigger local update according to the change of external data; Step S243: adjusting the event capture and rendering strategy according to the current usage scenario (such as reading, gaming, video playback, etc.); Step S244: Analyze the user's operation trajectory and historical operation behavior, predict the user's subsequent operation area, and pre-render the relevant area in advance.

7. The method for developing a view reuse component for implementing local rendering on the guLiteOs platform according to claim 3, characterized in that: The view reuse mechanism includes the following sub-steps S31: When rendering for the first time, save the state, layout and related data of the component, and extract the relevant information from the cache for reuse when the component or area needs to be rendered again later; S32: Dynamically adjust component reuse strategy according to user operation frequency; S33: By linking with the event-driven local rendering mechanism, it is determined whether the component needs to be reused based on the user operation intensity, frequency and duration; S34: predicting a possible operation area based on the user's historical behavior, and pre-rendering the area in advance; S35: Automatically adjust the cache based on the usage frequency and importance of the components to retain key components.

Images