A page data saving method, device, apparatus and storage medium

Abstract

The application discloses a page data saving method, device and equipment and a storage medium. According to a pre-established page life cycle monitoring mechanism, the state change of a page is monitored in real time. A saving task is constructed in real time based on the state change of the page, and is saved into a task queue of browser structured storage. The saving task in the task queue is sent to a server, and a sending result is determined. If the sending result is a sending failure, the saving task is resent, the step of determining the sending result is returned to be executed until the number of resending reaches a preset upper limit, a sending failure label is marked and saved in storage. When it is identified that the page is initialized, the saving task marked with the sending failure label is loaded from the storage and resent. The application discards the timing saving mechanism of the existing scheme, realizes dynamic data saving and sending according to the real-time change state of the page, and reduces data loss.

Description

Technical Field

[0001] This application relates to the field of page data storage technology, specifically to a page data storage method, apparatus, device, and storage medium. Background Technology

[0002] In web applications, reliable data storage is a core user experience metric. Users may spend a significant amount of time editing complex forms, and any data loss due to unexpected page closures, browser crashes, or network fluctuations can cause serious user losses and negative experiences. Traditional data storage methods rely on users actively clicking the save button during editing to synchronously send the data to the server. However, in practice, many users forget to manually save, accidentally close tabs, or experience unexpected browser crashes, resulting in the permanent loss of entered but unsaved data.

[0003] To address the aforementioned issues, an automatic saving solution has been developed, which involves periodically sending form data to the server during the user's editing process. However, this timing mechanism is very rigid and cannot dynamically save and send data based on real-time changes in the page, which can easily lead to data loss. Summary of the Invention

[0004] In view of this, this application provides a page data saving method, apparatus, device and storage medium to solve the problem that the existing timing mechanism is very rigid and cannot realize dynamic data saving and sending according to the real-time changes of the page, which easily leads to data loss.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] Firstly, a method for saving page data includes:

[0007] Based on a pre-established page lifecycle monitoring mechanism, monitor page state changes in real time;

[0008] Based on the changes in the page's state, a save task is constructed in real time and saved to the browser's structured storage task queue;

[0009] Send the saved tasks in the task queue to the server and determine the sending result;

[0010] If the sending result is a sending failure, then resend and return to the step of determining the sending result, until the number of resends reaches a preset limit, then mark the sending failure tag and save it in storage;

[0011] When the page is identified as being initialized, the saved task marked with a sending failure tag is loaded from the storage and resent.

[0012] Preferably, the step of monitoring page state changes in real time according to a pre-established page lifecycle monitoring mechanism includes:

[0013] The page lifecycle monitoring mechanism includes a page visibility change event listener, a freeze event listener, and a page hide event listener.

[0014] The page visibility change event listener is used to listen for page visibility change events in real time;

[0015] The freeze event listener is used to monitor freeze events in the browser where the page is located in real time.

[0016] The page hiding event listener is used to monitor in real time whether the page is prone to being uninstalled or cached.

[0017] A state change is determined when one or more of the following events are detected: visibility change event, freeze event, unloaded tendency event, or cached tendency event.

[0018] Preferably, the step of constructing and saving the task in real time based on the state changes of the page includes:

[0019] When the page changes from a visible active state to a visible inactive state, the accumulated data changes before the change are constructed into a save task;

[0020] When the page changes from a visible state to a hidden state, the current data is compared with the data when the save task was last built, and the data with the difference is used to build the save task.

[0021] When the page changes from a visible or hidden state to a frozen state, tasks that have not been marked with persistent tags are extracted from the storage to construct a save task;

[0022] When the page changes from a frozen state to a visible state, the tasks marked with the "sent failure" tag in the storage are saved as tasks.

[0023] Preferably, sending the saved tasks in the task queue to the server includes:

[0024] If the state change corresponding to the save task when it is constructed is from visible active state to visible inactive state, then the delayed send interface is called to send it to the server.

[0025] If the state change corresponding to the save task when it is constructed is from visible to hidden, or from frozen to visible, then the keep-alive sending interface is called to send it to the server.

[0026] If the state change corresponding to the save task during its construction is from visible or hidden to frozen, then the asynchronous beacon interface is invoked to send it to the server.

[0027] Preferably, it further includes:

[0028] Real-time monitoring of the status of the delayed transmission interface and the keep-alive transmission interface;

[0029] If the delayed sending interface is available, the saved task is used as the request body, and an activation delay time is set. The delayed sending interface is called when the page is closed or when the activation delay time is reached.

[0030] If the delayed transmission interface is unavailable, it is switched to the asynchronous beacon interface to invoke the asynchronous beacon interface;

[0031] If the asynchronous beacon interface fails to connect with the save task, it will be switched to the keep-alive sending interface, which will then be invoked.

[0032] Preferably, determining the sending result includes:

[0033] Establish a send request for the aforementioned save task;

[0034] Determine the interface invoked when sending the save task to the server;

[0035] If the interface being called is a delayed sending interface, the activation status identifier of the sending request is checked periodically. If the activation status is detected as activated, the sending is determined to be successful; if the activation status is not detected within the preset timeout period, the sending is determined to be unsuccessful.

[0036] If the interface being called is an asynchronous beacon interface, then the return identifier of the asynchronous beacon interface is obtained to determine the sending result;

[0037] If the interface called is a keep-alive sending interface, then wait for the response returned by the server and determine the sending result based on the response.

[0038] Secondly, a page data storage device includes:

[0039] The state change monitoring module is used to monitor page state changes in real time according to a pre-established page lifecycle monitoring mechanism.

[0040] A save task construction module is used to construct save tasks in real time based on the state changes of the page and save them to the task queue of the browser's structured storage;

[0041] The task sending module is used to send the saved tasks in the task queue to the server and determine the sending result;

[0042] The judgment module is used to resend the data if the sending result is a sending failure, return to the step of determining the sending result, and continue until the number of resends reaches a preset limit. The sending failure tag is then marked and saved in storage.

[0043] The resend module is used to load the saved task marked with a sending failure tag from the storage and resend it when the page is detected to be initializing.

[0044] Preferably, the task sending module includes:

[0045] A request creation module is used to create a request for sending the saved task.

[0046] The interface call determination module is used to determine the interface called when the saving task is sent to the server.

[0047] The first judgment module for sending results is used to periodically check the activation status identifier of the sending request if the interface being called is a delayed sending interface. If the activation status is detected as activated, the sending is determined to be successful; if the activation status is not detected within a preset timeout period, the sending is determined to be unsuccessful.

[0048] The second judgment module for sending results is used to determine the sending result by obtaining the return identifier of the asynchronous beacon interface if the called interface is an asynchronous beacon interface;

[0049] The third judgment module for sending results is used to wait for the response returned by the server if the called interface is a keep-alive sending interface, and determine the sending result based on the response.

[0050] Thirdly, a page data storage device, including a memory and a processor;

[0051] The memory is used to store programs;

[0052] The processor is configured to execute the program to implement the various steps of the page data saving method as described in any of the first aspects.

[0053] Fourthly, a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the page data saving method as described in any of the first aspects.

[0054] As can be seen from the above technical solution, this application monitors page state changes in real time based on a pre-established page lifecycle monitoring mechanism; constructs a save task in real time based on the page state changes and saves it to the task queue of the browser's structured storage; sends the save task in the task queue to the server and determines the sending result; if the sending result is a sending failure, it resends and returns to the step of determining the sending result until the number of resends reaches a preset limit, marks the sending failure tag and saves it in storage; when the page is detected to be initializing, it loads the save task marked with the sending failure tag from the storage and resends it. This application first transforms the timing of data capture from rigid timed intervals to dynamic event streams through real-time monitoring, thereby obtaining the most timely state change information. Based on this, persistent tasks stored locally are constructed to achieve the first layer of data storage. Then, the data is sent to the server to determine the sending result. The sending result means that each save task has a clear final state, and success or failure is traceable. If the sending fails, it is resent. After reaching a preset limit, the task is tagged as having failed and saved in storage. Retrying can strive to send the save task to the server as quickly as possible in the event of temporary problems such as network fluctuations. Then, during subsequent page initialization, the save tasks marked with the sending failure tag can be loaded from storage and resent. This ensures that the previously accumulated failed save tasks are not forgotten due to users closing the page or restarting the browser, but are automatically awakened and re-attempted for synchronization during the next initialization, ensuring that the data is not lost. Attached Figure Description

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

[0056] Figure 1 An optional flowchart of a page data saving method provided in an embodiment of this application;

[0057] Figure 2 A schematic diagram of a page data storage device provided in an embodiment of this application;

[0058] Figure 3 This is a schematic diagram of the structure of a page data storage device provided in an embodiment of this application. Detailed Implementation

[0059] 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, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0060] This invention can be used in a wide variety of general-purpose or special-purpose computing environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.

[0061] This invention provides a method for saving page data. This method can be applied to various computer terminals or smart terminals, and its execution entity can be the processor or server of the computer terminal or smart terminal. The flowchart of the method is shown below. Figure 1 As shown, it specifically includes:

[0062] S1: Based on a pre-established page lifecycle monitoring mechanism, monitor page state changes in real time.

[0063] With a pre-established listening mechanism, the page no longer relies on fixed time intervals, but can instantly perceive every user interaction with the page, changes in page content, or other state changes, ensuring that data changes can be captured in a timely manner from the source.

[0064] S2: Based on the changes in the state of the page, a save task is constructed in real time and saved to the task queue of the browser's structured storage.

[0065] Based on the monitored changes in the page state, the page data is constructed into a save task and written to the browser's local structured storage. This fundamentally decouples the data saving and network transmission processes, so the persistence of data is no longer subject to the server's response speed or network conditions. Even if the page suddenly crashes or is closed, the changed data has already been solidified locally.

[0066] S3: Send the saved tasks in the task queue to the server and determine the sending result.

[0067] Retrieve and save tasks from the local task queue, send them, and confirm their delivery status. This enables the formal synchronization of local persistent data to the server, providing a precise basis for subsequent reliability assurance and avoiding the chaos of duplicate or missed data submissions.

[0068] S4: If the sending result is a sending failure, resend and return to the step of determining the sending result until the number of resends reaches a preset limit, mark the sending failure tag and save it in storage.

[0069] This application sets up a retry mechanism with a maximum number of attempts for scenarios where transmission fails. When the maximum number of retries is reached, a persistent failure label is attached to the data, thereby safely isolating and saving the abnormal data, avoiding an infinite loop, and allowing for focused processing in subsequent processes.

[0070] S5: When the page is detected to be initializing, load the saved task marked with the sending failure tag from the storage and resend it.

[0071] Once the page initialization is detected, the system actively loads and retryes those saved tasks that have been marked as failed. This ensures that data that cannot be synchronized temporarily due to special circumstances can be synchronized again as soon as the application restarts, guaranteeing that the recovery of user data is completely automatic and transparent, without any manual intervention.

[0072] As can be seen from the above technical solution, this application monitors page state changes in real time based on a pre-established page lifecycle monitoring mechanism; constructs a save task in real time based on the page state changes and saves it to the task queue of the browser's structured storage; sends the save task in the task queue to the server and determines the sending result; if the sending result is a sending failure, it resends and returns to the step of determining the sending result until the number of resends reaches a preset limit, marks the sending failure tag and saves it in storage; when the page is detected to be initializing, it loads the save task marked with the sending failure tag from the storage and resends it. This application first transforms the timing of data capture from rigid timed intervals to dynamic event streams through real-time monitoring, thereby obtaining the most timely state change information. Based on this, persistent tasks stored locally are constructed to achieve the first layer of data storage. Then, the data is sent to the server to determine the sending result. The sending result means that each save task has a clear final state, and success or failure is traceable. If the sending fails, it is resent. After reaching a preset limit, the task is tagged as having failed and saved in storage. Retrying can strive to send the save task to the server as quickly as possible in the event of temporary problems such as network fluctuations. Then, during subsequent page initialization, the save tasks marked with the sending failure tag can be loaded from storage and resent. This ensures that the previously accumulated failed save tasks are not forgotten due to users closing the page or restarting the browser, but are automatically awakened and re-attempted for synchronization during the next initialization, ensuring that the data is not lost.

[0073] The method provided in this embodiment of the invention involves a process of real-time monitoring of page state changes based on a pre-established page lifecycle monitoring mechanism, as detailed below:

[0074] The page lifecycle monitoring mechanism includes a page visibility change event listener, a freeze event listener, and a page hide event listener.

[0075] The page visibility change event listener is used to listen for page visibility change events in real time;

[0076] The freeze event listener is used to monitor freeze events in the browser where the page is located in real time.

[0077] The page hiding event listener is used to monitor in real time whether the page is prone to being uninstalled or cached.

[0078] A state change is determined when one or more of the following events are detected: visibility change event, freeze event, unloaded tendency event, or cached tendency event.

[0079] Specifically, this application deploys three types of listeners, which monitor changes in different dimensions of the page:

[0080] Page visibility change event listeners monitor whether the user is still viewing the page. Browsers provide two visibility states: one is that the page is completely invisible, such as when the user switches to another tab; the other is that the page becomes visible again, when the user switches back. Both situations indicate a change in the page's runtime environment. When the page is invisible, the browser may reduce resource allocation; when it becomes visible again, it's necessary to confirm whether the previous state of the page remains intact. Simply checking if the page content has been modified by the user is insufficient; it's also necessary to know if the page itself was temporarily suspended by the user.

[0081] A freeze event listener monitors whether the browser is about to freeze a page. Modern browsers freeze background tabs to save memory and CPU. After freezing, JavaScript execution on the page is completely suspended, timers are stopped, and network requests are interrupted. Therefore, if this event is not specifically monitored, developers will not be aware that the page is about to be frozen. Ongoing asynchronous operations and unprocessed data in memory will be suspended until the browser may directly discard the page. This listener can intercept this signal before the freeze occurs.

[0082] Page hiding event listeners listen for events that indicate a tendency for the page to be unloaded or cached. In other words, an unload tendency means that the page is about to be closed or the navigation is left, and the browser will trigger related events, and the page will soon disappear. A cache tendency means that the page may be put into the browser's round-trip cache. Although the page is not destroyed, the execution context will be paused and resumed. For both of these situations, emergency handling needs to be completed before the page leaves the current execution state.

[0083] The process of constructing and saving tasks in real time based on the state changes of the page in this application will be described in detail below.

[0084] When the page changes from a visible active state to a visible inactive state, the accumulated data changes before the change are constructed into a save task;

[0085] When the page changes from a visible state to a hidden state, the current data is compared with the data when the save task was last built, and the data with the difference is used to build the save task.

[0086] When the page changes from a visible or hidden state to a frozen state, tasks that have not been marked with persistent tags are extracted from the storage to construct a save task;

[0087] When the page changes from a frozen state to a visible state, the tasks marked with the "sent failure" tag in the storage are saved as tasks.

[0088] Specifically, when a page transitions from a visible active state to a visible inactive state, it means that the page is still visible, but the user has stopped interacting with it, indicating that the current round of editing has ended. The strategy at this time is to package all the data changes accumulated since the last task was built into a save task all at once. This proactively captures user behavior and encapsulates the data while the page's operating environment is still stable, rather than waiting for the next risk event to trigger a passive response, thus reducing the time that unsaved data remains in memory.

[0089] The transition from a visible state to a hidden state refers to the page about to disappear from the user's view, such as when switching tabs, minimizing windows, or unloading the page. This process takes very little time and there isn't enough time to perform full processing. Therefore, we need to compare the current data with the baseline data from the last time the task was built and saved, and only extract the changed parts to build the task. This ensures that critical data is not lost and also reduces the processing volume, ensuring that local writing can be completed quickly before the page is hidden.

[0090] When a page transitions from a visible or hidden state to a frozen state, it means the browser is about to freeze the page, and the JS thread will be completely suspended. This is a relatively urgent state, so it is necessary to find those tasks that have not yet been marked as persistent in the local storage, such as tasks that were previously built but have not yet been successfully sent to the server, including tasks that were not successfully sent, or tasks that have been successfully sent but have not yet been confirmed.

[0091] The transition from a frozen state to a visible state means that the page recovers from freezing and regains its execution capability. At this point, the tasks marked as failed to send are directly loaded from storage and put into the sending process as new saved tasks. These tasks were left over from previous retries that failed to reach the server. Unfreezing the page means a completely new execution context and possible network recovery. Task sending is achieved at this point, and data recovery can be achieved without waiting for any user operation.

[0092] The following embodiments provide a detailed explanation of the steps in this application for sending saved tasks in the task queue to the server.

[0093] If the state change corresponding to the save task when it is constructed is from visible active state to visible inactive state, then the delayed send interface is called to send it to the server.

[0094] If the state change corresponding to the save task when it is constructed is from visible to hidden, or from frozen to visible, then the keep-alive sending interface is called to send it to the server.

[0095] If the state change corresponding to the save task during its construction is from visible or hidden to frozen, then the asynchronous beacon interface is invoked to send it to the server.

[0096] Specifically, the division of these three sending interfaces is essentially based on the different tolerance levels of the page's current state for sending behavior, matching different priority network request methods.

[0097] When the page is still running normally and the user has only temporarily stopped interacting without the risk of closing or leaving the page, there is no need to rush. In this case, the sending can be slightly delayed, such as by merging multiple tasks and sending them later, or by lowering the priority of the request to avoid dense network requests crowding out the browser's main thread resources. Therefore, using a delayed sending interface is to maintain high performance while ensuring data security.

[0098] The keep-alive sending interface addresses two scenarios: one is the save task built when the page changes from visible to hidden, and the other is the save task built when the page recovers from frozen to visible. The common point of these two scenarios is that the current lifecycle of the page is unstable. Hiding means that the page may be unloaded at any time, and recovering from frozen means that it has just woken up from a suspended state, and the network environment and execution context need to be re-established. Therefore, these tasks cannot wait, otherwise the window may close. It is necessary to call the keep-alive sending interface. The request will carry a flag to keep the connection alive. Even at the boundary of the page being about to be exited, the browser will try its best to ensure that the request is sent and strive to complete the sending within a limited time.

[0099] When the window of time before the freeze occurs is very short, the JS thread is about to be suspended, and regular network requests are likely to be interrupted before they are sent, calling the asynchronous beacon interface will cause the browser to put the request in the background, ensuring that data is still sent out even after the page is frozen or closed, without blocking the page from freezing.

[0100] Optionally, this application also includes:

[0101] When calling the above interfaces, the status of the delayed sending interface and the keep-alive sending interface is monitored in real time;

[0102] If the delayed sending interface is available, the saved task is used as the request body, and an activation delay time is set. The delayed sending interface is called when the page is closed or when the activation delay time is reached.

[0103] If the delayed transmission interface is unavailable, it is switched to the asynchronous beacon interface to invoke the asynchronous beacon interface;

[0104] If the asynchronous beacon interface fails to connect with the save task, it will be switched to the keep-alive sending interface, which will then be invoked.

[0105] Specifically, when the delayed sending interface is available, the save task is packaged into a request body, and an activation delay time is set. There is a dual trigger mechanism here: either it waits for the delay time to expire normally before sending, or if the page is suddenly closed during this waiting period, it will also trigger sending immediately to ensure basic page performance. If the delayed sending interface is detected to be unavailable, such as because the browser does not support it or it is disabled in the current environment, the already determined interface is directly downgraded to the asynchronous beacon interface for sending. The asynchronous beacon interface may also fail to connect, such as if the data volume exceeds the limit or the request body format is not accepted. Therefore, if the connection fails, the keep-alive sending interface is used instead. This hierarchical degrading mechanism ensures the success rate of the task at the time of sending.

[0106] Furthermore, the process of determining the transmission result may include the following steps:

[0107] Establish a send request for the aforementioned save task;

[0108] Determine the interface invoked when sending the save task to the server;

[0109] If the interface being called is a delayed sending interface, the activation status identifier of the sending request is checked periodically. If the activation status is detected as activated, the sending is determined to be successful; if the activation status is not detected within the preset timeout period, the sending is determined to be unsuccessful.

[0110] If the interface being called is an asynchronous beacon interface, then the return identifier of the asynchronous beacon interface is obtained to determine the sending result;

[0111] If the interface called is a keep-alive sending interface, then wait for the response returned by the server and determine the sending result based on the response.

[0112] Specifically, the delayed sending interface works by setting a delay timer and suspending the request. It is then activated and sent when the timer expires or the page is closed. It does not execute the sending action immediately after the call, so the sending result cannot be obtained immediately. Therefore, the activation status flag of this request is periodically polled. When the activation status flag changes from inactive to active, it means that the delay condition has been met, and the sending is considered successful. If the activation status is not reached within the preset timeout period, it means that the delay mechanism may be stuck, and the sending is considered to have failed.

[0113] The characteristic of asynchronous beacon interfaces is that the browser guarantees delivery after the request is sent, but it does not wait for the server response or provide a callback. The caller does not receive the traditional HTTP response code and response body, but only a boolean return flag indicating whether the browser has successfully added the request to the background queue. Therefore, this return flag can be obtained directly. If the return is successful, it means that the request has been handed over to the browser's backend to ensure delivery, and the sending is considered successful. If the return fails, it means that there is a problem with the integration, such as exceeding the data limit or invalid format, and the sending is considered to have failed.

[0114] The keep-alive sending interface is a regular HTTP request with a liveness flag, and the server will process it normally and return a response. Therefore, the method of judgment is to synchronously wait for the HTTP response returned by the server, and use the response status code and response body to determine the sending result. For example, if the status code is in the 2xx range, it is considered a success; if it is 4xx or 5xx, it is considered a failure; and if the network is interrupted, it is also considered a failure.

[0115] and Figure 1 Corresponding to the method described above, this embodiment of the invention also provides a page data storage device for storing page data. Figure 1In the specific implementation of the method, the page data saving device provided in this embodiment of the invention can be used in computer terminals or various mobile devices, combined with Figure 2 The page data storage device is introduced, such as... Figure 2 As shown, the device may include:

[0116] The state change monitoring module 10 is used to monitor the state changes of the page in real time according to the pre-established page lifecycle monitoring mechanism.

[0117] The save task construction module 20 is used to construct save tasks in real time based on the state changes of the page and save them to the task queue of the browser's structured storage.

[0118] The task sending module 30 is used to send the saved tasks in the task queue to the server and determine the sending result;

[0119] The judgment module 40 is used to resend if the sending result is a sending failure, return to the step of determining the sending result, until the number of resends reaches a preset limit, mark the sending failure tag and save it in storage;

[0120] The resend module 50 is used to load the saved task marked with a sending failure tag from the storage and resend it when the page is identified as being initialized.

[0121] As can be seen from the above technical solution, this application monitors page state changes in real time based on a pre-established page lifecycle monitoring mechanism; constructs a save task in real time based on the page state changes and saves it to the task queue of the browser's structured storage; sends the save task in the task queue to the server and determines the sending result; if the sending result is a sending failure, it resends and returns to the step of determining the sending result until the number of resends reaches a preset limit, marks the sending failure tag and saves it in storage; when the page is detected to be initializing, it loads the save task marked with the sending failure tag from the storage and resends it. This application first transforms the timing of data capture from rigid timed intervals to dynamic event streams through real-time monitoring, thereby obtaining the most timely state change information. Based on this, persistent tasks stored locally are constructed to achieve the first layer of data storage. Then, the data is sent to the server to determine the sending result. The sending result means that each save task has a clear final state, and success or failure is traceable. If the sending fails, it is resent. After reaching a preset limit, the task is tagged as having failed and saved in storage. Retrying can strive to send the save task to the server as quickly as possible in the event of temporary problems such as network fluctuations. Then, during subsequent page initialization, the save tasks marked with the sending failure tag can be loaded from storage and resent. This ensures that the previously accumulated failed save tasks are not forgotten due to users closing the page or restarting the browser, but are automatically awakened and re-attempted for synchronization during the next initialization, ensuring that the data is not lost.

[0122] In one example, the task sending module 30 includes:

[0123] A request creation module is used to create a request for sending the saved task.

[0124] The interface call determination module is used to determine the interface called when the saving task is sent to the server.

[0125] The first judgment module for sending results is used to periodically check the activation status identifier of the sending request if the interface being called is a delayed sending interface. If the activation status is detected as activated, the sending is determined to be successful; if the activation status is not detected within a preset timeout period, the sending is determined to be unsuccessful.

[0126] The second judgment module for sending results is used to determine the sending result by obtaining the return identifier of the asynchronous beacon interface if the called interface is an asynchronous beacon interface;

[0127] The third judgment module for sending results is used to wait for the response returned by the server if the called interface is a keep-alive sending interface, and determine the sending result based on the response.

[0128] Furthermore, embodiments of this application provide a page data storage device. Optionally, Figure 3 The hardware structure block diagram of the page data storage device is shown below. Figure 3 The hardware structure of the page data storage device may include: at least one processor 01, at least one communication interface 02, at least one memory 03, and at least one communication bus 04.

[0129] In this embodiment, the number of processor 01, communication interface 02, memory 03 and communication bus 04 is at least one, and processor 01, communication interface 02 and memory 03 communicate with each other through communication bus 04.

[0130] Processor 01 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0131] Memory 03 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0132] The memory stores a program, which the processor can call to execute. The program is used to perform the following page data saving method, including:

[0133] Based on a pre-established page lifecycle monitoring mechanism, monitor page state changes in real time;

[0134] Based on the changes in the page's state, a save task is constructed in real time and saved to the browser's structured storage task queue;

[0135] Send the saved tasks in the task queue to the server and determine the sending result;

[0136] If the sending result is a sending failure, then resend and return to the step of determining the sending result, until the number of resends reaches a preset limit, then mark the sending failure tag and save it in storage;

[0137] When the page is identified as being initialized, the saved task marked with a sending failure tag is loaded from the storage and resent.

[0138] Optionally, the refined and extended functions of the program can be found in the description of the page data saving method in the method embodiments.

[0139] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor. When the program runs, it controls the device where the storage medium is located to execute the following page data saving method, including:

[0140] Based on a pre-established page lifecycle monitoring mechanism, monitor page state changes in real time;

[0141] Based on the changes in the page's state, a save task is constructed in real time and saved to the browser's structured storage task queue;

[0142] Send the saved tasks in the task queue to the server and determine the sending result;

[0143] If the sending result is a sending failure, then resend and return to the step of determining the sending result, until the number of resends reaches a preset limit, then mark the sending failure tag and save it in storage;

[0144] When the page is identified as being initialized, the saved task marked with a sending failure tag is loaded from the storage and resent.

[0145] Specifically, the storage medium can be a computer-readable storage medium, which can be an electronic storage device such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM.

[0146] Optionally, the refined and extended functions of the program can be found in the description of the page data saving method in the method embodiments.

[0147] Furthermore, the functional modules in the various embodiments of this disclosure can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a live streaming device, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this disclosure.

[0148] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0149] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0150] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for saving page data, characterized in that, include: Based on a pre-established page lifecycle monitoring mechanism, monitor page state changes in real time; Based on the changes in the page's state, a save task is constructed in real time and saved to the browser's structured storage task queue; Send the saved tasks in the task queue to the server and determine the sending result; If the sending result is a sending failure, then resend and return to the step of determining the sending result, until the number of resends reaches a preset limit, then mark the sending failure tag and save it in storage; When the page is identified as being initialized, the saved task marked with a sending failure tag is loaded from the storage and resent.

2. The method according to claim 1, characterized in that, The step of monitoring page state changes in real time according to a pre-established page lifecycle monitoring mechanism includes: The page lifecycle monitoring mechanism includes a page visibility change event listener, a freeze event listener, and a page hide event listener. The page visibility change event listener is used to listen for page visibility change events in real time; The freeze event listener is used to monitor freeze events in the browser where the page is located in real time. The page hiding event listener is used to monitor in real time whether the page is prone to being uninstalled or cached. A state change is determined when one or more of the following events are detected: visibility change event, freeze event, unloaded tendency event, or cached tendency event.

3. The method according to claim 1, characterized in that, The real-time construction and saving task based on the page's state changes includes: When the page changes from a visible active state to a visible inactive state, the accumulated data changes before the change are constructed into a save task; When the page changes from a visible state to a hidden state, the current data is compared with the data when the save task was last built, and the data with the difference is used to build the save task. When the page changes from a visible or hidden state to a frozen state, tasks that have not been marked with persistent tags are extracted from the storage to construct a save task; When the page changes from a frozen state to a visible state, the tasks marked with the "sent failure" tag in the storage are saved as tasks.

4. The method according to claim 1, characterized in that, Sending the saved tasks in the task queue to the server includes: If the state change corresponding to the save task when it is constructed is from visible active state to visible inactive state, then the delayed send interface is called to send it to the server. If the state change corresponding to the save task when it is constructed is from visible to hidden, or from frozen to visible, then the keep-alive sending interface is called to send it to the server. If the state change corresponding to the save task during its construction is from visible or hidden to frozen, then the asynchronous beacon interface is invoked to send it to the server.

5. The method according to claim 4, characterized in that, Also includes: Real-time monitoring of the status of the delayed transmission interface and the keep-alive transmission interface; If the delayed sending interface is available, the saved task is used as the request body, and an activation delay time is set. The delayed sending interface is called when the page is closed or when the activation delay time is reached. If the delayed transmission interface is unavailable, it is switched to the asynchronous beacon interface to invoke the asynchronous beacon interface; If the asynchronous beacon interface fails to connect with the save task, it will be switched to the keep-alive sending interface, which will then be invoked.

6. The method according to any one of claims 1 to 5, characterized in that, The determination of the sending result includes: Establish a send request for the aforementioned save task; Determine the interface invoked when sending the save task to the server; If the interface being called is a delayed sending interface, the activation status identifier of the sending request is checked periodically. If the activation status is detected as activated, the sending is determined to be successful; if the activation status is not detected within the preset timeout period, the sending is determined to be unsuccessful. If the interface being called is an asynchronous beacon interface, then the return identifier of the asynchronous beacon interface is obtained to determine the sending result; If the interface called is a keep-alive sending interface, then wait for the response returned by the server and determine the sending result based on the response.

7. A page data storage device, characterized in that, include: The state change monitoring module is used to monitor page state changes in real time according to a pre-established page lifecycle monitoring mechanism. A save task construction module is used to construct save tasks in real time based on the state changes of the page and save them to the task queue of the browser's structured storage; The task sending module is used to send the saved tasks in the task queue to the server and determine the sending result; The judgment module is used to resend the data if the sending result is a sending failure, return to the step of determining the sending result, and continue until the number of resends reaches a preset limit. The sending failure tag is then marked and saved in storage. The resend module is used to load the saved task marked with a sending failure tag from the storage and resend it when the page is detected to be initializing.

8. The apparatus according to claim 7, characterized in that, The task sending module includes: A request creation module is used to create a request for sending the saved task. The interface call determination module is used to determine the interface called when the saving task is sent to the server. The first judgment module for sending results is used to periodically check the activation status identifier of the sending request if the interface being called is a delayed sending interface. If the activation status is detected as activated, the sending is determined to be successful; if the activation status is not detected within a preset timeout period, the sending is determined to be unsuccessful. The second judgment module for sending results is used to determine the sending result by obtaining the return identifier of the asynchronous beacon interface if the called interface is an asynchronous beacon interface; The third judgment module for sending results is used to wait for the response returned by the server if the called interface is a keep-alive sending interface, and determine the sending result based on the response.

9. A page data storage device, characterized in that, Including memory and processor; The memory is used to store programs; The processor is configured to execute the program to implement each step of the page data saving method as described in any one of claims 1-6.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements each step of the page data saving method as described in any one of claims 1-6.

Images