Methods for capturing browser state data and electronic devices

Abstract

This application discloses a method and electronic device for capturing browser state data, relating to the field of data processing technology. The method includes: determining the storage area for each state data based on data change frequency and preset node dependencies; generating incremental state data according to a preset difference determination strategy and storing it in a first data area, whereby the incremental state data includes changed data, page structure fingerprints, and user operation sequence data; periodically detecting preset crash events; and, in response to any preset crash event meeting a corresponding first warning threshold, using a preset service thread to retrieve incremental state data from the first data area and package and store it in a preset crash state area. This application significantly reduces serialization overhead and storage volume through incremental state data generation and memory tiering strategies. Crash detection ensures highly reliable capture of the final state, solving the problem that browser sandbox environments cannot record the moment of a crash.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and electronic device for capturing browser state data. Background Technology

[0002] The global state of browser-based single-page applications (SPAs) is mostly stored in browser memory, making it susceptible to loss due to JavaScript runtime crashes, user errors, system resource reclamation, offline events, and other scenarios. Using full serialization for storage requires traversing the entire state tree, which can easily block the main thread and, due to storage capacity limitations, cannot capture the final state at the moment of a crash. Native application crash handling solutions rely on the operating system's application programming interface (API), cannot adapt to the browser sandbox environment, and can only recover static data, not the user interaction context. Therefore, there is an urgent need for a solution that can achieve real-time capture of crash states within a browser sandbox environment. Summary of the Invention

[0003] This application provides a method and electronic device for capturing browser state data, to at least solve the problems of crash state capture and storage medium performance optimization.

[0004] Firstly, this application provides a method for capturing browser state data, including:

[0005] The storage area for each state data is determined based on the data change frequency and the preset node dependency relationship. The storage area includes the first data area, where the data change frequency of the state data stored in the first data area is less than that of the second data area and greater than that of the third data area.

[0006] Incremental state data is generated and stored in the first data area based on a preset difference determination strategy. The incremental state data includes change data, page structure fingerprint, and user operation sequence data.

[0007] Periodically check for preset crash events, which include at least one of code exception, insufficient memory, and unexpected uninstallation;

[0008] In response to any preset crash event meeting the corresponding first warning threshold, a preset service thread is used to obtain incremental state data from the first data area and package and store it in the preset crash state area, which is located in the first data area.

[0009] Secondly, this application also provides an electronic device, comprising:

[0010] Memory, used to store computer programs;

[0011] A processor is used to implement the steps of any of the methods in the first aspect when executing a computer program.

[0012] This application provides a method and electronic device for capturing browser state data. It divides data into first, second, and third data zones based on data change frequency, ensuring that data with different change frequencies have appropriate storage locations and facilitating rapid retrieval of required state data during crashes, thus improving capture efficiency. Incremental state data is generated based on a preset difference determination strategy, recording only changed data, page structure fingerprints, and user operation sequence data. Compared to recording all state data completely, the incremental data volume is significantly reduced, making storage and transmission more efficient. Furthermore, by focusing only on the changed parts, it can more accurately capture dynamic changes in the browser state, avoiding redundancy and errors caused by repeatedly recording unchanged data. Moreover, the incremental state data includes changed data, page structure fingerprints, and user operation sequence data, rather than just static data, laying the foundation for restoring from static values ​​to full-scene reconstruction. By periodically detecting preset crash events such as code anomalies, insufficient memory, and unexpected uninstallation, it can promptly detect potential browser anomalies. This proactive monitoring mechanism allows the system to respond before or immediately after a crash, buying time for subsequent data saving and processing, enhancing system stability and reliability. Incremental state data is pre-stored in the first data area, eliminating the need for temporary serialization in case of a crash. Even if the main thread is stuck, the pre-defined service thread can still read data from the first data area. The crash state area remains in the first data area, reusing existing storage media without requiring additional storage resources. This adapts to the browser sandbox environment and aligns with pure front-end implementation logic. Attached Figure Description

[0013] To more clearly illustrate the embodiments of this application, the accompanying 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.

[0014] Figure 1 This is a schematic diagram illustrating an application scenario corresponding to a browser state data capture method provided in an embodiment of this application;

[0015] Figure 2 A flowchart illustrating a method for capturing browser state data according to an embodiment of this application;

[0016] Figure 3 A signaling interaction flowchart of a browser state data capture method provided in an embodiment of this application;

[0017] Figure 4 A schematic diagram of a browser state data capture device provided in an embodiment of this application;

[0018] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0020] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] The global state of browser-based single-page applications (SPAs) is mostly stored in browser memory, making it susceptible to loss due to JavaScript runtime crashes, user errors, system resource reclamation, and offline scenarios. However, full serialization requires traversing the entire state tree, taking over 800ms for a 10MB state tree, easily causing main thread blocking and UI lag. Furthermore, it's limited by local storage capacity (5MB). Session storage cannot handle crash scenarios and, because it relies on normal main thread execution, cannot capture the final state at the moment of a crash. Backend synchronization solutions rely on the network, fail in offline scenarios, waste bandwidth with full transmission, and pose privacy and compliance risks for sensitive data transmission. Native application crash handling solutions rely on the operating system's application programming interface (API), cannot adapt to browser sandbox environments, and can only record method call sequences, failing to capture the Document Object Model (DOM) state and user interaction context. Therefore, a pure front-end, high-performance state persistence solution is urgently needed to address the issues of crash state capture and performance optimization.

[0023] Therefore, when facing the technical problems of the aforementioned related technologies, to address the performance bottleneck caused by full serialization blocking the main thread, the storage area is divided by mining the change frequency characteristics of state data. State data is divided into first, second, and third data areas according to change frequency. The change frequency of the first data area is between that of the other two areas, avoiding both the volatility of hot data area memory storage and the latency problem of low-speed access to cold data area, providing a basis for high-performance storage. Simultaneously, only incremental state data is generated and stored in the first data area, replacing full serialization and solving the problem of excessive time consumption caused by traversing the entire state tree in traditional solutions. To overcome the difficulty of crash state capture in browser sandbox environments, a preset service thread is set to independently execute the capture logic, periodically detecting crash events such as code anomalies, insufficient memory, and unexpected uninstallation. When the warning conditions are met, incremental data is directly read from the first data area and packaged into a dedicated crash state area, avoiding the problem of losing final states due to reliance on the main thread. Placing the crash state area in the first data area adapts to the performance and capacity characteristics of the storage medium, solving the problem of mismatch between read / write efficiency and capacity of a single storage medium.

[0024] Figure 1 This is a schematic diagram illustrating an application scenario corresponding to a browser state data capture method provided in an embodiment of this application. For example... Figure 1 As shown, the application scenario includes: terminal device 101 and browser kernel 102. The browser state data capture device includes a main thread and a preset service thread, deployed in browser kernel 102.

[0025] For example, consider a sudden memory overflow crash during user data input on a form page. When the user first loads the front-end application through the visual interface of terminal device 101, the main thread performs initialization, obtaining the number of CPU (Central Processing Unit) cores (e.g., 2 cores) and the JS heap limit (e.g., 300MB). Determining it to be a low-end device, the threshold for the second data area is set to 4 times / second. A scheduler is started once per second to calculate the data change frequency and determine the storage area for each state data based on preset node dependencies. The user enters fields such as name and address in the order submission form on the visual interface of terminal device 101. Each time a state change is triggered, incremental state data is generated according to a preset difference determination strategy and stored in the first data area. The incremental state data includes changed data, page structure fingerprints, and user operation sequence data. Then, every 200ms, preset crash events are detected. When memory usage continues to rise and exceeds the preset memory usage threshold, a memory shortage warning is triggered. A preset service thread retrieves incremental state data from the first data area and packages it for storage in the preset crash state area.

[0026] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0027] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0028] Figure 2 This is a flowchart illustrating a method for capturing browser state data according to an embodiment of this application, as shown below. Figure 2 As shown, the execution entity in this embodiment is a browser state data capture device, including a main thread and a preset service thread. This browser state data capture device can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc; alternatively, it can be implemented through a physical device integrating or installing the relevant computer program, such as a chip or electronic device. The electronic device can be a computer, etc. The browser state data capture method provided in this embodiment includes the following steps:

[0029] S201. Based on the data change frequency and preset node dependency relationship, determine the storage area of ​​each state data. The storage area includes the first data area. The data change frequency of the state data stored in the first data area is less than that of the second data area and greater than that of the third data area.

[0030] Among them, data change frequency refers to the number of times browser state data, such as form input content, component state, page routing, etc., are modified within a unit of time.

[0031] Among them, the pre-defined node dependency relationship refers to the pre-arranged association constraints between various state data nodes, representing the subordinate and associated binding characteristics of different business state nodes in data logic, page rendering, and interactive linkage. Nodes with dependency relationships often need to be read and persisted synchronously, and cannot be arbitrarily split and stored, which is a constraint condition for allocating storage areas.

[0032] The first data area, also known as the warm data area, is a storage area in the browser's local storage medium that balances read / write performance with data persistence, such as sessionStorage.

[0033] The second data area, also known as the hot data area, points to the browser memory and stores state data that changes very frequently.

[0034] The third data area, also known as the cold data area, refers to the browser's large-capacity, low-speed local storage, such as IndexedDB, which stores state data that is changed very infrequently.

[0035] It is understandable to pre-set change frequency threshold ranges for the three data areas. For example, the threshold for the second data area is set to a change frequency > 50 times / minute; the threshold for the first data area is set to 5 times / minute < change frequency ≤ 50 times / minute; and the threshold for the third data area is set to a change frequency ≤ 5 times / minute.

[0036] Specifically, the modification behavior of each type of state data is collected in real time, recording the timestamp, content, and triggering scenario of each modification. Based on the collected raw modification data, the number of changes for each type of state data is calculated within a preset time window, such as 1 minute, to obtain the initial change frequency. Simultaneously, the calculation logic is dynamically adjusted according to device performance; for example, the time window is shortened to 30 seconds on low-spec mobile devices. Finally, a standardized change frequency value for each type of state data is output. The calculated change frequency for each type of state data is compared one by one with a set threshold interval to form a preliminary partitioning result based solely on change frequency.

[0037] Furthermore, the initial partitioning results are verified on a node dependency group basis. If multiple nodes within the same dependency group are assigned to different storage areas, partition correction logic is initiated. Following the principle of prioritizing the overall integrity of dependencies and then matching change frequency, all dependency nodes in the same group are uniformly adjusted to the same storage area. During adjustment, the storage level that best matches the change frequency characteristics of most nodes in the group is selected first. If the frequency differences within the group are large, they are uniformly assigned to the first data area, thus avoiding the splitting of dependency associations and balancing read / write performance and persistence capabilities.

[0038] Optionally, the change frequency of various status data can be periodically counted. If the change frequency of a certain type of data continues to deviate from the threshold of the original allocated area, it can be migrated to a matching storage area. At the same time, the status of the storage medium can be monitored. If the occupancy rate of the second data area is too high, some non-core high-frequency data can be temporarily migrated to the first data area to avoid memory overflow.

[0039] S202. Generate incremental state data according to the preset difference determination strategy and store it in the first data area. The incremental state data includes change data, page structure fingerprint and user operation sequence data.

[0040] Among them, the preset difference determination strategy refers to a pre-defined rule system used to identify the differences between the current state data and the baseline state data of the previous version, such as the JSON Patch (JavaScript Object Notation Patch) algorithm.

[0041] Incremental state data refers to the portion of state data that changes within a certain time window.

[0042] Among them, changed data refers to the specific changes in state data, including changes in form input content, component state switching, page route navigation, and other aspects.

[0043] Among them, the page structure fingerprint refers to the unique identifier of the page's DOM structure characteristics, which is generated by the operation type, unique positioning information, and content characteristics of the page change nodes.

[0044] User operation sequence data refers to user interaction behavior information recorded in chronological order, including the trigger time, target element, and operation details of operations such as clicking, inputting, scrolling, and selecting.

[0045] Specifically, each state dispatch (state behavior) triggers a state change, and a pre-defined service thread listens for changes in the state data values ​​in the state management library's state behavior stream, such as form input or component state modifications. Simultaneously, a MutationObserver captures DOM changes, such as node additions / deletions and attribute modifications, and records every user interaction. When any type of change is detected, a pre-defined difference determination strategy is triggered to generate incremental data.

[0046] Furthermore, the system locates changed state nodes, such as the recipient's name field in an order form, and extracts only the changed content of that node, such as changing it from Zhang San to Li Si. The changed content is then standardized, such as by marking the change type (addition, modification, deletion), ultimately generating structured change data. When a change in the page DOM structure is detected, the unique location information of the changed node is determined, and the operation type of that node is recorded, such as subtree modification, attribute change, or node removal. A node signature is generated by combining the node content characteristics, and the signatures of all changed nodes are integrated hierarchically to generate a unique page structure fingerprint. During user interactions, operation details are recorded in real-time in timestamp order. The operation type, such as click, input, scroll, trigger time, and the unique identifier of the target element, are captured. The operation sequence is deduplicated and simplified, and sorted by timestamp to form an ordered user operation sequence data.

[0047] Furthermore, the generated change data, page structure fingerprint, and user operation sequence data are integrated into a complete incremental state data packet. This incremental state data packet is then asynchronously written to the first data area.

[0048] S203. Periodically check for preset crash events, which include at least one of code exception, insufficient memory, and unexpected uninstallation.

[0049] Periodic detection refers to the proactive detection of crash risks at preset fixed time intervals, such as 200 milliseconds.

[0050] Among them, the preset crash event refers to a predefined abnormal scenario that may lead to the loss of browser state data.

[0051] Among them, code exceptions refer to uncaught errors that occur during JavaScript runtime, including syntax errors, type errors, recursion stack overflow, and unhandled rejection of asynchronous operations.

[0052] Insufficient memory refers to the browser's JS heap memory usage reaching or approaching a preset threshold, or triggering the operating system's memory reclamation mechanism.

[0053] Accidental uninstallation refers to page destruction caused by actions not initiated by the user, including accidental F5 refresh, closing of tabs, mobile browser being recycled in the background, and abnormal interruption during page navigation.

[0054] Among them, the warning conditions refer to the trigger thresholds or judgment rules set for each type of preset crash event.

[0055] Optionally, for code exceptions, the warning condition is that an unhandled JS exception is captured within a single detection cycle, or the cumulative number of exceptions exceeds 3 within 1 minute. For insufficient memory, the warning condition is that the current JS heap memory usage is ≥90%, or the memory usage increases by more than 10% over 3 consecutive detection cycles. For unexpected uninstallation, the warning condition is that a page uninstallation event is detected, but no user-initiated submission is captured.

[0056] Optionally, periodic crash event detection can be performed by the main thread or by a pre-deployed service thread (Service Worker) as the main body for crash event detection.

[0057] Specifically, it monitors global exception events of the browser kernel, capturing unhandled synchronous or asynchronous error information, such as error type, trigger location, and stack trace. Captured exceptions are categorized and marked, distinguishing between minor and fatal exceptions. If a fatal exception is detected, or the number of exceptions reaches a threshold within a short period, the code exception warning conditions are immediately met.

[0058] Furthermore, by utilizing the performance monitoring interface provided by the browser, key metrics such as the current used capacity, total capacity, and memory growth rate of the JS heap memory are obtained. If the memory usage rate reaches or exceeds the threshold, or if memory usage increases rapidly for several consecutive cycles, the memory shortage warning condition is met. Events such as page uninstallation, refresh, and background switching are monitored, and the timing and source of these events are captured. The system checks for records of user-submitted operations; if an uninstallation event is detected and no valid submission record is found, the unexpected uninstallation warning condition is met.

[0059] Furthermore, at the end of each cycle, the detection thread summarizes the detection results of the three types of crash events. If any event meets the warning conditions, a warning signal is immediately generated and sent to the preset service thread through an independent communication channel, triggering the incremental state data packaging and storage process.

[0060] S204. In response to any preset crash event satisfying the corresponding first warning threshold, a preset service thread is used to obtain incremental state data from the first data area and package and store it in a preset crash state area, which is located in the first data area.

[0061] The first warning threshold is a pre-set threshold value for each type of pre-defined crash event, serving as a quantitative standard for determining whether the current operating state is about to trigger a crash. When the monitoring indicators of a crash event reach or exceed this threshold, a high-risk crash is identified, and the state data protection process must be executed immediately.

[0062] Among them, the default service thread refers to a dedicated execution unit that runs independently of the browser's main thread, such as the ServiceWorker thread, and is not affected by the main thread being stuck, encountering an exception, or being uninstalled.

[0063] The preset crash state area is a dedicated sub-area within the first data area, used to centrally store incremental state data packets when a crash warning is triggered. It has independent indexing and protection mechanisms to prevent confusion with or overwriting of regular incremental data.

[0064] Specifically, upon detecting a crash event, the type of the pre-defined crash event is marked, and read / write permissions for the first data area are locked. The pre-defined service thread retrieves the corresponding incremental status data in the first data area based on the context information of the warning signal. If incomplete incremental data fragments are detected, such as when the main thread crashes and writes are interrupted, a fragment consolidation mechanism is initiated to complete the missing fragments based on data verification rules. The pre-defined service thread integrates the retrieved incremental status data into a standardized crash status data packet, adding a unique identifier to the packet, including metadata such as the warning event type, trigger timestamp, device information, and page Uniform Resource Locator (URL). The various types of data within the data packet are structured, and data checksums, such as hash values, are added. The data packet, i.e., the snapshot object, is written using a unique key name, such as crash snapshot (CRASH_SNAPSHOT) + timestamp + page hash value.

[0065] The browser state data capture method provided in this application divides data into first, second, and third data areas based on data change frequency. This ensures that data with different change frequencies has its own suitable storage location and facilitates quick retrieval of the required state data during a crash, improving capture efficiency. Incremental state data is generated based on a preset difference determination strategy, recording only changed data, page structure fingerprints, and user operation sequence data. Compared to recording all state data completely, the incremental data volume is significantly reduced, making storage and transmission more efficient. Furthermore, by focusing only on the changed parts, it can more accurately capture the dynamic changes in browser state, avoiding redundancy and errors caused by repeatedly recording unchanged data. Moreover, the incremental state data includes changed data, page structure fingerprints, and user operation sequence data, rather than just static data, laying the foundation for restoring from static values ​​to full-scene reconstruction. By periodically detecting preset crash events such as code anomalies, insufficient memory, and unexpected uninstallation, potential browser anomalies can be detected promptly. This proactive monitoring mechanism allows the system to respond before or immediately after a crash, buying time for subsequent data saving and processing, enhancing system stability and reliability. Incremental state data is pre-stored in the first data area, eliminating the need for temporary serialization in case of a crash. Even if the main thread is stuck, the pre-defined service thread can still read data from the first data area. The crash state area remains in the first data area, reusing existing storage media without requiring additional storage resources. This adapts to the browser sandbox environment and aligns with pure front-end implementation logic.

[0066] As an optional implementation, based on any of the above embodiments, the storage area for each state data is determined based on the data change frequency and preset node dependencies, including:

[0067] Obtain current device performance data and the current load rate of each storage region.

[0068] State data storage rules are determined based on current device performance data and the current load rate of each storage area.

[0069] A preset change frequency counter is used to calculate the number of visits to each node in order to obtain the data change frequency of each state data.

[0070] The storage area for each state data is determined based on the state data storage rules, preset node dependencies, and the data change frequency of each state data.

[0071] Among them, device performance data refers to core indicators that reflect the hardware capabilities of the user's local device and the running status of the browser, including the number of CPU cores, JS heap memory, and real-time memory utilization.

[0072] Among them, the current load rate of the storage area refers to the indicator that measures the current resource saturation of the first, second and third storage areas, reflecting the amount of data stored in the area, the level of read and write requests, and the percentage of remaining available space.

[0073] Among them, status data storage rules refer to a quantitative rule system based on device performance data, used to determine the status data storage area, such as the data change frequency threshold corresponding to different performance levels of devices.

[0074] Specifically, during application initialization and periodic inspections, comprehensive data on current device performance is collected, including static hardware information such as the number of CPU cores and total memory capacity, as well as dynamic operational data such as the JS heap memory limit and the current percentage of memory used. Simultaneously, the operational status of each of the first, second, and third storage regions is sequentially monitored, and the percentage of storage space occupied, the real-time concurrency of read / write requests, and the remaining available space for each region are statistically analyzed to calculate the current load rate of each storage region.

[0075] Optionally, based on the collected device performance data, the devices are first classified into performance levels, such as high, medium, and low. For example, devices with ≥8 CPU cores and a JS heap memory limit ≥1GB are considered high-performance devices; devices with 4-8 CPU cores and a JS heap memory limit of 512MB-1GB are considered medium-performance devices. Different change frequency thresholds are set for devices of different performance levels. For example, the threshold for the second data zone of high-performance devices is a change frequency >60 times / minute, while the threshold for the first data zone is 6-60 times / minute.

[0076] Then, based on the current load of each storage region, the basic rules are dynamically adjusted. For storage regions with high load rates, the adaptation threshold is increased; for storage regions with low load rates and sufficient resource availability, the adaptation threshold is decreased.

[0077] Furthermore, a preset change frequency counter is activated to perform fine-grained counting of all state data nodes. Each state data node is assigned an independent counting identifier, and the counter runs according to a preset time window, capturing the modification / access behavior of each node in real time and outputting a standardized change frequency value for each state data node. Based on the established state data storage rules and the data change frequency of each state data, a preliminary matching of suitable candidate storage regions is performed for each state data, initially categorizing them into corresponding levels according to frequency. Then, constraint verification is performed based on preset node dependencies. If the preliminary matching results result in the same dependency group being scattered across multiple storage regions, the entire group of nodes is uniformly adjusted to the most suitable storage region. After adjustment, the final storage region corresponding to each state data node is locked.

[0078] The browser state data capture method provided in this application determines state data storage rules based on current device performance data and the current load rate of each storage area, dynamically adjusts the state data hierarchical strategy, and achieves environment-aware intelligent scheduling. Through storage allocation based on change frequency, it can accurately match data characteristics with storage resources, improving resource utilization. It comprehensively considers multiple conditions such as storage rules, change frequency, dependency constraints, and regional load in its decision-making, intelligently adjusting partition allocation when dependency conflicts occur, ensuring both logical integrity and maintaining the frequency hierarchy order of the first, second, and third data areas. This significantly improves the persistence stability of state data, the completeness of crash state capture, and the accuracy of subsequent page recovery.

[0079] As an optional implementation, based on any of the above embodiments, after determining the storage area for each state data based on the data change frequency and preset node dependencies, the method further includes:

[0080] Calculate the continuous activity level of each state data.

[0081] If the continuous activity level of any state data exceeds the preset activity threshold within a preset number of consecutive calculation cycles, the state data will be migrated to a storage area where the data change frequency is higher than that of the current storage area.

[0082] If the continuous activity level of any state data is lower than the preset activity threshold within a preset number of consecutive calculation cycles, the state data will be migrated to a storage area where the data change frequency is lower than that of the current storage area.

[0083] Among them, continuous activity refers to the comprehensive degree to which a single state data node maintains continuous and active data change behavior over multiple consecutive statistical periods, and is used to characterize the frequency of long-term stable updates of the node.

[0084] The calculation period refers to a pre-defined fixed statistical time unit, which serves as the basic time granularity for statistical status data change behavior and activity calculation, and is used for periodic batch evaluation of the activity level of each node.

[0085] The preset calculation period refers to the number of consecutive statistical periods specified in advance, which serves as an observation window for judging the trend of node activity and avoids misjudgment caused by sudden changes.

[0086] Among them, the preset activity threshold refers to the pre-set critical standard for activity, which is divided into an upper limit threshold and a lower limit threshold, serving as the quantitative basis for judging whether a node is overly active or has low activity over a long period of time.

[0087] Specifically, using a preset calculation period as the fixed time granularity, the number of changes and update density of each status data node within a single period are periodically collected. Activity quantification is performed on each status data node, the activity results for each period are recorded, and data is retained for consecutive periods.

[0088] Furthermore, by continuously observing a preset number of consecutive calculation cycles, if the continuous activity level of a certain state data node consistently exceeds the preset activity upper limit threshold throughout the entire observation window, it indicates that the node has transitioned from a medium or low-frequency state to a long-term high-frequency active state, and the response speed of its current storage area can no longer match its normalized high-frequency update requirements. Based on the storage area frequency hierarchy, the entire state data is migrated to the next higher-level storage area with a higher data change frequency. The migration process synchronously follows the preset node dependency relationships; if there are related dependent nodes, the entire group of dependent nodes is migrated upwards together, ensuring that the related data storage hierarchy is unified and the logic is not fragmented.

[0089] Optionally, within a preset number of consecutive calculation period observation windows, if the continuous activity level of a certain state data node is consistently lower than the preset activity lower limit threshold in each period, it indicates that the node has been in a low-update, low-activity state for a long time. It is unnecessary to continue occupying high-frequency, high-speed storage resources, as this would easily lead to wasted memory resources and redundant load. Based on the storage region frequency hierarchy, the state data is migrated to the next lower level storage region with a lower corresponding data change frequency. The migration also follows node dependency constraints, with related dependent nodes being moved down synchronously to avoid data synchronization anomalies caused by split storage, while simultaneously releasing the resource occupation of higher-level storage.

[0090] Understandably, if the current storage area for state data is at the highest level, such as the second data area, then when migration to a higher level is required, the current storage area should be maintained. Similarly, if the current storage area for state data is at the lowest level, such as the third data area, then when migration to a lower level is required, the current storage area should be maintained.

[0091] The browser state data capture method provided in this application, by periodically quantifying the long-term activity level of nodes, overcomes the limitations of relying solely on instantaneous change frequency for judgment. It can identify the normalized, stable activity trend of nodes and filter out interference from sudden temporary changes. Migrating high-activity nodes to higher storage areas adapts to business changes where state data shifts from low to high frequency, promptly moving long-term highly active nodes to storage areas with higher response speeds to match their high-frequency update needs and reduce read / write latency. Migrating low-activity nodes to lower storage areas promptly removes long-term inactive nodes from high-speed, high-resource-consuming high-level storage areas, freeing up valuable memory and high-speed storage resources, and reducing overall memory usage and storage area load.

[0092] As an optional implementation, based on any of the above embodiments, incremental state data is generated according to a preset difference determination strategy, including:

[0093] The rules for generating incremental state data are determined based on the hierarchical depth of the state data and the length of the difference data.

[0094] The change data is calculated using the corresponding incremental state data generation rules.

[0095] Obtain page element modification data, element attribute change data, and element removal data to determine page change nodes.

[0096] Generate a page structure fingerprint based on page change nodes.

[0097] A circular buffer with a circular overlay is used to store user operation sequence data. The fixed storage capacity of the circular buffer is the preset number of operation events.

[0098] Among them, the hierarchy depth refers to the number of tree-like levels formed after the browser state data is broken down according to business logic and page structure, representing the degree of nesting of a certain state node in the overall data structure.

[0099] Among them, the difference data length refers to the size of the data volume of the part that differs from the baseline state in the current state, and is used to measure the complexity of the changes.

[0100] Among them, the incremental status data generation rule refers to the differentiated processing rule tailored to the depth of status data hierarchy and the length of differential data, which specifies how to extract, simplify and organize change data under different nesting levels and different change volumes.

[0101] Among them, element modification data refers to structural change information such as the addition of elements, content modification, and display status changes in the subtree level of the page's DOM tree.

[0102] Among them, element attribute change data refers to the change information of the page element's own attribute values, such as style, disabled status, ID (Identifier), etc.

[0103] Among them, element removal data refers to information about the physical deletion of element nodes in the page's DOM tree.

[0104] The preset number of operation events refers to the fixed storage limit set for the circular buffer, such as limiting the storage of the most recent 100 user operation events.

[0105] Specifically, the system monitors the differences generated by each state change and assesses the scale of the difference data. Combining the depth of the hierarchy and the size of the difference, different adaptation scenarios are defined. For fine-grained changes such as form input, local attribute changes, and local component state switching, field-level change data is generated. For coarse-grained changes such as route switching, overall list refresh, and overall component reconstruction, subtree-level change data is generated. When a change in state data is detected, the system first determines the hierarchy depth of the current changing state node and the length of the difference data, matching it with the aforementioned incremental generation rules. Using the latest baseline state data as a reference, all data nodes are traversed, identifying nodes with differences and marking them as added, modified, or deleted nodes. Only relevant information from the difference nodes is extracted to generate patch data, not the full state data. Finally, the patch data is standardized to form structured change data.

[0106] Furthermore, the system monitors all structural changes to the document body (document.body), collecting three types of information in real time: element modification data, element attribute change data, and element removal data. When collecting element modification data, it focuses on changes at the subtree level, such as the node information corresponding to actions like inputting content into input boxes, adding address input boxes, or hiding or showing buttons. When collecting element attribute change data, it records the specific changes to element attributes, such as an input box changing from empty to filled. When collecting element removal data, it records the unique identifier and hierarchical path of the deleted element, such as deleted address input boxes or closed error message boxes. Finally, based on the integrated information, it locates specific page change nodes, providing a foundation for generating a page structure fingerprint. A unique node signature is generated for each page change node, containing the node operation type, a unique selector, and a content or attribute hash value. All node signatures are organized according to the hierarchical structure of the page DOM tree, forming a hierarchical signature set. A hash calculation is performed on the hierarchical signature set to generate a globally unique hash value, which is the page structure fingerprint.

[0107] Furthermore, initialize a circular buffer with a preset number of overwrite operations, setting a fixed storage capacity for the buffer based on a pre-defined number, such as 100. Monitor all user interactions in real time, including clicks, input, scrolling, and selections. Record complete information about each valid operation immediately. Write the complete information of each operation into the circular buffer in chronological order. When the buffer is full, newly captured operation data starts from the beginning of the buffer, sequentially overwriting the oldest written operation data, ensuring that the buffer always stores the most recent preset number of operation events.

[0108] Optionally, it can also be time-bound, such as storing operation events from the last 5 seconds.

[0109] The browser state data capture method provided in this application determines incremental generation rules based on layer depth and difference length, breaking through the limitation of processing all states with a unified rule, and realizing an adaptive matching generation strategy based on data nesting complexity and change volume. It calculates changed data according to corresponding rules, abandoning the traditional full snapshot method, and only extracts valid changed content based on differences, significantly reducing data generation time and memory usage. By obtaining data such as page element modification, attribute change, and removal, page change nodes are determined, enabling precise location of content that needs to be synchronized. A page structure fingerprint is generated based on page change nodes, which can be used to quickly determine whether the page structure has changed. A circular overlay buffer is used to store user operation sequence data, and its fixed storage capacity limits memory usage. When the buffer is full, new operation events will overwrite the oldest operation events, avoiding the problem of unlimited memory growth and ensuring that the system will not experience performance degradation or crashes due to insufficient memory during long-term operation. Furthermore, storing multi-dimensional incremental state data lays a good foundation for state recovery.

[0110] As an optional implementation, based on any of the above embodiments, periodically detecting preset crash events includes:

[0111] Preset error listeners and preset exception thresholds are used to determine whether the code is abnormal.

[0112] The system uses a preset timer to check the current memory usage and compares it with a preset memory threshold to determine if there is insufficient memory.

[0113] A preset uninstallation listener and historical operations are used to determine if there is any unexpected uninstallation.

[0114] In response to any preset crash event satisfying the corresponding second warning threshold, the incremental state data summary, incremental state data index and preset context identifier within the current period are obtained and packaged and stored in a data area. The second warning threshold is less than the first warning threshold.

[0115] Among them, the preset error listener refers to a pre-configured listening component used to capture JavaScript runtime errors in the browser, which can identify synchronous or asynchronous code exceptions.

[0116] Among them, the preset anomaly threshold refers to the pre-set threshold for the number or severity of anomalies, which is used to determine whether the code anomaly has reached the warning level.

[0117] Among them, the preset timed checker refers to a detection component that actively probes the browser's memory status at fixed time intervals.

[0118] Among them, the preset memory threshold refers to the critical value of memory usage that is set in advance based on device performance and browser running characteristics, such as 80%-90% of the upper limit of JS heap memory.

[0119] Among them, the preset uninstall listener is a component that specifically listens for uninstall-related events on the page, and can distinguish between normal uninstallation after the user actively submits an uninstallation and accidental uninstallation without any legitimate operation.

[0120] Among them, historical operations refer to the recent user interaction records stored in the circular buffer, which are used to determine whether there was a legitimate exit behavior before the page was uninstalled.

[0121] The second warning threshold is an early warning threshold for the risk of collapse. It has a lower warning level and is triggered earlier. Its value is less than the first warning threshold. It is used to perform lightweight data saving in the early stages of the risk.

[0122] The incremental status data summary refers to a concise summary of the incremental status data, which includes lightweight information such as core changes, data volume, and generation time.

[0123] The incremental status data index refers to the index identifier used to quickly locate and search for incremental status data, which includes the data storage location, data number, and associated node information.

[0124] Among them, the preset context identifier refers to the context information used to mark the current page's operating environment, business scenario, device status, and crash warning type.

[0125] Specifically, the listener monitors both synchronous code exceptions and uncaught rejection exceptions in asynchronous code. It categorizes captured exceptions into fatal exceptions (such as recursive stack overflows and memory overflow errors) and non-fatal exceptions (such as individual interface request failures), triggering crash warnings only for fatal exceptions. The listener summarizes the exception capture results according to a detection cycle. If a fatal exception is captured in a single cycle, or if the cumulative number of non-fatal exceptions exceeds a preset number (e.g., 5 times) within three consecutive cycles, the code is determined to have an exception and meets the crash warning conditions.

[0126] Furthermore, a pre-set timed checker is used to determine if there is insufficient memory. Each time the checker runs, it actively collects the browser's current memory usage data. The collected memory usage data is compared with a preset memory threshold. If the used memory is greater than or equal to the preset memory threshold, or if the memory usage rate increases by more than 10% for two consecutive detection cycles, then there is a risk of insufficient memory.

[0127] Furthermore, a preset uninstallation listener is used to determine if accidental uninstallation occurs. The listener focuses on monitoring events that may trigger uninstallation, such as page refresh, tab closing, browser background switching, and page redirection, while recording the time and source of each event. If the listener detects a recent legitimate operation when it captures an uninstallation event, it is considered a normal uninstallation; otherwise, it is considered an accidental uninstallation.

[0128] Understandably, at the end of each detection cycle, the results of three categories—code exceptions, insufficient memory, and unexpected uninstallation—are uniformly integrated. If any type of detection result is determined to meet the crash warning conditions, a warning signal is immediately generated and sent to the preset service thread; if none of them are met, the periodic detection continues.

[0129] Optionally, when any one of the three preset crash events reaches the corresponding second warning threshold, a lightweight data saving process is immediately initiated. Three types of information are extracted from the current period: an incremental state data summary, an incremental state data index, and a preset context identifier. The full incremental data is not retrieved to ensure lightweight execution. These three types of information are packaged in a unified format and stored in a designated location in the first data area, while simultaneously updating the storage index for subsequent fast retrieval.

[0130] The browser state data capture method provided in this application includes a preset error listener that can monitor abnormal situations during code execution in real time, enabling timely detection as soon as an abnormality occurs. A preset timed checker periodically acquires the currently used memory and compares it with a preset memory threshold. When memory approaches or exceeds the preset threshold, the system can take preventative measures. Proactive, periodic detection of preset crash events allows for timely detection and saving of state data, enabling the capture of the browser environment's final state and effectively improving the capture rate. When a second warning threshold is met, lightweight packaging and storage of summary information enables early intervention and pre-emptive saving of crash risks. This lightweight saving method does not consume significant storage and computing resources, making it suitable for long-term, frequent execution. The saved information can be quickly used for recovery and location.

[0131] As an optional implementation, based on any of the above embodiments, a preset service thread is used to obtain incremental state data from the first data area and package and store it in a preset crash state area, including:

[0132] Obtain the page unload delay lock by requesting the preset interface.

[0133] If the page unloading delay lock is successfully acquired, the incremental state data will be retrieved from the first data area and packaged and stored in the preset crash state area within the delay time window using a preset service thread.

[0134] If the page unload delay lock acquisition fails, the preset service thread will retrieve incremental state data from the first data area, package it, and send it asynchronously to the local virtual endpoint through the preset channel, so that the preset service thread can intercept the packaged incremental state data and store it in the preset crash state area.

[0135] Among them, the page unloading delay lock is a mechanism provided by the browser to temporarily block the page unloading process. After acquiring the lock, a short delay time window can be obtained, allowing the preset service thread enough time to complete the data packaging and storage.

[0136] The delay time window refers to the fixed duration obtained after the page unloads the delay lock, such as 3 seconds. It is the core time guarantee for the preset service thread to complete the incremental data reading, packaging, and storage.

[0137] Among them, the local virtual endpoint refers to a virtual address simulated locally in the browser for receiving asynchronous data transmission. It has no actual network requests and only serves as a carrier for data relay within the preset service thread.

[0138] Among them, the preset channel refers to the dedicated data transmission channel between the preset service thread and the local virtual endpoint. It has the characteristics of being asynchronous and having a high priority, and can ensure data transmission when the page unload lock fails to be acquired.

[0139] Specifically, when the preset service thread receives a crash warning signal, it triggers the process of acquiring a page unloading delayed lock. It sends an application to the browser kernel via a preset interface to acquire the unloading delayed lock, including the duration of the delay window. If no successful response is received within 500 milliseconds, the lock acquisition is considered failed, and a backup plan is immediately activated. If the page unloading delayed lock is successfully acquired, the preset service thread immediately performs data processing using the delay window. Read and write permissions for the first data area are locked to prevent incremental state data from being modified or overwritten during the reading process. Based on the context of the warning signal, such as the trigger time and page identifier, the latest incremental state data packet is retrieved from the first data area, including changed data, page structure fingerprints, and user operation sequence data. The retrieved incremental data is structured and packaged, with metadata such as the warning event type, timestamp, and data checksum added. Within the delay window, the packaged data packet is written to the preset crash state area.

[0140] Furthermore, if the page unloading delayed lock acquisition fails, the default service thread still retrieves and packages incremental state data from the first data area according to the normal process, with the packaging rules remaining consistent with those when the lock acquisition was successful. After packaging, the data packet is asynchronously sent to the local virtual endpoint through a default channel. The default service thread pre-registers the interception rules for the local virtual endpoint, and when the data packet is sent to the endpoint, it immediately intercepts it and triggers the storage process. After intercepting the data packet, the default service thread writes it to the default crash state area.

[0141] The browser state data capture method provided in this application embodiment requests and acquires a page unloading delay lock. If successful, data acquisition and storage operations are performed within the delay time window. This ensures sufficient time to completely package and store the incremental state data in the first data area into a preset crash state area before the page is completely unloaded, avoiding data loss due to premature page unloading. When the page unloading delay lock acquisition fails, it indicates that there may be an abnormal situation such as the page being unloaded immediately. In this case, an asynchronous method is used to send the data to a local virtual endpoint, and a preset service thread intercepts the data and stores it in the preset crash state area, providing an alternative solution for data storage. Even if the page is quickly unloaded, this asynchronous mechanism ensures that incremental state data is not lost, improving the reliability and fault tolerance of the system in the face of abnormal situations, thereby increasing the capture rate of state data at the moment of crash.

[0142] As an optional implementation, based on any of the above embodiments, after obtaining incremental state data from the first data area and packaging and storing it in the preset crash state area using a preset service thread, the method further includes:

[0143] Determine whether a preset crash state region exists in the first data area.

[0144] If a region timestamp exists and is less than or equal to a preset time threshold, then incremental state data after packaging is read from the preset crash state region.

[0145] Based on the page structure fingerprint, the page is restored to its pre-crash structure, and the changed data is filled into the corresponding positions on the page. In addition, the user's operations are replayed based on the timestamps of the user operation sequence data, so that the page is restored to its pre-crash state.

[0146] Among them, the regional timestamp refers to the time identifier carried by the incremental state data packets stored in the preset crash state region, which records the specific time when the data packets were generated.

[0147] The preset time threshold refers to a pre-defined time range, such as 5 minutes, used to filter valid crash data.

[0148] Specifically, when the page reloads, such as after a crash or after an unexpected uninstall and restart, the main thread accesses the root directory of the first data area to search for a unique identifier for a preset crash state region. If no identifier is found, it is determined that there is no usable crash recovery data, and the page loads according to the normal initialization process without performing any recovery operations. If a preset crash state region is determined to exist, the region timestamps of all incremental state data packets within the preset crash state region are read. The region timestamps are compared with the current time to calculate the data storage duration. If the duration is less than or equal to a preset time threshold, the data is considered valid; if it exceeds the threshold, the data is considered expired, the region is cleared, and the recovery process is terminated.

[0149] Furthermore, the valid data packet is read from the preset crash state area, and the changed data, page structure fingerprint, and user operation sequence data are parsed out. Simultaneously, data integrity is verified, such as by comparing hash values. If the data is corrupted, the data packet is skipped, and the next newer valid data packet is selected. The page structure fingerprint is parsed to extract all page change node information, such as node type, unique selector, operation type, and attribute hash value. The current page node is compared with the nodes in the fingerprint one by one according to the DOM tree hierarchy. If a changed node is missing from the current page, it is recreated and added to the corresponding level; if the node attributes do not match the fingerprint, the attributes are modified to match; if there are redundant nodes, they are removed. The display state and style attributes of the nodes are restored to ensure that the page structure and visual presentation are completely consistent with before the crash. After the structure restoration is completed, the hash value of the current page structure is checked to see if it matches the page structure fingerprint. If they do not match, the node comparison and correction are repeated until the structure matches.

[0150] Furthermore, based on the restored page structure, static data backfilling is completed. The node paths and corresponding values ​​in the changed data are parsed, and the data is accurately filled into the corresponding positions on the page. For example, form content entered before the crash is filled into the corresponding input boxes, and the selected product status is restored to the product list. The operation sequence is sorted by timestamp, and starting from the earliest operation, the actions in the operation sequence are executed one by one. Input operations simulate character input, scrolling operations adjust the page to the corresponding coordinates, and click operations trigger the click event of the target element. After playback, the user's last operation position before the crash is located, such as the cursor position in the input box or the scroll bar's stopping position, allowing the user to directly continue their previous operations without being aware that the page had crashed.

[0151] The browser state data capture method provided in this application accurately filters out crash state data within a valid time range by determining whether a preset crash state region exists in the first data area and checking whether the region's timestamp is less than or equal to a preset time threshold. This avoids using expired or invalid data for page recovery, ensuring that the data used for recovery is recent and reliable, thereby guaranteeing data availability and integrity. Restoring the page to its pre-crash structure based on the page structure fingerprint allows for rapid location of changes in the page structure and accurate restoration to the original structure. Filling the changed data into the corresponding positions on the page ensures the accuracy of the page content; the data is not lost after page recovery and remains displayed in the correct position. Replaying user operations based on the timestamps of the user operation sequence data allows for the restoration of the pre-crash operation process according to the user's actual operation order. This is not a simple static numerical restoration; it not only ensures the correctness of the page state but also makes the user's operation experience more consistent and natural.

[0152] As an optional implementation, based on any of the above embodiments, replaying user operations according to the timestamps of user operation sequence data includes:

[0153] Iterate through the user operation sequence data in ascending order of timestamps and check the stability of the page target elements corresponding to each operation event.

[0154] Calling the event triggering interface triggers the corresponding type of event on the target element of the page.

[0155] If the target element on the page is an input box, call the cursor position setting interface to restore the cursor to its position before the crash, and restore the page's scroll coordinates before the crash through the window scrolling interface.

[0156] Among them, the document selector refers to the tool provided by the browser for accurately locating elements in the DOM tree. It can find the target element corresponding to the operation event through the element's unique identifier.

[0157] Among them, the event triggering interface refers to the browser's built-in interface used to simulate and trigger user interaction events. It can accurately trigger various operation events such as clicks, inputs, scrolling, and selections, and reproduce the user's interactive behavior.

[0158] The cursor position setting interface is a dedicated interface used to adjust the cursor position within the input box. It can precisely position the cursor to the character index position before the crash, restoring the interactive state when input was interrupted.

[0159] The window scrolling interface refers to the interface used to control the page scrolling position. It can restore the page scrolling coordinates to the X and Y axis values ​​before the crash, thus restoring the user's browsing position.

[0160] Specifically, the user operation sequence data is preprocessed and traversed to extract the timestamps of all operation events and sort them in ascending order. For each sorted operation event, the unique identifier of the target element recorded in the event is extracted. Using a document selector, the corresponding target element is located in the current page's DOM tree based on this unique identifier. A stability check is performed on the target element, including whether it exists, whether its location is unique, whether its element type is consistent, and whether it is currently interactive. Events that meet the conditions are replayed normally; events that do not meet the conditions are skipped and a recovery log is recorded.

[0161] Furthermore, for each target element that has been located, the type of operation event is analyzed, such as click, character input, dropdown selection, mouse hover, etc., and matched with the corresponding event triggering interface of the browser. The event triggering interface is called to trigger the corresponding event on the target element. For click operations, a click event is triggered; for dropdown selection operations, a selection event is triggered; and for input operations, an input event is triggered one by one according to the characters recorded in the original operation.

[0162] Optionally, for input box-type target elements, additional precise restoration of the cursor and scroll position is performed. If the target element of the current operation is an input box, the cursor position before the crash is recorded in the user operation sequence data, the cursor position setting interface is called, and the cursor is precisely positioned at that position, restoring the state when the user input was interrupted. The page scroll coordinates of the last recorded operation are extracted from the user operation sequence data, and the window scrolling interface is called to scroll the page to that coordinate position. If the operation sequence contains multiple scroll operations, the scroll event is triggered sequentially according to the timestamp, eventually stopping at the scroll position before the crash.

[0163] The browser state data capture method provided in this application traverses user operation sequence data in ascending order of timestamps, ensuring that the playback strictly follows the actual order of user operations. This guarantees that the order of these operations is not disrupted, thus accurately reconstructing the user's true operation flow and making the page restoration to the state before the crash more accurate. By locating the page target element corresponding to each operation event through a document selector, the specific element targeted by the user during the operation can be accurately found, ensuring that the event is triggered on the correct element during playback. Calling the event triggering interface to trigger the corresponding type of event on the page target element can simulate the user's real operation behavior, allowing the page to produce the same changes as during the user's operation during playback, thereby ensuring the accuracy of page restoration. If the page target element is an input box, calling the cursor position setting interface restores the cursor to its position before the crash, providing the user with a more coherent and natural operating experience. Restoring the page's scroll coordinates before the crash through the window scrolling interface ensures that the page content seen by the user after playback is consistent with that before the crash, allowing the user to directly see the previously viewed content after page restoration, improving the user experience.

[0164] As an optional implementation, based on any of the above embodiments, it further includes:

[0165] In response to the page being restored to its pre-crash state, current device performance data and crash recovery data are obtained. The crash recovery data includes at least one of the following: recovery time, incremental state data volume, patch replay length, number of invalid events, and number of anomalies after recovery.

[0166] A recovery assessment result is generated based on current device performance data and crash recovery data.

[0167] The capture strategy is updated based on the recovery assessment results. The capture strategy includes at least one of the following: state data storage rules, migration rules, incremental state data generation rules, and preset crash time warning thresholds.

[0168] Crash recovery data refers to the multi-dimensional statistical data generated throughout the entire process of a page recovering from a crash to its pre-crash state. This includes key metrics such as recovery time, incremental state data volume, patch replay length, number of invalid events, and number of anomalies after recovery.

[0169] The recovery time refers to the total time taken from initiating the page crash recovery process to the page being fully restored to its pre-crash state.

[0170] The incremental state data volume refers to the total storage capacity occupied by the incremental state data packets generated during a single crash recovery.

[0171] Among them, the patch replay length refers to the total length of the number of difference data entries, the number of page structure change nodes, and the user operation replay events that need to be restored during the recovery process.

[0172] The number of invalid events refers to the total number of invalid operations and invalid change nodes that fail to locate, have no effect, are redundant, or cannot match page nodes during operation playback or page structure restoration.

[0173] Among them, the number of abnormal occurrences after recovery refers to the cumulative number of times code errors, state synchronization errors, and page rendering errors occur again within a certain observation period after the page is restored.

[0174] Specifically, once the page is fully restored to its pre-crash interactive and structural state, current device performance data is immediately collected, including hardware processing power, browser real-time memory usage, local storage read / write speed, and page rendering smoothness. Simultaneously, complete crash recovery data is collected, and the recovery time from data reading to structural restoration, data backfilling, and operation replay is calculated. The overall volume of retained incremental state data is measured. The total length of differential patches and operation sequences requiring replay is calculated. The number of node location failures and invalid execution events during replay is counted. Furthermore, during subsequent fixed observation periods, the number of new code exceptions and state errors generated after page recovery is counted. All collected metrics are standardized and unified to form a raw dataset suitable for comprehensive evaluation.

[0175] Furthermore, considering the hardware performance of the equipment, the current recovery time is assessed to determine whether it matches the reasonable time standard for that equipment. Based on the incremental data volume and patch replay length, the extent of incremental generation rules and the excessive workload of replay are evaluated. The number of invalid events is used to determine if there are any adaptation defects in page node dependency matching and element location mechanisms. Based on the number of anomalies after recovery, the stability of the current storage partition, incremental data format, and alert triggering timing are assessed to identify any potential stability risks. Considering multiple dimensions such as efficiency, data volume, replay success rate, and post-recovery stability, a clear recovery assessment result is output, indicating specific optimization directions such as performance bottlenecks, insufficient rule adaptation, and unreasonable alert thresholds.

[0176] Optionally, if the assessment shows that the recovery time is far beyond a reasonable range and the incremental data volume is too large, then update the incremental status data generation rules, optimize the data simplification logic, and prune redundant levels and invalid fields. If there are too many invalid events and nodes frequently locate anomalies, then fine-tune the status data storage rules and node migration rules, strengthen the storage constraints of dependent nodes in the same group, and optimize the activity migration judgment conditions. If memory-related crashes occur frequently or warnings are triggered too early or too late, then correct the preset crash event warning threshold and adjust the interval and critical standards between the second warning threshold and the first warning threshold in a tiered manner.

[0177] The update of state data storage rules can be achieved by retrieving all crash logs within a preset period. These logs contain core information such as the trigger time, exception type, and associated state data node identifier for each crash. The number of crashes is then categorized and statistically analyzed by state data node dimension. Nodes with a cumulative crash count ≥ a certain threshold are marked as target crash nodes. Even if a node's crash count does not meet the threshold, but a single crash results in a recovery time far exceeding the threshold, it is still included in the target crash node range. Nodes are sorted from highest to lowest crash count, with priority given to nodes with the highest crash frequency. The change frequency threshold for the second data area in the original state data storage rules is extracted; for example, if the original threshold was 50 times / minute, this threshold is lowered by a preset percentage. For instance, if the original threshold of 50 times / minute is lowered by 20%, the new threshold is 40 times / minute.

[0178] Optionally, if there are multiple target crash nodes, it is necessary to confirm the performance adaptation level of the nodes, such as low-end, medium-end, and high-end devices, and adjust the settings accordingly based on the device level.

[0179] Furthermore, the threshold adjustment results of all target crash nodes are integrated to generate updated state data storage rules. The real-time change frequency of all state data nodes is re-collected. Based on the updated second data area change frequency threshold, the change frequency of each node is compared one by one to determine the storage area of ​​each state data.

[0180] Optionally, within 24 hours after the rule update, the detection cycle can be shortened, such as from 5 minutes to 2 minutes, to monitor the storage status and page performance of the target crash node and confirm that no new crash events are triggered.

[0181] The browser state data capture method provided in this application acquires device performance data and crash recovery data, achieving full coverage of multi-dimensional indicators throughout the entire recovery process. It not only focuses on whether the recovery is successful but also quantifies recovery quality from multiple dimensions, including time consumption, data volume, replay effectiveness, and post-recovery stability. It simultaneously incorporates the actual operating performance of the device, avoiding judgments based on a single indicator detached from hardware capabilities, making the evaluation results more aligned with real-world operating scenarios. It breaks away from the crude evaluation model that uses recovery success as the sole criterion, establishing a multi-dimensional comprehensive evaluation system that can accurately pinpoint the root cause of performance bottlenecks, distinguishing between specific issues such as incremental redundancy generation, unreasonable storage partitioning, replay mechanism defects, or improper warning threshold settings. The capture strategy is updated based on the evaluation results, achieving a closed-loop self-iterative crash protection system that no longer relies on fixed static rules and can adaptively optimize based on device performance and actual crash recovery behavior.

[0182] Figure 3This is a signaling interaction flowchart of a browser state data capture method according to an embodiment of this application. The execution entity of this embodiment is a browser state data capture device deployed in the browser kernel, including a main thread and a preset service thread. It is understood that this embodiment only uses the main thread to perform capture as an example for demonstration. A separate thread can also be set up for performing capture, and this embodiment does not limit this.

[0183] like Figure 3 As shown, the browser state data capture method provided in this embodiment includes the following steps:

[0184] S301, Users perform input and other operations on the visual interface of the terminal device.

[0185] S302. After receiving a user operation, the main thread uses the resource monitoring module to obtain the current device performance data and the current load rate of each storage area.

[0186] S303: The main thread determines the state data storage rules based on the current device performance data and the current load rate of each storage area.

[0187] S304. The main thread uses a preset change frequency counter to calculate the number of times each node is accessed in order to obtain the data change frequency of each state data.

[0188] S305. The main thread's state hierarchical management module determines the storage area for each state data based on state data storage rules, preset node dependencies, and the data change frequency of each state data.

[0189] S306. Under continuous user operation, the main thread generates incremental state data based on a preset difference determination strategy.

[0190] S307. The main thread stores the incremental state data in the first data area of ​​the storage area.

[0191] S308. The main thread periodically uses the crash detection module to establish communication with the memory monitor and crash signal source to detect various preset crash events.

[0192] S309. In response to any preset crash event satisfying the corresponding first warning threshold, the differential snapshot generation module of the preset service thread obtains incremental state data from the first data area and packages it.

[0193] S310. The preset service thread stores the packaged incremental state data in the preset crash state area, which is located in the first data area.

[0194] S311. When the page is reloaded, the main thread's state recovery module reads the packaged incremental state data from the preset crash state area.

[0195] S312. The main thread restores the page to its pre-crash structure based on the page structure fingerprint, fills the changed data into the corresponding positions on the page, and replays the user's operations based on the timestamps of the user operation sequence data, so that the page is restored to its pre-crash state.

[0196] In this embodiment, the implementation method and technical effect of S301-S312 are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0197] Figure 4 This is a schematic diagram of a browser state data capture device provided in an embodiment of this application. Figure 4 As shown, the browser state data capture device provided in this embodiment is located in an electronic device. The browser state data capture device 40 provided in this embodiment includes: a determination module 41, a generation module 42, a detection module 43, and a packaging and storage module 44.

[0198] Specifically, the determination module 41 is used to determine the storage area of ​​each state data based on the data change frequency and preset node dependencies. The storage area includes a first data area, where the data change frequency of the state data stored is less than that of the second data area and greater than that of the third data area. The generation module 42 is used to generate incremental state data according to a preset difference determination strategy and store it in the first data area. The incremental state data includes changed data, page structure fingerprints, and user operation sequence data. The detection module 43 is used to periodically detect preset crash events, which include at least one of code exceptions, insufficient memory, and accidental uninstallation. The packaging and storage module 44 is used to, in response to any preset crash event satisfying the corresponding first warning threshold, use a preset service thread to obtain incremental state data from the first data area and package and store it in a preset crash state area, which is located in the first data area.

[0199] Optionally, the determining module 41, when determining the storage area for each state data based on the data change frequency and preset node dependencies, is specifically used for: obtaining current device performance data and the current load rate of each storage area; determining state data storage rules based on the current device performance data and the current load rate of each storage area; calculating the number of accesses to each node using a preset change frequency counter to obtain the data change frequency of each state data; and determining the storage area for each state data according to the state data storage rules, preset node dependencies, and the data change frequency of each state data.

[0200] Optionally, the browser state data capture device provided in this application further includes a calculation module and a migration module.

[0201] Accordingly, the calculation module is used to calculate the continuous activity level of each state data; the migration module is used to migrate the state data to a storage area with a higher data change frequency than the current storage area if the continuous activity level of any state data is higher than the preset activity threshold within a preset number of consecutive calculation cycles; and to migrate the state data to a storage area with a lower data change frequency than the current storage area if the continuous activity level of any state data is lower than the preset activity threshold within a preset number of consecutive calculation cycles.

[0202] Optionally, the generation module 42, when generating incremental state data according to the preset difference determination strategy, is specifically used for: determining the incremental state data generation rules based on the hierarchical depth of the state data and the length of the difference data; calculating the change data using the corresponding incremental state data generation rules; obtaining the element modification data, element attribute change data, and element removal data of the page to determine the page change nodes; generating the page structure fingerprint based on the page change nodes; and storing the user operation sequence data using a circular overlay ring buffer, wherein the fixed storage capacity of the ring buffer is a preset number of operation events.

[0203] Optionally, the detection module 43, when periodically detecting each preset crash event, is specifically used to: determine whether the code is abnormal by using a preset error listener and a preset exception threshold; obtain the currently used memory through a preset timer checker and compare it with a preset memory threshold to determine whether there is insufficient memory; determine whether there is an unexpected uninstallation by using a preset uninstall listener and historical operations; and in response to any preset crash event satisfying the corresponding second warning threshold, obtain the incremental state data summary, incremental state data index and preset context identifier within the current period, and package and store them in a data area, wherein the second warning threshold is less than the first warning threshold.

[0204] Optionally, the packaging and storage module 44, when using a preset service thread to obtain incremental state data from the first data area and package and store it in the preset crash state area, specifically performs the following: requesting and obtaining a page unloading delay lock through a preset interface; if the page unloading delay lock is successfully obtained, then using the preset service thread to obtain incremental state data from the first data area and package and store it in the preset crash state area within the delay time window; if the page unloading delay lock is not obtained, then using the preset service thread to obtain incremental state data from the first data area, package it, and asynchronously send it to the local virtual endpoint through a preset channel, so that the preset service thread intercepts the packaged incremental state data and stores it in the preset crash state area.

[0205] Optionally, the browser state data capture device provided in this application also includes a state recovery module.

[0206] Correspondingly, the state recovery module is used to determine whether a preset crash state region exists in the first data area; if it exists and the region timestamp is less than or equal to a preset time threshold, then the packaged incremental state data is read from the preset crash state region; the page is restored to the structure before the crash based on the page structure fingerprint, and the changed data is filled into the corresponding position of the page; and the user operation is replayed according to the timestamp of the user operation sequence data so that the page is restored to the state before the crash.

[0207] Optionally, the state recovery module is also used to traverse the user operation sequence data in ascending order by timestamp and detect the stability of the page target element corresponding to each operation event; call the event triggering interface to trigger the corresponding type of event on the page target element; if the page target element is an input box, call the cursor position setting interface to restore the cursor to the position before the crash, and restore the scroll coordinates of the page before the crash through the window scrolling interface.

[0208] Optionally, the browser state data capturing device provided in this application further includes an acquisition module and an update module.

[0209] Accordingly, the acquisition module is used to acquire current device performance data and crash recovery data in response to the page being restored to the state before the crash. The crash recovery data includes at least one of the following: recovery time, incremental state data volume, patch replay length, number of invalid events, and number of anomalies after recovery. The generation module 42 is also used to generate a recovery evaluation result based on the current device performance data and the crash recovery data. The update module is used to update the capture strategy according to the recovery evaluation result. The capture strategy includes at least one of the following: state data storage rules, migration rules, incremental state data generation rules, and preset crash time warning threshold.

[0210] It should be noted that the technical effects of the browser state data capture device used in this embodiment have been explained in the embodiments of the browser state data capture method described above, and therefore will not be repeated in this embodiment.

[0211] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 51 and a memory 52. ​​Optionally, the electronic device 50 further includes a communication component 53. The processor 51, memory 52, and communication component 53 are connected via a bus.

[0212] In a specific implementation, at least one processor 51 executes computer execution instructions stored in memory 52, causing at least one processor 51 to execute the above-described embodiment of the browser state data capture method.

[0213] The specific implementation process of processor 51 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0214] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0215] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0216] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0217] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above-described browser state data capture method embodiments when running.

[0218] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0219] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described browser state data capture method embodiments.

[0220] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described browser state data capture method embodiments.

[0221] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0222] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0223] The foregoing has provided a detailed description of a browser state data capture method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for capturing browser state data, characterized in that, include: The storage area for each state data is determined based on the data change frequency and the preset node dependency relationship. The storage area includes a first data area, where the data change frequency of the state data stored in the first data area is less than that of the second data area and greater than that of the third data area. Incremental state data is generated and stored in the first data area according to a preset difference determination strategy. The incremental state data includes change data, page structure fingerprint, and user operation sequence data. Periodically detect each preset crash event, which includes at least one of code exception, insufficient memory, and unexpected uninstallation; In response to any preset crash event meeting the corresponding first warning threshold, a preset service thread retrieves incremental status data from the first data area and packages and stores it in a preset crash status area. The preset crash status area is a dedicated sub-area within the first data area, used to centrally store incremental status data packets when a crash warning is triggered. The preset service thread is an execution unit that runs independently of the browser's main thread.

2. The method according to claim 1, characterized in that, The process of determining the storage area for each state data based on data change frequency and preset node dependencies includes: Obtain current device performance data and the current load rate of each storage region; The status data storage rules are determined based on the current device performance data and the current load rate of each storage area. A preset change frequency counter is used to calculate the number of visits to each node in order to obtain the data change frequency of each state data. The storage area for each state data is determined based on the state data storage rules, preset node dependencies, and the data change frequency of each state data.

3. The method according to claim 2, characterized in that, After determining the storage area for each state data based on the data change frequency and preset node dependencies, the method further includes: Calculate the continuous activity level of each state data; If the continuous activity level of any state data is higher than the preset activity threshold within a preset number of consecutive calculation cycles, the state data will be migrated to a storage area where the data change frequency is higher than that of the current storage area. If the continuous activity level of any state data is lower than the preset activity threshold within a preset number of consecutive calculation cycles, the state data will be migrated to a storage area where the data change frequency is lower than that of the current storage area.

4. The method according to claim 1, characterized in that, The step of generating incremental state data based on a preset difference determination strategy includes: The rules for generating incremental state data are determined based on the hierarchical depth of the state data and the length of the differential data. The change data is calculated using the corresponding incremental state data generation rules. Obtain page element modification data, element attribute change data, and element removal data to determine page change nodes; Generate page structure fingerprints based on page change nodes; A circular buffer with a circular overlay is used to store user operation sequence data, and the fixed storage capacity of the circular buffer is a preset number of operation events.

5. The method according to claim 1, characterized in that, The periodic detection of each preset crash event includes: Use preset error listeners and preset exception thresholds to determine if the code is abnormal; The current used memory is obtained by a preset timer checker and compared with a preset memory threshold to determine whether there is insufficient memory. A preset uninstallation listener and historical operations are used to determine if there is any accidental uninstallation. In response to any preset crash event satisfying the corresponding second warning threshold, the incremental state data summary, incremental state data index and preset context identifier within the current period are obtained and packaged and stored in a data area, wherein the second warning threshold is less than the first warning threshold.

6. The method according to claim 1, characterized in that, The step of using a preset service thread to obtain incremental state data from the first data area and package and store it in a preset crash state area includes: Obtain the page uninstallation delay lock by requesting the preset interface; If the page unloading delay lock is successfully acquired, then within the delay time window, a preset service thread will be used to retrieve incremental state data from the first data area and package and store it in the preset crash state area. If the page unloading delay lock acquisition fails, a preset service thread will retrieve incremental state data from the first data area, package it, and asynchronously send it to the local virtual endpoint through a preset channel, so that the preset service thread can intercept the packaged incremental state data and store it in the preset crash state area.

7. The method according to claim 2, characterized in that, After the step of using a preset service thread to obtain incremental state data from the first data area and package and store it in the preset crash state area, the method further includes: Determine whether a preset crash state region exists in the first data area; If a region timestamp exists and is less than or equal to a preset time threshold, then the packaged incremental state data is read from the preset crash state region. Based on the page structure fingerprint, the page is restored to its pre-crash structure, and the changed data is filled into the corresponding positions on the page. In addition, the user's operations are replayed according to the timestamps of the user operation sequence data, so that the page is restored to its pre-crash state.

8. The method according to claim 7, characterized in that, The step of replaying user operations based on the timestamps of user operation sequence data includes: Traverse the user operation sequence data in ascending order of timestamp and check the stability of the page target element corresponding to each operation event; The event triggering interface is invoked to trigger an event of the corresponding type on the target element of the page. If the target element on the page is an input box, call the cursor position setting interface to restore the cursor to its position before the crash, and restore the page's scroll coordinates before the crash through the window scrolling interface.

9. The method according to claim 7, characterized in that, Also includes: In response to the page being restored to its pre-crash state, the device acquires current device performance data and crash recovery data, wherein the crash recovery data includes at least one of the following: recovery time, incremental state data volume, patch replay length, number of invalid events, and number of anomalies after recovery. Generate recovery assessment results based on current device performance data and crash recovery data; The capture strategy is updated based on the recovery assessment results. The capture strategy includes at least one of the following: state data storage rules, migration rules, incremental state data generation rules, and preset crash time warning threshold.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as described in any one of claims 1 to 9.

Images