A state data aggregation method

Abstract

The application relates to a state data aggregation method, comprising the following steps: S1, uniformly parsing original messages by a system and constructing the original messages into standardized state units; S2, continuously collecting and analyzing multidimensional data by the system to generate an aggregation control index for representing a current system running state; S3, dynamically determining whether the state units are aggregated and determining corresponding aggregation granularity according to the aggregation control index and attributes of the state units; and S4, grouping relevant state units according to the determined aggregation granularity and preset aggregation rules and generating corresponding aggregated state units. The application parses original messages into state units and generates aggregated state units based on multidimensional conditions, so that the system takes the aggregated state as a basic unit for processing and scheduling, avoids processing each message separately, significantly reduces the processing times in a high-frequency message arrival scenario, and improves the processing efficiency of the system in a high-load scenario.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for aggregating state data. Background Technology

[0002] In everyday applications of wearable devices such as smartwatches and health monitoring terminals, the devices continuously receive status information from multi-source heterogeneous data streams. This status data covers types such as application notifications, system events, and sensor feedback. The arrival patterns of status data exhibit significant irregularities: their frequency fluctuates dramatically, potentially experiencing explosive influxes in a short period or remaining in a low-activity state for extended periods; data sources are widely distributed across multiple application domains, including social, health, and navigation; simultaneously, the data exhibits strong temporal continuity, with subsequent states often depending on the context of previous states.

[0003] When users are stationary or have good interaction conditions, existing processing mechanisms rely on users actively viewing each item or manually triggering management operations, which is acceptable in normal scenarios. However, when users are engaged in activities such as running, cycling, or driving, frequent body movements significantly limit their input capabilities, and their attention is occupied by the main activity, making it difficult to effectively allocate attention to device interaction. Traditional processing models that rely on user responses therefore fail. In such constrained states, if the device continues to process each status data item at its original granularity, it will lead to a rapid accumulation of status messages, continuously high loads on system computing resources such as processors and memory, resulting in slow device response, delayed execution of critical functions, and accelerated battery consumption, ultimately threatening the operational stability and battery life of the terminal device.

[0004] While existing technical solutions attempt to alleviate the problem through visual folding or simplified interaction, these improvements only focus on superficial user interface optimizations and fail to address the underlying organizational logic and processing mechanisms of state data. In particular, they lack a mechanism that can sense dynamic conditions such as limited input or strained system resources in real time and intelligently adjust data aggregation strategies accordingly. Consequently, they cannot achieve automatic grouping and efficient management of state data in motion scenarios to balance processing load and user experience requirements. Summary of the Invention

[0005] Therefore, the purpose of this invention is to provide a state data aggregation method that can avoid state data accumulation, reduce system resource consumption, and improve device response speed and operational stability.

[0006] This invention provides a state data aggregation method, comprising the following steps: S1. The system performs unified parsing of the original message and constructs it into standardized state units; S2. The system continuously collects and analyzes multi-dimensional data, which provides the system with real-time operating context information, enabling the system to intelligently determine whether the current operation input that needs to be aggregated is limited or the resources are limited. S3. The system dynamically determines whether to aggregate state units and the granularity of the aggregation based on multi-dimensional data and the attributes of the message itself. S4. The system groups the relevant state units according to the determined aggregation granularity and preset rules. If the groups meet the aggregation conditions, the system merges them into an aggregated state unit and uses the aggregated state unit to replace the original state units in the set for subsequent processing. S5. When the user's input state or the system resource state returns to normal, the system will dynamically reduce the aggregation granularity according to the preset release conditions, allowing detailed information to be displayed or processed.

[0007] The state data aggregation method of the present invention parses the original message into state units and generates aggregated state units based on multi-dimensional conditions, so that the system uses the aggregated state as the basic unit for processing and scheduling, avoiding processing each message one by one, thereby significantly reducing the number of processing times in scenarios where high-frequency messages arrive.

[0008] In one embodiment of the present invention, the system initialization and multi-channel data acquisition architecture are further performed in step S1. When the terminal device starts, the message receiving module, the status management module, the data acquisition module and the aggregation decision module are initialized. At the same time, a dedicated data acquisition channel is configured, including a message attribute acquisition channel, a user behavior feature acquisition channel and a system resource status acquisition channel, for the effective acquisition of multi-dimensional data.

[0009] In one embodiment of the present invention, the method further includes a message temporary receiving identifier allocation mechanism in step S1. When the terminal device receives an original message, it allocates a temporary receiving identifier to the original message and parses the message attribute data of the original message to obtain at least one of the message type, source identifier, priority, and arrival timestamp.

[0010] In one embodiment of the present invention, step S2 further includes a refined collection mechanism for user behavior characteristics and system resource status, acquiring user behavior characteristic data within a preset time window, the user behavior characteristic data being used to characterize the user's operational activity level within the time window; simultaneously, collecting system resource status data at the message arrival time or within the most recent sampling period, the system resource status data being used to characterize the current operating load of the terminal device.

[0011] In one embodiment of the present invention, step S3 further includes performing format standardization processing and storage management of state units. Based on message attribute data, user behavior feature data, system resource status data and time attributes, a corresponding state unit is constructed, and format standardization processing is performed on the state unit. The state unit is then stored in the state management module to support subsequent aggregation processing.

[0012] In one embodiment of the present invention, step S3 further includes loading an aggregation determination triggering mechanism and a strategy configuration. When a new state unit is detected to be generated, or when user behavior characteristics or system resource status are detected to exceed a preset threshold, the aggregation determination process is triggered. The preset threshold parameters are loaded from the strategy configuration. The threshold parameters include at least a system resource threshold, a user behavior characteristic threshold, an aggregation trigger threshold, and a priority exemption rule parameter.

[0013] In one embodiment of the present invention, step S3 further includes determining whether the terminal device is in a resource-limited state based on a threshold of system resources; determining whether the terminal device is in an operation input-limited state based on a threshold of user behavior characteristics; and marking state units whose priority meets the exemption conditions so that they do not participate in subsequent aggregation processing.

[0014] In one embodiment of the present invention, step S4 further includes storing and guiding the association between state units and aggregation granularities. Based on the system resource status determination results and user behavior feature determination results, and combined with the arrival number or arrival rate of state units, a corresponding aggregation granularity is determined for each state unit that has not been exempted. A correspondence between state units and aggregation granularities is generated and stored in the state management module to guide the subsequent aggregation execution process.

[0015] In one embodiment of the present invention, step S4 further includes grouping the state units according to the aggregation granularity and preset grouping rules. The grouping rules include at least the message type dimension, message source dimension, and time interval dimension to form multiple state unit sets.

[0016] In one embodiment of the present invention, step S4 further includes merging the set of state units into an aggregated state unit when a certain set of state units meets the aggregation condition, and using the aggregated state unit to replace the state units in the set for subsequent processing; when a new state unit meets the condition of being merged into an existing aggregated state unit, updating the corresponding aggregated state unit is performed.

[0017] The state data aggregation method of the present invention has the following advantages compared with the prior art: First, this application parses the original message into state units and generates aggregated state units based on multi-dimensional conditions, so that the system uses the aggregated state as the basic unit for processing and scheduling, avoiding processing each message one by one, thereby significantly reducing the number of state processing operations in scenarios where high-frequency messages arrive.

[0018] Second, by dynamically determining the aggregation granularity level for state units and adjusting it based on changes in multi-dimensional data during operation, the system can automatically change the state processing granularity according to the operating status of terminal devices, thereby improving processing efficiency and adaptability under resource-constrained conditions.

[0019] Third, the aggregation decision-making process does not rely on user input, but automatically determines the status based on system resource status, user behavior characteristics, and message attributes, enabling terminal devices to effectively manage message status even when the user is in motion or when input is restricted. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of the state data aggregation method of the present invention. Detailed Implementation

[0022] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0023] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] It should be noted that the following description covers various aspects of embodiments within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0025] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0026] Additionally, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that practice can be carried out without these specific details.

[0027] Traditional wearable devices continuously receive high-frequency status data when the user is in motion or when input is limited. If a line-by-line or full-data processing method is still used, data will accumulate rapidly, increasing the system's processing load and potentially causing frequent status updates and resource consumption, thus affecting the device's operational stability and power consumption. Existing technologies primarily improve information display or interaction methods, failing to address the processing pressure caused by the high frequency of status data arrivals under limited input conditions at the level of status data organization and processing mechanisms.

[0028] To address this issue, the present invention provides a state data aggregation method, aiming to solve the aforementioned technical problems. The method includes the following steps: S1. The system performs unified parsing of the original messages and constructs them into standardized state units. The parsing of the original messages can employ a predefined fixed parser, performing hard-coded parsing for each known message format to extract the message content. The construction of state units can simply map the parsed data fields to a general data structure; for example, storing the text content of all messages uniformly in a string field without deeper structuring. For instance, when the system receives a message from a specific application, it can extract the message title and brief content based on the application's fixed message template and encapsulate them into a general state unit containing "title" and "content" fields.

[0029] S2. The system continuously collects and analyzes multi-dimensional data. This multi-dimensional data provides the system with real-time operational context information, enabling it to intelligently determine whether the current state is characterized by limited input or resource constraints for operations requiring aggregation processing. Multi-dimensional data collection can be achieved by periodically polling the system interface to obtain single-dimensional system operating parameters, such as reading CPU utilization at fixed time intervals. Analysis of the collected data can employ simple threshold comparison methods; for example, when CPU utilization exceeds a certain fixed percentage, it is determined to be a resource-constrained state. Similarly, the system can check the battery level of terminal devices every minute; if the battery level falls below a certain fixed percentage, it is determined to be a resource-constrained state, and based on this, it decides whether status data aggregation is necessary.

[0030] S3. The system dynamically determines whether to aggregate state units and the granularity of aggregation based on multi-dimensional data and the attributes of the messages themselves. The dynamic decision-making for aggregation can be based on a preset static rule table, which determines whether to aggregate based on simple combinations of multi-dimensional data (e.g., considering only system load) and single attributes of the message (e.g., message type). The dynamic determination of the aggregation granularity can adopt a fixed-level granularity division; for example, only providing "full aggregation" and "no aggregation" modes, without supporting finer intermediate granularity adjustments. For example, when the system detects a resource-constrained state, all non-urgent messages are determined to be aggregated, and the aggregation granularity is set to only display the number of messages.

[0031] S4. The system groups relevant state units according to the determined aggregation granularity and preset rules. Groups that meet the aggregation conditions are merged into a single aggregated state unit, which replaces the original state units in the set for subsequent processing. State unit grouping can be based on a single preset rule; for example, all state units from the same application are grouped together. Aggregation conditions can be determined based on a simple quantity threshold; for example, when the number of state units in a group reaches a preset value, the aggregation condition is met. Merging aggregated state units can involve simply concatenating the titles of all state units within a group to form a summary title, which is then used to replace the original unit. For example, the system groups all message state units from "Social Application A" into one group. When the number of messages in that group reaches 5, the system merges them into a single aggregated state unit, whose title is displayed as "Social Application A has 5 new messages."

[0032] S5. When the user's input state or system resource state returns to normal, the system dynamically reduces the aggregation granularity according to preset release conditions, allowing detailed information to be displayed or processed. The release conditions can be based on a single, preset system state indicator; for example, when the system CPU utilization is below a certain fixed threshold for a continuous period, aggregation is triggered. The dynamic reduction in aggregation granularity can be a direct switch from a fully aggregated mode to a completely non-aggregated mode, displaying all detailed information at once without gradual granularity adjustments. For example, when the system detects that the user has performed several consecutive touch operations on the terminal device and the system resource load is low, the system determines that the user's input state has returned to normal, thereby releasing all aggregations and displaying all state units in their original detailed information form.

[0033] In this context, raw messages refer to the unprocessed initial data received by the terminal device from external data sources. This data may include notifications, system events, or application status information, and typically exists in various formats and structures. A state unit refers to a data structure that has undergone unified parsing and standardization by the system. It carries the core information of the raw message and is stored, managed, and processed in a unified format. Multi-dimensional data refers to various types of data continuously collected and analyzed by the system, such as user behavior characteristic data and system resource status data. This data collectively provides the system with real-time operational context information to assess the current working environment of the terminal device. Operation input-restricted state refers to a situation where the user's ability to interact with the terminal device is limited due to physical activity, distraction, or other external factors. Resource-restricted state refers to a situation where the terminal device's processing power or available resources are limited due to internal factors such as high processor load, large memory usage, or insufficient battery power. Aggregation granularity refers to the level of fineness in the aggregation processing of state units. It determines how many or what types of state units will be merged into a single aggregated state unit, and the level of detail of the information displayed after aggregation. An aggregated state unit refers to a single logical unit formed by merging multiple related state units according to preset rules. It represents a summary of the original set of state units and replaces the original units in subsequent processing. The release condition refers to preset rules or thresholds used by the system to determine when to reduce the aggregation granularity and restore detailed information display, such as when user input returns to normal or system resource status improves.

[0034] This application standardizes the raw messages and combines multi-dimensional data to determine whether operation input is restricted or resource-constrained. It dynamically determines the aggregation and granularity of state units, then groups and merges related state units into aggregated state units. This effectively reduces the processing pressure caused by the high frequency of state data arrivals under conditions of user movement or restricted operation input. As a result, it reduces the system processing load, avoids frequent state updates and resource consumption, improves the operational stability and power consumption of terminal devices, and adaptively displays detailed information when the state returns to normal, thus optimizing the user experience. In the above embodiments of this application, a state data aggregation method is proposed to automatically manage and aggregate state data under conditions of limited operational input. However, in the process of constructing standardized state units in step S1, without a dedicated initialization mechanism and an efficient data acquisition architecture, multi-dimensional data acquisition may be incomplete, delayed, or chaotic, thereby affecting the accuracy of subsequent aggregation decisions and system processing efficiency.

[0035] In response, this application further proposes a system initialization and multi-channel data acquisition architecture in step S1. When the terminal device starts up, the message receiving module, status management module, data acquisition module, and aggregation decision module are initialized. At the same time, dedicated data acquisition channels are configured, including message attribute acquisition channel, user behavior feature acquisition channel, and system resource status acquisition channel, for the effective acquisition of multi-dimensional data.

[0036] Specifically, the system initialization and multi-channel data acquisition architecture refers to establishing a complete data acquisition system in the early stages of system operation to ensure smooth subsequent data processing. Its role is to provide a stable and efficient data input foundation for the entire state data aggregation method. This architecture can instantiate modules and establish channels when the terminal device starts up by loading a preset configuration file or executing a specific startup script; alternatively, an on-demand initialization strategy can be adopted, where initialization is performed only when a module or channel is needed for the first time. However, to ensure timely data acquisition, this is usually completed during the system startup phase.

[0037] When the terminal device starts up, the message receiving module, state management module, data acquisition module, and aggregation decision module are initialized. This ensures that all core functional modules related to state data processing are ready before the terminal device begins normal operation, avoiding data loss or processing delays due to unloaded modules during runtime. This can be achieved by the operating system or application framework automatically calling pre-registered initialization functions when it detects a terminal device startup event, sequentially creating and configuring instances of the message receiving module, state management module, data acquisition module, and aggregation decision module; alternatively, a master control module or starter can be used to start and verify the running status of these core modules one by one according to a predetermined order and dependencies, ensuring they can work together normally. Simultaneously, dedicated data acquisition channels are configured, including: message attribute acquisition channels, user behavior feature acquisition channels, and system resource status acquisition channels. By setting independent acquisition paths for different types of data, mutual interference between data can be effectively avoided, improving the efficiency and accuracy of data acquisition and facilitating subsequent independent processing and management of data from different dimensions. For example, a message queue or event bus-based mechanism can be used to allocate an independent queue or topic for each data type. The corresponding acquisition module publishes data to the corresponding channel, while the processing module subscribes to data from the corresponding channel. Alternatively, different data interfaces and protocols can be defined, allowing message attributes, user behavior characteristics, and system resource status data to be transmitted and stored through their respective independent APIs or data streams, thus forming logically independent channels. The ultimate goal of all the above initialization and configuration work is to effectively acquire multi-dimensional data, aiming to ensure that the system can comprehensively, timely, and accurately obtain all the key information needed for state aggregation decisions, including the attributes of the message itself, the user's current operating status, and the operating load of the terminal device.

[0038] Through the above technical solution, this application completes the initialization of key modules and the configuration of the multi-channel data acquisition architecture during the terminal device startup phase, thus laying a solid foundation for subsequent state data aggregation processing. Specifically, system initialization ensures that core functional modules such as the message receiving module, state management module, data acquisition module, and aggregation decision module are in a ready state at the beginning of device operation, avoiding data processing interruptions or inefficiencies caused by module loading delays during runtime. Simultaneously, by configuring dedicated message attribute acquisition channels, user behavior feature acquisition channels, and system resource status acquisition channels, independent, parallel, and efficient acquisition of data from different dimensions is achieved, effectively avoiding data confusion and acquisition bottlenecks, and ensuring the comprehensiveness and real-time nature of multi-dimensional data. Therefore, the system can obtain accurate and timely runtime context information, making the judgment of restricted operation input or resource-restricted states in subsequent step S2 more precise, and providing reliable data support for dynamically determining whether state units should be aggregated and the aggregation granularity in step S3, significantly improving the robustness and decision accuracy of the entire state data aggregation method.

[0039] In some of the solutions mentioned above in this application, the original message is uniformly parsed and constructed into a standardized state unit. However, in this process, there is a lack of a temporary identifier allocation and attribute data parsing mechanism for the original message, which may lead to identifier conflicts or attribute missingness during message processing, affecting the accuracy and efficiency of subsequent aggregation.

[0040] In this regard, this application further proposes that in step S1, a temporary message receiving identifier allocation mechanism is implemented. When the terminal device receives an original message, a temporary receiving identifier is allocated to the original message, and the message attribute data of the original message is parsed to obtain at least one of the following: message type, source identifier, priority, and arrival timestamp.

[0041] Specifically, this temporary message receiving identifier allocation mechanism aims to provide a unique, temporary identification tag for each raw message received by the system. Its core function is to ensure that, even when multiple messages with similar content arrive simultaneously, the system can accurately distinguish and track the lifecycle of each message, avoiding confusion and duplicate processing. This mechanism can be implemented using a global counter or sequence generator. Each time a new message is received, the counter increments, and the current count value is assigned as a temporary receiving identifier to that message. Alternatively, it can be generated using a hash algorithm combining timestamps and the device's unique ID. For example, the message's precise arrival timestamp can be combined with the terminal device's MAC address or serial number, and then a hash function can be used to generate a highly unique identifier. Assigning temporary receiving identifiers to raw messages is the concrete execution of this mechanism, ensuring that each raw message obtains its unique identifier at the initial stage of entering the system processing flow. This is crucial for accurate message tracking and management in subsequent stages such as state unit construction, aggregation judgment, and deaggregation. When the message receiving module captures a new raw message data packet, it can immediately call the identifier allocation service, which generates a unique identifier and binds it to the metadata of the raw message, such as storing it in the data structure of a message object; or, it can be implemented at the entry point of the message queue, where the queue manager or a dedicated preprocessing component is responsible for attaching a unique temporary receiving identifier to the raw message when it is placed in the queue to be processed, and then passing it to the subsequent parsing module.

[0042] Simultaneously, the system parses the message attribute data of the original message. This step aims to extract the inherent, structured attribute information from the raw format of the original message. These attributes are the foundation for understanding message content, classifying messages, assessing message importance, and making subsequent aggregation decisions. This can be achieved through predefined parsers or adapters. For original messages from different sources or in different formats, the system configures corresponding parsing rules (e.g., regular expressions, JSON parsers, XML parsers, etc.) to accurately extract the required attribute fields from the message body. Alternatively, machine learning or natural language processing techniques can be used. For unstructured or semi-structured original messages, the system can train models to identify and extract key information, mapping it to standardized message attribute data. Through parsing, the system can obtain at least one of the following: message type, source identifier, priority, and arrival timestamp. This is the specific output of message attribute data parsing, providing key input parameters for subsequent state unit construction and aggregation decisions. These attributes each carry different semantic information, collectively supporting the system's comprehensive understanding and processing of messages. During the parsing process, the system extracts specific field values ​​from the original message and assigns them to the corresponding message type, source identifier, priority, and arrival timestamp variables according to preset field mapping rules. For some attributes, such as priority, it may be necessary to look up a table or infer from the message content. For example, priority may be dynamically assigned based on the message keywords or the importance of the sender. The arrival timestamp is usually automatically recorded by the system when it receives the message.

[0043] By assigning temporary receiving identifiers to the original messages through the above technical solutions, each message has a unique identity from the moment it is received, effectively avoiding identifier conflicts or confusion that may occur in subsequent processing, thereby improving the accuracy of message tracking. Simultaneously, by parsing and extracting key attribute data such as message type, source identifier, priority, and arrival timestamp in the early stages, the completeness and standardization of the information required for state unit construction are ensured, avoiding the impact of missing attributes on subsequent aggregation decisions. Therefore, the system can more reliably construct standardized state units based on accurate and complete message information, providing a solid data foundation for subsequent aggregation decisions, thus significantly improving the accuracy of state data aggregation and overall processing efficiency. For example, message type can guide classification aggregation, source identifier can be used for aggregation strategies based on specific sources, priority can be used for exemption judgment, and arrival timestamp provides a precise basis for time-window-based aggregation, making the entire aggregation process more intelligent and efficient.

[0044] This application also includes, in step S2, a refined collection mechanism for user behavior characteristics and system resource status, to obtain user behavior characteristic data within a preset time window, which is used to characterize the user's operational activity level within the time window; at the same time, system resource status data is collected at the message arrival time or within the most recent sampling period, which is used to characterize the current operating load of the terminal device.

[0045] Specifically, this refined collection mechanism for user behavior characteristics and system resource status aims to ensure a more detailed and systematic collection process through a specially designed data acquisition method. This avoids the potential for general collection methods to miss crucial details, thus providing an accurate and reliable data foundation for determining whether a terminal device is under operational input or resource constraints. For example, a dedicated data collection agent can be integrated at the terminal device's operating system level. This agent can monitor and record user interactions on the screen, such as touch, swipe, and key presses, as well as system performance indicators such as CPU usage, memory consumption, network bandwidth, and battery temperature in real time.

[0046] To acquire user behavior feature data within a preset time window, this technology aims to capture user actions within a continuous time period (i.e., the preset time window), rather than focusing solely on instantaneous values. This provides a more stable reflection of the overall trend of user activity and offers a more reliable basis for determining whether input is restricted. For example, the system can maintain a circular buffer, continuously recording all user interaction events (such as touch counts, swipe distances, key press frequencies, etc.) over the past N seconds (e.g., N=5 seconds, 10 seconds, or 30 seconds), and perform statistical analysis on the data in the buffer when needed to calculate user activity metrics. Alternatively, the terminal device can periodically (e.g., every second) sample user interaction events and store these sampled data in a sliding window. When user behavior feature data is needed, the system aggregates and calculates the data within the sliding window, such as calculating the average number of interactions or interaction intensity per unit time.

[0047] User behavior feature data is used to characterize the user's operational activity level within a time window. This technical feature clarifies the core role of user behavior feature data: quantifying the frequency and intensity of user interactions within a specific time period, thereby directly linking it to the user's current interactive capabilities and enabling the system to accurately identify whether the user is in a scenario where operational input is limited. Operational activity level can be characterized by calculating indicators such as the average number of touches, the average speed of swipe operations, the average frequency of key presses, or the total number of interaction events generated per unit time within a preset time window. For example, when the number of touches per unit time is below a certain threshold, the user's operational activity level can be considered low. Furthermore, multiple user behavior indicators can be combined; for example, different weights can be assigned to touch events, swipe events, and voice input events, and then a weighted average or comprehensive score can be calculated to more comprehensively reflect the user's operational activity level within the time window.

[0048] Simultaneously, the system collects system resource status data at the time of message arrival or within the most recent sampling period. This technical feature aims to select appropriate times to collect system resource status data, ensuring the data's real-time performance is synchronized with the current system status and avoiding misjudgments due to outdated data, thereby supporting accurate assessment of the terminal device's operating load. For example, when a new message arrives at the terminal device, the system immediately triggers a system resource status collection, obtaining data such as current CPU utilization, memory free space, and network bandwidth usage. Alternatively, the system can set a fixed sampling period (e.g., every 100 milliseconds or per second) to periodically collect and update system resource status data. When it is necessary to determine the system resource status, the most recently sampled data is directly read.

[0049] Ultimately, system resource status data is used to characterize the current operating load of terminal devices. This technical feature clarifies the core role of system resource status data: providing real-time load indicators to support accurate assessment of the current operating load of terminal devices, thus providing a reliable basis for determining whether terminal devices are in a resource-constrained state. Operating load can be characterized by single or combined indicators such as CPU utilization, memory usage, disk I / O rate, network throughput, battery temperature, or power consumption. For example, when CPU utilization consistently exceeds a certain threshold, the terminal device can be considered to be under high load. Furthermore, a comprehensive evaluation of multiple system resource indicators can be conducted, such as by weighted averaging of CPU, memory, and network indicators, or by using machine learning models for integrated judgment, to more comprehensively reflect the overall operating load of the terminal device.

[0050] Through the above technical solution, this application solves the problem of inaccurate status judgment caused by coarse data collection by establishing a refined collection mechanism for user behavior characteristics and system resource status, thereby improving the reliability of aggregation decisions. Specifically, a specially designed data acquisition method ensures a more detailed and systematic collection process, avoiding the shortcomings of general collection methods that may miss key details. User behavior characteristic data within a preset time window is acquired. Based on the preset time window, user operation behavior is captured over a continuous period, rather than instantaneous values. This more stably reflects the overall trend of operational activity, providing a reliable basis for judging the state of restricted operation input. User behavior characteristic data is directly related to user interaction capabilities, enabling the system to accurately identify scenarios with restricted operation. Simultaneously, system resource status data is collected at the message arrival time or within the most recent sampling period. Selecting message arrival or the most recent period as the collection time ensures that the data is real-time and synchronized with the current system status, avoiding misjudgments caused by outdated data. System resource status data provides real-time load indicators, supporting accurate assessment of resource-constrained states. The synergistic effect of these refined data collection and timing-specific data acquisition features lays a solid foundation for multi-dimensional data analysis, enabling the system to more accurately and timely determine whether the current state is one where the input for aggregation processing is limited or resources are limited. This optimizes the subsequent aggregation decision-making process and improves the overall efficiency and user experience of the state data aggregation method. In the above-described embodiments of this application, a mechanism is proposed to dynamically determine whether state units should be aggregated and the granularity of aggregation based on multi-dimensional data. However, in its implementation, the inconsistent format of state units may lead to inaccurate aggregation decisions, and the lack of effective storage management may reduce the system's processing efficiency, thereby affecting the reliability and overall performance of subsequent aggregation operations.

[0051] In response, this application further proposes that in step S3, the format standardization processing and storage management of the state unit be performed. Based on message attribute data, user behavior feature data, system resource status data and time attributes, the corresponding state unit is constructed, and the format standardization processing of the state unit is performed. The state unit is then stored in the state management module to support subsequent aggregation processing.

[0052] Specifically, the standardization of state unit formats and storage management aims to ensure that all state data to be aggregated has a unified structure and efficient access methods. Format standardization can be achieved by defining a unified data schema or protocol, for example, converting all state units into a preset JSON or XML format containing fixed fields and data types, or mapping raw data from different sources to a unified internal representation using a data converter. Storage management can employ various technologies, such as using in-memory databases (e.g., Redis) for high-speed caching to support fast read and write operations, or using persistent storage systems (e.g., relational databases or NoSQL databases) for long-term storage and indexing to ensure data reliability and retrieval.

[0053] Message attribute data describes the basic characteristics of the original message. For example, it may include message type (e.g., notification, warning), source identifier (e.g., application ID, device ID), priority (e.g., high, medium, low), and arrival timestamp. These attributes provide basic identification and classification information for state units. User behavior characteristic data reflects the level of user interaction with the terminal device. For example, it may include the number and frequency of user touches, swipes, and key presses within a preset time window, or it may combine data from sensors such as accelerometers and gyroscopes to determine whether the user is in motion. System resource status data characterizes the current operating load of the terminal device. For example, it may include real-time indicators such as CPU utilization, memory usage, battery level, network bandwidth, or storage space. Time attributes record the generation or arrival time of the state unit. For example, it may include the creation timestamp or last update timestamp of the state unit, which is crucial for time-series analysis and the definition of aggregation windows.

[0054] Based on the aforementioned message attribute data, user behavior feature data, system resource status data, and time attributes, the system constructs corresponding state units. The construction process integrates this multi-dimensional data into a single logical entity. For example, a data structure (such as a class or struct) is defined, with these attributes used as its fields, or represented using key-value pairs or JSON objects. Subsequently, the constructed state units undergo format standardization processing to ensure all state units have a unified structure and data type, eliminating heterogeneity. This is achieved by applying predefined conversion rules and data cleaning algorithms to convert raw data of different formats into a unified internal representation, or by using data schema validation tools to check whether the state units conform to preset format specifications. Finally, the format-standardized state units are stored in the state management module. The state management module can be a centralized storage service responsible for CRUD operations on state units, or a distributed caching system that stores state units using hashing or range partitioning methods and provides high-concurrency access interfaces to support subsequent aggregation processing.

[0055] Through the above technical solutions, this application effectively solves the problem of inaccurate aggregation decisions caused by inconsistent state unit formats and improves system processing efficiency. By constructing state units based on multi-dimensional data, it ensures that each state unit contains comprehensive contextual information, providing an accurate data foundation for subsequent aggregation decisions. Performing format standardization processing on state units unifies the structure and representation of state units from different sources or types, eliminating data heterogeneity, thereby reducing errors and delays in the aggregation process and improving processing reliability. Storing state units in the state management module achieves orderly organization and efficient access to state units, enabling the aggregation decision module to quickly retrieve and process relevant state units, significantly improving system response speed and overall processing efficiency. These measures work synergistically to ensure the optimization of state unit format and storage, directly improving the accuracy, reliability, and efficiency of aggregation operations, and providing a solid data foundation for aggregation processing under conditions of limited input or resources. Furthermore, in step S3, the aggregation determination triggering mechanism and policy configuration loading are performed. When a new state unit is detected to be generated, or when user behavior characteristics or system resource status are detected to exceed a preset threshold, the aggregation determination process is triggered; and preset threshold parameters are loaded from the policy configuration. The threshold parameters include at least system resource threshold, user behavior characteristic threshold, aggregation triggering threshold, and priority exemption rule parameters.

[0056] Specifically, this aggregation decision triggering mechanism aims to initiate the aggregation decision process of state units, ensuring that the system can respond promptly to changes in the external environment or internal state. It can be implemented through a dedicated monitoring service module, which continuously listens to system events and data streams, and sends a trigger command to the aggregation decision module via a message queue or event bus when specific conditions are met. Alternatively, this mechanism can be integrated into the state management module, where its internal logic directly calls the aggregation decision function when a state unit is stored or updated. Policy configuration loading provides configurable parameters and rules for this mechanism, enabling it to adapt to different operating scenarios and aggregation requirements. For example, policy configuration can be stored and loaded via XML, JSON files, or a database, and dynamically updated during system startup or runtime.

[0057] When a new state unit is detected, this is a fundamental trigger condition for the aggregation decision process, ensuring that any newly arrived and standardized state data can be included in the aggregation consideration. This can be achieved by issuing a "new state unit generated" event immediately after the state management module receives and stores the new state unit, which is listened to and responded to by the aggregation decision triggering mechanism; or, after the state management module completes the construction and storage of the state unit, it can directly call the entry function of the aggregation decision process and pass the newly generated state unit as a parameter.

[0058] This application also includes detecting user behavior characteristics or system resource status exceeding preset thresholds. This is crucial for aggregation, enabling the system to dynamically adjust aggregation strategies based on actual user operation restrictions or system load conditions. The data acquisition module continuously collects user behavior characteristic data and system resource status data, and periodically compares them with preset thresholds loaded in the strategy configuration. Once a threshold is detected, the aggregation judgment process is triggered; alternatively, it can be implemented through an event-driven approach, where the corresponding monitoring agent immediately reports when user behavior characteristic data or system resource status data changes significantly, and the aggregation judgment trigger mechanism performs threshold determination.

[0059] Once any of the above triggering conditions is met, the system will initiate the aggregation decision process. This is the bridge between translating the detected conditions into actual aggregation decision behavior, initiating the subsequent aggregation granularity determination and grouping merging process. The aggregation decision triggering mechanism sends an explicit instruction to the aggregation decision module, instructing it to begin executing the aggregation decision logic, including evaluating whether the current state unit needs aggregation and determining the aggregation granularity; alternatively, the triggering mechanism can directly call the predefined aggregation decision function in the aggregation decision module and pass relevant context information.

[0060] To ensure the flexibility and configurability of aggregation decisions, the system loads preset threshold parameters from the policy configuration. These parameters allow system administrators or users to adjust aggregation behavior according to actual needs. During system initialization, the aggregation decision module can read all preset threshold parameters from a centralized configuration service or local configuration file and store them in memory for real-time querying; alternatively, the threshold parameters can be stored in a database, and the aggregation decision module dynamically queries the latest parameter values ​​from the database each time a threshold judgment is needed to support hot updates. These threshold parameters include at least system resource thresholds, user behavior characteristic thresholds, aggregation trigger thresholds, and priority exemption rule parameters. Among them, the system resource threshold is used to determine whether the terminal device is in a resource-constrained state, such as CPU utilization, memory usage, etc.; the user behavior characteristic threshold is used to determine whether the terminal device is in an operation input-constrained state, such as user operation activity, device movement status, etc.; the aggregation trigger threshold may be used to define the triggering conditions of the aggregation operation itself, for example, aggregation is only started when the number of pending state units reaches a certain value; the priority exemption rule parameters define which high-priority or critical state units should be exempted from aggregation even under aggregation conditions, to ensure the timely delivery and display of important information.

[0061] Through the above technical solution, this application introduces an aggregation decision triggering mechanism and strategy configuration loading, effectively solving the problem of lack of a timely response mechanism in dynamic aggregation decision-making. Specifically, when the system detects the generation of a new state unit, it can immediately initiate the aggregation decision-making process, avoiding decision delays caused by the accumulation of new data. Simultaneously, by continuously monitoring user behavior characteristics and system resource status, once these key indicators exceed preset thresholds (e.g., prolonged user inactivity or system resource scarcity), the system can accurately determine that it is currently in a state of limited operation input or limited resources, and promptly trigger the aggregation decision-making process. This proactive triggering mechanism ensures that aggregation decisions are executed when most needed, thereby avoiding reduced system response efficiency and insufficient resource utilization caused by passive waiting. Furthermore, by loading preset threshold parameters, including system resource thresholds, user behavior characteristic thresholds, aggregation trigger thresholds, and priority exemption rule parameters, from the strategy configuration, this application enables the aggregation decision-making process to possess high flexibility and configurability, allowing for dynamic adjustments based on different operating environments and user needs. In particular, the introduction of priority exemption rule parameters ensures that high-priority or critical information can be displayed or processed in a timely and complete manner even during aggregation processing, avoiding the omission of important information. Overall, this solution makes the aggregation management of status data more efficient and accurate, significantly improving the operating efficiency and user experience of terminal devices under conditions of limited operation input or resources, while reducing the complexity of system processing.

[0062] Furthermore, in step S3, it also includes determining whether the terminal device is in a resource-limited state based on a threshold of system resources; determining whether the terminal device is in an operation input-limited state based on a threshold of user behavior characteristics; and marking state units whose priority meets the exemption conditions so that they do not participate in subsequent aggregation processing.

[0063] Specifically, the system determines whether a terminal device is in a resource-constrained state based on system resource thresholds. This mechanism aims to assess the current operating load of the terminal device to determine whether aggregation processing needs to be initiated. The system continuously monitors a series of key system resource indicators, such as CPU utilization, RAM usage, storage read / write speeds, network bandwidth usage, and battery remaining power or power consumption rate. When any one or more of these indicators exceed preset system resource thresholds—for example, if CPU utilization consistently exceeds 80% or available memory falls below a certain percentage—the system determines that the terminal device is in a resource-constrained state. Furthermore, indirect indicators such as device temperature, the number of background processes running, or the response time of critical applications can also be used to assist in the determination. When these indicators reach or exceed preset thresholds, they can also be considered resource-constrained.

[0064] Meanwhile, a threshold-based judgment system determines whether the terminal device is in a state of restricted input based on user behavior characteristics. This judgment mechanism is used to identify whether the user is currently in an environment where it is inconvenient to perform fine operations or where attention is limited. Specifically, the system can collect and analyze user behavior characteristic data, such as the frequency of touchscreen interactions, the success rate of gesture recognition, the input density of voice commands, or eye-tracking data within a preset time window. When these user behavior characteristic indicators are lower than preset user behavior characteristic thresholds, such as when no touch input or voice commands are detected within a certain period, the system can determine that the user is in a state of restricted input. Furthermore, motion sensor data from the terminal device (such as accelerometers and gyroscopes) can be combined to determine whether the user is in a state of vigorous movement, or ambient light sensors and distance sensors can be used to determine whether the device is in a non-interactive environment (such as in a pocket). When these environmental characteristics meet specific threshold conditions, they can also assist in determining whether the user's input is restricted.

[0065] Furthermore, state units that meet the exemption criteria are marked to exclude them from subsequent aggregation processing. This mechanism aims to ensure that critical or urgent state information is displayed or processed promptly and completely, unaffected by aggregation strategies. The system evaluates the priority of each state unit based on preset priority exemption rule parameters. These exemption rules can be pre-configured, for example, setting specific types of messages (such as emergency security alerts or medical reminders) or state units with the highest priority identifier as exemption targets. When a state unit's priority meets these exemption criteria, the system explicitly marks it, for example, by setting an "exemption" flag or routing it to a separate non-aggregation processing channel. Through this marking, the state unit directly bypasses subsequent aggregation determination and grouping processes, ensuring that its original information is preserved and processed with priority.

[0066] Through the above technical solutions, the system can accurately determine whether a terminal device is in a resource-constrained or operation input-constrained state based on system resource thresholds and user behavior characteristic thresholds, thereby avoiding unnecessary aggregation processing and ensuring the efficiency of aggregation decisions. Simultaneously, by marking state units whose priority meets the exemption conditions, it can effectively prevent high-priority information from being mistakenly aggregated or delayed in processing, ensuring the timely transmission and integrity of critical information. These mechanisms, combined with the aforementioned aggregation determination triggering mechanism and policy configuration loading, make the state data aggregation method more adaptable and robust in dynamic environments, significantly improving system processing efficiency and user experience.

[0067] In some of the solutions mentioned above in this application, the association between state units and aggregation granularity is proposed to optimize the grouping and merging process. However, in its implementation, there is a lack of an effective mechanism for dynamically determining and storing the association relationship. This results in the aggregation granularity being unable to respond in real time to changes in system resource status and user behavior, and unable to be personalized by combining the number or rate of arrival of state units. As a result, the aggregation efficiency is low, the processing delay is increased, and it may affect the accuracy and consistency of subsequent aggregation execution.

[0068] In this regard, this application further proposes that, in step S4, the association between state units and aggregation granularity is stored and guided. Based on the system resource status determination result and the user behavior characteristic determination result, and combined with the arrival number or arrival rate of state units, the corresponding aggregation granularity is determined for each state unit that is not exempted; the correspondence between state units and aggregation granularity is generated, and the correspondence is stored in the state management module to guide the subsequent aggregation execution process.

[0069] Specifically, the storage and guidance mechanism for the association between state units and aggregation granularities aims to establish and maintain the mapping relationship between state units and aggregation granularities, and use this relationship to guide subsequent aggregation processing. Its role is to ensure that aggregation operations can be performed according to predetermined strategies and real-time conditions, thereby achieving dynamic aggregation. Possible implementation methods include: one approach is to use key-value pairs, where the key is a unique identifier for the state unit and the value is the corresponding aggregation granularity, stored in an in-memory database or file system; another approach is to construct an association table containing the state unit ID, aggregation granularity ID, and other relevant metadata, stored and queried through a database management system.

[0070] The system resource status determination result and the user behavior characteristic determination result are conclusions drawn by the system after analyzing multi-dimensional data in step S2. They indicate whether the terminal device is currently in a resource-limited or operation input-limited state. These are key input parameters that determine the aggregation granularity, reflecting the terminal device's operating environment and user interaction capabilities. For example, the system resource status determination result can be a Boolean value (such as "resource-limited" or "resource-normal") or a quantified level (such as "slightly limited," "moderately limited," or "severely limited"); similarly, the user behavior characteristic determination result can also be a Boolean value (such as "operation input-limited" or "operation input-normal") or a quantified level. These results can be determined through preset threshold comparisons or machine learning models.

[0071] The arrival count or arrival rate of state units refers to the total number of state units formed after parsing and constructing the raw messages received by the system within a specific time window, or the frequency of state unit arrivals per unit time. It reflects the density of the data stream and the processing pressure. For example, the arrival count could be the total number of state units received in the past minute; the arrival rate could be the number of state units received per second. These data can be obtained in real time through counters, sliding window statistics, or the length of the message queue.

[0072] For each state unit that is not exempted, a corresponding aggregation granularity is determined. This step involves assigning an appropriate aggregation level to each state unit that needs aggregation based on the aforementioned input information (system resource status determination results, user behavior feature determination results, and the number or rate of arrival of state units). Aggregation granularity can be understood as the level of fineness of aggregation. For example, "high granularity" might mean merging multiple similar state units into a single generalized unit, while "low granularity" might mean retaining more original information or performing only a small amount of merging. The determination process can be based on a predefined set of rules (e.g., high-granularity aggregation is used if resources are limited and the arrival rate is high) or through a dynamic decision model (e.g., based on fuzzy logic or reinforcement learning).

[0073] The first step involves generating a mapping between state units and aggregation granularities. This step binds the aggregation granularities determined in the previous step to the corresponding state units, forming a mapping relationship that can be queried and used subsequently. This mapping relationship is the direct basis for aggregation execution. For example, a data structure, such as a list or hash table, can be generated, where each entry contains a unique identifier for a state unit and its assigned aggregation granularity identifier. The next step is to store the mapping relationship in the state management module. This step persistently saves the generated mapping relationship between state units and aggregation granularities to the state management module. The state management module is responsible for maintaining all state information in the system, including original state units, aggregated state units, and various relationships. Storage methods can include memory caching, local file storage, relational databases, or non-relational databases to ensure that these mapping relationships can be retrieved and used quickly and accurately in subsequent processing. The storage of the mapping relationship serves to guide subsequent aggregation execution. This feature clarifies the main purpose of the stored mapping relationship. In subsequent aggregation execution (e.g., grouping and merging), the system will query the state management module to obtain the appropriate aggregation granularity for each state unit and perform corresponding processing accordingly. This guidance ensures the accuracy, consistency, and dynamic adaptability of the aggregation process, enabling the system to effectively manage state data based on real-time conditions and preset strategies.

[0074] By introducing a storage and guidance mechanism for the association between state units and aggregation granularity, this application effectively solves the problem of insufficient determination of dynamic aggregation granularity, thereby ensuring that the aggregation process is efficient and adaptable to real-time changes. Specifically, the aggregation granularity is determined based on the system resource status judgment results and user behavior feature judgment results. Utilizing real-time system resource status and user behavior feature data, the aggregation granularity can dynamically respond to changes in the terminal device's operating load and user activity level, avoiding aggregation mismatches caused by resource or input limitations, thus improving the system's adaptability in complex environments. Simultaneously, granularity determination is combined with the arrival quantity or rate of state units, fully considering the frequency and scale of state data arrivals, effectively preventing insufficient or excessive aggregation when data arrives at high frequencies, and optimizing system resource utilization efficiency. A corresponding aggregation granularity is determined for each non-exempt state unit, enabling targeted processing of units requiring aggregation, eliminating interference from exempted units, and significantly improving the efficiency and accuracy of personalized processing. The generation of the correspondence between state units and aggregation granularity establishes a clear mapping, facilitating rapid referencing and execution of aggregation operations in subsequent steps. By storing the corresponding relationships in the state management module, persistent storage of these relationships is achieved, supporting consistent guidance across multiple aggregation processes and enhancing system stability and reliability. Ultimately, this mechanism can be directly applied to the grouping and merging operation in step S4, ensuring that aggregation granularity decisions are seamlessly integrated into the overall processing flow. This significantly improves the efficiency and accuracy of state data aggregation, reduces system processing complexity, and optimizes the overall performance of terminal devices.

[0075] Furthermore, in step S4, the state units are grouped according to the aggregation granularity and preset grouping rules. The grouping rules include at least the message type dimension, message source dimension, and time interval dimension, forming multiple state unit sets.

[0076] Specifically, state units are grouped according to aggregation granularity, where aggregation granularity refers to the fineness or scope of merging state units. In some of the above embodiments, the system has already determined a corresponding aggregation granularity for each non-exempt state unit. Grouping based on this determined aggregation granularity means that the system organizes state units according to a preset aggregation level (e.g., fine-grained, medium-grained, coarse-grained). For example, when the aggregation granularity is "fine-grained," it may be required that state units within the group be highly similar in message type, source, and time; when the aggregation granularity is "coarse-grained," it allows state units within the group to have greater differences in these dimensions. Another implementation is that the aggregation granularity can be a dynamically calculated value reflecting the degree of current system resource constraints or user input limitations, and the system uses this value to determine the strictness of the grouping.

[0077] Meanwhile, preset grouping rules refer to a series of conditions and logic configured before or during system operation to guide the grouping of state units. These rules can be hard-coded into the system or stored in a configuration database and dynamically loaded through the policy configuration module. For example, a preset rule could be: state units with the same message type, the same message source, and a time interval within 5 seconds should be grouped into the same group. Another implementation approach is that preset grouping rules can be a set of configurable templates, which users or administrators can select or modify according to actual needs to adapt to different application scenarios and aggregation strategies.

[0078] The grouping rules include at least three dimensions: message type, message source, and time interval. The message type dimension refers to grouping based on the category of the message represented by the state unit. For example, all state units representing "notifications" can be grouped into one category, all state units representing "system events" into another, and all state units representing "application status updates" into a third. Grouping by message type helps to group semantically similar or functionally related state units together, providing a logical basis for subsequent aggregation processing. The message source dimension refers to grouping based on the original sender or generator of the state unit. For example, state units from "email clients" can be grouped into one category, state units from "instant messaging applications" into another, and state units from "sensor data" into a third. Grouping by message source effectively distinguishes data streams generated by different applications or modules, preventing the inappropriate aggregation of heterogeneous messages from different sources. The time interval dimension refers to grouping based on the specific time period in which the state unit arrives or is generated. For example, all state units arriving "within the last 5 minutes" can be grouped into one category, all state units arriving "within the current hour" into another, or all state units arriving "on the same day" into one category. Grouping by time interval dimension effectively handles state units with temporal correlation, ensuring that temporal continuity and relevance are maintained during aggregation. Ultimately, after the above grouping operation, the original discrete state units are organized into several logically independent groups with certain internal correlations, forming multiple state unit sets. Each set contains a group of state units that satisfy specific grouping conditions. These sets are the basic units for subsequent aggregation processing, providing clear boundaries and structure for the system to determine which state units can be merged into a single aggregated state unit.

[0079] Through the above technical solution, when grouping state units, the system can systematically and meticulously group state units according to a pre-determined aggregation granularity, combined with preset grouping rules such as message type, message source, and time interval. This multi-dimensional and structured grouping method effectively solves the problems of grouping efficiency and accuracy caused by unclear grouping rules. Specifically, grouping according to aggregation granularity ensures that the fineness of the grouping matches the current system state (such as resource constraints or limited operation input), avoiding unnecessary refinement or over-coarsening. At the same time, introducing key dimensions such as message type, message source, and time interval as grouping rules makes the grouping process more logical, effectively aggregating semantically related, consistent-source, and temporally continuous state units into the same set. This not only improves the efficiency of state unit set formation but also significantly enhances the accuracy of grouping, laying a solid foundation for subsequently merging sets that meet the aggregation conditions into a single aggregated state unit. Thus, under conditions of limited operation input or resources, it can more effectively organize and manage state data, reduce system processing complexity, and improve the overall operating efficiency of terminal devices.

[0080] Furthermore, in step S4, when a set of state units satisfies the aggregation condition, the set of state units is merged to generate an aggregated state unit, and the aggregated state unit replaces the state units in the set to participate in subsequent processing; when a new state unit satisfies the condition of being merged into an existing aggregated state unit, the corresponding aggregated state unit is updated.

[0081] Specifically, when a set of state units meets the aggregation conditions, the system triggers a merging operation to combine the set of state units into a single aggregated state unit. These aggregation conditions can be preset in various forms. For example, the system can preset a series of aggregation conditions, such as when the number of units in the set reaches a specific threshold, the priority of all state units in the set is lower than a preset value, or the arrival time interval of state units in the set is less than a certain threshold. Once the conditions are met, the system extracts the common attributes (such as message type and source) of all state units in the set and combines them with aggregation granularity information to generate a new aggregated state unit. This aggregated state unit can contain summary information, counts, or representative data of the original state units. Alternatively, the system can be configured to trigger aggregation determination when specific events occur, such as when the system resource status is continuously below a certain threshold, user input restrictions persist, or a preset time period ends, to check the aggregation conditions of the currently formed set of state units. If the conditions are met, the system integrates the key information of the state units in the set (such as message title, quantity, earliest / latest timestamps) to generate an aggregated state unit representing the set.

[0082] After generating an aggregated state unit, the system replaces the state units within the set with this aggregated state unit in subsequent processing. This can be achieved in several ways. For example, in the state management module, after generating an aggregated state unit, the system updates the references or pointers to the original state units, making them point to the newly generated aggregated state unit. Simultaneously, the original state units are marked as aggregated or logically deleted, ensuring that subsequent processing only recognizes and operates on the aggregated state unit. For instance, in a message queue or display list, multiple discrete messages are replaced with a single aggregated message. Another approach is for the system to remove the original state units from the active processing queue and insert the aggregated state unit into the corresponding processing queue or display rendering module. An aggregated state unit can contain a list or reference pointing to the identifiers of the original state units it contains, allowing for de-aggregation or viewing of details when needed. However, by default, subsequent processing is based solely on the attributes of the aggregated state unit.

[0083] Furthermore, to ensure the real-time and dynamic nature of aggregated states, when a new state unit meets the conditions for merging into an existing aggregated state unit, the system will perform update processing on the corresponding aggregated state unit. The system continuously monitors newly arriving state units. For each new state unit, the system matches it with existing aggregated state units based on its message type, source identifier, priority, and other attributes. If the attributes of the new state unit match the aggregation conditions of an aggregated state unit (e.g., belonging to the same message type, the same source, and within the same time window), the system merges the new state unit into the corresponding aggregated state unit. Update processing may include increasing the count of the aggregated state unit, updating its time range (e.g., earliest / latest arrival time), or updating its summary information (e.g., adding a title to the new message). The system can also be configured with a rule engine, which determines whether merging is allowed based on preset merging rules (e.g., the new state unit has the same aggregation granularity as an existing aggregated state unit, and its key attributes (e.g., message source, topic) are highly similar). Once merging is deemed allowed, the system calls the update interface of the aggregated state unit to integrate the data of the new state unit. For example, if an aggregated status cell indicates "5 unread emails", when a new email arrives and meets the merging criteria, the aggregated status cell will be updated to "6 unread emails", and its preview content may also be updated.

[0084] Through the above technical solution, this application effectively solves the problems of dynamic adaptability and efficiency in aggregation processing. Specifically, when a set of state units meets the aggregation conditions, the system can automatically merge the set of state units to generate an aggregated state unit. This mechanism enables the system to quickly perform the merging operation when the conditions are met, generating an aggregated unit representing multiple state units, thereby significantly reducing the amount of discrete data that needs to be processed and effectively avoiding the rapid accumulation of state data. At the same time, by replacing the state units within the set with aggregated state units in subsequent processing, the subsequent processing flow is simplified, the system load is reduced, and the overall processing efficiency is improved. Furthermore, when a new state unit meets the conditions for merging into an existing aggregated state unit, the system can perform update processing on the corresponding aggregated state unit. This dynamic update mechanism allows the system to integrate newly arrived state units into the existing aggregate in real time, ensuring that the aggregated state unit can reflect the latest data changes in a timely manner, thereby enhancing the dynamic adaptability and real-time response capability of the system. This allows the terminal device to still manage and present state data efficiently and accurately even under conditions of limited operation input or limited resources.

[0085] Based on the above, referring to Figure 1 As shown, this application discloses a state data aggregation method, which specifically includes the following steps: Step S1: Start the terminal device's message processing system and initialize the message receiving module, status management module, data acquisition module, and aggregation decision module. Configure the data acquisition channels, including the message attribute acquisition channel, user behavior feature acquisition channel, and system resource status acquisition channel.

[0086] Step S2: When the terminal device receives a message, it assigns a temporary receiving identifier to the message and parses the message attribute data of the message to obtain at least one of the following: message type, source identifier, priority, and arrival timestamp.

[0087] Step S3: Obtain user behavior feature data within a preset time window. The user behavior feature data is used to characterize the user's operational activity level within the time window. At the same time, collect system resource status data at the message arrival time or within the most recent sampling period. The system resource status data is used to characterize the current operating load of the terminal device.

[0088] Step S4: Based on the message attribute data, user behavior feature data, system resource status data, and time attribute, construct the corresponding state unit and perform format standardization processing on the state unit. Store the state unit in the state management module to support subsequent aggregation processing.

[0089] Step S5: When a new state unit is detected to be generated, or when user behavior characteristics or system resource status are detected to exceed a preset threshold, the aggregation judgment process is triggered; and preset threshold parameters are loaded from the policy configuration. The threshold parameters include at least system resource threshold, user behavior characteristic threshold, aggregation trigger threshold, and priority exemption rule parameters.

[0090] Step S6: Based on the system resource threshold, determine whether the terminal device is in a resource-limited state; based on the user behavior feature threshold, determine whether the terminal device is in an operation input-limited state; mark the state units whose priority meets the exemption conditions so that they do not participate in the subsequent aggregation process.

[0091] Step S7: Based on the system resource status determination results and user behavior characteristic determination results, and combined with the arrival number or arrival rate of status units, determine the corresponding aggregation granularity for each non-exempt status unit; where the more strained the system resource status or the lower the user operation activity level, the higher the determined aggregation granularity.

[0092] Step S8: Generate the correspondence between state units and aggregation granularity, and store the correspondence in the state management module to guide the subsequent aggregation execution process.

[0093] Step S9: Group the state units according to the aggregation granularity and the preset grouping rules. The grouping rules include at least the message type dimension, message source dimension, and time interval dimension to form multiple state unit sets.

[0094] Step S10: When a set of state units satisfies the aggregation condition, the set of state units is merged to generate an aggregated state unit, and the aggregated state unit replaces the state units in the set for subsequent processing; when a new state unit satisfies the condition of being merged into an existing aggregated state unit, the corresponding aggregated state unit is updated.

[0095] Step S11: When the user operation input state or system resource state is detected to be restored, and the preset release condition is met, the aggregation granularity of some aggregated state units is reduced; and the current set of aggregated state units is output as the processing result to the subsequent modules.

[0096] The specific implementation method is as follows: Suppose a user is running outdoors while wearing a smartwatch. During the run, the user's input is limited, and the smartwatch continuously receives the following high-frequency status data: 1. Multiple new email notifications: For example, receive 5 new emails from different senders within 5 minutes.

[0097] 2. Multiple social media updates: For example, receiving 10 social media updates from different apps or friends within 5 minutes.

[0098] 3. Heart rate abnormality alert: For example, if the heart rate continues to exceed the preset threshold.

[0099] 4. Low battery warning: For example, the watch battery is below 20%.

[0100] 5. System resource status: For example, the watch's CPU usage remains high due to background synchronization tasks.

[0101] According to the technical solution of this application, the smartwatch will be processed in the following manner: State unit construction and multi-dimensional data collection: Every new email, every social media update, heart rate abnormality reminder, and low battery warning is parsed and constructed into an independent state unit.

[0102] The system also collects user behavior characteristics: the user is running, which falls under the category of "limited operation input" and "high activity level".

[0103] System resource status: High CPU utilization indicates "resource-constrained".

[0104] Message attributes: abnormal heart rate and low battery are "high priority", emails are "medium priority", and social media updates are "low priority".

[0105] Dynamic determination and exemption of aggregation granularity: Since the user is in a running state (operation input is limited and activity is high) and system resources are scarce (CPU utilization is high), the system determines that "high aggregation granularity" is required.

[0106] According to the priority exemption rules, abnormal heart rate alerts and low battery warnings are marked as exempt due to their high priority and are not included in the regular aggregation, ensuring that users can receive critical safety information in a timely manner.

[0107] State unit grouping and aggregation: Email notifications: Five new email notifications have been grouped and aggregated into a single "aggregated status unit" that displays "You have 5 new emails".

[0108] Social media updates: 10 social media updates are grouped and aggregated into an "aggregated status unit" that displays "You have 10 social media posts".

[0109] Heart rate abnormality and low battery: Due to exemptions, they will be presented as separate state units, such as "Heart rate too high: 165 bpm" and "Battery low: 15%".

[0110] Output results: Ultimately, instead of 17 individual notifications displayed on the smartwatch screen or via vibration / voice prompts, users will see four aggregated or exempted key messages: "Heart rate too high: 165 bpm", "Battery low: 15%", "You have 5 new emails", and "You have 10 social media posts". This significantly reduces the amount of information, preventing distraction due to information overload while running, and ensuring the timely delivery of important information.

[0111] Particle size adjustment: When a user finishes running, stops exercising, and sits down to rest, the system detects that the user's behavior characteristics have changed to "unrestricted input" and "low activity level," while CPU usage also returns to normal. At this point, the system reduces the aggregation granularity. For example, when a user clicks "You have 5 new emails," the system may expand to display the title and sender of each email, or display new messages in more detail one by one when they are received later.

[0112] This embodiment illustrates how the present solution can effectively manage high-frequency state data, reduce information overload, and improve user experience and device efficiency in scenarios where user movement and input are limited, through a multi-dimensional data-driven aggregation mechanism.

[0113] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A method for aggregating state data, characterized in that, Includes the following steps: S1. The system performs unified parsing of the original message and constructs it into standardized state units; S2. The system continuously collects and analyzes multi-dimensional data, which provides the system with real-time operating context information, enabling the system to determine whether it is currently in a state of limited user interaction or resource constraints that requires aggregation processing, and to generate aggregate control indicators to characterize the current operating status of the system. S3. The system dynamically determines whether a state unit should be aggregated based on the aggregation control index and the state unit attributes, and determines the corresponding aggregation granularity. S4. The system groups the relevant state units according to the determined aggregation granularity and preset rules. For groups that meet the aggregation conditions, the system merges them into an aggregated state unit and uses the aggregated state unit to replace the state units in the group for subsequent processing. S5. When the user interaction state or system resource state returns to normal, the system dynamically reduces the aggregation granularity according to the preset release conditions, and restores the display or processing of the original message.

2. The state data aggregation method according to claim 1, characterized in that: The system also includes system initialization and multi-channel data acquisition architecture in step S1. When the terminal device starts up, the message receiving module, status management module, data acquisition module and aggregation decision module are initialized. At the same time, dedicated data acquisition channels are configured, including message attribute acquisition channel, user behavior feature acquisition channel and system resource status acquisition channel, for effective acquisition of multi-dimensional data.

3. The state data aggregation method according to claim 1, characterized in that: The method also includes a message temporary receiving identifier allocation mechanism in step S1. When the terminal device receives an original message, it allocates a temporary receiving identifier to the original message and parses the message attribute data of the original message to obtain at least one of the message type, source identifier, priority and arrival timestamp.

4. The state data aggregation method according to claim 1, characterized in that: It also includes a refined collection mechanism for user behavior characteristics and system resource status in step S2, which acquires user behavior characteristic data within a preset time window. The user behavior characteristic data is used to characterize the user's operational activity level within the time window. At the same time, system resource status data is collected at the message arrival time or within the most recent sampling period. The system resource status data is used to characterize the current operating load of the terminal device.

5. The state data aggregation method according to claim 1, characterized in that: The process also includes, in step S3, standardizing the format of the state units and managing their storage. Based on message attribute data, user behavior feature data, system resource status data and time attributes, the state units are standardized and stored in the state management module to support subsequent aggregation processing.

6. The state data aggregation method according to claim 5, characterized in that: The process also includes loading the aggregation determination trigger mechanism and policy configuration in step S3. When a new state unit is detected to be generated, or when user behavior characteristics or system resource status are detected to exceed a preset threshold, the aggregation determination process is triggered. The preset threshold parameters are loaded from the policy configuration. The threshold parameters include at least the system resource threshold, user behavior characteristic threshold, aggregation trigger threshold, and priority exemption rule parameters.

7. The state data aggregation method according to claim 6, characterized in that: It also includes, in step S3, determining whether the terminal device is in a resource-constrained state based on a threshold of system resources; Based on thresholds of user behavior characteristics, determine whether the terminal device is in a state of restricted operation input; mark state units that meet the exemption conditions in order to exclude them from subsequent aggregation processing.

8. The state data aggregation method according to any one of claims 7, characterized in that: The process also includes storing and guiding the association between state units and aggregation granularities in step S4. Based on the system resource status determination results and user behavior characteristic determination results, and combined with the arrival number or arrival rate of state units, a corresponding aggregation granularity is determined for each state unit that has not been exempted. The correspondence between state units and aggregation granularities is generated and stored in the state management module to guide the subsequent aggregation execution process.

9. The state data aggregation method according to claim 8, characterized in that: The process also includes, in step S4, grouping the state units according to the aggregation granularity and preset grouping rules. The grouping rules include at least the message type dimension, message source dimension, and time interval dimension, forming multiple state unit sets.

10. The state data aggregation method according to claim 9, characterized in that: The process also includes step S4, in which, when a set of state units meets the aggregation condition, the set of state units is merged to generate an aggregated state unit, and the aggregated state unit replaces the state units in the set for subsequent processing; when a new state unit meets the condition for merging into an existing aggregated state unit, the corresponding aggregated state unit is updated.

Images