Page state synchronization method and apparatus based on state snapshot, device, and medium

Abstract

The present application relates to the technical field of data synchronization, and discloses a page state synchronization method and device based on state snapshots, equipment and medium, comprising: obtaining a page state field and configuring a merging condition, generating a page state model; generating an incremental state snapshot containing version information when the page state changes and sending it to a state synchronization server; receiving a unified version state snapshot and conflict information when the page enters or returns; comparing the unified version state snapshot with the local page state, determining the target field state, updating the application page and generating a page recovery result; generating a page state synchronization log based on the state snapshot, conflict information and page recovery result. The present application can be applied to financial technology and medical health business scenarios, determines the target field state through page state modeling, incremental snapshots, version comparison and conflict processing, reduces the inconsistency of multi-end page states, and improves the traceability of state recovery through the synchronization log.

Description

Technical Field

[0001] This invention relates to the field of data synchronization technology, and in particular to a method, apparatus, device and medium for synchronizing page state based on state snapshots. Background Technology

[0002] Existing mini-program pages typically store page state through local caching, page routing parameters, global state objects, and server-side interface data. When switching between different running platforms and different entry points, or returning after completing an operation, the page state stored on each running platform may be different from the server-side state. Existing technologies lack a unified method for consistency determination and restoration of states from different sources, making it difficult to accurately determine the valid state that a page should adopt, resulting in inconsistencies in the key states displayed by the same page in different running environments.

[0003] In the fintech business, users may access the same page for coupon redemption, points redemption, order payment, insurance benefits, or vehicle management through embedded mini-programs within applications, WeChat mini-programs, or Alipay mini-programs. After a user completes a coupon redemption, payment, benefit redemption, or vehicle switching on one operating platform, other operating platforms or returned pages may still retain the state before the operation. Due to version and update time differences between local page states, client-side operation states, and server-side business states, existing technologies struggle to accurately determine the current valid state when a page is restored, easily leading to inconsistent processing progress for the same financial transaction across different operating platforms.

[0004] In the healthcare business, users may access the same page for appointment booking, online consultation, examination and testing, prescription confirmation, or payment settlement through different operating platforms. After a user completes a process such as switching patients, confirming an appointment, submitting consultation information, or making payment on one operating platform, other operating platforms or pages returned to may still display the page state before the operation. Because the locally saved state of the page may differ from the processing state on the healthcare server, existing technologies cannot accurately restore the page state consistent with the current healthcare service progress, resulting in inconsistent display of the same healthcare business page in different operating environments. Summary of the Invention

[0005] The main objective of this invention is to provide a page state synchronization method, apparatus, device, and storage medium based on state snapshots, aiming to solve the technical problem that, when switching or returning to restore the same application page across different operating terminals, it is difficult to determine the effective page state to be used based on a unified version relationship and conflict determination criteria, resulting in inconsistent page states across different operating terminals.

[0006] To achieve the above objectives, the present invention provides a page state synchronization method based on state snapshots, comprising: Obtain the page status fields of the application page, configure corresponding merging conditions for each page status field, and generate a page status model based on the page status fields and the merging conditions; In response to a state change operation on the application page, the changed page state fields are determined based on the page state model, an incremental state snapshot containing version information is generated, and the incremental state snapshot is sent to the state synchronization server. In response to a page entry or page return operation on the application page, a status acquisition request is sent to the status synchronization server, and a unified version status snapshot and conflict information are received from the status synchronization server. The unified version status snapshot and conflict information are generated by the status synchronization server based on the incremental status snapshot, the server confirmation status corresponding to the incremental status snapshot, and the current unified status snapshot already stored by the status synchronization server, and in accordance with the merging conditions. Obtain the local page state containing version information stored locally on the application page, compare the state difference and version with the unified version state snapshot, and determine the difference state field and version comparison result; Based on the unified version status snapshot, the conflict information, and the version comparison result, the target field status corresponding to the difference status field is determined, and the application page is updated based on the target field status to generate a page recovery result. A page status synchronization log is generated based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

[0007] Furthermore, to achieve the above objectives, the present invention provides a page state synchronization device based on state snapshots, comprising: The page state modeling module is used to obtain the page state fields of the application page, configure corresponding merging conditions for each page state field, and generate a page state model based on the page state fields and the merging conditions. The incremental snapshot generation module is used to respond to the state change operation of the application page, determine the changed page state field based on the page state model, generate an incremental state snapshot containing version information, and send the incremental state snapshot to the state synchronization server. The unified state acquisition module is used to respond to a page entry operation or page return operation on the application page, send a state acquisition request to the state synchronization server, and receive a unified version state snapshot and conflict information sent by the state synchronization server. The unified version state snapshot and conflict information are generated by the state synchronization server based on the incremental state snapshot, the server confirmation state corresponding to the incremental state snapshot, and the current unified state snapshot already stored by the state synchronization server, and according to the merging conditions. The status difference comparison module is used to obtain the local page status containing version information stored locally on the application page, compare the unified version status snapshot with the local page status, and determine the difference status field and the version comparison result. The page state recovery module is used to determine the target field state corresponding to the difference state field based on the unified version state snapshot, the conflict information and the version comparison result, update the application page based on the target field state, and generate a page recovery result. The synchronization log generation module is used to generate page status synchronization logs based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a state snapshot-based page state synchronization program stored in the memory and executable on the processor, wherein when the state snapshot-based page state synchronization program is executed by the processor, it implements the steps of the state snapshot-based page state synchronization method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a state snapshot-based page state synchronization program, which, when executed by a processor, implements the steps of the state snapshot-based page state synchronization method as described above.

[0010] Beneficial Effects: This invention relates to the field of data synchronization technology and discloses a method, apparatus, device, and medium for page state synchronization based on state snapshots. The method includes: acquiring page state fields and configuring merging conditions to generate a page state model; generating an incremental state snapshot containing version information and sending it to a state synchronization server when the page state changes; receiving a unified version state snapshot and conflict information when entering or returning to the page; comparing the unified version state snapshot with the local page state to determine the target field state, updating the application page, and generating a page recovery result; and generating a page state synchronization log based on the state snapshot, conflict information, and page recovery result. This invention can be applied to business scenarios such as fintech and healthcare. By determining the target field state through page state modeling, incremental snapshots, version comparison, and conflict handling, it provides a unified basis for page recovery, reduces the overwriting of new states by old states and inconsistencies in page states across multiple devices, and improves the traceability of the state recovery process through synchronization logs. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a page state synchronization method based on state snapshots according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the page state synchronization method based on state snapshots according to the present invention. Figure 3 for Figure 2 A detailed flowchart of step S10; Figure 4 for Figure 2 A detailed flowchart of step S20; Figure 5 for Figure 2 A detailed flowchart of step S40; Figure 6 for Figure 2 A detailed flowchart of step S50; Figure 7 for Figure 2 A detailed flowchart of step S60; Figure 8 for Figure 2 A detailed flowchart illustrating the processing steps following step S60; Figure 9 This is a schematic diagram of the functional modules of a preferred embodiment of the page state synchronization device based on state snapshot of the present invention. Figure 10 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 11This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The page state synchronization method based on state snapshots provided in this invention can be applied to applications such as... Figure 1 In this application environment, the client communicates with the server via a network. The server can obtain page state fields from the client and configure merging conditions to generate a page state model; when the page state changes, it generates an incremental state snapshot containing version information and sends it to the state synchronization server; when the page enters or returns, it receives a unified version state snapshot and conflict information; it compares the unified version state snapshot with the local page state to determine the target field state, updates the application page, and generates a page recovery result; and it generates a page state synchronization log based on the state snapshot, conflict information, and page recovery result. This invention can be applied to business scenarios such as fintech and healthcare. By determining the target field state through page state modeling, incremental snapshots, version comparison, and conflict handling, it provides a unified basis for page recovery, reduces the overwriting of new states by old states and inconsistencies in page states across multiple devices, and improves the traceability of the state recovery process through synchronization logs. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the page state synchronization method based on state snapshots provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the page state synchronization method based on state snapshots proposed in this invention includes the following steps: S10, obtain the page status field of the application page, configure the corresponding merging conditions for each page status field, and generate a page status model based on the page status field and the merging conditions; In this embodiment, the page identifier, page structure data, component binding relationships, and status declaration data of the application page are read to determine data items related to page display, interactive input, and business progress. For each data item, the field identifier, field access path, field value type, status source, and storage location are recorded to form a page status field that can be independently read and written. The status source may include page data objects, component data objects, routing parameters, local cache, and server-returned data.

[0016] For each page status field, the source priority is determined based on the status source attribute, the expiration condition is determined based on the validity period attribute, the field merging method is determined based on the update attribute, and the server confirmation identifier is determined based on the server confirmation requirement. These factors are then combined into the merging conditions. The field merging method can prioritize newer versions, higher source values, non-empty states, or server-confirmed status.

[0017] The page identifier is used as an index, and the page status field is used as a field node. The field node is associated with the field access path, field value type, status source, storage location, and merging conditions to generate a page status model. The field nodes can be stored using a mapping structure, tree structure, or serialized configuration structure, and can record the model version and configuration update time.

[0018] When the page structure is fixed and the number of fields is small, a configuration table is used to store the page identifier, field identifier, field access path, field value type, status source, validity period, field merging method and server confirmation identifier, and the configuration records under the same page identifier are combined into a mapping structure.

[0019] In scenarios where page components are dynamically generated or there are many fields, the system parses data binding expressions, component attributes, and event binding relationships in the component tree to identify field access paths. These paths are then matched with the field configuration data to supplement source priority, expiration conditions, field merging methods, and server-side confirmation identifiers. Field nodes can be organized according to page regions or component hierarchies, loading only the field nodes corresponding to the current page region.

[0020] In the fintech business, coupon redemption pages can include membership level, coupon redemption status, order payment status, policy benefit status, and vehicle binding status. The coupon redemption status, order payment status, and policy benefit status are configured with server-side confirmation identifiers. The membership level and vehicle binding status are configured with source priority and validity period, and a page status model is generated according to the page identifiers.

[0021] In the healthcare business domain, health service pages can include patient selection status, appointment time slot, consultation information submission status, prescription confirmation status, and payment settlement status. The appointment confirmation status, prescription confirmation status, and payment settlement status are configured with server-side confirmation flags. The patient selection status is configured with a field merging method prioritizing newer versions. Appointment time slots are configured with expiration conditions, and the field nodes are organized according to page areas.

[0022] This embodiment identifies independently manageable page status fields and configures source priority, expiration conditions, field merging methods, and server confirmation identifiers for each field, giving page data from different sources and with different validity periods a clear organizational basis. By associating field attributes and merging conditions with page identifiers, it reduces field confusion and configuration differences, improving the accuracy and reusability of the page status structure.

[0023] S20, in response to the state change operation of the application page, the changed page state field is determined based on the page state model, an incremental state snapshot containing version information is generated, and the incremental state snapshot is sent to the state synchronization server. In this embodiment, when a state change occurs on the application page, the field states before and after the change are read based on the field identifier, field access path, and field value type in the page state model. State change operations can be triggered by component value changes, interaction events, page parameter changes, interface data writing, or cache updates. Text, numeric, boolean, enumeration, and object fields are compared according to their corresponding data types. When a field value, valid state, or content integrity changes, the corresponding field is identified as the changed page state field.

[0024] The incremental content consists of the changed page state fields and their corresponding updated state; unchanged fields are not written to the incremental state snapshot. Version information is used to identify the chronological order of page state changes and can be formed from the current page version, operation sequence information, or update time. The incremental state snapshot may also include page identifier, field identifier, and snapshot generation time, and is sent to the state synchronization server after being serialized according to a preset data structure.

[0025] When page state is centrally managed by a data binding framework, a state monitoring interface is used to record the state values ​​before and after a field is written, and these values ​​are mapped to the corresponding page state fields based on the field access path. After comparison, the changed fields, the changed field state, and version information are written to an incremental state snapshot.

[0026] When page state is distributed across multiple components, interactive events are used to determine the scope of affected components and read the corresponding fields. For object-type fields, a summary value can be generated first, and changes can be identified by differences in the summary values. Then, the changed attribute content is written to the incremental state snapshot to reduce repeated comparisons and transmissions.

[0027] In the fintech business, after a user completes coupon redemption, order payment, or vehicle switching, the corresponding redemption status, payment status, or vehicle binding status and version information are written into an incremental status snapshot and sent.

[0028] In the healthcare business, after a user switches patients, selects an appointment time, or submits consultation information, an incremental status snapshot is generated by combining the corresponding field status, page identifier, and version information and then sent.

[0029] This embodiment locates and compares page state fields using a page state model, recording only the states of fields that have changed, thus reducing the repeated transmission of unchanged data; it also distinguishes the sequential relationship of consecutive state changes through version information, improving the accuracy of recording page state changes across multiple running terminals.

[0030] S30, in response to a page entry operation or page return operation occurring on the application page, a status acquisition request is sent to the status synchronization server, and a unified version status snapshot and conflict information are received from the status synchronization server. The unified version status snapshot and conflict information are generated by the status synchronization server based on the incremental status snapshot, the server confirmation status corresponding to the incremental status snapshot, and the current unified status snapshot already stored by the status synchronization server, and in accordance with the merging conditions. In this embodiment, when an application page enters or returns, the page lifecycle callback reads the page identifier and local version information, and writes both into a status retrieval request. The page identifier is used to locate the status data of the corresponding page, and the local version information is used to indicate the current page's saved status version. The status retrieval request is sent to the status synchronization server via a network interface. The request may also include a user identifier, a business object identifier, and a request identifier to distinguish between different users, different business objects, and different request batches.

[0031] After receiving a status retrieval request, the state synchronization server searches for the incremental state snapshot and the stored current unified state snapshot based on the page identifier, user identifier, and business object identifier. It determines the page state fields to be merged based on the field change data in the incremental state snapshot and retrieves the incremental field status corresponding to each page state field to be merged. Based on the same field identifier, it retrieves the corresponding current field status from the current unified state snapshot. The incremental field status represents the field content most recently reported by the client, while the current field status represents the field content already saved by the server.

[0032] Each page status field to be merged is associated with a corresponding merging condition. When the merging condition includes a server-side confirmation identifier, the corresponding field is identified as the page status field to be confirmed, and the server-side confirmation status is obtained from the business status record, asynchronous callback record, or status confirmation interface. Based on version order, source priority, status validity period, field merging method, and server-side confirmation status, the incremental field status is compared with the current field status at the field level to form the target merged field status. If a unique field status cannot be determined based on the merging condition, the field identifier, candidate field status, candidate version, and conflict type are recorded as conflict field data.

[0033] The target merge field status is written to the corresponding field position in the current unified state snapshot, and the field version information and snapshot version information are updated according to the field status changes to generate a unified version state snapshot. Conflicting field data is organized according to field identifier and conflict type to generate conflict information. The state synchronization server associates the unified version state snapshot and conflict information with the request identifier and returns it to the application page, so that the returned data corresponds to the current page entry or page return operation.

[0034] In scenarios where page states are centrally stored, a state data table is used to save a snapshot of the current unified state, using page identifier, user identifier, and business object identifier as a composite index. The state synchronization server reads the incremental state snapshot and the current unified state snapshot based on the composite index, calls the merging conditions field by field to complete the determination, and writes the state of the target field to be merged back to the state data table. Fields that require server confirmation are queried through the business state interface to confirm the result before participating in the field state determination.

[0035] In scenarios with high page views and scattered state data, a distributed cache is used to store a snapshot of the current unified state, while message logging is used to store incremental state snapshots and asynchronous confirmation states. The state synchronization server reads the three types of data in parallel, establishes corresponding relationships according to field identifiers, and then generates the target merged field state based on merging conditions. Conflicting field data is written to a separate conflict record area, and unified version state snapshots are returned in groups according to page regions to reduce the amount of data transmission of irrelevant fields.

[0036] In the fintech business, when a user returns to the order payment page, the status synchronization server reads the pending payment status reported by the client, the stored current page status, and the server-side confirmation status generated by the payment callback. If the payment callback shows that payment has been made, the paid status is determined as the target merged field status; if the client-side status and the payment callback do not correspond, the order payment status is recorded as conflict field data, and a unified version status snapshot and conflict information are returned.

[0037] In the healthcare business, when a user returns to the appointment service page, the status synchronization server reads the appointment time slot submitted by the client, the appointment status in the current unified status snapshot, and the appointment confirmation record. If the appointment confirmation record is valid, the confirmed appointment status is written to the unified version status snapshot; if the appointment time slot version is inconsistent with the confirmation record, the corresponding fields and version differences are written into the conflict information and returned together with the unified version status snapshot.

[0038] This embodiment initiates a status acquisition request through page identifier and local version information, and performs field-level determination on the status synchronization server for incremental field status, current field status and server confirmation status. It can determine the target merged field status based on version, source and validity period; and form conflict information for fields that cannot be determined to have a unique result, so that the unified version status snapshot can reflect the currently available page status and reduce the situation where different running terminals use different field statuses when entering or returning to the page.

[0039] S40, obtain the local page state containing version information stored locally on the application page, compare the state difference and version of the unified version state snapshot with the local page state, and determine the difference state field and version comparison result. In this embodiment, the page identifier, field identifier, field status, and version information stored locally on the application page are read to form the local page status. The field status can come from page data objects, component status, local cache, or page routing parameters. The version information can be set to page-level version, field-level version, or a combination of both, to represent the data time sequence corresponding to the local field status.

[0040] Establish a field mapping between the unified version state snapshot and the local page state based on the page state fields, and perform consistency processing on field value types, null value forms, and object attribute order. State difference comparison is used to determine whether the unified field state corresponding to the same page state field is the same as the local field state. When there are differences in field values, valid states, or object attribute content, the corresponding page state field is identified as the difference state field.

[0041] Version comparison is performed independently of status value comparison. Based on the version order of the unified field version information and the local field version information, the version relationship of fields with newer unified versions, newer local versions, or the same versions is determined, and the version comparison results are summarized and generated. Fields with the same status value but different versions still retain the corresponding field version relationship to avoid missing version changes based solely on field values.

[0042] When page states are stored using a key-value structure, a comparison index is built using field identifiers to match the same-named fields in the unified version state snapshot and the local page state item by item. Text, numeric, and boolean fields are directly compared after standardization, while object fields are expanded according to the attribute path and compared item by item, while also comparing the corresponding field version information.

[0043] When page state is stored using hierarchical objects, field nodes are located using the field access path in the page state model. For object-type fields with large content, summary values ​​are generated for both the unified field state and the local field state. If the summary values ​​differ, the corresponding attribute content is compared. Version information is read synchronously according to field nodes to form the version sequence relationship for each field.

[0044] In the fintech business, the order page locally saves the pending payment status, while the unified version status snapshot records the paid status. The difference status fields are determined by comparing the status values ​​of the order payment status field, and the version order relationship between the two is determined by the corresponding version information.

[0045] In the healthcare business, the appointment page saves the original appointment time locally, while the unified version status snapshot records the changed appointment time. Differences are identified by comparing the content of the appointment time field, and the version information of the field is compared to generate the corresponding version comparison results.

[0046] This embodiment establishes a correspondence between a unified version status snapshot and the local page status by using field identifiers and field access paths. It also performs status value comparisons and version sequence comparisons to accurately identify differences in field content and version, reducing misjudgments caused by different field formats, different object attribute orders, or the same field value but different versions.

[0047] S50, based on the unified version status snapshot, the conflict information and the version comparison result, determine the target field status corresponding to the difference status field, update the application page based on the target field status, and generate a page recovery result; In this embodiment, the unified field status and version information corresponding to each differential status field are read from the unified version status snapshot, and a correspondence is established between the field identifier and the local page status. Conflict information is used to mark page status fields with multiple candidate states that cannot be directly adopted using the unified field status. The version comparison result is used to indicate the version order between the unified field status and the local field status. For differential status fields without conflicts and with a newer unified field status version, the unified field status is determined as the target field status. For differential status fields with conflicts or version anomalies, the field status that can be written to the page is determined by combining the conflict type, candidate field status, and version relationship. The target field status includes a field identifier, field value, and corresponding version, used to clarify the page update location and update content.

[0048] Based on the field access paths recorded in the page state model, the target field state is written to the corresponding data node of the application page. Text, numeric, boolean, and enumeration fields can have their values ​​directly replaced. Object fields can have their changed attributes updated according to the attribute path, avoiding the need to rebuild unchanged object content. After the field is written, the corresponding component's data binding is updated, ensuring that the page's displayed content and interactive state are consistent with the target field state. For page state fields involving local caching, the target field state and its corresponding version can be written to the cache location, maintaining a correspondence between the page data object and the locally stored content.

[0049] The page recovery results record the update status of each difference status field, which may include field identifier, field status before update, target field status, update completion status, and update completion time. A field value is successfully written and the corresponding component completes the update, recorded as "Complete"; if the field path does not exist, the field type does not match, or the component update is incomplete, the corresponding "Incomplete" status is recorded. The page recovery results reflect the fields involved in this page update and the update results.

[0050] When a page uses a centralized data object to manage state, the field access path is retrieved from the page state model based on the field identifier. The state of each target field is written into the centralized data object, and the page data update interface is called once to submit multiple field changes. When multiple differing state fields belong to the same page area, they can be merged into a single update request, reducing redundant component refreshes.

[0051] When page states are distributed across multiple components, the component identifier corresponding to each differing state field is determined based on the field access path, and the target field state is sent to the corresponding component. Object-type fields are updated at the attribute level, replacing only the changed attributes; after the component returns an update completion indicator, the corresponding update completion status and update completion time are recorded. When the field type is inconsistent with the target field state, the field value is type-converted, and fields that cannot be converted are recorded as incomplete.

[0052] In the fintech business, if the local field status on the order payment page is "Pending Payment," while the field status in the unified version status snapshot is "Paid," and the unified field version is newer, then "Paid" will be determined as the target field status, and the payment status component and local cache will be updated. The page restoration result records the order payment status before the update, the target content, and the update completion status.

[0053] In the healthcare business, if the local appointment time slot on the appointment service page differs from the appointment time slot in the unified version status snapshot, and the conflict information indicates that the appointment time slot confirmed by the server has taken effect, the confirmed appointment time slot will be set as the target field status, and the appointment time slot component will be updated. After the update is complete, the page will restore the result record of the corresponding field status and completion time.

[0054] This embodiment selects the target field status corresponding to each difference status field by using a unified version status snapshot, conflict information, and version comparison results. This reduces the direct overwriting of the current page content by earlier versions or conflicting states. By updating the corresponding data nodes according to the field access path, the scope of page updates can be narrowed. Furthermore, by recording the status before and after the update and the completion status through the page recovery results, the accuracy and verifiability of page status recovery can be improved.

[0055] S60, generate a page status synchronization log based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

[0056] In this embodiment, page identifier, user identifier, business object identifier, runtime type, operation sequence information, version information, snapshot generation time, and field change content are read from the incremental state snapshot to form a snapshot reporting record. Unified version information, page state fields participating in the state merging, and their corresponding field states are read from the unified version state snapshot to form a state merging record. The incremental state snapshot reflects field changes occurring on the endpoint, while the unified version state snapshot reflects the merged state available for use by the page. The two types of records are associated through page identifier, business object identifier, operation sequence information, and version information.

[0057] The conflict information is used to retrieve the conflict status field, candidate field status, field version, and conflict type. The conflict status field is then associated with the corresponding target field status to form a conflict record. The page recovery results are used to retrieve the difference status field, the field status before update, the target field status, the update completion status, and the update completion time to form a page recovery record. The conflict record reflects the basis for determining the target field status, while the page recovery record reflects the completion status after the target field status is written to the application page.

[0058] Snapshot reporting records, state merging records, conflict records, and page recovery records are written to the same log data structure. Logs are categorized by page identifier, user identifier, and business object identifier. Record content is arranged according to operation sequence information, version information, and time information to generate a page state synchronization log. Logs can be stored as structured text, key-value objects, or binary sequences. Each record is configured with a record type and recording time, enabling differentiation between different state changes and page recovery processes.

[0059] When the number of page state synchronizations is infrequent and the content of each record is small, structured text is used to organize the log content. A log index is composed of page identifier, user identifier, and business object identifier. Incremental state snapshots, unified version state snapshots, conflict information, and page recovery results are converted into corresponding log items. Then, based on the operation sequence information and version information, they are written to the same log object, which facilitates the complete preservation of the content of a single page state synchronization.

[0060] In scenarios with frequent page state changes and large log data volumes, a segmented logging approach is adopted. Snapshot reporting records, state merging records, conflict records, and page recovery records are written to their respective record areas and associated with the same page identifier, business object identifier, operation sequence information, and version information. Field status content can save only the field identifier, status summary, and version information; for large object-type fields, the summary value and change attributes are saved to reduce log storage volume.

[0061] In the fintech business, after a user completes coupon redemption or order payment, the page status synchronization log records the redemption or payment status reported by the client, the merged unified status, the conflict type, the status of the target field used, and the page update completion status, so that the page status record corresponding to the same business object remains clear.

[0062] In the healthcare business, after a user completes the change of appointment time or submits consultation information, the page status synchronization log records the changed appointment or consultation fields, unified version status, conflicting content, and page recovery results, so that the page status records generated by different running terminals can be distinguished according to user, business object, and version information.

[0063] This embodiment, by associating incremental state snapshots, unified version state snapshots, conflict information, target field status, and page recovery results, can fully reflect page state changes, state merging, conflict determination, and page update status. Organizing log content according to page identifier, business object identifier, operation sequence information, and version information can reduce the confusion between records of changes in different pages or different states, and improve the completeness and verifiability of page state synchronization records.

[0064] In one embodiment, such as Figure 3As shown, step S10 above includes: S101, obtain the page structure data and state definition data of the application page, determine the state nodes from the page structure data, extract the state identifier and state value type corresponding to each state node from the state definition data, associate each state node with the corresponding state identifier and state value type to obtain the page state field. S102, extract the status category, status source type, status validity period information, status update attribute and server confirmation requirement information corresponding to each page status field from the status definition data, determine the source priority based on the status source type, determine the expiration condition based on the status validity period information, determine the field merging method based on the status category and the status update attribute, and determine the server confirmation identifier based on the server confirmation requirement information. S103, combine the server confirmation identifier, source priority, expiration condition and field merging method corresponding to each page status field to generate the merging conditions corresponding to each page status field; S104, establish the field condition correspondence between each page status field and the corresponding merging condition, organize each page status field and the corresponding merging condition based on the field condition correspondence, and generate status field configuration data. S105, obtain the page identifier of the application page, associate the page identifier with the status field configuration data, and generate a page status model.

[0065] In this embodiment, the page structure data and state definition data corresponding to the application page are read. The page structure data may consist of a component tree, node hierarchy, component attributes, data binding paths, and interaction event configurations, used to locate component nodes or data nodes that can carry the page state. The state definition data may consist of field declarations, field type declarations, state source configurations, and state update configurations, used to describe the data content associated with each node. The page structure data is traversed according to component identifiers, node paths, or data binding paths, and nodes with state read or write positions are identified as state nodes, excluding nodes that only perform layout, style, or static display functions and are not associated with variable data.

[0066] Based on the node identifier correspondence between state nodes and state definition data, the associated state identifier and state value type of each state node are read. The state identifier distinguishes different state contents and can be a field name, field code, or hierarchical access path. The state value type constrains the data format of the state content and can include text, numeric, boolean, enumeration, set, and object types. The state node, state identifier, and state value type are written to the same field record, making the field record simultaneously contain page position, data identifier, and data format, forming a page state field. Object or set types can be further split according to attribute paths, so that attributes requiring independent comparison or update form separate page state fields.

[0067] The status category, status source type, status validity period information, status update attributes, and server confirmation requirement information are read from the status definition data according to the status identifier. The status category distinguishes between display status, input status, routing status, environment status, and business status. The status source type indicates whether the field status originates from page data objects, component data objects, routing parameters, local cache, or server-returned data. The status validity period information may include the validity duration, expiration time, or expiration trigger condition. The status update attributes may include overwrite update, append update, attribute-level update, and prohibition of null value overwrite. The server confirmation requirement information indicates whether the field status requires confirmation from the server's returned result.

[0068] Configure source priorities for each status source based on its source type, enabling selection according to source order when multiple candidate statuses exist for the same field. Generate expiration conditions based on status validity information. Expiration conditions can be determined by comparing the field update time with the validity period, or triggered by page exit, changes in business objects, or changes in login status. Determine the field merging method based on status category and status update attributes. Display statuses can prioritize newer versions, input statuses can prioritize current input content, object-type statuses can use attribute-level merging, and business statuses can prioritize server-side confirmation results. Generate a server-side confirmation identifier based on server-side confirmation requirement information to mark page status fields that require querying the server-side status before determining their content.

[0069] Combine the source priority, expiration condition, field merging method, and server confirmation identifier corresponding to the same page status field into a merging condition, maintaining the correspondence between each component and the field identifier. Establish the field condition correspondence between page status fields and merging conditions, using the field identifier as an index, and write the field value type, status source type, source priority, expiration condition, field merging method, and server confirmation identifier into the same configuration record. Arrange the configuration records according to the field identifier or status node hierarchy to generate status field configuration data, ensuring that each page status field can uniquely locate the corresponding merging condition.

[0070] The system reads the page identifier of the application page and associates it with the status field configuration data. The page identifier can be formed from page routing, page encoding, or page registration information, and is used to distinguish the field configurations corresponding to different pages. The associated data can be stored using a mapping structure, a tree structure, or a serialized configuration structure, where the page identifier serves as the index, the page status field as the field node, and the merging condition as the associated attribute of the field node, thus generating a page status model. The page status model can record the configuration version and update time, used to distinguish different configuration content after changes in the page field structure or merging conditions.

[0071] This embodiment identifies page status fields that can be independently read, compared, and updated by using page structure data and status definition data. It also configures source priority, expiration conditions, field merging methods, and server confirmation identifiers for each page status field, ensuring that status content from different sources, with different validity periods, and different update attributes has a clear organizational basis. Furthermore, by associating page status fields with merging conditions through field condition correspondences and forming a page status model according to page identifiers, it reduces confusion regarding field meanings and configuration inconsistencies, improving the accuracy of page status field identification and merging condition configuration.

[0072] In one embodiment, such as Figure 4 As shown, step S20 above includes: S201, in response to the state change operation of the application page, obtain the page state before and after the state change operation, and extract the field state corresponding to each page state field from the page state before and after the state change operation based on the page state model, and generate a set of field states before the operation and a set of field states after the operation. S202, compare the pre-operation field status set and the post-operation field status set item by item according to the page status field, determine the page status field whose field status has changed as the changed page status field, and generate field change data based on the pre-operation field status and post-operation field status corresponding to the changed page status field. S203, obtain the base version identifier currently saved on the application page and the operation sequence information corresponding to the state change operation, generate version information based on the base version identifier, and obtain the current time information, and determine the current time information as the snapshot generation time; S204, obtain the page identifier, user identifier, business object identifier and the current running terminal type of the application page, and combine the page identifier, user identifier, business object identifier, running terminal type, field change data, operation sequence information, version information and snapshot generation time to generate an incremental state snapshot containing version information; S205, obtain the current network transmission status. When the current network transmission status is a transmittable state, send the incremental status snapshot to the status synchronization server. When the current network transmission status is a non-transmittable state, write the incremental status snapshot into the reporting queue according to the operation sequence information. After the current network transmission status is converted to a transmittable state, send the incremental status snapshot in the reporting queue to the status synchronization server according to the operation sequence information.

[0073] In this embodiment, when the application page experiences component value writing, interactive event triggering, route parameter changes, interface data backfilling, or cache content updates, the page state before and after the state change operation is recorded. The page state can be stored in a combination of page data objects, component data objects, and cache mapping data, and the affected data range is determined by the event identifier corresponding to the state change operation, avoiding traversing page content unrelated to the current change.

[0074] Based on the field identifiers, field access paths, and field value types recorded in the page state model, each page state field is located from the page states before and after the state change operation. The field access path is used to locate the field within the hierarchical data structure, and the field value type controls the reading method and data format. A one-to-one correspondence is established between the extracted field identifiers and the field states, thus forming a set of field states before and after the operation. Object-type fields can be expanded according to attribute paths, and set-type fields can be read based on element identifiers, element order, or set summaries, ensuring consistent comparison granularity between the field states before and after the operation.

[0075] The two field status sets are matched item by item according to the page status field. For text, numeric, boolean, and enumeration fields, the standardized field values ​​are compared; for object fields, the attribute content is compared item by item; and for collection fields, the element identifier and element content are compared. Numeric precision, null value format, and character encoding can be standardized before comparison to reduce errors caused by format differences. When a field value, field validity status, or object attribute changes, the corresponding page status field is identified as the changed page status field.

[0076] For each page status field that has changed, the field identifier, the field status before the operation, and the field status after the operation are associated as a field change item. Multiple field change items are then combined into field change data. Field change data can record change types such as replacement, addition, deletion, or attribute update, used to distinguish how the field content has changed. Unchanged page status fields are not written into the field change data, ensuring that subsequent snapshots only contain the content related to this current status change.

[0077] The baseline version identifier indicates the page state version used by the application page before this state change operation. It can be read from the local page state, the most recently received unified version state snapshot, or the page-level version record. The version space to which the incremental content belongs is determined based on the baseline version identifier, forming version information and establishing a correspondence between the field change data and the page state version it is based on. Operation sequence information is generated according to the order in which state change operations occur. It can use an incrementing sequence number within the page session or a sequential code with a running endpoint identifier to distinguish multiple consecutive incremental state snapshots generated on the same page. Current time information generates the snapshot generation time according to the time recorded by the running endpoint, marking the time position when the snapshot was formed.

[0078] Page identifiers determine the application page to which the changed field data belongs; user identifiers distinguish the user whose state has changed; business object identifiers differentiate different data objects within the same page; and runtime type distinguishes different container environments. The above identifier information, field change data, operation sequence information, version information, and snapshot generation time are written into a preset snapshot structure to generate an incremental state snapshot. The snapshot structure can use a field mapping object or a serialized data structure, with each component stored according to fixed field names and data types for easy identification by the state synchronization server.

[0079] The current network transmission status can be determined based on network connectivity, interface reachability, and the most recent transmission result. When in a transmittable state, incremental state snapshots are sent via the state synchronization interface. When in a non-transmittable state, incremental state snapshots, along with operation sequence information, are written to a reporting queue, which maintains its order according to the operation sequence information. After network transmission status recovers, incremental state snapshots in the queue are read and sent sequentially according to the operation sequence information, ensuring that continuous page state changes reach the state synchronization server in the original operation order.

[0080] This embodiment locates the page state fields before and after the state change operation through the page state model, and generates field change data according to a unified field granularity, which can reduce the duplicate recording and transmission of unchanged fields; by generating incremental state snapshots with version information, operation sequence information and snapshot timestamps, the version basis, operation order and time position can be identified, which can improve the distinguishability of continuous state changes; by judging the network state and saving incremental state snapshots generated during non-transferable periods in the reporting queue, the omission of state changes caused by network fluctuations can be reduced, and the reporting order of incremental state snapshots can be maintained.

[0081] In one embodiment, such as Figure 5 As shown, step S40 above includes: S401, Obtain the local page state stored locally on the application page, and read the local field state and local field version information corresponding to each page state field from the local page state; S402, extract the unified field status and unified field version information corresponding to each page status field from the unified version status snapshot; S403, according to the page status field, establish a field comparison correspondence between the unified field status and the corresponding local field status, and between the unified field version information and the corresponding local field version information, and generate field comparison data based on the field comparison correspondence; S404, Based on the field comparison data, compare the status values ​​of the unified field status with the corresponding local field status, and determine the page status fields with different status values ​​as the difference status fields. S405, based on the field comparison data, compare the version order of the unified field version information with the corresponding local field version information, generate the field version relationship corresponding to each page status field, and generate the version comparison result based on the field version relationship.

[0082] In this embodiment, the page identifier, field identifier, field value, and field version tag stored locally on the application page are read, and the data location corresponding to each page state field is located according to the field access path in the page state model. Page data objects, component states, page routing parameters, and field content stored in the local cache can all be included in the local page state. However, only the field state that matches the field identifier and storage location is retained for the same page state field to avoid incorrect correspondence between fields with the same name. The local field version information can be formed by combining the page-level version tag and the field-level update sequence number to indicate the version position to which the local field state belongs.

[0083] The unified field status and version information corresponding to each page status field are read from the unified version status snapshot according to the field identifier. The unified field status may include the field value, field validity flag, and field value type. The unified field version information may include the field version flag, status update time, and snapshot version flag. For page status fields that are missing in the local page status or unified version status snapshot, the field missing status is recorded to avoid equating field missingness directly with null values.

[0084] Based on the same page status field, a mapping relationship is established between the unified field status and the local field status, and a version mapping relationship is established between the unified field version information and the local field version information. Before establishing the mapping relationship, the format of the field values ​​involved in the comparison is standardized: text fields use consistent character encoding and whitespace format, numeric fields use consistent numeric precision, Boolean and enumeration fields use consistent value formats, and object fields are arranged according to attribute path and attribute name. The field comparison data records the field identifier, unified field status, local field status, unified field version information, local field version information, and field missing status, ensuring that the status value comparison and version comparison use the same field index.

[0085] The unified field status and local field status are compared based on the field value type. Basic type fields are compared by their standardized values; object type fields are compared by their corresponding attribute content; and collection type fields are compared by their element identifier, element quantity, and element content. When field values ​​differ, field valid markers differ, object attribute content differs, or one side of the field is missing, the corresponding page status field is identified as a difference status field. Page status fields that differ only in storage format but have the same standardized field value are not recorded as difference status fields.

[0086] The version code structure is used to compare the unified field version information and the local field version information. When the version code uses an incremental sequence number, the sequence number is compared. When the version code includes both the page version and the field update sequence number, the page version and the field update sequence number are compared sequentially. When the version code includes a timestamp, the timestamp can be used as an auxiliary comparison. The comparison results include "unified field version is newer," "local field version is newer," "versions are the same," and "version relationship cannot be determined." The comparison results corresponding to each page status field are recorded as field version relationships. Multiple field version relationships are summarized according to the page status field to generate version comparison results, ensuring that differences in status values ​​and version order remain independent.

[0087] This embodiment accurately matches the unified field status with the local field status by using field identifiers and field access paths, and standardizes the field value format before comparison, which can reduce misjudgments of status differences caused by character format, numerical precision, and object attribute order. By comparing field status and field version separately, it can simultaneously identify inconsistencies in content, version regression, and missing fields, so that the comparison results of different status fields and versions have clear data basis and improve the accuracy of page status difference identification.

[0088] In one embodiment, such as Figure 6 As shown, step S50 above includes: S501, extract the unified field status corresponding to each difference state field from the unified version status snapshot, and extract the local field status corresponding to each difference state field from the local page status. Based on the conflict information, determine the conflict state field from the difference state field, determine the conflict type corresponding to each conflict state field, and extract the server confirmation status corresponding to the conflict state field that needs server confirmation from the conflict information. Based on the version comparison result, determine the version rollback field from the difference state field. S502, Remove the version rollback field from the difference status field, determine the difference status field that belongs to the conflict status field in the remaining difference status field as the conflict handling field, and determine the difference status field other than the conflict handling field in the remaining difference status field as the direct update field; S503, determine the unified field status corresponding to each directly updated field as the target field status, and determine the conflict handling method based on the merging conditions and conflict type corresponding to each conflict handling field. For conflict handling fields that do not require server confirmation, determine the target field status based on the unified field status and local field status according to the conflict handling method. For conflict handling fields that require server confirmation, determine the target field status based on the corresponding server confirmation status according to the conflict handling method. S504, for each version rollback field, filter historical unified version state snapshots containing the corresponding field state and without associated conflict information from the stored historical unified version state snapshots, determine the historical unified version state snapshot with the latest version order as the most recent trusted state snapshot corresponding to each version rollback field, extract the trusted field state corresponding to each version rollback field from the most recent trusted state snapshot, and determine the trusted field state as the target field state corresponding to each version rollback field. S505, based on the page state model, update the target field state corresponding to each difference state field to the corresponding page state field in the application page, obtain the update completion status and update completion time corresponding to each difference state field, record the local field state, target field state, update completion status and update completion time corresponding to each difference state field, and generate the page recovery result.

[0089] In this embodiment, the unified field status corresponding to each differing state field is read from the unified version state snapshot according to the field identifier, and the local field status is read from the local page status according to the same field identifier. The unified field status reflects the field values ​​and field versions saved after the status is merged, while the local field status reflects the field values ​​currently held by the application page. The two types of field status are associated using the same data type and field granularity to avoid the impact of different object levels, null value forms, or numerical precision on subsequent status selection.

[0090] Based on the field identifiers in the conflict information, identify the conflict status fields in the difference status fields and read the conflict type corresponding to each conflict status field. Conflict types may include fields with the same version but different values, inconsistent field values ​​from different status sources, field statuses exceeding their validity period, and inconsistencies between the server-side confirmation status and the client-side field status. Conflict status fields requiring server confirmation are also associated with corresponding server-side confirmation statuses, reflecting server-side business records or confirmation results. Based on the version comparison results, identify the version fallback field. The version fallback field indicates that the unified field version or the field version to be adopted is earlier than the current trusted version; directly writing it to the page may cause a newer status to be overwritten by an earlier status.

[0091] After excluding the version rollback field from the difference status fields, the remaining fields are then divided based on the field identifiers of the conflict status fields. Difference status fields that are conflict status fields form conflict resolution fields, while those that are not conflicting form direct update fields. Version rollback fields, conflict resolution fields, and direct update fields use mutually exclusive sets of fields to avoid simultaneously determining the target field status for the same page status field using multiple methods.

[0092] For fields that are directly updated, if the unified field status has been merged and there are no associated conflicts, it can be directly identified as the target field status. For conflict-handling fields, the conflict handling method is selected according to the merging conditions and conflict type associated with the fields. Merging conditions can include source priority, expiration conditions, field merging method, and server confirmation identifier. For conflict-handling fields that do not require server confirmation, the target field status can be selected from the unified field status and local field status based on the field version, status source, update time, and valid status. Alternatively, valid attributes of object-type fields can be combined according to attribute-level merging methods. For conflict-handling fields that require server confirmation, the server confirmation status is used as the basis for status selection. When the server confirmation status includes confirmation version or confirmation time, it can also verify whether the server confirmation status is consistent with the business object identifier and field version of the conflict-handling field to avoid using confirmation results that do not belong to the current field status.

[0093] For the version rollback field, snapshots containing the corresponding field status are filtered from the stored historical unified version status snapshots according to the field identifier, excluding snapshots with associated conflict information. The remaining historical unified version status snapshots are compared in version order, and the snapshot with the latest version position that is earlier than the current abnormal version is determined as the most recent trusted status snapshot. The field value, field version, and valid status in the most recent trusted status snapshot constitute the trusted field status, and this trusted field status is determined as the target field status corresponding to the version rollback field. Different version rollback fields can be matched with their respective most recent trusted status snapshots; multiple fields are not required to roll back to the same snapshot version.

[0094] Based on the field access paths, field value types, and storage locations recorded in the page state model, the target field states corresponding to each differing state field are written into the page state fields of the application page. Basic type fields are replaced with their field values; object type fields can be updated according to the attribute path to reflect changed attributes; and collection type fields can be added, deleted, or replaced according to element identifiers. After the fields are written, the page data node or component state is read to determine if the written value matches the target field state, and the update completion status and update completion time are recorded. If the field path does not exist, the field type cannot be converted, or the state is inconsistent after writing, the incomplete state and corresponding time are recorded.

[0095] The local field status, target field status, update completion status, and update completion time corresponding to each difference status field are associated according to the field identifier to generate the page recovery result. The page recovery result reflects the status changes before and after the field update and the actual completion status, so that the page update results generated by direct update, conflict handling, and version rollback can be saved according to the same data structure.

[0096] This embodiment divides the difference status fields into direct update fields, conflict handling fields, and version rollback fields, and uses unified field status, conflict determination results, or the most recent trusted status snapshot to determine the status of the target fields, which can reduce the overwriting of current page data by conflict states and earlier version states. By locating the field positions based on the page status model and recording the status before and after the update, the update completion status, and the update completion time, the accuracy of page recovery can be improved, and the recovery results of each field can have clear status and time basis.

[0097] In one embodiment, such as Figure 7 As shown, step S60 above includes: S601, extract page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information and version information from the incremental state snapshot, and record the page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information and version information as snapshot reporting log items; S602, extract unified version information and a list of status merging fields from the unified version status snapshot, and record the page identifier, the user identifier, the business object identifier, the unified version information and the list of status merging fields as status merging log items; S603, extract the conflict status field and the conflict type corresponding to each conflict status field from the conflict information, associate the page identifier, the user identifier, the business object identifier, the conflict status field, the conflict type and the corresponding target field status, and generate a conflict processing log item; S604, extract each difference status field and the target field status, update completion status and update completion time corresponding to each difference status field from the page recovery result, generate a difference status field list based on each difference status field, and record the page identifier, the user identifier, the business object identifier, the difference status field list and the target field status, update completion status and update completion time corresponding to each difference status field as page recovery log items; S605, associate the snapshot reporting log item, the status merging log item, the conflict handling log item, and the page recovery log item with the page identifier, the user identifier, and the business object identifier, and organize the associated log items with the operation sequence information, the version information, and the unified version information to generate a page status synchronization log.

[0098] In this embodiment, page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information, and version information are read from the incremental state snapshot. The page identifier distinguishes the application page that caused the state change; the user identifier distinguishes the user to whom the state data belongs; the business object identifier distinguishes different data objects within the same page; and the runtime type marks the container environment in which the state change occurred. The operation sequence information indicates the order of state change operations within the same page session; the version information indicates the page state version on which the incremental state snapshot is based; and the snapshot generation time indicates the time when the incremental state snapshot was formed. The above information is written to the snapshot reporting log entry, ensuring that each incremental state report has a clear data attribution, runtime environment, operation order, and version basis.

[0099] Read the unified version information and the status merging field list from the unified version status snapshot. The unified version information represents the page status version formed after the field status merging is completed, and the status merging field list records the page status fields that participated in this status merging. Write the page identifier, user identifier, and business object identifier together with the unified version information and the status merging field list into the status merging log item, so that the reported version corresponding to the incremental status snapshot and the merged version can be associated with the same data objects.

[0100] The conflict status field and conflict type are read from the conflict information. The conflict status field is used to locate page status fields that cannot be directly adopted as a single candidate status. The conflict type is used to record conflict situations such as inconsistent field values, abnormal version relationships, inconsistent status sources, or inconsistent server-confirmed statuses. The conflict status field, conflict type, and the final adopted target field status are associated according to the field identifier and written to the page identifier, user identifier, and business object identifier to generate a conflict handling log item. The target field status is used to record the actual field value and corresponding version selected after conflict handling, ensuring that the content of the conflict corresponds to the handling result.

[0101] The page recovery results are used to read each difference status field and its corresponding target field status, update completion status, and update completion time. These fields are then arranged according to their field identifiers to form a difference status field list. The update completion status indicates whether the target field status has been written to the corresponding data location on the application page, and the update completion time indicates the time when the field update was completed or when the record was incomplete. The difference status field list, along with the corresponding target field status, update completion status, and update completion time, are written to the page recovery log entry to record the scope of page status updates and the actual update results for each field.

[0102] The system matches snapshot reporting log items, state merging log items, conflict handling log items, and page recovery log items according to page identifier, user identifier, and business object identifier, ensuring that log content generated by different pages, users, or business objects remains separate. The system determines the arrangement of state changes within the same page session based on operation sequence information, establishes a correspondence between incremental state versions and merged state versions based on version information and unified version information, and writes the associated log items into the same log data structure to generate a page state synchronization log. The page state synchronization log can be stored using structured objects, serialized records, or itemized storage structures. Each log item is configured with log type, field index, and time information to support reading the corresponding record according to page, business object, operation order, or version position.

[0103] This embodiment records the reporting information of incremental status snapshots, the merging information of unified version status snapshots, the processing results of conflict fields, and the recovery results of page fields separately, and associates them according to page identifier, user identifier, business object identifier, operation sequence information, and version information. This reduces confusion between different page status records, completely saves page status changes, status merging, conflict handling, and page update information, and improves the completeness, accuracy, and verifiability of page status synchronization records.

[0104] In one embodiment, such as Figure 8 As shown, after step S60 above, the following steps are also included: S701, acquire multiple page status synchronization logs, extract page identifier, operation sequence information, version information, snapshot generation time, update completion time, conflict type and update completion status from each page status synchronization log, determine page status fields from the status merging field list, conflict status field and difference status field list in each page status synchronization log, and aggregate the log content in each page status synchronization log according to the page identifier and the page status field to generate a field synchronization log set corresponding to each page status field; S702, in the synchronization log set of each field, the corresponding snapshot generation time, update completion time, conflict type and update completion status are associated with the same operation sequence information and version information. Based on the snapshot generation time and the update completion time, page recovery time data is generated. The page recovery time data, conflict type and update completion status corresponding to each page status field are statistically analyzed to generate page recovery time statistics, conflict count data and recovery incomplete count data. S703, the page status field that meets the preset recovery time condition, the conflict count condition, or the recovery incomplete count condition is determined as the target adjustment status field; S704, combine the conflict type, page recovery time statistics, conflict count data and recovery failure count data corresponding to each target adjustment status field to generate field synchronization feature data, obtain the status adjustment correspondence relationship that represents the correspondence between the field synchronization feature data and the status adjustment type, and determine the status adjustment type corresponding to each target adjustment status field based on the field synchronization feature data and the status adjustment correspondence relationship. S705, Based on the state adjustment type, generate merge condition adjustment data and synchronization level adjustment data corresponding to each target adjustment state field. The merge condition adjustment data includes source priority adjustment data, expiration condition adjustment data, field merging method adjustment data, and server confirmation identifier adjustment data. Associate the merge condition adjustment data and the synchronization level adjustment data with the corresponding target adjustment state fields to generate page state model adjustment data.

[0105] In this embodiment, multiple page state synchronization logs are read, and the page identifier, operation sequence information, version information, snapshot generation time, update completion time, conflict type, and update completion status are parsed according to a unified log field structure. The page identifier distinguishes the application page to which the log belongs; the operation sequence information and version information are used to locate the same page state change and its version position; the snapshot generation time indicates the time when the incremental state snapshot was formed; and the update completion time indicates the time when the corresponding page state field was updated or when incomplete results were recorded. The conflict type reflects situations where there are version differences, source differences, or confirmation status differences in the field state; and the update completion status reflects whether the target field state has been written to the corresponding page state field.

[0106] Identify the page state fields involved in each log from the state merge field list, conflict state field list, and difference state field list. The state merge field list reflects the range of fields participating in unified state merging, the conflict state field list reflects fields with state conflicts, and the difference state field list reflects fields where the unified field state differs from the local field state. The content of these three types of fields is deduplicated according to the field identifier, while retaining the correspondence between each page state field and its corresponding log item. Log content is aggregated according to page identifier and page state field, ensuring that snapshot reports, state merging, conflict handling, and page recovery records corresponding to the same page state field on the same page are written to the same field synchronization log set. Multiple page state synchronization logs can be selected according to statistical time range, log quantity range, or page version range to avoid state records that are too far apart being included in the same statistical result.

[0107] In the synchronized log sets for each field, snapshot generation time, update completion time, conflict type, and update completion status are matched according to the same operation sequence information and version information. The same operation sequence information confirms that each log item originates from the same state change operation, and the same version information confirms that the snapshot reported content and the page recovery content are within the same version range. The time interval between the update completion time and the corresponding snapshot generation time is recorded as the page recovery time data. Records lacking update completion time or with an incomplete update status do not generate valid time values, but retain an incomplete marker to avoid including incomplete page recovery records in the normal time consumption.

[0108] The system statistically analyzes the page recovery time data corresponding to each page status field, generating page recovery time statistics. These statistics include average time, maximum time, percentile time, time fluctuation, and the number of times the set time value was exceeded. The system also counts the number of state conflicts for each page status field according to conflict type, and combines the results of each type to generate conflict count data. Finally, it counts the number of records whose update completion status is changed to incomplete status, generating recovery incomplete count data. All statistical results are associated with the page identifier and page status fields, ensuring that the status representation of different pages or different fields is separated.

[0109] The system compares page recovery time statistics with preset recovery time conditions, conflict count data with preset conflict count conditions, and recovery failure count data with preset recovery failure count conditions. Preset conditions can be numerical thresholds, proportional thresholds, or continuous statistical period conditions. When any statistical result meets the corresponding preset condition, the relevant page status field is designated as the target adjustment status field. Using multiple conditions in parallel can identify fields with abnormal recovery times, frequent conflicts, or a large number of page recovery failures.

[0110] The conflict type, page recovery time statistics, conflict count data, and recovery incomplete count data corresponding to each target adjustment status field are combined according to the field identifier to generate field synchronization feature data. This field synchronization feature data can retain the frequency distribution, time statistics, and incomplete proportion of each conflict type, allowing different anomalies to participate in the determination of the status adjustment type. The status adjustment correspondence can be stored using a configuration table, mapping matrix, or condition set, recording the correspondence between the range of different field synchronization feature data and the status adjustment type. Matching the field synchronization feature data with the status adjustment correspondence yields the status adjustment type corresponding to each target adjustment status field.

[0111] Based on the status adjustment type, merge condition adjustment data and synchronization level adjustment data are generated. Source priority adjustment data is used to change the adoption order among different status sources; expiration condition adjustment data is used to change the validity period or expiration trigger condition of a field status; field merging method adjustment data is used to change the field processing method, such as prioritizing newer versions, higher sources, or attribute-level merging; server confirmation flag adjustment data is used to change whether a field requires server confirmation; and synchronization level adjustment data is used to change the reporting or restoration attention level of a field status. These adjustment data are then associated with the target adjustment status fields according to their field identifiers to generate page status model adjustment data, ensuring that each adjustment has a clearly defined applicable page, applicable field, and adjustment type.

[0112] This embodiment aggregates multiple page status synchronization logs by page identifier and page status field, and matches snapshot generation time, update completion time, conflict type, and update completion status according to operation sequence information and version information. This generates field-level statistics on recovery time, number of conflicts, and number of incomplete recovery attempts. Based on the statistical results, target adjustment status fields are selected, and then the field synchronization feature data and status adjustment correspondence are used to generate merged condition adjustment data and synchronization level adjustment data. This can accurately locate fields with concentrated page status recovery anomalies and make the page status model adjustment data have clear field objects, anomaly basis, and adjustment content.

[0113] In one embodiment, within a fintech business, the same benefits activity page can run on both the application's embedded end and multiple mini-program runtimes. Page structure data records the component nodes corresponding to the member information area, coupon redemption area, product inventory area, order payment area, vehicle information area, and filtering area. Status definition data records the status identifiers and status value types associated with each component node. Based on the page structure data and status definition data, page status fields are generated, including member level, coupon redemption status, remaining redemption count, product inventory status, add-to-cart status, order payment status, policy benefits status, vehicle binding status, address input status, page tabs, and filtering conditions.

[0114] Configure corresponding merging conditions for each page status field. Configure server-side confirmation identifiers for coupon redemption status, order payment status, policy benefit status, and vehicle binding status; configure expiration dates for membership level and product inventory status; configure the merging method for address input status and filter conditions based on the current input; and configure the merging method for page tabs based on client-side status. Establish a correspondence between each page status field and its source priority, expiration condition, merging method, and server-side confirmation identifier, and associate it with the page identifier of the benefit activity page to generate a page status model.

[0115] After a user completes vehicle switching, coupon redemption, and adding items to their cart on a specific operating system, the page state before and after the operation is read based on the page state model. This determines the changed vehicle binding status, coupon redemption status, remaining redemption attempts, item inventory status, and cart addition status, and generates field change data. An incremental state snapshot is composed of the page identifier, user identifier, business object identifier, operating system type, field change data, operation sequence information, version information, and snapshot generation time. When network transmission is unavailable, the incremental state snapshot is written to the reporting queue according to the operation sequence information and sent to the state synchronization server in sequence after network recovery.

[0116] When a user returns to the benefits activity page after completing payment, or re-enters the same page from another operating platform, the application page sends a status retrieval request. The status synchronization server looks up the incremental status snapshot and the stored current unified status snapshot based on the user identifier and business object identifier, and obtains the relevant server-side confirmed status from the coupon service, order service, benefits service, and vehicle service. If the coupon service has recorded that the coupon has been claimed, the claimed status is used; if the order service has recorded that the order has been paid, the paid status is used; if the vehicle service has confirmed that the vehicle has been switched, the new vehicle binding status is used. If the address input status and filter conditions are within the validity period and the version is relatively new, the client-side status can be retained. If a unique field status cannot be determined according to the merging conditions, the corresponding page status field is recorded as conflict field data, and conflict information is generated.

[0117] The application page compares the status values ​​and versions of the unified version status snapshot with the local page status. If the local coupon redemption status is "available for redemption" while the unified field status is "redeemed," then the coupon redemption status is determined as a difference status field. If the local order payment status is "pending payment" while the unified field status is "paid," then the order payment status is determined as a difference status field. If the local vehicle binding status still corresponds to the original vehicle, while the unified field status corresponds to the new vehicle, then the vehicle binding status is determined as a difference status field, and the version order of each field is recorded.

[0118] For difference status fields that do not conflict and have a relatively new unified field version, the unified field status is directly adopted. For conflict-handling fields that require server confirmation, the target field status is determined according to the server confirmation status. For fields such as address input status and filter conditions, the target field status is determined according to version information, update time, and expiration conditions. When version rollback is detected, the most recent trusted status snapshot without associated conflict information and with the latest version order is selected from the historical unified version status snapshots, and the trusted field status from that snapshot is adopted.

[0119] After the target field status is written to the corresponding page status field, the coupon claim button can switch from "available for claim" to "claimed," the order area can switch from "pending payment" to "paid," the vehicle information can switch to "new vehicle," and the product inventory and add-to-cart buttons will only update the changed content. The local field status, target field status, update completion status, and update completion time of each difference status field are recorded as the page restoration result.

[0120] Incremental state snapshots, unified version state snapshots, conflict information, and page recovery results are respectively generated as snapshot reporting log items, state merging log items, conflict handling log items, and page recovery log items. These are then associated according to page identifier, user identifier, business object identifier, operation sequence information, and version information to generate a page state synchronization log. Multiple page state synchronization logs can be further aggregated according to page state fields to statistically analyze page recovery time, number of conflicts, and number of incomplete recovery attempts. When order payment status frequently experiences state conflicts, the priority of server-side confirmation results can be increased; when there is a risk of duplicate operations in coupon redemption status, the server-side confirmation flag can be adjusted; when product inventory recovery takes a long time, the synchronization level can be adjusted; when filter conditions are frequently lost, expiration conditions can be adjusted, thereby generating page state model adjustment data.

[0121] In one embodiment, a page state synchronization device based on a state snapshot is provided, which corresponds one-to-one with the page state synchronization method based on a state snapshot described in the above embodiments. (Refer to...) Figure 9 , Figure 9 This is a schematic diagram of the functional modules of a preferred embodiment of the page state synchronization device based on state snapshots of the present invention. The page state synchronization device based on state snapshots includes: a page state modeling module 10, an incremental snapshot generation module 20, a unified state acquisition module 30, a state difference comparison module 40, a page state recovery module 50, and a synchronization log generation module 60. Detailed descriptions of each functional module are as follows: The page state modeling module 10 is used to obtain the page state fields of the application page, configure corresponding merging conditions for each page state field, and generate a page state model based on the page state fields and the merging conditions. The incremental snapshot generation module 20 is used to respond to the state change operation of the application page, determine the changed page state field based on the page state model, generate an incremental state snapshot containing version information, and send the incremental state snapshot to the state synchronization server. The unified state acquisition module 30 is used to respond to a page entry operation or page return operation on the application page, send a state acquisition request to the state synchronization server, and receive a unified version state snapshot and conflict information sent by the state synchronization server. The unified version state snapshot and conflict information are generated by the state synchronization server based on the incremental state snapshot, the server confirmation state corresponding to the incremental state snapshot, and the current unified state snapshot already stored by the state synchronization server, and according to the merging conditions. The status difference comparison module 40 is used to obtain the local page status containing version information stored locally on the application page, compare the unified version status snapshot with the local page status, and determine the difference status field and the version comparison result. Page state recovery module 50 is used to determine the target field state corresponding to the difference state field based on the unified version state snapshot, the conflict information and the version comparison result, update the application page based on the target field state, and generate page recovery result; The synchronization log generation module 60 is used to generate a page status synchronization log based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

[0122] In one embodiment, the page state modeling module 10 is specifically used for: Obtain the page structure data and state definition data of the application page, determine the state nodes from the page structure data, extract the state identifier and state value type corresponding to each state node from the state definition data, and associate each state node with the corresponding state identifier and state value type to obtain the page state field. Extract the status category, status source type, status validity period information, status update attribute and server confirmation requirement information corresponding to each page status field from the status definition data; determine the source priority based on the status source type; determine the expiration condition based on the status validity period information; determine the field merging method based on the status category and the status update attribute; and determine the server confirmation identifier based on the server confirmation requirement information. The server confirmation identifier, source priority, expiration condition and field merging method corresponding to each page status field are combined to generate the merging conditions corresponding to each page status field; Establish a field condition correspondence between each page status field and its corresponding merging condition, organize each page status field and its corresponding merging condition based on the field condition correspondence, and generate status field configuration data; Obtain the page identifier of the application page, associate the page identifier with the status field configuration data, and generate a page status model.

[0123] In one embodiment, the incremental snapshot generation module 20 is specifically used for: In response to a state change operation on the application page, the page state before and after the state change operation is obtained, and based on the page state model, the field state corresponding to each page state field is extracted from the page state before and after the state change operation to generate a set of field states before the operation and a set of field states after the operation. The pre-operation field status set and the post-operation field status set are compared item by item according to the page status field. The page status field whose field status has changed is determined as the changed page status field. Field change data is generated based on the pre-operation field status and post-operation field status corresponding to the changed page status field. Obtain the baseline version identifier currently saved on the application page and the operation sequence information corresponding to the state change operation, generate version information based on the baseline version identifier, and obtain the current time information, and determine the current time information as the snapshot generation time; Obtain the page identifier, user identifier, business object identifier, and current running terminal type of the application page; combine the page identifier, user identifier, business object identifier, running terminal type, field change data, operation sequence information, version information, and snapshot generation time to generate an incremental state snapshot containing version information; Obtain the current network transmission status. When the current network transmission status is transmissible, send the incremental status snapshot to the status synchronization server. When the current network transmission status is non-transmissible, write the incremental status snapshot into the reporting queue according to the operation sequence information. After the current network transmission status is converted to transmissible, send the incremental status snapshot in the reporting queue to the status synchronization server according to the operation sequence information.

[0124] In one embodiment, the state difference comparison module 40 is specifically used for: Obtain the local page state stored locally on the application page, and read the local field state and local field version information corresponding to each page state field from the local page state; Extract the unified field status and unified field version information corresponding to each page status field from the unified version status snapshot; Based on the page status field, establish a field comparison correspondence between the unified field status and the corresponding local field status, and between the unified field version information and the corresponding local field version information, and generate field comparison data based on the field comparison correspondence. Based on the field comparison data, the unified field status is compared with the corresponding local field status, and the page status fields with different status values ​​are identified as the difference status fields. Based on the field comparison data, the version order of the unified field version information and the corresponding local field version information is compared to generate the field version relationship of each page status field, and the version comparison result is generated based on the field version relationship.

[0125] In one embodiment, the page state restoration module 50 is specifically used for: Extract the unified field status corresponding to each difference state field from the unified version status snapshot, and extract the local field status corresponding to each difference state field from the local page status. Based on the conflict information, determine the conflict state field from the difference state field, determine the conflict type corresponding to each conflict state field, and extract the server confirmation status corresponding to the conflict state field that needs server confirmation from the conflict information. Based on the version comparison result, determine the version rollback field from the difference state field. Remove the version rollback field from the difference status field, determine the difference status field that belongs to the conflict status field in the remaining difference status field as the conflict handling field, and determine the difference status field other than the conflict handling field in the remaining difference status field as the direct update field; The unified field status corresponding to each directly updated field is determined as the target field status, and the conflict handling method is determined based on the merging conditions and conflict types corresponding to each conflict handling field. For conflict handling fields that do not require server confirmation, the target field status is determined based on the unified field status and local field status according to the conflict handling method. For conflict handling fields that require server confirmation, the target field status is determined based on the corresponding server confirmation status according to the conflict handling method. For each version rollback field, filter historical unified version status snapshots that contain the corresponding field status and are not associated with conflict information from the stored historical unified version status snapshots. Determine the historical unified version status snapshot with the latest version order as the most recent trusted status snapshot corresponding to each version rollback field. Extract the trusted field status corresponding to each version rollback field from the most recent trusted status snapshot, and determine the trusted field status as the target field status corresponding to each version rollback field. Based on the page state model, the target field state corresponding to each difference state field is updated to the corresponding page state field in the application page. The update completion status and update completion time corresponding to each difference state field are obtained. The local field state, target field state, update completion status and update completion time corresponding to each difference state field are recorded to generate the page recovery result.

[0126] In one embodiment, the synchronization log generation module 60 is specifically used for: Extract page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information, and version information from the incremental state snapshot, and record the page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information, and version information as snapshot reporting log items; Extract unified version information and a list of status merging fields from the unified version status snapshot, and record the page identifier, the user identifier, the business object identifier, the unified version information, and the list of status merging fields as status merging log items; Extract the conflict status field and the conflict type corresponding to each conflict status field from the conflict information, and associate the page identifier, the user identifier, the business object identifier, the conflict status field, the conflict type and the corresponding target field status to generate a conflict processing log item; Extract each difference status field and the corresponding target field status, update completion status and update completion time from the page recovery result. Generate a difference status field list based on each difference status field. Record the page identifier, the user identifier, the business object identifier, the difference status field list and the corresponding target field status, update completion status and update completion time as page recovery log items. The snapshot reporting log item, the status merging log item, the conflict handling log item, and the page recovery log item are associated with the page identifier, the user identifier, and the business object identifier. The associated log items are then organized according to the operation sequence information, the version information, and the unified version information to generate a page status synchronization log.

[0127] In one embodiment, the synchronization log generation module 60 is specifically used for: Multiple page status synchronization logs are obtained. Page identifier, operation sequence information, version information, snapshot generation time, update completion time, conflict type, and update completion status are extracted from each page status synchronization log. Page status fields are determined from the status merging field list, conflict status field, and difference status field list in each page status synchronization log. The log content in each page status synchronization log is aggregated according to the page identifier and the page status field to generate a field synchronization log set corresponding to each page status field. In the synchronization log set of each field, the corresponding snapshot generation time, update completion time, conflict type and update completion status are associated with the same operation sequence information and version information. Page recovery time data is generated based on the snapshot generation time and the update completion time. The page recovery time data, conflict type and update completion status corresponding to each page status field are statistically analyzed to generate page recovery time statistics, conflict count data and recovery failure count data. The page status fields that meet the preset recovery time conditions, the preset conflict count conditions, or the preset recovery incomplete count conditions are identified as the target adjustment status fields. The conflict type, page recovery time statistics, conflict count data, and recovery failure count data corresponding to each target adjustment status field are combined to generate field synchronization feature data. The status adjustment correspondence relationship that represents the correspondence between the field synchronization feature data and the status adjustment type is obtained. Based on the field synchronization feature data and the status adjustment correspondence relationship, the status adjustment type corresponding to each target adjustment status field is determined. Based on the status adjustment type, merge condition adjustment data and synchronization level adjustment data corresponding to each target adjustment status field are generated. The merge condition adjustment data includes source priority adjustment data, expiration condition adjustment data, field merging method adjustment data, and server confirmation identifier adjustment data. The merge condition adjustment data and the synchronization level adjustment data are associated with the corresponding target adjustment status fields to generate page status model adjustment data.

[0128] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides deterministic and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements server-side functions or steps of a state snapshot-based page state synchronization method.

[0129] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a state snapshot-based page state synchronization method.

[0130] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the page status fields of the application page, configure corresponding merging conditions for each page status field, and generate a page status model based on the page status fields and the merging conditions; In response to a state change operation on the application page, the changed page state fields are determined based on the page state model, an incremental state snapshot containing version information is generated, and the incremental state snapshot is sent to the state synchronization server. In response to a page entry or page return operation on the application page, a status acquisition request is sent to the status synchronization server, and a unified version status snapshot and conflict information are received from the status synchronization server. The unified version status snapshot and conflict information are generated by the status synchronization server based on the incremental status snapshot, the server confirmation status corresponding to the incremental status snapshot, and the current unified status snapshot already stored by the status synchronization server, and in accordance with the merging conditions. Obtain the local page state containing version information stored locally on the application page, compare the state difference and version with the unified version state snapshot, and determine the difference state field and version comparison result; Based on the unified version status snapshot, the conflict information, and the version comparison result, the target field status corresponding to the difference status field is determined, and the application page is updated based on the target field status to generate a page recovery result. A page status synchronization log is generated based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

[0131] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Obtain the page status fields of the application page, configure corresponding merging conditions for each page status field, and generate a page status model based on the page status fields and the merging conditions; In response to a state change operation on the application page, the changed page state fields are determined based on the page state model, an incremental state snapshot containing version information is generated, and the incremental state snapshot is sent to the state synchronization server. In response to a page entry or page return operation on the application page, a status acquisition request is sent to the status synchronization server, and a unified version status snapshot and conflict information are received from the status synchronization server. The unified version status snapshot and conflict information are generated by the status synchronization server based on the incremental status snapshot, the server confirmation status corresponding to the incremental status snapshot, and the current unified status snapshot already stored by the status synchronization server, and in accordance with the merging conditions. Obtain the local page state containing version information stored locally on the application page, compare the state difference and version with the unified version state snapshot, and determine the difference state field and version comparison result; Based on the unified version status snapshot, the conflict information, and the version comparison result, the target field status corresponding to the difference status field is determined, and the application page is updated based on the target field status to generate a page recovery result. A page status synchronization log is generated based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

[0132] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0133] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0135] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0136] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A page state synchronization method based on state snapshots, characterized in that, Includes the following steps: Obtain the page status fields of the application page, configure corresponding merging conditions for each page status field, and generate a page status model based on the page status fields and the merging conditions; In response to a state change operation on the application page, the changed page state fields are determined based on the page state model, an incremental state snapshot containing version information is generated, and the incremental state snapshot is sent to the state synchronization server. In response to a page entry or page return operation on the application page, a status acquisition request is sent to the status synchronization server, and a unified version status snapshot and conflict information are received from the status synchronization server. The unified version status snapshot and conflict information are generated by the status synchronization server based on the incremental status snapshot, the server confirmation status corresponding to the incremental status snapshot, and the current unified status snapshot already stored by the status synchronization server, and in accordance with the merging conditions. Obtain the local page state containing version information stored locally on the application page, compare the state difference and version with the unified version state snapshot, and determine the difference state field and version comparison result; Based on the unified version status snapshot, the conflict information, and the version comparison result, the target field status corresponding to the difference status field is determined, and the application page is updated based on the target field status to generate a page recovery result. A page status synchronization log is generated based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

2. The page state synchronization method based on state snapshots as described in claim 1, characterized in that, Obtain the page status fields of the application page, configure corresponding merging conditions for each page status field, and generate a page status model based on the page status fields and the merging conditions, including: Obtain the page structure data and state definition data of the application page, determine the state nodes from the page structure data, extract the state identifier and state value type corresponding to each state node from the state definition data, and associate each state node with the corresponding state identifier and state value type to obtain the page state field. Extract the status category, status source type, status validity period information, status update attribute and server confirmation requirement information corresponding to each page status field from the status definition data; determine the source priority based on the status source type; determine the expiration condition based on the status validity period information; determine the field merging method based on the status category and the status update attribute; and determine the server confirmation identifier based on the server confirmation requirement information. The server confirmation identifier, source priority, expiration condition and field merging method corresponding to each page status field are combined to generate the merging conditions corresponding to each page status field; Establish a field condition correspondence between each page status field and its corresponding merging condition, organize each page status field and its corresponding merging condition based on the field condition correspondence, and generate status field configuration data; Obtain the page identifier of the application page, associate the page identifier with the status field configuration data, and generate a page status model.

3. The page state synchronization method based on state snapshots as described in claim 1, characterized in that, In response to a state change operation on the application page, based on the page state model, the changed page state fields are determined, an incremental state snapshot containing version information is generated, and the incremental state snapshot is sent to the state synchronization server, including: In response to a state change operation on the application page, the page state before and after the state change operation is obtained, and based on the page state model, the field state corresponding to each page state field is extracted from the page state before and after the state change operation to generate a set of field states before the operation and a set of field states after the operation. The pre-operation field status set and the post-operation field status set are compared item by item according to the page status field. The page status field whose field status has changed is determined as the changed page status field. Field change data is generated based on the pre-operation field status and post-operation field status corresponding to the changed page status field. Obtain the baseline version identifier currently saved on the application page and the operation sequence information corresponding to the state change operation, generate version information based on the baseline version identifier, and obtain the current time information, and determine the current time information as the snapshot generation time; Obtain the page identifier, user identifier, business object identifier, and current running terminal type of the application page; combine the page identifier, user identifier, business object identifier, running terminal type, field change data, operation sequence information, version information, and snapshot generation time to generate an incremental state snapshot containing version information; Obtain the current network transmission status. When the current network transmission status is transmissible, send the incremental status snapshot to the status synchronization server. When the current network transmission status is non-transmissible, write the incremental status snapshot into the reporting queue according to the operation sequence information. After the current network transmission status is converted to transmissible, send the incremental status snapshot in the reporting queue to the status synchronization server according to the operation sequence information.

4. The page state synchronization method based on state snapshots as described in claim 1, characterized in that, Obtain the local page state containing version information stored locally on the application page; compare the unified version state snapshot with the local page state for state difference and version comparison; determine the difference state fields and version comparison results, including: Obtain the local page state stored locally on the application page, and read the local field state and local field version information corresponding to each page state field from the local page state; Extract the unified field status and unified field version information corresponding to each page status field from the unified version status snapshot; Based on the page status field, establish a field comparison correspondence between the unified field status and the corresponding local field status, and between the unified field version information and the corresponding local field version information, and generate field comparison data based on the field comparison correspondence. Based on the field comparison data, the unified field status is compared with the corresponding local field status, and the page status fields with different status values ​​are identified as the difference status fields. Based on the field comparison data, the version order of the unified field version information and the corresponding local field version information is compared to generate the field version relationship of each page status field, and the version comparison result is generated based on the field version relationship.

5. The page state synchronization method based on state snapshots as described in claim 1, characterized in that, Based on the unified version status snapshot, the conflict information, and the version comparison result, the target field status corresponding to the difference status field is determined. Based on the target field status, the application page is updated, and a page recovery result is generated, including: Extract the unified field status corresponding to each difference state field from the unified version status snapshot, and extract the local field status corresponding to each difference state field from the local page status. Based on the conflict information, determine the conflict state field from the difference state field, determine the conflict type corresponding to each conflict state field, and extract the server confirmation status corresponding to the conflict state field that needs server confirmation from the conflict information. Based on the version comparison result, determine the version rollback field from the difference state field. Remove the version rollback field from the difference status field, determine the difference status field that belongs to the conflict status field in the remaining difference status field as the conflict handling field, and determine the difference status field other than the conflict handling field in the remaining difference status field as the direct update field; The unified field status corresponding to each directly updated field is determined as the target field status, and the conflict handling method is determined based on the merging conditions and conflict types corresponding to each conflict handling field. For conflict handling fields that do not require server confirmation, the target field status is determined based on the unified field status and local field status according to the conflict handling method. For conflict handling fields that require server confirmation, the target field status is determined based on the corresponding server confirmation status according to the conflict handling method. For each version rollback field, filter historical unified version status snapshots that contain the corresponding field status and are not associated with conflict information from the stored historical unified version status snapshots. Determine the historical unified version status snapshot with the latest version order as the most recent trusted status snapshot corresponding to each version rollback field. Extract the trusted field status corresponding to each version rollback field from the most recent trusted status snapshot, and determine the trusted field status as the target field status corresponding to each version rollback field. Based on the page state model, the target field state corresponding to each difference state field is updated to the corresponding page state field in the application page. The update completion status and update completion time corresponding to each difference state field are obtained. The local field state, target field state, update completion status and update completion time corresponding to each difference state field are recorded to generate the page recovery result.

6. The page state synchronization method based on state snapshots as described in claim 1, characterized in that, A page status synchronization log is generated based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result, including: Extract page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information, and version information from the incremental state snapshot, and record the page identifier, user identifier, business object identifier, snapshot generation time, runtime type, operation sequence information, and version information as snapshot reporting log items; Extract unified version information and a list of status merging fields from the unified version status snapshot, and record the page identifier, the user identifier, the business object identifier, the unified version information, and the list of status merging fields as status merging log items; Extract the conflict status field and the conflict type corresponding to each conflict status field from the conflict information, and associate the page identifier, the user identifier, the business object identifier, the conflict status field, the conflict type and the corresponding target field status to generate a conflict processing log item; Extract each difference status field and the corresponding target field status, update completion status and update completion time from the page recovery result. Generate a difference status field list based on each difference status field. Record the page identifier, the user identifier, the business object identifier, the difference status field list and the corresponding target field status, update completion status and update completion time as page recovery log items. The snapshot reporting log item, the status merging log item, the conflict handling log item, and the page recovery log item are associated with the page identifier, the user identifier, and the business object identifier. The associated log items are then organized according to the operation sequence information, the version information, and the unified version information to generate a page status synchronization log.

7. The page state synchronization method based on state snapshots as described in claim 1, characterized in that, After generating the page status synchronization log based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result, the method further includes: Multiple page status synchronization logs are obtained. Page identifier, operation sequence information, version information, snapshot generation time, update completion time, conflict type, and update completion status are extracted from each page status synchronization log. Page status fields are determined from the status merging field list, conflict status field, and difference status field list in each page status synchronization log. The log content in each page status synchronization log is aggregated according to the page identifier and the page status field to generate a field synchronization log set corresponding to each page status field. In the synchronization log set of each field, the corresponding snapshot generation time, update completion time, conflict type and update completion status are associated with the same operation sequence information and version information. Page recovery time data is generated based on the snapshot generation time and the update completion time. The page recovery time data, conflict type and update completion status corresponding to each page status field are statistically analyzed to generate page recovery time statistics, conflict count data and recovery failure count data. The page status fields that meet the preset recovery time conditions, the preset conflict count conditions, or the preset recovery incomplete count conditions are identified as the target adjustment status fields. The conflict type, page recovery time statistics, conflict count data, and recovery failure count data corresponding to each target adjustment status field are combined to generate field synchronization feature data. The status adjustment correspondence relationship that represents the correspondence between the field synchronization feature data and the status adjustment type is obtained. Based on the field synchronization feature data and the status adjustment correspondence relationship, the status adjustment type corresponding to each target adjustment status field is determined. Based on the status adjustment type, merge condition adjustment data and synchronization level adjustment data corresponding to each target adjustment status field are generated. The merge condition adjustment data includes source priority adjustment data, expiration condition adjustment data, field merging method adjustment data, and server confirmation identifier adjustment data. The merge condition adjustment data and the synchronization level adjustment data are associated with the corresponding target adjustment status fields to generate page status model adjustment data.

8. A page state synchronization device based on state snapshots, characterized in that, The page state synchronization device based on state snapshots includes: The page state modeling module is used to obtain the page state fields of the application page, configure corresponding merging conditions for each page state field, and generate a page state model based on the page state fields and the merging conditions. The incremental snapshot generation module is used to respond to the state change operation of the application page, determine the changed page state fields based on the page state model, generate an incremental state snapshot containing version information, and send the incremental state snapshot to the state synchronization server. The unified state acquisition module is used to respond to a page entry operation or page return operation on the application page, send a state acquisition request to the state synchronization server, and receive a unified version state snapshot and conflict information sent by the state synchronization server. The unified version state snapshot and conflict information are generated by the state synchronization server based on the incremental state snapshot, the server confirmation state corresponding to the incremental state snapshot, and the current unified state snapshot already stored by the state synchronization server, and according to the merging conditions. The status difference comparison module is used to obtain the local page status containing version information stored locally on the application page, compare the unified version status snapshot with the local page status, and determine the difference status field and the version comparison result. The page state recovery module is used to determine the target field state corresponding to the difference state field based on the unified version state snapshot, the conflict information and the version comparison result, update the application page based on the target field state, and generate a page recovery result. The synchronization log generation module is used to generate page status synchronization logs based on the incremental status snapshot, the unified version status snapshot, the conflict information, the target field status, and the page recovery result.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a snapshot-based page state synchronization program stored in the memory and executable on the processor, wherein the snapshot-based page state synchronization program, when executed by the processor, implements the steps of the snapshot-based page state synchronization method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a state snapshot-based page state synchronization program, which, when executed by a processor, implements the steps of the state snapshot-based page state synchronization method as described in any one of claims 1-7.

Images