Thread security synchronous monitor method and system

Abstract

The invention discloses a thread security synchronization monitor method, which comprises the following steps that: when data calling occurs, a calling party registers a monitor according to data, the monitor is used for monitoring called data and recording monitoring information monitored by the monitor, and when the called data changes, all the monitors are traversed, and the monitored information is recorded by the calling party; callback is carried out on the sound monitor of the changed called data, callback feedback is recorded, and the sound monitor is adjusted according to the callback feedback. According to the technical scheme, the monitor is used for monitoring the data and is adjusted according to the monitoring condition, so that the method can be used for data broadcasting of any type, multiplexing of multiple service modules is facilitated, and the problems that in the prior art, life cycle management is not comprehensive, monitoring control granularity is insufficient, and thread scheduling has defects are solved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a thread-safe synchronization listener method and system. Background Technology

[0002] In modern Android application development, inter-component data communication and state synchronization are crucial for achieving reactive architectures. While widely used synchronization mechanisms such as LiveData and RxJava offer some lifecycle awareness and thread scheduling capabilities, they suffer from the following limitations in real-world scenarios: They cannot finely differentiate between identification channels, lacking channel-level listening capabilities for different devices, screens, and channels; lifecycle management is incomplete, easily leading to listener leaks in complex component nesting; listener control granularity is insufficient, lacking capabilities for one-time listening, sticky data listening, and conditional triggering; and thread scheduling defects exist, with some implementations failing to guarantee that listener callbacks always run on the main thread, potentially causing UI anomalies. Summary of the Invention

[0003] To address the aforementioned issues, this invention provides a thread-safe synchronization listener method and system. Through a sticky listener dispatch mechanism, and by utilizing the listener for data monitoring, the listener can be adjusted based on the monitoring results. This method can be used for any type of data broadcasting, facilitating reuse across multiple business modules. It solves the problems of incomplete lifecycle management, insufficient granularity of monitoring control, and defects in thread scheduling found in existing technologies.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A thread-safe synchronization listener method includes the following steps: S1. When a data call occurs, the caller registers a listener based on the data, and the listener is used to listen for the called data; S2. Record the listening information obtained by the listener; S3. When the called data changes, iterate through all listeners, execute callbacks for listeners whose called data has changed, record callback feedback, and adjust the listeners based on the callback feedback.

[0005] Furthermore, in step S1, the listener includes: a resident listener, a one-time listener, and a filtering listener.

[0006] Furthermore, when the listener is a one-time listener, after executing the callback for the one-time listener, the one-time listener is removed.

[0007] Furthermore, when the caller registers a listener based on the data, the process also includes: setting the listener's lifecycle during registration, and removing the listener when its lifecycle ends.

[0008] Furthermore, when the caller registers a listener based on the data, the process also includes: when the listener registers, predicting a simulated value based on the historical data of the called data, and distributing the simulated value to the listener.

[0009] Furthermore, the specific implementation of predicting simulated values ​​based on historical data of the called data is as follows: constructing a data prediction model, collecting historical data of the called data, establishing a historical dataset based on the historical data of the called data, inputting the historical dataset into the data prediction model, and outputting simulated values ​​from the data prediction model. When the listener is called back, it adds the updated data to the historical data of that data and adjusts the data prediction model based on the deviation between the updated data and the simulated value.

[0010] Furthermore, the data prediction model is a linear regression prediction model.

[0011] Furthermore, the process of iterating through all listeners and executing callbacks for listeners whose called data has changed also includes filtering listeners using an adaptive filtering mechanism while iterating through all listeners.

[0012] Furthermore, after the listener callback, it records whether the callback is valid. When the proportion of invalid callbacks exceeds a preset threshold, the filtering conditions are automatically tightened to reduce subsequent callbacks. When the number of callbacks is insufficient or all callbacks are valid, the filtering conditions are automatically relaxed to increase the callback frequency.

[0013] Through the above technical solution, the present invention has the following beneficial effects: it provides a sticky listening function to ensure that the listener can immediately receive the last state, supports one-time listening, automatically releases resources after data response, supports setting data filters, triggers a response only when conditions are met, and, combined with Android's LifecycleOwner, realizes automatic release of the listener, and provides a thread-safe data distribution and management mechanism. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the overall process of a thread-safe synchronization listener method according to the present invention.

[0015] Figure 2 This is a schematic diagram of the structure of a thread-safe synchronization listener system according to an embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] Example 1 See Figure 1 A thread-safe synchronization listener method includes the following steps: S1. When a data call occurs, the caller registers a listener based on the data, and the listener is used to listen for the called data; S2. Record the listening information obtained by the listener; S3. When the called data changes, iterate through all listeners, execute callbacks for listeners whose called data has changed, record callback feedback, and adjust the listeners based on the callback feedback.

[0019] The components in this application are implemented using the generic class SyncListener, and mainly include the following modules: 1. ListenerBean: Used to record information about each listener (listener identifier, callback function, lifecycle, filtering conditions, etc.); 2. Callback registration method: (1) observeForever(): A persistent listener; (2) observe(): binds a lifecycle listener; (3) observeIndexed(): Supports callback form of (markNum, value); (4) observeOnce(): listens once, and releases after the callback is executed once; (5) observeWithFilter(): Registers a listener for the filter conditions to be triggered; 3. Data distribution method: postValue(value: T, markNum: Int): Broadcasts data from the main thread, filtered by the identifier; 4. Auxiliary functions: (1) removeObserver(): Removes a specific callback; (2) clearAllObservers(): Clears all observers; (3) getObserverCount() / hasObservers(): Check the listening status; (4) getValueByMark(): Retrieves the last data by the identifier.

[0020] In an optional embodiment, in step S1, the listener includes: a resident listener, a one-time listener, and a filtering listener.

[0021] A resident listener is a listener that remains in a listening state at all times, continuously receiving data updates or event notifications. It remains effective throughout the system's operation and will not be actively removed. It is suitable for scenarios that require real-time updates, such as user interface state synchronization and real-time monitoring.

[0022] One-time listeners automatically remove themselves after receiving a data update or event notification, and will no longer listen for subsequent updates. They are suitable for short-term listening that only cares about specific events or data changes, avoiding interference with subsequent updates. Once a callback is triggered, the system will automatically unregister the listener. They are suitable for scenarios such as pop-up notifications and data initialization.

[0023] Filter listeners trigger callbacks only when the conditions are met, based on preset conditions or rules. Filter conditions can be set, such as numerical ranges or status indicators, to determine whether to activate the listener. This effectively reduces unnecessary callbacks and resource consumption, making it suitable for scenarios with frequent data fluctuations. It is typically used in situations where specific conditions are required for processing, such as sending notifications only when there are significant status changes in a monitoring system.

[0024] Resident listeners, one-off listeners, and filter listeners are designed for different use cases. Resident listeners are suitable for continuously tracking data changes, one-off listeners are used for specific instantaneous responses, and filter listeners are triggered by conditional restrictions to improve efficiency. Choosing the right listener type can effectively optimize system performance and user experience.

[0025] In an optional embodiment, when the listener is a one-time listener, the one-time listener is removed after the callback is executed on the one-time listener.

[0026] In an optional embodiment, when the caller registers a listener based on data, the method further includes: setting the listener's lifecycle during registration, and removing the listener when its lifecycle ends.

[0027] Setting a listener's lifecycle and automatically removing it when it expires can effectively manage system resources, prevent memory leaks, improve performance, reduce invalid notifications, enhance system flexibility, and improve user experience. This mechanism ensures that in high-concurrency environments, the system can respond efficiently to important events and maintain the consistency and accuracy of information.

[0028] In an optional embodiment, when the caller registers a listener based on the data, the method further includes: when the listener is registered, predicting a simulated value based on the historical data of the called data, and distributing the simulated value to the listener.

[0029] In traditional listeners, newly registered listeners typically only receive the most recently distributed value. If the system hasn't pushed new data yet, new listeners won't see any data changes for a short period, leading to "perceptual lag" issues such as interface stuttering and missing device status. To address this "initial empty data" problem, this invention introduces a sticky value prediction mechanism: allowing the system to predict the next possible state value based on historical data trends, even without actual data distribution, and immediately distribute this as a "simulated value" upon listener registration, improving the continuity and responsiveness of the user experience.

[0030] By collecting historical data in real-time or periodically, calculating the differences between recent data values ​​to determine the direction of change, and using a set time window to calculate the average rate of change to determine the overall trend, this method then determines whether the current data state is stable or exhibiting a smooth trend based on the average rate of change and a threshold, thereby predicting the next value. If historical values ​​show a linear increase, the predicted value is based on the last value plus the expected change; if the state is stable, the current value is maintained; and if there is no obvious trend, the prediction is abandoned. This mechanism not only reduces the frequency of actual data transmission but also maintains the consistency of the user interface using predicted values ​​when state changes are slow, thus effectively improving system performance and user experience, especially in resource-constrained applications or applications requiring real-time responses.

[0031] When frequent synchronization of states is required (such as in device control panels, IoT monitoring, audio and video control systems, etc.), the system often needs to broadcast state changes to the listening end at a high frequency to ensure a sense of "synchronization". If the predicted value is highly consistent with the subsequent real value, no additional data dispatch is required. When the state changes slowly, the real broadcast can be delayed, and the predicted value can be used to maintain UI continuity. In addition, through the predicted value mechanism, the listener can use the predicted value to display the state before the network updates the state, maintaining a smooth experience.

[0032] In an optional embodiment, the specific implementation of predicting simulated values ​​based on historical data of the called data is as follows: constructing a data prediction model, collecting historical data of the called data, establishing a historical dataset based on the historical data of the called data, inputting the historical dataset into the data prediction model, and outputting simulated values ​​from the data prediction model. When the listener is called back, it adds the updated data to the historical data of that data and adjusts the data prediction model based on the deviation between the updated data and the simulated value.

[0033] In an optional embodiment, the data prediction model is a linear regression prediction model.

[0034] In an optional embodiment, iterating through all listeners and executing callbacks for listeners whose invoked data has changed further includes filtering listeners using an adaptive filtering mechanism while iterating through all listeners.

[0035] In monitoring systems, it is often necessary to restrict the conditions for callback triggering through filters. However, the fixed filtering conditions used in existing technologies cannot adapt to changes in user behavior. When the monitoring frequency is too high, it can easily lead to heavy system load, while when the monitoring frequency is too low, it can easily miss important information. Therefore, this invention proposes a mechanism that automatically adjusts the filtering conditions based on user feedback. As the system performs, it automatically optimizes the triggering strategy without requiring manual adjustment by users or developers. This ensures the accuracy of notifications while reducing invalid monitoring and lowering the system load.

[0036] In an optional embodiment, after the listener callback, it is recorded whether the callback is valid. When the proportion of invalid callbacks exceeds a preset threshold, the filtering conditions are automatically tightened to reduce subsequent callbacks. When the number of callbacks is insufficient or all callbacks are valid, the filtering conditions are automatically relaxed to increase the callback frequency.

[0037] This adaptive filtering mechanism adjusts the filtering criteria by recording the validity of each listener trigger and analyzing recent trigger effects. When the proportion of invalid triggers exceeds a set threshold, the system automatically tightens the filtering criteria to reduce subsequent triggers; conversely, when the number of valid triggers is high, the system appropriately widens the filtering range and increases the trigger frequency. Specifically, a callback is triggered when the initial filtering condition is set to "50". If only 2 out of the last 10 triggers are valid, the system raises the threshold to 60. As the number of valid triggers increases, the threshold may be adjusted again to ensure that the listening behavior is optimized to avoid over-triggering or missing key changes.

[0038] Example 2 See Figure 2 A thread-safe synchronization listener system, comprising: The listener registration module is used to register a listener based on the data when a data call occurs. The listener is used to listen for the called data. The listening and recording module is used to record the listening information obtained by the listener; The listener adjustment module is used to iterate through all listeners when the called data changes, execute callbacks for listeners whose called data has changed, record callback feedback, and adjust the listeners based on the callback feedback. The embodiments disclosed in this specification are merely illustrative of one aspect of the invention, and the scope of protection of the invention is not limited to these embodiments. Any other functionally equivalent embodiments fall within the scope of protection of the invention. Those skilled in the art can make various other corresponding changes and modifications based on the technical solutions and concepts described above, and all such changes and modifications should fall within the scope of protection of the claims of this invention.

Claims

1. A thread-safe synchronization listener method, characterized in that, Includes the following steps: S1. When a data call occurs, the caller registers a listener based on the data, and the listener is used to listen for the called data; S2. Record the listening information obtained by the listener; S3. When the called data changes, iterate through all listeners, execute callbacks for listeners whose called data has changed, record callback feedback, and adjust the listeners based on the callback feedback.

2. The thread-safe synchronization listener method according to claim 1, characterized in that, In step S1, the listener includes: a resident listener, a one-time listener, and a filter listener.

3. The thread-safe synchronization listener method according to claim 2, characterized in that, When the listener is a one-time listener, after executing the callback for the one-time listener, the one-time listener is removed.

4. The thread-safe synchronization listener method according to claim 1, characterized in that, When the caller registers a listener based on the data, the following steps are also included: when the listener is registered, the listener's lifecycle is set, and when the listener's lifecycle ends, the listener is removed.

5. A thread-safe synchronization listener method according to claim 1, characterized in that, When the caller registers a listener based on the data, the process also includes: when the listener is registered, predicting a simulated value based on the historical data of the called data, and distributing the simulated value to the listener.

6. A thread-safe synchronization listener method according to claim 5, characterized in that, The specific implementation of predicting simulated values ​​based on historical data of the called data is as follows: constructing a data prediction model, collecting historical data of the called data, establishing a historical dataset based on the historical data of the called data, inputting the historical dataset into the data prediction model, and outputting simulated values ​​from the data prediction model. When the listener is called back, it adds the updated data to the historical data of that data and adjusts the data prediction model based on the deviation between the updated data and the simulated value.

7. A thread-safe synchronization listener method according to claim 6, characterized in that, The data prediction model is a linear regression prediction model.

8. A thread-safe synchronization listener method according to claim 1, characterized in that, It iterates through all listeners, executes callbacks for listeners whose called data has changed, and also includes: filtering listeners using an adaptive filtering mechanism while iterating through all listeners.

9. A thread-safe synchronization listener method according to claim 8, characterized in that, After the listener callback, record whether the callback is valid. When the proportion of invalid callbacks exceeds the preset threshold, automatically tighten the filtering conditions to reduce subsequent callbacks. When the number of callbacks is insufficient or all callbacks are valid, automatically relax the filtering conditions to increase the callback frequency.

10. A thread-safe synchronization listener system, characterized in that, include: The listener registration module is used to register a listener based on the data when a data call occurs. The listener is used to listen for the called data. The listening and recording module is used to record the listening information obtained by the listener; The listener adjustment module is used to iterate through all listeners when the called data changes, execute callbacks for listeners whose called data has changed, record callback feedback, and adjust the listeners based on the callback feedback.

Images