Resource updating method and device, medium and product

Abstract

The embodiment of the invention relates to the technical field of computers, and discloses a resource updating method and device, a medium and a product. The method applied to a server comprises the following steps: determining first data and second data according to a current version resource file; wherein the first data is used for providing a complete resource block of a current version; the second data is used for providing a difference block between the current version and the previous version; determining a hierarchical aggregation file according to the first data and the second data; wherein the hierarchical aggregation file is used for representing a mapping relationship between the complete resource block and the difference block corresponding to each resource hierarchy. The technical problems that in the prior art, when the file version is updated, resource consumption is large, and different updating scenes cannot be flexibly adapted are at least solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource updating method, apparatus, medium and product. Background Technology

[0002] In the digital age, software, games, and other applications need continuous iteration and upgrades to meet user needs and adapt to technological advancements. File version updates have become a routine part of supporting the lifespan of these applications. As application functions become increasingly complex, the number and size of resource files continue to grow. How to efficiently complete version updates has become a key factor affecting user experience.

[0003] Among the file version update solutions in related technologies, there is the traditional whole-package download method. This method involves first assembling the scattered files into a complete package for the client to download. After the client completes the download, it then needs to unpack the package to obtain all the files included in the latest version.

[0004] However, the inventors discovered that the related technology has at least the following technical problems: high resource consumption and inability to flexibly adapt to different update scenarios. Summary of the Invention

[0005] One objective of this application is to provide a resource update method, device, medium, and product, at least to solve the technical problems in the related art where file version updates involve high resource consumption and inflexible adaptation to different update scenarios.

[0006] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0007] In a first aspect, some embodiments of this application provide a resource update method, which is applied to a server. The method includes: determining first data and second data based on a current version resource file; wherein the first data is used to provide complete resource blocks of the current version; the second data is used to provide difference blocks between the current version and the previous version; and determining a hierarchical aggregation file based on the first data and the second data; wherein the hierarchical aggregation file is used to characterize the mapping relationship between complete resource blocks and difference blocks corresponding to each resource level.

[0008] Secondly, some embodiments of this application also provide a resource update method, which is applied to a client. The method includes: obtaining a hierarchical aggregation file generated by a server as described above; determining a target level based on the hierarchical aggregation file; and performing a differentiated update operation based on the first data and second data integrated in the target level.

[0009] Thirdly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0010] Fourthly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods described above.

[0011] Fifthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0012] Compared with related technologies, the solution provided in this application involves the server determining first data for providing complete resource blocks and second data for providing inter-version difference blocks based on the current version of the resource file. This satisfies update requirements and facilitates flexible adaptation to different update scenarios. Furthermore, by combining a hierarchical differential scheme with the first and second data, a hierarchical aggregation file representing the mapping relationship between complete resource blocks and difference blocks at each resource level is determined. This clearly presents the mapping relationship between each resource level and its corresponding complete data and difference blocks. This hierarchical integration design of the difference blocks avoids fragmentation issues and allows the integrated file to achieve a streaming processing effect of simultaneous downloading, decompression, and splicing.

[0013] Meanwhile, the client can accurately obtain the necessary data for the target layer from the hierarchical aggregation file according to actual update needs, without downloading irrelevant layers from the entire resource package. Since the transmitted data can be only the necessary part of the target layer, rather than the complete package, the size of the downloaded package can be significantly reduced, improving the compression ratio. Furthermore, because the hierarchical aggregation file itself has a hierarchically structured data structure, the target layer data obtained by the client can be directly used for update operations, eliminating the need to first download the entire package to the local machine and then decompress and split it to extract the required content, as is done with traditional full-package downloads. This process avoids the decompression step of the entire package, which often requires frequent disk reads and writes and is highly dependent on disk performance. Therefore, this application can also avoid the decompression stage, reducing reliance on disk performance and helping to reduce the processing load on the device.

[0014] Because the hierarchical aggregation file not only contains the complete resource block of the current version but also integrates the difference blocks between different versions, and the hierarchical mapping relationship clearly defines the corresponding rules for each version's data, the client can flexibly choose the update path based on this data: it can directly update from a lower version to the latest version through the complete resource block, it can gradually update through the difference blocks of multiple consecutive versions, and it can also jump between non-consecutive versions through cross-version difference blocks. Therefore, this application supports updates between multiple versions and arbitrary states, further improving the flexibility and applicability of updates. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0016] Figure 1 An exemplary flowchart of a resource update method provided for some embodiments of this application;

[0017] Figure 2 An exemplary flowchart illustrating yet another resource update method provided in some embodiments of this application;

[0018] Figure 3 This is an exemplary structural diagram of an electronic device provided for some embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The following terms are used in this document.

[0021] Traditional Chunk download method: This is a download mode that linearly divides the original file into chunks using a specific algorithm, where each chunk is called a Chunk block. This mode uses a sliding window combined with hashing to process the file into blocks, allowing the client to quickly identify the differences between two versions of the file, and then only download the differences to complete the overall file update.

[0022] Traditional Diff scheme: This is a byte-level differential update method. Compared to Chunk mode, each diff block in a traditional Diff update is smaller, and the precision can reach the single-byte level. This mode pre-generates diff blocks for all files, and then integrates and packages these diff blocks into a single compressed file. After the client downloads this compressed file, it needs to decompress it and then complete the content concatenation to achieve the file update.

[0023] QPS, short for Queries Per Second, is an important indicator for measuring system processing capacity. It is mainly used to represent the number of requests a server can process in one second.

[0024] First Embodiment

[0025] The first embodiment of this application relates to a resource updating method. For example... Figure 1 As shown, the method, when applied to the server, may include the following steps:

[0026] Step S101: Determine first data and second data based on the current version of the resource file; wherein, the first data is used to provide the complete resource block of the current version; and the second data is used to provide the difference block between the current version and the previous version.

[0027] Step S102: Determine a hierarchical aggregation file based on the first data and the second data; wherein the hierarchical aggregation file is used to characterize the mapping relationship between complete resource blocks and difference blocks corresponding to each resource level.

[0028] The following sections will provide a detailed explanation of each of the above steps.

[0029] Specifically, regarding step S101, the current version resource file can be understood as all the original material files contained in the software / application / game version that is being prepared for update or release, which is a specific version, complete, and static resource collection.

[0030] The server can determine two types of data based on the current version of the resource files (such as game assets, configuration files, etc.): first data and second data.

[0031] The complete resource block in the first data refers to the full collection of resource files in the current version, which includes the final state of all files and data from basic resources to newly added content, such as the complete scene map file, full character model data, sound effect resource library, etc. in the game. It is a complete dataset formed by packaging all resources of the current version according to a preset structure, which is used to support resource acquisition when the client is first installed or when there is a full update across versions.

[0032] The difference blocks in the second data are sets of change data generated by comparing the current version with the previous version of resource files. These can include newly added resource blocks, modification difference blocks, and deletion marker blocks. Newly added resource blocks refer to files or data segments added in the current version (such as model files for new scenes or new sound effect data blocks); modification difference blocks refer to parts of the resource content that have changed (such as mesh vertex difference packages for character models or logic modification patches for script code); and deletion marker blocks are deletion identifiers for resources that existed in the previous version but were removed in the current version (e.g., recording the path and version status of deleted files through a version mapping table). The difference blocks only contain the changes between versions. The client can achieve incremental updates by parsing the difference blocks and merging them with local resources, avoiding repeated downloads of unchanged resources and significantly reducing data transmission volume.

[0033] Specifically, regarding step S102, the server can integrate the first data of the complete resource with the second data of the difference block according to a preset resource hierarchy dimension (such as business module, directory structure, or functional category) to generate a hierarchical aggregation file. This hierarchical aggregation file mixes and integrates complete resource blocks and difference blocks of the same level into a single complete file, thus containing both the complete resource blocks of the current version and the difference blocks between versions. The purpose of this hierarchical aggregation file is to establish a mapping relationship, clarifying the correspondence rules between complete resources and difference blocks at each level (e.g., "role system," "UI interface"), such as which files need to be replaced for a certain module. In this way, the client can subsequently accurately locate the level and specific content to be updated based on the hierarchical aggregation file, thereby achieving efficient incremental updates, avoiding full downloads, and significantly reducing traffic consumption.

[0034] Optionally, in some embodiments, determining the first data and the second data based on the current version of the resource file may include:

[0035] First data is generated based on the complete content of the current version resource file. This first data provides all the resource blocks required to constitute the complete resource of the current version. For example, the complete content may include the overall file of the new scene map, the overall file of the optimized character model, and the overall file of the newly added environmental sound effects.

[0036] Second data is generated by comparing the current version of the resource file with the previous version of the resource file. This second data is used to provide the difference resource blocks between the two versions. For example, the difference resource blocks may include newly added block data packages that constitute the new scene map, mesh and texture difference packages optimized for the original character models, and newly added environmental sound effect file data blocks.

[0037] The first data represents the complete resource composition of the current version, while the second data only represents the resource portions that have changed compared to the previous version. Therefore, a hierarchical aggregation file can be determined based on the first and second data.

[0038] For example, when an online game releases a new version, the current version's resource files include new scene maps, optimized character models, and new environmental sound effects. The first data generated by the server is the complete resource package for this version, containing all scenes (including existing and new scenes), all character models, and sound effects; the second data is the difference package compared to the previous version, which only contains the exclusive textures and new chunk data packages for the new scenes, the mesh vertex difference package for the character models, the texture detail difference package, and the new environmental sound effects.

[0039] The subsequently constructed hierarchical aggregation file can be organized into three levels: scene map, character model, and ambient sound effects. Each level is marked with both complete resource paths and difference resource paths: the scene map level marks both the complete resource path (for new users to download) and the difference block path (containing only new scene textures for existing users to update); the character model level, which only performs detail optimizations, directly points to the model difference file in the second data; the ambient sound effects level marks the reference path of the original sound effects in the complete resources, as well as the download path of the newly added sound effects in the second data. After client parsing, new users can download the complete resources of each level, while existing users only need to download the new scene textures, character detail optimization files, and new sound effects, without having to repeatedly download unchanged resources. This significantly reduces the update package size and achieves efficient updates.

[0040] It is not difficult to see that, compared with related technologies, the solution provided in this application, where the server determines the first data for providing complete resource blocks and the second data for providing inter-version difference blocks based on the current version of the resource file, can meet update requirements and is conducive to flexibly adapting to different update scenarios. Based on this, combined with a hierarchical differential scheme, a hierarchical aggregation file representing the mapping relationship between complete resource blocks and difference blocks corresponding to each resource level is determined based on the first and second data, clearly presenting the mapping relationship between each resource level and its corresponding complete data and difference blocks. This hierarchical integration design of the difference blocks avoids fragmentation problems and allows the integrated file to achieve a streaming processing effect of downloading, decompressing, and splicing simultaneously.

[0041] Meanwhile, the client can accurately obtain the necessary data for the target layer from the hierarchical aggregation file according to actual update needs, without downloading irrelevant layers from the entire resource package. Since the transmitted data can be only the necessary part of the target layer, rather than the complete package, the size of the downloaded package can be significantly reduced, improving the compression ratio. Furthermore, because the hierarchical aggregation file itself has a hierarchically structured data structure, the target layer data obtained by the client can be directly used for update operations, eliminating the need to first download the entire package to the local machine and then decompress and split it to extract the required content, as is done with traditional full-package downloads. This process avoids the decompression step of the entire package, which often requires frequent disk reads and writes and is highly dependent on disk performance. Therefore, this application can also avoid the decompression stage, reducing reliance on disk performance and helping to reduce the processing load on the device.

[0042] Because the hierarchical aggregation file not only contains the complete resource block of the current version but also integrates the difference blocks between different versions, and the hierarchical mapping relationship clearly defines the corresponding rules for each version's data, the client can flexibly choose the update path based on this data: it can directly update from a lower version to the latest version through the complete resource block, it can gradually update through the difference blocks of multiple consecutive versions, and it can also jump between non-consecutive versions through cross-version difference blocks. Therefore, this application supports updates between multiple versions and arbitrary states, further improving the flexibility and applicability of updates.

[0043] In some application examples, it has been demonstrated that compared to the traditional chunking method, the compression rate of this application can be improved by about 10%-15%, the resource download size is reduced by about 70% compared to the traditional chunking method, and by about 90% compared to the traditional whole package download method. Furthermore, the resource update scheme proposed in this application is no longer limited to between two versions, but can support flexible updates between multiple versions and any state. Taking game version updates as an example, these advantages significantly improve the update completion rate from 70% to about 95%.

[0044] Second Embodiment

[0045] The second embodiment of this application relates to a resource update method. The second embodiment is an improvement upon the first embodiment, specifically in that it provides a method for determining the first data.

[0046] The first data specifically refers to multiple chunks determined based on the current version of the resource file. For example, the method for determining the first data may include:

[0047] Step S101A1: Determine multiple Chunk blocks based on the current version of the resource file;

[0048] Step S101A2: Determine the first data based on the Chunk block.

[0049] For step S101A1, for example, the current version resource file can be processed by chunking, dividing the complete resource block into multiple data blocks (chunks) of fixed or variable size, each chunk having a unique identifier (such as a hash value or index). For example, if the current version resource file is a game scene package (such as scene_v2.asset), it can be split according to a fixed size (such as one chunk per 1MB) to generate multiple chunks, such as chunk_001, chunk_002, etc.

[0050] For step S101A2, for example, the first data (i.e., the complete resource block) is constructed based on the chunked collection. This can be recorded in the form of an index table or a manifest file, recording the storage location, version information, and dependencies of all chunk blocks. For instance, the server can generate a manifest_v2.json file, which lists all chunk blocks of scene_v2.asset (such as the hash values ​​and download paths of chunk_001 to chunk_100). The client can then obtain the complete version of the resource data through this manifest.

[0051] It is not difficult to see that in the embodiments of this application, dividing the current version resource file into multiple chunks and determining the first data based on the chunks is beneficial to achieving more efficient data processing and version management. This is because the division of chunks decomposes the current version resource file into smaller independent units, thereby reducing the complexity of data processing. At the same time, generating the first data based on the chunks can accurately reflect the structural characteristics of the file content, thereby improving the efficiency of subsequent data comparison or updates, and is beneficial to optimizing storage space and reducing network transmission load.

[0052] Third Embodiment

[0053] The third embodiment of this application relates to a resource update method. The third embodiment is an improvement upon the first embodiment, specifically in that it provides a method for determining the second data.

[0054] The second data specifically refers to the difference blocks determined by comparing the current version of the resource file with the previous version of the resource file. For example, the method for determining the second data may include:

[0055] Step S101B1: Based on the current version resource file and the previous version resource file, determine the difference blocks that represent the changed data between versions;

[0056] Step S101B2: Determine the second data based on the difference block.

[0057] For step S101B1, for example, by comparing the current version of the resource file with the previous version of the resource file, a difference calculation (such as binary diff or file-level comparison) is performed to identify newly added, modified, or deleted data blocks and generate corresponding difference blocks (diff blocks). For example, if the previous version contains the scene file scene_v1.asset (composed of chunk_001 to chunk_090), while the current version scene_v2.asset only has chunk_005 and chunk_045 modified and chunk_091 added, then the difference blocks generated after the difference operation can be marked as diff_chunk_005, diff_chunk_045, and add_chunk_091, and the remaining unchanged blocks do not need to be included again.

[0058] For step S101B2, for example, the aforementioned difference blocks can be integrated into second data (i.e., a difference block package), which can be stored in the form of a lightweight incremental update file (such as patch_v1_v2.pak), containing only the actual data of the changed parts and their metadata (such as block index and version number). For example, the second data can be structured to record the new content of diff_chunk_005, the offset correction value of diff_chunk_045, and the complete data of add_chunk_091.

[0059] It should be noted that this embodiment can also be an improvement on the second embodiment.

[0060] It is not difficult to see that in the embodiments of this application, by comparing the current version resource file with the previous version resource file and extracting the difference blocks that represent the changes between versions, and then determining the second data based on the difference blocks, the method can significantly improve the efficiency of version updates. This is because the difference blocks only contain the changed parts of the file rather than the complete file, which greatly reduces the amount of data in the second data, thereby reducing storage and transmission overhead. At the same time, since only the difference parts are processed instead of all the data, the speed of version comparison and synchronization can be further accelerated, which is conducive to achieving more efficient resource management and faster version iteration.

[0061] In conjunction with the first to third embodiments, it should be noted that although the resource update method provided in this application can be used in conjunction with the traditional Chunk scheme and the traditional Diff scheme, there are significant differences in the core mechanism. These differences enable this application to have superior performance, as detailed below:

[0062] Compared to traditional chunking schemes, this application differs in that: traditional chunking schemes use a rolling window chunking model, where each hash only targets a small segment of content (usually a few megabytes), sacrificing overall file context information during compression, resulting in a low compression ratio; and because the number of chunks needs to be controlled, the size of a single chunk cannot be too small, easily generating a large amount of redundant data (for example, in a 1MB chunk, the actual content that needs to be updated may only be 1KB, and the redundant download portion may exceed 50%). Furthermore, when the number of resources that need to be updated is too large, it puts enormous pressure on the server's QPS. In contrast, this application determines the first data (complete resource block) and the second data (difference block), and generates a hierarchical aggregation file representing the data mapping relationship between each resource level. This allows for structured management of resources hierarchically, enabling clients to accurately obtain the necessary data for the target level without downloading irrelevant content. This avoids redundant data caused by chunking limitations, reduces server request pressure, and effectively improves the compression ratio due to the more targeted data transmission.

[0063] Compared to traditional Diff schemes, this application differs in that traditional Diff schemes require generating small diff files for each file individually. These files are then either packaged into complete files for the client to download, decompress, and concatenate (consuming significant time), or the client directly downloads the fragmented diff files (resulting in a massive number of requests and high QPS pressure on the server). Furthermore, because all diff files need to be generated in advance, cross-version updates are not supported. In contrast, this application, while retaining the advantage of small diff file size, integrates complete resource blocks and difference blocks through hierarchical aggregation files. Clients can then implement streaming operations that download and process simultaneously, avoiding the request pressure from numerous fragmented files and the time-consuming decompression and concatenation. Simultaneously, leveraging the clear mapping relationships within the hierarchical aggregation files, combined with the client's diff algorithm logic, it can also support byte-level updates between any version and any client state, overcoming the limitations of traditional Diff schemes on cross-version updates.

[0064] In summary, this application, through its unique hierarchical aggregation mechanism, can effectively overcome the shortcomings of traditional Chunk and Diff schemes in terms of compression ratio, redundant data, server pressure, and cross-version update support, thereby significantly improving the efficiency and flexibility of resource updates.

[0065] Fourth embodiment

[0066] The fourth embodiment of this application relates to a resource update method. The fourth embodiment is an improvement upon the first embodiment, specifically in that it provides a method for determining a hierarchical aggregation file based on the first data and the second data.

[0067] Specifically, determining the hierarchical aggregation file based on the first data and the second data, i.e., step S102, may include:

[0068] Step S1021: Group the complete resource blocks in the first data and the difference blocks in the second data according to the preset resource level dimension; wherein, the preset resource level dimension is used to define the rules for logical association or similar attributes between data blocks;

[0069] Step S1022: Aggregate complete resource blocks within the same group into a first aggregate file, and aggregate difference blocks within the same group into a second aggregate file;

[0070] Step S1023: Generate the hierarchical aggregation file based on the first aggregation file and the second aggregation file corresponding to each group, so as to establish the mapping relationship between the preset resource hierarchy dimension and the aggregated file.

[0071] For step S1021, for example, the resource hierarchy dimension preset by the server can be A, B, C, etc. (e.g., divided according to resource function type), used to clarify the grouping rules of resource blocks, that is, resource blocks with logical association or similar attributes are grouped into the same group. For example, all complete resource blocks (A1, A2, A3) belonging to dimension A in the first data and the difference block (a1) belonging to dimension A in the second data are grouped into group A; complete resource blocks (B1, B2) belonging to dimension B in the first data and the difference block (b1) belonging to dimension B in the second data are grouped into group B, thereby realizing grouping according to preset rules. The granularity of the resource hierarchy structure can be flexibly adjusted according to actual needs, and this embodiment does not impose specific limitations.

[0072] Regarding step S1022, optionally, in some embodiments, aggregating complete resource blocks within the same group into a first aggregate file and aggregating difference blocks within the same group into a second aggregate file may include: in response to the existence of multiple complete resource blocks within the same group, packaging the multiple complete resource blocks into a single complete resource aggregate file as the first aggregate file; in response to the existence of multiple difference blocks within the same group, packaging the multiple difference blocks into a single difference aggregate file as the second aggregate file. For example, after grouping, the server can perform categorized aggregation of resource blocks within each group: in group A, all complete resource blocks (A1, A2, A3) are packaged into a first aggregate file (A complete package); the difference block (a1) within the same group is packaged into a second aggregate file (A difference package). Similarly, group B will generate a first aggregate file (B complete package) containing B1 and B2, and a second aggregate file (B difference package) containing b1, achieving separate aggregation of complete and difference resources under the same dimension.

[0073] For step S1023, for example, the server can integrate the first and second aggregate files of all groups to generate an index structure that records the correspondence between hierarchical dimensions and aggregate files, i.e., a hierarchical aggregate file. For example, in the hierarchical aggregate file, dimension A can be associated with the storage path of the complete package A and the storage path of the difference package A, and dimension B can be associated with the storage path of the complete package B and the storage path of the difference package B. Through this mapping relationship, the client can directly and quickly locate the required aggregate file according to the target dimension, achieving efficient resource acquisition.

[0074] Optionally, in some embodiments, the method is applied to a game project, and the preset resource hierarchy dimension includes at least one of the following: resource type, game scene, and game task; the resource type is used to divide resource blocks of the same type into a first group; the game scene is used to divide resource blocks belonging to the same game scene into a second group; the game task is used to divide resource blocks belonging to the same game task into a third group; wherein, the first group, the second group, and the third group are independent of each other.

[0075] For example, regarding resource type (first group): this dimension is divided according to the format or functional attributes of the resource, grouping resource blocks of the same type into the same group. For instance, all model files (such as character model A1, prop model A2) can be grouped into the "Model" subgroup under the first group, all texture maps (such as scene texture A3, character texture A4) can be grouped into the "Texture" subgroup, and all audio files (such as background music A5, action sound effects A6) can be grouped into the "Audio" subgroup, thus achieving independent grouping management by resource type.

[0076] For example, regarding the game scene (second group): this dimension is divided according to the spatial scene of the game world, and resource blocks belonging to the same scene are grouped into the same group, regardless of the resource type. For example, all resource blocks in scene B1 (main city square), including the main city model B1-1, square texture B1-2, and NPC dialogue audio B1-3, are grouped into the "scene B1" subgroup under the second group; all resource blocks in scene B2 (forest dungeon), including the tree model B2-1, fog effect B2-2, and battle sound effect B2-3, are grouped into the "scene B2" subgroup, forming independent groups based on scene.

[0077] For example, regarding the game task (third group): this dimension is divided according to the game's task units, grouping resource blocks serving the same task into the same group, independent of resource type and scene. For instance, all resource blocks for task C1 (main quest "Chapter 1 Awakening"), including the task-specific character model C1-1, trigger scene C1-2, and story audio C1-3, are grouped into the "Task C1" subgroup under the third group; all resource blocks for task C2 (side quest "Mysterious Merchant"), including the merchant model C2-1, trading scene C2-2, and interactive sound effects C2-3, are grouped into the "Task C2" subgroup, achieving independent grouping centered on the task.

[0078] For example, suppose in step S1021, the server's update requirement is "optimize the forest instance scene". Among the three preset levels, the second level (the game scene to which it belongs) is responsible for managing resources related to the game scene. Therefore, the server can determine "forest instance" as the target group according to the second level, and uniformly classify the complete resource blocks belonging to the forest instance in the first data (such as tree models, background music, and lighting textures) and the difference blocks belonging to the scene in the second data (such as the newly added waterfall model and the adjusted monster spawn point coordinates) into the "forest instance" group, so as to achieve precise grouping by scene dimension. Furthermore, in step S1022, the server can classify and aggregate resources within the "Forest Instance" group: complete resource blocks (tree models, background music, etc.) from the first data are packaged into a first aggregate file (Forest Instance Complete Package), and difference blocks (new waterfall models, adjusted refresh point coordinates, etc.) from the second data are packaged into a second aggregate file (Forest Instance Difference Package), instead of simply integrating them into a single file, thus achieving separate management of complete and difference resources. In step S1023, the server can generate a hierarchical aggregate file based on the above two aggregate files. This hierarchical aggregate file is used to clearly record the mapping relationship between "Forest Instance" and the two aggregate files in the "Game Scene" dimension, i.e., the storage path of the Forest Instance Complete Package and the storage path of the Forest Instance Difference Package corresponding to "Forest Instance". Thus, when the client updates, it can directly locate the required file through this mapping: new users download the complete package, while old users only download the difference package, achieving targeted and efficient updates to the Forest Instance scene.

[0079] Optionally, in some embodiments, the method may further include performing at least one of selective compression or selective encryption on the hierarchical aggregation file during the generation of the hierarchical aggregation file.

[0080] Specifically, when generating hierarchical aggregation files, the server can perform targeted processing on the aggregation files (protecting the first aggregation file and the second aggregation file) under the preset resource hierarchy dimension according to the characteristics of the resources and security requirements.

[0081] For example, for basic texture resources (such as general ground maps, protecting the complete textures of the first aggregate file and the texture difference blocks of the second aggregate file) contained in the first level (resource type dimension), selective compression can be performed due to their high reusability but low security requirements. For example, efficient compression algorithms such as LZ4 or ETC2 can be used to reduce file size while ensuring image quality, thereby speeding up transmission and reducing storage usage.

[0082] For example, for the main storyline script resource blocks involved in the third level (the game task dimension) (including the complete script of the first aggregate file and the script difference block of the second aggregate file under this dimension), selective encryption is performed because they contain core plot logic and have high security requirements. For example, they can be encrypted with a server-side dedicated symmetric key to prevent the resources from being tampered with, reverse-analyzed, or illegally extracted.

[0083] For example, for a regular scene model resource block in a copy within the second level (the game scene dimension) (including the complete model of the first aggregate file and the model difference block of the second aggregate file within this dimension), if both size control and basic protection are required, selective compression and selective encryption operations can be performed simultaneously. That is, the model vertex data can be compressed first using the Mesh compression algorithm to reduce the size, and then the compressed file can be encrypted with lightweight AES, balancing protection and parsing efficiency.

[0084] Through the above-mentioned differentiated processing, we can balance resource transmission efficiency, storage costs and client parsing speed, and strengthen security protection for core resources (such as plot scripts and key models) to adapt to the actual needs of different resources.

[0085] It should be noted that this embodiment may also be an improvement based on the second embodiment and / or the third embodiment.

[0086] It is not difficult to see that in this embodiment, by grouping and aggregating resource blocks according to a preset resource hierarchy, refined management of resource updates is achieved: First, by grouping the first and second data according to resource hierarchy, the scope of resources to be integrated can be accurately identified, avoiding redundant processing of irrelevant resources, thereby significantly reducing the computational overhead of the server; on this basis, complete resource blocks and differential blocks within the same group are aggregated into a first aggregate file and a second aggregate file, respectively, and a hierarchical aggregate file is generated to establish a mapping relationship between resource hierarchy and aggregate file, so that the final generated aggregate file only contains complete and differential resources related to the target hierarchy; therefore, the client can directly call the aggregate file corresponding to a specific hierarchy when updating, achieving accurate and efficient targeted updates, thereby effectively reducing the client's bandwidth consumption and update time.

[0087] Fifth embodiment

[0088] The fifth embodiment of this application relates to a resource updating method. For example... Figure 2 As shown, the method, when applied to the server, may include the following steps:

[0089] Step S201: Obtain the hierarchical aggregation file generated by the server as described in any one or more embodiments of the first to fourth embodiments;

[0090] Step S202: Determine the target level based on the hierarchical aggregation file;

[0091] Step S203: Perform a differential update operation based on the first data and the second data integrated in the target level.

[0092] The following sections will provide a detailed explanation of each of the above steps.

[0093] For step S201, for example, the client obtains the generated hierarchical aggregation file from the server. The server generates the hierarchical aggregation file by integrating the first data (complete resource block) and the second data (difference block) according to the resource level in any one or more of the first to fourth embodiments. For example, after the player starts the game, the client can automatically connect to the server and obtain multiple hierarchical aggregation files such as "Forest Dungeon Scene" and "Main Quest Chapter 3". Each file contains the complete resources and version difference resources of the corresponding level.

[0094] For step S202, for example, the client can determine the target level to be processed from the obtained layer aggregation file based on the content it needs to update. For instance, if the client detects that the resource version of the local "Forest Dungeon Scene" is lower than the latest version on the server, and players frequently enter this scene recently, then the client determines the layer corresponding to the "Forest Dungeon Scene" as the target layer and focuses on processing the update of that layer.

[0095] For step S203, for example, the client extracts integrated first and second data from the aggregation file of the determined target level, and performs differentiated updates based on the difference between the local version and the latest version. For example, if the client's local "forest instance scene" resources are only slightly different from the latest version, the client extracts the second data (such as the newly added waterfall model and the adjusted monster spawn points) from the aggregation file of that level for incremental updates; if local resources are missing or the version difference is too large, the client extracts the first data (the complete tree model of the scene, background music, etc.) for a full update to achieve accurate updates for the scene.

[0096] It is easy to see that in this embodiment, by obtaining the aggregated file integrated by the server in a hierarchical manner, the client can directly obtain a structured resource package, which can avoid multiple requests for scattered resources and thus reduce the number of network interactions. Based on this, the target level can be determined according to the aggregated file, so that the client can accurately locate the range of resources that need to be updated, thereby avoiding invalid processing of irrelevant resources. On this basis, the first and second data integrated in the target level can be used to perform differentiated updates, so that the client can choose full or incremental updates according to actual needs, thus significantly reducing the bandwidth consumption and time cost required for updates. At the same time, the clear resource range is conducive to improving the accuracy and stability of updates.

[0097] Sixth Embodiment

[0098] The sixth embodiment of this application relates to a resource update method. The sixth embodiment is an improvement upon the fifth embodiment, specifically in that it provides a method for determining the target level based on the hierarchical aggregation file.

[0099] Specifically, determining the target level based on the hierarchical aggregation file, i.e., step S202, may include:

[0100] Step S2021: Determine the version difference type of the resource to be updated based on the local resource version and the version information in the hierarchical aggregation file;

[0101] Step S2022: Determine the target level based on the resource level dimension in the hierarchical aggregation file and the attribute characteristics of the resource to be updated.

[0102] For step S2021, for example, the client can perform a full comparison between the local file status table and the server-side file status table carried in the hierarchical aggregation file to determine the version difference type of each resource. The version difference type includes near-near version updates and non-near-near version updates.

[0103] The local file status table records the current version of all files, while the server-side file status table records the latest version. For example, if the client finds that the local "Forest Dungeon Scene" resource is version V2, and the latest version of the same resource on the server is version V3, with only one version difference, it is determined to be an "imminent version update." If the local "Main Quest Chapter 3" resource is version V1, and the latest version on the server is version V4, with three version differences, it is determined to be a "non-imminent version update."

[0104] For step S2022, for example, the client can determine the target level to be updated based on the preset hierarchical structure of "resource type → game scene → game task" in the hierarchical aggregation file, combined with the attribute characteristics of the resource to be updated. For example, "Forest Dungeon Scene" belongs to the scene type resource, corresponding to the second level in the preset hierarchy, which is the game scene resource management level. The client can determine "Forest Dungeon Scene" as the target level accordingly. "Main Quest Chapter 3" belongs to the task type resource, corresponding to the third level in the preset hierarchy, which is the game task resource management level. The client can determine "Main Quest Chapter 3" as the target level.

[0105] Optionally, in some embodiments, the client maintains a file status table to record the version identifiers of each local file; the step S2021, which determines the version difference type of the resource to be updated based on the local resource version and the version information in the hierarchical aggregation file, may include:

[0106] Step S20211: Compare the local file version identifier recorded in the file status table with the version identifier of the corresponding server file in the hierarchical aggregation file to determine the version difference status;

[0107] Step S20212: Based on the version gap status, determine whether the version gap type is an adjacent version update or a non-adjacent version update.

[0108] For step S20211, for example, the client can first extract the version identifier of each local file from the file status table, and then compare it one by one with the version identifier of the corresponding server file in the hierarchical aggregation file to determine the version difference between the two. For example, the file status table records the local "Forest Instance Scene" file version identifier as V2, and the hierarchical aggregation file records the corresponding server file version identifier as V3. By comparison, it is determined that the two are different by 1 version. The file status table records the local "Main Quest Chapter 3" file version identifier as V1, and the hierarchical aggregation file records the corresponding server file version identifier as V4. After comparison, it is determined that the two are different by 3 versions.

[0109] Regarding step S20212, for example, the client can classify specific version difference types based on the determined version difference status and a preset version difference threshold (e.g., a difference of 1 version is the critical value): when the version difference between the local file and the corresponding file on the server is only 1 version, it can be determined as "near-immediate version update"; when the version difference is 2 or more versions, it can be determined as "non-near-immediate version update". For example, the version difference status of "Forest Dungeon Scene" is 1 version, so it is classified as "near-immediate version update"; the version difference status of "Main Quest Chapter 3" is 3 versions, so it is classified as "non-near-immediate version update".

[0110] Optionally, in some embodiments, the step of performing a differential update operation based on the first and second data integrated in the target level, i.e., step S203, may include:

[0111] When the version gap type is a non-adjacent version update, a complete resource block is obtained from the first data of the target level to replace the local resource;

[0112] When the version difference type is an upcoming version update, the difference block is obtained from the second data of the target level and merged with the local resources.

[0113] Specifically, when the version gap type is a non-immediate version update, the client can obtain complete resource blocks from the first data of the target level and replace the corresponding level resources stored locally with these complete resource blocks. For example, when "Chapter 3 of the main quest" is determined to be a non-immediate version update, the client can obtain the corresponding chunk blocks that constitute the complete resources from the first data of that quest level (without downloading the entire first aggregate file). These chunk blocks together constitute the complete resource blocks of the quest. Subsequently, these data are used to replace all the original resources of that quest level locally, achieving complete synchronization with the server version.

[0114] Specifically, when the version difference type is near-update, the client can obtain the difference blocks from the second data of the target level, and then merge these difference blocks with the corresponding level resources stored locally. For example, when the "Forest Instance Scene" is determined to be near-update, the client can obtain the corresponding diff difference blocks from the second data of the scene level (without downloading the entire second aggregate file). These difference blocks are the difference resource part of the scene. Then, these data are merged with the existing local resources of the scene, supplementing or updating only the changed parts to complete the update of the scene.

[0115] Optionally, in some embodiments, determining the target level based on the hierarchical aggregation file includes: determining the target level to be downloaded level by level in hierarchical order according to the preset resource hierarchical dimensions in the hierarchical aggregation file.

[0116] Specifically, when determining the target level, the client can first determine the target level to be downloaded according to the preset resource level dimensions in the level aggregation file, and then complete the download and subsequent unpacking and aggregation operations based on the determined target level. In this embodiment, this "first determine the level, then download in an orderly manner" design allows the client to accurately locate the range of resources that need to be updated, significantly improving the flexibility and controllability of the download process.

[0117] In some cases, after completing the version comparison of all files, the client can first classify the files to be updated according to the preset resource level dimension, and then determine the target level to be downloaded step by step according to the hierarchical order (such as resource type → game scene → in-game task). Based on the determined target level and version difference type, a differentiated update operation is performed: when the version difference type is not an adjacent version update, the complete resource block is obtained from the first data of the target level (for example, after the target level corresponding to "Chapter 3 of the main quest" is determined, only the part of the chunk block that constitutes the complete resource in the first data of that level is downloaded, without downloading the entire first aggregate file), and these data are used to replace the original resources of the corresponding level on the local machine to achieve complete synchronization with the server version; when the version difference type is an adjacent version update, the difference block is obtained from the second data of the target level (for example, after the target level corresponding to "Forest dungeon scene" is determined, only the part of the diff difference block required in the second data of that level is downloaded, without downloading the entire second aggregate file), and these difference blocks are merged with the existing resources of the corresponding level on the local machine, only supplementing or updating the changed parts to complete the update of that level. By adopting this hierarchical and differentiated update approach of "first determining the target level and then matching the update strategy", the client can accurately match the update needs of different target levels (such as the target level corresponding to different in-game tasks can flexibly choose full or incremental update), further optimizing resource acquisition efficiency.

[0118] Optionally, in some embodiments, the method may further include: rolling back to the resource version before the update when the update fails; recording the update failure log and reporting it to the server.

[0119] Optionally, in some embodiments, the rollback operation may include: obtaining resource data of the previous available version based on the version rollback information in the hierarchical aggregation file; and replacing the resource data of the currently failed update.

[0120] Specifically, when an update fails, the client can roll back to the resource version before the update and log the update failure to the server. The rollback operation can include: the client retrieving the resource data of the previous available version from the version rollback information contained in the hierarchical aggregation file, and then replacing the currently failed update resource data with this data. For example, if the client fails to update the "Equipment System" level due to a network interruption, it can first query the version rollback information for that level in the hierarchical aggregation file, retrieve the previously available "Equipment System" resource data, and then use this data to overwrite the currently failed update of the "Equipment System" resources, restoring the level to its normal state before the update. Simultaneously, the time, level, and reason for the update failure are logged and reported to the server so that the server can analyze the problem and optimize the update mechanism.

[0121] It is not difficult to see that in this embodiment of the application, by determining the type of version difference of the resource to be updated based on the local resource version and the version information in the hierarchical aggregation file, the specific requirements for resource updates can be clarified, thereby providing a basis for judgment for subsequent update operations. On this basis, by determining the target level based on the resource hierarchical dimension in the hierarchical aggregation file and the attribute characteristics of the resource to be updated, the scope of resources that need to be updated can be accurately locked, so that the update operation is only carried out for a specific level. Therefore, invalid processing of irrelevant resources can be avoided, which can improve the targeting of the update and reduce the resource consumption of the client, thus improving the overall update efficiency.

[0122] Seventh Embodiment

[0123] The seventh embodiment of this application relates to a resource update method. The seventh embodiment is an improvement upon the fifth embodiment, specifically in that it provides two parallel implementation methods for performing differentiated update operations when files at the same level simultaneously require updates to adjacent and non-adjacent versions.

[0124] Optionally, in some embodiments, when files requiring both adjacent and non-adjacent version updates exist simultaneously at the same level, the differential update operation may include:

[0125] Step S301: Calculate the first total data volume of all complete resource blocks of the files to be updated;

[0126] Step S302: Calculate the second total data volume of all difference blocks in the files to be updated;

[0127] Step S303: Select the scheme with the fewest download resources based on the first total data volume and the second total data volume.

[0128] Optionally, in some embodiments, when files requiring both adjacent and non-adjacent version updates exist simultaneously at the same level, the differential update operation may include:

[0129] Step S301': For files that require an upcoming version update, obtain the corresponding difference block from the second data of the hierarchical aggregated file and download it;

[0130] Step S302': For files that require non-adjacent version updates, obtain the corresponding complete resource block from the first data of the hierarchical aggregated file and download it;

[0131] Specifically, both the difference block and the complete resource block are downloaded in segments, with each segment downloading a portion of the data content separately.

[0132] Specifically, when different versions of files exist within the same level (e.g., the "in-game quests" level), meaning some files need to download cross-version resources (not in the immediate future) and some need to download resources from the immediate future, the client can support the following two differentiated update strategies:

[0133] The first approach is to select the mode that downloads the least amount of resources. Specifically, the client can execute steps S301-S303 to calculate the first total data size (first option) and the second total data size (second option) of the complete resource blocks for all files to be updated, and select the option with the smaller data size. For example, in the "In-Game Missions" level, there are 3 files to be updated, 2 of which are not in the immediate vicinity of the update and 1 is in the immediate vicinity. First option: 50MB of complete resources for each of the 2 non-immediate update files and 30MB of complete resources for the 1 immediate update file; Second option: 20MB of cross-version difference blocks for each of the 2 non-immediate update files and 5MB of difference blocks for the 1 immediate update file, for a total second total data size of 45MB. The client selects the second option, downloading only 45MB of difference blocks to complete the full-level update, significantly saving bandwidth and update time.

[0134] The second approach involves downloading the required resources for each of the two file types in segments. Specifically, the client can execute steps S301'-S302': for non-immediately updated files, download their dedicated complete resource blocks (not the entire package) from the first data segment; for nearby updated files, download their dedicated difference blocks from the second data segment. For example, in the above hierarchy: for two non-immediately updated files, only their respective core complete resource fragments (such as mission story files, dedicated models) are downloaded, totaling 80MB; for one nearby updated file, only the difference blocks (such as mission parameter adjustment packages) of 5MB are downloaded. By obtaining the data in targeted segments, redundant data from the entire package can be avoided, achieving a more precise 85MB data download beyond the 130MB (full) and 45MB (total difference) downloads, balancing update efficiency and resource consumption.

[0135] It should be noted that this embodiment can also be an improvement based on the sixth embodiment.

[0136] It is easy to see that in this embodiment, the two parallel implementation methods optimize the efficiency of mixed version update scenarios within the same level from different dimensions: the former, by calculating and selecting the scheme with the smaller total data volume, can minimize the amount of downloaded data, significantly saving network bandwidth and update time; the latter, by selectively acquiring the required resources (difference blocks / complete resource blocks) for different update types of files and combining segmented downloads, can accurately avoid redundant data from downloading the entire package, improving the flexibility and accuracy of resource acquisition. Both achieve a balance between update efficiency and resource consumption, adapting to different network environments and resource demand scenarios, and enhancing the adaptability of client updates and user experience.

[0137] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0138] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0139] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0140] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0141] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0142] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0143] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0144] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0145] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0146] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0147] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0148] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0149] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0150] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0151] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0152] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0153] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A resource update method, characterized in that, The method is applied to the server side, and the method includes: Based on the current version of the resource file, determine the first data and the second data; wherein, the first data is used to provide the complete resource block of the current version; and the second data is used to provide the difference block between the current version and the previous version. Based on the first data and the second data, a hierarchical aggregation file is determined; wherein, the hierarchical aggregation file is used to characterize the mapping relationship between complete resource blocks and difference blocks corresponding to each resource level.

2. The method according to claim 1, characterized in that, The first data specifically refers to: multiple chunks determined based on the current version of the resource file; The second data specifically refers to the difference blocks determined by comparing the current version of the resource file with the previous version of the resource file.

3. The method according to claim 1, characterized in that, The step of determining the hierarchical aggregation file based on the first data and the second data includes: Based on a preset resource hierarchy dimension, complete resource blocks in the first data and difference blocks in the second data are grouped; wherein, the preset resource hierarchy dimension is used to define the rules for logical association or similar attributes between data blocks; Aggregate complete resource blocks within the same group into a first aggregate file, and aggregate difference blocks within the same group into a second aggregate file; Based on the first and second aggregate files corresponding to each group, the hierarchical aggregate file is generated to establish the mapping relationship between the preset resource hierarchy dimension and the aggregated file.

4. The method according to claim 3, characterized in that, The step of aggregating complete resource blocks within the same group into a first aggregate file and aggregating difference blocks within the same group into a second aggregate file includes: In response to the existence of multiple complete resource blocks in the same group, the multiple complete resource blocks are packaged into a single complete resource aggregation file as the first aggregation file; In response to the existence of multiple difference blocks in the same group, the multiple difference blocks are packaged into a single difference aggregate file as the second aggregate file.

5. The method according to claim 3, characterized in that, The method is applied to game projects; the preset resource hierarchy dimensions include at least one of the following: resource type, game scene, and game task. The resource type is used to divide resource blocks of the same type into the first group; The game scene to which they belong is used to divide resource blocks belonging to the same game scene into the second group; The game task to which they belong is used to divide resource blocks belonging to the same game task into the third group; The first group, the second group, and the third group are independent of each other.

6. The method according to any one of claims 1 to 5, characterized in that, The method also includes: During the generation of the hierarchical aggregation file, at least one of selective compression or selective encryption operations is performed on the hierarchical aggregation file.

7. A resource update method, characterized in that, The method is applied to a client, and the method includes: Obtain the hierarchical aggregation file generated by the server as described in any one of claims 1-6; Based on the hierarchical aggregation file, determine the target hierarchy; Perform a differential update operation based on the first and second data integrated in the target level.

8. The method according to claim 7, characterized in that, Determining the target level based on the hierarchical aggregation file includes: Based on the local resource version and the version information in the hierarchical aggregation file, determine the type of version gap for the resource to be updated; The target level is determined based on the resource level dimensions in the hierarchical aggregation file and the attribute characteristics of the resource to be updated.

9. The method according to claim 8, characterized in that, The client maintains a file status table to record the version identifiers of each local file; the determination of the version difference type of the resource to be updated based on the local resource version and the version information in the hierarchical aggregation file includes: The version difference status is determined by comparing the local file version identifier recorded in the file status table with the version identifier of the corresponding server file in the hierarchical aggregation file. Based on the version gap status, the version gap type is determined to be either an adjacent version update or a non-adjacent version update.

10. The method according to claim 9, characterized in that, The step of performing a differential update operation based on the integrated first and second data in the target level includes: When the version gap type is a non-adjacent version update, a complete resource block is obtained from the first data of the target level to replace the local resource; When the version difference type is an upcoming version update, the difference block is obtained from the second data of the target level and merged with the local resources.

11. The method according to claim 7, characterized in that, The step of determining the target level based on the hierarchical aggregation file includes: determining the target level to be downloaded level by level in hierarchical order according to the preset resource hierarchical dimensions in the hierarchical aggregation file.

12. The method according to claim 7, characterized in that, When files at the same level require both adjacent and non-adjacent version updates, the differential update operation includes: Calculate the first total data volume of all complete resource blocks of the files to be updated; Calculate the second total data volume for obtaining all the difference blocks of the files to be updated; Based on the first total data volume and the second total data volume, select the scheme that requires the least amount of download resources.

13. The method according to claim 7, characterized in that, When files at the same level require both adjacent and non-adjacent version updates, the differential update operation includes: For files that require an upcoming version update, the corresponding difference blocks are retrieved from the second data of the hierarchical aggregated file and downloaded. For files that require non-adjacent version updates, the corresponding complete resource block is obtained from the first data of the hierarchical aggregate file and downloaded. Specifically, both the difference block and the complete resource block are downloaded in segments, with each segment downloading a portion of the data content separately.

14. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as claimed in any one of claims 1 to 6 or the steps of the method as claimed in any one of claims 7 to 13.

15. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6 or the steps of the method according to any one of claims 7 to 13.

16. A computer program product comprising a computer program / instructions, characterized in that, When executed by a processor, the computer program / instructions implement the steps of the method according to any one of claims 1 to 6 or the steps of the method according to any one of claims 7 to 13.

Images