Mobile application platform fusion base development method and device

Abstract

The present application provides a method and device for developing a mobile application platform fusion base, which relates to the field of information technology, including: based on the analysis results of data dependencies between different modules, judging whether there are data dependency conflicts and version conflicts, and if so, using a pre-set mobile application data conflict solution and version compatibility analysis method to merge data for dependency conflicts and version conflicts; based on the results of data merging, updating the version number of local data, forming association information between the merged data and the local data version, and using a pre-defined timestamp record format standard to synchronously record the modification time of each piece of data. Solve the data synchronization problem of mobile applications in offline environments, ensure data consistency, reduce data loss and user intervention, and improve synchronization efficiency and user experience.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a method and device for developing a mobile application platform fusion base. Background Art

[0002] When implementing offline capabilities, the mobile application platform fusion base faces technical contradictions in data synchronization and version management. When the application runs without a network connection, how to ensure the consistency of local data and server data becomes a key issue. Since the data cannot be synchronized in real time, conflicts and overwriting between local data and server data may occur. At the same time, in an offline environment, the application also needs to be able to detect and obtain the latest version of the server so that it can be automatically synchronized and updated when the network connection is restored. This requires the application to have the ability of version management and incremental update, to be able to identify the difference between the local version and the server version, and to synchronize only the necessary data and files to reduce the amount of data transmission and synchronization time. In summary, when implementing the offline capabilities of mobile applications, while ensuring data consistency and user experience, the performance and resource consumption of the application are taken into account, which puts high demands on the architectural design and implementation of the mobile application platform fusion base. Summary of the invention

[0003] The present invention provides a method for developing a mobile application platform fusion base, which mainly includes:

[0004] Obtain local data and server-side data from the mobile application platform, perform data comparison for data modifications and additions in an offline environment, identify the differences between local data and server-side data, and simultaneously obtain local version numbers and server-side version numbers, and analyze the differences between data versions based on preset version number naming conventions; for data with version differences, merge the locally modified data on the mobile application platform with the server-side data, including analyzing the data dependency relationships between different modules of the mobile application platform based on a pre-built version dependency graph, determining the order of data merging based on the dependency relationships, and dynamically selecting incremental synchronization, batch synchronization, or scheduled synchronization methods based on the network connection status of the mobile device and a preset version update strategy, and adjusting the synchronization task scheduling strategy; based on the analysis results of the data dependency relationships between different modules, determine whether there are data dependency conflicts and version conflicts, and if so, use the pre-set mobile synchronization methods for the dependency conflict data and version conflicts, respectively. The method uses the mobile application data conflict resolution method and version compatibility analysis method to merge data; based on the result of the data merge, the version number of the local data is updated, and the merged data is associated with the local data version. At the same time, the predefined timestamp record format standard is used to synchronously record the modification time of each data; after the data synchronization result and the version update result are confirmed, the execution status and key information of the synchronization and update process are obtained by calling the synchronization result status acquisition interface and the version update result acquisition interface, and the predefined data modification time capture method is used to record the modification time point of the data during the synchronization and update process to form a synchronization and update log; based on the synchronization and update log, the key information in the synchronization and update process, including the mobile application platform data modification content, modification time point, and version number, is extracted and recorded in accordance with the predefined key information format, and the extracted key information is persistently stored in a preset storage method to form structured synchronization and update log data.

[0005] The present invention provides a mobile application platform fusion base development device, which mainly includes: a data acquisition and comparison module, which is used to acquire local data and server data of the mobile application platform, perform data comparison for data modification and addition in an offline environment, identify the difference between local data and server data, and simultaneously acquire the local version number and the server version number, and analyze the difference between data versions based on a preset version number naming specification; a data merging and dependency analysis module, which is used to merge the data modified locally on the mobile application platform with the server data for data with version differences, including analyzing the data dependency relationship between different modules of the mobile application platform based on a pre-built version dependency relationship graph, determining the order of data merging according to the dependency relationship, and dynamically selecting incremental synchronization, batch synchronization or scheduled synchronization mode according to the network connection status of the mobile device and the preset version update strategy, and adjusting the synchronization task scheduling strategy; a conflict resolution and version compatibility module, which is used to determine whether there is a data dependency conflict and version conflict based on the analysis results of the data dependency relationship between different modules, and if so, , respectively using the pre-set mobile application data conflict solution and version compatibility analysis method to merge data; the version update and timestamp recording module is used to update the version number of local data according to the result of data merging, and form associated information between the merged data and the local data version, and at the same time use the predefined timestamp recording format standard to synchronously record the modification time of each data; the synchronization status acquisition and log recording module is used to obtain the execution status and key information of the synchronization and update process by calling the synchronization result status acquisition interface and the version update result acquisition interface after the data synchronization result and the version update result are confirmed, and use the predefined data modification time capture method to record the modification time point of the data in the synchronization and update process to form a synchronization and update log; the key information extraction and storage module, based on the synchronization and update log, extracts and records the key information in the synchronization and update process, including the mobile application platform data modification content, modification time point, and version number, in accordance with the predefined key information format, and stores the extracted key information persistently according to the preset storage method to form structured synchronization and update log data.

[0006] The technical solution provided by the embodiment of the present invention may have the following beneficial effects:

[0007] The present invention discloses a method for developing a fusion base for a mobile application platform. The method compares local and server data, identifies differences and performs intelligent merging. It analyzes data dependencies between modules based on a version dependency graph and determines the merging order. For dependency conflicts and version conflicts, a preset conflict resolution method is adopted, such as taking the server data as the standard or retaining dual versions. At the same time, a synchronization strategy is dynamically selected according to the network status, such as incremental or batch synchronization. In addition, the present invention also processes conflicting data according to business rules and user intentions. During the synchronization process, the data modification time is recorded and a structured log is generated. This method can effectively solve the data synchronization problem of mobile applications in an offline environment, ensure data consistency, reduce data loss and user intervention, and improve synchronization efficiency and user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 The present invention is a flow chart of the mobile application platform fusion base development method. DETAILED DESCRIPTION

[0009] The following will describe the technical solutions in the embodiments of the present invention in detail in conjunction with the accompanying drawings in the embodiments of the present invention. The described embodiments are only part of the embodiments of the present invention.

[0010] like Figure 1 The mobile application platform fusion base development method of this embodiment may specifically include:

[0011] S101, obtain local data and server data of the mobile application platform, compare data for data modification and addition in an offline environment, and identify the differences between local data and server data. At the same time, obtain the local version number and server version number, and analyze the differences between data versions based on the preset version number naming convention.

[0012] Get the data records in the local database and the data records in the server. The data records contain a unique identifier, timestamp and field value. Build a JSON format data object array based on the data records. The JSON format data object array contains complete data content. Compare the last modification time of the local data and the server data through the timestamp field in the JSON format data object array. If the local data timestamp is later than the server data timestamp, mark the record as a synchronization item. Analyze the local data and the server data, compare the value of each field by traversing the JSON format data object array, and record the difference information when inconsistency is found to obtain a difference result set containing all difference items.

[0013] Exemplarily, when obtaining local data and server data of a mobile application platform, data records are read from the local SQLite database and the server respectively, and information such as a unique identifier, timestamp, and field value are extracted for each record to construct a JSON format data object array containing complete data content. For data modification and addition in an offline environment, the last modification time of local data and server data is compared through the timestamp field in the data object array. If the local data timestamp is later than the server data timestamp, the record is marked as a synchronization item, and the modified field value is compared with the original value one by one to obtain the difference data. Myer's difference algorithm is used to analyze local data and server data, and the value of each field is compared by traversing the JSON data object array. When inconsistencies are found, the difference information is recorded, including the field name, local value, and server value, and finally a difference result set containing all difference items is generated. When obtaining local data of a mobile application platform, the SQLite database interface is used to read the data table stored in the internal storage of the device, and all fields are selected through SQL query statements and arranged in descending order according to timestamps to obtain a result set containing complete records. At the same time, an HTTP GET request is sent to the server through the RESTful API interface to obtain the corresponding server data. The request contains the authentication token and device identifier, and the server returns a data response in JSON format based on this information. The local data and server data are stored in two data structures in memory respectively, and each record contains information such as a unique identifier, a timestamp, and a field value. For data modification and addition in an offline environment, a local queue mechanism is implemented. When the network connection is detected to be disconnected, all data operation requests are added to a FIFO queue. Each queue item contains the operation type (modification or addition), data content, and a timestamp. When the network is restored, the queue is traversed and each operation is processed. For modification operations, a field-level difference detection algorithm is used to compare the modified value with the original value to generate a difference object containing the changed field name and the new value. For addition operations, the complete record is directly marked as a to-be-synchronized item. A hash value comparison algorithm is used to analyze local data and server data. First, all field values ​​of each record are concatenated, and then a fixed-length hash value is calculated using the SHA-256 hash function. By comparing the hash values ​​of local records and server records, the changed records can be quickly identified. For records with inconsistent hash values, further use field-level comparison to determine which specific fields have changed. Collect all difference information into a difference result set, including record identifiers, changed field names, local values, and server values. After obtaining the local version number and server version number, use the Semantic Versioning specification for parsing. The version number format is "major version number.minor version number.revision number", such as "2.4.1".Extract each numerical part by string segmentation and convert it into integer for comparison. If the local version is lower than the server version, trigger the incremental update process. The server maintains a version difference log to record the specific changes of each version update. According to the local version number, obtain the difference data of all subsequent versions from the server. Apply these difference data to the local database one by one in the order of version numbers to achieve progressive data synchronization. When applying updates, use the transaction mechanism to ensure data consistency, and roll back if an error occurs in the middle.

[0014] S102: For data with version differences, the data modified locally on the mobile application platform is merged with the server-side data, including analyzing the data dependency relationship between different modules of the mobile application platform based on a pre-built version dependency graph, and determining the order of data merging according to the dependency relationship. At the same time, according to the network connection status of the mobile device and the preset version update strategy, the incremental synchronization, batch synchronization or scheduled synchronization mode is dynamically selected to adjust the synchronization task scheduling strategy.

[0015] According to the pre-established version dependency graph, the version information of each module is obtained from the local database; the dependency graph is topologically sorted to obtain the dependency order between modules; and the sorting results are stored in the priority queue data structure. The data with version differences are merged using a three-way merge algorithm; the data records to be merged are obtained from the local database and the server respectively; the differences are identified by comparing the MD5 hash values ​​of the field values ​​to generate a merged result set; the network connection status information of the mobile device is obtained; it is determined whether the current network type is WIFI or a mobile data network; if it is determined to be a mobile data network, the incremental synchronization based on the timestamp is triggered; if it is determined to be a WIFI network, the batch synchronization process based on the data block is started. For mobile data networks, only data records modified after the last synchronization time are synchronized. For WIFI networks, the data to be synchronized is divided into fixed-size data blocks, and multi-threaded parallel transmission is used for data transmission. The execution strategy of the synchronization task is dynamically adjusted through the distributed task scheduler, including setting the priority, concurrency and retry times of the synchronization task according to different network states and data volumes; when the network is unstable, the retry interval is calculated, the location of the synchronized data block is recorded, and synchronization continues from the breakpoint after the network is restored.

[0016] Exemplarily, according to the pre-built version dependency graph, the version information of each module is read from the local SQLite database, and the dependency graph is topologically sorted by the Kahn algorithm to obtain the dependency order between modules and determine the priority order of data merging. The sorting results are stored in the priority queue data structure in the memory for subsequent sequential processing. A three-way merge algorithm based on Git is used to merge data with version differences, and the data records to be merged are obtained from the local database and the server respectively. The differences are quickly identified by comparing the MD5 hash values ​​of the field values ​​to generate a merged result set. If a conflict occurs, it is automatically resolved according to the preset latest winning rule based on the timestamp, and the result is written to the local database and marked as merged. The network connection status information of the mobile device is obtained, and the current network type is determined by the Android or iOS native API. Whether it is WIFI, 4G or 5G. If it is a mobile data network, the incremental synchronization process is triggered, and the incremental synchronization algorithm based on the timestamp is used to synchronize only the data records modified after the last synchronization time. If it is a WIFI network, a batch synchronization process based on data blocks is started, and the data to be synchronized is divided into data blocks of fixed size, and a multi-threaded parallel transmission method is used to improve the synchronization efficiency. The distributed task scheduler Apache Airflow is used to dynamically adjust the execution strategy of synchronization tasks, and the priority, concurrency, and retry times of synchronization tasks are set according to different network states and data volumes. When the network is unstable, an exponential backoff algorithm is used to calculate the retry interval. The initial waiting time is 100 milliseconds, and the waiting time is doubled after each retry. The maximum waiting time does not exceed 30 seconds. At the same time, the breakpoint resume function is implemented to record the location of the synchronized data block and continue synchronization from the breakpoint after the network is restored. According to the pre-built version dependency graph, a directed acyclic graph (DAG) is used to represent the dependency relationship between modules. Each node represents a module, and the edge represents the dependency relationship. The version information of each module is read from the local SQLite database, including the module identifier, version number, and dependency list. The Kahn algorithm is used for topological sorting, a queue is initialized, and all nodes with an in-degree of 0 are added to the queue. The nodes in the queue are processed cyclically, and a node is taken out of the queue each time, added to the result list, and the in-degree of its adjacent nodes is reduced. If the in-degree of the adjacent node becomes 0, it is added to the queue. Repeat this process until the queue is empty, get the topological sorting result of the module, and determine the priority order of data merging. According to the topological sorting result, process the data merging task of each module in turn. Use the three-way merge algorithm to merge data with version differences, and obtain the data records to be merged from the local database and the server respectively. For each field, compare the values ​​of the local version, server version, and common ancestor version. If the three are the same, keep it unchanged. If the local version is different from the server version but one of them is the same as the ancestor version, use the changed value.If both the local version and the server version have changed, they will be automatically resolved or marked for manual processing according to the preset merge rules. The merge rules may include timestamp priority, field priority, etc. Use the ConnectivityManager function of Android or the Reachability framework of iOS to obtain the network connection status information of the mobile device and determine whether the current network type is a mobile data network or WIFI. If it is a mobile data network, the incremental synchronization process is triggered, and the timestamp comparison method is used to synchronize only the data records modified after the last synchronization time. If it is a WIFI network, the batch synchronization process is started, and the data block transmission method is used to divide the data to be synchronized into blocks of fixed size (such as 1MB) and transmit them block by block. For scheduled synchronization, use cron expressions to set periodic tasks, such as performing full synchronization at 3 am every day. Dynamically adjust the execution strategy of synchronization tasks through the distributed task scheduler, and use priority queues to manage synchronization tasks. Set task priority according to network status and data volume, such as batch synchronization tasks under WIFI network have higher priority than incremental synchronization tasks under mobile network. Set concurrency limits, such as a maximum of 5 concurrent synchronization tasks under WIFI network and a maximum of 2 under mobile network. The exponential backoff algorithm is used to calculate the retry interval, with an initial interval of 1 second, which doubles after each failure, a maximum interval of 60 seconds, and a maximum of 5 retries. During task execution, the network status changes are monitored in real time. When the network status changes, the execution strategy of the current task is re-evaluated, and the task is paused, resumed, or rescheduled when necessary.

[0017] S103. Based on the analysis results of the data dependency relationships between different modules, determine whether there are data dependency conflicts and version conflicts. If so, use a pre-set mobile application data conflict resolution method and version compatibility analysis method to merge data for dependency conflicts and version conflicts.

[0018] Construct a directed acyclic graph, which represents the data dependency relationship between modules of the mobile application platform. According to the directed acyclic graph, obtain the data records of the relevant modules from the local database and the server. For the obtained data records, compare the data version number and timestamp to determine whether there is a dependency conflict and version conflict. If it is determined that there is a dependency conflict, the conflict is automatically handled according to the conflict type and the predefined resolution strategy. If it is determined that there is a version conflict, perform version compatibility analysis by comparing the semantic version number, including splitting the version number into the major version number, the minor version number and the revision number, and comparing the numerical values ​​of each part in turn. If the major version numbers are the same, it is determined to be compatible; if the major version numbers are different, it is determined to be incompatible. For the versions determined to be compatible, perform an automatic merge operation to update the data of the new version to the local database. For the versions determined to be incompatible, perform a version upgrade, download and install the new version of the application, and perform data migration.

[0019] Exemplarily, the Kahn topological sorting algorithm is used to analyze the dependencies of each module of the mobile application platform, and a directed acyclic graph is constructed to represent the data dependencies between modules. A queue is initialized, and all nodes with an in-degree of 0 are added to the queue. The nodes in the queue are processed cyclically, and a node is taken out of the queue each time, added to the result list, and the in-degree of its adjacent nodes is reduced. If the in-degree of the adjacent node becomes 0, it is added to the queue. This process is repeated until the queue is empty, and the topological sorting result of the module is obtained. By traversing the graph structure, circular dependencies and potential conflict points are identified. According to the constructed dependency graph, data records of relevant modules are obtained from the local SQLite database and the server. For each record, the data version number and timestamp are compared to determine whether there is a dependency conflict and version conflict. If a conflict is detected, the conflicting data is marked and the conflict type is recorded and stored in the conflict data structure in the memory. For the marked dependency conflict data, the pre-set rule-based conflict resolution strategy is called. Conflicts are automatically handled according to the conflict type and predefined resolution strategy. Resolution strategies include: timestamp priority, field priority, specific value priority, etc. If the conflict cannot be resolved automatically, the conflict data will be added to the manual processing queue, and the conflict details and solution suggestions will be recorded. For version conflict issues, the semantic version number comparison algorithm is used to perform version compatibility analysis. The version number is divided into the major version number, the minor version number and the revision number, and the numerical values ​​of each part are compared in turn. If the major version numbers are the same, it is determined to be compatible; if the major version numbers are different, it is determined to be incompatible. For compatible versions, an automatic merge operation is performed to update the data of the newer version to the local database. For incompatible versions, the version upgrade process is triggered, the new version of the application is downloaded and installed, and then data migration is performed. During the merge and migration process, the transaction mechanism is used to ensure data consistency, and a rollback operation is performed if an exception occurs. The Apriori association rule mining algorithm is used to analyze the data dependency relationship of each module of the mobile application platform. The minimum support threshold is set to 0.1 and the minimum confidence threshold is set to 0.7. Frequent item sets are generated through multiple iterations, and finally a set of association rules between modules is obtained. A directed graph is constructed based on the association rules. The nodes represent modules, the edges represent dependencies, and the weights of the edges are determined by the confidence of the association rules. Use the Tarjan algorithm to detect strongly connected components in the graph, identify circular dependencies, and mark the module sets of circular dependencies as potential conflict points. Based on the constructed dependency graph, obtain the data records of the relevant modules from the local SQLite database and the remote MySQL server, and calculate the MD5 hash value for each record. By comparing the hash values ​​of the local and server data, determine whether there is data inconsistency. At the same time, compare the data version numbers, using the semantic version number format, including the major version number, minor version number, and revision number. If the local version number is less than the server version number, it is marked as a version conflict. The detected conflicting data is stored in the priority queue in the memory and sorted by conflict type and module priority.For dependent conflicting data, the preset conflict resolution method is called, and a rule-based three-way merge algorithm is used. First, the common ancestor version is determined, and then the differences between the local version, the server version, and the ancestor version are compared. For non-conflicting fields, the new data value is directly adopted; for conflicting fields, the priority is automatically selected according to the predefined field priority rules, and the priority is primary key > foreign key > timestamp > numeric type > character type from high to low. If it cannot be resolved automatically, the conflicting data will be added to the manual processing queue, and the cause of the conflict and related context information will be recorded at the same time. For version conflict issues, compatibility is determined by the semantic version number comparison algorithm. Compare the major version numbers, and if they are different, they are judged to be incompatible; if the major version numbers are the same, compare the minor version numbers, and if the local minor version number is less than the server minor version number, it is judged to be backward compatible; if the minor version numbers are also the same, compare the revision numbers and judge it to be fully compatible. For compatible versions, perform automatic merge operations, adopt field-level merge strategies, and retain the latest non-null values. For incompatible versions, trigger the version upgrade process, apply the new version data structure of the server to the local database, and perform data migration. After the merge is completed, the merge result is checked for data consistency, and the checksum of key fields is calculated to ensure that the local data is consistent with the server data.

[0020] Establish predefined resolution strategies, including merging or overwriting conflicting data based on business rules and user intent. At the same time, adopt corresponding data processing methods for different types of conflict scenarios, including using server-side version data as the basis, using local version data as the basis, and retaining two data versions to minimize data loss and user intervention.

[0021] A decision tree model is constructed based on preset business rules and user behavior logs. The decision tree model uses conflicting data types, modification time, and data importance as decision nodes. The optimal splitting attribute is selected through the information gain ratio, and a decision tree is recursively constructed. The decision tree is traversed to determine the conflict resolution strategy. A three-way merge algorithm based on timestamps is used to obtain conflicting data records from the local database and the server. According to the modification timestamps of the conflicting data records, the local version, the server version, and the common ancestor version are compared. If the server data timestamp is later than the local data, the server version is used as the basis for overwriting. If the local data timestamp is later than the server, the local version is retained. For sensitive data types of user personal information or key business data, a dual-version retention strategy is adopted. A conflict data table is created in the local database, which contains the original data field, version identifier, data source, and modification time metadata. The server and local data versions are stored in the conflict data table at the same time, and a unique identifier is added to each version. Verify the merged data through pre-defined data integrity verification rules; calculate the checksum of key fields and compare the hash values ​​before and after the merge; record the conflict information in the log table, which contains the conflict field, conflict type, original value and conflict value information; set the log retention policy, regularly clean up expired logs, and keep the log table size within a controllable range.

[0022] Exemplarily, according to the preset business rules and user behavior logs, a C4.5 decision tree model is constructed, and factors such as conflicting data types, modification time, and data importance are used as decision nodes. The optimal splitting attribute is selected by the information gain ratio, and the decision tree is recursively constructed. For each conflicting data record, the decision tree is traversed from the root node, and branches are selected according to the attribute value until the leaf node is reached to determine the most suitable conflict resolution strategy. A three-way merge algorithm based on timestamps is used to obtain conflicting data records from the local SQLite database and the server. For each field, the modification timestamps of the local version, the server version, and the common ancestor version are compared. If the server data timestamp is later than the local data, the server version is used as the basis for overwriting. If the local data timestamp is later than the server, the local version is retained. If the timestamps of the two are the same, the data content is compared and not marked as conflict at the same time. For sensitive data types such as user personal information or key business data, a dual version retention strategy is adopted. A conflict data table is created in the local SQLite database, and the table structure contains metadata such as the original data field, version identifier, data source, and modification time. Store the server-side and local data versions in the table at the same time, and add a unique identifier for each version. At the application level, implement the version switching function to allow switching between different versions. Verify the merged data through pre-defined data integrity verification rules. Use the SHA-256 hash algorithm to calculate the checksum of key fields and compare the hash values ​​before and after the merge. If data inconsistency or loss is found, the rollback mechanism is triggered. Use database transactions to restore the data to the state before the merge. At the same time, record the conflict information in the log table, including detailed information such as conflict fields, conflict types, original values, and conflict values. Set a log retention policy, regularly clean up expired logs, and keep the log table size within a controllable range. According to the preset business rules and user behavior analysis results, build a C4.5 decision tree model, and use factors such as conflict data type, modification time, and data importance as decision nodes. By analyzing historical operation records, extract user behavior features such as modification frequency and data access mode as model input. The decision tree uses the information gain ratio as the splitting criterion, sets the minimum number of leaf node samples to 10, and the maximum tree depth to 5 to prevent overfitting. For each conflicting data, traverse the decision tree, select branches according to the node conditions, and finally reach the leaf node to determine the most suitable conflict resolution strategy. Strategies include server priority, local priority, merge retention, dual version retention, etc. A three-way merge algorithm based on timestamp is used to obtain conflicting data records from the local SQLite database and the server. For each field, compare the last modified timestamps of the local version, server version, and common ancestor version. If the three are the same, keep them unchanged; if there is an update on the local or server side, use the updated version; if there are updates on both and they are different, mark them as conflicts.For conflicting fields, the policy output by the decision tree is used: if the server is given priority, the server data is used directly; if the local data is given priority, the local data is retained; if the data is retained for merging, the conflicting data is merged into a new value, such as string concatenation or numerical averaging. For specific types of sensitive data, such as user personal information or financial transaction records, a dual-version retention policy is adopted. Create a conflict data table in the local database and use JSON format to store the server and local data versions. Add metadata tags to each version, including information such as data source, modification time, and modification device. Set the version retention period to 30 days, and automatically clear it if it expires. Verify the merged data through pre-defined data integrity verification rules. The rules include field non-null check, data type consistency, and association integrity. If data inconsistency or loss is found, the incremental backup mechanism is triggered to record the difference between the original data and the merged data in the log file. Use the binary difference algorithm to calculate data changes and only store the changed parts to save storage space. Set the automatic rollback threshold. When the data change ratio exceeds 20%, it will automatically roll back to the state before the merge, and record the conflict information in a special conflict log table for subsequent manual analysis and processing.

[0023] S104. According to the result of the data merging, the version number of the local data is updated, and the merged data is associated with the local data version. At the same time, a predefined timestamp recording format standard is used to synchronously record the modification time of each piece of data.

[0024] Get the result of data merging, read the current version number stored as an integer value from the local database, including the major version number, minor version number, and revision number; determine the version number update method according to the type of merge operation. If it involves structural changes, the major version number is increased by 1, if a new function is added, the minor version number is increased by 1, and if only the error is fixed, the revision number is increased by 1; combine the updated version numbers into a string. Create a version association table, which contains data identifiers, version numbers, and associated time fields; add a version number field to the data table and set it as a foreign key to reference the version number field of the version association table. Add a modification time field to the data table, use the database built-in function to generate a time string that meets the standard, use the timestamp information as the attribute field of the data table, and bind it to the data record for storage. Create a trigger, which is used to update the timestamp field of the corresponding record when the data is inserted, updated, or deleted; in the trigger, use the database built-in time function to obtain the current timestamp and assign the timestamp to the modification time field. If a delete operation is performed, the record is copied to the history table before deletion; the timestamp of the copied record in the history table is updated, and the record in the original data table is deleted; a new associated record is inserted into the version association table, and the associated record contains the data identifier, the updated version number and the current timestamp.

[0025] Exemplarily, according to the result of data merging, a new local data version number is generated by using the semantic version number rule. The current version number is read from the local SQLite database, and the major version number, minor version number, and revision number are stored as integer values ​​respectively. The type of the merge operation is determined: if a structural change is involved, the major version number is increased by 1; if a new function is added, the minor version number is increased by 1; if only an error is fixed, the revision number is increased by 1. The updated version number is combined into a string in the format of "major version number.minor version number.revision number". Through the foreign key constraint mechanism in the relational database, an association table between the merged data and the local data version is established. A version association table is created in the local database, including the fields: data identifier, version number, and association time. A composite primary key is created for the data identifier and version number fields to ensure uniqueness. A version number field is added to the data table and set as a foreign key to reference the version number field of the version association table. After each data update operation, the version association table is updated synchronously and a new association record is inserted. The modification time of each piece of data is recorded in the ISO8601 standard format, accurate to milliseconds. A modification time field is added to the data table, and the type is set to TIMESTAMP. Use the database built-in function to generate a time string that complies with the ISO8601 standard in the format of "YYYY-MM-DDTHH:mm:ss.sssZ". Use the timestamp information as the attribute field of the data table and bind it to the specific data record for storage. Use the database trigger mechanism to automatically update the timestamp field of the corresponding record when the data is inserted, updated, or deleted. Create BEFOREINSERT, BEFOREUPDATE, and BEFOREDELETE triggers for each table involved in data modification. In the trigger, use the database built-in time function to obtain the current timestamp and assign it to the modification time field. For the deletion operation, copy the record to the history table before deleting it, and update the timestamp of the history record. According to the result of the data merge, use the semantic version number rule to update the local data version. The version number format is "major version number.minor version number.revision number", such as "2.4.1". When a major change occurs, the major version number increases by 1; when a new function is added, the minor version number increases by 1; when a problem is fixed, the revision number increases by 1. Use the regular expression "^(\d+).(\d+).(\d+)$" to parse the current version number and extract the values ​​of each part. Determine the part of the version number to be increased based on the nature of the merge operation. For example, upgrade from "1.2.3" to "1.3.0". Associate the new version number with the merged data record and store it in the version management table of the local SQLite database. Use the foreign key constraint mechanism in the relational database to establish an association table between the merged data and the local data version.Create a table named "data_version_mapping" with the following fields: id (primary key), data_id (foreign key, associated with the data table), version_id (foreign key, associated with the version table), association_time (association time). When inserting a new merged data record, create a corresponding association record in this table to achieve two-way tracking of data and version. Use the ISO8601 standard format to record the modification time of each data, accurate to milliseconds. The timestamp format is "YYYY-MM-DDTHH:mm:ss.sssZ", such as "2023-04-01T14:30:15.123Z". Use the timestamp information as an attribute field of the data table, named "last_modified_at", and set the type to TIMESTAMP. This field is automatically filled when data is inserted or updated. Use the database trigger mechanism to automatically update the timestamp field of the corresponding record when data is inserted, updated, or deleted. Create a trigger named "update_timestamp" and trigger it before INSERT, UPDATE, and DELETE operations on the data table. The trigger logic assigns the current system time to the "last_modified_at" field. The current system time is obtained using the database built-in function NOW(). At the same time, the trigger will also record this operation in the version management table, including the operation type, the number of records affected, and the operation time, for subsequent auditing and backtracking. Add a "version" field to the data table with an initial value of 1. Each time an update operation is performed, first check whether the current version number is consistent with the one before the update. If it is consistent, the update is allowed and the version number is increased by 1; if it is inconsistent, it means that the data has been modified by other processes. At this time, the current update operation is canceled and conflict information is returned. The application layer decides how to handle the conflict.

[0026] S105. After the data synchronization results and version update results are confirmed, the execution status and key information of the synchronization and update process are obtained by calling the synchronization result status acquisition interface and the version update result acquisition interface; a predefined data modification time capture method is used to record the modification time points of the data during the synchronization and update process to form a synchronization and update log.

[0027] Receive a request that includes a synchronization task identifier and a version update task identifier; obtain key information such as execution status, progress percentage, and completion time based on the identifier in the request; create a trigger that captures data modification events and records the operation type, data content before and after the modification, modification time, and operation user; use the task scheduler to create a scheduled task that reads new data modification records from the audit log table at preset intervals to obtain the timestamp, operation type, data table name, record primary key, and modification content; use the message queue to create a synchronization log topic and an update log topic, and the message queue receives serialized log objects, whose keys are a combination of the data table name and the record primary key; if the execution status returned by the synchronization and update interface is completed, generate a synchronization and update process report in real time, perform aggregate statistics based on the time window and operation type, and calculate the success rate, failure rate, and average processing time indicators.

[0028] Exemplarily, by calling the synchronization result status acquisition interface and the version update result acquisition interface, the interface receives the request sent by the HTTPPOST request method, and the request body contains the synchronization task identifier and the version update task identifier. According to the identifier in the request body, key information such as execution status, progress percentage, and completion time are obtained. Using the database trigger mechanism, AFTERINSERT, UPDATE, and DELETE triggers are created in the data table. The trigger captures data modification events and records the operation type, data content before and after modification, modification time, and operation user. Using the Quartz task scheduler, a scheduled task is created. The scheduled task reads the newly added data modification records from the audit log table every 1 minute to obtain the timestamp in ISO8601 format, the operation type of enumeration type, the data table name, the record primary key, and the modification content in JSON format. Using the Apache Kafka message queue, a synchronization log topic and an update log topic are created. The message queue receives log objects serialized in Avro format. The key of the log object is a combination of the data table name and the record primary key. If the execution status returned by the synchronization and update interface is completed, the Apache Flink stream processing engine is used to generate a detailed synchronization and update process report in real time, set up the connection between the Flink job and Kafka, define the Kafka data source in Flink to consume the messages in the Kafka topic, perform aggregate statistics according to the time window and operation type, and calculate indicators such as success rate, failure rate and average processing time. Call the synchronization result status acquisition interface and version update result acquisition interface through the RESTful API interface, use the HTTP POST method to send a request, and the request body contains the synchronization task identifier and version update task identifier. Set the request header Content-Type to application / json and receive the JSON format response returned by the server. Parse the response data and extract key information such as execution status, progress percentage, and completion time. Use the database trigger mechanism to create AFTERINSERT, UPDATE, and DELETE triggers in the data table. The trigger function captures data modification events and records the operation type, data content before and after modification, modification time, and operation user. Write this information into a special audit log table to ensure the traceability of data modification. Use the Quartz task scheduler to create a scheduled task to read the newly added data modification records from the audit log table every 1 minute. Use Java8's StreamAPI to process the log data and convert it into a structured log object, which contains the timestamp in ISO8601 format, the operation type of the enumeration type, the data table name, the record primary key, and the modification content in JSON format. Use the ApacheKafka message queue to create a synchronization log topic and an update log topic. Serialize the processed log object into Avro format and send it to the corresponding Kafka topic.Set the key of the message to a combination of the data table name and the record primary key to ensure the order of messages for the same record. According to the execution status returned by the synchronization and update interface, combined with the data modification log in the Kafka message queue, use the Apache Flink stream processing engine to generate detailed synchronization and update process reports in real time. Flink jobs consume messages from Kafka topics, aggregate statistics according to time windows and operation types, and calculate indicators such as success rate, failure rate, and average processing time. Store the aggregated results in the ClickHouse column database for efficient log analysis and query. At the same time, for abnormal situations, trigger the alarm mechanism, send email notifications through the SMTP protocol, or use the WebHook interface to push messages to instant messaging tools. Call the synchronization result status acquisition interface and version update result acquisition interface through HTTP POST requests, use JSON Web Token for identity authentication, and the request body contains the task identifier and timestamp. The interface returns JSON format data, including fields such as execution status (success, failure, in progress), completion percentage, and error information. Use the retry mechanism to handle network exceptions, with a maximum of 3 retries, each with an interval of 5 seconds. Aspect-Oriented Programming (AOP) technology is used to implement the data modification time capture mechanism. Aspects are added before and after the execution of the data access layer method to record the method name, parameters, return value and execution time. The ThreadLocal function is used to store the modification records of the current transaction, and the records are written to the log table in batches when the transaction is committed. The log table structure contains the following fields: id, operation type, table name, record id, value before modification, value after modification, modification time, and operation user. The Quartz scheduler is used to create a scheduled task, read the new records from the log table every 5 minutes, and use the StringBuilder function to splice and generate a structured log, which contains the ISO8601 format timestamp, operation type, data identifier and modification content. A detailed report is generated based on the execution status and log records returned by the interface. The report contains the overall status, success rate, list of failed items, abnormal conditions, etc. The MD5 algorithm is used to calculate the checksum of the report content to ensure integrity. The report is stored in a special collection of the MongoDB database, and the TTL index is set to automatically delete reports older than 30 days. An exception handling mechanism is implemented to capture errors during synchronization and update, record error stack information, and trigger alarms. Use Redis to implement distributed locks to prevent multiple nodes from processing the same task at the same time. Set the lock timeout to 10 minutes, and the lock will be automatically released after the timeout.

[0029] S106. Based on the synchronization and update log, the key information in the synchronization and update process, including the mobile application platform data modification content, modification time point, and version number, is extracted and recorded according to the predefined key information format; the extracted key information is persistently stored according to the preset storage method to form structured synchronization and update log data.

[0030] Get the data modification content, modification time and version number of the mobile application platform from the synchronization and update logs, and use the pre-defined regular expression pattern for matching and extraction. Create a concurrent hash table structure based on the extraction results, with the key as a unique identifier and the value as an object containing content, timestamp and version number. Convert the data in the hash table into a standard JSON object, which contains id, content, timestamp and version fields. If the accumulated JSON objects in the memory reach the preset threshold or time interval, the JSON object is written to the distributed file storage. Insert the structured synchronization and update log data into the special log table of the time series database storage engine.

[0031] Exemplarily, according to the predefined key information format, a regular expression is used to extract the mobile application platform data modification content, modification time point and version number from the synchronization and update log. The regular expression pattern is designed as (?P <content> .*?)|(?P <timestamp>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z)|(?P <version>\d+.\d+.\d+) to match the key information in the log. The extraction results are stored in the concurrent hash table structure ConcurrentHashMap in memory, with the key as a unique identifier and the value as an object containing content, timestamp, and version number. The extracted key information is structured in JSON format, and the data in the hash table is converted into a standard JSON object using the Jackson library. The JSON object contains the fields id (unique identifier), content (data modification content), timestamp (modification time in ISO8601 format), and version (semantic version number). To ensure data integrity, the SHA-256 hash value of the JSON object is calculated and added to the object. In batch processing, the JSON object in memory is written to the distributed file storage system HDFS every 5 minutes or when 1,000 records are accumulated. A storage structure partitioned by date is used, with the path format / logs / YYYY / MM / DD / HH / , and a new file is created every hour. The Parquet columnar storage format is used to support data compression and fast retrieval. Before writing to HDFS, the data is serialized using the Avro mode to improve storage efficiency. Use the InfluxDB storage engine, a time series database, to insert structured synchronization and update log data into a dedicated log table. Define measurement as sync_update_logs, tags as version and app_id, and fields as content and other metadata. Use timestamp as the primary index, and create secondary indexes on the tags version and app_id. Configure data retention policy, set a 30-day retention period, and automatically delete or archive expired data to cold storage. Use the continuous query function to aggregate data every hour, calculate statistical information such as modification frequency and version distribution, and store it in a separate measurement table for fast report generation and monitoring indicators. Use regular expressions to extract data from synchronization and update logs based on predefined key information formats. The format definition includes fields: operation type (add, modify, delete), data identifier, modification content, modification time, and version number. The regular expression pattern is "(\w+):(\d+):({.*?}):(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z):(v\d+.\d+.\d+)", which matches five fields respectively. Java's Pattern and Matcher classes are used to implement matching, and the matching results are stored in Concurrent HashMap, where the key is the data identifier and the value is the matched information. The Google Gson library is used to convert the extracted key information into JSON format.Create a LogEntry class with the five fields mentioned above, and use Gson's toJson method to convert the data in the HashMap into a JSON string. The JSON structure is {"operationType":"modify","dataId":"1234","content":{"field1":"newValue"},"timestamp":"2023-04-01T12:34:56Z","version":"v1.2.3"}. Use Apache Kafka to implement batch processing and persistence of data. Create a Kafka topic named "sync-update-log" with 6 partitions and a replication factor of 3. Use the Kafka Producer API to send JSON data to the topic, set the batch size to 100 messages or 1MB, and the compression type to GZIP. The message key is set to the data identifier to ensure that messages with the same data go to the same partition. Use the InfluxDB time series database to store structured log data. Create a database named "sync_update_logs" and set the retention policy to 30 days. Define measurement as "log_entries", tag as operation type and version number, field as modification content and data identifier. Use InfluxDB Java client to write data in batches, with the batch size set to 1000. Create a continuous query to aggregate data every hour and calculate the number of each operation type. Create an index on the version number field to optimize the performance of queries by version. Implement an error handling mechanism. When an exception occurs during extraction or storage, the error information is recorded in a dedicated error log topic. Use the SHA-256 algorithm to calculate the checksum of each log and store it in a separate field in InfluxDB for data integrity verification. Set up Kafka consumer groups to achieve parallel processing and improve the efficiency of processing large amounts of logs. Use InfluxDB's retention policy to automatically delete expired data and control storage space growth.

[0032] The present invention provides a mobile application platform fusion base development device, which mainly includes: a data acquisition and comparison module, which is used to acquire local data and server data of the mobile application platform, perform data comparison for data modification and addition in an offline environment, identify the difference between local data and server data, and simultaneously acquire the local version number and the server version number, and analyze the difference between data versions based on a preset version number naming specification; a data merging and dependency analysis module, which is used to merge the data modified locally on the mobile application platform with the server data for data with version differences, including analyzing the data dependency relationship between different modules of the mobile application platform based on a pre-built version dependency relationship graph, determining the order of data merging according to the dependency relationship, and dynamically selecting incremental synchronization, batch synchronization or scheduled synchronization mode according to the network connection status of the mobile device and the preset version update strategy, and adjusting the synchronization task scheduling strategy; a conflict resolution and version compatibility module, which is used to determine whether there is a data dependency conflict and version conflict based on the analysis results of the data dependency relationship between different modules, and if so, , respectively using the pre-set mobile application data conflict solution and version compatibility analysis method to merge data; the version update and timestamp recording module is used to update the version number of local data according to the result of data merging, and form associated information between the merged data and the local data version, and at the same time use the predefined timestamp recording format standard to synchronously record the modification time of each data; the synchronization status acquisition and log recording module is used to obtain the execution status and key information of the synchronization and update process by calling the synchronization result status acquisition interface and the version update result acquisition interface after the data synchronization result and the version update result are confirmed, and use the predefined data modification time capture method to record the modification time point of the data in the synchronization and update process to form a synchronization and update log; the key information extraction and storage module, based on the synchronization and update log, extracts and records the key information in the synchronization and update process, including the mobile application platform data modification content, modification time point, and version number, in accordance with the predefined key information format, and stores the extracted key information persistently according to the preset storage method to form structured synchronization and update log data. The present invention also provides an electronic device, comprising: one or more processors, and a memory; the processor and the memory are coupled; the memory is used to store computer program code, the computer program code includes computer instructions; when the processor executes the computer instructions, the electronic device executes the above-mentioned mobile application platform fusion base development method. The present invention also provides a computer-readable storage medium, the computer-readable storage medium stores computer instructions or programs, when the computer instructions or programs are run on a computer, the computer executes the above-mentioned mobile application platform fusion base development method.

[0033] The preferred embodiments of the present invention disclosed above are only used to help explain the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to only specific implementation methods. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.< / version> < / timestamp> < / content>

Claims

1. A method for developing a mobile application platform fusion base, characterized in that: The method comprises: Obtain local data and server-side data from the mobile application platform, perform data comparison for data modification and addition in an offline environment, identify the differences between local data and server-side data, and simultaneously obtain local version numbers and server-side version numbers, and analyze the differences between data versions based on a preset version number naming convention; merge the locally modified data on the mobile application platform with the server-side data for data with version differences, including analyzing the data dependency relationships between different modules of the mobile application platform based on a pre-built version dependency graph, determining the order of data merging based on the dependency relationships, and dynamically selecting incremental synchronization, batch synchronization, or scheduled synchronization methods based on the network connection status of the mobile device and a preset version update strategy, and adjusting the synchronization task scheduling strategy; based on the analysis results of data dependencies between different modules, determine whether there are data dependency conflicts and version conflicts, and if so, use a pre-set mobile application data conflict resolution method and version compatibility analysis method to merge data for dependency conflicts and version conflicts; update the version number of the local data based on the results of the data merging, associate the merged data with the local data version, and use a pre-defined The timestamp recording format standard synchronously records the modification time of each piece of data; after the data synchronization result and the version update result are confirmed, the execution status and key information of the synchronization and update process are obtained by calling the synchronization result status acquisition interface and the version update result acquisition interface, and the predefined data modification time capture method is adopted to record the modification time point of the data in the synchronization and update process to form a synchronization and update log; based on the synchronization and update log, the key information in the synchronization and update process, including the mobile application platform data modification content, modification time point, and version number, is extracted and recorded according to the predefined key information format, and the extracted key information is persistently stored according to the preset storage method to form structured synchronization and update log data; for the data with version differences, the data modified locally on the mobile application platform is merged with the server-side data, including analyzing the data dependency relationship between different modules of the mobile application platform based on the pre-built version dependency relationship graph, determining the order of data merging according to the dependency relationship, and dynamically selecting incremental synchronization, batch synchronization or scheduled synchronization mode according to the network connection status of the mobile device and the preset version update strategy, and adjusting the synchronization task scheduling strategy, including: According to the pre-established version dependency graph, obtain the version information of each module from the local database; Topologically sorting the dependency graph to obtain a dependency order between modules; Store the sorting results in a priority queue data structure; A three-way merge algorithm is used to merge data with different versions; Obtain the data records to be merged from the local database and the server respectively; Identify differences by comparing the MD5 hash values ​​of field values ​​and generate a merged result set; Get the network connection status information of the mobile device; Determine whether the current network type is WIFI or mobile data network; If it is determined to be a mobile data network, then timestamp-based incremental synchronization is triggered; If it is determined to be a WIFI network, a batch synchronization process based on data blocks is started; For mobile data networks, only synchronize data records that have been modified since the last synchronization time; For WIFI networks, the data to be synchronized is divided into fixed-size data blocks, and multi-threaded parallel transmission is used for data transmission; Dynamically adjust the execution strategy of synchronization tasks through the distributed task scheduler, including setting the priority, concurrency and retry times of synchronization tasks according to different network status and data volume; When the network is unstable, the retry interval is calculated, the location of the synchronized data block is recorded, and synchronization is continued from the breakpoint after the network is restored; the analysis results based on the data dependencies between different modules determine whether there are data dependency conflicts and version conflicts. If so, for the dependency conflicting data and version conflicts, the pre-set mobile application data conflict resolution method and version compatibility analysis method are used to merge the data, including: Constructing a directed acyclic graph, wherein the directed acyclic graph represents the data dependency relationship between modules of the mobile application platform; According to the directed acyclic graph, data records of relevant modules are obtained from the local database and the server; For the acquired data records, compare the data version number and timestamp to determine whether there is a dependency conflict and version conflict; If a dependency conflict is detected, the conflict is automatically handled based on the conflict type and predefined resolution strategy; If a version conflict is detected, version compatibility analysis is performed by comparing semantic version numbers, including splitting the version number into major version number, minor version number, and revision number, and comparing the values ​​of each part in turn; If the major version numbers are the same, they are considered compatible; If the major version numbers are different, they are considered incompatible; For versions that are determined to be compatible, an automatic merge operation is performed to update the new version data to the local database; For versions that are determined to be incompatible, upgrade the version, download and install the new version of the application, and perform data migration.

2. The method according to claim 1, characterized in that The method of obtaining local data and server data of the mobile application platform, performing data comparison for data modification and addition in an offline environment, identifying the difference between the local data and the server data, obtaining the local version number and the server version number, and analyzing the difference between the data versions based on a preset version number naming convention includes: Obtain data records in a local database and data records in a server, wherein the data records include a unique identifier, a timestamp, and a field value; Construct a JSON format data object array according to the data record, wherein the JSON format data object array contains complete data content; Compare the last modification time of the local data and the server data through the timestamp field in the JSON format data object array, and if the local data timestamp is later than the server data timestamp, mark the record of the local data as a to-be-synchronized item; The local data and the server data are analyzed, and the value of each field is compared by traversing the JSON format data object array. When inconsistency is found, the difference information is recorded to obtain a difference result set containing all difference items.

3. The method according to claim 1, characterized in that The analysis result of data dependency between different modules is used to determine whether there is a data dependency conflict and a version conflict. If so, a pre-set mobile application data conflict solution and version compatibility analysis method are used to merge data for dependency conflict data and version conflict, respectively. The method also includes: Establish predefined resolution strategies, including merging or overwriting conflicting data based on business rules and user intent. At the same time, adopt corresponding data processing methods for different types of conflict scenarios, including using server-side version data as the basis, using local version data as the basis, and retaining two data versions to minimize data loss and user intervention.

4. The method according to claim 3, characterized in that Establish predefined resolution strategies, including merging or overwriting conflicting data according to business rules and user intent, and adopt corresponding data processing methods for different types of conflict scenarios, including taking the server version data as the standard, taking the local version data as the standard, and retaining two data versions to minimize data loss and user intervention, including: A decision tree model is built based on preset business rules and user behavior logs. The decision tree model uses conflicting data types, modification time, and data importance as decision nodes. The optimal split attribute is selected through the information gain ratio, and a decision tree is recursively constructed. The decision tree is traversed to determine the conflict resolution strategy. A three-way merge algorithm based on timestamps is used to obtain conflicting data records from the local database and the server. According to the modification timestamps of the conflicting data records, the local version, the server version, and the common ancestor version are compared. If the server data timestamp is later than the local data, the server version is used as the basis for overwriting. If the local data timestamp is later than the server version, the local version is retained. For sensitive data types of key business data, a dual-version retention strategy is adopted; a conflict data table is created in the local database, which contains the original data field, version identifier, data source and modification time metadata; the server-side and local data versions are stored in the conflict data table at the same time, and a unique identifier is added to each version; the merged data is verified through pre-defined data integrity verification rules; the checksum of key fields is calculated, and the hash values ​​before and after the merge are compared; the conflict information is recorded in the log table, which contains the conflict field, conflict type, original value and conflict value information; a log retention policy is set, and expired logs are cleaned up regularly to keep the log table size within a controllable range.

5. The method according to claim 1, characterized in that The method of updating the version number of the local data according to the result of the data merging, forming association information between the merged data and the local data version, and synchronously recording the modification time of each piece of data using a predefined timestamp recording format standard includes: Get the result of data merging, and read the current version number stored as an integer value from the local database, including the major version number, minor version number, and revision number; Determine the version number update method based on the type of merge operation. If it involves structural changes, the major version number is increased by 1. If a new function is added, the minor version number is increased by 1. If only bugs are fixed, the revision number is increased by 1. Combine the updated version number into a string; Creating a version association table, wherein the version association table includes a data identifier, a version number, and an association time field; Add a version number field in the data table and set it as a foreign key to reference the version number field of the version association table; Add a modification time field to the data table, use the database built-in function to generate a time string that meets the standard, use the timestamp information as the attribute field of the data table, and bind it to the data record for storage; Create a trigger, wherein the trigger is used to update the timestamp field of the corresponding record when the data is inserted, updated or deleted; In the trigger, a database built-in time function is used to obtain a current timestamp, and the current timestamp is assigned to a modification time field; If a delete operation is performed, the record is copied to the history table before deletion; Update the timestamp of the copied record in the history table and delete the record in the original data table; A new association record is inserted into the version association table, wherein the association record includes a data identifier, an updated version number and a current timestamp.

6. The method according to claim 1, characterized in that After the data synchronization result and the version update result are confirmed, the execution status and key information of the synchronization and update process are obtained by calling the synchronization result status acquisition interface and the version update result acquisition interface, and the predefined data modification time capture method is used to record the modification time point of the data in the synchronization and update process to form a synchronization and update log, including: Receive a request, wherein the request includes a synchronization task identifier and a version update task identifier; Obtaining key information of execution status, progress percentage and completion time according to the identifier in the request; Create a trigger, which is used to capture data modification events and record the operation type, data content before and after modification, modification time and operation user; Use the task scheduler to create a scheduled task, which reads the newly added data modification records from the audit log table at preset intervals to obtain the timestamp, operation type, data table name, record primary key and modification content; Use a message queue to create a synchronization log topic and an update log topic, the message queue receives a serialized log object, and the key of the log object is a combination of a data table name and a record primary key; If the execution status returned by the synchronization and update interface is completed, a synchronization and update process report is generated in real time, and aggregate statistics are performed according to the time window and operation type to calculate the success rate, failure rate and average processing time indicators.

7. The method according to claim 1, characterized in that Based on the synchronization and update log, the key information in the synchronization and update process, including the mobile application platform data modification content, modification time point, and version number, is extracted and recorded according to a predefined key information format; The extracted key information is persistently stored according to the preset storage method to form structured synchronization and update log data, including: Obtain the mobile application platform data modification content, modification time point and version number from the synchronization and update logs, and use a predefined regular expression pattern for matching and extraction; Create a concurrent hash table structure based on the extraction results, with the key being a unique identifier and the value being an object containing the content, timestamp, and version number; The data in the hash table is converted into a standard JSON object, wherein the JSON object includes id, content, timestamp and version fields; If the accumulated JSON objects in the memory reach the preset threshold or time interval, the JSON objects are written to the distributed file storage; The structured synchronization and update log data is inserted into the dedicated log table of the time series database storage engine.

8. A mobile application platform fusion base development device, characterized in that: The method for developing a mobile application platform fusion base as described in any one of claims 1 to 7 is applied, and the device includes: a data acquisition and comparison module, which is used to acquire local data and server data of the mobile application platform, perform data comparison for data modification and addition in an offline environment, identify the difference between local data and server data, and simultaneously acquire the local version number and the server version number, and analyze the difference between data versions based on a preset version number naming specification; a data merging and dependency analysis module, which is used to merge the data modified locally on the mobile application platform with the server data for data with version differences, including analyzing the data dependency relationship between different modules of the mobile application platform based on a pre-built version dependency relationship graph, determining the order of data merging according to the dependency relationship, and dynamically selecting incremental synchronization, batch synchronization or scheduled synchronization mode according to the network connection status of the mobile device and the preset version update strategy, and adjusting the synchronization task scheduling strategy; a conflict resolution and version compatibility module, which is used to determine whether there is a data dependency conflict and version conflict based on the analysis results of the data dependency relationship between different modules, and if so, In case of data and version conflicts, a pre-set mobile application data conflict solution method and a version compatibility analysis method are used to merge data respectively; a version update and timestamp recording module is used to update the version number of local data according to the result of data merging, form associated information between the merged data and the local data version, and synchronously record the modification time of each data by using a predefined timestamp recording format standard; a synchronization status acquisition and log recording module is used to obtain the execution status and key information of the synchronization and update process by calling the synchronization result status acquisition interface and the version update result acquisition interface after the data synchronization result and the version update result are confirmed, and a pre-defined data modification time capture method is used to record the modification time point of the data in the synchronization and update process to form a synchronization and update log; a key information extraction and storage module is based on the synchronization and update log, and extracts and records the key information in the synchronization and update process, including the data modification content, modification time point, and version number of the mobile application platform, in accordance with the predefined key information format, and the extracted key information is persistently stored in a preset storage method to form structured synchronization and update log data.

Images