A method for developing view reuse components for local rendering on the guLiteOs platform

Abstract

The present invention provides a method for developing a view reuse component that implements local rendering on the guLiteOS platform, aiming to optimize resource utilization and improve system response speed through dynamic loading, event-driven local updates, and view reuse technology. The method comprises the following steps: first, dynamically loading core operating components based on user interaction and system status, and non-core components are marked as "to be loaded" and delayed loading until specific needs are triggered. Secondly, through an event-driven mechanism, user operations are captured and the affected area is calculated, and only the affected interface part is locally rendered, thereby avoiding the waste of resources caused by global rendering. Finally, through the view reuse mechanism, the component state is saved after the first rendering, and the cache and reuse strategies are dynamically adjusted according to the frequency and importance of user operations. This method can reduce repeated rendering, optimize memory usage, and improve the overall performance of the system and user experience.

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 implementing local rendering on a guLiteOs platform. Background Art

[0002] With the widespread adoption of mobile devices and embedded platforms, applications are increasingly demanding a better user experience. Especially in resource-constrained environments, conserving resources while ensuring system performance becomes a key challenge. Traditional global rendering mechanisms often lead to resource waste and performance bottlenecks, especially when users only operate on a portion of the interface. Furthermore, frequently used interfaces require fast responses to avoid unnecessary rendering delays, which places higher demands on system resource management and dynamic rendering optimization.

[0003] While some current technologies based on lazy loading and dynamic loading have optimized resource allocation to a certain extent, they still have limitations when handling complex interactions and adapting to multiple scenarios, and cannot achieve precise resource management. Furthermore, while view reuse technology can avoid duplicate rendering, how to more intelligently combine user actions and event-driven mechanisms to achieve efficient component reuse remains a pressing technical challenge. Therefore, to address these issues, an efficient and intelligent method for local rendering and view reuse is urgently needed to improve system performance and resource utilization.

[0004] The present invention provides a method for developing a view reuse component that implements local rendering on the guLiteOS platform. The method aims to solve the problems of resource waste and response delay in the existing technology 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 the guLiteOs platform to solve the above technical problems.

[0006] The present invention provides a method for developing a view reuse component for implementing local rendering on the 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: Control 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 during startup. 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: Calculate the priority of each component to be loaded based on the user's interaction position, the relative distance to the component, the component's weight, and the current resource status, and thereby determine the loading order of the components;

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

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

[0016] Step S21: Analyzing the user's interactive operation parameters to improve the accuracy of event capture;

[0017] Step S22: Calculating the impact radius of the event based on 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 within 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 strength, 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 changes in external data;

[0025] Step S243: Adjust 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 component's state, layout, and related data. When the component or area needs to be rendered again, extract the relevant information from the cache for reuse.

[0029] S32: Dynamically adjust component reuse strategy based on user operation frequency;

[0030] S33: By linking with the event-driven local rendering mechanism, it determines whether components need to be reused based on the intensity, frequency, and duration of user operations;

[0031] S34: Predicting possible operation areas based on user historical behavior and pre-rendering the areas in advance;

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

[0033] The present invention provides a method for developing a view reuse component for local rendering on the 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, improving system startup speed and the smoothness of user interaction experience.

[0035] 2. Optimized resource utilization: Through an event-driven local update mechanism, the scope of interface updates is precisely controlled, and local rendering is performed only 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 component status and layout during the first rendering. When the same area needs to be rendered subsequently, it is directly read from the cache, avoiding repeated rendering and reducing the burden on memory and processors. This improves rendering efficiency, especially in frequently updated operation interfaces.

[0037] 4. Intelligent scene adaptation: Through dynamic feedback mechanisms and scene adaptation strategies, it can adjust event capture and rendering strategies in real time according to different application scenarios (such as reading, gaming, video playback, etc.), ensuring 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 based on the frequency and importance of component usage, prioritize retaining data of key components, effectively release memory resources, avoid unnecessary occupation, and improve system resource utilization and overall performance.

[0040] This method combines multiple optimization strategies to not only improve the system's rendering efficiency and response speed, but also effectively optimizes the use of memory and processors, 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 following briefly introduces the drawings required for use in the embodiments or the description of the prior art. 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 any creative work.

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

[0043] Figure 2 This is a structural diagram of embodiment 2 of the present invention;

[0044] Figure 3 This is a schematic structural diagram 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] To facilitate understanding of the present invention, the present invention will be described more fully below with reference to the accompanying drawings. Preferred embodiments of the present invention are shown in the accompanying drawings. However, the present invention may be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the present disclosure.

[0047] Example 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 the 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: Control 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 method for developing a view reuse component 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 precisely controls the scope of interface updates, rendering only the affected parts and avoiding resource waste caused by global rendering. This allows for more efficient allocation of processor and memory resources, especially in complex interfaces or resource-constrained environments, improving resource utilization efficiency.

[0055] Through the view reuse mechanism, component states are cached after the first render, and subsequent renders reuse data directly from the cache without recalculation. This approach not only reduces memory and processor load, but also significantly improves the processing speed of frequently operated interfaces.

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

[0057] Example 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] During startup, only essential components related to core operations are loaded. Non-core components are not loaded immediately during the initial phase but are marked as "pending," deferring their loading until triggered by user interaction or specific needs. This approach prioritizes fast responsiveness of critical functions during the system startup process, reducing initial memory usage and processor load.

[0061] Step S12: User interaction monitoring

[0062] By monitoring user interaction events such as clicks, slides, and scrolls, the system captures the user's current operation location (xu, yu) in real time. When a user interaction is detected within a specific area, 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 location, 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 user's interaction priority at coordinates (x,y) at time t. This reflects the frequency and importance of user actions. User actions at different locations have different impacts on priority.

[0068] (x u ,y u ) and (x i ,y i ): is the user's current operating position, and (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 operating position.

[0069] is a Gaussian decay function that is 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 greater the distance, the lower the priority. The parameter σ controls the range of attenuation; larger values ​​increase the range of influence.

[0070] M(t): represents the resource state or available resources 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, we can more intelligently determine which components should be lazy loaded. When the user is operating in a specific area, lower-priority components will be loaded later, reducing unnecessary resource consumption. Prioritizing the loading of critical components ensures a fast response time and avoids loading irrelevant components in the initial stage. This improves the efficiency of subsequent lazy loading, loading secondary components only when necessary. This shortens overall loading time, reduces initial resource usage, and improves operational fluency.

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

[0073] By monitoring resource usage, we optimize the loading order to ensure that key components are prioritized when resources are tight, reducing latency and improving overall performance.

[0074] A dynamic priority-based calculation mechanism makes view reuse more intelligent. When components in high-priority areas are frequently used, they are reused first, reducing duplicate rendering and loading. Reuse of low-priority components is delayed or processed when resources are sufficient. This greatly improves the efficiency of the view reuse mechanism, reduces unnecessary rendering operations, and optimizes memory utilization. Through intelligent reuse, unnecessary performance consumption is avoided, ensuring smoother operation.

[0075] By using the priority data calculated using this formula, we can analyze user interaction trajectories and predict their behavior, determining the user's next action area and pre-loading or rendering the corresponding components. This significantly improves the accuracy of pre-rendering because high-frequency areas are prioritized, allowing for earlier responses. This enhanced precision provides a smoother user experience. Key components can be loaded and rendered before the user's actions, reducing user wait time and providing more immediate feedback.

[0076] When processing external data changes, the priority data provided by the formula ensures that only critical areas are updated, eliminating the need for global rendering. Changes triggered by external data can affect specific areas, and the formula prioritizes these areas and components based on interaction frequency and resource availability. By optimizing local updates, the overhead of global rendering is avoided, and only the affected areas are updated, ensuring real-time operation and accurate updates, improving overall processing efficiency.

[0077] Step S14: Components are loaded sequentially based on priority, from high to low. Components related to user operations are loaded progressively based on the current resource status and calculated priority, ensuring maximum resource utilization within limited resources. Dynamic adjustment of the loading order ensures priority response for critical components while reducing the memory usage of non-critical components.

[0078] This embodiment uses dynamic loading and lazy loading mechanisms to minimize resource usage at startup and flexibly load required components as needed during user operation. Priority calculation and resource management enable efficient memory management, ensuring a smooth user experience and optimized system performance.

[0079] Example 3

[0080] See also Figure 3 This embodiment provides step 2: Through an event-driven local update mechanism, the system can dynamically identify key points of user interaction or data change and accurately control the scope of interface updates, thereby avoiding the overhead of global rendering. This mechanism optimizes resource utilization, prioritizes the affected interface areas, improves overall interface responsiveness, 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 location. At the same time, the accuracy of event capture is further optimized by combining the user's operation force (such as light touch, hard press), operation duration, and operation frequency.

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

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

[0085] Analysis of operation duration: For actions such as dragging or long pressing, determine the scope of influence based on the duration of the action. Longer-lasting actions generally indicate greater user attention to that area, thus triggering more extensive interface updates.

[0086] Scenario Adaptive Adjustment: Dynamically adjusts event capture strategies based on the current application scenario. For example, in reading scenarios, scrolling capture accuracy will be enhanced to ensure smooth page scrolling, while in gaming scenarios, the response speed of click and slide operations will be prioritized.

[0087] Recognition of combined operations: This not only captures single operation types, but also identifies continuous or combined operations, such as rapid double-clicks or multi-finger operations. The rendering area is adjusted based on the complexity of the combined operation to accommodate 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 to suit different application scenarios and system performance.

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

[0093] F u : Operation frequency coefficient, which indicates how frequently users operate in a specific area. The higher the frequency, the larger the affected area, and 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, 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 unrelated 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) Optimize resource utilization

[0099] By calculating the event's impact radius, Ru(t), we can determine only the areas affected by the event for update. Stronger events (such as a hard press or swipe) may affect a wider area, while smaller events like a tap may affect a smaller area. By determining the size of the impacted area, we can render only the parts that need to be updated, reducing resource waste and avoiding unnecessary global rendering.

[0100] (2) Improve response speed

[0101] Partial rendering significantly improves system responsiveness. By calculating the impact radius, it can quickly determine which components need to be updated first, thus reducing waiting time, ensuring that users receive immediate feedback on their actions, and improving interactive fluidity.

[0102] (3) Determine rendering priority

[0103] Different events have varying impacts on the UI. Calculating the radius allows for dynamic adjustment of component rendering priorities. Events with larger impacts are typically associated with high-priority areas (such as frequently used interfaces), while events with smaller impacts may be associated with less important areas. By calculating the radius, rendering resources can be allocated appropriately, ensuring that critical components are updated first.

[0104] (4) Accurate rendering

[0105] The impact radius can be dynamically adjusted based on event intensity, operation frequency, and other factors, ensuring resources are used in the areas actually affected. By precisely defining the affected area, unnecessary resource consumption is avoided while improving the user experience.

[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. Distance between components and the event location: The distance between components within the impact area and the event center directly affects their priority. Components closer to the event location are given higher priority and rendered first. Components farther away are given lower priority and can be rendered later.

[0109] 2. Component weight: Component weights are assigned based on their importance. Components with higher weights receive higher rendering priority, ensuring fast response times for critical components. For example, components with frequent user interaction or components critical to UI responsiveness 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 geometry of a circle, components affected by an event can be quickly determined to be within the circular area. This greatly simplifies calculations, reduces overhead, and speeds up the triggering of local rendering, significantly improving the responsiveness of user actions. The simple geometry of the circular area allows for quick determination of components within and outside the bounds, reducing complex calculations and significantly accelerating rendering response times.

[0113] Elliptical influence area: The major and minor 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 major axis can extend along the direction of the operation, while the minor axis can limit the expansion in the vertical direction, thereby achieving finer 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 operation range, 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 where 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 specifically includes the following sub-steps:

[0117] S241: Dynamic Feedback of User Operations: As user operations continue or new operations occur, these events are captured in real time, and the local rendering range is dynamically adjusted based on the impact area calculated in the previous step. Based on information such as operation frequency and force, 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 impact area, a high degree of synchronization with user operations is maintained, reducing interface lag and improving the immediacy and smoothness of interaction.

[0118] S242: Local updates driven by external data: In addition to user operations, the affected areas can be promptly calculated and local updates triggered based on changes in external data (such as network data, sensor input, etc.). For external data changes, 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 based on the current usage scenario (such as reading, gaming, video playback, etc.). For example, in a reading scenario, the capture and response of scrolling operations can be enhanced, while in a gaming scenario, click and slide operations are prioritized. Adjusting event capture and rendering priorities in different scenarios can effectively improve the user experience. Scenario 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 likely subsequent operation area is predicted and pre-rendered in advance. This intelligent prediction mechanism can significantly reduce user waiting time during the interaction process. By predicting and pre-rendering the operation trajectory, the user's operation area receives a faster response, avoiding possible delays and improving the overall smoothness of user interaction.

[0121] Example 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 significantly improving system response speed. The view reuse mechanism includes the following sub-steps:

[0123] S31. Component state caching and reuse

[0124] When a component is first rendered, 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 instead of re-rendering, ensuring that duplicate computations are reduced. By reusing components directly from the cache, duplicate resource allocation is avoided, significantly reducing memory and processor load, and improving rendering efficiency, especially in frequently updated user interfaces.

[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 prioritized for retrieval from the cache to ensure a fast response time in these areas. For low-frequency interaction areas, the system can delay reuse or clear the corresponding cache to optimize memory usage. Dynamically adjusting reuse priorities ensures smooth system responsiveness even under high load, preventing low-priority areas from taking up excessive memory and improving overall resource utilization.

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

[0128] This reuse mechanism works in conjunction with an event-driven local rendering mechanism, determining whether components should be reused based on the intensity, frequency, and duration of user operations. When users perform high-intensity or prolonged operations, the system prioritizes reusing component states to avoid unnecessary rendering operations. Combined with the event-driven mechanism, the system can quickly anticipate subsequent user actions, reducing rendering latency by preemptively reusing components and improving the overall interface's real-time responsiveness.

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

[0130] Based on historical user behavior, the system predicts likely operational areas and pre-renders those areas in advance. When the user enters that area, the system reuses the pre-rendered results, enabling seamless loading and display, avoiding interface lag. This mechanism, by reusing pre-rendered data, delivers faster responses to user actions, significantly improving the interactive experience and avoiding noticeable interface lag in complex operating environments.

[0131] S35. Intelligent Resource Management

[0132] When resources are limited or memory is nearing saturation, the system automatically adjusts the cache based on component usage frequency and importance, retaining critical components while freeing up cache space for less frequently used components to avoid memory overflow. This mechanism, through intelligent cache control, enables smooth operation even in resource-constrained environments, significantly improving system memory utilization and making it 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 resource waste and performance bottlenecks common in traditional view reuse. This mechanism, combined with user behavior prediction, enables faster responses and precise resource allocation, resulting in unexpected technical benefits and improving overall system performance and user experience.

[0134] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned 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-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the patent for this invention shall be determined by the appended claims.

Claims

1. A method for developing a view reuse component for local rendering on the 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: Control 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; The step S1 includes the following sub-steps: Step S11: Only necessary components related to core operations are loaded during startup. Non-core components are marked as "pending" 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: Calculate the priority of each component to be loaded based on the user's interaction position, the relative distance to the component, the component's weight, and the current resource status, and thereby determine the loading order of the components; Step S14: Select components to load in descending order of priority; Step S13 includes priority calculation The priority formula is as follows: ； L i (t): represents the loading priority of component i at time t; P u (x,y,t): represents the interaction priority of the user at coordinate (x,y) at time t; (x u ,y u ) is the user's current operating position, (x i ,y i ) is the coordinate position of the component i to be loaded; : is a Gaussian attenuation function used to calculate the component position (x i ,y i ) and the user operation position (x u ,y u ) distance adjusts the component priority, and the parameter σ controls the range of attenuation; M(t): represents the resource status or available resource situation of the system at the current time t; The step 2 includes the following sub-steps: Step S21: Analyzing the user's interactive operation parameters to improve the accuracy of event capture; Step S22: Calculating the impact radius of the event based on 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 within the area; Step S24: adjusting rendering priority and resource allocation through a dynamic feedback mechanism and scene adaptation strategy; S22: Influence radius calculation The calculation formula for the influence radius is: ； Among them, R u (t): the impact radius of the event at time t; λ: The proportional coefficient that controls the size of the impact radius; L u : Operation force coefficient, indicating the intensity of user interaction; F u : Operation frequency coefficient, which indicates the frequency of user operations in a specific area; T u : operation duration; x u ,y u and x e ,y e :User operation point (x u ,y u ) and the event location (x e ,y e ) coordinates, and calculate the distance between the event and the user action; d max : The maximum allowed interaction distance, which limits the maximum range of the influence radius; The affected area in step S23 is circular or elliptical; 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 changes in external data; Step S243: Adjusting event capture and rendering strategies according to the current usage scenario; 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.

2. A method for developing a view reuse component for implementing local rendering on the guLiteOs platform according to claim 1, characterized in that: The view reuse mechanism includes the following sub-steps S31: When rendering for the first time, save the rendering state and layout of the component. When the component or area needs to be rendered again later, extract the component state from the cache for reuse; S32: Dynamically adjust component reuse strategy based on user operation frequency; S33: By linking with the event-driven local rendering mechanism, it determines whether components need to be reused based on the intensity, frequency, and duration of user operations; S34: Predicting possible operation areas based on user historical behavior and pre-rendering the areas in advance; S35: Automatically adjust the cache based on the frequency and importance of components to retain key components.

Images