Hybrid resource update method, electronic device, and program product

Abstract

The present disclosure provides a hybrid resource updating method, an electronic device and a program product. The hybrid resource updating method comprises: receiving a version query request sent by a client, the version query request comprising first version information of a native application and second version information of a page resource; querying, according to the first version information, an application version updating table to determine whether a first target version updating strategy corresponding to the first version information exists, and querying, according to the second version information, a page resource version updating table associated with the application version updating table to determine whether a second target version updating strategy corresponding to the second version information exists; constructing, according to the first target version updating strategy and / or the second target version updating strategy, to obtain a version updating instruction; and sending the version updating instruction to the client, so that the client updates resources according to the version updating instruction.

Description

Technical Field

[0001] This disclosure relates to a hybrid resource update method, electronic device, and program product. Background Technology

[0002] In the field of mobile application development, a hybrid development model combining native applications and web page resources is widely adopted to balance user experience and development efficiency. However, in the current hybrid development model, new versions of web page resources often depend on the support of new versions of the application. If users load new web page resources directly without updating the application, it can easily lead to compatibility issues such as malfunctions or blank screens. On the other hand, application version updates require approval from app stores and manual downloads by users, a lengthy and uncontrollable process. While hot updates of web page resources are fast, the lack of a collaborative management mechanism with application versions leads to a fragmented update process, exacerbating version fragmentation and management chaos. Summary of the Invention

[0003] This disclosure provides a hybrid resource update method, electronic device, and program product.

[0004] According to one aspect of this disclosure, a hybrid resource update method is provided, applied to a server, the hybrid resource update method comprising: Receive a version query request sent by the client, the version query request including the first version information of the native application and the second version information of the page resources; Based on the first version information, a query is performed in the application version update table to determine whether there is a first target version update strategy corresponding to the first version information; and based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether there is a second target version update strategy corresponding to the second version information. The version update instruction is generated by constructing according to the first target version update strategy and / or the second target version update strategy. The version update instruction is sent to the client, causing the client to update the native application and / or the page resources according to the version update instruction.

[0005] According to at least one embodiment of the hybrid resource update method of this disclosure, based on the first version information, a query is performed in the application version update table to determine whether there is a first target version update strategy corresponding to the first version information, including: Based on the first version information, a query is performed in the application version update table to determine whether there is a first version update strategy whose current version number field value is the same as the first version information. If the first version update policy exists, determine whether the first version update policy is enabled; When the first version update strategy is enabled, the first version update strategy is determined to be the first target version update strategy.

[0006] According to at least one embodiment of the hybrid resource update method of this disclosure, based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether a second target version update strategy corresponding to the second version information exists, including: Based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether there is a second version update strategy whose field value of the current resource version number field is the same as the second version information; If the second version update strategy exists, determine whether the second version update strategy is enabled; When the second version update strategy is enabled, the second version update strategy is determined to be the second target version update strategy.

[0007] According to at least one embodiment of the hybrid resource update method of this disclosure, a version update instruction is obtained by constructing a version update instruction based on a first target version update strategy and / or a second target version update strategy, including: If the first target version update strategy exists, the update method, update text and application download address are extracted from the first target version update strategy as application update information; and if the second target version update strategy exists, the module name, page resource download address and integrity verification code are extracted from the second target version update strategy as page resource update information. The application update information and / or the page resource update information are encapsulated to obtain a version update instruction.

[0008] According to at least one embodiment of the hybrid resource update method of this disclosure, the hybrid resource update method further includes: Receive configuration instructions, which are used to modify the field values ​​of the status field in the version update strategy of the application version update table and / or the page resource version update table; According to the configuration instructions, the value of the status field in the corresponding version update strategy is updated to enabled or disabled, thereby controlling the timing of the version update strategy's activation.

[0009] According to one aspect of this disclosure, a hybrid resource update method is also provided, applied to a client, the hybrid resource update method comprising: Generate a version query request, which includes the first version information of the native application and the second version information of the page resources; The version query request is sent to the server, which is used to execute the hybrid resource update method applied to the server as described in any of the above embodiments; Receive version update commands sent by the server; According to the version update instruction, update the resources of the native application and / or page resources.

[0010] According to at least one embodiment of the hybrid resource update method of this disclosure, when updating the resources of the native application according to the version update instruction, the method includes: According to the version update instruction, if the update method is a forced update, a forced update prompt message will be displayed in the interface of the native application, and the continued use of the native application will be prohibited; if the update method is an optional update, an optional update prompt message will be displayed in the interface. In response to the confirmation operation of the forced update prompt or the optional update prompt, the user is redirected to the corresponding download page according to the application download address in the version update instruction; The user obtains the resource package for the updated version of the native application from the download page and completes the resource update.

[0011] According to at least one embodiment of the hybrid resource update method of this disclosure, before displaying the forced update prompt information or the optional update prompt information, the hybrid resource update method further includes: Extract the update text from the version update instruction, the update text including update content or a description of new version features; Based on the update content or new version feature description, generate a forced update prompt message or an optional update prompt message.

[0012] According to at least one embodiment of the hybrid resource update method of this disclosure, when updating the page resources according to the version update instruction, the method includes: Create and execute a background download task based on the page resource download address in the version update instruction to obtain the resource package of the page resource to be updated; Based on the integrity check code in the version update instruction, perform integrity verification on the resource package of the page resource to be updated; If the resource package of the page resource to be updated passes the integrity verification, the stored resource package of the page resource is replaced according to the resource package of the page resource to be updated.

[0013] According to at least one embodiment of the hybrid resource update method of this disclosure, if the resource package of the page resource to be updated fails the integrity verification, the resource package of the page resource to be updated is deleted.

[0014] According to at least one embodiment of the hybrid resource update method of this disclosure, the integrity of the resource package of the version to be updated of the page resource is verified based on the integrity check code in the version update instruction, including: A hash calculation is performed on the resource package of the page resource to be updated to obtain the verification value; Compare the verification value with the integrity check code in the version update instruction; If the verification value is the same as the integrity check code, the resource package of the page resource to be updated is determined to have passed the integrity check; if the verification value is different from the integrity check code, the resource package of the page resource to be updated is determined to have failed the integrity check.

[0015] According to one aspect of this disclosure, a hybrid resource update apparatus is provided for use on a server, comprising: The first receiving module is used to receive a version query request sent by the client, the version query request including the first version information of the native application and the second version information of the page resources; The query module is used to query the application version update table based on the first version information to determine whether there is a first target version update strategy corresponding to the first version information, and to query the page resource version update table associated with the application version update table based on the second version information to determine whether there is a second target version update strategy corresponding to the second version information. The building module is used to build according to the first target version update strategy and / or the second target version update strategy to obtain version update instructions; The first sending module is used to send the version update instruction to the client, so that the client updates the native application and / or the page resources according to the version update instruction.

[0016] According to one aspect of this disclosure, a hybrid resource update apparatus is provided for use on a client, comprising: The generation module is used to generate a version query request, which includes the first version information of the native application and the second version information of the page resources. The second sending module is used to send the version query request to the server, and the server is used to execute the hybrid resource update method applied to the server as described in any of the above embodiments. The second receiving module is used to receive version update instructions sent by the server; The update module is used to update the native application and / or page resources according to the version update instruction.

[0017] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a hybrid resource update method according to any embodiment of this disclosure.

[0018] According to another aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement a hybrid resource update method according to any embodiment of this disclosure.

[0019] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a hybrid resource update method according to any embodiment of this disclosure. Attached Figure Description

[0020] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of a hybrid resource update method according to one embodiment of this disclosure.

[0022] Figure 2 This is a flowchart illustrating a hybrid resource update method according to one embodiment of the present disclosure.

[0023] Figure 3 This is a flowchart illustrating the process of determining a first target version update strategy in a hybrid resource update method according to one embodiment of this disclosure.

[0024] Figure 4 This is a flowchart illustrating the process of determining a second target version update strategy in a hybrid resource update method according to one embodiment of this disclosure.

[0025] Figure 5 This is a flowchart illustrating step S230 of a hybrid resource update method according to one embodiment of the present disclosure.

[0026] Figure 6This is a flowchart illustrating the configuration status field in a hybrid resource update method according to one embodiment of this disclosure.

[0027] Figure 7 This is a flowchart illustrating another embodiment of the hybrid resource update method of this disclosure.

[0028] Figure 8 This is a schematic diagram of the native application update process in a hybrid resource update method according to one embodiment of the present disclosure.

[0029] Figure 9 This is a flowchart illustrating the process of determining update prompt information in a hybrid resource update method according to one embodiment of the present disclosure.

[0030] Figure 10 This is a schematic diagram of the page resource update process in a hybrid resource update method according to one embodiment of the present disclosure.

[0031] Figure 11 This is a flowchart illustrating step S1020 of a hybrid resource update method according to one embodiment of this disclosure.

[0032] Figure 12 This is a schematic diagram of the architecture of a hybrid resource update system according to one embodiment of the present disclosure.

[0033] Figure 13 This is a flowchart illustrating another embodiment of the hybrid resource update method disclosed herein.

[0034] Figure 14 This is a schematic structural block diagram of a hybrid resource update apparatus according to one embodiment of the present disclosure.

[0035] Figure 15 This is a schematic structural block diagram of a hybrid resource update apparatus according to another embodiment of this disclosure.

[0036] Figure 16 This is a schematic structural block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0037] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0038] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0039] Existing technologies lack a unified and dynamic collaborative management mechanism for version updates of native applications and embedded page resources, leading to version mismatches that cause functional compatibility issues and fragmented update processes.

[0040] To this end, this disclosure proposes the following technical solution: the server performs collaborative queries in the interrelated application version update table and page resource version update table based on the version information of the native application and page resources reported by the client, thereby realizing collaborative version management of two different types of resources.

[0041] Furthermore, the server constructs version update instructions based on the query results, which include version update strategies for native applications and / or page resources. This enables the client to execute subsequent update operations according to the unified version update instructions, achieving unified control over the lifecycle of mixed resource updates and avoiding version incompatibility and functional compatibility issues caused by the lack of a collaborative management mechanism.

[0042] Figure 1 This is a schematic diagram illustrating an application scenario of a hybrid resource update method according to one embodiment of this disclosure. For example... Figure 1 As shown, this application scenario may include terminal device 101, network 102, and server 103.

[0043] For example, a client runs on terminal device 101. This client is an application (APP) that integrates an update scheduler. The update scheduler is mainly responsible for collecting the version information of the native application and the version information of each page resource embedded in the native application. When the native application is launched or switched to the foreground (i.e., after minimizing the original application or running the application in the background, and then bringing the application back to the foreground and making it interactive), the update scheduler will generate a version query request based on the collected first version information of the native application and the second version information of the page resources, and send the version query request to server 103 through network 102.

[0044] Server 103 is equipped with a server-side component that can execute the hybrid resource update method for servers provided in this disclosure. For example, the server maintains an interrelated application version update table and a page resource version update table. Upon receiving a version query request from a client, the server can collaboratively query the application version update table and the page resource version update table based on the first version information and the second version information contained in the query request, determine the corresponding version update strategy, and then generate a corresponding version update instruction. The server sends this version update instruction to the client via network 102, enabling the client to update the native application and / or page resources according to the version update instruction.

[0045] Figure 2 This is a flowchart illustrating a hybrid resource update method according to one embodiment of this disclosure. This hybrid resource update method is applied to the server as described above.

[0046] like Figure 2 As shown, the hybrid resource update method may optionally include steps S210 to S240.

[0047] In step S210, a version query request sent by the client is received. The version query request includes the first version information of the native application and the second version information of the page resources.

[0048] In this implementation, when the native application starts or is switched to the foreground, the update scheduler in the client collects the first version information of the native application (such as the version number of the native application) and the second version information (such as the version number of the page resource) of at least one page resource embedded in the native application (such as each dynamically updatable H5 (HTML5) business module inside the native application).

[0049] Next, the update scheduler encapsulates the collected first and second version information according to a pre-defined data format to construct a version query request. The client sends this version query request to the server over the network to inquire whether there are any new version resources (including native application and page resources) available for the client to update.

[0050] Optionally, the version query request may also include the client's platform information (such as iOS or Android). Since the native application distribution channels for iOS and Android platforms differ (such as the Apple App Store and various Android app stores), their version iteration rhythms may be inconsistent, and the compatibility requirements of H5 resource packages may also vary. Therefore, by including platform information in the version query request, the server can configure independent version update strategies for clients on different platforms, avoiding erroneous update issues caused by mixing cross-platform strategies.

[0051] In step S220, based on the first version information, a query is performed in the application version update table to determine whether there is a first target version update strategy corresponding to the first version information; and based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether there is a second target version update strategy corresponding to the second version information.

[0052] The application version update table is used to manage the version update strategy of native applications. Optionally, the application version update table may include at least one or more fields from the following: platform identifier, current version number, next version number, forced update identifier, update text, application download address, and status field.

[0053] The page resource version update table is used to manage the version update strategy for page resources (such as H5 resources). Optionally, the page resource version update table may include at least one or more fields from the following: platform identifier, module name, current resource version number, next resource version number, page resource download address, integrity check code, and status field.

[0054] In this implementation, after receiving a version query request from the client, the server parses the request and extracts the first version information of the native application and the second version information of the page resources. The server then initiates a dual-path query process based on this first and second version information.

[0055] In the first query, the server uses the first version information (which may be combined with the platform identifier) ​​as the query condition to search the application version update table to determine if there is a version update strategy corresponding to the first version information (such as a version update strategy where the current version number field value is the same as the first version information). If it exists, it is identified as the first target version update strategy. If it does not exist, it is determined that there is currently no native application update suitable for this client.

[0056] In the second query, the server uses the second version information (which may be combined with the platform identifier) ​​as the query condition to search the page resource version update table to determine if there is a version update strategy corresponding to the second version information (such as a version update strategy where the current resource version number field value is the same as the second version information). If it exists, it is identified as the second target version update strategy. If it does not exist, it is determined that the current page resource does not need to be updated.

[0057] Optionally, if there are multiple page resources, the version query request can include the module name of each page resource and its corresponding second version information. When performing the query, the server uses the module name and second version information of the page resource as combined query conditions to search the page resource version update table to see if there is a version update strategy with the same module name field value as the module name reported by the client and the same current resource version number field value as the second version information.

[0058] Optionally, when the version query request includes the platform identifier corresponding to the client, the server can perform a combined query (such as based on the platform identifier and the first version information, or based on the platform identifier, the module name, and the second version information) when performing the aforementioned search, so as to find the version update strategy corresponding to the platform identifier and avoid the mixing of cross-platform strategies.

[0059] It should be noted that the related application version update table and page resource version update table described in this disclosure are designed to serve the update needs of the same hybrid application (i.e., the native application and its embedded page resources). They are organized into a unified update logic framework using common fields (such as the platform identifier field). The application version update table and the page resource version update table are independent of each other, but together they provide complete update guidance to the client, achieving a divide-and-conquer yet collaborative management effect for the native application and page resources.

[0060] Please continue to refer to this. Figure 2 In step S230, a version update instruction is obtained by constructing according to the first target version update strategy and / or the second target version update strategy.

[0061] In this implementation, the server constructs a version update instruction according to the first target version update strategy and / or the second target version update strategy obtained from the query, following a pre-defined instruction construction rule. For example, if only the first target version update strategy exists, it means that the page resources do not need to be updated, and the server generates the corresponding version update instruction only according to the first target version update strategy; or, if only the second target version update strategy exists, it means that the native application does not need to be updated, and the server generates the corresponding version update instruction only according to the second target version update strategy; or, if both the first and second target version update strategies exist, it means that both the native application and the page resources need to be updated, and the server generates a unified version update instruction based on both the first and second target version update strategies.

[0062] In this way, the server integrates the first target version update strategy corresponding to the native application and the second target version update strategy corresponding to the page resources into the same version update instruction and returns it to the client. The client only needs to make one query request to obtain the complete update instruction, realizing the collaborative management of the native application and page resources and avoiding version incompatibility and functional compatibility issues.

[0063] In step S240, the version update instruction is sent to the client, causing the client to update the native application and / or the page resources according to the version update instruction.

[0064] In this implementation, the server sends the constructed version update command to the client. The client parses the version update command to determine whether there is a native application update and whether there is a page resource update. If one or both need to be updated, the client updates the corresponding resources (i.e., native application or page resources) according to the update instructions contained in the version update command.

[0065] Optionally, for native applications, resource updates manifest as redirecting users to the app store to download and install the new version; for page resources, resource updates manifest as silently downloading the new version resource package in the background and replacing the old version resources stored locally.

[0066] Thus, in the hybrid resource update method disclosed herein, the server performs collaborative queries in the interrelated application version update table and page resource version update table based on the version information of the native application and page resources reported by the client, thereby realizing collaborative version management of two different types of resources.

[0067] Furthermore, the server constructs version update instructions based on the query results, which include version update strategies for native applications and / or page resources. This enables the client to execute subsequent update operations according to the unified version update instructions, achieving unified control over the lifecycle of mixed resource updates and avoiding version incompatibility and functional compatibility issues caused by the lack of a collaborative management mechanism.

[0068] In some embodiments of this disclosure, based on the first version information, a query is performed in the application version update table to determine whether a first target version update strategy corresponding to the first version information exists. Optionally, this includes steps S310 to S330. Please refer to [link / reference]. Figure 3 .

[0069] In step S310, based on the first version information, a query is performed in the application version update table to determine whether there is a first version update strategy whose field value of the current version number field is the same as that of the first version information.

[0070] In step S320, if the first version update policy exists, it is determined whether the first version update policy is enabled.

[0071] In step S330, when the first version update strategy is enabled, the first version update strategy is determined to be the first target version update strategy.

[0072] The current version number field is used in the application version update table to identify the old version of the native application to which this version update policy is applied. Its field value indicates which version of the native application will trigger this version update policy.

[0073] In this implementation, the server searches the application version update table based on the first version information contained in the version query request to see if there exists a version update strategy whose current version number field value is the same as the first version information (such as the version number of the native application). If it exists, it is identified as the first version update strategy. If it does not exist, it means that the native application does not need to be updated.

[0074] Optionally, if the version query request also includes a platform identifier, the server will search the application version update table for a version update strategy that has the same value for the platform identifier field as the platform identifier and the same value for the current version number field as the first version information, based on the platform identifier and the first version information.

[0075] For example, if the version query request contains the platform identifier "android" and the first version information "3.1.0", the server will look up the version update strategy in the application version update table where the platform (i.e., platform identifier) ​​field value is "android" and the current_version (i.e., current version number) field value is "3.1.0".

[0076] Based on the determined first version update policy, the server further checks whether the first version update policy is enabled. If the first version update policy is enabled, it means that the first version update policy has been allowed to take effect. Conversely, if the first version update policy is disabled, it means that the first version update policy has not been allowed to take effect.

[0077] Optionally, the version update policy includes a status field, which indicates whether the version update policy is in effect. For example, when the value of the status field in the version update policy is "1", it means that the version update policy is enabled; when the value of the status field is "0", it means that the version update policy is disabled. Thus, the server determines whether the first version update policy is enabled based on the value of the status field in the first version update policy, thereby filtering out version update policies that, although matching the version, are not yet allowed to take effect.

[0078] When the first version update strategy is determined to be enabled, the server identifies it as the first target version update strategy. This allows the server to extract the parameters required to build the version update instructions from the first target version update strategy, thereby guiding the resource updates of the native application.

[0079] In this way, by adding an enable status check on top of version information matching, operations personnel can flexibly control the timing of each version update policy's activation without deleting the policy. For example, a version update policy can be pre-configured as "disabled" before a new version of a native application is released to the app store, and then changed to "enabled" after the app store is completed. This decouples release from deployment and avoids errors caused by premature updates due to unprepared resources.

[0080] In some embodiments of this disclosure, based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether a second target version update strategy corresponding to the second version information exists. Optionally, this includes steps S410 to S430. Please refer to [reference needed]. Figure 4 .

[0081] In step S410, based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether there is a second version update strategy whose field value of the current resource version number field is the same as the second version information.

[0082] In step S420, if the second version update policy exists, it is determined whether the second version update policy is enabled.

[0083] In step S430, when the second version update strategy is enabled, the second version update strategy is determined to be the second target version update strategy.

[0084] The current resource version number field is a field in the page resource version update table used to identify the old version of the page resource to which this version update policy is applied. Its field value indicates which version of the page resource will trigger this version update policy.

[0085] In this implementation, after receiving the version query request from the client and parsing out the second version information, the server initiates a query process for the version update strategy of the page resources. When the version query request contains second version information for multiple page resources, the server needs to perform independent query and filtering operations for each page resource.

[0086] For each page resource, the server searches the page resource version update table based on the module name (if there are multiple page resources) and second version information to see if a version update strategy exists where the module name field value is the same as the module name reported by the client, and the current resource version number field value is the same as the second version information reported by the client. If such a strategy exists, the server can identify it as the second version update strategy; otherwise, it means that the page resource does not need to be updated.

[0087] For example, if the client reports the second version information of a page resource with the module name "activity" as "v1", the server will look for a version update strategy in the page resource version update table with the value of "activity" in the module_name (i.e., module name) field and "v1" in the current_version (i.e., current resource version number) field. If such a strategy is found, it will be determined as the second version update strategy.

[0088] After determining the second version update strategy, the server further checks whether the second version update strategy is enabled. As mentioned earlier, if the second version update strategy is enabled, it means that the second version update strategy has been allowed to take effect, and the server can determine it as the second target version update strategy. If the second version update strategy is disabled, it means that the second version update strategy has not been allowed to take effect, and the server will not perform any further processing.

[0089] Optionally, the version update strategy in the page resource version update table may include a status field to indicate whether the version update strategy is in effect. The server can determine whether the second version update strategy is enabled based on the status field in the second version update strategy.

[0090] In this way, by adding an enable status check on top of version information matching, operations personnel can flexibly control when the version update policy for each page resource takes effect without deleting the version update policy. For example, the corresponding version update policy can be pre-configured but set to "disabled" before the page resource package is uploaded to the CDN (Content Delivery Network). Once the resource is ready, the status can be changed to "enabled," thus decoupling the release and deployment and avoiding loading failures caused by premature updates due to unready resources.

[0091] In some embodiments of this disclosure, step S230, constructing a version update instruction based on the first target version update strategy and / or the second target version update strategy, may optionally include steps S231 to S232. Please refer to [link / reference]. Figure 5 .

[0092] In step S231, if the first target version update strategy exists, the update method, update text, and application download address are extracted from the first target version update strategy as application update information; and if the second target version update strategy exists, the module name, page resource download address, and integrity verification code are extracted from the second target version update strategy as page resource update information.

[0093] In step S232, the application update information and / or the page resource update information are encapsulated to obtain a version update instruction.

[0094] The update method includes either a forced update or an optional update. Optionally, the version update strategy in the application version update table includes a forced update identifier field. The value of this forced update identifier field indicates whether the version update strategy uses a forced update method or an optional update method. For example, a value of "1" for the forced update identifier field indicates that the version update strategy uses a forced update method, while a value of "0" indicates that the version update strategy uses an optional update method.

[0095] The update description is the update information displayed to users, explaining the functional changes or fixes in the new version. Optionally, the version update strategy in the application version update table includes an update description field, and the value of this field is the update description corresponding to that version update strategy.

[0096] In this implementation, after the server completes the query of the application version update table and the page resource version update table, the server determines whether there is a corresponding first target version update strategy or a second target version update strategy.

[0097] When a first target version update strategy is determined, the server determines the update method, update text, and application download address required for the native application update based on the field values ​​in the first target version update strategy, as the application update information.

[0098] Specifically, the server determines the update method of the native application based on the value of the forced update identifier field in the first target version update strategy; extracts the value of the update copy field in the first target version update strategy to obtain the update copy of the native application; and extracts the value of the application download address field in the first target version update strategy to obtain the download address of the new version of the application. The application download address can guide the client to the corresponding application market page to complete the download of the resource package of the new version of the native application.

[0099] Meanwhile, when the server determines that a second target version update strategy exists, since multiple page resources may need to be updated, the server can iterate through all second target version update strategies. For each second target version update strategy, the server determines the module name, page resource download address, and integrity check code required for page resource updates based on the field values ​​in that strategy, and uses these as the page resource update information.

[0100] Specifically, the server extracts the value of the "Module Name" field from the second target version update strategy to obtain the module name, which identifies which page resource needs to be updated. The server also extracts the value of the "Page Resource Download Address" field from the second target version update strategy to obtain the download address for the new version of the page resource. This download address informs the client where to download the resource package for the new version of the page resource. Finally, the server extracts the value of the "Integrity Check Code" field from the second target version update strategy to obtain the integrity check code for the page resource (e.g., the MD5 hash calculated based on the resource package of the new version of the page resource). This integrity check code is used by the client to verify the integrity and correctness of the resource package of the new version of the page resource after downloading it.

[0101] After the above information is extracted, the server encapsulates the extracted application update information and / or page resource update information according to a pre-defined data format to obtain the corresponding version update instruction.

[0102] Therefore, the server constructs version update instructions that include version update strategies for native applications and / or page resources, enabling the client to execute subsequent update operations according to the unified version update instructions. This achieves unified control over the lifecycle of mixed resource updates and avoids version incompatibility and functional compatibility issues caused by the lack of a collaborative management mechanism.

[0103] In some embodiments of this disclosure, the hybrid resource update method may optionally further include steps S610 to S620, please refer to... Figure 6 .

[0104] In step S610, a configuration instruction is received, which is used to modify the field value of the status field in the version update strategy of the application version update table and / or the page resource version update table.

[0105] In step S620, according to the configuration instruction, the field value of the status field in the corresponding version update strategy is updated to enabled or disabled, thereby controlling the timing of the version update strategy taking effect.

[0106] The configuration instruction is an operation request used to modify parameters of the version update strategy in a version update table (such as an application version update table or a page resource version update table). In one embodiment, the configuration instruction can be used to modify the field value of the status field in the version update strategy of the application version update table and / or the page resource version update table.

[0107] In this implementation, the configuration and activation of version update strategies often need to be carried out in stages during actual business operations to ensure coordination and synchronization between resource preparation and strategy release.

[0108] To this end, the server also provides a backend management interface. After configuring the version update strategy, operations personnel can use the backend management interface to select the version update strategy that needs to be adjusted (such as the version update strategy in the application version update table, the version update strategy in the page resource version update table, or multiple version update strategies in two version update tables). After selecting the version update strategy, operations personnel can switch the status of the selected version update strategy from disabled to enabled, or from enabled to disabled, in the backend management interface.

[0109] The backend management interface generates corresponding configuration instructions based on the operations personnel's actions. Optionally, this configuration instruction should at least include the table identifier of the version update table containing the version update policy to be modified, the unique identifier of the version update policy to be modified (such as a primary key ID), and the target status value (such as "1" indicating enabled status and "0" indicating disabled status). The backend management interface then sends this configuration instruction to the server.

[0110] Upon receiving the configuration command, the server parses it, extracting the table identifier, the unique identifier of the version update policy to be modified, and the target status value. Then, the server locates the corresponding version update table based on the table identifier, and identifies the specific version update policy within that table based on the unique identifier of the policy to be modified. Next, the server modifies the value of the status field of that version update policy to the target status value specified in the configuration command. For example, if the configuration command requires the version update policy to be "enabled," the value of its status field (i.e., the status field) is updated from "0" to "1"; if it requires "disabled," the status field is updated from "1" to "0." After the update operation is completed, the effective status of the version update policy immediately changes.

[0111] After the status is updated, when a client subsequently initiates a version query request, the server will filter the query results based on the updated status field value. If the status is "Enabled," the version update strategy will be correctly matched and included in the query results (e.g., identified as the first or second target version update strategy); if the status is "Disabled," the strategy will be filtered out and will not appear in the query results. In this way, operations personnel do not need to delete or recreate strategy records; they can flexibly control the activation timing of each version update strategy simply by modifying the value of a status field.

[0112] It's worth noting that the above steps support modifying a single version update policy within a single version update table, as well as batch modifying multiple version update policies, and even simultaneously modifying version update policies in both the application version update table and the page resource version update table. This allows operations personnel to collaboratively or independently control application updates and page resource updates based on business needs.

[0113] Figure 7 This is a flowchart illustrating another embodiment of the hybrid resource update method of this disclosure. This hybrid resource update method is applied to the client as described above.

[0114] like Figure 7 As shown, the hybrid resource update method may optionally include steps S710 to S740.

[0115] In step S710, a version query request is generated, which includes the first version information of the native application and the second version information of the page resources.

[0116] In step S720, the version query request is sent to the server, which is used to execute the hybrid resource update method applied to the server as described in any of the preceding embodiments.

[0117] In step S730, a version update instruction sent by the server is received.

[0118] In step S740, the native application and / or page resources are updated according to the version update instruction.

[0119] In this implementation, when a pre-set trigger condition is met (such as the native application starting up or being switched to the foreground), the client's update scheduler collects the first version information of the native application and the second version information of at least one page resource embedded in the native application, and constructs a corresponding version query request based on the first version information and the second version information.

[0120] Next, the client sends the version query request to the server via the network. The server can then execute the hybrid resource update method applied to the server as described in any of the previous embodiments based on the received version query request, thereby generating the corresponding version update instruction.

[0121] The server sends the generated version update command to the client. Upon receiving the version update command, the client parses it and, if there are native application updates and / or page resource updates, updates the native application and / or page resources according to the parameter information in the version update command.

[0122] In this way, the server performs collaborative queries in the related application version update table and page resource version update table based on the version information of the native application and page resources reported by the client, thereby realizing collaborative version management of two different types of resources.

[0123] Furthermore, the server constructs version update instructions based on the query results, which include version update strategies for native applications and / or page resources. This enables the client to execute subsequent update operations according to the unified version update instructions, achieving unified control over the lifecycle of mixed resource updates and avoiding version incompatibility and functional compatibility issues caused by the lack of a collaborative management mechanism.

[0124] In some embodiments of this disclosure, when updating the resources of the native application according to the version update instruction, steps S810 to S830 may be optionally included. Please refer to [reference needed]. Figure 8 .

[0125] In step S810, according to the version update instruction, if the update method is forced update, a forced update prompt message is displayed in the interface of the native application, and the continued use of the native application is prohibited; if the update method is optional update, an optional update prompt message is displayed in the interface.

[0126] In step S820, in response to the confirmation operation of the forced update prompt message or the optional update prompt message, the user is redirected to the corresponding download page according to the application download address in the version update instruction.

[0127] In step S830, the resource package of the version to be updated of the native application is obtained through the download page, and the resource update is completed.

[0128] In this implementation, when the client parses the version update instruction and determines that the native application needs to update its resources, the client determines the corresponding update method from the version update instruction (by reading the forced update identifier).

[0129] When the update method is forced, the client displays a dialog box in the native application's interface containing a forced update prompt and prohibiting further use of the native application. Access to the native application can only resume after the resource update is complete. When the update method is optional, the client displays a dialog box in the native application's interface containing an optional update prompt, allowing the user to choose when to update.

[0130] It should be noted that different button combinations can be configured for different update method prompts. For example, for a forced update prompt, only a "Update Now" button can be added, and the dialog box for the forced update prompt cannot be closed. For an optional update prompt, both "Update Now" and "Later" buttons can be added, and the user can close the dialog box for the optional update prompt by clicking "Later".

[0131] Whether it's a forced update or an optional update, when a user confirms the forced update prompt or optional update prompt (e.g., by clicking the "Update Now" button in the prompt), the client will redirect to the corresponding download page based on the application download address in the version update instruction (e.g., by opening the corresponding app store and directly navigating to the details page of the native application).

[0132] On this download page, users can click the "Download" or "Update" button to begin downloading the resource package for the updated version of the native application. After the download is complete, the resource package can be installed to update the native application's resources.

[0133] Thus, by distinguishing between mandatory and optional updates, this disclosed hybrid resource update method can flexibly handle various release scenarios: for critical security fixes, major defect repairs, or backend protocol changes, a mandatory update approach ensures all users can quickly upgrade to a compatible version, avoiding service unavailability due to version incompatibility; for non-critical updates such as routine feature iterations and interface optimizations, an optional update approach gives users the option to choose, avoiding excessive disruption to users. This significantly improves the flexibility and adaptability of releasing new versions of native applications.

[0134] In some embodiments of this disclosure, before displaying the forced update prompt message or the optional update prompt message, the hybrid resource update method may optionally further include steps S910 to S920, please refer to... Figure 9 .

[0135] In step S910, the update text is extracted from the version update instruction, and the update text includes the update content or a description of the new version features.

[0136] In step S920, a forced update prompt message or an optional update prompt message is generated based on the updated content or the new version function description.

[0137] In this implementation, once the update method of the native application is determined, the client extracts the update text from the version update instruction. For example, the update text is "Version 3.2.0 Update Notes: Added property comparison function; optimized activity page loading speed; fixed known issues".

[0138] The client uses the updated text as content material for generating subsequent prompts. Specifically, when the update method is a forced update, the client generates a forced update prompt based on the updated text; when the update method is an optional update, the client generates an optional update prompt based on the updated text.

[0139] Therefore, by presenting users with specific and clear update content and descriptions of new version features, users can understand the value and necessity of upgrading, thus being more willing to proactively perform the update. Especially in optional update scenarios, thorough textual explanations help users make informed decisions.

[0140] Furthermore, the update text is dynamically distributed from the server, with the client only responsible for displaying it. Operations personnel can flexibly write and adjust the update description text according to the characteristics of different versions and the operational strategies at different times, reducing the need for client-side version releases due to changes in the notification content and lowering development and maintenance costs.

[0141] In some embodiments of this disclosure, when updating the page resources according to the version update instruction, steps S1010 to S1030 may be optionally included. Please refer to [link / reference]. Figure 10 .

[0142] In step S1010, a background download task is created and executed according to the page resource download address in the version update instruction to obtain the resource package of the page resource to be updated.

[0143] In step S1020, the integrity of the resource package of the page resource to be updated is verified according to the integrity check code in the version update instruction.

[0144] In step S1030, if the resource package of the page resource to be updated passes the integrity check, the stored resource package of the page resource is replaced according to the resource package of the page resource to be updated.

[0145] In this implementation, when the client parses the version update instruction and determines that there are page resources to be updated, the client extracts the download address of the page resource from the version update instruction and creates and executes a background download task accordingly. During the background download task executed by the client, the user can use other functions of the native application normally.

[0146] Once the background download task is complete, the client uses the integrity check code included in the version update instruction to perform an integrity check on the resource package of the downloaded page resources to be updated, in order to ensure the integrity and correctness of the resource package.

[0147] If the resource package passes the integrity check, the client replaces the previously stored page resource package (i.e., the older version) with this resource package. The next time the user accesses this page resource (e.g., by clicking to enter an activity page), the native application will automatically load the latest version of the page resource and display the updated page content.

[0148] In this way, the downloading, verification, and replacement of all page resources are completed silently in the background. Users do not need to manually operate or wait for the page to load; they can directly use the latest version of resources on their next visit. Furthermore, by introducing an integrity verification mechanism into the page resource update process, the client can verify whether the downloaded resource package has been corrupted or maliciously tampered with during transmission. Only resource packages that pass the integrity verification are officially enabled, effectively preventing application malfunctions or crashes caused by network transmission errors or man-in-the-middle attacks, ensuring the stable operation of the native application.

[0149] In some embodiments of this disclosure, if the resource package of the page resource to be updated fails the integrity verification, the resource package of the page resource to be updated is deleted.

[0150] In this implementation, if a downloaded resource package fails the integrity check, it indicates that the resource package may be corrupted or untrusted. In this case, the client can delete the newly downloaded resource package to free up storage space. Therefore, by promptly deleting resource packages that fail the integrity check, application malfunctions, page errors, or application crashes caused by file corruption are avoided, ensuring the stable operation of the native application.

[0151] Optionally, after the resource package deletion operation is completed, the client records an error log. This error log may include information such as the module name, integrity checksum, actual calculated value, and timestamp, for subsequent problem tracking and analysis. Furthermore, the client can, according to a preset retry policy, re-initiate a download attempt for a new version of the resource package for that page after a certain time interval or when the network environment changes.

[0152] In some embodiments of this disclosure, step S1020, which involves verifying the integrity of the resource package of the page resource to be updated based on the integrity check code in the version update instruction, may optionally include steps S1021 to S1023. Please refer to [reference needed]. Figure 11 .

[0153] In step S1021, a hash calculation is performed on the resource package of the page resource to be updated to obtain a verification value.

[0154] In step S1022, the verification value is compared with the integrity check code in the version update instruction.

[0155] In step S1023, if the verification value is the same as the integrity check code, it is determined that the resource package of the page resource to be updated has passed the integrity check; if the verification value is different from the integrity check code, it is determined that the resource package of the page resource to be updated has failed the integrity check.

[0156] In this implementation, after the background download task is completed, the client performs an integrity check on the resource package of the downloaded page resources to be updated, based on the integrity check code contained in the version update instruction.

[0157] Specifically, the client performs a hash calculation on the resource package of the downloaded page resource (the version to be updated) to obtain the corresponding checksum. Optionally, the client uses the MD5 message digest algorithm to calculate a fixed-length (e.g., 128-bit) digest value for the downloaded page resource (the version to be updated) as the checksum.

[0158] After calculating the checksum, the client compares it bit by bit with the integrity checksum extracted from the version update command. If any character matches, the resource package passes the integrity check, indicating that no data corruption occurred during the download process and the content is completely consistent with the original resource on the server, making it safe to use. If any character differs, the resource package fails the integrity check, indicating that it has been corrupted or tampered with and cannot be trusted or used.

[0159] In this way, through hash calculation and comparison, the client can accurately verify whether the downloaded resource package has been lost or tampered with during transmission, ensuring that the resource package of the page resource finally enabled is completely consistent with the original resource on the server, thus avoiding application function abnormalities caused by file corruption.

[0160] Figure 12 This is a schematic diagram of the architecture of a hybrid resource update system according to one embodiment of the present disclosure.

[0161] like Figure 12 As shown, the Native container in the client is the basic framework part developed using native technologies (i.e., the native application mentioned above). This Native container is responsible for providing core function calls, system capability interfaces, and high-performance interactive interfaces, while also providing runtime environment support for page resources (such as H5 pages).

[0162] The update scheduler is integrated into the client and serves as the control center for the update logic. It is responsible for initiating version query requests, parsing the version update instructions returned by the server, and coordinating the execution of corresponding update operations based on the content of the version update instructions.

[0163] The local metadata storage is a storage area on the client's local machine used to persistently store version information (such as the first version information of the native application and the second version information of page resources). For example, when generating a version query request, the update scheduler reads the first version information of the native application and the second version information of the page resources from the local metadata storage. After the resource update is completed, the update scheduler writes the updated version information back to the local metadata storage.

[0164] The local page resource bundle is a collection of page resource files stored locally on the client side. It contains static resource files for each page that have been downloaded and passed integrity checks. The native container reads resources from the local page resource bundle through a loading mechanism and renders the corresponding page.

[0165] The server-side backend management interface is a graphical configuration platform provided for operations personnel. Through this backend management interface, operations personnel can configure and manage version update strategies, including adding, deleting, querying, and modifying version update strategies in the application version update table and page resource version update table.

[0166] The API interface server is the interface layer on the server side responsible for handling network requests from clients. Its main responsibilities include receiving version query requests sent by clients, parsing the request parameters contained therein, calling the backend database query logic (including application version update table queries and page resource version update table queries), and then encapsulating the query results into version update instructions and returning them to the client.

[0167] In addition, CDN (Content Delivery Network) resource servers are used to store and distribute resource packages of page resources, ensuring that clients can efficiently and reliably obtain new versions of page resource packages from the nearest (or most efficient) network node.

[0168] Figure 13 This is a flowchart illustrating another embodiment of the hybrid resource update method disclosed herein. Figure 13 As shown, the hybrid resource update method may optionally include steps S1301 to S1313.

[0169] In step S1301, the application is launched. For example, the user clicks the application icon on the terminal device, the operating system loads and launches the native application, and the user enters the native application's main interface or initial page. Launching the native application is one of the times that a version update query is triggered, ensuring that the user can obtain the latest version information when they begin using the native application.

[0170] In step S1302, the update scheduler is initialized. The update scheduler integrated within the client completes its initialization during the native application startup process, loads the necessary configuration parameters, and prepares to execute subsequent version query tasks.

[0171] In step S1303, the update scheduler sends a version query request to the server. The update scheduler reads the current client's platform identifier (such as iOS or Android), the current version number of the native application (i.e., the first version information), and the current resource version number of each page resource (such as H5 modules) (i.e., the second version information) from the local metadata storage, encapsulates this information into a version query request, and sends it to the server's API interface server over the network to inquire whether there is a new version available for updating.

[0172] In step S1304, the server queries the version update table. After receiving the version query request from the client, the server parses the platform identifier, the current version number of the native application, and the current resource version number of each page resource in the version query request. Based on this information, the server queries the application version update table and the page resource version update table respectively to find a version update policy that matches the current version number or the current resource version number and is enabled.

[0173] In step S1305, it is determined whether an application update exists. The server returns the query result (i.e., the version update instruction) to the client. The update scheduler parses the version update instruction and determines whether it contains update information for the native application (such as a forced update identifier, update text, application download address, etc.). If an application update exists, the process proceeds to step S1306 to execute the application update procedure; if no application update exists, the process jumps to step S1307 to continue determining whether a page resource update exists.

[0174] In step S1306, the application update process is executed. The client determines the corresponding update method based on the forced update identifier in the application update information of the version update instruction and displays the corresponding update prompt on the interface. Specifically, if the update method is a forced update, an unskippable update dialog box (containing a forced update prompt) pops up, and the user can only continue using the native application after updating it; if the update method is an optional update, an update dialog box (i.e., optional update prompt) pops up with "Update Now" and "Later" options.

[0175] After the user confirms the update (e.g., by clicking the "Update Now" button), the client is redirected to the specified application download address to download and install the new version of the native application from the corresponding app store. Once the application update process is complete, proceed to step S1307.

[0176] In step S1307, it is determined whether there is a page resource update. The client parses the version update instruction returned by the server and checks whether it contains page resource update information. If page resource update information exists, proceed to step S1308; otherwise, jump directly to step S1313.

[0177] In step S1308, a background download task is created. Based on the page resource update information, for each updated page resource, the update scheduler creates a background download task according to the page resource download address provided in the page resource update information. Optionally, this background download task runs with low priority and does not occupy the foreground interface thread, allowing the user to use other functions of the native application normally during this period. Furthermore, the background download task can, depending on the current network environment, only start downloading under Wi-Fi to save user data.

[0178] In step S1309, the page resource package is downloaded. The background download task obtains the new version of the page resource package from the specified CDN network address (i.e., the page resource download address).

[0179] In step S1310, it is determined whether the integrity check has passed. After the download is complete, the client performs an MD5 hash calculation on the downloaded new version of the page resource package to obtain the checksum, and compares it with the integrity checksum carried in the version update instruction. If the two match, the integrity check is deemed to have passed, and the process proceeds to step S1311; if they do not match, the check is deemed to have failed, and the process proceeds to step S1312.

[0180] In step S1311, the local resource package is replaced and the local version number is updated. For page resource packages that pass the integrity check, the client moves or decompresses them to the local page resource package's official storage directory, overwriting the original old version resource files. Simultaneously, the resource version number of the corresponding page resource in the local metadata storage is updated to the new resource version number to ensure that subsequent accesses can recognize the latest version.

[0181] In step S1312, the corrupted package is deleted and an error log is recorded. For page resource packages that fail integrity verification, the client immediately deletes them to free up storage space and prevent the corrupted resources from being misused. Simultaneously, the client records error information in its local log, including the module name, expected MD5 value (i.e., integrity checksum), actual calculated value (i.e., checksum), and timestamp, for subsequent problem tracking and analysis. According to a preset retry policy, the client may retry downloading the page resource package after a period of time.

[0182] In step S1313, the process ends. At this point, the entire version query and update process is complete. The client will continue to run normally, and subsequent startups or foreground switching will trigger new version queries, forming a continuous version synchronization mechanism.

[0183] Figure 14 This is a schematic structural block diagram of a hybrid resource update apparatus according to one embodiment of the present disclosure, which is applied to the server as described above.

[0184] like Figure 14 As shown, the hybrid resource update device includes a first receiving module 1410, a query module 1420, a construction module 1430, and a first sending module 1440.

[0185] The system includes a first receiving module 1410 for receiving a version query request from a client, the version query request including first version information of the native application and second version information of the page resources; a query module 1420 for querying the application version update table based on the first version information to determine whether there is a first target version update strategy corresponding to the first version information, and querying the page resource version update table associated with the application version update table based on the second version information to determine whether there is a second target version update strategy corresponding to the second version information; a construction module 1430 for constructing a version update instruction based on the first target version update strategy and / or the second target version update strategy; and a first sending module 1440 for sending the version update instruction to the client, causing the client to update the native application and / or the page resources according to the version update instruction.

[0186] In some embodiments of this disclosure, the first receiving module 1410 is further configured to: receive a configuration instruction, the configuration instruction being used to modify the field value of the status field in the version update strategy of the application version update table and / or the page resource version update table; and update the field value of the status field in the corresponding version update strategy to enabled or disabled according to the configuration instruction, thereby controlling the timing of the version update strategy taking effect.

[0187] Figure 15 This is a schematic structural block diagram of a hybrid resource update apparatus according to another embodiment of this disclosure. This hybrid resource update apparatus is applied in the client described above.

[0188] like Figure 15 As shown, the hybrid resource update device includes a generation module 1510, a second sending module 1520, a second receiving module 1530, and an update module 1540.

[0189] The generation module 1510 is used to generate a version query request, which includes first version information of the native application and second version information of the page resources; the second sending module 1520 is used to send the version query request to the server, which is used to execute the hybrid resource update method applied to the server as described in any of the preceding embodiments; the second receiving module 1530 is used to receive the version update instruction sent by the server; and the update module 1540 is used to update the native application and / or page resources according to the version update instruction.

[0190] In some embodiments of this disclosure, before displaying the forced update prompt or the optional update prompt, the update module 1540 is further configured to extract update text from the version update instruction, the update text including update content or a new version function description; and generate forced update prompt or optional update prompt based on the update content or the new version function description.

[0191] Figure 16 This is a schematic structural block diagram of an electronic device according to one embodiment of the present disclosure.

[0192] like Figure 16As shown, the hardware structure of electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripherals, voltage regulators, power management circuits, external antennas, etc. Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one connection line is used in this figure, but this does not indicate that there is only one bus or one type of bus.

[0193] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means that can contain a program for storage, communication, propagation, or transmission for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0194] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0195] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0196] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0197] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0198] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0199] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0200] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0201] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A hybrid resource update method, characterized in that, When applied to the server side, the hybrid resource update method includes: Receive a version query request sent by the client, the version query request including the first version information of the native application and the second version information of the page resources; Based on the first version information, a query is performed in the application version update table to determine whether there is a first target version update strategy corresponding to the first version information; and based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether there is a second target version update strategy corresponding to the second version information. Based on the first target version update strategy and / or the second target version update strategy, a version update instruction is obtained; and The version update instruction is sent to the client, causing the client to update the native application and / or the page resources according to the version update instruction.

2. The hybrid resource update method as described in claim 1, characterized in that, Based on the first version information, a query is performed in the application version update table to determine whether a first target version update strategy corresponding to the first version information exists, including: Based on the first version information, a query is performed in the application version update table to determine whether there is a first version update strategy whose current version number field value is the same as the first version information. If the first version update policy exists, determine whether the first version update policy is enabled; and When the first version update strategy is enabled, the first version update strategy is determined to be the first target version update strategy.

3. The hybrid resource update method as described in claim 1, characterized in that, Based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether a second target version update strategy corresponding to the second version information exists, including: Based on the second version information, a query is performed in the page resource version update table associated with the application version update table to determine whether there is a second version update strategy whose field value of the current resource version number field is the same as the second version information; If the second version update policy exists, determine whether the second version update policy is enabled; and When the second version update strategy is enabled, the second version update strategy is determined to be the second target version update strategy.

4. The hybrid resource update method as described in claim 1, characterized in that, The version update instruction is constructed based on the first target version update strategy and / or the second target version update strategy, including: If the first target version update strategy exists, the update method, update text, and application download address are extracted from the first target version update strategy as application update information; and if the second target version update strategy exists, the module name, page resource download address, and integrity verification code are extracted from the second target version update strategy as page resource update information; and The application update information and / or the page resource update information are encapsulated to obtain a version update instruction.

5. The hybrid resource update method as described in any one of claims 1-4, characterized in that, The hybrid resource update method further includes: Receive configuration instructions, which are used to modify the field values ​​of the status fields in the version update strategies of the application version update table and / or the page resource version update table; and According to the configuration instructions, the value of the status field in the corresponding version update strategy is updated to enabled or disabled, thereby controlling the timing of the version update strategy's activation.

6. A hybrid resource update method, characterized in that, When applied to a client, the hybrid resource update method includes: Generate a version query request, which includes the first version information of the native application and the second version information of the page resources; The version query request is sent to the server, which is used to execute the hybrid resource update method as described in any one of claims 1-5; Receive version update commands sent by the server; and According to the version update instruction, update the resources of the native application and / or page resources.

7. The hybrid resource update method as described in claim 6, characterized in that, When updating the resources of the native application according to the version update instruction, the following is included: According to the version update instruction, if the update method is a forced update, a forced update prompt message will be displayed in the interface of the native application, and the continued use of the native application will be prohibited; if the update method is an optional update, an optional update prompt message will be displayed in the interface. In response to a confirmation operation of the forced update prompt or the optional update prompt, the user is redirected to the corresponding download page based on the application download address in the version update instruction; and The user obtains the resource package for the updated version of the native application from the download page and completes the resource update.

8. The hybrid resource update method as described in claim 6, characterized in that, When updating the page resources according to the version update instruction, the following is included: Create and execute a background download task based on the page resource download address in the version update instruction to obtain the resource package of the page resource to be updated; Based on the integrity check code in the version update instruction, perform integrity verification on the resource package of the page resource to be updated; and If the resource package of the page resource to be updated passes the integrity verification, the stored resource package of the page resource is replaced according to the resource package of the page resource to be updated.

9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the hybrid resource update method according to any one of claims 1 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the hybrid resource update method according to any one of claims 1 to 8.

Images