Page recovery method and device, electronic equipment, medium and program product

Abstract

The invention provides a page recovery method and device, electronic equipment, a medium and a program product, and can be applied to the technical field of cloud computing and the field of financial science and technology. The method comprises the steps that before a current page jumps to a target page, state information of the current page is acquired; generating summary information based on the state information, and separately storing the summary information and the page data; under the condition that the target page is returned to the current page, performing consistency verification based on the summary information; and in response to passing of the consistency verification, performing page recovery of the current page based on the page data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing and the technical field of financial technology, and more particularly to a page recovery method, device, equipment, medium and program product. BACKGROUND

[0002] With the development of Web technology, the demand for page recovery of users in a weak network or a disconnected network environment is increasing, especially in scenarios such as filling out a form, complex configuration or file upload. If the state cannot be recovered after page refresh or jump, it will seriously affect the experience and efficiency. At present, there is no uniform page recovery standard or complete solution in the industry, and most websites still recover the page by reloading resources and data, which not only increases the server load and bandwidth consumption, but also cannot retain the user's operation state.

[0003] Some existing technologies attempt to cache page data or state in memory or use the browser local storage mechanism for recovery, but the above methods still have deficiencies: on the one hand, directly caching complete page data will occupy a lot of memory or storage space, and in the case of application switching or a large number of pages, it is easy to be invalid, and the stability of recovery is poor; on the other hand, the local storage mechanism can save part of the data, but due to the lack of a lightweight verification identifier, it cannot quickly determine whether the data is complete and valid during page recovery. Once there is inconsistency or data loss, resources still need to be reloaded, resulting in slow recovery speed and loss of user operation state. In addition, most of the existing methods fail to achieve separate management of page state and page data, and lack efficient recovery strategies based on summary information, so they are not stable and not universal in cross-page or multiple scenarios. SUMMARY

[0004] In view of the above problems, the present application provides a page recovery method, device, equipment, medium and program product.

[0005] According to a first aspect of the present application, a page recovery method is provided, the method comprising: obtaining state information of a current page before the current page jumps to a target page; generating summary information based on the state information, and storing the summary information and the page data separately; in the case of the target page rolling back to the current page, performing consistency check based on the summary information; and in response to passing the consistency check, performing page recovery of the current page based on the page data.

[0006] According to an embodiment of this application, the method further includes: responding to a failure of the consistency check by performing page recovery of the current page based on a hierarchical recovery mechanism, wherein the hierarchical recovery mechanism includes at least: restoring the page structure of the current page based on the summary information; supplementing the missing data of the current page asynchronously; and restoring the interactive state of the current page based on a preset recovery priority.

[0007] According to an embodiment of this application, the step of storing the summary information and the page data separately includes: writing the summary information into a first storage medium in response to the triggering of the current page jump; and writing the page data into a second storage medium based on the monitoring results of the browser operating environment in response to the completion of writing the summary information.

[0008] According to an embodiment of this application, the step of writing the page data to the second storage medium based on the monitoring results of the browser operating environment in response to the completion of writing the digest information includes: monitoring the state of the browser operating environment in response to the completion of writing the digest information; if the browser operating environment is in the target state, writing the page data to the second storage medium based on an asynchronous task; if the browser operating environment is not in the target state, delaying the writing of the page data.

[0009] According to embodiments of this application, the target state includes at least one of the following: the browser triggers an idle callback event, the page enters a hidden state, the network latency is lower than a first preset threshold, or the memory usage rate is lower than a second preset threshold.

[0010] According to an embodiment of this application, the method further includes: obtaining target data verification information corresponding to the page data; determining whether data verification information consistent with the target data verification information exists in the second storage medium before writing the page data; and if so, skipping the writing of the page data.

[0011] According to an embodiment of this application, if the data does not exist, the difference between the page data and the data already stored in the second storage medium is compared to obtain incremental data, and the incremental data is written into the second storage medium.

[0012] According to an embodiment of this application, writing the page data to the second storage medium based on an asynchronous task includes: in response to a failure to write the page data, performing an asynchronous write retry on the page data; and in response to the number of asynchronous write retry attempts reaching a retry threshold, obtaining target field data from the page data and writing the target field data to the second storage medium.

[0013] A second aspect of this application provides a page recovery apparatus, the apparatus comprising: a data acquisition module, configured to: acquire state information of the current page before navigating to a target page; a summary information generation module, configured to: generate summary information based on the state information, and store the summary information and the page data separately; a consistency verification module, configured to: perform consistency verification based on the summary information when the target page reverts to the current page; and a page recovery module, configured to: recover the current page based on the page data in response to the consistency verification passing.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] According to the embodiments of this application, by extracting state information and generating summary information before page navigation, and using a method of storing summary information separately from page data, the validity of data is ensured through consistency verification when the page is rolled back, and rapid recovery is achieved after the verification is passed. This can avoid re-requesting page resources, reduce network overhead, improve page recovery speed, and effectively retain the user's operation state on the page, thereby improving the user experience and system response efficiency in weak network or offline environments. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustrations depict application scenarios of page recovery methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0020] Figure 2 A flowchart illustrating a page restoration method according to an embodiment of this application is shown schematically.

[0021] Figure 3 This schematically illustrates a flowchart of a method for separately storing summary information and page data according to some exemplary embodiments of this application;

[0022] Figure 4 The illustration shows a schematic diagram of a method for writing page data according to some exemplary embodiments of this application;

[0023] Figure 5 A schematic diagram illustrating the structure of a page recovery apparatus according to an embodiment of this application is shown; and

[0024] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a page recovery method according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0029] First, the technical terms used in this article will be explained and clarified as follows.

[0030] Summary information is a simplified representation generated based on page state information. It typically records the core characteristics of the page using methods such as data fingerprints, hash values, and structured tags. Summary information occupies little storage space, facilitates rapid comparison and verification, and is mainly used for consistency verification when rolling back the page to ensure that the restored data version is correct.

[0031] Page data refers to the complete set of data that constitutes a page, including static content (such as text, images, and style sheets), dynamic data (such as API request results and real-time rendered content), and interactive states (such as form input and button selection). Page data is the primary carrier for recovery operations; by storing and loading page data, a complete page can be reconstructed.

[0032] A tiered recovery mechanism refers to a strategy that gradually restores a page according to different levels of page structure, data content, and interaction status when a consistency check fails. This mechanism allows for the priority loading of structure and key content, followed by the addition of details and user status, thereby ensuring page availability and a progressive experience under weak network or abnormal conditions.

[0033] Asynchronous tasks refer to data writing or processing tasks that are executed without blocking the main thread.

[0034] Incremental data refers to the differences extracted by comparing the data to be written to the page with the existing stored data. Incremental data only contains changed fields or modules, is small in size, and can be written quickly, reducing storage space and transmission bandwidth consumption. It is an important means to improve the efficiency of high-frequency system interactions.

[0035] With the continuous development of web technologies, especially the widespread adoption of Single Page Applications (SPAs) and Progressive Web Applications (PWAs), users' demand for webpage recovery is increasing. Traditional web applications can rely on the server to quickly load data and pages under good network conditions. However, in weak network or offline environments, webpage loading and state recovery are often slow, preventing users from quickly returning to previously visited pages or restoring their previous operational state. This is particularly problematic when users have already filled out forms, performed complex configurations, or uploaded files. If the state cannot be restored after a page refresh or redirect, it not only severely impacts user experience but also causes operational interruptions and reduced efficiency. Therefore, webpage recovery capabilities are gradually becoming a key factor in improving user experience and enhancing application usability.

[0036] Currently, there is no unified technical standard or complete solution for web page recovery. Different websites adopt different methods based on their own technology stack and application scenarios, but most websites do not implement a complete page recovery function. Instead, they use the method of reloading the resources and data of the previous page to restore the page. Although this method is simple, it requires re-sending requests to the backend server, which increases response time, puts additional load on the server, and the user's operation state on the page cannot be retained, resulting in a poor user experience and wasted bandwidth resources.

[0037] Some common existing methods include: one approach is to cache some of the page's data and state directly in the runtime environment's memory, and then read and render the page from the cache when the user navigates or returns, in order to avoid repeated requests and rendering; another approach is to utilize the browser's local storage mechanism to store page data or state information locally, and restore it when the user visits or returns again, in order to reduce reliance on the server.

[0038] However, these existing technologies still have significant shortcomings: First, directly caching complete page data consumes a lot of resources and is usually limited to internal application navigation. Once accessed across sites or multiple pages, the cached content is often cleared, making continuous recovery impossible. Second, existing methods lack separate management of page state and page data, making it impossible to quickly verify and locate recovery points using lightweight summary information, resulting in insufficient recovery efficiency. Third, although local storage mechanisms can preserve data to some extent, the lack of a reliable consistency verification mechanism means that if data is missing or the versions are inconsistent, resources still need to be reloaded, thus failing to guarantee the stability and universality of page recovery.

[0039] Based on this, embodiments of this application provide a page recovery method, the method comprising: obtaining state information of the current page before navigating to a target page; generating summary information based on the state information, and storing the summary information and the page data separately; performing a consistency check based on the summary information when the target page returns to the current page; and performing page recovery of the current page based on the page data in response to the successful consistency check. According to embodiments of this application, by extracting state information and generating summary information before page navigation, and using a method of storing the summary information and page data separately, data validity is ensured through consistency checks during page navigation, and rapid recovery is achieved after the check passes. This avoids re-requesting page resources, reduces network overhead, improves page recovery speed, and effectively preserves the user's operation state on the page, thereby improving user experience and system response efficiency in weak network or offline environments.

[0040] It should be noted that the page recovery method, apparatus, device, medium, and program products defined in this application can be used in the fields of cloud computing technology and fintech, and can also be used in a variety of other fields besides cloud computing technology and fintech. The application fields of the page recovery method, apparatus, device, medium, and program products provided in the embodiments of this application are not limited.

[0041] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0042] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0043] Figure 1 The illustration shows an application scenario of the page recovery method, apparatus, device, medium, and program product according to embodiments of this application.

[0044] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0045] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0046] In the embodiments of this application, the first terminal device 101 can be an example of the first device, and the second terminal device 102 and / or the third terminal device 103 can be an example of at least one second device. The first device and the second device can communicate collaboratively through an internal client mechanism to implement the data distribution and rendering logic described in the page restoration method.

[0047] In some embodiments, the first device and at least one second device may be different display modules, windows or screens on the same computing terminal (such as a host), or multiple physical devices that work together through a network, such as different client instances deployed on a desktop computer, tablet terminal or mobile device respectively.

[0048] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smart mobile terminals, tablet computers, laptop computers, and desktop computers.

[0049] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0050] It should be noted that the page recovery method provided in this application embodiment can generally be executed by server 105. Correspondingly, the page recovery device provided in this application embodiment can generally be located in server 105. The page recovery method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the page recovery device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0051] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0052] The following will be based on Figure 1 The described scene, through Figures 2 to 4 The page recovery method of the disclosed embodiments will be described in detail.

[0053] Figure 2 A flowchart illustrating a page restoration method according to an embodiment of this application is shown schematically.

[0054] like Figure 2 As shown, the page recovery method 200 of this embodiment includes operations S210 to S240.

[0055] In operation S210, before jumping from the current page to the target page, the status information of the current page is obtained.

[0056] In some embodiments, before navigating from the current page to the target page, the system can collect the current page's runtime environment and interaction state to form state information. This state information may include page structure information, such as Document Object Model (DOM) hierarchy, node identifiers, style attributes, and script execution status, used to rebuild the page's basic framework during subsequent page restoration. In this embodiment, state information can be obtained directly through built-in browser interfaces or collected in real-time via script injection or runtime monitoring, ensuring that the state information covers the complete situation before the page navigation.

[0057] In other embodiments, the state information may further include user interaction-related information, such as the user's scroll position on the page, the content of input boxes, the state of expanded or collapsed components, and the user's selected tab or drop-down menu value. By obtaining this state information, it is possible to restore the interaction context before the user left when the page is navigated back, avoiding the loss of operations due to reloading. Different storage methods can be used for different types of interaction states; for example, input content can be stored as text, and scroll positions can be recorded as coordinates for quick loading and restoration later.

[0058] In some embodiments, the status information may also include runtime environment parameters, such as the network request status during page loading, resource cache identifiers, script execution progress markers, and memory usage. This type of status information is particularly important in weak network or offline environments, as it can be used to determine which resources can be directly recovered from the cache and which parts need to be fetched again or have a latency compensation mechanism triggered, thereby implementing a differentiated recovery strategy.

[0059] Furthermore, state information can also be obtained through lightweight abstract modeling. For example, for pages containing complex interaction logic, it is not necessary to collect all state parameters item by item. Instead, key operation paths can be extracted through behavior sequence modeling, such as the user's recent form filling operation, the navigation path within the page, and key control click events. Although the state information formed in this way is simplified, it can quickly reconstruct the main operation context during recovery, improving the overall response speed.

[0060] In some application scenarios, state information can also be acquired asynchronously through pre-collection. For example, when the system detects signs that a user may be about to navigate to a different page (such as clicking a link, triggering a navigation command, or performing a route switching operation), it can trigger the state information collection process in advance. This reduces the delay between the user's actual navigation action and the state acquisition operation, further improving the timeliness and stability of page recovery.

[0061] In operation S220, summary information is generated based on the status information, and the summary information and the page data are stored separately.

[0062] In the embodiments of this application, after obtaining the page's state information, the system can perform structured processing to form summary information for subsequent verification and recovery. The summary information can be represented using lightweight data structures, such as key-value maps, hash fingerprints, or serialized object digests, to facilitate rapid comparison and parsing during subsequent recovery. In this embodiment, the summary information can be stored in a relatively high-priority storage medium, while the complete page data can be stored separately in another storage area, thus achieving separate management of the two.

[0063] In other embodiments, the generation of summary information can be based on compression and filtering mechanisms. Specifically, after acquiring the state information, the system can use feature extraction algorithms to retain only the key elements necessary for page reconstruction, such as the page's DOM hierarchy identifiers, values ​​of key controls, and temporary content input by the user, while excluding a large number of redundant rendering parameters or cached resources. The summary information generated in this way is not only small in size, but can also be written preferentially in situations of unstable network or limited storage space, ensuring that a minimum amount of reconstruction basis is always available during subsequent recovery.

[0064] In some embodiments, the process of generating summary information can be combined with a data integrity verification mechanism. For example, when generating summary information, the system can calculate hash values ​​or checksums for the core parts of the page state information and store them in the summary structure. When the user returns to the page, the system can compare the checksum value of the summary information with the currently stored data to verify whether the stored data has been tampered with or lost, thereby improving the reliability of page recovery in scenarios such as weak network, network outage, or multi-terminal switching.

[0065] Furthermore, the separate storage of summary information and page data can be achieved through different levels of storage media. For example, summary information can be preferentially stored in browser local storage, memory cache, or session-level database, while page data can be stored in long-term storage media or cloud storage, thereby improving access efficiency when device resources are limited.

[0066] In embodiments of this application, the generation of summary information can also be combined with page data version management. When generating summary information, the system can include the page data version number, timestamp, or user identification identifier, so that a correspondence can be established between the version identifier in the summary and the page data during subsequent recovery. This ensures that the user receives the same page state as their previous operation when going back, avoiding errors or data misalignment issues caused by cross-version recovery.

[0067] In some embodiments, summary information can also be generated and stored asynchronously. For example, after detecting a page jump event, the system can immediately generate an initial summary and write it to a fast storage area, while the complete page data is asynchronously written to persistent storage in a background task.

[0068] In operation S230, when the target page is navigating back to the current page, a consistency check is performed based on the summary information.

[0069] In the embodiments of this application, when a user triggers a page back operation during browsing, the system can first obtain the previously stored summary information and compare it with the state data of the page to be restored. By comparing the consistency between the summary and the page data, the system can determine whether the currently stored data is in a complete and valid state, thereby avoiding page errors or data loss during the restoration process.

[0070] Specifically, consistency verification can be implemented based on the hash value of the digest information. For example, the system calculates and stores a checksum for the digest information before page redirection, and recalculates and compares the hash values ​​during rollback. If they match, it means the page data has not been corrupted and can be safely recovered; if they do not match, it means the data may have been lost or tampered with, and the system can further trigger a recovery mechanism. In this way, the reliability of page recovery can be significantly improved.

[0071] Furthermore, consistency checks can be combined with hierarchical strategies to ensure the availability of core page logic even when some information is missing. The system not only checks whether the summary and page data are completely consistent, but can also make judgments based on different verification levels. For example, it prioritizes checking whether the page structure matches, then checks whether key user input fields are consistent, and finally checks auxiliary information (such as scroll position, cached data, etc.).

[0072] In some embodiments, consistency checks can also be performed across devices or sessions. For example, when a user navigates to a page on a mobile device and then returns to the home screen on a desktop, the system can retrieve the user's summary information from the server and compare it with the local page data. If they match, the page is restored directly; if they do not match, the system can prompt the user to choose between local or cloud-based data, thereby ensuring a consistent experience across multiple devices.

[0073] In the embodiments of this application, consistency verification can also be performed using intelligent discrimination algorithms. When comparing the summary and page data, the system does not simply perform a binary "whether they are consistent" judgment, but combines statistical models or machine learning algorithms to calculate the tolerance for data differences. For example, if it is found that some content in the user input field is missing, but the overall page structure and key interaction states are consistent, it can be determined as "partially consistent". Based on this, the system can still prioritize restoring the page and supplement the missing content in the background.

[0074] In some embodiments, consistency verification can also be combined with security requirements. When a page involves sensitive data (such as a payment page or an identity authentication page), the system not only verifies the page summary and data content, but also further verifies security identifiers, such as digital signatures and encrypted verification codes, to ensure the legality and security of the page recovery process.

[0075] In some embodiments, consistency verification can also be combined with timestamp information. The system records the generation time when generating summary information, and compares the time difference between the timestamp and the current data during rollback. If the difference exceeds a preset threshold, the user is prompted that the data on the page may have expired, and an incremental update of the latest data is automatically triggered.

[0076] In some embodiments, consistency verification can be performed based on a multi-source verification mechanism. The system not only relies on locally stored digest information, but can also obtain redundant digest copies from the cloud, edge nodes, or collaborative caches. By comparing data from multiple sources, the correctness and integrity of the data are ensured, thereby improving the consistency guarantee capability in complex network environments.

[0077] In some embodiments, consistency checks can also dynamically adjust the granularity of the checks. For scenarios with high performance requirements, the system can check only key fields or modules; while in security-sensitive scenarios, a full check is performed, including page scripts, style sheets, and associated resource files, thereby achieving a flexible balance between performance and security.

[0078] In operation S240, in response to the successful consistency check, the current page is restored based on the page data.

[0079] In some embodiments, in response to a successful consistency check, the system can directly utilize previously stored page data to perform a complete rendering recovery of the current page. In this case, the page data may include the page's DOM structure, stylesheets, and script states. When loading this data, the system can complete the page rendering quickly without re-requesting the remote server, ensuring that the page content seen by the user remains consistent with that before the redirect, thereby reducing network overhead and improving loading speed.

[0080] In other embodiments, page restoration is not limited to loading static content, but also includes dynamic interactive information generated by the user on the page. For example, text entered by the user in a form, dropdown items selected on the page, and the position swiped to can all be recorded through page data and restored during restoration. In this way, even if the user is interrupted or goes back during page navigation, they can directly return to the original interaction context when the page is restored, avoiding repeated operations and improving the user experience.

[0081] Furthermore, the page recovery process can support tiered loading. After a consistency check passes, the core framework and key data of the page are loaded quickly to ensure immediate visibility and operability. Subsequent additional resources, such as images, videos, or complex data tables, are then loaded asynchronously in the background. This progressive recovery mechanism improves page responsiveness in weak network environments while ensuring data integrity and seamless interaction.

[0082] In some embodiments, page recovery can be optimized in conjunction with the client's caching strategy. When a resource matching the summary information is detected in the local cache, the system can directly call the cached data to complete the recovery; if some resources are missing or incomplete, only the necessary data is supplemented through differential requests, thereby avoiding repeated transmission and reducing storage and bandwidth consumption.

[0083] In some embodiments, the page restoration process can be adapted to the characteristics of different terminal devices. For example, on mobile devices, the system can prioritize restoring elements related to user interaction, such as input boxes and button states, to ensure a continuous operating experience; while on desktop devices, it can prioritize loading complex data tables or graphical displays to ensure the complete presentation of information, thereby improving consistency and efficiency across different terminal usage scenarios.

[0084] According to embodiments of this application, by obtaining the current page's state information before page navigation and generating summary information based on this state information, the summary information is stored separately from the page data. When returning to the target page, the summary information is used to perform a consistency check, and after the check passes, the page is restored based on the page data. This allows for the rapid restoration of page content and user operation state without re-requesting remote resources, effectively reducing network overhead and loading latency, and ensuring consistency between page display and interaction logic. Furthermore, this mechanism maintains page availability and continuity even in weak network, network outage, or high-latency environments, improving user experience and system response efficiency while also ensuring data integrity and security.

[0085] In the embodiments of this application, in response to the failure of the consistency check, the system does not directly abandon page recovery, but can perform page recovery of the current page based on a hierarchical recovery mechanism.

[0086] Specifically, the basic structural framework of the page can first be restored using the aforementioned summary information, such as the page's hierarchical layout, navigation elements, and placeholder components, thus maintaining the page's basic integrity in terms of visual appeal and interactive logic. Subsequently, missing data can be gradually supplemented using asynchronous loading, for example, by requesting backend data to fill in dynamic data, business data, or multimedia resources that were not stored synchronously, allowing the page content to be gradually restored while still visible to the user. Furthermore, during the data supplementation process, the system can also prioritize the restoration of state information that is most relevant to the user or closely related to interaction, such as form input, scroll position, and tab selection status, based on a preset restoration priority strategy, to ensure the continuity of user operations and uninterrupted task execution.

[0087] Optionally, the tiered recovery mechanism can be applied not only to the data layer but also dynamically adjusted based on network and device resource conditions. For example, when a poor network environment is detected, the system can restore only critical interactive fields and necessary business logic, delaying the loading of non-critical resources; and then gradually restore the remaining content after network conditions recover. Through this tiered and gradual recovery approach, the system can maintain page availability and stability under different operating environments, thereby improving the user's interactive experience in weak network or high-concurrency scenarios.

[0088] The page recovery method of this application will be specifically described below by way of preferred embodiments.

[0089] In the embodiments of this application, in order to improve the stability and flexibility of page data storage, summary information and page data can be stored separately.

[0090] Figure 3 The flowchart illustrates a method for separately storing summary information and page data according to some exemplary embodiments of this application.

[0091] like Figure 3 As shown, the method for separating and storing summary information and page data includes operations S310 to S320.

[0092] In operation S310, in response to the triggering of the current page jump, the summary information is written to the first storage medium.

[0093] Specifically, when a redirection event is triggered on the current page, the summary information generated from the state information can be written to the first storage medium first. The first storage medium can be a local cache or session storage area with fast access speed and high stability to ensure that critical page structure and interaction metadata can be saved in a timely and reliable manner.

[0094] In operation S320, in response to the completion of the summary information writing, the page data is written to the second storage medium based on the monitoring results of the browser operating environment.

[0095] After writing the summary information, the specific storage timing can be determined by monitoring the browser's runtime environment. When the runtime environment meets the target conditions, the system then writes the complete page data to the second storage medium via an asynchronous task.

[0096] In the embodiments of this application, the separate storage of summary information and page data enables a lightweight two-layer storage structure during page navigation. Summary information primarily records core elements such as the page's structural features, interaction states, and key identifiers; it is relatively small in size and writes quickly. Page data, on the other hand, includes specific business data, rendered charts, rich text information, or multimedia files; it is larger in size and takes longer to write. By storing these two types of information separately, summary information can be saved quickly, ensuring that even during page navigation or browser interruption, the most crucial basis for page recovery remains, preventing the complete loss of page state.

[0097] Furthermore, the separate storage of summary information and page data enables a multi-layered recovery mechanism. When a user navigates back to a page, the summary information can be used first for consistency verification, quickly comparing the current page state with the stored state to determine if the page data is directly usable. If the verification passes, the page can be restored without re-initiating a full request, greatly improving page response speed. If the verification fails, the summary information can still serve as an anchor point for recovery, helping the system quickly rebuild the basic framework and interaction logic of the page, and asynchronously fill in missing data to achieve tiered recovery.

[0098] Furthermore, separate storage can reduce conflicts and pressure on storage resources. Because summary information and page data differ in size, structure, and storage requirements, unified storage may cause write blocking, storage conflicts, or performance fluctuations. With separate storage, summary information can be written to faster storage media first, while page data is written to media suitable for storing large-scale data with a delay. This differentiated strategy not only improves storage success rate but also reduces the occupation of the system's main thread, improving overall page smoothness.

[0099] In the embodiments of this application, in response to the completion of the digest information writing, the state of the browser runtime environment can be monitored to determine whether it is in the target state, so as to determine the page data writing strategy.

[0100] In some embodiments, the target state may include at least one of the following: the browser triggers an idle callback event, the page enters a hidden state, network latency is lower than a first preset threshold, or memory usage is lower than a second preset threshold. Specifically, when the browser triggers an idle callback event, the system can utilize this idle time window to perform asynchronous writing of page data, thereby avoiding the occupation of critical rendering or interaction resources. When the page enters a hidden state (e.g., the user switches to another tab), the system can securely write page data to the second storage medium without affecting the current user's operating experience. When network latency is detected to be lower than the first preset threshold, it indicates that the network transmission environment is stable and suitable for quickly completing the writing of large amounts of data; when memory usage is detected to be lower than the second preset threshold, system resources are relatively sufficient, and the write operation has minimal interference with page operation.

[0101] The aforementioned target status monitoring design intelligently selects the appropriate writing time while ensuring that summary information has been written, achieving efficient and low-interference storage of page data. On the one hand, this mechanism reduces conflicts between the writing process and user interaction, avoiding page lag or resource contention; on the other hand, based on dynamic judgment of network and memory, it can also improve the writing success rate and efficiency, reducing the risk of data loss due to insufficient resources.

[0102] When the browser's runtime environment is in the target state, meaning all monitoring indicators are within the preset threshold range, an asynchronous task can be triggered to write page data to a second storage medium. Because this process is executed asynchronously, it will not block the browser's main thread, thus ensuring the continuity of user interaction on the front end and the smoothness of page rendering.

[0103] If the browser's runtime environment is not in the target state, the system can delay the execution of page data writing operations. This delay can be achieved by setting a waiting time or by being triggered by events, such as waiting for a browser idle callback, waiting for the page to run in the background, or waiting for the next low-priority task window. In this case, the summary information, as the minimized page state, has already been safely written, thus ensuring that the core page recovery capabilities remain unaffected even with delayed page data writing.

[0104] Furthermore, dynamic priority scheduling strategies can be combined to adjust the timing of data writes multiple times based on changes in the browser's operating environment. For example, if memory release is detected during the delay period, the write task can be started immediately, thus completing page data storage as quickly as possible while ensuring performance. Dynamic priority scheduling strategies can effectively balance the real-time nature of storage with system availability, avoiding page stuttering or write failures caused by resource contention.

[0105] By introducing monitoring of the browser's runtime environment after the summary information is written, and selecting asynchronous or delayed writing methods based on the state of the runtime environment, it is possible to effectively balance the real-time nature of page data storage and system performance while ensuring that the core state of the page has been safely saved.

[0106] Figure 4 The illustration shows a schematic diagram of a method for writing page data according to some exemplary embodiments of this application.

[0107] like Figure 4 As shown, the method for writing page data may include operations S410 to S430.

[0108] In operation S410, the target data verification information corresponding to the page data is obtained.

[0109] In the embodiments of this application, before performing the page data writing operation, the target data verification information corresponding to the page data can be obtained first. For example, the data verification information can be generated by the browser during page rendering, sent by the server, or automatically generated based on the content hash value of the page data. As a preferred approach, the data verification information can be in the form of a version number. By obtaining the version number, the system can identify the status of the data to be written.

[0110] In operation S420, before writing the page data, it is determined whether there is data verification information in the second storage medium that is consistent with the target data verification information.

[0111] In operation S430, if the page data exists, the writing of the page data is skipped.

[0112] If the verification result shows that the data verification information matches the verification information of the existing data in the second storage medium, it means that the page data to be written is logically unchanged or different from the already stored data. In this case, the system can skip the write operation, avoiding unnecessary data redundancy and storage operation overhead.

[0113] The above processing steps effectively reduce the consumption of storage resources by frequent write operations. For example, when a page frequently triggers navigation or partial refreshes, if the actual page data remains unchanged, the system can quickly detect consistency through version number comparison, thereby avoiding duplicate saving and reducing the use of disk I / O or browser local storage. Especially in mobile terminals or weak network environments, this mechanism can reduce energy consumption and performance degradation caused by duplicate storage.

[0114] Furthermore, when a user returns from the target page, if the data verification information required for recovery matches the verification information pointed to by the current summary information, the already stored data can be used directly to complete the recovery, thereby simplifying the recovery path and improving recovery efficiency. Conversely, if the data verification information is inconsistent, it means that the currently stored data may be outdated. In this case, the system can choose an incremental update strategy or trigger a subsequent differentiated write process.

[0115] Specifically, upon detecting inconsistencies in data verification information, the page data to be written can first be compared field-by-field with the historical page data already stored in the second storage medium to identify any discrepancies. Subsequently, incremental data is generated based on the comparison results; this incremental data only includes the fields, modules, or structural information that have changed. Finally, the incremental data can be written to the second storage medium, and the data verification information in the storage medium (such as version number, timestamp, or hash value) can be updated to reflect the latest state of the data.

[0116] This differentiated incremental write mechanism reduces storage and network transmission resource consumption, improves storage update efficiency, and reduces latency during the write process, minimizing the impact on user experience. In weak network or high-frequency interaction scenarios, incremental data writing significantly improves the real-time performance and flexibility of the system during page recovery, resulting in superior performance.

[0117] In embodiments of this application, the process of writing the page data to the second storage medium based on an asynchronous task may further include a recovery mechanism for write failures. Specifically, when an asynchronous write operation of the page data is detected to have failed, the system does not immediately abandon the write operation, but triggers retry logic to perform an asynchronous write retry operation on the page data. The retry process may be based on a preset time interval or an exponential backoff strategy to improve the success probability in the event of momentary network anomalies or temporary shortage of storage resources.

[0118] If, after multiple retries, the asynchronous write attempt fails after reaching the retry threshold, the system will initiate a degradation strategy. Specifically, target field data can be extracted from the page data. This target field data includes at least the core state information required for page recovery, such as form input content, page scroll position, user configuration parameters, or interaction context. Subsequently, the target field data can be written to a second storage medium to ensure that even if the entire page data cannot be saved, critical states can still be restored based on the target field data during subsequent page rollback or recovery.

[0119] Through the above mechanisms, the embodiments of this application can still ensure the basic reliability of page data storage even under conditions of limited storage resources, unstable network environment, or task interruption. On the one hand, the retry mechanism improves the success rate of write operations and enhances the robustness of the system; on the other hand, the degradation save strategy ensures that at least the critical state of the page can be recovered, avoiding the complete loss of user operation information, thereby improving the fault tolerance of the system and the user experience in complex operating environments.

[0120] The page recovery method provided in this application enables efficient and stable data storage and recovery during page navigation and rollback. On one hand, the separate storage of summary information and page data ensures hierarchical protection of page structure, data content, and interaction state, improving the flexibility and reliability of recovery. On the other hand, the introduction of consistency verification and hierarchical recovery mechanisms allows the system to quickly locate and recover data layer by layer when data integrity is compromised, ensuring stable page operation. Simultaneously, intelligent monitoring of the browser's operating environment, combined with asynchronous and delayed write strategies under the target state, effectively reduces the interference of write operations on front-end performance, avoiding performance degradation under resource constraints or weak network conditions. Furthermore, by skipping redundant writes through data verification information comparison or performing differentiated incremental updates when inconsistencies occur, the system can significantly reduce storage and network resource consumption, improving write and recovery efficiency. Combined with the retry mechanism for asynchronous writes and the target field write-back mechanism, it not only enhances the robustness and fault tolerance of data storage but also ensures the real-time performance and user experience of page recovery in complex scenarios such as weak networks and high-frequency interactions, achieving comprehensive optimization of performance, energy consumption, and reliability.

[0121] Corresponding to the above-described page recovery method, embodiments of this application also provide a page recovery device.

[0122] Figure 5 A schematic block diagram of a page recovery apparatus according to an embodiment of this application is shown.

[0123] like Figure 5 As shown, the page recovery device 500 of this embodiment includes a data acquisition module 510, a summary information generation module 520, a consistency verification module 530, and a page recovery module 540.

[0124] The data acquisition module 510 can be used to acquire the state information of the current page before navigating to the target page. In one embodiment, the data acquisition module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0125] The summary information generation module 520 can be used to generate summary information based on the status information, and to store the summary information and the page data separately. In one embodiment, the summary information generation module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0126] The consistency verification module 530 can be used to perform consistency verification based on the digest information when the target page returns to the current page. In one embodiment, the consistency verification module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0127] The page recovery module 540 can be used to restore the current page based on the page data in response to a successful consistency check. In one embodiment, the page recovery module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0128] According to embodiments of this application, the page recovery device 500 may further include a hierarchical recovery module. The hierarchical recovery module may also be used to recover the current page based on a hierarchical recovery mechanism in response to a failure of consistency verification. The hierarchical recovery mechanism includes at least: recovering the page structure of the current page based on the summary information; supplementing missing data of the current page asynchronously; and recovering the interactive state of the current page based on a preset recovery priority.

[0129] According to an embodiment of this application, the summary information generation module 520 can also be used to write the summary information into a first storage medium in response to the triggering of the current page jump; and to write the page data into a second storage medium based on the monitoring results of the browser operating environment in response to the completion of the summary information writing.

[0130] According to an embodiment of this application, the summary information generation module 520 can also be used to monitor the state of the browser's operating environment in response to the completion of the summary information writing; if the browser's operating environment is in the target state, the page data is written to the second storage medium based on an asynchronous task; if the browser's operating environment is not in the target state, the writing of the page data is delayed. The target state includes at least one of the following: the browser triggers an idle callback event, the page enters a hidden state, the network latency is lower than a first preset threshold, or the memory usage rate is lower than a second preset threshold.

[0131] According to an embodiment of this application, the summary information generation module 520 can also be used to perform an asynchronous write retry on the page data in response to the page data writing failure; and to obtain target field data in the page data and write the target field data into the second storage medium in response to the asynchronous write retry count reaching the retry count threshold.

[0132] According to an embodiment of this application, the page recovery device 500 may further include a storage module. The storage module can be used to obtain target data verification information corresponding to the page data; before writing the page data, determine whether data verification information consistent with the target data verification information exists in the second storage medium; and if it exists, skip writing the page data. If it does not exist, compare the page data with the differences between the page data and the data already stored in the second storage medium to obtain incremental data, and write the incremental data into the second storage medium.

[0133] According to embodiments of this application, any multiple modules among the data acquisition module 510, digest information generation module 520, conformance verification module 530, and page recovery module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the data acquisition module 510, digest information generation module 520, conformance verification module 530, and page recovery module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the data acquisition module 510, the summary information generation module 520, the consistency verification module 530, and the page recovery module 540 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0134] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a page recovery method according to an embodiment of this application.

[0135] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0136] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0137] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0138] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0139] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0140] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the page recovery method provided in the embodiments of this application.

[0141] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0142] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0143] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0144] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0146] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0147] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A method for restoring a page, characterized in that, The method includes: Before navigating from the current page to the target page, obtain the state information of the current page; Based on the status information, a summary information is generated, and the summary information and the page data are stored separately. When the target page is navigated back to the current page, a consistency check is performed based on the summary information; and In response to the successful consistency check, the current page is restored based on the page data.

2. The method according to claim 1, characterized in that, The method further includes: In response to a failure of the consistency check, the current page is restored based on a tiered recovery mechanism. The tiered recovery mechanism includes at least: restoring the page structure of the current page based on the summary information; supplementing the missing data of the current page asynchronously; and restoring the interactive state of the current page based on a preset recovery priority.

3. The method according to claim 1, characterized in that, The step of separating and storing the summary information and the page data includes: In response to the triggering of the current page redirection, the summary information is written to the first storage medium; and In response to the completion of the summary information writing, the page data is written to the second storage medium based on the monitoring results of the browser's operating environment.

4. The method according to claim 3, characterized in that, In response to the completion of writing the summary information, the page data is written to the second storage medium based on the monitoring results of the browser's operating environment, including: In response to the completion of writing the summary information, the status of the browser's operating environment is monitored; If the browser runtime environment is in the target state, the page data is written to the second storage medium based on an asynchronous task; If the browser's runtime environment is not in the target state, the writing of the page data will be delayed.

5. The method according to claim 4, characterized in that, The target state includes at least one of the following: the browser triggers an idle callback event, the page enters a hidden state, the network latency is lower than a first preset threshold, or the memory usage rate is lower than a second preset threshold.

6. The method according to any one of claims 3 to 5, characterized in that, The method further includes: Obtain the target data verification information corresponding to the page data; Before writing the page data, it is determined whether there is data verification information in the second storage medium that is consistent with the target data verification information; as well as If it exists, skip writing the page data.

7. The method according to claim 6, characterized in that, If it does not exist, compare the difference between the page data and the data already stored in the second storage medium to obtain incremental data, and write the incremental data into the second storage medium.

8. The method according to claim 4, characterized in that, The step of writing the page data to the second storage medium based on an asynchronous task includes: In response to the failure to write the page data, an asynchronous write retry is performed on the page data; as well as In response to the asynchronous write retries reaching the retry threshold, the target field data in the page data is obtained and written to the second storage medium.

9. A page recovery device, characterized in that, The device includes: The data acquisition module is used to: acquire the status information of the current page before navigating from the current page to the target page; The summary information generation module is used to: generate summary information based on the status information, and store the summary information and the page data separately; The consistency verification module is configured to: perform consistency verification based on the digest information when the target page returns to the current page; and The page recovery module is used to: in response to a successful consistency check, restore the current page based on the page data.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images