Page jump control method, patch file generation method, and control system

Abstract

This application discloses a page navigation control method, an application patch file generation method, and a control system. The method includes: obtaining a patch description file for a target application, wherein the patch description file includes patch metadata and a patch strategy corresponding to at least one repair route page of the target application; validating the patch description file, and storing the patch description file in a preset database if the validation passes; responding to a route navigation request triggered by a target object, searching the preset database for a target patch strategy corresponding to the target route page of the route navigation event, and determining the final route page based on the search results. This application solves the technical problem that related page navigation control technologies cannot handle mixed navigation flows, leading to inconsistent navigation and poor user experience.

Description

Technical Field

[0001] This application relates to the field of application development technology, and more specifically, to a page redirection control method, an application patch file generation method, and a control system. Background Technology

[0002] In application development, especially when using cross-platform frameworks like Flutter, achieving efficient and secure hot-fix capabilities is a key requirement for ensuring application stability and business agility. In recent years, some teams have proposed a page-level degradation solution based on Flutter Web to achieve hot-fix functionality. The core idea of ​​this solution is to completely replace the problematic native routing page with a Flutter Web routing page compiled from Dart, and then perform degradation repair through route scheduling. In practical implementation, this solution adopts a "baseline package + differential package" model, that is, by comparing the file system differences between the old and new complete versions, an incremental patch package is generated.

[0003] However, because this fix focuses on replacing individual route pages, in complex navigation flows composed of a mix of native and Flutter web route pages, the navigation mechanism of the native route page is built on a specific operating system ecosystem, while the navigation mechanism of the Flutter web route page is based on the browser ecosystem. Furthermore, navigation within the Flutter web route page is achieved by modifying the browser's URL (Uniform Resource Locator), and these actions do not notify the navigation stack of the native route page. This means that when a user attempts to navigate from a Flutter web route page to a native route page, because the navigation history within the Flutter web route page is not recorded in the native route page's navigation stack, they cannot correctly navigate back or may navigate back to the wrong page, disrupting navigation consistency and the continuity of the user experience.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a page navigation control method, an application patch file generation method, and a control system to at least solve the technical problem that related page navigation control technologies cannot cope with mixed navigation flows, resulting in inconsistent navigation and poor user experience.

[0006] According to one aspect of the embodiments of this application, a page redirection control method is provided, applied to a client device, comprising: obtaining a patch description file of a target application, wherein the patch description file includes patch metadata and patch policy corresponding to at least one patch route page of the target application; verifying the patch description file, and storing the patch description file in a preset database if the verification passes; responding to a route redirection event of the target application triggered by a target object, searching the preset database for a target patch policy of the target route page corresponding to the route redirection event, and determining the final route page based on the search results.

[0007] Optionally, the patch metadata includes at least: a first download address and a first encryption result of a baseline packet characterizing the Web resource information of the repaired route page before the repair; a second download address and a second encryption result of a differential packet characterizing the difference between the Web resource information of the repaired route page before and after the repair; and verification of the patch description file, including: for each repaired route page, determining the page type of the current repaired route page, wherein the page type includes at least one of the following: a newly added route page, a changed route page; if the page type of the current repaired route page is a changed route page, verifying the patch metadata of the current repaired route page based on the baseline packet and the differential packet of the current repaired route page; if the page type of the current repaired route page is a newly added route page, verifying the patch metadata of the current repaired route page based on the differential packet of the current repaired route page.

[0008] Optionally, the patch metadata of the current repair route page is verified based on the baseline packet and differential packet of the current repair route page, including: obtaining the baseline packet of the current repair route page based on the first download address, and obtaining the differential packet of the current repair route page based on the second download address; encrypting the baseline packet of the current repair route page to obtain a third encryption result, and encrypting the differential packet of the current repair route page to obtain a fourth encryption result; determining whether the first encryption result and the third encryption result are the same, and determining whether the second encryption result and the fourth encryption result are the same; if the first encryption result and the third encryption result are the same, and the second encryption result and the fourth encryption result are the same, the patch metadata of the current repair route page is determined to have passed the verification; if the first encryption result and the third encryption result are different and / or the second encryption result and the fourth encryption result are different, the patch metadata of the current repair route page is determined to have failed the verification.

[0009] Optionally, the patch metadata of the current repair route page is verified based on the differential packet of the current repair route page, including: obtaining the differential packet of the current repair route page based on the second download address; encrypting the differential packet of the current repair route page to obtain a fourth encryption result; determining whether the second encryption result and the fourth encryption result are the same; if the second encryption result and the fourth encryption result are the same, determining that the patch metadata of the current repair route page has passed the verification; if the second encryption result and the fourth encryption result are different, determining that the patch metadata of the current repair route page has failed the verification.

[0010] Optionally, storing the patch description file in a preset database includes: for each repair route page, determining the page type of the current repair route page; if the page type of the current repair route page is a changed route page, merging the baseline packet and differential packet of the current repair route page to obtain the target packet, and storing the target packet and patch policy of the current repair route page in the preset database; if the page type of the current repair route page is a new route page, using the differential packet of the current repair route page as the target packet, and storing the target packet and patch policy of the current repair route page in the preset database.

[0011] Optionally, responding to a route redirection event of the target application triggered by the target object includes: receiving a route redirection request initiated by the target object, wherein the route redirection request carries at least redirection intent information, and the redirection intent information includes at least: a Uniform Resource Identifier path and parameter information of the target route page; sending the redirection intent information in the route redirection request to a Web Dynamic View container, and obtaining a route redirection event fed back by the Web Dynamic View container, wherein the Web Dynamic View container is used to map the Uniform Resource Identifier path in the redirection intent information to a route identifier, and to perform format conversion on the parameter information of the target route page to obtain the route redirection event.

[0012] Optionally, the route redirection event carries at least the target route identifier of the target route page; the process involves searching a preset database for a target patching policy corresponding to the target route page of the route redirection event, and determining the final route page based on the search results, including: searching the preset database based on the target route identifier of the target route page; if the search results are empty, determining the target route page as the final route page; if the search results are not empty, determining a target patching policy containing the target route identifier, and determining whether the target patching policy meets preset policy activation conditions, wherein the policy activation conditions include at least one of the following: activation time, activation object category; if the target patching policy meets the policy activation conditions, rendering the target packet corresponding to the target route identifier in the preset database to obtain the final route page; if the target patching policy does not meet the policy activation conditions, determining the final route page as the target route page.

[0013] Optionally, rendering the target package corresponding to the target route identifier in the preset database includes: loading the target package corresponding to the target route identifier in the preset database using a Web dynamic view container, parsing the target package corresponding to the target route identifier to obtain script code, executing the script code, and obtaining the final route page.

[0014] According to another aspect of the embodiments of this application, an application patch file generation method is also provided, applied to a cloud device, comprising: obtaining a plurality of first routing pages of a target application before repair and a plurality of second routing pages after repair; determining a first fingerprint of each first routing page and a second fingerprint of each second routing page respectively, and determining at least one repaired routing page of the target application based on the first fingerprint and the second fingerprint; determining patch metadata and patch policy of each repaired routing page, and forming a patch description file of the target application by the patch metadata and patch policy of at least one repaired routing page.

[0015] Optionally, determining the first fingerprint of each first routing page and the second fingerprint of each second routing page includes: for each routing page, performing the following steps to determine the fingerprint of the routing page, wherein the routing page includes: a first routing page or a second routing page, and the fingerprint includes: the first fingerprint of the first routing page or the second fingerprint of the second routing page; determining multiple associated files of the routing page and the dependencies between the multiple associated files, wherein the types of associated files include at least one of the following: source code files, static resource files, and the dependencies include at least one of the following: import relationships, reference relationships; using each associated file as a tree node, determining the hierarchy between the corresponding tree nodes according to the dependencies, and constructing a dependency tree for the routing page; sequentially calculating the hash value of the associated file corresponding to each tree node in the dependency tree, and determining the fingerprint of the routing page based on the hash values ​​of all tree nodes in the dependency tree.

[0016] Optionally, the page type for repairing the route page includes at least one of the following: adding a route page, changing a route page; determining the repaired route page of the target application based on the first fingerprint and the second fingerprint includes: determining the intersection of multiple first route pages and multiple second route pages, and traversing each route page in the intersection; if the first fingerprint and the second fingerprint of the current route page are different, determining the current route page as the changed route page of the target application; determining the difference set obtained by subtracting multiple first route pages from multiple second route pages, and using each route page in the difference set as the added route page of the target application.

[0017] Optionally, the repair routing page generates a patch description file based on the repair routing page, including: when the page type of the repair routing page is a change routing page, obtaining the policy content of the repair routing page, and at least using the policy content and the route identifier of the repair routing page as the patch policy of the repair routing page; compiling multiple associated files of the repair routing page before repair into a baseline packet, and compiling multiple associated files of the repair routing page after repair into a target packet, calculating the difference between the baseline packet and the target packet using a differential algorithm to obtain a differential packet; encrypting the baseline packet to obtain a first encryption result, and encrypting the differential packet to obtain a second encryption result; to... The first download address, first encryption result, second download address, and second encryption result of the baseline packet of the repaired routing page are used as patch metadata for the repaired routing page; when the page type of the repaired routing page is a new routing page, the policy content of the repaired routing page is obtained, and at least the policy content and the routing identifier of the repaired routing page are used as the patch policy of the repaired routing page; the associated files of the repaired routing page after repair are compiled into a differential packet, and the differential packet is encrypted to obtain a second encryption result, and at least the second download address and second encryption result of the differential packet of the repaired routing page are used as patch metadata for the repaired routing page.

[0018] According to another aspect of the embodiments of this application, a control system is also provided, which includes at least: a cloud device and a client device, wherein the cloud device is configured to acquire multiple first routing pages of a target application before repair and multiple second routing pages after repair; determine a first fingerprint of each first routing page and a second fingerprint of each second routing page, and determine at least one repaired routing page of the target application based on the first fingerprint and the second fingerprint; determine patch metadata and patch policies of each repaired routing page, and form a patch description file of the target application by the patch metadata and patch policies of at least one repaired routing page; the client device is configured to acquire the patch description file of the target application from the cloud device, wherein the patch description file includes patch metadata and patch policies of at least one repaired routing page of the target application; verify the patch description file, and if the verification passes, store the patch description file in a preset database; and in response to a routing jump event of the target application triggered by a target object, search the preset database for a target patch policy of the target routing page corresponding to the routing jump event, and determine the final routing page based on the search results.

[0019] In this embodiment, a patch description file for the target application is obtained, which includes patch metadata and patch policies corresponding to at least one repaired route page of the target application. The patch description file is verified, and if the verification passes, it is stored in a preset database. In response to a route jump request triggered by the target object, the preset database is searched to determine whether a target patch policy exists for the target route page corresponding to the route jump event, whether the target route page has been repaired, and the final route page is determined based on the search results. By intelligently determining whether to use the original target route page or the hot-fixed Web route page, precise page-level repair is achieved, avoiding redundant resource loading, improving the efficiency of hot-fix and user experience. At the same time, it also ensures the consistency and smoothness of jumping between the original target route page and the Web route page, thereby reducing operation and maintenance costs, improving business iteration flexibility, and enhancing user experience. This solves the technical problem that related page jump control technologies cannot handle mixed navigation flows, resulting in inconsistent navigation and poor customer experience. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a flowchart illustrating an optional page navigation control method according to an embodiment of this application;

[0022] Figure 2 This is a comparative diagram of the route page lists before and after the repair of an optional application according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the dependency tree of an optional routing page according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram illustrating the principle of determining an optional repair route page according to an embodiment of this application;

[0025] Figure 5 This is a flowchart illustrating an optional application patch description file generation method according to an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of the workflow of an optional Web dynamic view container according to an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of an optional control system according to an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the hardware structure of an electronic device for implementing a page jump control method or an application patch description file generation method according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] To better understand the embodiments of this application, the following is a translation and explanation of some nouns or terms that appear in the description of the embodiments of this application:

[0032] Dart is an object-oriented, type-safe programming language designed by Google, primarily used for building high-performance web and mobile applications. Dart is a programming language suitable for both web development and efficient operation on modern hardware. It supports static type checking while also possessing the flexibility of dynamic languages. Dart compiles to high-performance JavaScript code that can run directly on the Dart virtual machine, providing developers with an efficient development experience and high runtime efficiency.

[0033] Hash operations are a common data processing method in computer science, primarily used to convert input data of arbitrary length (usually called a "message") into a fixed-length output (usually called a "hash value" or "digest"). This conversion process is performed by an algorithm called a hash function.

[0034] MD5 (Message Digest Algorithm 5) encryption algorithm: It is a commonly used cryptographic hash function that can calculate a fixed-length hash value from input data of arbitrary length. It is often used for verifying the integrity of transmitted data.

[0035] The Diff algorithm (Difference Algorithm) is a specialized algorithm used to compare the differences between two files or text sequences and generate a "difference" file describing these differences. Its core principle is to identify the common subsequences in two files or sequences and locate the differences based on these common subsequences. It is widely used in software development, version control systems, file merging and comparison, and many other fields.

[0036] Example 1

[0037] According to an embodiment of this application, a page navigation control method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0038] Figure 1 This is a flowchart illustrating a page navigation control method according to an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps:

[0039] Step S102: Obtain the patch description file of the target application, wherein the patch description file includes patch metadata and patch policy corresponding to at least one repair route page of the target application.

[0040] Step S104: Verify the patch description file, and if the verification passes, store the patch description file in the preset database;

[0041] Step S106: In response to the route jump event of the target application triggered by the target object, search the preset database to see if there is a target patch policy for the target route page corresponding to the route jump event, and determine the final route page based on the search results.

[0042] Based on the solution defined in steps S102 to S106 above, it can be understood that in this embodiment, the client device intelligently determines whether to use the application's native target routing page or the hot-fixed Web routing page, thereby achieving precise page-level repair. This avoids redundant resource loading, improves the efficiency of hot-fixing and user experience, and ensures consistency and smoothness when jumping between the native target routing page and the Web routing page. This achieves the goals of reducing operational costs, improving business iteration flexibility, and enhancing user experience. Furthermore, it solves the technical problem that related page jump control technologies cannot handle mixed navigation flows, leading to inconsistent navigation and poor customer experience.

[0043] The following section explains each step of the page redirection control method in conjunction with the specific implementation process.

[0044] In the technical solution provided in step S102 above, the client device can obtain the patch description file of the target application from the cloud device. The cloud device is a server cluster that provides the patch description file, which includes, but is not limited to, a distributed storage system of a cloud service provider, a self-built CDN (Content Delivery Network), or a hot update service backend specifically designed for mobile application operation and maintenance. The target application refers to a mobile application that has undergone hot patching, which includes, but is not limited to, applications developed based on the Flutter framework.

[0045] In addition, the patch description file mentioned above is a comprehensive description of all the repaired route pages in the target application, including the patch metadata and patch policy corresponding to the repaired route page. The patch metadata includes, but is not limited to, key parameters such as the patch package download link, the route identifier of the route to which the patch belongs, and the version number; while the patch policy is a set of rules that control the scope and time of patch effectiveness.

[0046] Optionally, the cloud device can obtain the patch description file for the target application as follows: determine the first fingerprint of each of the multiple first routing pages of the target application before the repair and the second fingerprint of each of the multiple second routing pages after the repair, and determine at least one repaired routing page of the target application based on the first fingerprint and the second fingerprint, and summarize the patch metadata and patch strategy of each repaired routing page.

[0047] Specifically, the process of generating patch description files for target applications on cloud devices involves the following steps:

[0048] Step S1: Parse the code of the target application before and after the repair to obtain multiple first route pages of the target application before the repair and multiple second route pages after the repair.

[0049] For example, by parsing the code of a new version v1.1 of an application that has been bug-fixed and has added new features, and comparing it with the base version v1.0, we can obtain their respective list of route pages, such as... Figure 2 As shown, they are denoted as R_v1 and R_v0 respectively. R_v0 includes multiple first route pages of the application before the repair, and R_v1 records multiple second route pages of the application after the repair.

[0050] Step S2: Determine the first fingerprint of each first routing page and the second fingerprint of each second routing page.

[0051] The determination of the fingerprints for each of the aforementioned route pages can be implemented as follows: Determine the multiple associated files of the route page and the dependencies between these files. The associated files can be of at least one of the following types: source code files or static resource files. Dependencies can be of at least one of the following types: import relationships or reference relationships. Treat each associated file as a tree node, determine the hierarchy between the corresponding tree nodes based on the dependencies, and construct the dependency tree for the route page. Calculate the hash value of the associated file corresponding to each tree node in the dependency tree, and determine the fingerprint of the route page based on the hash values ​​of all tree nodes in the dependency tree.

[0052] The dependency tree described above can be understood as the collection of all Dart source code files and their referenced static resource files (such as images, configuration files, font files, etc.) that the routing page directly and indirectly depends on during normal operation. This tree structure reflects the static reference relationships between the page and its code and resources. Therefore, the dependency tree of a routing page is the minimum complete set of files required for its compilation and rendering.

[0053] For example, Figure 3 This is a diagram illustrating the dependency tree of an optional route page, through... Figure 3As can be seen, the dependency tree includes all the files necessary for the corresponding route page to function properly. These files can be obtained by parsing the code of the route page using static analysis tools, and include, but are not limited to: source code files (such as route pages, state management, data models, HTTP (Hypertext Transfer Protocol) client devices, network services, authentication services, basic tool libraries, local storage, page components, utility functions, etc.), static resource files (such as image resources, icon resources, etc.), and configuration files (such as configuration management, etc.). These files form a complex dependency network through their dependencies. Based on the dependency tree, cloud devices can accurately identify related files with dependencies.

[0054] Then, a depth-first, post-order traversal algorithm is used to perform cryptographic operations (such as SHA-256) on the content of each file in the dependency tree (including Dart source files and static resource files). The set of all file paths and their corresponding hash values ​​is used as a unique numerical identifier for the dependency tree in a specific version. Therefore, this fingerprint can quickly and accurately reflect the content of all related files and their dependencies in the dependency tree. Generally, even a small change in the content of any file will cause a drastic change in its hash value, thus generating a completely new fingerprint.

[0055] Step S3: Determine at least one repair route page of the target application based on the first fingerprint and the second fingerprint.

[0056] Specifically, the intersection of multiple first route pages and multiple second route pages is determined, and each route page in the intersection is traversed. If the first fingerprint and the second fingerprint of the current route page are different, the current route page is determined as the modified route page and repair route page of the target application. The difference set obtained by subtracting multiple first route pages from multiple second route pages is determined, and each route page in the difference set is used as the new route page of the target application.

[0057] Continuing with the above Figure 2 Taking the two different versions of the application shown as examples, according to Figure 4The schematic diagram illustrates the determination principle. The target application's repair route pages are determined through the following steps: First, the intersection of route page lists R_v1 and R_v0 is determined. Then, it is determined whether the first fingerprint before repair and the second fingerprint after repair are the same for route pages B, C, and D within the intersection. If the two fingerprints differ, it indicates that at least one of the following information about the route page has changed: code, web resources, or dependent static file content. Therefore, since route pages B and C have the same two fingerprints, while route page D has different fingerprints, the cloud device can consider route page D as the changed route page for the application. Simultaneously, the cloud device can determine the difference between R_v1 and R_v0. Route page E in this difference set exists only in R_v1; therefore, route page E is a newly added route page for the application. Thus, the repair route pages for the application can be determined as route pages D and E.

[0058] It's important to note that the difference between the route page list R_v1 and the route page list R_v0 also includes the deleted route page A. The deleted route page A is not considered a repairable route page because: if a route page in the application is deleted, and the deleted route page is part of the navigation chain for other route pages, it inevitably involves changes to the navigation logic of those other route pages. Therefore, only the route page whose navigation logic has changed needs to be considered; no additional processing or compensation measures are required for the deleted page. Conversely, if a route page in the application is deleted, but the deletion does not cause any adjustments to the navigation logic of other route pages (i.e., there are no navigation instructions pointing to the deleted route in the code of other route pages), this indicates that the route page may have originally been a redundant page route. Its removal has no substantial impact on the overall application functionality and user navigation path; therefore, no additional processing or compensation measures are needed for it either.

[0059] Step S4: Determine the patch metadata and patch policy for each repair route page, and form a patch description file for the target application from the patch metadata and patch policy of at least one repair route page.

[0060] Specifically, for each patch route page, the cloud device can determine its patch metadata and patch strategy using the following method:

[0061] First, determine the page type of the current route repair page.

[0062] When the page type of the repaired routing page is a change routing page, obtain the policy content of the repaired routing page, and at least use the policy content and the routing identifier of the repaired routing page as the patch policy of the repaired routing page; compile multiple associated files of the repaired routing page before repair into a baseline package, and compile multiple associated files of the repaired routing page after repair into a target package, calculate the difference between the baseline package and the target package using a differential algorithm to obtain a differential package; encrypt the baseline package to obtain a first encryption result, and encrypt the differential package to obtain a second encryption result; at least use the first download address of the baseline package of the repaired routing page, the first encryption result, the second download address of the differential package, and the second encryption result as the patch metadata of the repaired routing page.

[0063] If the page type of the repaired routing page is a new routing page, obtain the policy content of the repaired routing page, and at least use the policy content and the routing identifier of the repaired routing page as the patch policy of the repaired routing page; compile the associated files of the repaired routing page into a differential package, encrypt the differential package to obtain a second encryption result, and at least use the second download address and the second encryption result of the differential package of the repaired routing page as the patch metadata of the repaired routing page.

[0064] It should be noted that the above patching strategy includes at least one of the following: policy identifier, whether it is enabled, the route identifier of the corresponding route page, policy content, etc. The policy content includes, but is not limited to, grayscale percentage (i.e., determining that the patching strategy can only take effect on a specific user type; specifically, by performing a hash modulo operation on the unique identifier of the customer to obtain a certain bucket value between 0 and 99, the patching strategy can only take effect when the value is less than this grayscale percentage), user group (i.e., determining that the patching strategy can only take effect on a specific user type), and the start and end time of the patch (i.e., determining that the patching strategy can only take effect at a specific time), etc.

[0065] In addition, the patch metadata may also include the route identifier of the repair route page (such as the route name, " / d", which is used to provide a basis for client devices to parse the patch description file), the version number of the target application to which the repair route page belongs (used to match different versions of the target application), etc.

[0066] Specifically, during the compilation process described above, the cloud device can use Flutter Web compilation commands to generate a baseline or differential package targeting the entry file of the route page. Additionally, the encryption operation can utilize MD5 encryption or other cryptographic algorithms to encrypt the baseline and / or differential packages, transforming them into an encrypted result of a specific length. This encrypted result is primarily used to verify the integrity of the patch metadata for each repaired route page within the patch description file during transmission, ensuring that the patch description file downloaded by the client device from the cloud device has not suffered any form of damage or tampering during transmission.

[0067] Furthermore, cloud-based devices can encapsulate the patch metadata and patch policies of all the repair route pages referenced by the target application into patch metadata files for each repair route page according to a unified data structure format. These patch metadata files are then integrated as arrays, ensuring that each patch metadata file has its own independent index and location for easy parsing and location. In addition, to enhance the descriptiveness and traceability of the patch description files, a JSON (JavaScript Object Notation) structure can be added outside the array to provide overall descriptive information (such as the patch ID and generation timestamp) for the patch description files, thus forming the patch description file for the target application.

[0068] In the above embodiments, since the differential packet only contains the parts of the repair route page that have actually been modified, the size of the patch description file is greatly reduced. For cloud devices, this significantly reduces the bandwidth consumption of the server sending the patch description file, alleviating server pressure and helping to improve the overall service response speed and stability. For client devices, the time and bandwidth required to download the patch description file are greatly reduced, and the storage resources on client devices will not be excessively occupied due to frequent full downloads, which helps to improve the overall user experience of the application.

[0069] In the technical solution provided in step S104 above, after the client device downloads the patch description file from the cloud device, it can store the downloaded patch description file in the private directory of the target application locally for subsequent parsing operations. Furthermore, the client device can load the patch description file in this private directory into its runtime memory and verify the patch metadata corresponding to each repair route page within the patch description file to ensure that the patch is not tampered with or maliciously attacked during transmission, thereby improving the stability of the target application and the security of user data.

[0070] As an optional implementation, the client device can verify the patch metadata corresponding to each repair route page carried in the patch description file by following these steps:

[0071] Step 1: Determine the page type of the current route repair page. The page type includes at least one of the following: add route page, change route page;

[0072] Step 2: If the current repair route page is a change route page, verify the patch metadata of the current repair route page based on the baseline packet and differential packet of the current repair route page.

[0073] Optionally, the client device may verify the patch metadata of the modified routing page according to the following rules: obtain the baseline packet of the current repaired routing page based on the first download address, and obtain the differential packet of the current repaired routing page based on the second download address; encrypt the baseline packet of the current repaired routing page to obtain a third encryption result, and encrypt the differential packet of the current repaired routing page to obtain a fourth encryption result; determine whether the first encryption result and the third encryption result are the same, and determine whether the second encryption result and the fourth encryption result are the same; if the first encryption result and the third encryption result are the same, and the second encryption result and the fourth encryption result are the same, determine that the patch metadata of the current repaired routing page has passed the verification; if the first encryption result and the third encryption result are different and / or the second encryption result and the fourth encryption result are different, determine that the patch metadata of the current repaired routing page has failed the verification.

[0074] Step 3: If the current repair route page is a new route page, verify the patch metadata of the current repair route page based on the differential packet of the current repair route page.

[0075] Optionally, the client device may verify the patch metadata of the newly added route page according to the following rules: obtain the differential packet of the current repair route page based on the second download address; encrypt the differential packet of the current repair route page to obtain a fourth encryption result; determine whether the second encryption result and the fourth encryption result are the same; if the second encryption result and the fourth encryption result are the same, determine that the patch metadata of the current repair route page has passed the verification; if the second encryption result and the fourth encryption result are different, determine that the patch metadata of the current repair route page has failed the verification.

[0076] When encrypting the differential packet and / or baseline packet of the current repair route page, the MD5 encryption algorithm or other cryptographic algorithms can also be used to perform encryption calculations on the differential packet and / or baseline packet of the current repair route page to convert it into an encrypted result of a specific length.

[0077] It should be noted that patch description files typically also include version information of the target application (such as version number, version identifier, etc.). Therefore, before verifying the patch metadata of each repair route page in the patch description file, the client device can first determine whether the version information of the target application carried in the patch description file is consistent with the version information of the target application it uses. If they are inconsistent, the verification will fail directly, and there is no need to perform subsequent verification of patch metadata. If they are consistent, then the subsequent verification of patch metadata will continue.

[0078] It should also be noted that once a certain version of the application is released, the code for all its corresponding route pages is fixed. Therefore, the client device can only download the corresponding baseline package or differential package once based on the first download address of the baseline package or the second download address of the differential package. Furthermore, for newly added route pages resulting from code modifications, there is no baseline package, only the differential package.

[0079] Specifically, after the above-mentioned version information, patch metadata and other verification operations, the patch metadata of repair route pages that fail verification can be intercepted, and the patch metadata of repair route pages that pass verification and the corresponding patch policies can be stored in a local preset database. This allows a fast, secure and consistent decision database (such as a local disk) to be created on the client device, so as to support the client device to execute page-level hotfix policies in real time and accurately without relying on the network.

[0080] Furthermore, the content of these route repair pages stored in the default database varies depending on the type of the repair page. Specifically:

[0081] For each repair route page that passes the verification, first determine the page type of the current repair route page.

[0082] If the current repair route page is a change route page, the baseline packet and differential packet of the current repair route page are merged to obtain the target packet, and the target packet and patch policy of the current repair route page are stored in the preset database.

[0083] If the current repair route page is a new route page, the differential packet of the current repair route page is used as the target packet, and the target packet and patching policy of the current repair route page are stored in the preset database.

[0084] In the above embodiments, for each verified repaired route page, the client device first determines its page type. If it is a modified route page, i.e., a route page that existed in a previous version but has been modified in the current version, the client device can use an efficient comparison algorithm to merge the page's baseline packet (a complete Web resource packet recording the state before repair) and differential packet (a simplified patch packet recording the changes), thereby generating a target packet (also known as a complete packet), which contains complete Web resource information of the state after repair. This accurately reconstructs the state of the repaired page while minimizing the size of the patch data, saving network resources and local storage space. Subsequently, the target packet and its patching strategy for the current repaired route page are stored in a preset database, forming a local policy library that can be quickly accessed and used for decision-making. If it is a newly added route page, i.e., a route page completely added in the current version, the client device directly treats the differential packet as the target packet. This is because the newly added route page does not have a corresponding state in the previous version, so there is no need to compare with the baseline. This simplified processing also reduces the complexity of the client device in processing patches, while ensuring that all newly introduced pages can take effect immediately according to the established patching strategy.

[0085] The client device utilizes the aforementioned differentiated processing flow to store different types of repair route pages. This allows the client device to quickly query and apply the correct patch strategy when a user triggers a route redirection request, avoiding the need to request cloud data for each redirection. This significantly reduces response time and improves navigation smoothness and user experience. Simultaneously, it reduces the impact of network instability on the repair process. Even in situations with poor network quality or no network, the client device can make correct routing decisions based on the local database, ensuring application stability and the security of the repair process. Furthermore, this storage method ensures that the patch metadata and patch strategies received by the client device from the cloud remain consistent throughout the application lifecycle, preventing data version conflicts that may arise from multiple network requests. This avoids inconsistent user experience or functional errors caused by inconsistent strategies.

[0086] In the technical solution provided in step S106 above, the client device, by integrating the navigation listening mechanism of the Flutter framework, can globally capture all route jump events without intruding on business code. Therefore, once the target object triggers a route jump request for the target application, the client device can intercept the route jump event, extract the route identifier of the target route page from the request, and prepare for further strategy retrieval. Then, based on the extracted route identifier, the client device searches the preset database for a target patch strategy for the target route page corresponding to the route jump event, and renders the engine based on the retrieval results, thereby ensuring that the target object can jump to the correct final route page.

[0087] As an optional implementation, the client device can obtain the route redirection event of the target application triggered by the target object in the following way:

[0088] Step 1: Receive the route redirection request initiated by the target object from the target application. The route redirection request carries at least redirection intent information, which includes at least: Uniform Resource Identifier path and parameter information of the target route page.

[0089] The aforementioned Uniform Resource Identifier (URI) path is used to specify the URI path of the complete Web Resource Package for a specific repair route page, which can guide the client device on how to jump to the target route page. The parameter information of the target route page is used to specify additional data for the route jump request, including but not limited to the query string of the URI, the state object passing, and the new object state information (such as page parameters and state identifiers). These parameters are usually added to the URI to distinguish different navigation requests and guide the Web page on how to load and display the page.

[0090] Step 2: Send the redirection intent information in the above-mentioned route redirection request to the Web dynamic view container, and obtain the route redirection event fed back by the Web dynamic view container. The Web dynamic view container is used to map the Uniform Resource Identifier path in the redirection intent information to the route identifier, and to perform format conversion on the parameter information of the target route page to obtain the route redirection event.

[0091] The aforementioned format conversion standardizes the parameter information of the target route page in the received redirection intent information, converting it into a format compatible with Flutter route pages. This conversion process includes, but is not limited to, standardizing the route names of the web page, adjusting the encoding method, and parsing and recombining the route parameter values ​​to form a route redirection event that can be understood by the client device, using the same route page format. Furthermore, the aforementioned route redirection event carries at least the target route identifier of the target route page to which the user is to redirect.

[0092] Specifically, the workflow of the aforementioned Web dynamic view container is as follows: Figure 5 As shown, through Figure 5 The specific workflow of this container is as follows:

[0093] Step 1: Environment initialization and immersive rendering to create a rendering area that is visually indistinguishable from the native page.

[0094] Specifically, this step involves the following steps: During initialization, the container hides its inherent browser UI elements (such as the address bar and toolbar) by configuring the properties of the underlying Web view controls. Simultaneously, the container is set to full-screen display, thus creating a visually clean and immersive rendering context specifically designed to host and present Web-formatted interface content.

[0095] Step 2: Load and render the target packages of each route page in the target application into the above environment.

[0096] Specifically, this step involves the following steps: The container receives instructions from a route guard on the client device, which contain route identifiers for all route pages of the target application. Using these route identifiers, the container can locate the corresponding target package from a local pre-defined database. Subsequently, the container instructs the web view control to load the target package's entry file from the local file system and complete the rendering.

[0097] The third step is to establish a communication and control bridge to create a two-way, reliable communication channel between the host environment (Flutter) and the guest environment (Web).

[0098] Specifically, this step involves the container injecting a custom logic script into the context of the Web view. This script is executed after the Web resources are loaded and is used to listen for internal events. The container also registers a message channel through which the script in the Web context can send intercepted events and data to the Flutter layer.

[0099] Step 4: Intercepting and translating internal intents to capture navigation requests initiated within the web page and convert them into standardized routing events.

[0100] Specifically, this step involves the following steps: A script injected via the downlink channel continuously listens for specific interactive events within the web page (such as JavaScript route navigation calls). When such events occur, the script prevents its default behavior (e.g., preventing browser redirection) and sends event information (such as the Uniform Resource Identifier path) to the container via the uplink channel. Upon receiving the information, the container translates it into a standard route redirection event containing the Uniform Resource Identifier path and parameter information.

[0101] Step 5: Forwarding and closing the loop of routing events to integrate local navigation intentions within the Web into the application's global navigation stack management.

[0102] Specifically, this step involves the container forwarding the newly generated route redirection event directly to the route guard on the client device. The route guard doesn't need to know whether the redirection event originated from a user clicking a native button or a link within a web page; it will re-execute the entire decision-making process (querying strategies, checking for gray-scale deployments, etc.) regardless of whether the user clicked a native route page or another web route page.

[0103] Furthermore, since the route redirection event carries at least the target route identifier of the target route page, the route guard in the client device can search the preset database to see if there is a target patch policy for the target route page corresponding to the route redirection request, and determine the final route page based on the search results:

[0104] Step 1: Retrieve from the pre-set database based on the target route identifier of the target route page. In other words, the client device uses the target route identifier of the target route page as the key to quickly search its local pre-set database for a corresponding patch policy. This ensures that the policy is implemented at the page level, avoiding global application or mismatches.

[0105] Step 2: If the search results are not empty, first determine the target patch policy containing the target route identifier. It should be noted that at this time, the client device does not directly apply the target patch policy containing the target route identifier, but determines whether the target patch policy meets the preset policy activation conditions. The policy activation conditions include at least one of the following: activation time, activation object category.

[0106] Considering that the effectiveness of a target patch policy requires certain conditions, such as effective time and target object category, the effective time can be understood as determining whether the current local time is within the effective window specified by the target patch policy. The target object category verifies whether the target object belongs to a preset category group, such as a grayscale group, enabling precise targeting based on user profiles. By comprehensively judging these effectiveness conditions, client devices can intelligently determine when, where, and which users to repair routing pages, minimizing the impact of routing page repair on normal user experience while improving the efficiency of routing page repair.

[0107] The third step is to render the target packet corresponding to the target route identifier in the preset database, provided that the target patch policy meets the policy activation conditions, and obtain the final route page (i.e., the Web route page) to achieve a "hotfix experience".

[0108] Specifically, the client device can use the Web dynamic view container to load the target package corresponding to the target route identifier in the preset database, parse the target package corresponding to the target route identifier to obtain script code, execute the script code, complete the above rendering operation, and obtain the final route page. The Web dynamic view container is configured with underlying Web view control properties that can be used to hide the inherent browser UI (User Interface) elements of the target package (such as the address bar, toolbar, etc.), while also setting the route page to full-screen display, providing the target package with a full-screen rendering environment visually indistinguishable from the native page.

[0109] Step 4: If the search results are empty or the target patch policy does not meet the policy's effective conditions, the target route page is determined as the final route page. An empty search result indicates that the page has not been covered by any hotfix policy. In this case, the client device determines the target route page as the final route page, automatically adopting the "no patch equals stability" security principle and directly loading the native target route page to ensure zero-risk operation of basic functions. If the target patch policy does not meet the policy's effective conditions, the client device can only fall back to the native target route page, ensuring stable state priority and achieving "automatic degradation upon failure."

[0110] The beneficial effects of the above technical solution will be illustrated by the following example:

[0111] For example, during the lifecycle of a hotfix patch, two core requirements need to be addressed: the ability to instantly circuit breakers for online issues and the ability to automatically go online and offline at scheduled times for events and other scenarios. Both require extremely high timeliness and determinism to avoid delays or errors caused by human intervention.

[0112] Traditional emergency rollback methods typically require repackaging the emergency version and pushing users to upgrade, resulting in a lengthy process, noticeable user impact, and uncontrollable losses. Traditional scheduled methods, on the other hand, rely on manual operation by developers or complex maintenance scripts, making them susceptible to human error and unable to guarantee precise switching across all client devices at the same time.

[0113] However, the technical solution provided in this application allows all client devices across the network to bypass the patch and downgrade to the stable version immediately when accessing the route within minutes or even seconds by setting the enable switch in the patch policy to false and issuing the patch. This achieves instantaneous damage mitigation. Furthermore, by setting the patch start and end times in the patch policy, client devices can automatically determine the correct version based on their local time, without cloud intervention. This ensures that all users automatically see the correct version of the activity page when accessing the site at the specified time and automatically revert to the original version after the activity ends. This provides the highest level of security and operational automation for hotfixes on client devices. It enables second-level global rollback, minimizing the impact of online incidents, and allows for unattended feature releases, significantly reducing maintenance costs and operational risks. It is particularly suitable for operational activities and emergency fault handling with extremely high timeliness and deterministic requirements.

[0114] In the above embodiments, a complete closed loop is achieved through bidirectional paths. Either the repair route page is enabled, or the original target route page is safely rolled back without any intermediate state. This completely eliminates the risks of "version repair" or "abnormal rendering" and realizes intelligent page version management that is "strategic in repair, controlled in execution, and guaranteed in failure".

[0115] In summary, the page navigation control method in this embodiment differs from existing methods in the following technical advantages:

[0116] (1) By verifying the integrity and legality of the patch description file, we ensure that only trusted patches are loaded, forming a security fallback at the client device level to prevent malicious or corrupted patches from affecting application stability.

[0117] (2) By persisting the patch policy locally to the preset database, the decision of the route jump event does not need to request the cloud device in real time, realizing millisecond-level policy matching, which significantly improves the jump response speed and user experience smoothness.

[0118] (3) Use the Web dynamic view container to capture and process all route jump events initiated by the target object, and query the patch policy in the preset database. Make real-time decisions based on the patch policy (such as whether it is enabled, gray-scale rules, user attributes, time conditions) to determine whether the current jump should point to the native route page or the repaired Web route page, thereby maintaining the consistency of the navigation stack and making the management of the hybrid navigation flow simple and efficient. This ensures that the jump request can be seamlessly connected regardless of whether it points to the native route page or the repaired Web route page, providing users with a smooth navigation experience that is no different from that of pure native applications.

[0119] Example 2

[0120] Currently, the relevant hotfix technology involves completely replacing the problematic native routing page with a Flutter Web routing page compiled from Dart, achieving degradation repair through route scheduling. In practice, this solution adopts a "baseline package + differential package" model, that is, by comparing the file system differences between the old and new complete application versions, an incremental patch package is generated to update resources. However, this method still has the following drawbacks:

[0121] (1) The above-mentioned repair scheme is based on the difference comparison of the entire application's file system. Although the generated patch package is named "incremental", it is actually based on files as the smallest unit. This means that even if only one method in a certain underlying utility class is modified, as long as the file changes, the entire file will be included in the patch package. More importantly, this scheme cannot accurately identify which specific upper-level business pages are affected by this modification, which may result in the patch package containing a large number of redundant page resources that are not affected by this modification, causing a waste of network traffic and a reduction in update efficiency.

[0122] (2) Because the above solution relies on a simple comparison of the file system rather than a deep analysis of code semantics and dependencies, it cannot achieve true accuracy. For example, when a public library is modified, the solution cannot automatically and accurately deduce the set of affected business pages, but instead relies on a full or partial resource update.

[0123] To address the aforementioned issues, this application also provides a method for generating application patch description files. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0124] Figure 6 This is a flowchart illustrating an optional application patch description file generation method according to an embodiment of this application, such as... Figure 6 As shown, the method includes at least steps S602-S606, wherein:

[0125] Step S602: Obtain multiple first route pages of the target application before the repair and multiple second route pages after the repair;

[0126] Step S604: Determine the first fingerprint of each first routing page and the second fingerprint of each second routing page respectively, and determine at least one repair routing page of the target application based on the first fingerprint and the second fingerprint.

[0127] Step S606: Determine the patch metadata and patch policy of each repair route page, and form a patch description file for the target application by the patch metadata and patch policy of at least one repair route page.

[0128] Based on the solution defined in steps S602 to S606 above, it can be understood that in this embodiment of the application, the cloud device overcomes the problems of coarse change granularity and high resource redundancy in traditional hot repair technology by accurately identifying the repair route page of the target application; by determining the patch metadata and patch strategy of each repair route page and integrating them into the patch description file of the target application, it realizes accurate management of the repair route page, thereby solving the technical problems of coarse repair granularity and high resource redundancy in related hot repair technologies.

[0129] The following section explains each step of the application patch description file generation method in conjunction with a specific implementation process.

[0130] In the technical solution provided in step S602 above, the cloud device can use the Dart static analysis tool to parse the code of the target application before and after the repair, and obtain multiple first route pages of the target application before the repair and multiple second route pages after the repair.

[0131] In the technical solution provided in step S604 above, for each of the multiple first routing pages and multiple second routing pages, the cloud device can determine the fingerprint of the first routing page (including the first fingerprint of the first routing page or the second fingerprint of the second routing page) according to the following method:

[0132] Step 1: Determine the multiple associated files of the route page and the dependencies between them. The types of associated files include at least one of the following: source code files and static resource files. The dependencies include at least one of the following: import relationship and reference relationship.

[0133] Step 2: Treat each associated file as a tree node, determine the hierarchy between the corresponding tree nodes based on the dependency relationship, and build the dependency tree of the route page;

[0134] Step 3: Calculate the hash value of the associated file corresponding to each tree node in the dependency tree in turn, and determine the fingerprint of the route page based on the hash value of all tree nodes in the dependency tree.

[0135] Specifically, regarding the technical solution provided in step three above, the cloud device can use a depth-first, post-order traversal algorithm to calculate the hash values ​​of all nodes in the dependency tree, and aggregate these hash values ​​to generate a fingerprint representing all file content and dependencies of the route page under a specific version. This fingerprint is a comprehensive identifier of the dependency tree, which can quickly and accurately reflect the content of all related files and dependencies in the dependency tree.

[0136] In the technical solution provided in step S606 above, the cloud device can determine at least one repair route page of the target application based on the first fingerprint and the second fingerprint in the following way: determine the intersection of multiple first route pages and multiple second route pages, and traverse each route page in the intersection. If the first fingerprint and the second fingerprint of the current route page are different, determine the current route page as the change route page repair route page of the target application; determine the difference set obtained by subtracting multiple first route pages from multiple second route pages, and take each route page in the difference set as the new route page of the target application.

[0137] It's important to note that the difference set between multiple first-route pages and multiple second-route pages also includes deleted route pages. Deleted route pages are not considered part of the target application's repair route pages because: if a route page in the application is deleted, and that deleted route page is a link in the navigation chain of other route pages, it inevitably involves changes to the navigation logic of those other route pages. Therefore, only the route page whose navigation logic has changed needs to be considered; no additional processing or compensation measures are required for the deleted page. Conversely, if a route page in the application is deleted, but the deletion does not cause any adjustments to the navigation logic of any other route pages (i.e., there are no navigation instructions pointing to the deleted route in the code of other route pages), this indicates that the route page may have originally been a redundant page route. Its removal has no substantial impact on the overall application functionality and user navigation path; therefore, no additional processing or compensation measures are needed for it either.

[0138] Furthermore, cloud devices can determine the patch metadata and patching strategies for each patching route page using the following methods:

[0139] First, determine the page type of the current route repair page.

[0140] When the page type of the repaired routing page is a change routing page, obtain the policy content of the repaired routing page, and at least use the policy content and the routing identifier of the repaired routing page as the patch policy of the repaired routing page; compile multiple associated files of the repaired routing page before repair into a baseline package, and compile multiple associated files of the repaired routing page after repair into a target package, calculate the difference between the baseline package and the target package using a differential algorithm to obtain a differential package; encrypt the baseline package to obtain a first encryption result, and encrypt the differential package to obtain a second encryption result; at least use the first download address of the baseline package of the repaired routing page, the first encryption result, the second download address of the differential package, and the second encryption result as the patch metadata of the repaired routing page.

[0141] If the page type of the repaired routing page is a new routing page, obtain the policy content of the repaired routing page, and at least use the policy content and the routing identifier of the repaired routing page as the patch policy of the repaired routing page; compile the associated files of the repaired routing page into a differential package, encrypt the differential package to obtain a second encryption result, and at least use the second download address and the second encryption result of the differential package of the repaired routing page as the patch metadata of the repaired routing page.

[0142] In addition, the patch metadata may also include the route identifier (such as the route name, " / d") of the repair route page, the version number of the target application to which the repair route page belongs, etc.

[0143] Finally, the cloud device can encapsulate the patch metadata and patch policies of all the repair route pages referenced by the target into patch metadata files for each repair route page according to a unified data structure format. These patch metadata files are then integrated as an array, ensuring that each patch metadata file has its own independent index and location for easy parsing and location. Furthermore, to enhance the descriptiveness and traceability of the patch description files, a JSON structure is encapsulated outside the array to add overall descriptive information (such as patch version, generation timestamp, and overall policy description) to the patch description files, thus forming the patch description file for the target application.

[0144] The beneficial effects of the application patch file generation method provided in this application embodiment will be illustrated below with the following examples:

[0145] For example, before a critical event, a large app might have six developers optimize six routing pages, preventing any impact on other parts of the app. The application patch file generation method provided in this application first compares the fingerprints of each routing page before and after the fix, accurately identifying the six routing pages affected by code or resource modifications. This ensures that subsequent fixes are limited to the parts that truly need updating, improving the accuracy of hotfixes. Furthermore, this method can generate page-level patch description files containing only these six routing pages, avoiding the technical problems of large patch description file sizes and low update efficiency caused by full or file-level comparisons. It achieves page-level incremental updates, avoiding the distribution and loading of redundant resources, significantly saving user traffic and server bandwidth, and improving the overall efficiency of hotfixes.

[0146] For example, after patching an overheating fix for a critical function (such as a new payment process) or a UI redesign (such as a product details page reconstruction), a safe and controllable method is needed to gradually expand the user experience and to target it precisely based on user value or business attributes.

[0147] Traditional canary releases typically rely on backend API configurations or release channel controls, making precise binding with frontend routing pages impossible. This means patch strategies often require repackaging or depend on complex server-side logic, resulting in long change cycles and difficulty in achieving fine-grained targeting at the user profile level (e.g., targeting only VIP users). Rollback operations are equally cumbersome, failing to achieve near-instantaneous effects.

[0148] The technical solution provided in this application ensures that all patch policies (grayscale ratio, target user segmentation, effective time, etc.) are dynamically deployable configurations and bound to specific route patch metadata. This allows operations personnel to update policy fields on cloud devices only, while client devices silently update and immediately implement the policies during the next detection. This enables seamless, real-time execution of refined release processes such as "small-scale verification -> expanded grayscale -> full release" or "internal testing users -> core users -> full users." This achieves seamless, second-level effective incremental release and precise operation, making feature releases as smooth and controllable as turning a knob. It allows for rapid data-driven verification and adjustment, significantly reducing the risk of new feature launches and supporting refined operational strategies based on user segmentation.

[0149] Example 3

[0150] According to embodiments of this application, a control system is also provided, such as... Figure 7 As shown, the control system includes at least: a cloud device 71 and a client device 72, wherein:

[0151] Cloud device 71 is used to obtain multiple first routing pages of the target application before repair and multiple second routing pages after repair; determine the first fingerprint of each first routing page and the second fingerprint of each second routing page respectively, and determine at least one repaired routing page of the target application based on the first fingerprint and the second fingerprint; determine the patch metadata and patch policy of each repaired routing page, and form a patch description file of the target application by the patch metadata and patch policy of at least one repaired routing page.

[0152] Client device 72 is used to obtain a patch description file of the target application from cloud device 71, wherein the patch description file includes patch metadata and patch policy for at least one patched route page of the target application; verify the patch description file, and if the verification passes, store the patch description file in a preset database; in response to a route jump event of the target application triggered by the target object, search the preset database to see if there is a target patch policy for the target route page corresponding to the route jump event, and determine the final route page based on the search results.

[0153] It should be noted that each module in the control system of this application corresponds one-to-one with each implementation step of Embodiment 1 and Embodiment 2. Some details not shown in this embodiment can be referred to Embodiment 1 and Embodiment 2, and will not be elaborated further here.

[0154] Example 4

[0155] According to an embodiment of this application, a computer program product is also provided, which includes a computer program, wherein when the computer program is executed by a processor, it implements the page jump control method in embodiment 1 or the application patch file generation method in embodiment 2.

[0156] According to an embodiment of this application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the page jump control method in Embodiment 1 or the application patch file generation method in Embodiment 2 by running the computer program.

[0157] According to an embodiment of this application, a processor is also provided for running a computer program, wherein the computer program executes the page jump control method in embodiment 1 or the application patch file generation method in embodiment 2 during runtime.

[0158] According to an embodiment of this application, an electronic device is also provided, comprising: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the page jump control method in Embodiment 1 or the application patch file generation method in Embodiment 2 through the computer program.

[0159] Optionally, the computer program executes the following steps during runtime: obtaining a patch description file for the target application, wherein the patch description file includes patch metadata and patch policy corresponding to at least one patched route page of the target application; verifying the patch description file, and storing the patch description file in a preset database if the verification passes; responding to a route redirection request triggered by the target object, searching the preset database for a target patch policy for the target route page corresponding to the route redirection event, and determining the final route page based on the search results.

[0160] Optionally, the computer program executes the following steps during runtime: obtaining multiple first routing pages of the target application before repair and multiple second routing pages after repair; determining the first fingerprint of each first routing page and the second fingerprint of each second routing page, and determining at least one repaired routing page of the target application based on the first and second fingerprints; determining the patch metadata and patch policy of each repaired routing page, and forming a patch description file of the target application from the patch metadata and patch policy of at least one repaired routing page.

[0161] As an alternative implementation, the above-mentioned electronic device may exist in the form of a mobile terminal, a computer terminal, or a similar computing device. Figure 8 A hardware block diagram of an electronic device for implementing a page navigation control method or an application patch file generation method is shown. Figure 8 As shown, the electronic device 80 may include one or more processors 802 (shown as 802a, 802b, ..., 802n in the figure) 802 (processor 802 may include, but is not limited to, a processing device such as a microprocessor or programmable logic device), a memory 804 for storing data, and a transmission device 806 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 8 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, electronic device 80 may also include components that are more... Figure 8 The more or fewer components shown, or having the same Figure 8 The different configurations shown.

[0162] It should be noted that the aforementioned one or more processors 802 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element of the electronic device 80. As involved in the embodiments of this application, the data processing circuit serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0163] The memory 804 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the page jump control method or application patch file generation method in the embodiments of this application. The processor 802 executes various functional applications and data processing by running the software programs and modules stored in the memory 804, that is, implementing the above-mentioned application page jump control method or application patch file generation method. The memory 804 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 804 may further include memory remotely located relative to the processor 802, and these remote memories can be connected to the electronic device 80 via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0164] The transmission device 806 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 80. In one example, the transmission device 806 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 806 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0165] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows users to interact with the user interface of the electronic device 80.

[0166] The sequence numbers of the above embodiments are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0167] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0168] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0170] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0171] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0172] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A page navigation control method, characterized in that, Applied to client devices, including: Obtain the patch description file of the target application, wherein the patch description file includes patch metadata and patch policy corresponding to at least one repair route page of the target application; The patch description file is verified, and if the verification passes, the patch description file is stored in a preset database; In response to a route redirection event of the target application triggered by the target object, the system searches the preset database to determine whether there is a target patch policy for the target route page corresponding to the route redirection event, and determines the final route page based on the search results.

2. The method according to claim 1, characterized in that, The patch metadata includes at least: a first download address of a baseline packet characterizing the Web resource information of the repaired route page before the repair and a first encryption result of the baseline packet; a second download address of a differential packet characterizing the difference in Web resource information of the repaired route page before and after the repair and a second encryption result of the differential packet; and verification of the patch description file, including: For each of the repaired route pages, determine the page type of the current repaired route page, wherein the page type includes at least one of the following: a new route page, a changed route page; If the page type of the current repair route page is the changed route page, the patch metadata of the current repair route page is verified based on the baseline packet and differential packet of the current repair route page; If the page type of the current repair route page is the newly added route page, the patch metadata of the current repair route page is verified based on the differential packet of the current repair route page.

3. The method according to claim 2, characterized in that, The patch metadata of the current repair route page is verified based on the baseline packet and differential packet of the current repair route page, including: Obtain the baseline packet of the current repair route page based on the first download address, and obtain the differential packet of the current repair route page based on the second download address; The baseline packet of the current repair route page is encrypted to obtain a third encryption result, and the differential packet of the current repair route page is encrypted to obtain a fourth encryption result; Determine whether the first encryption result and the third encryption result are the same, and determine whether the second encryption result and the fourth encryption result are the same; If the first encryption result and the third encryption result are the same, and the second encryption result and the fourth encryption result are the same, then the patch metadata of the current repair route page is determined to have passed the verification. If the first encryption result and the third encryption result are different and / or the second encryption result and the fourth encryption result are different, it is determined that the patch metadata of the current repair route page has failed the verification.

4. The method according to claim 2, characterized in that, The patch metadata of the current repair route page is verified based on the differential packet of the current repair route page, including: Obtain the differential packet of the current repair route page based on the second download address; The differential packets of the current repair route page are encrypted to obtain the fourth encryption result; Determine whether the second encryption result and the fourth encryption result are the same; If the second encryption result and the fourth encryption result are the same, it is determined that the patch metadata of the current repair route page passes the verification. If the second encryption result and the fourth encryption result are different, it is determined that the patch metadata of the current repair route page has failed the verification.

5. The method according to claim 2, characterized in that, Storing the patch description file in a preset database includes: For each of the repaired route pages, determine the page type of the current repaired route page; If the page type of the current repair route page is the changed route page, the baseline packet and differential packet of the current repair route page are merged to obtain the target packet, and the target packet and patch policy of the current repair route page are stored in the preset database. If the page type of the current repair route page is the newly added route page, the differential packet of the current repair route page is used as the target packet, and the target packet and patch policy of the current repair route page are stored in the preset database.

6. The method according to claim 1, characterized in that, A route redirection event of the target application triggered by the target object includes: Receive a route redirection request initiated by the target object from the target application, wherein the route redirection request carries at least redirection intent information, and the redirection intent information includes at least: a Uniform Resource Identifier path and parameter information of the target route page; The redirection intent information in the route redirection request is sent to the Web Dynamic View Container, and the route redirection event fed back by the Web Dynamic View Container is obtained. The Web Dynamic View Container is used to map the Uniform Resource Identifier path in the redirection intent information to a route identifier, and to perform format conversion on the parameter information of the target route page to obtain the route redirection event.

7. The method according to claim 5, characterized in that, The route redirection event carries at least the target route identifier of the target route page; The process includes retrieving from the preset database whether a target patch policy exists for the target route page corresponding to the route redirection event, and determining the final route page based on the retrieval results, including: The target route identifier of the target route page is used to retrieve the route from the preset database; If the search results are empty, the target route page is determined to be the final route page; If the search result is not empty, a target patch policy containing the target route identifier is determined, and it is determined whether the target patch policy meets the preset policy activation conditions. The policy activation conditions include at least one of the following: activation time, activation object category. If the target patching policy meets the policy activation conditions, the target packet corresponding to the target route identifier in the preset database is rendered to obtain the final route page; If the target patch policy does not meet the conditions for the policy to take effect, the final route page is determined to be the target route page.

8. The method according to claim 7, characterized in that, Rendering the target packet corresponding to the target route identifier in the preset database includes: The target packet corresponding to the target route identifier in the preset database is loaded using a Web dynamic view container, and the target packet corresponding to the target route identifier is parsed to obtain script code. The script code is then executed to obtain the final route page.

9. A method for generating application patch files, characterized in that, Applied to cloud devices, including: Retrieve multiple first-route pages of the target application before the fix and multiple second-route pages after the fix; The first fingerprint of each first routing page and the second fingerprint of each second routing page are determined respectively, and at least one repair routing page of the target application is determined based on the first fingerprint and the second fingerprint. The patch metadata and patch policy of each of the repair route pages are determined, and the patch metadata and patch policy of at least one repair route page are used to form the patch description file of the target application.

10. The method according to claim 9, characterized in that, Determine the first fingerprint of each first routing page and the second fingerprint of each second routing page, including: For each route page, the following steps are performed to determine the fingerprint of the route page, wherein the route page includes either the first route page or the second route page, and the fingerprint includes either the first fingerprint of the first route page or the second fingerprint of the second route page: Determine multiple associated files of the route page and the dependencies between the multiple associated files, wherein the types of the associated files include at least one of the following: source code files and static resource files, and the dependencies include at least one of the following: import relationships and reference relationships; Each of the associated files is used as a tree node, and the hierarchy between the corresponding tree nodes is determined according to the dependency relationship to construct the dependency tree of the routing page; The hash values ​​of the associated files corresponding to each tree node in the dependency tree are calculated sequentially, and the fingerprint of the routing page is determined based on the hash values ​​of all tree nodes in the dependency tree.

11. The method according to claim 9, characterized in that, The page type of the route repair page includes at least one of the following: a new route page, a route change page; determining the route repair page of the target application based on the first fingerprint and the second fingerprint includes: Determine the intersection of the plurality of first routing pages and the plurality of second routing pages, and traverse each routing page in the intersection. If the first fingerprint and the second fingerprint of the current routing page are different, determine the current routing page as the changed routing page of the target application. Determine the difference set obtained by subtracting the multiple first route pages from the multiple second route pages, and use each route page in the difference set as a new route page for the target application.

12. The method according to claim 11, characterized in that, The route repair page generates a patch description file based on the route repair page, including: When the page type of the repair route page is the changed route page, the policy content of the repair route page is obtained, and at least the policy content and the route identifier of the repair route page are used as the patch policy of the repair route page; multiple associated files of the repair route page before repair are compiled into a baseline package, and multiple associated files of the repair route page after repair are compiled into a target package; the difference between the baseline package and the target package is calculated using a differential algorithm to obtain a differential package; the baseline package is encrypted to obtain a first encryption result, and the differential package is encrypted to obtain a second encryption result; at least the first download address of the baseline package of the repair route page, the first encryption result, the second download address of the differential package, and the second encryption result are used as the patch metadata of the repair route page; When the page type of the repaired route page is the newly added route page, obtain the policy content of the repaired route page, and at least use the policy content and the route identifier of the repaired route page as the patch policy of the repaired route page; compile the associated files of the repaired route page into a differential package, encrypt the differential package to obtain a second encryption result, and at least use the second download address and the second encryption result of the differential package of the repaired route page as the patch metadata of the repaired route page.

13. A control system, characterized in that, The control system includes at least: a cloud device and a client device, wherein, The cloud device is used to obtain multiple first routing pages of the target application before repair and multiple second routing pages after repair; determine the first fingerprint of each first routing page and the second fingerprint of each second routing page respectively, and determine at least one repaired routing page of the target application based on the first fingerprint and the second fingerprint; determine the patch metadata and patch policy of each repaired routing page, and form the patch description file of the target application by the patch metadata and patch policy of the at least one repaired routing page; The client device is configured to obtain a patch description file for the target application from the cloud device, wherein the patch description file includes patch metadata and patch policies for at least one patched route page of the target application; verify the patch description file, and if the verification passes, store the patch description file in a preset database; in response to a route jump event of the target application triggered by the target object, search the preset database for a target patch policy for the target route page corresponding to the route jump event, and determine the final route page based on the search results.

Images