Method, device and equipment for updating front-end application

Abstract

The embodiment of the invention provides a method, a device and equipment for updating a front-end application, relates to the technical field of computers, and is used for realizing real non-perceptual updating, improving user experience, saving resources and improving updating efficiency. The method comprises the following steps: acquiring a state snapshot of a target application during current operation; performing semantic analysis and dependency analysis on the application file of the new version application of the target application and the application file of the old version application of the target application, calculating a minimum difference set between the new version application and the old version application of the target application, and generating a difference package; carrying out compatibility detection on the new version application and the old version application to obtain a compatibility detection result; when the compatibility detection result represents that the new version application is completely compatible with the old version application, hot updating is conducted on the target application based on the state snapshot and the difference package, an updating result of the target application is obtained, and user interface operation is not interrupted in the hot updating process.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, and device for updating a front-end application. Background Technology

[0002] Progressive Web Apps (PWAs), as applications built using modern web technologies, offer a user experience, reliability, and installability similar to native applications, while retaining the broad accessibility and frictionless distribution characteristics of web applications. However, existing PWA update methods have significant drawbacks, impacting user experience and resource efficiency.

[0003] In existing technologies, the traditional Service Worker update mechanism is usually adopted. Specifically, the traditional strategy of "download-wait-activate" is used. The update process is as follows: detect the new version, download all resources, wait for all pages to be closed, and activate the new Service Worker.

[0004] However, the above methods involve a forced refresh mode (i.e., a pop-up prompting the user to refresh the page for application updates), which interrupts the user's ongoing operations, resulting in a disrupted user experience. Furthermore, refreshing the page causes the loss of user input, scroll position, and other application states, making it impossible to maintain the application state during the update process. Users may see both the old and new versions of the interface simultaneously, causing operational confusion and a poor experience. Additionally, these methods require a full download of the new version application package; even minor modifications necessitate downloading the entire application package, resulting in wasted bandwidth and storage. Summary of the Invention

[0005] This application provides a method, apparatus, and device for updating front-end applications to achieve truly seamless updates, improve user experience, and implement a precise differential update algorithm that transmits only the code and resources that have actually changed in the application, saving resources and improving efficiency.

[0006] In a first aspect, embodiments of this application provide a method for updating a front-end application, the method comprising: Obtain a snapshot of the target application's current runtime state, including: multi-dimensional application state; Semantic and dependency analysis are performed on the application files of the new version of the target application and the application files of the old version of the target application. The minimum difference set between the new and old versions of the target application is calculated, and an interpolation package is generated. The minimum difference set is the set of the smallest code units that need to be updated. Perform compatibility testing between the new and old versions of the application to obtain the compatibility test results; When the compatibility test results indicate that the new version of the application is fully compatible with the old version of the application, a hot update is performed on the target application based on the state snapshot and differential package to obtain the updated result of the target application. The user interface operation is not interrupted during the hot update process.

[0007] In one optional embodiment, the multi-dimensional application state includes: framework state, component state, routing state, user interaction state, and business data state; then, a snapshot of the target application's current runtime state is obtained, including: While the target application is running, capture the multi-dimensional application state corresponding to the current timestamp; The multi-dimensional application state is structured, compressed, and deduplicated to obtain a state snapshot.

[0008] In one optional embodiment, semantic analysis and dependency analysis are performed on the application files of the new version of the target application and the application files of the old version of the target application to calculate the minimum set of differences between the new and old versions of the target application and generate a difference package, including: The application files of the new version application and the application files of the old version application are classified into new JS files, new CSS files and new resource files of the new version application, and old JS files, old CSS files and old resource files of the old version application. Perform semantic analysis and code unit dependency analysis on new and old JS files, calculate the minimum difference set, and generate JS patches. The JS patches contain the difference patches of each code unit in the minimum difference set. Generate a CSS patch based on the new and old CSS files; Generate a resource change list based on the new and old resource files; Generate an differential package based on the JS patch, CSS patch, and resource change list.

[0009] In one optional embodiment, semantic analysis and code unit dependency analysis are performed on the new and old JS files to calculate the minimum set of differences and generate a JS patch, including: Perform semantic analysis on the new and old JS files to obtain the JS change information corresponding to this version update task; Based on the application files of the new version of the application, a dependency graph is constructed. The dependency graph is used to describe the dependency relationships between various code units in the new version of the application. Based on JS change information and dependency graph, the set of affected code units corresponding to this version update task is determined, and redundancy is removed from the set of affected code units to obtain the set of minimum differences; Generate a JS patch based on the minimum set of differences and JS change information.

[0010] In one optional embodiment, semantic analysis is performed on the new JS file and the old JS file to obtain the JS change information corresponding to this version update task, including: The new JS file and the old JS file are parsed separately to generate the first abstract syntax tree corresponding to the new JS file and the second abstract syntax tree corresponding to the old JS file; Semantic difference is performed on the first abstract syntax tree and the second abstract syntax tree to obtain the JS change information corresponding to this version update task.

[0011] In one optional embodiment, a compatibility test is performed between the new version of the application and the old version of the application to obtain the compatibility test results, including: Analyze the application files of the new version and the old version to determine whether the compatibility assessment elements of this version update task are compatible. The compatibility assessment elements include: API, data and component interfaces. Semantic analysis is performed on the version numbers of the new and old versions of the application, as well as on the application files of the new and old versions of the application, to determine the destructive change detection results of this version update task. If the compatibility assessment elements are compatible and the destructive change detection result is no destructive change, then the compatibility test result is determined to be that the new version of the application is fully compatible with the old version of the application.

[0012] In one optional embodiment, a hot update is performed on the target application based on a state snapshot and differential packets to obtain the update result of the target application, including: This version update task is divided into different types of update tasks, and the scheduling priority of each update task is determined. According to the scheduling priority of each update task, each update task is executed in sequence. Executing an update task includes: performing topological sorting on the dependencies in the differential package, determining the module replacement order, and performing hot module replacement on each module corresponding to the target application based on the state snapshot and the differential package according to the module replacement order.

[0013] In one optional embodiment, based on state snapshots and differential packets, hot-swap is performed on each module corresponding to the target application, including: For each module, perform the following operations in sequence: load the new code of the target module from the differential package, and configure the new version of the target module, where the target module can be any one of the modules; Migrate the state of the target module in the state snapshot to the target module in the new version; Perform functional verification on the target module of the new version. When the functional verification is successful, perform hot module replacement on the next module.

[0014] Secondly, embodiments of this application also provide a front-end application update apparatus, the apparatus comprising: The acquisition module is used to acquire a snapshot of the target application's current runtime state, which includes a multi-dimensional application state. The generation module is used to perform semantic analysis and dependency analysis on the application files of the new version of the target application and the application files of the old version of the target application, calculate the minimum difference set between the new version of the target application and the old version of the application, and generate the difference package. The minimum difference set is the set of the smallest code units that need to be updated. The detection module is used to perform compatibility testing between the new version of the application and the old version of the application, and obtain the compatibility test results. The hot update module is used to perform a hot update on the target application based on the state snapshot and differential package when the compatibility test results indicate that the new version of the application is fully compatible with the old version of the application, so as to obtain the updated result of the target application. The user interface operation is not interrupted during the hot update process.

[0015] In one optional embodiment, the multi-dimensional application state includes: framework state, component state, routing state, user interaction state, and business data state; therefore, when obtaining a snapshot of the target application's current runtime state, the acquisition module is further used to: While the target application is running, capture the multi-dimensional application state corresponding to the current timestamp; The multi-dimensional application state is structured, compressed, and deduplicated to obtain a state snapshot.

[0016] In one optional embodiment, semantic analysis and dependency analysis are performed on the application files of the new version of the target application and the application files of the old version of the target application to calculate the minimum set of differences between the new and old versions of the target application. When generating the difference package, the generation module is further configured to: The application files of the new version application and the application files of the old version application are classified into new JS files, new CSS files and new resource files of the new version application, and old JS files, old CSS files and old resource files of the old version application. Perform semantic analysis and code unit dependency analysis on new and old JS files, calculate the minimum difference set, and generate JS patches. The JS patches contain the difference patches of each code unit in the minimum difference set. Generate a CSS patch based on the new and old CSS files; Generate a resource change list based on the new and old resource files; Generate an differential package based on the JS patch, CSS patch, and resource change list.

[0017] In one optional embodiment, when performing semantic analysis and code unit dependency analysis on the new and old JS files, calculating the minimum set of differences, and generating the JS patch, the generation module is also used for: Perform semantic analysis on the new and old JS files to obtain the JS change information corresponding to this version update task; Based on the application files of the new version of the application, a dependency graph is constructed. The dependency graph is used to describe the dependency relationships between various code units in the new version of the application. Based on JS change information and dependency graph, the set of affected code units corresponding to this version update task is determined, and redundancy is removed from the set of affected code units to obtain the set of minimum differences; Generate a JS patch based on the minimum set of differences and JS change information.

[0018] In one optional embodiment, when performing semantic analysis on the new and old JS files to obtain the JS change information corresponding to this version update task, the generation module is further used to: The new JS file and the old JS file are parsed separately to generate the first abstract syntax tree corresponding to the new JS file and the second abstract syntax tree corresponding to the old JS file; Semantic difference is performed on the first abstract syntax tree and the second abstract syntax tree to obtain the JS change information corresponding to this version update task.

[0019] In one optional embodiment, when performing compatibility testing between the new version of the application and the old version of the application and obtaining the compatibility test results, the testing module is further configured to: Analyze the application files of the new version and the old version to determine whether the compatibility assessment elements of this version update task are compatible. The compatibility assessment elements include: API, data and component interfaces. Semantic analysis is performed on the version numbers of the new and old versions of the application, as well as on the application files of the new and old versions of the application, to determine the destructive change detection results of this version update task. If the compatibility assessment elements are compatible and the destructive change detection result is no destructive change, then the compatibility test result is determined to be that the new version of the application is fully compatible with the old version of the application.

[0020] In an optional embodiment, when performing a hot update on the target application based on the state snapshot and differential packets, and obtaining the update result of the target application, the hot update module is further configured to: This version update task is divided into different types of update tasks, and the scheduling priority of each update task is determined. According to the scheduling priority of each update task, each update task is executed in sequence. Executing an update task includes: performing topological sorting on the dependencies in the differential package, determining the module replacement order, and performing hot module replacement on each module corresponding to the target application based on the state snapshot and the differential package according to the module replacement order.

[0021] In an optional embodiment, when performing hot module replacement on each module corresponding to the target application based on state snapshots and differential packets, the hot update module is further used to: For each module, perform the following operations in sequence: load the new code of the target module from the differential package, and configure the new version of the target module, where the target module can be any one of the modules; Migrate the state of the target module in the state snapshot to the target module in the new version; Perform functional verification on the target module of the new version. When the functional verification is successful, perform hot module replacement on the next module.

[0022] Thirdly, embodiments of this application also provide an electronic device, including: Processor; and Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the update method of the front-end application as described in the first aspect.

[0023] Fourthly, embodiments of this application also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the front-end application update method as described in the first aspect.

[0024] Fifthly, this application provides a computer program product that, when invoked by a computer, causes the computer to execute the update method steps of the front-end application as described in the first aspect.

[0025] The beneficial effects of this application are as follows: In the front-end application update method provided in this application embodiment, a snapshot of the target application's current runtime state is obtained. The state snapshot includes a multi-dimensional application state. Semantic analysis and dependency analysis are performed on the application files of the new version of the target application and the application files of the old version of the target application to calculate the minimum difference set between the new and old versions of the target application and generate an differential package. The minimum difference set is the minimum set of code units that need to be updated. Compatibility testing is performed on the new and old versions of the application to obtain the compatibility test results. When the compatibility test results indicate that the new and old versions of the application are fully compatible, a hot update is performed on the target application based on the state snapshot and the differential package to obtain the update result of the target application. The user interface operation is not interrupted during the hot update process. In this way, the application state continuity is maintained through the state snapshot, the user interface operation is not interrupted during the hot update process, and the user's application state is still maintained after the version switch, achieving a truly seamless update and improving the user experience. Furthermore, the differential package generated based on the minimum difference set of semantic analysis and dependency analysis only updates the necessary code units, solving the problems of serious resource waste and low efficiency. In addition, risks are identified in advance through compatibility testing, and hot updates are only performed when full compatibility is achieved, ensuring the security and reliability of the update process.

[0026] Furthermore, other features and advantages of this application will be set forth in the following description and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described herein are used to provide a further understanding of this application, constitute a part of this application, and do not constitute an improper limitation of this application. In the accompanying drawings: Figure 1 This is a schematic diagram of an optional system architecture applicable to the embodiments of this application.

[0028] Figure 2 This is a schematic diagram illustrating the implementation process of a front-end application update method provided in an embodiment of this application.

[0029] Figure 3 This is a schematic diagram of the structure of a front-end application update device provided in an embodiment of this application.

[0030] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0032] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0033] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0034] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0035] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0036] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0037] (1) State Serialization: Converts the runtime state of the front-end application into a data structure that can be transmitted and stored, including: framework state, component state, route state, user interaction state, business data state, etc.

[0038] (2) Hot switching: A technical protocol for dynamically replacing application code and state without interrupting application execution or refreshing the page.

[0039] (3) Hot module replacement: A technical mechanism for dynamically loading, unloading and replacing JavaScript modules at runtime.

[0040] (4) State transition: A conversion mechanism that accurately maps the application state of the old version to the component tree structure of the new version.

[0041] (5) Service Worker Proxy: A proxy mechanism that uses Service Worker to intercept network requests and control resource updates and version management.

[0042] (6) Dependency graph: A directed graph structure that describes the dependencies between modules, components and resource files in an application.

[0043] (7) Virtual DOM Diffing: An optimization technique that minimizes the differences in the actual DOM operation by comparing the virtual DOM tree.

[0044] (8) Rollback Recovery Mechanism: A security mechanism that quickly restores the original version state when hot switching fails.

[0045] (9) Abstract Syntax Tree (AST): A tree-like abstract representation of the source code of a programming language, used for code analysis and semantic understanding.

[0046] (10) Myers Difference Algorithm: An efficient text difference algorithm based on the longest common subsequence, used to calculate the minimum edit distance between two versions.

[0047] (11) Brotli Compression: A lossless data compression algorithm developed by Google. It has a higher compression ratio than gzip and is particularly suitable for text file compression.

[0048] Based on the above explanations of terms and related terminology, the design concept of the embodiments of this application will be briefly introduced below: Currently, PWAs, as applications built using modern web technologies, can provide a user experience, reliability, and installability similar to native applications, while retaining the broad accessibility and frictionless distribution characteristics of web applications. However, existing PWA update methods have significant drawbacks, impacting user experience and resource efficiency.

[0049] In existing technologies, the traditional Service Worker update mechanism is usually adopted. Specifically, the traditional strategy of "download-wait-activate" is used. The update process is as follows: detect the new version, download all resources, wait for all pages to be closed, and activate the new Service Worker.

[0050] However, the above methods involve a forced refresh mode (i.e., a pop-up prompting the user to refresh the page for application updates), which interrupts the user's ongoing operations, resulting in a disrupted user experience. Furthermore, refreshing the page causes the loss of user input, scroll position, and other application states, making it impossible to maintain the application state during the update process. Users may see both the old and new versions of the interface simultaneously, causing operational confusion and a poor experience. Additionally, these methods require a full download of the new version application package; even minor modifications necessitate downloading the entire application package, resulting in wasted bandwidth and storage.

[0051] In view of this, this application provides a method for updating a front-end application, which may specifically include: obtaining a snapshot of the current running state of the target application, the snapshot including: multi-dimensional application state; performing semantic analysis and dependency analysis on the application files of the new version of the target application and the application files of the old version of the target application, calculating the minimum difference set between the new version of the target application and the old version of the application, and generating a difference package, wherein the minimum difference set is: the minimum set of code units that need to be updated; performing compatibility testing on the new version of the application and the old version of the application, and obtaining a compatibility testing result; finally, when the compatibility testing result indicates that the new version of the application and the old version of the application are fully compatible, performing a hot update on the target application based on the state snapshot and the difference package, and obtaining the update result of the target application, wherein the user interface operation is not interrupted during the hot update process.

[0052] By employing the above approach, application state continuity is maintained through state snapshots, and hot updates do not interrupt user interface operations. After version switching, the user's application state remains intact, achieving truly seamless updates and improving user experience. Furthermore, based on semantic analysis and dependency analysis, a differential package with a minimal set of differences is generated, updating only necessary code units, thus addressing the problems of severe resource waste and low efficiency. In addition, compatibility testing identifies risks in advance, and hot updates are only performed when full compatibility is achieved, ensuring the security and reliability of the update process.

[0053] In particular, the preferred embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments of this application and the features in the embodiments can be combined with each other without conflict.

[0054] See Figure 1As shown, it is a schematic diagram of an optional system architecture applicable to the embodiments of this application. The system architecture may include: application state management layer 101, differential calculation engine layer 102, hot switching engine core layer 103, compatibility check and caching layer 104, service worker proxy layer 105, and browser rendering scheduling layer 106.

[0055] The application state management layer 101 includes: a state snapshot capturer, a component tree serializer, a route history recorder, and a form data retainer. Specifically, the state snapshot capturer performs a deep traversal of the application state tree to generate a complete snapshot; the component tree serializer serializes the React / Vue component tree structure into JSON; the route history recorder saves the page navigation history and the current route state; and the form data retainer preserves unsubmitted form data and input states.

[0056] The differential computation engine layer 102 includes: an AST semantic analyzer, a Myers differential algorithm generator, a dependency parser, a differential packet generator, and a Brotli compressor. Specifically, the AST semantic analyzer performs code semantic analysis and differential based on an abstract syntax tree; the Myers differential algorithm generator uses an efficient differential algorithm to calculate file changes; the dependency parser analyzes inter-module dependencies to determine the minimum update range; the differential packet generator generates the smallest incremental update packet; and the Brotli compressor uses an efficient compression algorithm to reduce transmission size.

[0057] The core layer 103 of the hot-swapping engine includes: a module hot-swapping engine, a state migration manager, and a rollback recovery mechanism. Specifically, the module hot-swapping engine dynamically replaces JavaScript modules at runtime; the state migration manager precisely maps the old state to the new version's component structure; and the rollback recovery mechanism detects switching failures and quickly restores to a stable version.

[0058] The compatibility check and caching layer 104 includes: an API compatibility checker, a version comparison analyzer, a snapshot storage manager, and a preload scheduler. Specifically, the API compatibility checker analyzes the compatibility of API, data, and component interfaces between new and old versions; the version comparison analyzer identifies disruptive changes based on semantic version comparison; the snapshot storage manager saves complete snapshots of multiple versions for rollback; and the preload scheduler predicts and preloads possible updates based on user behavior.

[0059] Service Worker proxy layer 105 includes: a network request interceptor, a version control manager, and an offline degradation processor. The network request interceptor intercepts network requests and intelligently selects between cached and network resources; the version control manager maintains version mapping relationships and switching states; and the offline degradation processor implements degradation strategies in case of network anomalies.

[0060] The browser rendering scheduling layer 105 includes: a time-slice scheduler, a priority manager, and a DOM batch updater. The time-slice scheduler uses time-slicing technology to avoid blocking the main thread; the priority manager coordinates the priorities of virtual DOM updates and actual DOM rendering; the DOM batch updater provides an efficient interface for batch DOM updates; and the performance monitor monitors performance metrics of the update process in real time.

[0061] The scenarios applicable to the embodiments of this application include, but are not limited to: large-scale PWA applications (such as e-commerce, social, and office platforms), enterprise-level applications with micro-frontend architecture, SaaS products with extremely high user experience requirements, online tools and games that require frequent updates, and mobile traffic-sensitive web applications.

[0062] The following describes the front-end application update method provided by the exemplary embodiments of this application in conjunction with the above-described system architecture and with reference to the accompanying drawings. It should be noted that the above-described system architecture is only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.

[0063] See Figure 2 The diagram shown illustrates the implementation flow of a front-end application update method provided in this application embodiment. The specific implementation flow of this method is as follows: S20: Obtain a snapshot of the target application's current runtime state.

[0064] The state snapshot is a snapshot of the target application (i.e., the application to be updated) while it is being used by users. The state snapshot includes multi-dimensional application state, which includes: framework state, component state, routing state, user interaction state, and business data state.

[0065] In this embodiment of the application, when an update request for the target application is received, the current running state of the target application is serialized to obtain a state snapshot.

[0066] Optionally, in this embodiment, when the background Service Worker detects the release of a new version for the target application, it triggers an update request for the target application; or, when it detects an update instruction for the target application, it triggers an update request for the target application. This embodiment does not impose any restrictions on this.

[0067] Optionally, in this embodiment of the application, a possible implementation is provided for obtaining a snapshot of the target application's current runtime state, specifically by performing the following operations: S200: Capture the multi-dimensional application state corresponding to the current timestamp when the target application is running.

[0068] In this embodiment, the framework state corresponding to the current runtime of the target application is captured and serialized. The component tree corresponding to the current runtime of the target application is then depth-traversed to obtain the serialized component state. The routing state of the current runtime of the target application is captured and serialized. The user interaction state corresponding to the current runtime of the target application is captured and serialized. The business data state corresponding to the current runtime of the target application is extracted and serialized. The component tree is the component hierarchy of the front-end framework (React / Vue), describing the nesting relationship of UI components and their attributes and states.

[0069] The framework state includes: Redux / Vuex store state, middleware state, asynchronous task state, etc.; component state includes: React / Vue component internal state, props, lifecycle state, etc.; route state includes: current route, history, query parameters, route guards, etc.; user interaction state includes: scroll position, focus state, selected state, drag state, etc.; business data state includes: form data, cached data, temporary data, user preferences, etc.

[0070] S201: Perform structured compression and deduplication on the multi-dimensional application state to obtain a state snapshot.

[0071] In this embodiment of the application, the obtained multi-dimensional application state is structured, compressed, and deduplicated. Then, the processed multi-dimensional application state and the current timestamp are added to the newly created state snapshot to obtain the state snapshot.

[0072] Structured compression refers to compression using the characteristics of JSON structure, while deduplication means that when the same primary object is referenced by multiple secondary objects, the primary object is stored only once. Specifically, in an application context, multiple locations may reference the same JavaScript object. In JavaScript, objects are passed by reference, and multiple variables or properties can point to the same object. For example, in the application state, there is a user object `user={name:"Zhang San",age:25}`. The `currentUser` property of Reduxstore, the props property of component A, and the state property of component B all reference this `user` object. Without reference deduplication, serialization might store three copies of the user object's data (one in the store, one in component A, and one in component B), resulting in wasted storage. Reference deduplication identifies these identical object references and stores the user object's data only once. Other parts of the application use reference IDs to point to it. For example, the serialization result would be `{user:{id:1,name:"Zhang San",age:25},store:{currentUser:{ref:1}},componentA:{props:{user:{ref:1}}},componentB:{state:{user:{ref:1}}}}`. This way, the user object is stored only once, and other parts of the application point to it via reference IDs, thereby reducing storage space and optimizing the size of the state snapshot.

[0073] This allows for the acquisition of a comprehensive state snapshot, ensuring the complete preservation of the application's runtime state. Furthermore, by employing structured compression and deduplication techniques, the size of the state snapshot is reduced, saving storage space.

[0074] S21: Perform semantic analysis and dependency analysis on the application files of the new version of the target application and the application files of the old version of the target application, calculate the minimum set of differences between the new version of the target application and the old version of the application, and generate the difference package.

[0075] The minimum difference set is the set of the smallest code units that need to be updated.

[0076] Optionally, in this embodiment of the application, a possible implementation is provided for performing semantic analysis and dependency analysis on the application files of the new version of the target application and the application files of the old version of the target application, calculating the minimum set of differences between the new version of the target application and the old version of the application, and generating a differential package, specifically performing the following operations: S210: Classify the application files of the new version application and the application files of the old version application to obtain the new JS file, new CSS file and new resource file of the new version application, and the old JS file, old CSS file and old resource file of the old version application.

[0077] In this embodiment of the application, the application files of the new version of the application are classified into new JS files, new CSS files and new resource files, and the application files of the old version of the application are classified into old JS files, old CSS files and old resource files.

[0078] S211: Perform semantic analysis and code unit dependency analysis on the new and old JS files, calculate the minimum set of differences, and generate a JS patch.

[0079] The JS patch contains differential patches for each code unit in the minimum difference set.

[0080] Specifically, in this embodiment of the application, the steps for performing semantic analysis and code unit dependency analysis on the new and old JS files, calculating the minimum set of differences, and generating the JS patch are as follows: S2110: Perform semantic analysis on the new and old JS files to obtain the JS change information corresponding to this version update task.

[0081] Optionally, in this embodiment of the application, a possible implementation is provided for performing semantic analysis on the new JS file and the old JS file to obtain the JS change information corresponding to this version update task, specifically by performing the following operations: S2110-1: Parse the new JS file and the old JS file respectively, and generate the first abstract syntax tree corresponding to the new JS file and the second abstract syntax tree corresponding to the old JS file.

[0082] In this embodiment of the application, the new JS file is parsed to generate a first abstract syntax tree corresponding to the new JS file, and the old JS file is parsed to generate a second abstract syntax tree corresponding to the old JS file.

[0083] S2110-2: Perform semantic difference on the first abstract syntax tree and the second abstract syntax tree to obtain the JS change information corresponding to this version update task.

[0084] In this embodiment of the application, semantic difference at the AST level is performed on the first abstract syntax tree and the second abstract syntax tree to obtain the JS change information corresponding to this version update task.

[0085] In this way, semantic difference at the AST level can identify subtle changes in code structure such as functions, classes, and variables, rather than just changes in text lines, thus improving the accuracy of identifying changes in JS.

[0086] S2111: Based on the application files of the new version of the application, construct the dependency graph.

[0087] The dependency graph is used to describe the dependencies between code units in the new version of the application. Each code unit includes: JS modules, components, and resource files. For example, JS modules (such as user.js for user management, product.js for product management, and utils.js for utility functions), React / Vue components (such as UserProfile and ProductList components), and resource files (such as styles.css and logo.png image files) can all serve as nodes in the dependency graph.

[0088] S2112: Based on JS change information and dependency graph, determine the set of affected code units corresponding to this version update task, and remove redundancy from the set of affected code units to obtain the minimum difference set.

[0089] In this embodiment, the modified code units are identified based on JS change information. Then, the nodes of these modified code units are found in the dependency graph. The edges of the dependency relationships are traced forward to find all dependent code units that directly or indirectly depend on these modified code units. The dependent code units and the modified code units are taken as the set of affected code units. Then, based on the dependency relationships, change types, and scope of impact, redundant and indirectly overridden affected code units in the set of affected code units are removed to obtain the minimum difference set.

[0090] For example, suppose the code units that have been changed are identified as including the utils.js module. In the dependency graph, the node corresponding to utils.js is found. Then, by tracing along the dependency edges, it is found that the user.js module, the ProductList component, and the styles.css file all depend on utils.js. Therefore, the set of affected code units includes {utils.js module, user.js module, ProductList component, styles.css file}.

[0091] For example, when performing redundancy removal, suppose the set of affected code units includes {utils.js, user.js, product.js, order.js}. If order.js only indirectly depends on utils.js through user.js, and user.js has been updated, then order.js may not need to be updated directly. If utils.js changes but the API is compatible, it may only need to update utils.js itself, and the affected code units that depend on it do not need to be updated. If utils.js changes and the API is incompatible, utils.js and all affected code units that directly depend on it need to be updated.

[0092] S2113: Generate a JS patch based on the minimum set of differences and JS change information.

[0093] In this embodiment of the application, the JS change information of each code unit in the smallest difference set is filtered out from the JS change information to obtain the JS patch.

[0094] In this way, by analyzing the dependencies between code units through dependency graphs, the propagation path of changes can be accurately identified, avoiding excessive or missed updates, reducing redundant updates, retaining only necessary update units, and improving the conciseness of the differential package. Combining semantic analysis (AST parsing) and structural analysis (dependency graphs) to consider both code logic changes and architectural dependency changes enhances the comprehensiveness of the analysis.

[0095] S212: Generates a CSS patch based on the new and old CSS files.

[0096] In this embodiment of the application, Myers difference is performed on the new CSS file and the old CSS file to obtain the CSS patch.

[0097] S213: Generate a resource change list based on the new and old resource files.

[0098] In this embodiment of the application, Myers difference is performed on the new resource file and the old resource file to obtain the resource change list.

[0099] S214: Generate differential packages based on JS patches, CSS patches, and resource change lists.

[0100] In this embodiment, the JS patch, CSS patch, and resource change list are added to the created differential package file to obtain the differential package.

[0101] In this way, JS files, CSS files, and resource files are processed separately, and the efficient Myers difference algorithm is used to calculate file changes for different types of files, which improves the accuracy of updates and the speed of generating difference packages.

[0102] Additionally, it is worth noting that in this embodiment, dependency update information can also be determined based on the dependency graphs generated by the new JS file and the old JS file respectively, and the dependency update information can also be added to the differential package file to obtain the differential package.

[0103] Furthermore, in this embodiment of the application, in order to reduce the transmission volume of the differential packet, after obtaining the differential packet, an efficient compression algorithm (such as Brotli compression) is used to compress the differential packet to obtain the compressed differential packet.

[0104] S22: Perform compatibility testing between the new version of the application and the old version of the application, and obtain the compatibility test results.

[0105] Among them, the compatibility test results represent the compatibility between the new version of the application and the old version of the application.

[0106] Optionally, in this application embodiment, a possible implementation is provided for performing compatibility testing on the new version of the application and the old version of the application to obtain the compatibility testing results, specifically by performing the following operations: S220: Analyze the application files of the new version application and the application files of the old version application to determine whether the compatibility assessment elements of this version update task are compatible.

[0107] The compatibility assessment elements include: API, data, and component interfaces.

[0108] In this embodiment, the application files of the new version application and the JS files in the application files of the old version application are first used to generate a first abstract syntax tree and a second abstract syntax tree. Then, the structure of function signatures, class definitions, exported interfaces, etc. are compared to determine whether the compatibility evaluation elements of this version update task are compatible.

[0109] For example: if the old version of the application has user.getName() while the new version uses user.getProfile().name, or if the function parameter changes from (name, age) to (profile), then it is determined to be an incompatibility factor in the compatibility assessment. For component interfaces, check whether the props definition (e.g., the old version of the component receives onClick while the new version receives onButtonClick) and the event interface (e.g., the old version triggers the change event while the new version triggers the input event) are consistent. If they are inconsistent, then it is determined to be an incompatibility factor in the compatibility assessment.

[0110] S221: Perform semantic analysis on the version numbers of the new and old versions of the application, as well as on the application files of the new and old versions of the application, to determine the destructive change detection results of this version update task.

[0111] For example: if the major version number changes (e.g., 1.0.0 → 2.0.0), the destructive change detection result of this version update task is determined to be a destructive change; perform AST semantic analysis on the application files of the new version application and the application files of the old version application to identify changes in function signatures, API deletions, and data structure changes. If changes in function signatures, API deletions, or data structure changes are identified, the destructive change detection result of this version update task is determined to be a destructive change.

[0112] In addition, runtime testing (actual call testing) can be used to comprehensively evaluate the compatibility of this version update task.

[0113] S222: If the compatibility assessment elements are compatible and the destructive change detection result is no destructive change, then the compatibility test result is determined to be that the new version of the application is fully compatible with the old version of the application.

[0114] In this embodiment, if the compatibility assessment elements are compatible and the destructive change detection result is no destructive change, then the compatibility test result is determined to be that the new version application and the old version application are fully compatible; if the compatibility assessment elements are incompatible and the destructive change detection result is no destructive change, then the compatibility test result is determined to be that the new version application and the old version application are partially compatible; if the destructive change detection result is destructive change, then the compatibility test result is determined to be that the new version application and the old version application are incompatible.

[0115] In this way, a complete compatibility assessment system is established, covering three key dimensions: API, data, and component interfaces. This improves the comprehensiveness of the assessment. Furthermore, by combining semantic version analysis and code semantic analysis, destructive changes are verified twice, which improves the accuracy of identifying destructive changes and thus enhances the accuracy of compatibility testing.

[0116] In addition, the security of this version update can be tested. When the compatibility test results indicate that the new version of the application is fully compatible with the old version, and the security test is passed, a hot update is performed on the target application based on the state snapshot and differential package to obtain the update result of the target application. Specifically, a risk assessment model is established to predict the update security by integrating multiple factors.

[0117] For example: assess API compatibility risks (e.g., high risk of API signature changes, medium risk of parameter type changes), dependency risks (e.g., high risk of dependency module version conflicts), state transition risks (e.g., high risk of state transition failure due to data structure changes), and update impact risks (e.g., high risk of large update impact).

[0118] S23: When the compatibility test results indicate that the new version of the application is fully compatible with the old version of the application, a hot update is performed on the target application based on the state snapshot and differential package to obtain the update result of the target application.

[0119] In particular, the user interface operation is not interrupted during the hot update process.

[0120] Additionally, it is worth noting that in this embodiment, the generation of state snapshots, the generation of differential packets, and compatibility testing are performed in parallel.

[0121] In this embodiment of the application, when the compatibility test result indicates that the new version of the application is fully compatible with the old version of the application, and the state snapshot is successfully generated and the differential package is successfully generated, then it is determined that a seamless hot-switching strategy is adopted, that is, based on the state snapshot and the differential package, the target application is hot-updated to obtain the update result of the target application.

[0122] Optionally, in this embodiment, when the compatibility test results indicate that the new version of the application is partially compatible with the old version, and the state snapshot and differential package are successfully generated, a state transition strategy is adopted for version update (which requires data conversion and adaptation, including component state mapping, Store state migration, event handling updates, and lifecycle synchronization, to ensure that the state is used correctly in the new version; the difference between the state transition strategy and the seamless hot-swapping strategy is that the former requires state transition and adaptation). When the compatibility test results indicate that the new version of the application is incompatible with the old version, or the state snapshot or differential package is not successfully generated, a security degradation strategy (e.g., a forced page refresh strategy) is adopted for version update. In this way, the most suitable update strategy is intelligently selected after comprehensively considering the compatibility test results, ensuring the security and reliability of the update.

[0123] Optionally, in this embodiment of the application, a possible implementation is provided for hot updating the target application based on state snapshots and differential packets to obtain the update result of the target application, specifically by performing the following operations: S230: Divide the current version update task into different types of update tasks and determine the scheduling priority of each update task.

[0124] The types of update tasks include, but are not limited to: security patches, feature updates, style updates, and resource updates.

[0125] In this embodiment, when determining the scheduling priority of each update task, the scheduling priority of each update task is determined based on the update urgency, user interaction priority, and resource availability weight. The update urgency is fixed according to the type of update task, but can also be dynamically adjusted according to the content of the update task. For example, the update urgency of a security patch is 1.0, but if the security patch fixes a high-risk vulnerability, the update urgency can be increased to 1.2.

[0126] S231: Execute each update task in sequence according to its scheduling priority.

[0127] The execution of an update task includes: topologically sorting the dependencies in the differential package, determining the module replacement order, and performing hot module replacement on each module corresponding to the target application according to the module replacement order, based on the state snapshot and the differential package. The modules are JS modules.

[0128] For example, suppose the update tasks include: security patch update tasks, feature update tasks, style update tasks, and resource update tasks. The scheduling priority for security patch update tasks is 1.0, for feature update tasks it's 0.7, for style update tasks it's 0.4, and for resource update tasks it's 0.2. Then, the security patch update tasks are executed first, followed by the feature update tasks, style update tasks, and resource update tasks in that order. This ensures that critical updates are completed promptly, while non-critical updates do not block the user interface.

[0129] In this embodiment, the module replacement order is: the dependent module first, followed by the modules that depend on it. For example, assuming utils.js is a dependency of user.js, the module replacement order is to replace utils.js first, then replace user.js. This avoids user.js not finding the new version of utils.js during replacement, avoids dependency issues, and improves the accuracy of updates.

[0130] Optionally, in this embodiment of the application, when performing hot-swapping of each module corresponding to the target application based on the state snapshot and differential package according to the module replacement order, the following operations are performed sequentially for each module: S2310: Load new code for the target module from the differential package and configure the new version of the target module.

[0131] The target module can be any one of the modules.

[0132] S2311: Migrate the state of the target module in the state snapshot to the new version of the target module.

[0133] S2312: Perform functional verification on the target module of the new version. When the functional verification is successful, perform hot module replacement for the next module.

[0134] Among them, functional verification demonstrates that the target module of the new version works normally.

[0135] In this embodiment of the application, when performing functional verification, the following aspects are checked: (1) Check whether the new version of the target module can be loaded and executed normally (e.g., if the new version of the target module fails to load or throws an exception during execution, the functional verification fails); (2) Check whether the exported interfaces of the new version of the target module are complete (e.g., if the old version of the target module exports getUser and setUser, the new version of the target module should also export these interfaces; if they are missing, the functional verification fails); (3) Check whether the state transition is successful (e.g., after the user login state of the old version of the target module is transitioned to the new version of the target module, the new version of the target module can correctly read and use the state; otherwise, the functional verification fails); (4) Check whether the new version of the target module can respond to the call normally (e.g., when other modules call the API of the new version of the target module, they can return the result normally; if they cannot respond, the functional verification fails); If any of the above aspects fail, the functional verification result is determined to be unsuccessful, the target module is rolled back (the old version of the target module is restored), and a failure is returned; If any of the above aspects pass, the functional verification result is determined to be successful, and the module hot replacement of the next module continues to be executed.

[0136] This ensures the accurate migration of the module's state from the state snapshot to the new version module, maintaining state integrity and avoiding state loss issues. Furthermore, functional verification is performed immediately after each module replacement to prevent problem accumulation and ensure that each replaced module functions correctly.

[0137] Additionally, it is worth noting that in this embodiment, the overall task of executing each update task sequentially according to the scheduling priority of each update task is time-sliced. Specifically, the overall task can be divided into multiple sub-tasks, each update task can be divided into multiple sub-tasks, and the hot replacement task of each module can be divided into multiple sub-tasks. This embodiment does not impose any restrictions on this.

[0138] In this embodiment, the multiple subtasks after the time slice are not executed one by one, but are executed when the target application is idle and can be interrupted by user interaction. This avoids blocking the main thread for a long time, achieves seamless updates for the user, and improves the user experience. Here, "target application idle" does not mean that the target application has not been started, but rather that the user is not currently interacting with the target application. For example, if the target application displays interface A, but the user does not interact with interface A, then the target application is considered idle at this time.

[0139] For example, when a user clicks a button, the current subtask is immediately paused, and the user's action is given priority. The current subtask is resumed only when the user does not interact with the target application.

[0140] Furthermore, in this embodiment, after obtaining the update result of the target application, it is verified whether the status of the updated target application (i.e., the new version of the target application) is complete and whether the business logic is correct. If the status is incomplete or the business logic is incorrect, a rollback recovery mechanism is triggered. Here, "status complete" means that the application status of the updated target application includes all the key status information before the update, and "business logic correct" means that the business functions of the updated target application can run normally.

[0141] For example, assuming the Redux store contained shopping cart data, user login status, and current route information before the update, these states should be fully restored after the update to ensure users can continue their previous workflow. If issues such as feature failure, data loss, or page rendering errors occur after the update, then the business logic is incorrect.

[0142] Optionally, in this embodiment, after triggering the rollback recovery mechanism, the old version's complete snapshot can be found from multiple complete snapshots based on the old version number, allowing for quick restoration to the old version's state and ensuring application availability. A complete snapshot refers to a snapshot of the application's complete runtime state saved before each version update, with one snapshot corresponding to each version. For example, when the target application updates from v1.0 to v1.1, a complete snapshot of v1.0 will be saved (including Reduxstore data, the state and properties of all components, current routes and history, scroll positions, and form data, etc.).

[0143] Furthermore, in this embodiment, after the target application update is complete, the local cache and version history information can also be updated. The local cache refers to the application resource files (JS, CSS, images, etc.) stored locally in the browser, via the Service Worker's Cache API. The version history information refers to the version mapping relationship and switching status information maintained by the version control manager. The version mapping relationship is the mapping relationship between the old version and the new version (e.g., v1.0→v1.1→v1.2), and the switching status information includes: successful switching, failed switching, rollback, etc. This ensures that the version control manager can correctly manage versions and switching statuses, supporting subsequent version rollback and multi-tab version consistency.

[0144] Furthermore, based on the same technical concept, embodiments of this application provide a front-end application update apparatus, which is used to implement the above-described method flow of embodiments of this application. For example, see [link to relevant documentation]. Figure 3 As shown, the front-end application update device 300 may include: an acquisition module 301, a generation module 302, a detection module 303, and a hot update module 304.

[0145] The acquisition module 301 is used to acquire a snapshot of the current running state of the target application. The snapshot includes: multi-dimensional application state. The generation module 302 is used to perform semantic analysis and dependency analysis on the application files of the new version of the target application and the application files of the old version of the target application, calculate the minimum difference set between the new version of the target application and the old version of the application, and generate a difference package. The minimum difference set is the set of the smallest code units that need to be updated. The detection module 303 is used to perform compatibility testing between the new version of the application and the old version of the application, and obtain the compatibility test results. The hot update module 304 is used to perform a hot update on the target application based on the state snapshot and differential package when the compatibility test result indicates that the new version of the application is fully compatible with the old version of the application, so as to obtain the update result of the target application. The user interface operation is not interrupted during the hot update process.

[0146] In an optional embodiment, the multi-dimensional application state includes: framework state, component state, routing state, user interaction state, and business data state; therefore, when obtaining a snapshot of the target application's current runtime state, the acquisition module 301 is further used to: While the target application is running, capture the multi-dimensional application state corresponding to the current timestamp; The multi-dimensional application state is structured, compressed, and deduplicated to obtain a state snapshot.

[0147] In an optional embodiment, semantic analysis and dependency analysis are performed on the application files of the new version of the target application and the application files of the old version of the target application to calculate the minimum set of differences between the new version and the old version of the target application. When generating the difference package, the generation module 302 is further configured to: The application files of the new version application and the application files of the old version application are classified into new JS files, new CSS files and new resource files of the new version application, and old JS files, old CSS files and old resource files of the old version application. Perform semantic analysis and code unit dependency analysis on new and old JS files, calculate the minimum difference set, and generate JS patches. The JS patches contain the difference patches of each code unit in the minimum difference set. Generate a CSS patch based on the new and old CSS files; Generate a resource change list based on the new and old resource files; Generate an differential package based on the JS patch, CSS patch, and resource change list.

[0148] In an optional embodiment, when performing semantic analysis and code unit dependency analysis on the new and old JS files, calculating the minimum set of differences, and generating the JS patch, the generation module 302 is further configured to: Perform semantic analysis on the new and old JS files to obtain the JS change information corresponding to this version update task; Based on the application files of the new version of the application, a dependency graph is constructed. The dependency graph is used to describe the dependency relationships between various code units in the new version of the application. Based on JS change information and dependency graph, the set of affected code units corresponding to this version update task is determined, and redundancy is removed from the set of affected code units to obtain the set of minimum differences; Generate a JS patch based on the minimum set of differences and JS change information.

[0149] In an optional embodiment, when performing semantic analysis on the new and old JS files to obtain the JS change information corresponding to this version update task, the generation module 302 is further used to: The new JS file and the old JS file are parsed separately to generate the first abstract syntax tree corresponding to the new JS file and the second abstract syntax tree corresponding to the old JS file; Semantic difference is performed on the first abstract syntax tree and the second abstract syntax tree to obtain the JS change information corresponding to this version update task.

[0150] In an optional embodiment, when performing compatibility testing on the new version of the application and the old version of the application, and obtaining the compatibility test results, the testing module 303 is further configured to: Analyze the application files of the new version and the old version to determine whether the compatibility assessment elements of this version update task are compatible. The compatibility assessment elements include: API, data and component interfaces. Semantic analysis is performed on the version numbers of the new and old versions of the application, as well as on the application files of the new and old versions of the application, to determine the destructive change detection results of this version update task. If the compatibility assessment elements are compatible and the destructive change detection result is no destructive change, then the compatibility test result is determined to be that the new version of the application is fully compatible with the old version of the application.

[0151] In an optional embodiment, when performing a hot update on the target application based on the state snapshot and differential packets, and obtaining the update result of the target application, the hot update module 304 is further configured to: This version update task is divided into different types of update tasks, and the scheduling priority of each update task is determined. According to the scheduling priority of each update task, each update task is executed in sequence. Executing an update task includes: performing topological sorting on the dependencies in the differential package, determining the module replacement order, and performing hot module replacement on each module corresponding to the target application based on the state snapshot and the differential package according to the module replacement order.

[0152] In an optional embodiment, when performing hot module replacement on each module corresponding to the target application based on the state snapshot and differential packet, the hot update module 304 is further configured to: For each module, perform the following operations in sequence: load the new code of the target module from the differential package, and configure the new version of the target module, where the target module can be any one of the modules; Migrate the state of the target module in the state snapshot to the target module in the new version; Perform functional verification on the target module of the new version. When the functional verification is successful, perform hot module replacement on the next module.

[0153] Based on the description of the method and apparatus embodiments above, an exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method according to an embodiment of the present invention.

[0154] This application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0155] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0156] See Figure 4The diagram shown below illustrates the structure of an electronic device 400 that can serve as a server or client in this application, and is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0157] like Figure 4 As shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0158] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, output unit 407, storage unit 408, and communication unit 409. Input unit 406 can be any type of device capable of inputting information to electronic device 400. Input unit 406 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 407 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 408 may include, but is not limited to, disks and optical discs. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth devices, WiFi devices, worldwide interoperability for microwave access (WiMax) devices, cellular communication devices, and / or the like.

[0159] The computing unit 401 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above. For example, in some embodiments, the above-described front-end application update method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the above-described front-end application update method by any other suitable means (e.g., by means of firmware).

[0160] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0161] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0162] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device, PLD) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0163] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0164] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0165] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0166] Furthermore, it should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of this invention are still within the scope of this application.

Claims

1. A method for updating a front-end application, characterized in that, include: Obtain a snapshot of the target application's current runtime state, the snapshot including: multi-dimensional application state; Semantic analysis and dependency analysis are performed on the application files of the new version of the target application and the application files of the old version of the target application. The minimum difference set between the new version of the target application and the old version of the application is calculated, and a difference package is generated. The minimum difference set is the set of the smallest code units that need to be updated. Perform compatibility testing between the new version of the application and the old version of the application, and obtain the compatibility test results; When the compatibility test result indicates that the new version of the application is fully compatible with the old version of the application, the target application is hot-updated based on the state snapshot and the differential package to obtain the update result of the target application. The user interface operation is not interrupted during the hot-updation process.

2. The method as described in claim 1, characterized in that, The multi-dimensional application state includes: framework state, component state, routing state, user interaction state, and business data state; therefore, obtaining a snapshot of the target application's current runtime state includes: During the runtime of the target application, capture the multi-dimensional application state corresponding to the current timestamp; The multi-dimensional application state is structured, compressed, and deduplicated to obtain the state snapshot.

3. The method as described in claim 2, characterized in that, The process involves performing semantic and dependency analysis on the application files of the new and old versions of the target application, calculating the minimum set of differences between the new and old versions, and generating a difference package, including: The application files of the new version application and the application files of the old version application are classified to obtain the new JS file, new CSS file and new resource file of the new version application, and the old JS file, old CSS file and old resource file of the old version application. Semantic analysis and code unit dependency analysis are performed on the new JS file and the old JS file to calculate the minimum difference set and generate a JS patch. The JS patch contains the difference patch of each code unit in the minimum difference set. Generate a CSS patch based on the new CSS file and the old CSS file; Based on the new resource file and the old resource file, a resource change list is generated; Based on the JS patch, CSS patch, and resource change list, an differential package is generated.

4. The method as described in claim 3, characterized in that, The step of performing semantic analysis and code unit dependency analysis on the new JS file and the old JS file, calculating the minimum difference set, and generating a JS patch includes: Perform semantic analysis on the new JS file and the old JS file to obtain the JS change information corresponding to this version update task; Based on the application files of the new version of the application, a dependency graph is constructed, which is used to describe the dependency relationships between various code units in the new version of the application. Based on the JS change information and the dependency graph, the set of affected code units corresponding to this version update task is determined, and redundancy is removed from the set of affected code units to obtain the minimum difference set. Based on the minimum set of differences and the JS change information, a JS patch is generated.

5. The method as described in claim 4, characterized in that, The semantic analysis of the new JS file and the old JS file yields the JS change information corresponding to this version update task, including: The new JS file and the old JS file are parsed respectively to generate a first abstract syntax tree corresponding to the new JS file and a second abstract syntax tree corresponding to the old JS file; Semantic difference is performed on the first abstract syntax tree and the second abstract syntax tree to obtain the JS change information corresponding to this version update task.

6. The method as described in claim 1, characterized in that, The process of performing compatibility testing between the new version of the application and the old version of the application, and obtaining the compatibility test results, includes: Analyze the application files of the new version application and the application files of the old version application to determine whether the compatibility assessment elements of this version update task are compatible. The compatibility assessment elements include: API, data and component interfaces. Semantic analysis is performed on the version number of the new version application and the version number of the old version application, as well as on the application files of the new version application and the application files of the old version application, to determine the destructive change detection results of this version update task. If the compatibility assessment elements are compatible and the destructive change detection result is no destructive change, then the compatibility detection result is determined to be that the new version of the application is fully compatible with the old version of the application.

7. The method as described in claim 1, characterized in that, The process of performing a hot update on the target application based on the state snapshot and the differential packet to obtain the update result of the target application includes: The update task is divided into different types of update tasks, and the scheduling priority of each update task is determined. According to the scheduling priority of each update task, each update task is executed sequentially; wherein, executing an update task includes: performing topological sorting on the dependencies in the differential package, determining the module replacement order, and performing hot module replacement on each module corresponding to the target application according to the module replacement order, based on the state snapshot and the differential package.

8. The method as described in claim 7, characterized in that, The process of performing hot module replacement on each module corresponding to the target application based on the state snapshot and the differential packet includes: For each module, the following operations are performed in sequence: load the new code of the target module from the differential package, and configure the new version of the target module, wherein the target module is any one of the modules; Migrate the state corresponding to the target module in the state snapshot to the new version of the target module; The new version of the target module is functionally verified. When the functional verification is successful, the module hot-swap of the next module is executed.

9. A front-end application update device, characterized in that, include: The acquisition module is used to acquire a snapshot of the current runtime state of the target application, the snapshot including: multi-dimensional application state; The generation module is used to perform semantic analysis and dependency analysis on the application files of the new version of the target application and the application files of the old version of the target application, calculate the minimum difference set between the new version of the target application and the old version of the application, and generate a difference package, wherein the minimum difference set is: the minimum code unit set that needs to be updated; The detection module is used to perform compatibility testing between the new version of the application and the old version of the application, and obtain the compatibility test results. The hot update module is used to perform a hot update on the target application based on the state snapshot and the differential package when the compatibility detection result indicates that the new version of the application is fully compatible with the old version of the application, thereby obtaining the update result of the target application. The hot update process does not interrupt the user interface operation.

10. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method as described in any one of claims 1-8.

Images