A mobile application framework rapid construction method and system

Abstract

The application relates to the technical field of mobile application development, and discloses a mobile application framework rapid construction method and system, which comprises the following steps: parsing state persistence codes of a to-be-upgraded basic component to generate a state mode difference report; identifying an upper-layer component set and extracting a state access mode based on a component dependency graph; analyzing state persistence codes and data processing logic of the upper-layer component to generate a state dependency propagation graph; performing state change propagation analysis to mark upper-layer component state fields that need to be synchronously migrated; matching a migration strategy to generate a state migration script and arranging an execution order in a reverse topological sequence; and executing the state migration script to complete component hot replacement and state data loading. The application solves the cascading state inconsistency problem caused by the unsynchronized migration of upper-layer component state copies when the state structure of a basic component is changed.

Description

Technical Field

[0001] This invention relates to the field of mobile application development technology, and more specifically, to a method and system for rapidly building mobile application frameworks. Background Technology

[0002] In enterprise-wide large-scale app build scenarios, hot replacement of runtime components in mobile application frameworks is a common requirement. When the base component to be upgraded is called by multiple upper-layer components, and the base component to be upgraded maintains persistent runtime states such as user session state, cached data, and configuration preferences, the upper-layer components may cache partial copies of the state of the base component to be upgraded, process data based on the state format of the base component to be upgraded, or hold local data derived from the state of the base component to be upgraded during runtime. The state data structure of the new version of the base component may change due to the addition, deletion, type change, and renaming of fields. The hot replacement process needs to simultaneously migrate the state data of the base component to be upgraded and the relevant upper-layer components.

[0003] Existing methods for hot-swapping stateful components only parse the state persistence code of the old and new versions of the component for state migration, without handling the state copies and dependency logic stored in the upper-level components. Existing dependency chain impact analysis methods focus on interface behavior changes (response latency, exception throwing patterns, callback timing), failing to cover the state inconsistency issues caused by changes in state data structure propagating to upper-level components through data flow.

[0004] Therefore, when the state structure of the underlying component to be upgraded changes, the state copy in the upper-level component retains the old format, and the derived data processing logic does not match the new structure, resulting in technical problems such as inconsistent cascaded states and data processing failures. Summary of the Invention

[0005] This invention provides a method and system for rapidly building mobile application frameworks, solving the technical problems of difficulty in migrating state data during component upgrades, failure of upper-layer component state synchronization, and difficulty in tracing state dependency propagation paths in related technologies.

[0006] This invention provides a method for rapidly building a mobile application framework, comprising:

[0007] The code analyzes the state persistence code of the new and old versions of the basic components to be upgraded, extracts the structure definition of the state data, compares the state structure definition of the new and old versions, identifies the change types of fields such as field addition, field deletion, field type change and field renaming, and generates a basic component state mode difference report.

[0008] Based on the component dependency graph, identify all sets of upper-level components that directly and indirectly depend on the basic component to be upgraded, and extract the access patterns of each upper-level component to the state of the basic component to be upgraded.

[0009] Analyze the state persistence code and data processing logic of each component in the upper-level component set, identify the state fields of upper-level components that have data dependencies on the state of the basic components to be upgraded, and generate a state dependency propagation graph.

[0010] Based on the state dependency propagation graph and the basic component state pattern difference report, calculate the propagation path and impact range of each state change on the upper-layer component, and mark the upper-layer component state fields that need to be migrated synchronously and their corresponding migration types.

[0011] The state transition rule base is queried to match the transition strategy corresponding to each transition type. State transition scripts are generated for the basic components to be upgraded and the affected upper-level components respectively. The execution order of the state transition scripts is arranged according to the reverse topological order of the component dependency graph.

[0012] The state migration script is executed sequentially to transform the old version state data. After the component hot-swap operation is performed, each component loads the migrated state data.

[0013] Furthermore, the state structure definition includes field names, data types, nesting relationships, and serialization formats; the extraction process of the state structure definition is as follows: parsing the state class definition code, extracting the member variables declared in the class as state fields, obtaining the type declarations of each member variable as field data types, identifying the object type fields in the member variables and recursively extracting their internal field structures to form nesting relationships, parsing the serialization library call statements in the serialization method implementation code, and identifying the serialization format type.

[0014] Furthermore, the comparison of the state structure definition identifies retained fields and newly added / deleted fields through field name matching, identifies type changes through type signature comparison, and identifies renamed fields through field semantic similarity calculation;

[0015] The semantic similarity calculation of the field adopts the cosine similarity algorithm. After converting the field name into word vectors, the similarity is calculated. When the similarity exceeds the preset threshold and there is no field with the same name in the new version, it is determined to be a renamed field.

[0016] The identification process of the upper-level component set is as follows: starting from the basic component to be upgraded, a breadth-first search algorithm is used to traverse along the reverse edges of the component dependency graph to collect all reachable upper-level component nodes; the access mode includes reading fields, writing fields, and subscribing to change events.

[0017] Furthermore, the process of extracting the access pattern is as follows: parse the code files of each upper-layer component, identify the code statements that call the status access interface of the basic component to be upgraded, determine the access operation type according to the interface type, record it as a read field access when the interface is a status acquisition method, record it as a write field access when the interface is a status setting method, record it as a subscribe to change event access when the interface is a status listener registration method, extract the field path identifier in the interface call parameters, and combine the access operation type with the field path identifier to form an access pattern record.

[0018] Furthermore, the upper-layer component state field includes a state replica field, a derived computation field, and a cache mapping field; the state dependency propagation graph is a directed acyclic graph structure, with nodes including component nodes and state field nodes, edges representing the dependency relationships of state data, and edge attributes labeling dependency types including replica dependency, derived dependency, and mapping dependency; the identification process of the upper-layer component state field is as follows: perform data flow analysis on the upper-layer component code, construct a control flow graph and a data dependency graph, mark the read operation of the state data of the basic component to be upgraded as the data source point, track the variable assignment, function call, and field write operations through the data flow, and when the data flow reaches the storage operation of the upper-layer component state field, mark the state field as a dependency field, and determine the dependency type according to the operation type in the data flow path.

[0019] Furthermore, the calculation process for the propagation path of state changes to upper-layer components includes: traversing all changes in the state pattern difference report of the basic components to obtain the change field identifier and change type; locating the node corresponding to the change field in the state dependency propagation graph, and performing a forward traversal using a depth-first search algorithm starting from this node to collect all affected upper-layer component state field nodes; and determining and marking the migration type of each upper-layer component state field based on the combination of change type and dependency type.

[0020] Furthermore, the migration types include field deletion migration, field addition migration, field type conversion migration, and field remapping migration; the rules for determining the migration type are as follows: when the change type is field deletion and the dependency type is replica dependency or mapping dependency, the migration type is field deletion migration; when the change type is field addition and the dependency type is replica dependency, the migration type is field addition migration; when the change type is field type change and the dependency type is replica dependency or derived dependency, the migration type is field type conversion migration; when the change type is field renaming and the dependency type is replica dependency or mapping dependency, the migration type is field remapping migration.

[0021] Furthermore, the process of generating the state transition script is as follows: Based on the transition type, the corresponding transition strategy template is retrieved from the state transition rule base. The transition strategy template includes the access path expression for the source state data, the operation sequence of the data transformation logic, and the write path expression for the target state data. The path expression placeholders in the transition strategy template are replaced with actual field identifiers, and the type placeholders in the transition strategy template are replaced with actual data types. The resulting code is then assembled into an executable state transition script. The reverse topology order refers to the order in which the dependent components are arranged before the dependent components.

[0022] Furthermore, the state transition script is executed in a sandbox environment, and the transformation result is stored in a temporary state cache. After the component loads the migrated state data, a cascaded state consistency verification program is run to verify the matching of state data formats and the integrity of data values ​​between the base component to be upgraded and each upper-level component. If the cascaded state consistency verification program passes the verification, the temporary state cache is cleared and the replacement is confirmed to be complete. If the verification fails, the component version is rolled back, the original state data is restored, and a state propagation conflict report and repair suggestions are output.

[0023] This invention provides a rapid mobile application framework building system, comprising:

[0024] The State Pattern Difference Analysis Module is used to parse the state persistence code of the old and new versions of the basic component to be upgraded, extract the structure definition of the state data and compare it, and generate a state pattern difference report of the basic component.

[0025] The upper-level component identification module is used to identify all upper-level components that directly and indirectly depend on the basic component to be upgraded based on the component dependency graph, and to extract the access patterns of each upper-level component to the state of the basic component to be upgraded.

[0026] The state dependency propagation graph generation module is used to analyze the state persistence code and data processing logic of each component in the upper-level component set, identify the state fields of upper-level components that have data dependencies on the state of the basic components to be upgraded, and generate a state dependency propagation graph.

[0027] The State Change Propagation Analysis module is used to calculate the propagation path and impact range of each state change on the upper-layer components based on the state dependency propagation graph and the difference report of the state mode of the basic components, and to mark the state fields of the upper-layer components that need to be migrated synchronously and their corresponding migration types.

[0028] The state transition script generation module is used to query the state transition rule base to match the migration strategy corresponding to each migration type, generate state transition scripts for the basic components to be upgraded and the affected upper-level components respectively, and arrange the execution order of the state transition scripts according to the reverse topological order of the component dependency graph.

[0029] The state migration execution module is used to execute state migration scripts in sequence to transform the old version state data, and after performing component hot replacement operations, each component loads the migrated state data.

[0030] The beneficial effects of this invention are as follows:

[0031] This invention explicitly models the state data dependencies between basic components and upper-level components by generating a state dependency propagation graph, performs state change propagation analysis to calculate the propagation path and impact range of state changes on upper-level components, and executes state migration scripts in reverse topological order to ensure the correctness of the migration order. It solves the technical problem of cascading state inconsistency and data processing failure caused by the asynchronous migration of upper-level component state copies when the state structure of basic components changes. It achieves the technical effects of expanding the state migration scope from a single basic component to the entire state dependency chain, accurately marking the state fields of upper-level components that need to be migrated synchronously, and avoiding incorrect state references during the migration process. Attached Figure Description

[0032] Figure 1 This is a flowchart of the mobile application framework rapid construction method of the present invention;

[0033] Figure 2 This is a component dependency relationship and access interface call frequency analysis diagram of the present invention;

[0034] Figure 3 This is a frequency distribution diagram of upper-layer component state access operations in this invention;

[0035] Figure 4 This is the node hierarchy distribution diagram of the state dependency propagation graph of the present invention;

[0036] Figure 5 This is a statistical chart of the status field change types and affected components of the present invention;

[0037] Figure 6 This is a diagram showing the execution timing and data processing volume distribution of the migration script of this invention;

[0038] Figure 7 This is an analysis chart of the pass rate of the cascaded state consistency verification of the present invention;

[0039] Figure 8 This is the field semantic similarity calculation and migration type distribution diagram of the present invention. Detailed Implementation

[0040] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0041] At least one embodiment of the present invention discloses a method for rapidly building a mobile application framework, such as... Figure 1 As shown, it includes the following steps:

[0042] Step 1: Parse the state persistence code of the basic component to be upgraded and generate a report on the differences in the state patterns of the basic component.

[0043] Obtain the state persistence code of the old and new versions of the basic component to be upgraded, extract the structure definition of the state data including field names, data types, nesting relationships and serialization formats, compare the state structure definitions of the old and new versions, identify change types such as field addition, field deletion, field type change and field renaming, and generate a basic component state mode difference report.

[0044] It should be noted that the aforementioned state persistence code refers to the code snippets in the component responsible for serializing and storing runtime state data and deserializing and restoring it, including state class definitions, serialization method implementations, and persistence configuration declarations.

[0045] Furthermore, the extraction process of the above state structure definition is as follows: parse the state class definition code, extract the member variables declared in the class as state fields, obtain the type declarations of each member variable as field data types, identify the object type fields in the member variables and recursively extract their internal field structures to form nested relationships, parse the serialization library call statements in the serialization method implementation code, and identify the serialization format type, including JSON format, XML format, or binary format.

[0046] It should be noted that the above state structure definition comparison identifies retained fields and newly added / deleted fields through field name matching, identifies type changes through type signature comparison, and identifies renamed fields through field semantic similarity calculation. The field semantic similarity calculation uses the cosine similarity algorithm, which converts the field name into word vectors and then calculates the similarity. When the similarity exceeds a preset threshold and there is no field with the same name in the new version, it is determined to be a renamed field.

[0047] Furthermore, the preset threshold value ranges from 0.7 to 0.9, and the specific value is determined according to the strictness of the field naming convention. The stricter the field naming convention, the higher the preset threshold value should be.

[0048] Furthermore, the aforementioned basic component state mode difference report records detailed information about each change, including change type identifier, old version name and data type of the affected fields, new version name and data type of the affected fields, and the nested hierarchy path of the change's impact.

[0049] Step 2: Identify the set of upper-level components based on the component dependency graph, and extract the access patterns of each upper-level component to the state of the basic components to be upgraded.

[0050] The component dependency graph in the framework metadata is parsed. Starting from the basic component to be upgraded, the dependency chain is traversed to identify all the upper-level components that directly and indirectly depend on the basic component to be upgraded. The access patterns of each upper-level component to the state of the basic component to be upgraded are extracted, including reading fields, writing fields, and subscribing to change events.

[0051] It should be noted that the above component dependency graph is part of the framework metadata, which records the calling dependencies between components. It is represented by a directed graph structure, where nodes are component identifiers and edges are dependencies.

[0052] It should be noted that the above dependency chain traversal adopts the breadth-first search algorithm. The input is the basic component node to be upgraded and the component dependency relationship graph, and the output is the set of upper-level component nodes. Starting from the basic component node to be upgraded, the algorithm traverses along the reverse edges of the dependency relationship to collect all reachable upper-level component nodes.

[0053] Furthermore, the process of extracting the above access patterns is as follows: parse the code files of each upper-layer component, identify the code statements that call the state access interface of the basic component to be upgraded, determine the access operation type according to the interface type, record it as a read field access when the interface is a state acquisition method, record it as a write field access when the interface is a state setting method, record it as a subscribe to change event access when the interface is a state listener registration method, extract the field path identifier in the interface call parameters, and combine the access operation type with the field path identifier to form an access pattern record.

[0054] Step 3: Analyze the state persistence code and data processing logic of the upper-level component collection to generate a state dependency propagation graph.

[0055] Analyze the state persistence code and data processing logic of each component in the upper-level component set, identify the upper-level component state fields that have data dependencies on the state of the basic component to be upgraded, including state copy fields, derived compute fields, and cache mapping fields, and generate a state dependency propagation graph.

[0056] It should be noted that the aforementioned "state copy field" refers to a field in the upper-level component that directly copies and stores the state data of the base component to be upgraded. The aforementioned "derived computed field" refers to a field stored after calculation and transformation based on the state data of the base component to be upgraded. The aforementioned "cached mapping field" refers to a cache structure field that uses the state data of the base component to be upgraded as its key or value.

[0057] It should be noted that the state dependency propagation graph described above is a directed acyclic graph structure, with nodes divided into two categories: component nodes and state field nodes. Edges represent the dependencies between state data, pointing from the state field of the dependent to the state field of the dependent. Edge attributes indicate the dependency type, including replica dependency, derived dependency, and mapping dependency.

[0058] In this embodiment, to accurately identify state dependency fields in upper-layer components, data flow analysis is performed on the upper-layer component code to trace the propagation path of the state data of the basic component to be upgraded from the acquisition point to the storage point, thereby identifying directly dependent and indirectly derived state fields. The data flow analysis employs static program analysis techniques to construct a control flow graph and data dependency graph of the upper-layer component code. The read operation of the state data of the basic component to be upgraded is marked as the data source point. The variable assignment, function call, and field write operations traversed by the data flow are tracked. When the data flow reaches the storage operation of the upper-layer component's state field, the upper-layer component's state field is marked as a dependent field, and the dependency type is determined based on the operation type in the data flow path: if the data is stored directly without transformation, it is a replica dependency; if the data is stored after computation and transformation, it is a derived dependency; and if the data is stored as a key-value pair, it is a mapping dependency.

[0059] Furthermore, the control flow graph described above is a fundamental data structure in program analysis. It uses basic code blocks as nodes and execution flow relationships as edges to represent the program's execution path. The data dependency graph records the definition and usage relationships between variables. When the value of one variable depends on another, a directed edge is established between the corresponding nodes of the two variables.

[0060] Furthermore, the rules for determining the operation type in the above data flow path are as follows: check the data dependency graph path between the data source point variable and the storage point variable. If there are no arithmetic operations, function calls, or type conversion operations on the data dependency graph path, it is determined to be direct storage without conversion. If there are arithmetic operations or function calls on the data dependency graph path, it is determined to be storage after calculation and conversion. If the type of the storage point variable is a mapping container type and the data source point variable is used as a parameter of the mapping operation, it is determined to be key-value pair storage.

[0061] Step 4: Based on the state dependency propagation graph and the difference report of the state pattern of the basic components, perform state change propagation analysis and mark the state fields of the upper-level components that need to be migrated synchronously.

[0062] Based on the state dependency propagation graph and the basic component state pattern difference report, calculate the propagation path and impact range of each state change on the upper-layer components, and mark the upper-layer component state fields that need to be migrated synchronously and their corresponding migration types.

[0063] It should be noted that the execution process of the above state change propagation analysis includes the following sub-steps:

[0064] Step 401: Iterate through all changes in the basic component state mode difference report and obtain the change field identifier and change type;

[0065] Step 402: Locate the node corresponding to the changed field in the state dependency propagation graph, and perform a forward traversal starting from the node corresponding to the changed field to collect all affected upper-level component state field nodes;

[0066] Step 403: Determine and mark the migration type of the state field of each upper-level component based on the combination of change type and dependency type.

[0067] It should be noted that the above migration types include field deletion migration, field addition migration, field type conversion migration, and field remapping migration, which correspond to the migration operations that the upper-level component's status fields need to perform when the basic component to be upgraded deletes, adds, changes type, or renames its fields.

[0068] It should be noted that the rules for determining the migration type in step 403 are as follows: when the change type is field deletion and the dependency type is replica dependency or mapping dependency, the migration type is field deletion migration; when the change type is field addition and the dependency type is replica dependency, the migration type is field addition migration; when the change type is field type change and the dependency type is replica dependency or derived dependency, the migration type is field type conversion migration; when the change type is field renaming and the dependency type is replica dependency or mapping dependency, the migration type is field remapping migration.

[0069] Furthermore, the aforementioned forward traversal employs a depth-first search algorithm, starting from the changed field node and recursively visiting successor nodes along the edges of the state dependency propagation graph, collecting all upper-level component state field nodes on the data dependency graph path until a leaf node with no successor node is reached.

[0070] Step 5: Match the migration strategy based on the migration type, generate the state migration script, and arrange the execution order in reverse topological order.

[0071] The system queries a predefined state transition rule library, matches the transition strategy corresponding to each transition type, generates state transition scripts for the base component to be upgraded and the affected upper-level components, and arranges the execution order of the state transition scripts according to the reverse topological order of the component dependency graph.

[0072] It should be noted that the aforementioned state transition rule base stores migration strategy templates corresponding to various migration types. The migration strategy templates define the reading method, transformation logic, and writing method of state data.

[0073] Furthermore, the migration strategy template mentioned above includes the following: the access path expression for the source state data, used to locate the fields that need to be migrated in the old version state data; the operation sequence of the data conversion logic, which defines the conversion steps such as type conversion, field mapping, or default value filling; and the write path expression for the target state data, used to determine the storage location of the migrated data in the new version state structure.

[0074] Furthermore, the process of generating the state transition script is as follows: based on the transition type, the corresponding transition strategy template is retrieved from the state transition rule base; the path expression placeholders in the transition strategy template are replaced with actual field identifiers; the type placeholders in the transition strategy template are replaced with actual data types; and the script is assembled into executable state transition script code.

[0075] It should be noted that the above reverse topological order refers to the order in which the dependent components are arranged before the dependent components in the component dependency graph. This ensures that the state transition of the base component to be upgraded is performed before the state transition of the upper-level component, thus avoiding the upper-level component referencing the state of the base component to be upgraded that has not yet been migrated during the migration process.

[0076] Furthermore, the above reverse topological order generation process is as follows: execute the topological sorting algorithm on the component dependency graph, output the topological sorting algorithm result in reverse order, and obtain the execution order sequence of the dependent components.

[0077] In this embodiment, to handle situations where no matching strategy exists in the state transition rule base, when a migration type is detected as not matching a predefined strategy, candidate migration strategies are generated based on the semantic features of the migration type and historical migration records, and marked as pending manual confirmation. This ensures the integrity of the migration process while reserving an interface for manual intervention. The process of generating candidate migration strategies is as follows: historical migration cases with semantic similarity to the current migration type are retrieved from historical migration records; the migration strategies used in the historical migration cases are extracted; the field identifiers and data types in the extracted migration strategies are replaced with the corresponding values ​​for the current migration scenario; candidate migration strategies are generated and a confidence score is attached. The confidence score is calculated based on the semantic similarity between the historical migration cases and the current scenario, and the semantic similarity is calculated using the cosine similarity algorithm.

[0078] Furthermore, the confidence score ranges from 0 to 1. When the confidence score is below 0.6, the system automatically triggers a manual confirmation process, requiring manual review of the correctness of the candidate migration strategy.

[0079] Step 6: Execute the state transition script to complete component hot replacement and state data loading.

[0080] The state migration script is executed sequentially to transform the old version of the state data. The transformation results are stored in a temporary state cache. After the component hot replacement operation is performed, each component loads the migrated state data from the temporary state cache.

[0081] It should be noted that the aforementioned temporary state cache is a state storage area isolated from the production environment, used to temporarily store the migrated state data until the component hot replacement is completed and passes verification.

[0082] In this embodiment of the application, in order to reduce the risk of state loss during the hot replacement of components, the current state data of each component is backed up to the state snapshot storage area before the state migration script is executed, so that the state before the migration can be restored in the event of migration failure.

[0083] In this embodiment, to verify the correctness of the migrated state data and avoid impacting the production environment, the state transition script is executed in a sandbox environment. The sandbox environment simulates the component runtime configuration of the production environment but is isolated from the production environment data, thereby enabling the verification of the migration results without affecting the production environment.

[0084] Furthermore, the process of building the sandbox environment described above is as follows: copy the component configuration files and dependency metadata of the production environment, create an independent state storage space and copy the current state data snapshot of the production environment, load the new version of the basic components to be upgraded and the existing version of the upper-layer components, and configure network isolation rules to prevent the sandbox environment from accessing the production database and external service interfaces.

[0085] In this embodiment, to ensure the consistency of component state data after hot component replacement, after the component loads the migrated state data, a cascaded state consistency verification program is run to verify the matching of state data formats and the integrity of data values ​​between the base component to be upgraded and each upper-layer component. If the cascaded state consistency verification program passes the verification, the temporary state cache is cleared and the replacement is confirmed to be complete. If the cascaded state consistency verification program fails the verification, the component version is rolled back, the original state data is restored, and a state propagation conflict report and repair suggestions are output.

[0086] It should be noted that the above-mentioned cascading state consistency verification procedure verifies the following: whether the data type of the state field of each upper-level component matches the data type of the corresponding field of the base component to be upgraded; whether the value of the state copy field of each upper-level component is consistent with the value of the corresponding field of the base component to be upgraded; and whether the value of the derived calculated field of each upper-level component can be correctly calculated from the current state of the base component to be upgraded.

[0087] Furthermore, the aforementioned state data format matching verification is implemented through a type system compatibility check, verifying whether the data type of the upper-level component's state field can accept the data type assignment of the corresponding field in the underlying component to be upgraded. The aforementioned data value integrity verification is implemented through field NOT NULL constraint checks and numerical range constraint checks, verifying whether the migrated state data meets the state constraints of each component.

[0088] Furthermore, the aforementioned state propagation conflict report records the specific location and reason for the verification failure, including the identifier of the upper-level component where the conflict occurred, the path of the conflict state field, the difference between the expected data type and the actual data type, and the suggested type of repair operation.

[0089] This implementation generates a state dependency propagation graph, explicitly modeling the state data dependencies between the base component to be upgraded and the upper-level components. This expands the scope of state migration from a single base component to be upgraded to the entire state dependency chain. Therefore, changes in the state structure of the base component to be upgraded can be traced to the state copy field and derived computed field of the upper-level component, solving the problem of cascading state inconsistency caused by existing methods that only migrate the internal state of the base component to be upgraded while omitting the state copy of the upper-level component.

[0090] This implementation performs state change propagation analysis, calculating the propagation path and impact range of each state change on upper-layer components based on the state dependency propagation graph. This accurately identifies the state fields of upper-layer components that require synchronous migration. Therefore, it solves the problem of existing dependency chain impact analysis methods that only focus on interface behavior changes while ignoring the propagation of state data structure changes to upper-layer components.

[0091] This implementation executes the state transition script in reverse topological order of the component dependency graph, ensuring that the state transition of the underlying component to be upgraded is completed before processing the state of dependent components. Therefore, it avoids state reference errors caused by upper-level components referencing the state of the underlying component to be upgraded that has not yet been migrated during the migration process.

[0092] A large retail group is undergoing digital transformation using its enterprise mobile application platform. The platform hosts 127 mobile applications from different business lines, including modules for store management, inventory management, membership services, and promotional activities. The user authentication component (AuthenticationService) is a core foundational component, depended upon by 89 upper-layer business components. This authentication component maintains runtime data such as user login session state, permission caching, and device fingerprints.

[0093] On January 21, 2026, the security team discovered a security vulnerability in the session state structure of the existing authentication components. It was necessary to upgrade the session state from a single token mode to a dual token mode (AccessToken + RefreshToken), while adding a device risk score field and removing the obsolete single sign-on identifier field. The upper-layer order processing component (OrderService) caches copies of user tokens for rapid authentication, the membership points component (LoyaltyService) calculates user activity based on session state, and the promotion push component (PromotionService) maintains a push mapping table with user tokens as the key. The platform needed to complete component hot-swap and state migration without interrupting 24 / 7 online service.

[0094] An example of implementing core step 1.

[0095] In step 1 of the specific implementation, the system obtains the state persistence code of the AuthenticationService component v2.3.5 (old version) and v3.0.0 (new version), extracts the state data structure definition and performs comparative analysis.

[0096] Table 1 Input data for step 1:

[0097]

[0098] Table 2 Output data for step 1:

[0099]

[0100] The semantic similarity calculation process for fields is as follows: The field names "token" and "accessToken" are converted into word vectors, and the cosine similarity is calculated.

[0101]

[0102] Because the similarity of 0.83 exceeds the preset threshold of 0.75 and the "token" field does not exist in the new version, it is determined to be a renaming operation.

[0103] Figure 5 It shows the number of components affected under different change types.

[0104] An example of implementing core step 2.

[0105] Corresponding to step 2 in the specific implementation, the system identifies the upper-level components that depend on AuthenticationService based on the component dependency graph and extracts the access patterns of each component to the authentication status.

[0106] Table 3 Input data for step 2 (dependent component identification):

[0107]

[0108] Table 4 Output data of step 2 (access pattern extraction):

[0109]

[0110] The system traverses the dependency chain using a breadth-first search, identifies four directly or indirectly dependent upper-level components starting from AuthenticationService, and parses their code to identify six access pattern records.

[0111] Figure 2 It shows the component dependencies and the distribution of API call counts.

[0112] Figure 3 This shows the frequency distribution of access operations for each access type of the upper-level component.

[0113] An example of implementing core step 3.

[0114] Corresponding to step 3 in the specific implementation, the system analyzes the state persistence code and data processing logic of the upper-layer components, and identifies state-dependent fields through data flow analysis.

[0115] Table 5 Input data for step 3 (data flow analysis):

[0116]

[0117] Table 6 Output data of step 3 (state dependency propagation graph):

[0118]

[0119] The system identified three dependent fields in three upper-level components through data flow analysis. The constructed state dependency propagation graph contains eight nodes, with the propagation path reaching a maximum of two layers.

[0120] Figure 4 The distribution of propagation path lengths for each dependent node is shown.

[0121] An example of implementing core step 4.

[0122] Corresponding to step 4 in the specific implementation, the system performs state change propagation analysis based on the state dependency propagation graph and the basic component state pattern difference report.

[0123] Table 7 Output data from step 4 (affected field markers):

[0124]

[0125] Starting with the change CHG004 (token renamed to accessToken), the system performs a depth-first search in the state dependency propagation graph, identifying three state fields of three upper-level components that are affected. Based on the combination of dependency type and change type, the migration type is determined as follows: OrderService's cachedToken field has a replica dependency and the source field is renamed, so the migration type is field remapping migration; LoyaltyService's activityScore field has a derived dependency and the computed input field is renamed, so the migration type is field type conversion migration; PromotionService's tokenToPushId field has a mapping dependency and the mapping key field is renamed, so the migration type is field remapping migration.

[0126] Figure 8 It demonstrates the calculation of field semantic similarity and the distribution of migration types.

[0127] An example of implementing core step 5.

[0128] In step 5 of the specific implementation, the system matches the migration strategy and generates a state transition script, which is then executed in reverse topological order.

[0129] The system performs a topological sort on the component dependency graph to obtain a forward sequence: [AuthenticationService, OrderService, LoyaltyService, PromotionService]. Reversing this order yields the execution sequence: [AuthenticationService, OrderService, LoyaltyService, PromotionService]. The state transition scripts generated for each component are as follows:

[0130] AuthenticationService state transition script (script number) ):

[0131] Read the old state path: / SessionState / token, the transformation logic is: rename the field mapping (token → accessToken), and write to the new state path: / SessionState / accessToken.

[0132] Read old state path: / SessionState / ssoFlag, transformation logic: field deletion operation, write to new state path: none.

[0133] The new field path is / SessionState / refreshToken. The transformation logic is as follows: generate a new token (call TokenGenerator.generateRefresh()) and write it to the new state path: / SessionState / refreshToken.

[0134] Add a new field path: / SessionState / riskScore, transformation logic: fill with default value (initial value 0.5), write to the new state path: / SessionState / riskScore

[0135] OrderService State Transition Script (Script Number) ):

[0136] Read the old state path: / OrderContext / cachedToken. Transformation logic: Read the value of / SessionState / accessToken from the new state of AuthenticationService, replace it, and write it to the new state path: / OrderContext / cachedToken.

[0137] LoyaltyService State Transition Script (Script Number) ):

[0138] Read the old state path: / UserActivity / activityScore. The conversion logic is as follows: Read / SessionState / loginTime from the new state of AuthenticationService, recalculate the activity score (current time minus login time converted to hours), and write it to the new state path: / UserActivity / activityScore.

[0139] PromotionService State Transition Script (Script Number) ):

[0140] Read the old state path: / PushMapping / tokenToPushId. Transformation logic: Iterate through all keys in the Map, replace the old token key with the accessToken value read from the new state of AuthenticationService, and write it to the new state path: / PushMapping / tokenToPushId.

[0141] An example of implementing core step 6.

[0142] Corresponding to step 6 in the specific implementation, the system executes the state transition script in the sandbox environment and performs cascading state consistency verification.

[0143] The system first backs up the production environment's status data to the status snapshot storage area (snapshot number). Then, in the sandbox environment, execute the four migration scripts in sequence.

[0144] Table 8 shows the execution results of the migration script in step 6:

[0145]

[0146] Table 9 shows the consistency verification results of step 6:

[0147]

[0148] Example of derived data integrity verification: User The SessionState.loginTime is 2026-01-21 10:15:32, and the current time is 2026-01-21 14:33:45. Calculate the active duration:

[0149]

[0150] The stored value of UserActivity.activityScore is 4 (rounded down), which is consistent with the recalculated result.

[0151] The verification program confirmed the migration was successful after checking all items in 500 samples. The system then performed a hot replacement operation, upgrading AuthenticationService from v2.3.5 to v3.0.0. Each upper-layer component loaded the migrated state data from the temporary state cache, cleared the temporary cache, and deleted the state snapshot, completing the entire hot replacement process.

[0152] Figure 6 The execution sequence of the migration script and the distribution of data processing volume are shown.

[0153] Figure 7 The pass rate of cascaded state consistency verification is shown.

[0154] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for rapidly building a mobile application framework, characterized in that, Includes the following steps: The code analyzes the state persistence code of the new and old versions of the basic components to be upgraded, extracts the structure definition of the state data, compares the state structure definition of the new and old versions, identifies the change types of fields such as field addition, field deletion, field type change and field renaming, and generates a basic component state mode difference report. Based on the component dependency graph, identify all sets of upper-level components that directly and indirectly depend on the basic component to be upgraded, and extract the access patterns of each upper-level component to the state of the basic component to be upgraded. Analyze the state persistence code and data processing logic of each component in the upper-level component set, identify the state fields of upper-level components that have data dependencies on the state of the basic components to be upgraded, and generate a state dependency propagation graph. The upper-layer component state fields include state replica fields, derived compute fields, and cache mapping fields; the state dependency propagation graph is a directed acyclic graph structure, with nodes including component nodes and state field nodes, edges representing the dependency relationships of state data, and edge attributes labeling dependency types including replica dependency, derived dependency, and mapping dependency; the identification process of the upper-layer component state fields is as follows: perform data flow analysis on the upper-layer component code, construct a control flow graph and a data dependency graph, mark the read operation of the state data of the basic component to be upgraded as the data source point, track the variable assignment, function call, and field write operations through the data flow, and when the data flow reaches the storage operation of the upper-layer component state field, mark the state field as a dependency field, and determine the dependency type according to the operation type in the data flow path; Data flow analysis uses static program analysis techniques to determine dependency types based on the operation types in the data flow path: if data is stored directly without transformation, it is a replica dependency; if data is stored after computation and transformation, it is a derived dependency; if data is stored as key-value pairs, it is a mapping dependency. Based on the state dependency propagation graph and the basic component state pattern difference report, calculate the propagation path and impact range of each state change on the upper-layer component, and mark the upper-layer component state fields that need to be migrated synchronously and their corresponding migration types. The state transition rule base is queried to match the transition strategy corresponding to each transition type. State transition scripts are generated for the basic components to be upgraded and the affected upper-level components respectively. The execution order of the state transition scripts is arranged according to the reverse topological order of the component dependency graph. The state migration script is executed sequentially to transform the old version state data. After the component hot-swap operation is performed, each component loads the migrated state data.

2. The method for rapidly constructing a mobile application framework according to claim 1, characterized in that, The state structure definition includes field names, data types, nesting relationships, and serialization formats. The extraction process of the state structure definition is as follows: parse the state class definition code, extract the member variables declared in the class as state fields, obtain the type declarations of each member variable as field data types, identify the object type fields in the member variables and recursively extract their internal field structures to form nesting relationships, parse the serialization library call statements in the serialization method implementation code, and identify the serialization format type.

3. The method for rapidly constructing a mobile application framework according to claim 1, characterized in that, The comparison of the state structure definition identifies retained fields and newly added / deleted fields by matching field names, identifies type changes by comparing type signatures, and identifies renamed fields by calculating field semantic similarity. The semantic similarity calculation of the field adopts the cosine similarity algorithm. After converting the field name into word vectors, the similarity is calculated. When the similarity exceeds the preset threshold and there is no field with the same name in the new version, it is determined to be a renamed field. The identification process of the upper-level component set is as follows: starting from the basic component to be upgraded, a breadth-first search algorithm is used to traverse along the reverse edges of the component dependency graph to collect all reachable upper-level component nodes; the access mode includes reading fields, writing fields, and subscribing to change events.

4. The method for rapidly constructing a mobile application framework according to claim 1, characterized in that, The process of extracting the access pattern is as follows: parse the code files of each upper-layer component, identify the code statements that call the status access interface of the basic component to be upgraded, determine the access operation type according to the interface type, record it as a read field access when the interface is a status acquisition method, record it as a write field access when the interface is a status setting method, record it as a subscribe to change event access when the interface is a status listener registration method, extract the field path identifier in the interface call parameters, and combine the access operation type with the field path identifier to form an access pattern record.

5. The method for rapidly constructing a mobile application framework according to claim 1, characterized in that, The calculation process for the propagation path of state changes to upper-layer components includes: traversing all changes in the state pattern difference report of the basic components to obtain the change field identifier and change type; locating the node corresponding to the change field in the state dependency propagation graph, and performing a forward traversal using a depth-first search algorithm starting from this node to collect all affected upper-layer component state field nodes; and determining and marking the migration type of each upper-layer component state field based on the combination of change type and dependency type.

6. The method for rapidly constructing a mobile application framework according to claim 5, characterized in that, The migration types include field deletion migration, field addition migration, field type conversion migration, and field remapping migration; the rule for determining the migration type is: when the change type is field deletion and the dependency type is replica dependency or mapping dependency, the migration type is field deletion migration; When the change type is "field addition" and the dependency type is "replica dependency", the migration type is "field addition migration"; When the change type is a field type change and the dependency type is a replica dependency or a derived dependency, the migration type is a field type conversion migration; when the change type is a field renaming and the dependency type is a replica dependency or a mapping dependency, the migration type is a field remapping migration.

7. The method for rapidly constructing a mobile application framework according to claim 1, characterized in that, The process of generating the state transition script is as follows: Based on the transition type, the corresponding transition strategy template is retrieved from the state transition rule base. The transition strategy template includes the access path expression for the source state data, the operation sequence of the data transformation logic, and the write path expression for the target state data. The path expression placeholders in the transition strategy template are replaced with actual field identifiers, and the type placeholders in the transition strategy template are replaced with actual data types. The resulting code is then assembled into an executable state transition script. The reverse topology order refers to the order in which the dependent components are arranged before the dependent components.

8. The method for rapidly constructing a mobile application framework according to claim 1, characterized in that, The state transition script is executed in a sandbox environment, and the transformation result is stored in a temporary state cache. After the component loads the migrated state data, a cascaded state consistency verification program is run to verify the matching of state data formats and the integrity of data values ​​between the base component to be upgraded and each upper-level component. If the cascaded state consistency verification program passes the verification, the temporary state cache is cleared and the replacement is confirmed to be complete. If the verification fails, the component version is rolled back, the original state data is restored, and a state propagation conflict report and repair suggestions are output.

9. A mobile application framework rapid construction system, used to execute the mobile application framework rapid construction method according to any one of claims 1 to 8, characterized in that, include: The State Pattern Difference Analysis Module is used to parse the state persistence code of the old and new versions of the basic component to be upgraded, extract the structure definition of the state data and compare it, and generate a state pattern difference report of the basic component. The upper-level component identification module is used to identify all upper-level components that directly and indirectly depend on the basic component to be upgraded based on the component dependency graph, and to extract the access patterns of each upper-level component to the state of the basic component to be upgraded. The state dependency propagation graph generation module is used to analyze the state persistence code and data processing logic of each component in the upper-level component set, identify the state fields of upper-level components that have data dependencies on the state of the basic components to be upgraded, and generate a state dependency propagation graph. The upper-layer component state fields include state replica fields, derived compute fields, and cache mapping fields; the state dependency propagation graph is a directed acyclic graph structure, with nodes including component nodes and state field nodes, edges representing the dependency relationships of state data, and edge attributes labeling dependency types including replica dependency, derived dependency, and mapping dependency; the identification process of the upper-layer component state fields is as follows: perform data flow analysis on the upper-layer component code, construct a control flow graph and a data dependency graph, mark the read operation of the state data of the basic component to be upgraded as the data source point, track the variable assignment, function call, and field write operations through the data flow, and when the data flow reaches the storage operation of the upper-layer component state field, mark the state field as a dependency field, and determine the dependency type according to the operation type in the data flow path; Data flow analysis uses static program analysis techniques to determine dependency types based on the operation types in the data flow path: if data is stored directly without transformation, it is a replica dependency; if data is stored after computation and transformation, it is a derived dependency; if data is stored as key-value pairs, it is a mapping dependency. The State Change Propagation Analysis module is used to calculate the propagation path and impact range of each state change on the upper-layer components based on the state dependency propagation graph and the difference report of the state mode of the basic components, and to mark the state fields of the upper-layer components that need to be migrated synchronously and their corresponding migration types. The state transition script generation module is used to query the state transition rule base to match the migration strategy corresponding to each migration type, generate state transition scripts for the basic components to be upgraded and the affected upper-level components respectively, and arrange the execution order of the state transition scripts according to the reverse topological order of the component dependency graph. The state migration execution module is used to execute state migration scripts in sequence to transform the old version state data, and after performing component hot replacement operations, each component loads the migrated state data.

Images