Page offline resource package processing method and device, equipment and medium

Abstract

This application relates to a method, apparatus, device, and medium for processing offline resource packages for web pages. The method includes: responding to a publishing request and obtaining initial resources for a target page; performing validity verification on the initial resource package, constructing a standardized offline resource package based on the verified valid static resource files, wherein the offline resource package includes the verified valid static resource files and a resource list; generating a global hash value corresponding to the offline resource package based on the resource list, associating the target page identifier, the storage path of the offline resource package, and the global hash value for storage to form resource configuration information; responding to a configuration update request from a client, matching the carried query hash value and query page identifier with the resource configuration information, and returning corresponding real-time configuration information based on the matching result for loading the corresponding page. This application can ensure the security of offline resources required by application pages, and achieves efficient and accurate updates based on this and combined with a global hash value.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for processing offline resource packages of web pages. Background Technology

[0002] With the rapid development of mobile internet technology, in order to improve the user experience in weak network environments and reduce server load, pre-packaging the static resource files required for H5 pages into offline resource packages for clients to download and cache locally has become a common technical approach. In traditional solutions, the process typically involves unpacking the pre-installed offline resource package to a local cache directory upon first client launch, and then requesting and downloading a cached configuration file containing a resource list from the network upon client startup, thereby creating a WebView instance pool for reuse during page loads. The offline resource package and cached configuration file are provided by the server as pre-defined products; the client's main responsibility is to acquire, store, and match locally cached resources by intercepting network requests when loading the page.

[0003] However, the applicant discovered that this traditional technical solution, which is centered on client-side operations, exposed a series of fundamental technical problems stemming from its underlying principles in enterprise-level application scenarios that involve multi-terminal application matrices and frequent iterations of massive H5 pages.

[0004] First, traditional solutions lack systematic security and standardized control over offline resource packages at the production source. The construction of offline resource packages is typically completed independently by the front-end development team. The packaging process, internal file structure, and security depend entirely on the build process itself, with the server playing only a simple storage and distribution role. This results in resource packages ultimately distributed to millions of clients potentially containing unnecessary or even security-risk files unintentionally. The server lacks effective mechanisms for verification and filtering, posing potential security risks to the entire application ecosystem.

[0005] Secondly, in the process of updating and distributing resource configuration information, traditional solutions often rely on downloading the complete configuration file or negotiating through a general caching mechanism at the HTTP protocol level. When the resource configuration has not changed, the client still needs to conduct a complete network interaction with the server to confirm the status, or it needs to receive a potentially large configuration file for local comparison. This generates unnecessary network data transmission overhead, reduces response efficiency, and increases resource consumption for both the server and the client in scenarios with frequent configuration checks.

[0006] Furthermore, in traditional solutions, the configuration information describing resource versions and content is often loosely coupled with the resource entity itself, lacking a strongly associated, lightweight, and unique identifier to accurately and efficiently represent the version status of the entire offline resource package. This makes it inaccurate and inefficient for the client and server to synchronize resource status.

[0007] Therefore, how to build a systematic processing mechanism on the server side to ensure that the distributed offline resource packages are secure and standardized from the source, while achieving efficient and accurate distribution of resource configuration information and version synchronization, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0008] The purpose of this application is to solve at least one of the above-mentioned problems by providing a method for processing offline resource packages of pages, and corresponding apparatus, devices, non-volatile readable storage media, and computer program products.

[0009] According to one aspect of this application, a method for processing offline resource packages for web pages is provided, comprising: In response to a publish request for a target page, an initial resource package for implementing the target page is obtained, the initial resource package containing static resource files constituting the target page; The initial resource package is subjected to validity verification. Based on the verified valid static resource files, a standardized offline resource package is constructed. The offline resource package includes the verified valid static resource files and a resource list. The resource list includes the storage path and file hash value of the static resource files. Based on the resource list, a global hash value corresponding to the offline resource package is generated. The target page identifier, the storage path of the offline resource package, and the global hash value are associated and stored to form resource configuration information. In response to a client's configuration update request, the query hash value and query page identifier carried in the request are matched with the resource configuration information. Based on the matching result, the corresponding real-time configuration information is returned so that the corresponding page of the query page identifier can be loaded.

[0010] According to another aspect of this application, a page offline resource package processing apparatus is provided, comprising: The publish response module is configured to respond to a publish request for a target page and obtain an initial resource package for implementing the target page, wherein the initial resource package contains static resource files that constitute the target page; The security reconstruction module is configured to perform validity verification processing on the initial resource package, and construct a standardized offline resource package based on the verified valid static resource files. The offline resource package includes the verified valid static resource files and a resource list, and the resource list includes the storage path and file hash value of the static resource files. The configuration construction module is set to generate a global hash value corresponding to the offline resource package based on the resource list, and associate and store the target page identifier, the storage path of the offline resource package and the global hash value to form resource configuration information; The update response module is configured to respond to configuration update requests from clients. It matches the query hash value and query page identifier carried in the request with the resource configuration information and returns the corresponding real-time configuration information based on the matching result, so as to load the corresponding page of the query page identifier.

[0011] According to another aspect of this application, an electronic device is provided, including a central processing unit and a memory, wherein the central processing unit is configured to invoke and run a computer program stored in the memory to perform the steps of the method described in this application.

[0012] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the page offline resource package processing method in the form of computer-readable instructions, wherein the computer program, when invoked by a computer, executes the steps included in the method.

[0013] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0014] Compared to traditional technologies, this application establishes a closed-loop offline resource package processing mechanism on the server side, achieving secure and controllable resource distribution, efficient updates, and accurate versioning. First, standardized verification including security filtering is performed at the resource generation source to ensure the cleanliness and standardization of the distributed package content, eliminating the risk of malicious file propagation at its source. Second, a global hash value generated based on the resource manifest serves as a lightweight version fingerprint, allowing clients to quickly compare with the server simply by carrying this hash value. This enables instantaneous response with zero data transmission when the configuration remains unchanged, significantly optimizing network efficiency and update latency. Furthermore, this hash mechanism is strongly correlated with the resource package content, ensuring absolute consistency between the client and server's understanding of the version status. Combined with the precise path and hash instructions, this ensures reliable and error-free resource acquisition, verification, and loading throughout the entire process. The overall solution provides secure, efficient, and reliable systemic support for offline applications across multiple platforms and large-scale application pages. Attached Figure Description

[0015] Figure 1 This is an exemplary network architecture for this application; Figure 2 This is a flowchart illustrating one embodiment of the offline resource package processing method for pages in this application; Figure 3 This is a schematic block diagram of the offline resource package processing device for pages in this application; Figure 4 This is a schematic diagram of the structure of an electronic device used in this application. Detailed Implementation

[0016] The offline resource package processing method and its corresponding apparatus, equipment, and storage medium provided in this application aim to solve the technical problems such as security risks, low update efficiency, and inaccurate version management in the entire chain of offline resource packages from the source of construction to client loading by constructing a complete process for standardized processing, security control, and efficient distribution of application page offline resource packages on the server side. This provides reliable and efficient system support for the offline application of application pages in enterprise-level multi-terminal application matrices.

[0017] like Figure 1 As shown, an exemplary network architecture for deploying the technical solution of this application may include a client 80, a business server 81, and a storage server 82. The client 80 is typically a terminal device for user interaction, such as a smartphone, tablet, or personal computer. Users access and interact with various application pages through a host application running on it with a built-in Web view container (such as WebView). The business server 81 is responsible for handling the core business logic related to the lifecycle of offline resource packages for application pages. Specifically, this includes responding to publishing requests for target pages, performing validity verification and standardized construction on the obtained initial resource packages, generating and managing resource configuration information including version identifiers, storage paths, and integrity summaries, and responding to client configuration update requests and performing intelligent matching and instruction issuance. The storage server 82 is responsible for providing highly available file storage and distribution services. Specifically, it may include storing standardized offline resource package files generated by the business server 81 and various static resource files within them, and providing the client 80 with a stable storage path for these files as a download address. Users typically initiate access requests to specific application pages through the host application running on client 80. This request triggers client 80 to query the corresponding resource configuration information from business server 81. After completing the logic processing, business server 81 instructs client 80 to obtain the corresponding offline resource package file from storage server 82 and quickly load the corresponding page using locally cached resources.

[0018] The static resource files in this application constitute the most basic and essential set of elements that make up a standalone application page. In the field of web front-end technology, when a typical application page (such as an H5 page) is rendered in a client browser or WebView container, its content, style, interaction logic, and data are all defined and driven by a series of static resource files. These files typically include: Hypertext Markup Language (HTML) files describing the page's skeleton structure, Cascading Style Sheets (CSS) files defining the page's visual presentation, JavaScript files implementing the page's dynamic interactions and business logic, and data files such as JSON that may contain initialization configurations or static data. The offline resource package of this application is responsible for packaging all the static resource files that constitute a specific target application page into a complete set of resources that can be stored and loaded locally after security screening and standardization. Therefore, static resource files are the raw materials and components of an application page, while the offline resource package is a standardized finished product kit that can be efficiently distributed after these raw materials have been processed by this application. The relationship between the two is that of content and carrier, component and complete entity.

[0019] In a typical application scenario, taking a technology platform that operates multiple independent applications but shares a single H5 page framework and resources as an example, each application it serves needs to ensure that its embedded application pages, such as activity pages, product detail pages, or user center pages, can load quickly and stably under different network conditions. When a business team completes the development and construction of a new version of a page, it triggers the release process described in this application. After receiving the release request, the business server 81 retrieves the initial resource package produced by the build from the specified address and performs standardized processing, including security filtering, to generate a trusted offline resource package stored on the storage server 82. At the same time, it generates associated resource configuration information for version control and distribution. When a large number of users access the page through applications on their respective devices, their clients 80 initiate configuration queries to the business server 81. The business server 81 efficiently determines whether an update is needed by comparing the query hash value carried by the client with the global hash value on the server. If an update is needed, it issues precise instructions to guide the client to retrieve incremental or full resource packages from the storage server 82, thereby achieving accurate and efficient resource updates and loading while ensuring security.

[0020] It should be noted that each step of the offline resource package processing method of this application can be implemented as a computer program and deployed in a distributed manner on the corresponding devices within the aforementioned network architecture according to their functional divisions. For example, the core logic related to resource package processing, configuration management, and request matching can be deployed on the business server 81, while the logic related to the storage and distribution of offline resource package entity files can rely on the storage server 82. Through the collaborative work between the client 80, the business server 81, and the storage server 82, this application jointly constructs a complete offline link from resource publishing, secure processing, intelligent distribution to client loading, ensuring the security of resource distribution, the efficiency of the update process, and the reliability of the final loading.

[0021] Having explained the above architecture, principles, and related concepts, the following section will elaborate on various implementation methods of this application in conjunction with the accompanying drawings.

[0022] Please see Figure 2 According to the offline resource package processing method provided in this application, it can be implemented as a computer program product and run on an electronic device acting as a server, including the following steps: Step S3100: Respond to the publishing request for the target page and obtain the initial resource package for implementing the target page, wherein the initial resource package contains static resource files constituting the target page; In a typical business scenario, after completing the development and building of a specific application page, developers can initiate the release process. This release process can be triggered by a release tool running on the developer's local machine or in a continuous integration environment. This tool will send a release request to the server, specifically the application's business server, for the target page. This release request is a structured instruction designed to formally submit the build artifacts to the server for subsequent standardized processing and distribution. The release request carries key metadata for locating and identifying relevant resources; this metadata forms the basis for subsequent processing.

[0023] The key metadata included in the publish request includes, but is not limited to, the identifier of the target page and the storage address of the initial resource package. The target page identifier is a string used to uniquely identify the application page on the server side; for example, it could be a key composed of the project name and the page name. The initial resource package refers to a compressed archive automatically generated by the front-end build tool, containing all the static resource files required to constitute the target page; common formats are Zip and RAR. In one embodiment, the build tool automatically analyzes the page's dependencies during the packaging process, collecting and compressing all necessary script files, stylesheet files, hypertext markup language files, and possible data files to form a complete resource set, constituting the initial resource package. After this initial resource package is uploaded to a temporary file storage location, such as a specified bucket or directory of an object storage service, its network-accessible address—the storage address of the initial resource package—can be included in the publish request and sent to the business server.

[0024] After receiving a publish request, the business server can respond and retrieve the corresponding initial resource package based on the storage address in the key metadata of the request. Specifically, upon receiving the publish request, the server first parses the request content, i.e., the key metadata, and extracts the storage address of the initial resource package. Subsequently, based on this storage address, it downloads the initial resource package file from the specified storage location to the server's local temporary directory or memory for processing via a network protocol, such as Hypertext Transfer Protocol. This download process ensures that the server obtains the raw materials that need further processing.

[0025] Step S3200: Perform validity verification processing on the initial resource package, and construct a standardized offline resource package based on the verified valid static resource files. The offline resource package includes the verified valid static resource files and a resource list. The resource list includes the storage path and file hash value of the static resource files. After the developer submits a publishing request for the target page to the business server through the publishing tool, and the business server successfully downloads the initial resource package, a validity verification process can be performed. The purpose of this process is to extract a safe, standardized, and trustworthy final deliverable, namely a standardized offline resource package, from a build product that may have uncertainties or risks.

[0026] In a broad sense, validity verification can encompass multiple dimensions, including integrity verification, security verification, and normative reconstruction. First, the business server performs integrity verification on the initial resource package downloaded locally. This verification is fundamental to ensuring that the acquired file has not been damaged or tampered with during transmission. In one embodiment, the publishing request may include not only the storage address of the initial resource package but also the expected hash value of the initial resource package, such as its MD5 checksum. After downloading the initial resource package file, the business server recalculates the hash value of the file and compares it with the expected hash value provided in the request. If they match, the verification passes, indicating that the acquired file is complete and trustworthy; if they do not match, it indicates that the file may have been damaged or tampered with, and the processing can terminate here and return an error, thus avoiding processing unreliable data from the source.

[0027] After the initial resource package passes integrity verification, the application server decompresses it. The purpose of decompression is to release all files within the compressed package to a temporary working directory on the server, allowing subsequent access and manipulation of each file as a file system. After decompression, the directory will contain various static resource files that make up the target page, such as Hypertext Markup Language files, script files, stylesheet files, and data files. However, it may also contain other files unintentionally introduced during the build process that are unnecessary or even potentially harmful.

[0028] To ensure the security of the final offline resource package, the business server can filter files in the decompressed directory according to preset security policies, such as preset secure file filtering rules. Secure file filtering rules define the file types allowed to be included in the final offline resource package; that is, they define which types of files are permitted to be included. In one embodiment, this rule is embodied in a predefined whitelist of secure file types. This whitelist is a list containing specific file extensions, such as .html, .htm, .js, .css, .json, etc., representing Hypertext Markup Language, scripts, stylesheets, and static data. The business server compares the extension of each file in the decompressed directory with the whitelist, identifying files whose extensions are not in the whitelist as not conforming to the secure file filtering rules, and removing them from the working directory. This process effectively filters out potentially malicious scripts, irrelevant configuration files, temporary files, or any unexpected resource types, ensuring the purity of the offline resource package content.

[0029] In another embodiment, the security file filtering rules can be more granular, not only based on file extensions, but also combining file content characteristics, file storage path patterns, or calling external security scanning engines to perform static analysis of file content to identify and remove more complex security threats. Regardless of the specific rules used, the goal is to proactively identify and remove files that do not meet preset security standards, ultimately retaining a set of static resource files that have been verified as valid.

[0030] After completing security filtering and obtaining a clean set of verified and valid static resource files, the business server needs to establish verifiable integrity credentials for these files. To do this, the business server calculates the file hash value for each retained static resource file. The file hash value can be a fixed-length, unique digital fingerprint calculated using a hash algorithm based on the binary data content of the static resource file. Any minor modification to the file content will cause a significant change in its hash value. One embodiment uses the MD5 algorithm for calculation, but those skilled in the art will understand that other cryptographic hash functions such as SHA-256 are equally applicable. The process of calculating the file hash value is essentially a digital notarization of the identity and integrity of each file.

[0031] Furthermore, the business server is responsible for constructing a resource list. This resource list is used to establish and record the mapping relationship between each verified valid static resource file and its corresponding file hash value, while also recording the logical storage path of the static resource file within the offline resource package. In one embodiment, the resource list can be implemented in JSON format as a collection of key-value pairs. The key can be the relative path of the file within the offline resource package, such as index.html or static / js / main.a1b2c3.js; the value is the file hash value string corresponding to that file. Through this list, any entity possessing the offline resource package and the corresponding list can quickly locate a specific file and verify, by comparing the hash value, whether the file remains consistent with its original state and has not been tampered with.

[0032] After constructing the resource manifest, the business server will perform a repackaging operation to generate a standardized offline resource package. Based on this, all verified and valid static resource files retained in the previous steps, along with the newly generated resource manifest file itself, are packaged into a new compressed file, such as a new ZIP archive. This newly generated package is the standardized offline resource package referred to in this application, and it differs fundamentally from the initial resource package at key levels: it contains only files filtered by security rules and includes an authoritative resource manifest used to verify the integrity of all files. The generation of the standardized offline resource package marks the completion of the validity verification process, producing a secure, self-contained, and verifiable final distribution entity.

[0033] The newly generated offline resource package contains only filtered files and a list of resources, and its structure is well-organized. To facilitate subsequent distribution, the business server can upload this standardized offline resource package to a persistent, highly available distributed storage system, such as a bucket based on object storage services. After successful upload, the business server obtains a stable storage path pointing to this offline resource package from the distributed storage system. This storage path, such as a URL or an object key, will become the basis for clients to subsequently download the offline resource package.

[0034] Step S3300: Generate a global hash value corresponding to the offline resource package based on the resource list, and associate and store the target page identifier, the storage path of the offline resource package and the global hash value to form resource configuration information; After constructing the standardized offline resource package and storing it in the distributed storage system, the business server further generates a global hash value that uniquely represents the entire offline resource package version based on the key intermediate product generated in the aforementioned steps, namely the resource list. The process of generating this global hash value is to aggregate the individual integrity proofs of all static resource files recorded in the resource list into a single, compact digital summary representing the overall state of the entire resource set.

[0035] In one embodiment, the application server first extracts the file hash values ​​of all static resource files recorded in the constructed resource list. A typical structure of the resource list is a mapping relationship where the storage path of the static resource file is the key, and its corresponding file hash value is the value. The application server parses this list, collecting the file hash values ​​from all key-value pairs to form a set of file hash values.

[0036] Subsequently, to ensure the determinism of the global hash values ​​generated each time based on the same set of files, the business server needs to sort this set of file hash values ​​according to a predetermined, unambiguous sorting rule. The sorting rule can be based on multiple dimensions. One direct rule is to sort according to the lexicographical order of the storage paths of the static resource files corresponding to these hash values. Another rule is to directly sort the file hash value strings themselves, for example, by ascending order of their hexadecimal string representation. Regardless of the specific rule used, the goal is to establish a repeatable and deterministic order, ensuring that as long as the content of the resource list is the same, the final data sequence used for calculation will be consistent regardless of the processing order.

[0037] After sorting, the business server concatenates all file hash values ​​in the sorted order to form a single hash string to be calculated. This concatenation process can be a simple string join, or specific delimiters can be inserted between adjacent hash values ​​to enhance robustness. Finally, the business server performs a hash operation on this concatenated hash string. The hash algorithm used in this operation can be the same algorithm used to calculate the hash value of a single file, such as MD5, or a more secure algorithm, such as SHA-256. The result of this hash operation generates the global hash value corresponding to the offline resource package. This global hash value, as a highly condensed digital fingerprint of the integrity of the resource list content and even all files in the entire offline resource package, possesses uniqueness and collision resistance. Any modification to any file recorded in the resource list or its recorded hash value will cause unpredictable changes to the calculated global hash value.

[0038] After generating the global hash value, the business server needs to associate and persistently store the core metadata related to this offline resource package to form the resource configuration information for subsequent client queries and matching. This core metadata includes at least the target page identifier, the storage path of the offline resource package, and its corresponding global hash value. The target page identifier is a string used to uniquely index and identify a specific application page on the server side. The storage path of the offline resource package is the address credential obtained from the distributed storage system in previous steps, used to locate and download the standardized offline resource package. The global hash value is an authoritative digest representing the content of this specific version of the offline resource package.

[0039] The business server stores these three elements in association. In one embodiment, this association storage uses the target page identifier as the primary key or index, and associates the storage path and global hash value of the offline resource package with a record or document in the database as field values. In another embodiment, a data structure can be constructed using the combination of the target page identifier and the global hash value as the key. The purpose of the association storage is to establish a fast query mapping relationship, so that given a target page identifier, the access address and version fingerprint of its currently available and latest offline resource package can be obtained. This data set, namely the resource configuration information referred to in this application, becomes the authoritative data source for the server to manage the offline resource version status of the page and respond to client update requests.

[0040] Step S3400: In response to the client's configuration update request, match the query hash value and query page identifier carried in the request with the resource configuration information, and return the corresponding real-time configuration information according to the matching result so as to load the corresponding page of the query page identifier.

[0041] After the application server builds and stores the resource configuration information for the target page, it enters a standby state, ready to respond to client status queries. When a client, such as a host application running on a user's mobile device, needs to load or update a specific application page, it sends a configuration update request to the application server. The purpose of this request is to obtain the latest resource configuration status for that page from the application server to determine whether to continue using the local cache or to fetch new resources from the network.

[0042] A configuration update request initiated by the client carries at least two key parameters. The first parameter is the query page identifier, which explicitly specifies to the business server the target page the client wants to query or update. The second parameter is the query hash value, which is a global hash value stored locally by the client, derived from the resource configuration information successfully obtained from the business server last time. This query hash value essentially represents the specific version state of the offline resource package currently cached by the client for the corresponding page indicated by the query page identifier; it serves as the credential for version state synchronization between the client and the server.

[0043] After receiving a configuration update request from a client, the business server matches the query hash value and query page identifier carried in the request with its own maintained resource configuration information, and generates and returns the corresponding real-time configuration information based on the matching result. The matching process can begin by locating the corresponding resource configuration information based on the query page identifier. The business server then searches its stored resource configuration information database or index for the latest record associated with that query page identifier, and extracts from this record the global hash value of the latest offline resource package currently maintained by the server for that page, as well as its storage path.

[0044] The subsequent matching operation hinges on comparing the query hash value carried by the client (i.e., the client's historical version state) with the latest global hash value extracted by the server (i.e., the server's current version state). This comparison can be a direct string or numerical comparison. The result clearly indicates whether the client's local state matches the server's latest state, thereby determining the server's subsequent response logic.

[0045] When the matching result indicates that the query hash value is inconsistent with the recorded global hash value, it means that the offline resource package version cached locally by the client is no longer the latest, and the server needs to guide the client to update. In this case, the business server generates first real-time configuration information. The first real-time configuration information includes the storage path of the target resource package to be downloaded for the corresponding page identified by the query page, and the global hash value of the latest offline resource package for the corresponding page. In one embodiment, the storage path of the target resource package is the storage path of the latest offline resource package recorded in the server resource configuration information, instructing the client to perform a full update. In another embodiment, as will be further explained in subsequent embodiments of this application, the server can replace this path with the storage path of an incremental update package according to a more refined strategy to guide the client to perform a more efficient incremental update. However, regardless of the method, the global hash value issued is always the global hash value of the latest offline resource package to ensure that the client's local state is consistent with the latest version recognized by the server after the update is completed. The business server returns the generated first real-time configuration information to the client. Upon receiving this information, the client is instructed to download the target resource package according to the storage path specified in the message. After the download is complete, the client uses the global hash value provided in the message to perform an integrity check on the downloaded resource package—specifically, the final offline resource package after the update. If the check passes, the client updates its local cache with the new resource package and loads the corresponding application page accordingly, thus completing a full closed loop from receiving instructions from the server to executing the update locally.

[0046] When the matching result indicates that the query hash value matches the recorded global hash value, it means that the client has already cached the offline resource package that is exactly the same as the latest version on the server, and no resource download is required. In this case, the business server generates a second immediate configuration message. This second immediate configuration message does not contain the complete configuration of the resource path, but rather a lightweight status indication, such as a specific status code or a short instruction message. Its purpose is to explicitly convey to the client that the configuration has not changed. The business server returns this second immediate configuration message to the client. After parsing this information, the client is instructed to directly use its locally cached resource configuration corresponding to the query hash value to load the corresponding page. This process achieves efficient cache negotiation, avoiding unnecessary data network transmission when resources have not changed, greatly improving response speed and reducing system load.

[0047] Through the above matching and response mechanism, the business server can intelligently handle configuration query requests from a massive number of clients and issue update commands only when necessary. This ensures that all clients can eventually load the correct version page while maximizing network communication efficiency and resource utilization efficiency.

[0048] As can be seen from the above embodiments, this application demonstrates significant advantages in solving the technical problems faced by traditional solutions, including but not limited to: First, this application establishes reliable security and standardization guarantees at the source of offline resource package generation. By responding to release requests and performing a set of validity verification processes on the obtained initial resource packages, it can proactively identify and remove files that do not conform to preset security rules. This ensures that the final standardized offline resource packages contain only verified, valid, and secure static resource files, fundamentally eliminating the risk of malicious or redundant files being distributed to a large number of clients due to oversights in the build process or untrusted input. This significantly improves the security of enterprise-level application distribution content and guarantees the uniformity and standardization of the internal structure of all distribution packages.

[0049] Secondly, this application uses a global hash value as the basis for resource configuration information and intelligent matching mechanisms, improving the efficiency and accuracy of resource configuration updates. The global hash value generated from the resource list within the offline resource package serves as a unique, lightweight fingerprint for that resource package version, constituting resource configuration information along with the page identifier and storage path. When a client initiates a configuration update request, it only needs to carry its locally cached historical hash value as the query hash value. The server can accurately determine the client's resource status by quickly comparing it with the currently stored global hash value, thereby providing real-time configuration information to guide the client in updating the corresponding page. This achieves near-zero-cost cache negotiation, significantly reducing network traffic overhead and server response latency, and solving the resource waste problem caused by frequent downloads of complete configuration files or inefficient network negotiation in traditional solutions.

[0050] Furthermore, the resource configuration information system constructed in this application supports efficient and accurate version status synchronization. The global hash value is not only used for efficient change checks, but also serves as a strong digest of the offline resource package content, ensuring absolute consistency between the client and server's understanding of the resource version. When an update is needed, the server-issued instant configuration information explicitly includes the storage path of the latest resource package and its corresponding global hash value. The client can accurately obtain the target resource for the corresponding page based on this information and use the hash value to verify the integrity and version correctness of the resource after downloading. This strong verification mechanism based on cryptographic hashing makes version management more accurate and reliable, effectively avoiding loading errors caused by version inconsistencies or file corruption, and improving the stability of the entire offline system.

[0051] As can be seen, this application has revolutionized the offline resource package processing flow on the server side, which not only ensures the security and quality of distributed resources from the source, but also greatly optimizes the network transmission efficiency and state synchronization accuracy during the configuration update process, thereby providing a controllable, high-performance, and highly reliable systematic solution for the offline application of multi-terminal, large-scale application pages.

[0052] Based on any embodiment of the method in this application, a validity verification process is performed on the initial resource package, and a standardized offline resource package is constructed based on the verified valid static resource files, including: Step S3210: Download the initial resource package corresponding to the target page from the address associated with the publishing request, and perform an integrity check on the initial resource package; After the business server obtains the initial resource package associated with the publication request for the target page, it enters a specific validity verification process. This process aims to extract a secure, standardized, and verifiable offline resource package from potentially untrusted build artifacts, thus laying the foundation for subsequent accurate distribution and reliable loading. First, the business server needs to download the initial resource package corresponding to the target page from the storage address parsed from the publication request. After downloading, the initial resource package is immediately subjected to integrity verification. Integrity verification is a crucial preliminary step to ensure that the original data obtained by the server is consistent with its publication source and has not been damaged or tampered with during transmission.

[0053] In one embodiment, the publishing request includes not only the storage address of the initial resource package but also the expected hash value of that initial resource package. After downloading, the business server recalculates the hash value of the downloaded file and compares the calculated result with the expected hash value provided in the publishing request. If they match, the verification passes, indicating that the obtained file is complete and reliable; if they do not match, the verification fails, and the subsequent process can be terminated and an error returned. This intercepts unreliable data input at the first moment, preventing further processing based on damaged or forged files.

[0054] Step S3220: Decompress the initial resource package that has passed the integrity check, and filter the files in the decompressed directory according to the preset security file filtering rules to remove files that do not conform to the security file filtering rules and retain the verified and valid static resource files. After the initial resource package passes integrity verification, the application server performs a decompression operation. This decompression restores the compressed initial resource package to its original directory structure within the file system, allowing each static resource file to be accessed and processed independently. The decompressed directory contains not only essential static resource files required to construct the target page, such as Hypertext Markup Language files, script files, stylesheet files, and data files, but may also include temporary files, logs, configuration files, and even potentially security-risk files unintentionally introduced during the build process.

[0055] To ensure the security of the generated offline resource package, the business server actively filters all files in the decompressed directory according to preset security file filtering rules. These security file filtering rules are a predefined set of standards for determining whether a file is allowed to be included in the final offline resource package. In one embodiment, this rule is manifested as a whitelist of secure file types, which is a specific list of file extensions, such as .html, .js, .css, .json, etc. The business server traverses the decompressed directory, checks the extension of each file, and identifies files whose extensions are not in the whitelist as not conforming to the security file filtering rules, removing them from the working directory. In another embodiment, the security file filtering rules can be more complex, such as combining magic numbers in the file content, calling external virus scanning interfaces to perform security checks on the files, or checking whether the file path conforms to a specific security mode.

[0056] Regardless of the specific implementation method used, the goal is to proactively and accurately remove files that do not conform to the rules based on preset security standards, and ultimately retain a set of static resource files that have been verified as safe and valid, thereby ensuring the purity of the offline resource package content.

[0057] Step S3230: Calculate the file hash value of each retained static resource file, and construct a resource list by mapping the storage path of each static resource file to its file hash value; After filtering the files and obtaining a clean set of verified and valid static resource files, the business server needs to generate verifiable integrity credentials for these files. To do this, the business server calculates the file hash value for each of the retained static resource files. The file hash value is a fixed-length digital fingerprint calculated by applying a hash algorithm to the complete binary content of the file; any modification to the file content will cause a significant change in its hash value.

[0058] In one embodiment, MD5 or SHA series algorithms are used for calculation. After calculating the hash values ​​of all files, the business server constructs a resource list. The resource list is a structured data record used to establish and persistently store the precise mapping relationship between the logical storage path of each static resource file within the offline resource package and its corresponding file hash value. One implementation method is to use JSON format, with the file path as the key and the corresponding file hash value as the value, forming a key-value pair set. For example, one entry might be "index.html": "a1b2c3d4e5f67890", and another entry might be "static / js / app.js": "f0e1d2c3b4a59687". This list becomes the "ID card" and "verification code" directory for all files within the offline resource package, serving as the basis for subsequent file-level integrity verification and the generation of package-level global identifiers.

[0059] Step S3240: Repackage the retained static resource files and the resource list into a standardized offline resource package, and store the offline resource package in a distributed storage system to obtain its storage path.

[0060] After constructing the resource manifest, the business server performs a repackaging operation to generate a standardized offline resource package. This operation packages all verified and valid static resource files retained in the previous steps, along with the newly generated resource manifest file itself, into a new compressed file, which can be in Zip or RAR format. This newly generated compressed file is the standardized offline resource package, with a deterministic and secure internal structure, and includes complete metadata for self-verification. To ensure stable access by clients, the business server needs to store this newly generated standardized offline resource package in a highly available, scalable distributed storage system, such as an object storage service.

[0061] The business server uploads the offline resource package file to the storage location specified by the distributed storage system. Upon successful upload, the distributed storage system returns a unique and stable storage path pointing to the file. This storage path, such as an HTTP or HTTPS URL, or a unique object key within the object storage service, will become the final basis for the client to locate and download the offline resource package. At this point, a complete processing flow from receiving the raw build artifacts to producing a secure, standardized, and distributable offline resource package is completed.

[0062] The above embodiments, applied as an organic whole, transform the abstract methodological steps of this application into a concrete, executable technical implementation with multiple layers of defense, addressing the issues of security and standardization of offline resource package sources. This embodiment forms a tightly linked, progressively advancing quality control chain, from source verification during the download process to proactive security filtering after decompression, then to establishing cryptographically-level integrity credentials for clean files and generating a self-describing resource list, ultimately producing a standardized package with a trusted storage path. This chain not only ensures the absolute security and purity of the content within each offline resource package ultimately distributed to a massive number of clients, but also, through built-in list and hash mechanisms, gives the resource packages independently verifiable integrity and immutability. Therefore, at the technical implementation level, it fundamentally eliminates the risk of malicious file propagation and version content contamination, building a solid security foundation for the reliable operation of the entire offline system.

[0063] Based on any embodiment of the method in this application, generating a global hash value corresponding to the offline resource package based on the resource list includes: Step S3310: Obtain the file hash values ​​of all static resource files recorded in the resource list; After the business server constructs a standardized offline resource package containing a resource list, a series of specific calculation steps need to be performed based on the constructed resource list in order to generate a global hash value that can uniquely and compactly identify the entire offline resource package version.

[0064] First, the application server extracts all file hash values ​​recorded in the resource manifest. The resource manifest is typically organized as key-value pairs, where the key is the logical storage path of a static resource file within the offline resource package, and the value is the file hash value corresponding to that file. The application server parses the data structure of the resource manifest, traverses all key-value pairs, and collects the values—the file hash values ​​of each static resource file—one by one, forming a set containing all file hash values. This set constitutes the original data foundation for calculating the global hash value, ensuring that the generation of the global hash value is closely dependent on the integrity status of each specific file within the offline resource package.

[0065] Step S3320: Sort and concatenate all file hash values ​​according to the predetermined sorting rules to form a hash string to be calculated; After obtaining all file hash values, to ensure absolute consistency in the global hash value calculated based on the exact same set of files each time, the business server needs to sort the set of file hash values ​​according to a predetermined, deterministic sorting rule. The purpose of sorting is to eliminate the randomness caused by different collection orders of hash values, thus standardizing the input data sequence. The predetermined sorting rule can have various specific implementations.

[0066] In one embodiment, the files can be sorted lexicographically according to the storage paths of the static resource files corresponding to their hash values ​​recorded in the resource manifest. For example, if the resource manifest records the hash values ​​of files a.js, b.css, and index.html in that order, the hash values ​​are arranged according to the lexicographical order of the path strings a.js, b.css, and index.html. In another embodiment, the file hash value strings themselves can be sorted directly, for example, by ascending or descending order according to the hexadecimal string representation of the hash value. Regardless of the specific rule used, it must be predefined and consistently followed within the system to ensure that resource manifests with the same content always produce the same sorting result.

[0067] After sorting, the business server concatenates all sorted file hash values ​​in their order to form a single hash string to be calculated. The concatenation operation is the process of joining strings. A simple implementation is to directly append the subsequent hash value string to the end of the previous hash value string. In another embodiment, a specific separator that does not appear in the hash value itself, such as a colon, semicolon, or newline character, can be inserted between adjacent file hash values ​​to enhance the robustness and readability of the string and avoid problems caused by ambiguous boundaries. This concatenated hash string is essentially a serialized data block representing the overall state of the file set, organized in a defined order from multiple discrete fingerprints representing the integrity of individual files.

[0068] Step S3330: Perform a hash operation on the hash string to generate a global hash value that serves as a unique identifier for the offline resource package.

[0069] Finally, the business server performs a hash operation on this concatenated hash string. The hash algorithm used in this operation can be the same as the algorithm used to calculate the hash value of a single file, such as the MD5 algorithm, or a different, generally more secure algorithm, such as the SHA-256 algorithm. The hash operation on the hash string generates a new hash value of fixed length. This newly generated hash value is defined as the global hash value corresponding to the offline resource package. Due to the characteristics of hash algorithms, any slight modification to the original hash string, including changing the hash value of any file or altering the order of the hash values, will lead to a significant and unpredictable change in the final calculated global hash value. Therefore, this global hash value possesses the core attribute of uniquely identifying the entire offline resource package. It is not only a highly condensed summary of the integrity of all file content within the package but also implicitly contains structural information about the file list, sensitively reflecting any changes to the overall offline resource package and serving as a version indicator to some extent.

[0070] The above embodiments provide a specific and reliable technical implementation path for solving the technical problems of efficient and accurate distribution of resource configuration information and version synchronization. This embodiment transforms the file hash value, representing the integrity of individual files, into a serialized intermediate representation through deterministic sorting and concatenation. This intermediate representation is then subjected to another hash operation to generate a global hash value. This process ensures that the global hash value is strongly correlated with every file within the package and possesses the characteristics of fixed length, ease of transmission, and comparison. This global hash value, as a digital fingerprint of the offline resource package, provides a unique, authoritative, and unforgeable technical credential for lightweight, high-precision version status comparison and cache negotiation between the server and client. This achieves near-zero-cost configuration update checks while fundamentally guaranteeing the absolute accuracy and consistency of version management.

[0071] Based on any embodiment of the method in this application, the query hash value and query page identifier carried in the request are matched with the resource configuration information, and the corresponding real-time configuration information is returned according to the matching result, including: Step S3410: Compare and match the query hash value carried in the configuration update request with the global hash value recorded in the resource configuration information of the corresponding page of the query page identifier carried in the request, and determine the matching result; wherein, the query hash value is the historical global hash value that has been cached locally on the client. After the business server builds and persistently stores resource configuration information including the target page identifier, offline resource package storage path, and global hash value, the server is ready to respond to configuration update requests initiated by clients. When a client, such as a host application running on a user's terminal, needs to load a specific page or check if its resource configuration has been updated, it will send a configuration update request to the business server. This request is the starting point for synchronizing the resource configuration status of a specific page between the client and the server.

[0072] The configuration update request carries key parameters for the server to match and make decisions. The first key parameter is the query page identifier. This identifier is a string whose value corresponds to the target page identifier previously used by the server to associate stored resource configuration information, explicitly informing the business server which application page the client wants to query or update this time. For example, for an event details page, its query page identifier could be a string such as campaign_detail_v2. The second key parameter is the query hash value. This query hash value is not generated temporarily, but is a specific string corresponding to the query page identifier, read by the client from its local storage. This string originates from the resource configuration information that the client successfully received and processed from the business server during the last time it accessed the page; specifically, it is the global hash value contained in that resource configuration information. Therefore, the query hash value is essentially a digital fingerprint of the offline resource package version of the page referred to by the query page identifier, cached locally on the client, representing the historical version state currently held by the client.

[0073] After receiving a configuration update request, the business server first needs to parse it to extract the query page identifier and query hash value. Next, the business server initiates a matching process. The first step of this matching process is to quickly search and locate the target page identifier within its stored resource configuration information. The resource configuration information maintained by the business server can be organized in a database, cache, or other key-value storage system, where the target page identifier serves as the primary key or index for retrieval. The business server uses the received query page identifier as input to perform a query operation. In one embodiment, the business server searches the corresponding table in the database for the latest record whose target page identifier field value completely matches the received query page identifier. This record contains the latest resource configuration information currently maintained by the server for that page, including two important fields: the record's global hash value and the storage path of the offline resource package.

[0074] After successfully retrieving the corresponding resource configuration information record, the matching process enters the comparison and matching phase. The business server directly compares the query hash value carried in the configuration update request with the global hash value recorded in the resource configuration information record corresponding to the page identified by the query page, retrieved from the database. The recorded global hash value represents the unique identifier of the latest offline resource package version for that page, as authoritatively recognized by the server. The query hash value, on the other hand, represents the identifier of the client's locally cached version. The comparison operation itself is a simple string equivalence comparison. The business server calls a string comparison function to determine whether the query hash value is completely consistent with the recorded global hash value.

[0075] The result of this comparison and matching is deterministic, directly determining the server's subsequent response branch. If the comparison result is consistent, it indicates that the version cached locally on the client is exactly the same as the latest version on the server. If the comparison result is inconsistent, it clearly indicates that the version currently held by the client is outdated compared to the latest version on the server. The process of determining the matching result is the process of completing this string comparison and clarifying its consistency state. The business server uses this consistency state, i.e., the matching result, as a clear logical judgment output to drive the subsequent logic for generating real-time configuration information.

[0076] Step S3420: When the matching result indicates that the query hash value is inconsistent with the recorded global hash value, generate first real-time configuration information, which includes the storage path of the target resource package to be downloaded for the corresponding page of the query page identifier and the global hash value of the latest offline resource package of the corresponding page. When the business server determines through comparison that the query hash value sent by the client is inconsistent with the global hash value recorded in the resource configuration information, it indicates that the offline resource package version cached locally by the client is no longer up-to-date. The server needs to generate and return an explicit instruction to guide the client to complete the resource update. This instruction is carried in the form of first real-time configuration information. The first real-time configuration information is a structurally complete and semantically clear data object containing all the key information required for the client to successfully obtain and verify the new version of the resource.

[0077] The initial configuration information includes an essential field that specifies the storage path of the target resource package that the client needs to download. In a basic full update scenario, such as the first access to the corresponding page, this storage path directly originates from the resource configuration information record retrieved by the business server during the comparison process. Specifically, this record contains the complete access address of the latest version of the standardized offline resource package in the distributed storage system. Upon receiving this information, the client will initiate a network download based on this path to obtain the complete offline resource package file.

[0078] Meanwhile, the first real-time configuration information also includes another crucial field: the global hash value of the latest offline resource package for the corresponding page. This global hash value, along with the aforementioned storage path, originates from the same resource configuration information record. Its function is to serve as authoritative proof for the client to verify whether it has ultimately obtained an offline resource package locally that is completely identical to the version specified by the server. Specifically, after completing the operation according to the instructions, the client needs to verify the complete offline resource package it ultimately holds locally, which is ready to be used to load the page; the benchmark value used for this verification is this global hash value.

[0079] In addition, the first real-time configuration information may also include an incremental method field to indicate the corresponding incremental method of the target resource package, including full update or incremental update, so that the client knows how to apply the target resource package and how to perform the corresponding hash verification.

[0080] The client's application logic for this global hash value may vary depending on the type of the target resource package (full or incremental), but the final verification object is always the complete offline resource package. In one embodiment, when the storage path of the target resource package points to a full offline resource package, the client directly downloads the file. After the download is complete, the client immediately calculates the hash value of the downloaded complete offline resource package file and compares the calculation result with the global hash value provided in the first real-time configuration information. If they match, it proves that the downloaded resource package is complete, has not been tampered with, and its version is consistent with the version the server intends to distribute. The client then uses this new package to update its local cache.

[0081] In another embodiment, as detailed later in this application, when the storage path of the target resource package points to an incremental update package, the client first downloads this incremental update package. Then, the client applies this incremental update package to its existing local historical offline resource packages, generating a complete, latest version of the offline resource package locally using a binary difference synthesis algorithm. After this synthesis operation is completed, the client does not verify the incremental update package itself, but instead calculates the hash value of the synthesized, locally complete, latest offline resource package. The client then compares this calculated hash value with the global hash value provided in the first real-time configuration information. If they match, it proves that the local synthesis operation was successful, and the generated offline resource package is completely consistent with the latest version specified by the server. The client then updates its local resource configuration with this newly synthesized complete package.

[0082] Step S3430: Return the first real-time configuration information to the client to instruct it to download the target resource package, verify and update the resource configuration of the corresponding page that has been cached locally according to the global hash value, and then load the corresponding page.

[0083] After the business server generates first real-time configuration information containing the target resource package storage path and the latest offline resource package global hash value, the server encapsulates this information into a response and returns it to the client. In one embodiment, the server uses the Hypertext Transfer Protocol (HTTP) to construct the response. The server uses the first real-time configuration information as the body payload of the HTTP response. This payload can be serialized according to a preset format, for example, it can use JSON format, defining the target resource package storage path and global hash value as specific fields in the JSON object, such as "package_url" and "global_hash". When constructing the HTTP response, the server sets the correct status code, such as status code 200, indicating that the client's configuration update request has been successfully processed and a valid response body has been included. At the same time, the server usually sets appropriate response headers, such as setting the Content-Type header to application / json, to tell the client how to correctly parse the response body. After completing the construction of the response, the server sends the HTTP response back to the requesting client through the established network connection.

[0084] Upon receiving this HTTP response, the client parses it. First, the client checks the HTTP status code to confirm successful request processing. Then, based on the format indicated by the Content-Type header, it deserializes the response body to extract the target resource package storage path and global hash value contained in the initial configuration information. Afterward, the client initiates a resource download based on the target resource package storage path parsed from the configuration information. This is typically a separate network request from the previous configuration query request. The downloaded target resource package, depending on the server-side decision, can be a complete offline resource package or an incremental update package.

[0085] After successfully downloading the target resource package, the client enters the resource verification and application phase. Based on the global hash value obtained from the first real-time configuration information, it performs integrity verification on the final offline resource package generated locally. The ultimate goal of this operation is to ensure that the content of the offline resource package held locally by the client is absolutely consistent with the latest version specified by the server. The specific verification logic varies depending on the type of the downloaded target resource package. In one embodiment, if the target resource package is a complete offline resource package, the client directly calculates its global hash value for the downloaded offline resource package file. The client calls the same hash algorithm used by the server to generate the global hash value, for example, performing SHA-256 calculation on the file content to obtain the hash value. Subsequently, the client compares this calculated hash value with the global hash value received from the first real-time configuration information. If the two match, it proves that the complete offline resource package is intact and error-free, and the verification passes.

[0086] In another embodiment, if the target resource package is an incremental update package, the client needs to perform an incremental update first. The client finds the historical offline resource package corresponding to the query hash value locally. Then, the client calls a binary difference synthesis algorithm, such as applying the bsdiff algorithm, to apply the downloaded incremental update package to the local historical offline resource package, thereby generating a new, complete offline resource package file locally. After this synthesis process is successfully completed, the client does not verify the incremental update package, but instead calculates the global hash value of the newly generated, complete offline resource package file. The client compares the calculated hash value with the global hash value received from the first real-time configuration information. If they match, it proves that the incremental update synthesis operation was successful, the newly generated offline resource package is completely consistent with the latest version specified by the server, and the verification passes.

[0087] Regardless of the path chosen, once verification passes, the client completes the update of the local resource configuration for the corresponding page. The client stores the verified offline resource package file (either fully downloaded or incrementally synthesized) in a designated local cache directory and updates its local version status record accordingly, primarily the global hash value of the updated offline resource package. Subsequently, when a user needs to load the corresponding page, the client can utilize this latest cached offline resource package, intercepting resource requests through containers such as WebView and providing the file from the local cache, thus achieving fast page loading.

[0088] The above embodiments form a complete, closed-loop technical chain, from the client initiating a request with accurate historical version credentials (i.e., query hash value), to the server performing rapid and definitive comparison and matching, to generating configuration information containing clear download instructions and final acceptance criteria based on the matching results, and finally, the client completing the download, verification, and local status update according to the instructions. This chain not only achieves a high degree of automation in resource configuration updates, but more importantly, by using lightweight hash comparison as a decision-making mechanism, it achieves near-zero-cost instant response when the configuration remains unchanged. When the configuration changes, whether the changes are distributed in a full or incremental manner, it ensures the absolute accuracy of the client's final state. This ensures accurate version management while greatly optimizing network transmission efficiency and reducing the processing load on both the client and server, providing a reliable and efficient systemic solution for offline resource updates in large-scale, multi-terminal applications.

[0089] Based on any embodiment of the method in this application, the query hash value carried in the configuration update request is compared and matched with the global hash value recorded in the resource configuration information of the corresponding page of the query page identifier carried in the request. After determining the matching result, the method includes: Step S3440: When the matching result indicates that the query hash value is consistent with the recorded global hash value, generate status information indicating that the configuration has not changed as the second real-time configuration information; When the business server compares the query hash value sent by the client with the global hash value recorded in the resource configuration information and determines that they match, it indicates that the offline resource package version currently cached locally by the client is exactly the same as the latest version maintained by the server. In this case, the client does not need to download any new resource files. The server's responsibility is to efficiently and explicitly notify the client of this status, thereby avoiding unnecessary subsequent network downloads by the client and saving network bandwidth and client processing resources. This responsibility is accomplished by generating and distributing a second real-time configuration message.

[0090] The second immediate configuration message serves to convey a clear and unambiguous instruction to the client: use the locally cached resource configuration. To deliver this instruction accurately and efficiently, the second immediate configuration message is designed as a lightweight data payload primarily carrying a status indication. There are various specific implementations for generating this status message. In one embodiment, the second immediate configuration message can be a predefined status code with specific semantics. For example, the server can generate an HTTP status code such as 304 Not Modified. In the HTTP protocol, status code 304 is specifically used to indicate that the resource requested by the client has not been modified since its last request, and the client should directly use its locally cached version. When constructing the HTTP response, the server sets this status code in the response line, while the response body can be empty or contain only the necessary protocol headers, thus forming an extremely lightweight response.

[0091] In another embodiment, the second immediate configuration information can be a structured, short message encapsulated in the response body. For example, the server generates a simple JSON object, such as {"code": 1, "message": "NOT_CHANGED"}, where the code field value of 1 indicates that the configuration has not changed, and the message field provides a readable description. When returning this JSON object, the server also sets an HTTP status code indicating success, such as 200 OK. This approach gives the server greater flexibility and allows for the definition of richer status semantics.

[0092] Regardless of whether status codes or structured messages are used, the logic for generating the second real-time configuration information is directly driven by the matching result. Once the server determines that the query hash value matches the record's global hash value, it immediately triggers the information generation process. The server calls the corresponding logic module, which combines status indication data that conforms to the preset protocol specifications. The generation process is deterministic and does not involve additional queries to resource files or databases, therefore the latency is extremely low. The generated second real-time configuration information is then encapsulated and prepared to be returned to the client.

[0093] Step S3450: Return the second real-time configuration information to the client to instruct it to load the corresponding page using the locally cached resource configuration.

[0094] After the business server generates status information indicating that the configuration has not changed (i.e., the second immediate configuration information), it needs to effectively return this information to the client to complete the response loop for this configuration update request. The server encapsulates this information into a complete network response. After constructing this response, the server sends it back to the client that initiated the request.

[0095] After receiving the server's response, the client initiates the parsing process. The client first checks the HTTP status code. If the status code is 304 Not Modified, the client interprets this as a special success response, meaning the server confirms its local cache is up-to-date. The client reads relevant cache control information from the HTTP response headers and updates its local cache metadata regarding the resource configuration, such as cache expiration time. If the status code is 200 OK, the client parses the response body based on the Content-Type header. The client deserializes the JSON-formatted response body, extracting the defined status code and message fields. By parsing the code field value as 1 or the message field as NOT_CHANGED, the client logically understands that the configuration has not changed.

[0096] Regardless of how the client parses the instruction indicating no configuration change (status code 304 or a specific field in the message body), its subsequent behavior is consistent: the client does not initiate any network download requests for the offline resource package. Instead, the client directly uses its locally cached resource configuration. Specifically, the client reads the offline resource package file and other cached metadata associated with the queried page identifier and query hash value from its local storage. The client application's internal routing and loading logic instructs page containers such as WebView to load the entry file, such as index.html, from this local offline resource package. The page container then intercepts all network requests for that page resource and provides the corresponding file content from the local offline resource package, thus completing the page loading and rendering. The entire process is completed locally without any additional network I / O waiting, achieving instant page loading.

[0097] The above embodiments transform the logical result of a consistent hash value comparison into an extremely lightweight network response (such as a 304 status code). This minimizes the information synchronization overhead between the server and client in most routine query scenarios where no actual changes occur in resource configuration. This not only significantly reduces unnecessary network traffic and server processing load, but more importantly, it enables the client to confirm the validity of its local cache almost in real time and immediately trigger the local loading process. This achieves zero-wait configuration checks and instantaneous page loading at the user experience level, further providing performance optimization guarantees for the efficient offline resource update system constructed in this application.

[0098] Based on any embodiment of the method in this application, generating first on-the-spot configuration information includes: Step S3421: Determine the version of the offline resource package currently in use by the client based on the query page identifier and the query hash value; Once the business server has determined the need to generate the first real-time configuration information and identified the target version to be distributed (i.e., the latest version), a more optimized processing flow can be executed. This flow aims to provide incremental update packages to clients as much as possible, reducing the amount of data they download. This flow begins by determining the client's current precise version status. The business server determines the version of the offline resource package currently being used by the client based on the query page identifier and query hash value carried in the client's configuration update request. The query hash value is a global hash value from the client's historical configuration, uniquely identifying a specific offline resource package version.

[0099] The application server can maintain a version mapping list, associating the global hash value of each published offline resource package with its corresponding, more readable version identifier (e.g., semantic version number v1.2.0). By querying this mapping list, the application server can obtain the explicit version identifier of the offline resource package corresponding to that hash value, and this version is determined to be the version currently used by the client. For example, if the hash value is found to be abc123 corresponding to version v2.0.0, then the client's current version is v2.0.0.

[0100] Step S3422: Determine whether there is an incremental update package to upgrade the current version to the latest version. If there is no incremental update package, generate an incremental update package based on the binary difference data of the offline resource packages of the current version and the latest version. After determining the client's current version, the business server needs to check if an incremental update package exists that allows direct upgrades from the current version to the target latest version. This determination is based on the incremental update package inventory maintained by the business server. The server can pre-calculate and store incremental update packages for some common and important version upgrade paths. In one embodiment, the server maintains an incremental update package index table, which records available incremental update packages, their applicable source versions (base versions), target versions, and their storage paths. The business server queries this index table with the current version as the source version and the latest version as the target version. If a matching record is found, it indicates the existence of an available, pre-generated incremental update package, and the server can directly obtain its storage path. If no record is found, it indicates that no readily available incremental update package exists.

[0101] When the determination result indicates that no pre-generated incremental update package exists, the application server can initiate the process of dynamically generating the incremental update package. This process requires the server to obtain the complete offline resource package files corresponding to the client's currently used version and the latest version. The application server locates and obtains the offline resource package files for these two versions using its maintained version-to-offline resource package file mapping. After obtaining the two files, the application server calls a binary difference algorithm, such as the bsdiff algorithm, to perform calculations on the two files. This algorithm analyzes the binary data differences between the two version files and generates a patch file containing only these difference data; this patch file is the dynamically generated incremental update package.

[0102] After generating the incremental update package, the business server uploads the package to the distributed storage system to obtain its stable storage path, and records the information of this newly generated incremental update package (source version, target version, storage path) in the incremental package index table for use in subsequent requests for the same upgrade path, thereby avoiding duplicate calculations.

[0103] Step S3423: When the incremental update package exists or is generated, the storage path of the incremental update package is used as the storage path of the target resource package in the first real-time configuration information, and the global hash value of the offline resource package corresponding to the latest version is provided, and the update method is marked as incremental update.

[0104] After the preceding steps determine the existence of an incremental update package, or dynamically generate one, the server ultimately identifies a usable incremental update package and its storage path. At this point, the first real-time configuration information generated or prepared by the business server requires special processing.

[0105] Specifically, in the first real-time configuration information, the storage path field for the target resource package no longer contains the path to the complete offline resource package, but instead contains the storage path to this incremental update package. Simultaneously, the business server must provide the global hash value of the offline resource package corresponding to the target version, i.e., the latest version. This global hash value is used by the client to perform eventual consistency verification on the synthesized result after applying the incremental package locally and synthesizing the complete new package. Furthermore, the business server must explicitly indicate in the first real-time configuration information that this update method is an incremental update. This annotation can be achieved by adding a specific field to the information structure, for example, adding a field named `update_type` and setting its value to `incremental`. In another embodiment, it can also be implicitly indicated as an incremental package through a specific resource package path prefix or protocol.

[0106] The first real-time configuration information generated in this way accurately guides the client to perform incremental updates: the client downloads the incremental package according to the path, applies the synthesis, and uses the provided global hash value to verify the synthesized new package, thereby completing an efficient and accurate version upgrade.

[0107] The above embodiments, based on the determination of the need for an update, introduce a layer of intelligent decision-making and on-demand production capabilities. By judging and dynamically generating incremental update packages, it ensures that, under technically feasible conditions, client version upgrades can always be completed with the minimum amount of data (only the differing parts). This not only significantly saves users' network traffic, especially in mobile network environments, but also reduces client download waiting time and server outbound bandwidth pressure. Simultaneously, this mechanism, by providing a global hash value of the target version as the final verification standard, fundamentally guarantees that the results of the incremental update process are completely consistent with the full update result, eliminating the risk of version inconsistencies caused by incremental synthesis errors. Thus, while significantly improving update efficiency, it uncompromisingly ensures the accuracy and reliability of version management, representing a deep optimization and concrete implementation of the goal of efficient and accurate updates.

[0108] Based on any embodiment of the method in this application, after returning the corresponding real-time configuration information according to the matching result, the method includes: Step S4100: Receive page loading performance data reported by the client and store it in the performance monitoring database. The page loading performance data includes the global hash value of the current version of the corresponding page, the first drawing time, the first content drawing time, and the loading result. After the business server processes the client's configuration update request and issues the immediate configuration information, a closed-loop process for performance monitoring and alerting is further included to evaluate and ensure the loading experience of offline resource packages in a real user environment. This process begins by receiving data reports from the client.

[0109] During or after successfully loading and rendering the corresponding page, the client collects page loading performance data and reports it to the business server via a separate network interface or along with the next configuration request. The received page loading performance data may include the global hash value of the current version of the corresponding page, the first render time, the first content render time, and the loading result. The global hash value of the current version refers to the global hash value of the offline resource package actually used by the client when loading the page. The first render time and the first content render time are core performance indicators for measuring page loading speed, representing the time elapsed for the first pixel rendering and the first rendering of meaningful content (such as text or images) on the screen, respectively, usually measured in milliseconds. The loading result is a marker indicating whether the page loading was successful or failed, such as success, failure, or timeout. After receiving this data, the business server stores it in a dedicated performance monitoring database. During storage, the global hash value of the current version is used as one of the key indexes or partition keys to enable efficient aggregation and querying of data by version in subsequent operations.

[0110] Step S4200: Based on the historical page loading performance data under the same global hash value in the performance monitoring database, calculate the average loading performance index of the offline resource package of the corresponding page; After accumulating historical page loading performance data under the same global hash value in the performance monitoring database, the business server can periodically or on demand trigger analysis tasks to calculate the average loading performance metrics of the corresponding page's offline resource package. Specifically, the calculation involves querying the database for all performance data records labeled with that specific global hash value. Then, the business server performs statistical analysis on the performance metric fields in these records. For the first-draw time, the calculation can be the arithmetic mean of that time value across all successfully loaded records. The arithmetic mean of the first-content-draw time is also calculated. The loading results can be used to calculate the success rate of that version, for example, the number of successful draws divided by the total number of reports. Finally, for the offline resource package identified by this global hash value, the business server generates one or more quantified average loading performance metrics, such as an average first-draw time of 1200 milliseconds, an average first-content-draw time of 1800 milliseconds, and a loading success rate of 99.5%. These metrics objectively reflect the overall performance of that specific version of the offline resource package among real users.

[0111] Step S4300: Determine whether the average loading performance index is lower than the corresponding preset performance threshold. If it is lower than the performance threshold, generate performance alarm information for the offline resource package identified by the global hash value.

[0112] After calculating the average loading performance metrics, the business server can compare them with preset performance thresholds to determine whether the performance of this version is acceptable. Performance thresholds are predefined standard values ​​used to define whether performance meets the requirements, and can be set separately for different performance metrics. For example, a threshold of 2000 milliseconds can be set for the average first-draw time, 3000 milliseconds for the average first-content-draw time, and 99% for the loading success rate.

[0113] The business server compares each calculated average loading performance metric with its corresponding performance threshold. If any average loading performance metric falls below its corresponding performance threshold, the version's performance is deemed substandard. For example, if the calculated average first content rendering time is 3200 milliseconds, exceeding the 3000 millisecond threshold, it is considered below performance standards. Once this determination is made, the business server generates a performance alarm for the offline resource package identified by that global hash value. The performance alarm includes at least the global hash value that triggered the alarm, the substandard performance metric and its specific value, and the relevant threshold. After generating the alarm, the business server can distribute this alarm information to relevant operations personnel or alarm platforms through integrated event buses, message queues, email, instant messaging tools, etc., for timely intervention, analysis, and handling.

[0114] The above embodiments construct a complete monitoring closed loop, from client-side data collection and loading, server-side version-based aggregation and analysis, to threshold-based intelligent alerts. Utilizing the natural link of global hash values, it accurately pinpoints online performance issues to specific offline resource package versions, transforming the root cause identification of performance rollbacks and loading failures from guesswork to precise tracing. By setting and comparing performance thresholds, it can automatically identify versions with potential performance risks and proactively issue alerts, thus shifting the operation and maintenance mode from reactive post-event troubleshooting to proactive real-time discovery and even pre-event warnings. This not only significantly improves the timeliness of problem discovery but also provides data-driven decision-making basis for continuous evaluation and optimization of offline resource package quality, thereby significantly enhancing the overall controllability and stability of the offline solution while ensuring its high efficiency.

[0115] Please see Figure 3 According to one aspect of this application, a page offline resource package processing apparatus includes a publishing response module 3100, a security reconstruction module 3200, a configuration construction module 3300, and an update response module 3400. The publishing response module 3100 is configured to respond to a publishing request for a target page and obtain an initial resource package for implementing the target page, the initial resource package containing static resource files constituting the target page. The security reconstruction module 3200 is configured to perform validity verification processing on the initial resource package and construct a standardized offline resource package based on the verified valid static resource files, the offline resource package including verified... The system includes a static resource file and a resource list, the resource list including the storage path and file hash value of the static resource file; the configuration construction module 3300 is configured to generate a global hash value corresponding to the offline resource package based on the resource list, and associate and store the target page identifier, the storage path of the offline resource package and the global hash value to form resource configuration information; the update response module 3400 is configured to respond to the client's configuration update request, match the query hash value and query page identifier carried in the request with the resource configuration information, and return the corresponding real-time configuration information according to the matching result, so as to load the corresponding page of the query page identifier.

[0116] Based on any embodiment of the device in this application, the security reconstruction module 3200 includes: a completeness verification module, configured to download an initial resource package corresponding to the target page from the address associated with the publishing request, and perform completeness verification on the initial resource package; a decompression and filtering module, configured to decompress the initial resource package that has passed the completeness verification, and filter the files in the decompressed directory according to preset security file filtering rules to remove files that do not conform to the security file filtering rules and retain the verified and valid static resource files; a list construction module, configured to calculate the file hash value of each retained static resource file, and construct a resource list by mapping the storage path of each static resource file to its file hash value; and a packaging and storage module, configured to repackage the retained static resource files and the resource list into a standardized offline resource package, and store the offline resource package in a distributed storage system to obtain its storage path.

[0117] Based on any embodiment of the device in this application, the configuration construction module 3300 includes: a hash extraction module, configured to obtain the file hash values ​​of all static resource files recorded in the resource list; a character concatenation module, configured to sort and concatenate all file hash values ​​according to a predetermined sorting rule to form a hash string to be calculated; and a global hash module, configured to perform a hash operation on the hash string to generate a global hash value as a unique identifier of the offline resource package.

[0118] Based on any embodiment of the device in this application, the update response module 3400 includes: a comparison and matching module, configured to compare and match the query hash value carried in the configuration update request with the global hash value recorded in the resource configuration information of the corresponding page of the query page identifier carried in the request, and determine the matching result; wherein, the query hash value is a historical global hash value cached locally by the client; a change processing module, configured to generate first real-time configuration information when the matching result indicates that the query hash value is inconsistent with the recorded global hash value, the information including the storage path of the target resource package to be downloaded for the corresponding page of the query page identifier and the global hash value of the latest offline resource package of the corresponding page; and a first return module, configured to return the first real-time configuration information to the client to instruct it to download the target resource package, and after verifying and updating the resource configuration of the corresponding page cached locally according to the global hash value, load the corresponding page.

[0119] Based on any embodiment of the device in this application, following the comparison and matching module, the device further includes: a no-change processing module, configured to generate status information indicating that the configuration has not changed as second real-time configuration information when the matching result indicates that the query hash value is consistent with the recorded global hash value; and a second return module, configured to return the second real-time configuration information to the client to instruct it to load the corresponding page using the locally cached resource configuration.

[0120] Based on any embodiment of the device in this application, the change processing module includes: an in-use determination module, configured to determine the in-use version of the offline resource package currently used by the client based on the query page identifier and the query hash value; an incremental generation module, configured to determine whether there is an incremental update package that upgrades the in-use version to the latest version, and if there is no incremental update package, generate an incremental update package based on the binary difference data of the offline resource packages of the in-use version and the latest version; and an incremental configuration module, configured to, when the incremental update package exists or is generated, in the first real-time configuration information, use the storage path of the incremental update package as the storage path of the target resource package, provide the global hash value of the offline resource package corresponding to the latest version, and mark the update method as incremental update.

[0121] Based on any embodiment of the device in this application, the update response module 3400 further includes: a monitoring receiving module, configured to receive page loading performance data reported by the client and store it in a performance monitoring database, wherein the page loading performance data includes the global hash value of the current version of the corresponding page, the first rendering time, the first content rendering time, and the loading result; an indicator calculation module, configured to calculate the average loading performance indicator of the offline resource package of the corresponding page based on historical page loading performance data under the same global hash value in the performance monitoring database; and a performance alarm module, configured to determine whether the average loading performance indicator is lower than a corresponding preset performance threshold, and when it is lower than the performance threshold, generate performance alarm information for the offline resource package identified by the global hash value.

[0122] Another embodiment of this application also provides an electronic device. For example... Figure 4 The diagram shows the internal structure of an electronic device. This electronic device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database can store information sequences, and when executed by the processor, the computer-readable instructions enable the processor to implement a method for processing offline page resource packages.

[0123] The processor of this electronic device provides computing and control capabilities to support the operation of the entire device. The memory of this electronic device can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the offline page resource package processing method of this application. The network interface of this electronic device is used for communication with a terminal.

[0124] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0125] In this embodiment, the processor is used to execute... Figure 3 The specific functions of each module are described, and the memory stores the program code and various data required to execute the above modules or sub-modules. The network interface is used to realize data transmission between user terminals or servers. In this embodiment, the non-volatile readable storage medium stores the program code and data required to execute all modules in the page offline resource package processing device of this application, and the server can call the server's program code and data to execute the functions of all modules.

[0126] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the page offline resource package processing method of any embodiment of this application.

[0127] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A method for processing offline resource packages for web pages, characterized in that, include: In response to a publish request for a target page, an initial resource package for implementing the target page is obtained, the initial resource package containing static resource files constituting the target page; The initial resource package is subjected to validity verification. Based on the verified valid static resource files, a standardized offline resource package is constructed. The offline resource package includes the verified valid static resource files and a resource list. The resource list includes the storage path and file hash value of the static resource files. Based on the resource list, a global hash value corresponding to the offline resource package is generated. The target page identifier, the storage path of the offline resource package, and the global hash value are associated and stored to form resource configuration information. In response to a client's configuration update request, the query hash value and query page identifier carried in the request are matched with the resource configuration information. Based on the matching result, the corresponding real-time configuration information is returned so that the corresponding page of the query page identifier can be loaded.

2. The method for processing offline resource packages for web pages according to claim 1, characterized in that, Perform validity verification on the initial resource package, and construct a standardized offline resource package based on the verified valid static resource files, including: Download the initial resource package corresponding to the target page from the address associated with the release request, and perform an integrity check on the initial resource package; The initial resource package that has passed the integrity check is decompressed. According to the preset security file filtering rules, the files in the decompressed directory are filtered to remove files that do not conform to the security file filtering rules and retain the verified and valid static resource files. Calculate the file hash value of each retained static resource file, and construct a resource list by mapping the storage path of each static resource file to its file hash value; The retained static resource files and the resource list are repackaged into a standardized offline resource package, and the offline resource package is stored in a distributed storage system to obtain its storage path.

3. The method for processing offline resource packages for web pages according to claim 1, characterized in that, Generate a global hash value corresponding to the offline resource package based on the resource list, including: Obtain the file hash values ​​of all static resource files recorded in the resource list; According to the predetermined sorting rules, the hash values ​​of all files are sorted and concatenated to form a hash string to be calculated; Perform a hash operation on the hash string to generate a global hash value that serves as a unique identifier for the offline resource package.

4. The method for processing offline resource packages for web pages according to claim 1, characterized in that, The query hash value and query page identifier carried in the request are matched with the resource configuration information, and the corresponding real-time configuration information is returned based on the matching result, including: The query hash value carried in the configuration update request is compared and matched with the global hash value recorded in the resource configuration information of the corresponding page of the query page identifier carried in the request to determine the matching result; wherein, the query hash value is the historical global hash value that has been cached locally on the client. When the matching result indicates that the query hash value is inconsistent with the recorded global hash value, first real-time configuration information is generated. This information includes the storage path of the target resource package to be downloaded for the corresponding page of the query page identifier and the global hash value of the latest offline resource package of the corresponding page. The first real-time configuration information is returned to the client to instruct it to download the target resource package. After verifying and updating the resource configuration of the corresponding page that has been cached locally based on the global hash value, the corresponding page is loaded.

5. The method for processing offline resource packages for web pages according to claim 4, characterized in that, The query hash value carried in the configuration update request is compared and matched with the global hash value recorded in the resource configuration information of the corresponding page of the query page identifier carried in the request. After determining the matching result, the process includes: When the matching result indicates that the query hash value is consistent with the recorded global hash value, a status information indicating that the configuration has not changed is generated as the second real-time configuration information; The second real-time configuration information is returned to the client to instruct it to load the corresponding page using the locally cached resource configuration.

6. The method for processing offline resource packages for web pages according to claim 4, characterized in that, Generate the first real-time configuration information, including: Based on the query page identifier and the query hash value, determine the version of the offline resource package currently in use by the client; Determine whether there is an incremental update package to upgrade the current version to the latest version. If there is no incremental update package, generate an incremental update package based on the binary difference data of the offline resource packages of the current version and the latest version. When the incremental update package exists or is generated, the storage path of the incremental update package is used as the storage path of the target resource package in the first real-time configuration information, the global hash value of the offline resource package corresponding to the latest version is provided, and the update method is marked as incremental update.

7. The method for processing offline resource packages for web pages according to any one of claims 1 to 6, characterized in that, After returning the corresponding real-time configuration information based on the matching results, it includes: Receive page loading performance data reported by the client and store it in the performance monitoring database. The page loading performance data includes the global hash value of the current version of the corresponding page, the first rendering time, the first content rendering time, and the loading result. Based on the historical page loading performance data under the same global hash value in the performance monitoring database, the average loading performance index of the offline resource package of the corresponding page is calculated. Determine whether the average loading performance index is lower than the corresponding preset performance threshold. If it is lower than the performance threshold, generate a performance alarm message for the offline resource package identified by the global hash value.

8. A device for processing offline resource packages for web pages, characterized in that, include: The publish response module is configured to respond to a publish request for a target page and obtain an initial resource package for implementing the target page, wherein the initial resource package contains static resource files that constitute the target page; The security reconstruction module is configured to perform validity verification processing on the initial resource package, and construct a standardized offline resource package based on the verified valid static resource files. The offline resource package includes the verified valid static resource files and a resource list, and the resource list includes the storage path and file hash value of the static resource files. The configuration construction module is set to generate a global hash value corresponding to the offline resource package based on the resource list, and associate and store the target page identifier, the storage path of the offline resource package and the global hash value to form resource configuration information; The update response module is configured to respond to configuration update requests from clients. It matches the query hash value and query page identifier carried in the request with the resource configuration information and returns the corresponding real-time configuration information based on the matching result, so as to load the corresponding page of the query page identifier.

9. An electronic device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images