Component pool rendering method and device based on dynamic expansion and contraction in building intelligent control system

Abstract

The application relates to a component pool rendering method and device based on dynamic expansion and contraction in a building intelligent control system, wherein the method comprises the following steps: according to a preset rendering complexity threshold, classifying each component defined by a component library, wherein the classified component types comprise first type components and second type components; listening to and recording the calling frequencies of each type of component within a preset statistical period; according to the comparison result of the calling frequencies and a preset frequency threshold, dynamically adjusting the pre-instantiation quantity of each type of component in a component pool, wherein the component pool is used for caching instances created based on the component types defined by the component library; and in response to a drag-and-drop placement instruction of a component, obtaining an idle instance corresponding to a target component type from the component pool and performing a rendering operation. Through the application, the problems of dynamic adjustment and lack of self-adaptive capability of component management in the prior art, which lead to rigid resource allocation and memory fragmentation, are solved.

Description

Technical Field

[0001] This application relates to the field of building intelligent control systems, and in particular to a method and apparatus for rendering component pools based on dynamic scaling in building intelligent control systems. Background Technology

[0002] In the fields of building intelligent control and industrial automation, configuration software is a core tool for building human-machine interaction systems and monitoring platforms. With the deep integration of Industry 4.0 and IoT technologies, the application scenarios of modern industrial sites have undergone fundamental changes: from traditional point-based monitoring of single devices, it has evolved into comprehensive digital and visual management covering smart factories and smart parks. Under this trend, configuration monitoring screens are no longer limited to simple device status displays, but have evolved into large-scale visual dashboards that carry hundreds or thousands of dynamic graphic element nodes and integrate multi-dimensional real-time data. Such screens exhibit a significant polarization in resource load: on the one hand, they contain a large number of basic components with low computational density (such as indicator lights and text labels), and on the other hand, they integrate complex components with high computational density (such as aggregated real-time trend charts and 3D model embeddings).

[0003] Therefore, in the construction of large-scale projects like smart factories, engineers need to perform drag-and-drop configuration editing operations at an extremely high frequency. However, existing mainstream configuration software still uses a static, indiscriminate instantiation and synchronous rendering mechanism at the underlying architecture. This mechanism has the following significant drawbacks: When faced with scenarios where hundreds or thousands of similar basic components are repeatedly dragged, adjusted, or even deleted in a smart park environment, the "use-and-discard" mode, which triggers a complete instantiation with each drag, means that discarded objects can only be passively cleaned up by the system's garbage collection. On low-spec industrial control computers, frequent memory allocation and release can easily lead to memory fragmentation and even crashes. In addition, existing component pool technologies in the industry mostly adopt a static allocation strategy with fixed capacity, which cannot perceive the differences in the frequency distribution of component usage in actual business scenarios. This resource allocation mode that does not distinguish between hot and cold components prevents computing resources from being tilted towards frequently used hot components, leading to redundant memory occupation of non-hot resources and resource contention for hot components, making it difficult to meet dynamically changing engineering needs. It is evident that the current component management lacks dynamic adjustment and adaptive capabilities, resulting in rigid resource allocation and memory fragmentation. Summary of the Invention

[0004] This application provides a component pool rendering method and apparatus based on dynamic scaling in a building intelligent control system to solve the problems of rigid resource allocation and memory fragmentation caused by the lack of dynamic adjustment and adaptive capability in component management in the prior art.

[0005] Firstly, this application provides a component pool rendering method based on dynamic scaling in a building intelligent control system, including: Based on a preset rendering complexity threshold, the components defined in the component library are classified, and the classified component types include first type components and second type components. Monitor and record the frequency of calls to each type of component within a preset statistical period; Based on the comparison result between the called frequency and the preset frequency threshold, the number of pre-instantiated components of each type in the component pool is dynamically adjusted, wherein the component pool is used to cache instances created based on the component types defined in the component library; In response to the drag-and-drop command of a component, an idle instance corresponding to the target component type is obtained from the component pool, and a rendering operation is performed.

[0006] Secondly, this application provides a component pool rendering device based on dynamic scaling in a building intelligent control system, comprising: The first processing module is used to classify the components defined in the component library according to a preset rendering complexity threshold. The classified component types include first type components and second type components. The second processing module is used to monitor and record the call frequency of each type of component within a preset statistical period; The third processing module is used to dynamically adjust the number of pre-instantiated components of each type in the component pool according to the comparison result between the called frequency and the preset frequency threshold. The component pool is used to cache instances created based on the component types defined in the component library. The fourth processing module is used to respond to the drag-and-drop instruction of the component, obtain an idle instance corresponding to the target component type from the component pool, and perform a rendering operation.

[0007] Thirdly, this application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the processor is configured to execute the component pool rendering method based on dynamic scaling in the building intelligent control system described in the first aspect of this application.

[0008] Fourthly, this application also provides a computer storage medium storing computer-executable instructions, which are used to execute the component pool rendering method based on dynamic scaling in the building intelligent control system described in the first aspect of this application.

[0009] Compared with the prior art, the above-mentioned technical solution provided in this application embodiment has the following advantages: The method provided in this application embodiment classifies each component defined in the component library according to a preset rendering complexity threshold, then listens to and records the calling frequency of each type of component within a preset statistical period, and then dynamically adjusts the pre-instantiated number of corresponding components of each type in the component pool according to the comparison result of the calling frequency and the preset frequency threshold. Finally, in response to the drag and drop placement instruction of the component, it obtains an idle instance corresponding to the target component type from the component pool and performs a rendering operation. As can be seen, through the embodiments of this application, a component complexity classification system is established, providing a type basis for subsequent differentiated processing. Then, changes in business popularity are perceived in real time, providing a quantitative basis for resource scheduling. Furthermore, the number of pre-instantiated components is changed from a static fixed value to a dynamic adjustable value driven by popularity, and components are divided by a preset frequency threshold, realizing dynamic adaptive adjustment of the component pool capacity, allowing memory resources to elastically scale around hot components. In addition, the instances used in the rendering operation are not created on the spot, but are obtained from pre-created idle instances in the component pool, that is, the final rendering is completed with the minimum path, ensuring smooth interaction, while eliminating memory allocation behavior in the rendering path, that is, the reduction in the number of allocations leads to a significant reduction in the degree of fragmentation. Attached Figure Description The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0012] Figure 1 A flowchart illustrating a component pool rendering method based on dynamic scaling in a building intelligent control system, provided as an embodiment of this application; Figure 2 A flowchart illustrating a method for rendering a configuration component pool for dynamic scaling of intelligent building control, as provided in this application embodiment; Figure 3 A schematic diagram of a component classification modeling process provided in an embodiment of this application; Figure 4A flowchart illustrating a heat map and dynamic expansion process provided for an embodiment of this application; Figure 5 A schematic diagram illustrating a drag-and-drop and depth-delayed loading process provided in an embodiment of this application; Figure 6 A schematic diagram illustrating a memory monitoring and intelligent replacement process provided in an embodiment of this application; Figure 7 A schematic diagram of a scenario-based pre-creation priority process provided for embodiments of this application; Figure 8 A schematic diagram of the structure of a component pool rendering device based on dynamic scaling in a building intelligent control system provided in this application embodiment; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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.

[0014] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0015] To address the problems of rigid resource allocation and memory fragmentation caused by the lack of dynamic adjustment and adaptive capabilities in component management in existing technologies, this application provides a component pool rendering method based on dynamic scaling in a building intelligent control system, such as... Figure 1 As shown, the steps of this method include: Step 101: According to the preset rendering complexity threshold, classify the components defined in the component library. The classified component types include first type components and second type components. In this embodiment, the component library is used to store a collection of static definition information and configuration parameters for various components, including metadata such as component style attributes, data binding rules, rendering logic, and complexity markers. The definitions in the component library are read-only data; the system reads the component definitions from the component library at runtime to create corresponding instance objects.

[0016] Furthermore, the component pool in this application serves as a memory buffer for caching instantiated component objects and is the direct target of the dynamic scaling strategy. The component pool stores runtime instances created based on the component library definitions. These instances are in a ready state, created but not yet in use, and can be instantly retrieved and rendered onto the canvas via drag-and-drop operations. Essentially, the component pool uses a space-for-time caching strategy to decouple the instantiation process from the real-time path of user interaction, thereby reducing interaction latency.

[0017] Furthermore, the preset rendering complexity threshold in this embodiment is a preset critical value used to distinguish the computational intensity of components. This threshold is based on the component's rendering computational load (including but not limited to the number of geometric faces, data points, texture size, animation frames, etc.) to classify components into different complexity levels. Based on this, the first type of component refers to lightweight components with a computational rendering load below the preset complexity threshold, such as buttons, text labels, and icons. These components require fewer computational resources for instantiation and rendering and have a fast response time. The second type of component refers to heavyweight components with a computational rendering load reaching or exceeding the preset complexity threshold, such as real-time trend charts, multi-axis dashboards, and 3D models. The instantiation and rendering of these components involves a large amount of data computation and graphics processing, resulting in high resource consumption and long rendering time.

[0018] As can be seen, this step involves reading the complexity parameters of each component in the component library, such as the amount of data computation, graphics processing, and texture size involved in the rendering process. Components with a computational rendering amount less than a preset threshold are classified as Type 1 components (basic components), while components with a computational rendering amount greater than or equal to the preset threshold are classified as Type 2 components (complex components). By classifying components by complexity, a type-based identification foundation is laid for implementing differentiated scaling and rendering strategies in subsequent steps. Components with different complexity levels have fundamental differences in instantiation overhead and rendering time. A uniform processing method would lead to resource waste or response delays; therefore, classification is a necessary prerequisite for achieving refined resource management.

[0019] Step 102: Monitor and record the call frequency of each type of component within the preset statistical period; In this embodiment, the preset statistical period is a fixed time window set by the system to count the frequency of component calls. During this period, the system continuously accumulates the number of times each component is called. At the end of the period, a frequency value is calculated, and scaling decisions are made accordingly. The call frequency is the number of times a certain type of component is dragged and placed onto the canvas per unit time, measured in times per hour. This frequency reflects the actual usage intensity of each type of component during the project editing process.

[0020] As can be seen, during the user's configuration project editing process, the system continuously monitors the user's drag-and-drop operations. Each time a component is dragged to the canvas, its type identifier and placement timestamp are recorded. Using a preset statistical period (e.g., 60 seconds) as a time window, the total number of drag-and-drop operations for each type of component within that period is accumulated. The ratio of this accumulated number to the statistical period length is used to obtain the call frequency of each component type. By statistically analyzing the call frequency of each component in real time, the actual usage intensity of each component type during the current project editing process is quantitatively reflected. This frequency value serves as the core basis for subsequent dynamic scaling decisions, enabling the system to perceive changes in business load and avoid resource mismatch caused by static configuration.

[0021] Step 103: Based on the comparison result between the call frequency and the preset frequency threshold, dynamically adjust the number of pre-instantiated components of each type in the component pool. The component pool is used to cache instances created based on the component types defined in the component library. In this embodiment, the pre-instantiated number refers to the number of instances pre-created and kept in a ready state for a certain type of component in the component pool. These instances have completed memory allocation and initialization upon creation and can be immediately obtained and rendered when the user drags and drops, without experiencing the instantiation waiting time.

[0022] As can be seen, by comparing the calculated call frequency of each type of component with a preset frequency threshold, the popularity level of each type of component is determined based on the comparison results, and the pre-instantiation quantity of each component in the component pool is adjusted accordingly. Specifically, component types with higher call frequency receive a higher pre-instantiation quantity to ensure that they can be used immediately when users use them frequently; component types with lower call frequency maintain a lower pre-instantiation quantity or are not pre-instantiated to avoid memory resources being occupied by infrequently used components for a long time. Based on this, a component classification system is first established to lay the foundation for differentiated resource management; on this basis, the call frequency of each component is continuously monitored, enabling the system to obtain real-time perception of changes in business load; based on the perception results, the pre-instantiation quantity of each type of component in the component pool is dynamically adjusted, so that high-frequency components automatically receive more pre-instantiation supply, and low-frequency components automatically reduce resource quotas, thereby achieving adaptive allocation of resources tilted towards hot spots, breaking the static rigidity of fixed pool capacity; finally, idle instances are obtained from the component pool for rendering, replacing immediate creation and destruction with instance reuse, eliminating memory allocation behavior in the rendering path.

[0023] Step 104: In response to the drag-and-drop instruction of the component, obtain an idle instance corresponding to the target component type from the component pool and perform the rendering operation.

[0024] In this embodiment of the application, an idle instance refers to an instance object in the component pool that has been created, is in a ready state, and has not yet been occupied by a rendering operation.

[0025] As can be seen, when a user performs a drag-and-drop operation on a component, the system first identifies the type of the target component, then searches for and retrieves an idle instance of the corresponding component type from the component pool, and renders that instance to the specified position on the canvas. This quickly presents the pre-ready instance from the component pool to the user interface, achieving a drag-and-drop responsive interactive experience. Since the instantiation process has already been completed in the previous steps, this step only requires retrieving and drawing the instance, significantly shortening the rendering path and ensuring the smoothness of the editing operation.

[0026] Taking a typical editing scenario in a building intelligent control project as an example: When engineers are building a temperature monitoring dashboard for a smart park, they need to frequently drag and drop the temperature trend chart component (belonging to the second type of component) for layout adjustments, while the 3D building model component (also belonging to the second type of component) is only dragged and dropped once in the initial stage. Within a 60-second statistical period, the system detected that the temperature trend chart was dragged and dropped 80 times (corresponding to a call frequency of 80 times / hour), while the 3D building model was only dragged and dropped once (corresponding to a call frequency of 1 time / hour). Based on preset frequency thresholds (e.g., the first frequency threshold is 60 times / hour, and the second frequency threshold is 10 times / hour), the system classifies the temperature trend chart as a high-frequency type and increases its pre-instantiated quantity in the component pool to 3; the 3D building model is classified as a low-frequency type, and its pre-instantiated quantity is set to zero (i.e., no instance is pre-stored in the pool, it is only created immediately upon the first drag and dropped, and released after use). When engineers drag the temperature trend chart again, they can directly retrieve a ready instance from the component pool for rendering, eliminating the need for instantiation waiting time. Meanwhile, the 3D building model, due to its extremely low usage frequency, does not occupy pool resources and is only created on demand when necessary. This demonstrates that by real-time sensing of the actual usage frequency of each component in the business scenario, and accurately allocating limited component pool resources to high-frequency, frequently used components, optimal memory resource allocation is achieved, avoiding resource waste caused by infrequently used components occupying memory for extended periods.

[0027] Through steps 101 to 104 above, the components defined in the component library are classified according to the preset rendering complexity threshold. Then, the calling frequency of each type of component within the preset statistical period is monitored and recorded. Based on the comparison between the calling frequency and the preset frequency threshold, the number of pre-instantiated components of each type in the component pool is dynamically adjusted. Finally, in response to the drag-and-drop instruction of the component, an idle instance corresponding to the target component type is obtained from the component pool and the rendering operation is performed. As can be seen, through the embodiments of this application, a component complexity classification system is established, providing a type basis for subsequent differentiated processing. Then, changes in business popularity are perceived in real time, providing a quantitative basis for resource scheduling. Furthermore, the number of pre-instantiated components is changed from a static fixed value to a dynamic adjustable value driven by popularity, and components are divided by a preset frequency threshold, realizing dynamic adaptive adjustment of the component pool capacity, allowing memory resources to elastically scale around hot components. In addition, the instances used in the rendering operation are not created on the spot, but are obtained from pre-created idle instances in the component pool, that is, the final rendering is completed with the minimum path, ensuring smooth interaction, while eliminating memory allocation behavior in the rendering path, that is, the reduction in the number of allocations leads to a significant reduction in the degree of fragmentation.

[0028] In an optional embodiment of this application, the method of classifying the components defined in the component library according to a preset rendering complexity threshold in step 101 above may further include: Step 11: Mark components whose calculated rendering amount is less than the preset rendering complexity threshold as first type components, wherein the first type components include buttons, text labels and icons; In this embodiment, computational rendering overhead refers to the total amount of computing resources consumed by a component during instantiation and rendering, including but not limited to the overhead of drawing geometric faces, the overhead of binding and updating data points, the overhead of loading and sampling texture maps, the overhead of calculating and refreshing animation frames, and the overhead of communication and synchronization between the component and the backend data source. Computational rendering overhead is a comprehensive quantitative indicator for measuring the rendering complexity of a component.

[0029] Furthermore, the preset rendering complexity threshold is a critical value pre-defined in the system to distinguish the rendering complexity of components. This threshold is measured by the amount of computational rendering required; components below this threshold are considered lightweight components, while those reaching or exceeding it are considered heavyweight components. Further, the first type of component refers to lightweight components with a computational rendering requirement below the preset threshold. Typical characteristics of this type of component include simple rendering logic, single data interaction, low graphics rendering overhead, and instantiation completion within milliseconds.

[0030] Step 12: Mark the components whose calculated rendering amount is greater than or equal to the preset rendering complexity threshold as second type components. The second type components include real-time trend charts, multi-axis dashboards, and 3D models.

[0031] In this application embodiment, the second type of component refers to a heavyweight component whose computational rendering workload reaches or exceeds a preset threshold. Typical characteristics of this type of component include complex rendering logic, involvement of multi-dimensional data binding, high graphics rendering overhead, long instantiation time, and continuous consumption of significant computational resources during runtime.

[0032] As shown in steps 11 and 12 above, components with a computational rendering amount less than a preset threshold are marked as Type 1 components. These components typically function as status indicators, static labels, or simple interactive elements in the visual representation. Their visual appearance is characterized by regular geometric shapes, simple color variations, and no need for real-time data-driven operation. Therefore, during instantiation, only basic memory allocation and attribute assignment are required to complete rendering preparation. Components with a computational rendering amount reaching or exceeding the preset threshold are marked as Type 2 components. These components typically function as data visualization and analysis or 3D spatial display elements in the visual representation. Their visual appearance includes a large number of dynamic data points, involves coordinate transformations and interpolation calculations, or requires loading 3D meshes and texture data. Therefore, during instantiation, several time-consuming operations such as data source connection, event listener registration, and graphics pipeline initialization are required.

[0033] As can be seen, by dividing components into two categories based on a preset rendering complexity threshold, differentiated pool management and rendering strategies can be implemented for different types of components in subsequent processes. Components of the first type, with their small computational rendering load, can undergo real-time synchronous rendering to ensure immediate interactive response; components of the second type, with their large computational rendering load, can be included in a background asynchronous loading process to avoid blocking the main thread. This classification mechanism ensures that scaling decisions and rendering scheduling are tailored to each type of component, avoiding the inefficiency caused by using a uniform processing mode for all components. In other words, lightweight components are not slowed down by the loading process of heavyweight components, and heavyweight components are not forced to complete loading on the main thread due to the real-time rendering needs of lightweight components, thus achieving a dual optimization of system resource utilization and UI smoothness.

[0034] In an optional embodiment of this application, the method of monitoring and recording the call frequency of each type of component within a preset statistical period involved in step 102 above may further include: Step 21: Set the preset statistical period to a preset duration and count the cumulative number of times each type of component is dragged and placed onto the canvas within the preset statistical period. In this embodiment, the preset statistical period is a fixed time window pre-set for statistically analyzing the frequency of component calls. The length of this time window is the preset duration. When the window expires, the system performs a frequency calculation and makes a scaling decision accordingly. Subsequently, the window is reset and the next round of statistics begins.

[0035] The cumulative count refers to the total number of times a certain type of component is dragged and successfully placed onto the canvas by a user within a preset statistical period. Each complete drag-and-place operation is counted as one valid call; operations that are only dragged but not placed onto the canvas are not included in the statistics.

[0036] Step 22: Determine the call frequency by the ratio of the cumulative number of times to the preset statistical period.

[0037] Based on steps 21 and 22 above, the preset statistical period is first set to a fixed preset duration, such as 60 seconds. The determination of this preset duration needs to consider two aspects: if the duration is too short, the statistical sample size will be insufficient, the statistical significance of the frequency value will be poor, and it will be prone to drastic fluctuations due to accidental operations, leading to frequent oscillations in scaling decisions; if the duration is too long, the system response will be lagging, failing to reflect the actual changes in business activity in a timely manner, causing scaling decisions to lose their timeliness. Therefore, the duration selected in practice needs to strike a balance between these two factors. After this, within the time window of the preset duration, user drag-and-drop events are continuously monitored. Whenever a component of a certain type is dragged and placed on the canvas, the cumulative number of times for that type of component is accumulated. This cumulative number reflects the absolute usage frequency of that type of component within the statistical period. Finally, the cumulative number is divided by the duration of the preset statistical period to obtain the call frequency of that type of component. This frequency is measured in terms of the number of calls per unit time (e.g., times / hour), making the frequency values ​​between different statistical periods comparable.

[0038] To address this, the aforementioned building intelligent control engineering example is used. A preset statistical period of 60 seconds is set, and the system starts timing the statistics from time T0. Within the time window from T0 to T0+60 seconds, the system continuously listens for the engineer's drag-and-drop operations and records the following data: If the temperature trend chart component is dragged and placed 5 times within the window period, its cumulative count is 5 times, and the call frequency = 5 times / 60 seconds = 5 times / minute, equivalent to 300 times / hour; If the 3D building model component is dragged and placed 1 time within the window period, its cumulative count is 1 time, and the call frequency = 1 time / 60 seconds = 1 time / minute, equivalent to 60 times / hour; If the equipment start / stop button component is dragged and placed 12 times within the window period, its cumulative count is 12 times, and the call frequency = 12 times / 60 seconds = 12 times / minute, equivalent to 720 times / hour.

[0039] If the aforementioned frequency value is calculated at the 60th second, and dynamic scaling is executed accordingly, then the device start / stop button is identified as a high-frequency type and the number of instances in the pool is increased; the temperature trend chart is identified as a mid-frequency type and the normal allocation is maintained; and the 3D building model is identified as a low-frequency type and the allocation in the pool is reduced or even zeroed out. Subsequently, the statistics window is reset, and the system continues to monitor and recalculate the cumulative number of times each type of component is counted in the second statistical cycle from T0+60 seconds to T0+120 seconds. This cycle repeats continuously, ensuring that each scaling decision is based on the latest business activity data.

[0040] It's important to note that the call frequency measures the density of operations per unit of time, not the absolute number of operations. In the example above, if a certain type of component is dragged and placed 50 times within a 60-second window, its frequency is 50 times / minute; if it is dragged and placed only twice within another 60-second window, its frequency is 2 times / minute. The former is significantly higher than the latter, and the system determines that the component's popularity is increasing and expands its capacity accordingly, while shrinking its capacity when popularity decreases. Through normalization processing using a fixed time window, the frequency values ​​for different periods have a unified comparison benchmark, allowing the system to accurately identify the true rise and fall trend of component popularity rather than merely reflecting fluctuations in the absolute number of operations.

[0041] As can be seen, by using the average number of calls per unit time within a fixed time window as a quantitative indicator of call frequency, the system obtains objective data input that accurately reflects the actual business activity of various types of components during the engineering editing process. This frequency value has two technical benefits: In the time dimension, the fixed window provides a unified comparison benchmark for frequency results across different statistical periods, accurately reflecting the true upward and downward trends of component activity rather than superficial fluctuations in the absolute number of operations; in the decision-making dimension, this frequency value directly serves as the quantitative basis for determining high-frequency / medium-frequency / low-frequency in subsequent dynamic scaling steps, ensuring that scaling decisions are based on measurable and reproducible business data, avoiding subjective biases caused by human pre-setting, and ensuring the scientific and adaptive nature of resource allocation decisions.

[0042] In an optional embodiment of this application, the method of dynamically adjusting the number of pre-instantiated components of each type in the component pool based on the comparison result between the called frequency and the preset frequency threshold involved in step 103 above may further include: Step 31: If the frequency of being called is greater than or equal to the first frequency threshold, determine that the corresponding component type is a high-frequency type and set the number of pre-instantiated components to the first preset value. Step 32: If the call frequency is less than the first frequency threshold and greater than or equal to the second frequency threshold, determine that the corresponding component type is a medium frequency type and set the pre-instantiation quantity to the second preset value. Step 33: If the frequency of being called is less than the second frequency threshold, determine that the corresponding component type is a low-frequency type and set the number of pre-instantiations to zero; wherein, the first preset value is greater than the second preset value.

[0043] In this embodiment, the first frequency threshold is a preset frequency threshold used to determine whether a component is a high-frequency type. When the calling frequency of a certain type of component reaches or exceeds this threshold, it indicates that this type of component is a hot resource in the current project editing process and needs to be given priority resource protection. The second frequency threshold is a preset frequency threshold used to determine whether a component is a low-frequency type, and its value is lower than the first frequency threshold. When the calling frequency of a certain type of component is lower than this threshold, it indicates that this type of component is a low-frequency resource in the current project editing process and does not need to reserve an instance in the component pool.

[0044] The first preset value is the pre-instantiation quantity set for high-frequency type components, representing the number of ready instances that a high-frequency type component should maintain in the component pool. The second preset value is the pre-instantiation quantity set for mid-frequency type components, representing the number of ready instances that a mid-frequency type component should maintain in the component pool. This value is less than the first preset value.

[0045] For steps 31 to 33 above, in a specific example, the first preset value is set to 3, the second preset value is set to 1, the first frequency threshold is set to 60 times / hour, and the second frequency threshold is set to 10 times / hour.

[0046] During the editing process of a smart park monitoring dashboard, the call frequencies of various component types in the previous statistical period were as follows: the temperature trend chart was called 80 times / hour. The system compared this value with the first frequency threshold (60 times / hour). Since 80 ≥ 60, it was determined to be a high-frequency type, and the number of pre-instantiated instances of it in the component pool was set to the first preset value of 3. Thereafter, the three temperature trend chart instances remained in a ready state in the component pool. When engineers dragged and dropped the three temperature trend charts consecutively, the instances were instantly retrieved and rendered without any waiting delay.

[0047] The device start / stop button is called 25 times per hour. The system compares this value with a first frequency threshold (60 times per hour) and a second frequency threshold (10 times per hour). If 25 < 60 and 25 ≥ 10, it is classified as a medium-frequency type, and the number of pre-instantiated instances of this button in the component pool is set to the second preset value of 1. This button always maintains a ready instance in the pool to meet the immediate response requirements under normal usage frequency.

[0048] The 3D architectural model is called 3 times per hour. The system compares this value with a second frequency threshold (10 times per hour). Since 3 < 10, it is classified as a low-frequency type, and its pre-instantiated quantity in the component pool is set to zero. No instance of this model is reserved in the pool; it is created and rendered only when dragged and dropped for the first time, and its resources are released after use. Because this type of component is used very infrequently, the overhead of each creation is negligible in the overall editing process. The memory resources saved by not reserving instances can be reallocated to high-frequency components, improving overall resource utilization efficiency. The above judgment result is recorded and remains in effect until the frequency is recalculated in the next statistical period and updated based on the new comparison result.

[0049] This demonstrates that high-frequency components receive a sufficient supply of pre-instances. Regardless of the frequency at which users drag and drop, instances can be instantly retrieved from the component pool, avoiding the waiting delays introduced by reverting to instant creation mode due to insufficient instances in the pool. The pre-instance count for low-frequency components is set to zero, preventing infrequently used components from occupying component pool memory resources for extended periods. This avoids the memory redundancy caused by the indiscriminate use of hot and cold components in a fixed pool, as seen in existing technologies. This allows the limited component pool capacity to be focused on serving truly needed high-frequency, frequently used components. As component usage popularity changes in real time—for example, when a component increases from mid-frequency to high-frequency—its pre-instance count switches from the second preset value to the first preset value (automatic capacity expansion); conversely, when a component decreases from high-frequency to mid-frequency or low-frequency, its pre-instance count is reduced accordingly, even to zero (automatic capacity reduction). This dynamic adjustment mechanism ensures that the component pool capacity remains synchronized with business activity, achieving elastic scaling of the component pool capacity and optimal resource allocation, avoiding resource rigidity issues caused by improper static capacity settings.

[0050] In this embodiment of the application, the method may further include: Step 41: After dynamically adjusting the number of pre-instantiated components of each type in the component pool, query the component dependency graph to determine the associated component types that are related to the high-frequency type components; wherein, the component dependency graph records the co-occurrence association degree between each component type; In this embodiment, the component dependency graph is a pre-constructed data structure used to record the degree of co-occurrence association between various component types. This graph uses component types as nodes and the co-occurrence association between component types as edges, reflecting the objective laws governing the combined use of components in building intelligent control engineering practice. The graph can be constructed based on large-scale statistical analysis of historical engineering data; that is, by mining the component co-occurrence patterns in existing configuration engineering files, the probability of any two types of components being used simultaneously in the same screen can be quantitatively calculated.

[0051] Co-occurrence correlation is a quantitative indicator that measures the degree to which two types of components are used together in engineering practice. If two types of components frequently appear together in the same frame across multiple engineering documents, their co-occurrence correlation is high; conversely, if two types of components rarely or never appear together in the same frame, their co-occurrence correlation is low. Co-occurrence correlation is usually represented by a value between 0 and 1, with the value closer to 1 indicating a stronger correlation.

[0052] Associated component types are other component types that have co-occurrence relationships with high-frequency component types, as determined by a component dependency graph query. For example, if a temperature trend chart and a temperature alarm light are frequently used together in historical projects, then for the temperature trend chart, the temperature alarm light is an associated component type.

[0053] Step 42: If the associated component type is not a high-frequency component type, increase the number of pre-instantiated associated component types in the component pool based on the co-occurrence correlation between the associated component type and the high-frequency component type.

[0054] For steps 41 and 42 above, after completing the dynamic adjustment of the pre-instantiation quantity, the system uses the component determined to be a high-frequency type as the starting point for the query. It then retrieves all other component types that have a co-occurrence relationship with this high-frequency type in the component dependency graph and determines the retrieval results as the candidate set of associated component types. This step addresses the question of which components might require additional resources. First, it checks whether the associated component type itself has already been determined to be a high-frequency type—if it is, it has already obtained the highest pre-instantiation quantity guarantee in the above steps and does not need to perform an upward adjustment operation. If the associated component type is not a high-frequency type (i.e., a medium-frequency or low-frequency type), the system performs an upward adjustment operation on its pre-instantiation quantity based on the co-occurrence relationship between the associated component type and the high-frequency type. The upward adjustment magnitude is positively correlated with the co-occurrence relationship, meaning the stronger the co-occurrence relationship, the greater the upward adjustment magnitude.

[0055] In this specific example, the aforementioned building intelligent control example scenario is used. The pre-built component dependency graph records the following co-occurrence relationships: the co-occurrence correlation between the temperature trend graph and the temperature alarm light is 0.85 (high correlation), the co-occurrence correlation between the temperature trend graph and the humidity trend graph is 0.60 (medium correlation), and the co-occurrence correlation between the 3D building model and the equipment start / stop button is 0.05 (weak correlation).

[0056] At the end of the previous statistical period, the system determines through the judgment logic of steps 31 to 33 above that: the temperature trend chart is called 80 times / hour (high frequency type) and has obtained 3 pre-instantiated quantities (first preset value) in the component pool; the temperature alarm light is called 25 times / hour (medium frequency type) and has obtained 1 pre-instantiated quantity (second preset value) in the component pool.

[0057] After completing the basic expansion and contraction described above, the system executes steps 41 and 42: using the temperature trend graph (high-frequency type) as the starting point, it searches for its associated component types in the component dependency graph, finding the temperature alarm light (co-occurrence correlation 0.85) and the humidity trend graph (co-occurrence correlation 0.60). The system checks the heat level of both: the temperature alarm light belongs to the medium-frequency type, not the high-frequency type, therefore meeting the upward adjustment condition; the humidity trend graph also belongs to the medium-frequency type, similarly meeting the upward adjustment condition.

[0058] The system performs adjustments based on the co-occurrence correlation: the temperature alarm light and the temperature trend map have a co-occurrence correlation of 0.85, indicating a strong correlation, so the number of pre-instantiated instances is increased from 1 to 2; the humidity trend map and the temperature trend map have a co-occurrence correlation of 0.60, indicating a medium correlation, so the number of pre-instantiated instances is increased from 1 to 1 (i.e., no increase is made, or the system only increases the number of associated components exceeding a certain correlation threshold according to preset rules). Afterward, when engineers drag and drop the temperature trend map, the accompanying temperature alarm light is also highly likely to be used simultaneously. Since the temperature alarm light has already been pre-expanded to 2 instances in the component pool, it can be instantiated and rendered without waiting.

[0059] As can be seen, the basic scaling strategy allocates resources based solely on the independent usage frequency of each component, without considering the business combination patterns between components. This step, by introducing a dependency graph, elevates the system's resource allocation decision from single-point optimality to combinatorial optimality. When high-frequency components are used extensively, their associated components also receive pre-configured resources simultaneously, avoiding the additional delays introduced by the immediate creation of associated components due to insufficient instances in the pool. By checking whether associated components are of high-frequency type, i.e., high-frequency types have already received the maximum allocation in the basic scaling, no further adjustment is needed, avoiding redundant resource configuration and waste. By performing differentiated adjustments based on the numerical differences in co-occurrence correlation, i.e., adjusting more for high-correlation components and less or no for low-correlation components, precise allocation of incremental resource input is achieved, ensuring that limited component pool resources are invested in the associated component types most likely to be actually used, maximizing marginal benefits.

[0060] In optional embodiments of this application, the method of performing the rendering operation involved in step 104 of this application embodiment may further include: Step 51: If the target component is a first-type component, obtain an idle instance from the component pool and perform real-time rendering on the main thread. Step 52: If the target component is a second type component, generate placeholder primitives in the main thread and perform data binding and style rendering operations of the target component in the background thread. After rendering is completed, obtain a complete instance, replace the placeholder primitives with the complete instance and release the memory resources occupied by the placeholder primitives.

[0061] In this embodiment, the main thread is the system's main execution thread used to handle user interaction events, maintain interface refresh, and perform UI drawing operations. In graphical user interface applications, all operations directly related to interface display must be executed in the main thread, and the responsiveness of the main thread directly determines the smoothness of user operation. Background threads, which run in parallel with the main thread, are used to execute non-interface-blocking computationally intensive or I / O-intensive tasks. The computation process of background threads does not block the event response and interface refresh of the main thread; therefore, the user-perceived smoothness of operation is not affected by background tasks.

[0062] Furthermore, in this embodiment, the placeholder graphic element refers to a lightweight temporary graphical element created and displayed in the main thread when a second type of component (complex component) is dragged and placed. This graphic element has only low resolution and a simplified visual style (such as a gray rectangle or a placeholder label with the component name), and its rendering overhead is extremely low, completing drawing within milliseconds. The core function of the placeholder graphic element is to provide immediate feedback to the user that the operation has been received and the content is loading, avoiding unresponsive or blank interfaces.

[0063] Furthermore, data binding refers to the process of establishing a connection between a component and a backend data source (such as a real-time database, data acquisition channel, third-party API interface, etc.). For the second type of component, data binding involves multiple operations such as establishing a data subscription channel, registering data change callback functions, and initializing data structures, which is a prerequisite for the component to obtain and display real-time data. Style rendering refers to the process of converting the component's visual style definition (including but not limited to color, font, border, shadow, gradient, animation, etc.) into actual graphic output. For the second type of component, style rendering usually involves complex graphic drawing operations, such as multi-point interpolation and fitting of curves, drawing scales and pointers on dashboards, and texture mapping and lighting calculation of 3D models. Furthermore, a complete instance in the embodiments of this application refers to a component runtime object that has completed all data binding, style rendering, and graphic initialization operations. A complete instance has all preset visual details and complete data interaction capabilities, and is a completed state relative to placeholder primitives.

[0064] In this specific example, we will continue with the aforementioned building intelligent control engineering example. The engineer dragged three components consecutively in the same operation sequence: a device start / stop button (Type 1 component), a temperature trend graph (Type 2 component), and a 3D building model (Type 2 component). When the device start / stop button was dragged onto the canvas, the system recognized it as a Type 1 component, directly obtained an idle instance from the component pool, and completed the drawing and rendering in the main thread. The button immediately appeared on the canvas, and the engineer saw its complete appearance the instant the drag was released, with no perceptible delay.

[0065] Next, the engineer dragged the temperature trend chart onto the canvas. The system recognized it as a Type II component and quickly generated a gray rectangular placeholder graphic in the main thread, displaying it at the target location. The engineer's visual feedback was that the temperature trend chart had been occupied and was loading, with no interface lag. Simultaneously, the system executed the complete instantiation and loading of the temperature trend chart in a background thread, establishing a data binding channel with the temperature sensor, drawing the temperature curve, and initializing the axes and scale labels. After approximately 300 milliseconds, the background loading was complete, automatically replacing the gray placeholder graphic with the fully rendered temperature trend chart. The engineer then dragged the 3D building model onto the canvas. Again, a placeholder graphic was displayed first, and then the complete loading of the model was executed in a background thread, loading 3D mesh data, texture mapping, and performing lighting calculations. During the background loading process (approximately 1.5 seconds), the engineer could continue dragging other components, adjusting the layout, or scaling the canvas, with the main thread remaining consistently responsive. After 1.5 seconds, the complete instance of the 3D building model was loaded, automatically replacing the previous placeholder graphic. Throughout the entire process described above, the first type of component achieved immediate response, while the second type of component achieved instant feedback on operations and asynchronous content presentation. Engineers never experienced interface lag or freezing during the operation, and all operations received instant feedback.

[0066] Through steps 51 and 52 above, regardless of component complexity, users receive visual feedback within a very short time after dragging and dropping. First-type components directly display their complete content, while second-type components first display placeholder graphics. This instant feedback mechanism eliminates the uncertainty users experience when faced with a blank or frozen interface after an operation, significantly improving the smoothness of the interactive experience. Furthermore, in existing technologies, complex components complete all loading operations synchronously on the UI main thread. Continuous loading tasks create a task queue that blocks the main thread's event response, leading to a sharp drop in frame rate or even a freeze. This step completely decouples all time-consuming operations of complex components (data binding, style rendering, and graphics initialization) to a background thread. The main thread only handles lightweight placeholder graphic generation and final replacement operations, decoupling the loading of complex components from the main thread's response. Even if the user drags multiple complex components consecutively, each loading task executes in parallel on the background thread, and the main thread's responsiveness remains constant.

[0067] Furthermore, the method of performing data binding and style rendering operations of the target component in a background thread as mentioned in step 51 above can further include: Step 61: Obtain the current terminal's hardware performance parameters and current system resource utilization rate; In this application embodiment, hardware performance parameters are a set of quantitative indicators characterizing the computing power of the current terminal device, including but not limited to CPU clock speed and number of cores, GPU model and video memory capacity, and total system memory capacity. These parameters reflect the theoretical computing limit of the device in graphics rendering.

[0068] System resource utilization refers to the actual usage status of system resources at a given moment, including dynamic indicators such as CPU utilization, memory utilization, and GPU utilization. Unlike hardware performance parameters, which reflect "how much can be done," system resource utilization reflects how many available resources are currently available.

[0069] Step 62: Determine the target rendering quality level of the second type of component based on hardware performance parameters and system resource utilization. The rendering quality level includes a first quality level and a second quality level. The rendering accuracy and resource utilization of the second quality level are higher than those of the first quality level. Rendering quality level is the level of visual detail set by the system for the second type of component. Different quality levels correspond to different rendering parameter configurations, striking a trade-off between rendering precision and resource consumption. Higher quality levels offer richer visual details but consume more computational resources and time; lower quality levels offer less visual detail but faster rendering speed and lower resource consumption. In this step, the rendering quality levels include at least a first quality level (lower precision) and a second quality level (higher precision), with the second quality level offering higher rendering precision and resource consumption than the first quality level.

[0070] Step 63: If the target rendering quality level is the first quality level, perform rendering in a background thread by reducing the data sampling rate or reducing the texture resolution to generate a first rendering quality instance. Step 64: After the first rendering quality instance is rendered and the system resource utilization rate drops to the first preset threshold, the first rendering quality instance is upgraded to the second rendering quality instance.

[0071] In this specific example, we will continue with the aforementioned building intelligent control project example. An engineer is editing a monitoring dashboard on a low-spec industrial PC with weak GPU performance (low hardware performance parameters). At this point, the engineer drags a 3D building model component (a second-type component) onto the canvas.

[0072] First, the hardware performance parameters of the current terminal (GPU is an integrated graphics card with 512MB of video memory) and the current system resource utilization (CPU utilization 85%, memory utilization 75%) are obtained. After comprehensive judgment, it is determined that the current device performance is limited and the load is high, lacking sufficient resources to render the 3D model with full precision. Therefore, the target rendering quality level is set to the first quality level. Subsequently, the system performs rendering in a background thread by reducing the texture resolution—using a lower resolution (e.g., 256×256) texture version from the Mipmap chain to replace the original full resolution (e.g., 2048×2048) texture, generating a first rendering quality instance. This instance completes rendering in a short time (approximately 200 milliseconds) and replaces the previously displayed placeholder primitives. Engineers see a low-precision version of the 3D building model, where the model outline is clearly discernible, but the texture details are somewhat blurry.

[0073] Minutes later, the engineer closed other resource-intensive applications, and system resource usage dropped significantly (CPU utilization dropped to 40%, memory utilization dropped to 50%), falling below the first preset threshold (e.g., CPU utilization below 60% and memory utilization below 60%). Upon detecting this change, the system automatically triggered an upgrade operation, re-rendering the 3D architectural model in a background thread with full precision (using a 2048×2048 full-resolution texture), generating a second-quality rendering instance, and automatically replacing the low-precision version on the canvas. The engineer observed that the model texture went from blurry to clear, with a significant improvement in visual quality, and the entire upgrade process was completed in the background without interfering with the current editing operation.

[0074] As can be seen, in this embodiment, by monitoring hardware performance parameters and system resource utilization in real time, the system can proactively reduce the rendering precision of complex components when computing resources are scarce, ensuring that components can be loaded and rendered within an acceptable time, avoiding loading failures or long waits due to insufficient resources; when computing resources are abundant, it renders with full precision to guarantee visual quality. The first rendering quality instance is rendered quickly to ensure that users receive timely visual feedback; once system resources are sufficient, it is upgraded to the second rendering quality instance, achieving a smooth transition from usable to exquisite. What users perceive is a phased improvement in component quality, rather than the dilemma of either waiting a long time for full loading or always accepting low-quality rendering, as in existing solutions.

[0075] The present application will be explained and described below with reference to specific embodiments, which provide a method for rendering a configuration component pool for dynamic expansion and contraction of intelligent building control systems, such as... Figure 2 As shown, the steps of this method include: Step 201, Initialization and component classification modeling; Specifically, such as Figure 3 As shown, upon startup, the built-in component library is read, and the components are categorized and labeled according to their rendering complexity. Basic components (such as buttons, text labels, and simple icons) are defined, which have low rendering computation requirements; complex components (such as real-time trend charts, multi-axis dashboards, and 3D models) are defined, which have high rendering computation requirements. At the same time, an independent heat counter, instance queue, and priority level are established for each component type.

[0076] Step 202: Runtime heat statistics and dynamic expansion / shrinkage; Specifically, such as Figure 4 As shown, during user interaction, the system monitors drag-and-drop events in real time. Whenever a component is dragged and placed onto the canvas, the system records the component's ID and placement timestamp. The system calculates the component's usage frequency every fixed time window of 60 seconds. ( For the number of times it is placed, (For statistical duration).

[0077] Based on the calculated frequency The system categorizes components into three types and performs dynamic scaling: High frequency components ( ≥10 times / hour): If the resource is identified as a hot resource, the system will automatically expand the component pool and increase the number of pre-instances of this type of component to 3 to ensure that there is no need to wait for the instantiation process when dragging.

[0078] Intermediate frequency components (1≤ <10 times / hour): Maintain 1 instance in the pool.

[0079] Low-frequency components ( <1 time / hour): This is considered cold data. The system does not actively retain instances in the pool. Instead, it creates instances only when dragging and dropping for the first time and releases them after use.

[0080] Step 203, priority-based drag and drop with deep lazy loading; Specifically, such as Figure 5 As shown, when a user initiates a drag-and-drop action, the complexity level of the target component is first determined, and multi-level priority scheduling is executed: Basic component handling: If the target component is a basic component, an idle instance is directly called from the component pool and rendered to the canvas immediately.

[0081] Handling complex components: If the target component is complex, a deep lazy loading mode is activated: First, a placeholder is displayed on the canvas with a low resolution gray area to inform the user that the operation has been received, preventing the interface from becoming unresponsive. Then, asynchronous loading occurs, meaning the complete high-resolution instance is loaded simultaneously in a background thread, including time-consuming operations such as data binding and style rendering, without occupying the main UI thread. Finally, seamless replacement occurs, automatically replacing the placeholder on the canvas after the background instance has finished loading. This process completely solves the concurrency blocking problem when dragging and dropping multiple complex components.

[0082] Step 204, memory monitoring and intelligent eviction mechanism; Specifically, such as Figure 6 As shown, the background continuously monitors the memory usage of the current process. When detected When memory usage reaches ≥70%, the intelligent eviction mechanism is triggered. The system first filters out all "cold components" not in the component pool for recycling; if this is still insufficient, the component pool eviction process begins. The eviction strategy uses a time-weighted dual-dimensional algorithm: priority is given to removing component instances that have not been used for more than 5 minutes since the current time. If multiple candidates remain, the instance with the longest unused time in the history is removed. Instances that have just been used within the last 5 minutes are strictly prohibited from being removed. The eviction operation continues until memory usage drops to a minimum. Once the safe water level reaches ≤50%, the phase-out process will cease and normal operation will resume.

[0083] Step 205, Scenario-based pre-creation optimization; Specifically, such as Figure 7 As shown, when a user opens a new project file, the system parses the current interface's layout template and predicts the types of components that the page is likely to use. The system then uses a formula... Pre-create a corresponding number of component instances in the background and place them in the pool to further reduce the initial drag-and-drop latency.

[0084] Based on steps 201 to 205 above, resource bottlenecks are addressed through dynamic scaling, invalid memory is released through intelligent eviction, and rendering blocking is resolved through deep lazy loading. This achieves refined management of the entire lifecycle of configured components, improving the system's operational efficiency and stability in complex scenarios. Specifically, by dynamically adjusting the component pool capacity based on preset thresholds and real-time statistics of component usage frequency, the risk of resource allocation rigidity caused by improper fixed object pool size settings is eliminated. This dynamic balancing strategy enables the system to adapt to various business load changes, effectively suppressing memory jitter, reducing memory fragmentation, and ensuring stable operation even when handling complex visuals. Components are divided into basic and complex classes, and differentiated rendering strategies are implemented. Basic components are implemented with immediate response, while complex components are displayed as placeholders and loaded asynchronously and smoothly in the background, eliminating UI stuttering during concurrent loading of complex components and ensuring the smoothness of the main thread.

[0085] Corresponding to the above Figure 1 This application provides a component pool rendering device based on dynamic scaling in a building intelligent control system, such as... Figure 8 As shown, the device includes: The first processing module 802 is used to classify the components defined in the component library according to a preset rendering complexity threshold, wherein the classified component types include a first type of component and a second type of component. The second processing module 804 is used to monitor and record the call frequency of each type of component within a preset statistical period; The third processing module 806 is used to dynamically adjust the number of pre-instantiated components of each type in the component pool based on the comparison result between the call frequency and the preset frequency threshold. The component pool is used to cache instances created based on the component types defined in the component library. The fourth processing module 808 is used to respond to the drag and drop command of the component, obtain an idle instance corresponding to the target component type from the component pool, and perform rendering operations.

[0086] In an optional embodiment of this application, the first processing module in this application includes: The first marking unit is used to mark components whose computational rendering amount is less than a preset rendering complexity threshold as first type components, wherein the first type components include buttons, text labels and icons; The second marking unit is used to mark components whose computational rendering amount is greater than or equal to a preset rendering complexity threshold as second-type components. The second-type components include real-time trend charts, multi-axis dashboards, and 3D models.

[0087] In an optional embodiment of this application, the second processing module includes: The first processing unit is used to set the preset statistical period to a preset duration and to count the cumulative number of times each type of component is dragged and placed onto the canvas within the preset statistical period. The determination unit is used to determine the call frequency by the ratio of the cumulative number of times to the preset statistical period.

[0088] In an optional embodiment of this application, the third processing module includes: The second processing unit is used to determine that the corresponding component type is a high-frequency type when the call frequency is greater than or equal to the first frequency threshold, and to set the pre-instantiation quantity to the first preset value. The third processing unit is used to determine that the corresponding component type is a medium frequency type when the call frequency is less than the first frequency threshold and greater than or equal to the second frequency threshold, and to set the pre-instantiated quantity to the second preset value. The fourth processing unit is used to determine that the corresponding component type is a low-frequency type when the call frequency is less than the second frequency threshold, and to set the pre-instantiation quantity to zero. The first preset value is greater than the second preset value.

[0089] In optional embodiments of this application, the apparatus further includes: The fifth processing module is used to query the component dependency graph after dynamically adjusting the number of pre-instantiated components of each type in the component pool, and to determine the associated component types that are related to the high-frequency type components; wherein, the component dependency graph records the co-occurrence association degree between each component type; The sixth processing module is used to increase the number of pre-instantiated components of the associated component type in the component pool based on the co-occurrence correlation between the associated component type and the high-frequency component type when the associated component type is not a high-frequency component type.

[0090] In an optional embodiment of this application, the fourth processing module includes: The fifth processing unit is used to obtain an idle instance from the component pool and perform real-time rendering on the main thread when the target component is a first-type component. The sixth processing unit is used to generate placeholder primitives in the main thread when the target component is a second type component, and to perform data binding and style rendering operations of the target component in the background thread. After the rendering is completed, a complete instance is obtained, the placeholder primitives are replaced with the complete instance, and the memory resources occupied by the placeholder primitives are released.

[0091] In an optional embodiment of this application, the sixth processing unit performs the following steps: Obtain the current terminal's hardware performance parameters and current system resource utilization. Based on hardware performance parameters and system resource utilization, the target rendering quality level of the second type of component is determined. The rendering quality level includes a first quality level and a second quality level. The rendering accuracy and resource utilization of the second quality level are higher than those of the first quality level. When the target rendering quality level is the first quality level, rendering is performed in a background thread by reducing the data sampling rate or reducing the texture resolution to generate a first rendering quality instance. After the first rendering quality instance is completed and the system resource usage drops to the first preset threshold, the first rendering quality instance is upgraded to the second rendering quality instance.

[0092] like Figure 9 As shown in the figure, this application provides an electronic device, including a processor 911, a communication interface 912, a memory 913, and a communication bus 914, wherein the processor 911, the communication interface 912, and the memory 913 communicate with each other through the communication bus 914. Memory 913 is used to store computer programs; In one embodiment of this application, when the processor 911 executes the program stored in the memory 913, it implements the component pool rendering method based on dynamic expansion and contraction in the building intelligent control system provided in any of the aforementioned method embodiments. Its function is similar and will not be described again here.

[0093] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the component pool rendering method based on dynamic scaling in the building intelligent control system provided in any of the foregoing method embodiments.

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

[0095] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0096] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0097] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. 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 the invention. Therefore, the present invention 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 claimed herein.

Claims

1. A component pool rendering method based on dynamic scaling in a building intelligent control system, characterized in that, include: Based on a preset rendering complexity threshold, the components defined in the component library are classified, and the classified component types include first type components and second type components. Monitor and record the frequency of calls to each type of component within a preset statistical period; Based on the comparison result between the called frequency and the preset frequency threshold, the number of pre-instantiated components of each type in the component pool is dynamically adjusted, wherein the component pool is used to cache instances created based on the component types defined in the component library; In response to the drag-and-drop command of a component, an idle instance corresponding to the target component type is obtained from the component pool, and a rendering operation is performed.

2. The method according to claim 1, characterized in that, Based on a preset rendering complexity threshold, the components defined in the component library are categorized, including: Components whose computational rendering amount is less than the preset rendering complexity threshold are marked as the first type of component, wherein the first type of component includes buttons, text labels and icons; Components whose computational rendering amount is greater than or equal to the preset rendering complexity threshold are marked as the second type of component, wherein the second type of component includes real-time trend charts, multi-axis dashboards and 3D models.

3. The method according to claim 1, characterized in that, Monitor and record the call frequency of each type of component within a preset statistical period, including: Set the preset statistical period to a preset duration, and count the cumulative number of times each type of component is dragged and placed onto the canvas within the preset statistical period; The ratio of the cumulative number of times to the preset statistical period is determined as the call frequency.

4. The method according to claim 1, characterized in that, Based on the comparison between the called frequency and the preset frequency threshold, the number of pre-instantiated components of each type in the component pool is dynamically adjusted, including: If the frequency of being called is greater than or equal to the first frequency threshold, the corresponding component type is determined to be a high-frequency type, and the number of pre-instantiated components is set to the first preset value. If the called frequency is less than the first frequency threshold and greater than or equal to the second frequency threshold, the corresponding component type is determined to be a mid-frequency type, and the pre-instantiation quantity is set to the second preset value. If the frequency of being called is less than the second frequency threshold, the corresponding component type is determined to be a low-frequency type, and the number of pre-instantiations is set to zero. Wherein, the first preset value is greater than the second preset value.

5. The method according to claim 4, characterized in that, The method further includes: After dynamically adjusting the number of pre-instantiated components of each type in the component pool, the component dependency graph is queried to determine the associated component types that are related to the high-frequency type components; wherein, the component dependency graph records the co-occurrence correlation between each component type; If the associated component type does not belong to the high-frequency type component, the number of pre-instantiated instances of the associated component type in the component pool is increased based on the co-occurrence correlation between the associated component type and the high-frequency type component.

6. The method according to claim 1, characterized in that, Performing rendering operations includes: When the target component is a component of the first type, after obtaining an idle instance from the component pool, real-time rendering is performed in the main thread; When the target component is the second type of component, a placeholder graphic is generated in the main thread, and the data binding and style rendering operations of the target component are performed in the background thread. After the rendering is completed, a complete instance is obtained, and the placeholder graphic is replaced with the complete instance and the memory resources occupied by the placeholder graphic are released.

7. The method according to claim 6, characterized in that, The data binding and style rendering operations of the target component are performed in a background thread, including: Obtain the current terminal's hardware performance parameters and current system resource utilization. Based on the hardware performance parameters and the system resource utilization rate, the target rendering quality level of the second type of component is determined, wherein the rendering quality level includes a first quality level and a second quality level, and the rendering accuracy and resource utilization of the second quality level are higher than those of the first quality level. When the target rendering quality level is the first quality level, rendering is performed in the background thread by reducing the data sampling rate or reducing the texture resolution to generate a first rendering quality instance. After the first rendering quality instance is completed and the system resource utilization rate drops to a first preset threshold, the first rendering quality instance is upgraded to a second rendering quality instance.

8. A component pool rendering device based on dynamic scaling in a building intelligent control system, characterized in that, include: The first processing module is used to classify the components defined in the component library according to a preset rendering complexity threshold. The classified component types include first type components and second type components. The second processing module is used to monitor and record the call frequency of each type of component within a preset statistical period; The third processing module is used to dynamically adjust the number of pre-instantiated components of each type in the component pool according to the comparison result between the called frequency and the preset frequency threshold. The component pool is used to cache instances created based on the component types defined in the component library. The fourth processing module is used to respond to the drag-and-drop instruction of the component, obtain an idle instance corresponding to the target component type from the component pool, and perform a rendering operation.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory is used to store computer programs; the processor is used to execute the computer programs to implement the component pool rendering method based on dynamic scaling in the building intelligent control system according to any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the component pool rendering method based on dynamic scaling in the building intelligent control system according to any one of claims 1-7.

Images