Game running cache resource sharing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a game running cache resource sharing method and device, electronic equipment and a storage medium, and relates to the technical field of game development. The method comprises the following steps: a client sends a configuration acquisition request to a server, receives and analyzes a returned configuration file, and initializes a plurality of cache processing subclass instances inherited from a preset base class to correspond to different types of runtime cache tasks; when a target cache task is triggered, obtaining a content fingerprint of the target cache task, sending a query request to a server, and judging whether matched existing cache data exists or not; if the data exists, the client downloads the data and directly uses the data for task processing, the client does not need to repeatedly execute high-cost calculation tasks, cross-user and cross-device cache resource sharing is achieved by multiplexing other users or results generated in the historical operation process, and the performance during game operation is effectively optimized.

Description

Technical Field

[0001] This invention relates to the field of game development technology, and more specifically, to a method, apparatus, electronic device, and storage medium for sharing game runtime cache resources. Background Technology

[0002] In the operation of modern 3D games, there are a large number of computationally intensive or I / O-intensive time-consuming tasks, such as shader compilation, texture decoding, physical simulation pre-calculation, and animation skinning data generation. If these tasks are executed synchronously in the game's main thread, it can easily lead to a drop in frame rate and screen stuttering, seriously affecting the player's gaming experience, especially when entering the game for the first time or loading a new scene.

[0003] To alleviate this problem, the industry commonly employs local caching mechanisms: after the first execution of a time-consuming task, its result is persisted in binary form as a cache file (such as a shader cache), and subsequent runs directly read from this cache file to skip the original time-consuming task. However, this traditional approach is limited to "compile once, reuse many times" in a single-machine environment and cannot solve the fundamental problem that all time-consuming tasks still need to be completed on the first run. For new users or devices that have cleared the cache, the initial startup still faces a severe performance bottleneck, resulting in a poor user experience. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method, apparatus, electronic device and storage medium for sharing game runtime cache resources.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows: In a first aspect, the present invention provides a method for sharing game runtime cache resources, applied to a client, wherein the client communicates with a server, and the method includes: Send a configuration retrieval request to the server and receive the configuration file returned by the server; The configuration file initializes multiple cache processing subclass instances that inherit from a preset base class. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime. When any type of target cache task is triggered in the game, the content fingerprint of the target cache task is obtained, and a cache query request carrying the content fingerprint is sent to the server to query whether there is existing cache data that matches the content fingerprint. If the server returns a response, the existing cached data is downloaded from the server, and the target cache task is processed based on the existing cached data.

[0006] Optionally, the method further includes: If the server returns a non-existent response, the target caching task is executed, and local cache data corresponding to the target caching task is generated.

[0007] Optionally, after generating the local cache data corresponding to the target cache task, the method further includes: If, based on the type of the target cache task, the local cache data is determined to meet the preset upload conditions, then the local cache data is uploaded to the server.

[0008] Optionally, the step of uploading the local cached data to the server includes: During a preset time period after each frame of the game scene rendering is completed, all local cached data to be uploaded is scheduled in a unified manner and uploaded to the server in batches asynchronously.

[0009] Optionally, the step of determining whether the local cached data corresponding to the target cache task meets the preset upload conditions based on the type of the target cache task includes: If the number of locally cached data generated corresponding to the type of the target cache task is not less than a preset threshold, then the local cached data corresponding to the target cache task is determined to meet the preset upload conditions.

[0010] Secondly, the present invention provides a method for sharing game runtime cache resources, applied to a server, wherein the server and the client are connected in a communication connection, and the method includes: The system receives a configuration retrieval request sent by the client and returns a configuration file to the client, so that the client initializes multiple cache processing subclass instances that inherit from a preset base class according to the configuration file. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime. The system receives a cache query request sent by the client, which carries a content fingerprint of the target cache task. The system queries whether there is existing cache data that matches the content fingerprint. The content fingerprint is obtained by the client when it triggers any type of target cache task in the game. If the existing cached data exists, a presence response is returned to the client, instructing the client to download the existing cached data from the server to process the target cache task.

[0011] Thirdly, the present invention provides a game runtime cache resource sharing device, applied to a client, wherein the client is communicatively connected to a server, and the device includes: The first transceiver module is used to send a configuration retrieval request to the server and receive the configuration file returned by the server. The first processing module is used to initialize multiple cache processing subclass instances that inherit from a preset base class according to the configuration file. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime. When any type of target cache task is triggered in the game, the module obtains the content fingerprint of the target cache task and sends a cache query request carrying the content fingerprint to the server to query whether there is existing cache data that matches the content fingerprint. If the server returns a response indicating that there is, the module downloads the existing cache data from the server and processes the target cache task according to the existing cache data.

[0012] Fourthly, the present invention provides a game runtime cache resource sharing device, applied to a server, wherein the server is communicatively connected to a client, and the device includes: The second transceiver module is used to receive the configuration acquisition request sent by the client and return the configuration file to the client so that the client initializes multiple cache processing subclass instances that inherit from a preset base class according to the configuration file. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime. The second processing module is used to receive a cache query request sent by the client carrying a content fingerprint of the target cache task, and to query whether there is existing cache data that matches the content fingerprint. The content fingerprint is obtained by the client when triggering any type of target cache task in the game. If the existing cache data exists, a presence response is returned to the client to instruct the client to download the existing cache data from the server to process the target cache task.

[0013] Fifthly, the present invention provides an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the game runtime cache resource sharing method described in the first aspect above, or the game runtime cache resource sharing method described in the second aspect above.

[0014] In a sixth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the game runtime cache resource sharing method described in the first aspect above, or the game runtime cache resource sharing method described in the second aspect above.

[0015] The game runtime cache resource sharing method, apparatus, electronic device, and storage medium provided in this invention involve a client sending a configuration acquisition request to a server and receiving a configuration file returned by the server. Multiple cache processing subclass instances, inheriting from a preset base class, are initialized based on the configuration file. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime. When any type of target cache task is triggered in the game, the content fingerprint of the target cache task is obtained, and a cache query request carrying the content fingerprint is sent to the server to check if existing cache data matching the content fingerprint exists. If the server returns a response indicating existence, the existing cache data is downloaded from the server, and the target cache task is processed based on the existing cache data. Thus, the client can reuse the results generated by other users or in previous runs without repeatedly executing high-cost computational tasks, achieving cross-user and cross-device cache resource sharing and effectively optimizing game runtime performance.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This figure shows a schematic block diagram of an electronic device provided by an embodiment of the present invention; Figure 2 This illustration shows a flowchart of a game operation cache resource sharing method applied to a client, provided by an embodiment of the present invention. Figure 1 ; Figure 3 This illustration shows a flowchart of a game operation cache resource sharing method applied to a client, provided by an embodiment of the present invention. Figure 2 ; Figure 4 This illustration shows a flowchart of a game operation cache resource sharing method applied to a client, provided by an embodiment of the present invention. Figure 3 ; Figure 5 The illustration shows a flowchart of a game operation cache resource sharing method applied to a server, according to an embodiment of the present invention. Figure 6 This diagram illustrates a functional block diagram of a game operation cache resource sharing device for a client application, provided by an embodiment of the present invention. Figure 7 The diagram shows a functional block diagram of a game operation cache resource sharing device for servers provided by an embodiment of the present invention.

[0019] Icons: 100 - Electronic device; 110 - Memory; 120 - Processor; 130 - Communication module; 200 - Game operation cache resource sharing device applied to the client; 201 - First transceiver module; 202 - First processing module; 300 - Game operation cache resource sharing device applied to the server; 301 - Second transceiver module; 302 - Second processing module. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0022] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0023] Please refer to Figure 1 This is a block diagram of an electronic device 100. The electronic device 100 includes a memory 110, a processor 120, and a communication module 130. The memory 110, processor 120, and communication module 130 are electrically connected to each other directly or indirectly to realize data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0024] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0025] The processor 120 is used to read / write data or programs stored in the memory 110 and to perform corresponding functions.

[0026] The communication module 130 is used to establish a communication connection between the electronic device 100 and other communication terminals through the network, and to send and receive data through the network.

[0027] It should be understood that, Figure 1 The structure shown is only a schematic diagram of the electronic device 100; the server may also include components such as... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.

[0028] Figure 1 The electronic device 100 shown can be either a client or a server.

[0029] To overcome the shortcomings of the prior art, embodiments of the present invention provide a method for sharing game runtime cache resources applied to a client and a method for sharing game runtime cache resources applied to a server, which will be described in detail below.

[0030] Please refer to Figure 2 The method for sharing game runtime cache resources applied to the client includes steps S101 to S104.

[0031] S101 sends a configuration retrieval request to the server and receives the configuration file returned by the server.

[0032] In the initial stage after the client launches the game program, the configuration acquisition process is executed first: the client creates an instance of a configuration request subclass (e.g., ConfigRequester) that inherits from the preset base class AcquisitionWorkerBase, and executes its Execute() method in the first frame of the game. This method sends a synchronous or asynchronous configuration acquisition request to a remote server, and the target address of the request is determined by the preset server IP, port, and Uniform Resource Locator (URL).

[0033] After receiving the request, the server returns a structured configuration file (e.g., JSON or XML format). This configuration file contains key configuration items such as storage path information for various cached resources (i.e., URLs corresponding to different cache types), threshold parameters for triggering local upload operations, cache validity strategies, and server communication timeout settings.

[0034] The client receives and parses the configuration file, providing a basis for the initialization of subsequent cache processing modules.

[0035] S102 initializes multiple cache processing subclass instances that inherit from a preset base class according to the configuration file.

[0036] Each cache processing subclass instance is used to handle different types of cache tasks during game runtime.

[0037] After obtaining the configuration file, the client uses the DataAcquisition class, managed by a singleton pattern, to initialize multiple instances of specific cache processing subclasses based on the parameters in the configuration file. Each subclass instance inherits from a unified base class AcquisitionWorkerBase and overrides its implementation to adapt to the specific type of cache task.

[0038] For example: the ShaderCacheWorker subclass for handling shader caching; and a subclass that can be extended to handle other types of tasks such as texture compression caching and intermediate result caching for AI inference models.

[0039] During initialization, each subclass instance determines its corresponding server storage location based on the URL specified in the configuration file and sets local behavior strategies (such as upload frequency control, cache refresh condition isNeedFlush() judgment logic, etc.). All subclass instances are registered with the DataAcquisition singleton manager for unified scheduling and execution.

[0040] S103: When any type of target cache task is triggered in the game, obtain the content fingerprint of the target cache task and send a cache query request carrying the content fingerprint to the server to query whether there is existing cache data that matches the content fingerprint.

[0041] During game execution, when a time-consuming task is triggered (such as the initial compilation of a new shader), the corresponding cache handling subclass will intervene in the processing flow. At this time, the client first calculates the unique identifier of the task's input content—that is, the "content fingerprint." The MD5 hash algorithm can be used to perform a digest operation on the original shader source code and its compilation environment parameters (such as predefined macro combinations, GPU feature flags, etc.) to generate a fixed-length content fingerprint string.

[0042] Subsequently, the client sends a cache query request to the server through a generic interface provided by the DataAcquisition class (such as boolisHaveShaderCache(const char* md5)). This request carries the content fingerprint, accesses the namespace (bucket + URL path) of the corresponding cache type in the MinIO object storage system, and queries whether the corresponding cache file already exists.

[0043] S104, if the server returns an existing response, download the existing cached data from the server and process the target cache task based on the existing cached data.

[0044] If the server returns a "hit" (meaning that cached data corresponding to a matching content fingerprint exists), the client calls the download interface (such as char* downloadShaderCache(const char* md5)) to download the cached data asynchronously or synchronously from the server's object storage service.

[0045] For shader caching scenarios, the downloaded data is pre-compiled binary intermediate code (such as DXBC, SPIR-V, etc.), which can be directly loaded and used by the graphics driver, thus skipping the time-consuming local compilation process, significantly shortening the task execution time, and avoiding frame rate fluctuations.

[0046] As a result, the client can reuse the results generated by other users or in the past without having to repeatedly perform high-cost computing tasks, realizing cross-user and cross-device cache resource sharing and effectively optimizing the performance of the game runtime.

[0047] Further, please refer to Figure 3 The method for sharing game runtime cache resources applied to the client also includes step S105.

[0048] S105, if the server returns a non-existent response, then execute the target cache task and generate the local cache data corresponding to the target cache task.

[0049] When the client sends a cache query request to the server in step S103, if the server returns "miss" (i.e., there is no existing cached data that matches the content fingerprint), it indicates that the result required for the current task has not been pre-calculated and uploaded for sharing by other clients.

[0050] At this point, the client switches to local execution mode and starts the complete processing flow of the target cache task normally. Taking shader compilation as an example, the graphics system will call the GPU driver interface or a high-level shading language compiler (such as HLSL or GLSL compiler) to parse, optimize, and generate binary code for the shader source code, completing the time-consuming operations that would otherwise have to be performed.

[0051] After the task is successfully executed, the client generates the corresponding local cache data—for example, the compiled shader binary intermediate representation (such as SPIR-V, DXBC, etc.)—and temporarily stores it in the local cache directory for quick reuse in this and subsequent runs.

[0052] To provide shared resources to other clients, please refer to... Figure 4 After generating the local cache data corresponding to the target cache task, the game runtime cache resource sharing method applied to the client further includes step S106.

[0053] S106. If the local cached data meets the preset upload conditions based on the type of the target cache task, then the local cached data is uploaded to the server.

[0054] In a possible implementation, the process of "determining whether the local cached data meets the preset upload conditions based on the type of the target cached task" can be as follows: if the number of locally cached data generated corresponding to the type of the target cached task is not less than a preset threshold, then the local cached data corresponding to the target cached task is determined to meet the preset upload conditions.

[0055] After completing the target caching task and generating the corresponding local cache data, the client does not immediately upload the data. Instead, it determines whether the preset upload conditions are met based on the upload strategy associated with the type of caching task. Only when the conditions are met is the upload operation to the server triggered, thereby avoiding waste of system resources and a surge in server load caused by frequent small file network requests.

[0056] The "preset upload conditions" are dynamic policy parameters configured and managed according to the type of cache task. These conditions are determined based on a threshold for the number of locally generated cache data: that is, if the cumulative number of newly generated cache files corresponding to the target cache task of the current type (such as a shader compilation task) reaches or exceeds the preset threshold (e.g., 500), then the upload conditions are deemed met.

[0057] This threshold information originates from the configuration file obtained in step S101 and is uniformly distributed by the server. It can be flexibly adjusted according to different game projects, hardware environments, or network conditions. For example, for large-scale 3D games, a higher upload threshold can be set to reduce communication frequency; while for cloud gaming scenarios with low latency requirements, the threshold can be lowered to speed up cache sharing.

[0058] Furthermore, in a possible implementation, "uploading local cached data to the server" could be done by scheduling all local cached data to be uploaded in a unified manner during a preset time period after the rendering of each frame of the game scene, and uploading it to the server in batches asynchronously.

[0059] Understandably, the upload operation is not performed in real time, but is scheduled uniformly within a preset period after each frame of the game scene rendering ends. That is, the DataAcquisition singleton class calls the Execute() method of all registered cache processing subclass instances at the end of each frame (post-frame rendering phase), and each subclass checks its own status to see if it meets the upload conditions during this phase.

[0060] For example, a ShaderCacheWorker instance counts the number of new shader caches added since the last upload. If a threshold is reached, it packages this cached data and initiates an asynchronous upload process. Data of multiple cache types to be uploaded can be batched into one or more network requests and sent to the corresponding URL address on the server via HTTP / HTTPS protocol, achieving efficient aggregated transmission.

[0061] An asynchronous, non-blocking mechanism is used during the upload process to ensure that the execution of the main rendering thread or other critical game logic is not affected. Upload tasks are handled by independent worker threads or coroutines and are equipped with retry mechanisms, breakpoint resumption support, and error logging to ensure data integrity and transmission reliability.

[0062] After receiving an upload request, the server stores the locally cached data in a designated bucket of the MinIO object storage system using a content fingerprint (such as an MD5 value) as a unique key, forming a globally shared cache resource index. Subsequently, any client performing the same task can query and download the data using the content fingerprint for reuse, achieving cross-user and cross-device collaborative cache optimization.

[0063] By introducing a task-type-based conditional upload mechanism and a frame-level unified scheduling strategy, this invention effectively balances the contradiction between the timeliness of cache updates and system performance overhead. On the one hand, it avoids the high-frequency communication problem of "uploading every time a cache is generated"; on the other hand, it ensures that valuable cache results can be fed back to the shared pool in a timely manner, improving the overall system's intelligence level and group performance gains.

[0064] Furthermore, for any new types of runtime time-consuming tasks added in the future (such as AI behavior tree pre-calculation results, intermediate states of physical simulation, font rendering cache, etc.), simply inherit the AcquisitionWorkerBase base class and implement the corresponding isNeedFlush() and Execute() methods to seamlessly integrate into the existing architecture without modifying the core scheduling logic.

[0065] The following section provides a detailed introduction to the method of sharing game runtime cache resources applied to servers.

[0066] Please refer to Figure 5 The method for sharing game runtime cache resources applied to the server includes steps S201 to S203.

[0067] S201: Receive the configuration retrieval request sent by the client and return the configuration file to the client so that the client can initialize multiple cache processing subclass instances that inherit from the preset base class according to the configuration file.

[0068] Each cache processing subclass instance is used to handle different types of cache tasks during game runtime.

[0069] After the client launches the game program, it first initiates a configuration retrieval request. The server receives HTTP / HTTPS requests from the client by listening on a specified network port. This request is initiated by the ConfigRequester subclass, which inherits from the AcquisitionWorkerBase base class, and the target address corresponds to the preset configuration service URL.

[0070] Upon receiving the request, the server reads a predefined structured configuration file (e.g., JSON or YAML format) from local or distributed configuration storage and returns it as the response body to the client. The configuration file contains at least the following information: the server storage path corresponding to various caching tasks (i.e., URL routes for different cache types); the cache upload trigger threshold (e.g., "trigger an upload every 500 shader cache files generated"); and runtime control parameters such as cache expiration policy, communication timeout, and retry mechanism parameters.

[0071] Through this configuration file, the client can dynamically initialize multiple specific types of cache processing subclass instances locally (such as ShaderCacheWorker, and the future expandable TextureCacheWorker, etc.). Each instance is bound to a specific server storage location and service strategy according to its corresponding task type, ensuring accurate routing and efficient execution of subsequent cache operations.

[0072] S202, receive a cache query request sent by the client carrying the content fingerprint of the target cache task, and query whether there is existing cached data that matches the content fingerprint.

[0073] The content fingerprint is obtained by the client when it triggers any type of target cache task in the game.

[0074] During game execution, when a client triggers a time-consuming task (such as compiling a shader for the first time), a unique identifier for the task's input content—the "content fingerprint"—is calculated first. Optionally, this content fingerprint can be generated by performing a digest operation on the original resource data and its context parameters (such as shader source code, macro definition combinations, GPU feature identifiers, etc.) using the MD5 hash algorithm to ensure global uniqueness.

[0075] The client then sends a cache query request to the server, carrying the content fingerprint and pointing to the URL interface corresponding to the cache type. Upon receiving the request, the server parses the content fingerprint information and uses it as the key to perform a lookup operation in the backend object storage system.

[0076] Optionally, the server can use the open-source MinIO object storage service as the underlying storage engine, supporting high concurrency and low latency object access. The server checks whether a cached object file with the content fingerprint exists in the specified bucket and namespace by calling the MinIO SDK interface.

[0077] S203, if existing cached data exists, a response indicating existence is returned to the client, instructing the client to download the existing cached data from the server to process the target cache task.

[0078] If the server confirms the existence of a cached object file in object storage that matches the content fingerprint, it sends a response message to the client. This response message may include the following additional information: the size of the cached data; the last update time; a checksum (such as ETag or SHA-256 value) for the client to verify integrity; and a download link (presigned URL) for the client to directly access MinIO for efficient downloading.

[0079] Once the client receives the response, it can call the download interface (such as downloadShaderCache(const char* md5)) to obtain remote cached data, avoiding repeated execution of original time-consuming tasks (such as recompiling shaders), significantly shortening processing time, and improving frame rate stability and user experience.

[0080] This invention, through the construction of a unified cache indexing and distribution mechanism on the server side, achieves runtime cache resource sharing across clients, devices, and sessions. The server not only acts as a static resource configuration center but also undertakes the core functions of dynamic cache discovery and response, enabling the entire system to possess a self-optimizing capability that "gets faster with use." As the number of connected users increases, the number of effective cache entries accumulated on the server side continues to grow, resulting in a continuously amplified collective performance gain.

[0081] Furthermore, the game runtime cache resource sharing method applied to the server and the game runtime cache resource sharing method applied to the client form a closed-loop collaboration: the client is both a cache consumer and a potential producer (the subsequent upload mechanism will be discussed in other steps); the server acts as a trusted relay and persistence hub, ensuring the security, consistency and scalability of resource sharing.

[0082] Furthermore, the server also receives locally cached data uploaded by the client and stores it in the object storage system for subsequent querying and reuse by other clients.

[0083] Understandably, after the client completes a time-consuming task (such as shader compilation) and generates the corresponding local cache data, if the client determines that the preset upload conditions are met according to the caching processing strategy for that task type (such as the number of newly generated caches reaching a threshold), the client will encapsulate the cache data into an upload request and send it to the server.

[0084] The server receives the upload request by listening to a specified URL interface. The request contains the following key information: content fingerprint (such as an MD5 hash value), serving as a unique identifier for the cached data; the cached data body (such as compiled shader binary code); cache type identifier (such as ShaderCache, TextureTranscodeCache, etc.), used for routing to the correct storage namespace; and optional metadata information, such as generation time, GPU model, driver version, game resource version number, etc., used for subsequent cache validity verification or intelligent matching.

[0085] Upon receiving a request, the server first parses the content fingerprint and cache type, and determines the target storage location—the corresponding bucket and directory path in the MinIO object storage system—based on the configuration policy. Then, the server checks if the data corresponding to the content fingerprint already exists. If an object file with the same key already exists, it can choose to skip storage (to avoid duplicate writes) or determine whether to update based on timestamp / version information, thus ensuring data consistency.

[0086] Once the write operation is confirmed, the server calls the SDK interface provided by MinIO to upload and persistently store the received cached data in a distributed object storage cluster, using the content fingerprint as the object key. This process supports advanced features such as resume upload and multi-part upload, ensuring the stability and efficiency of large file transfers.

[0087] Optionally, the server also records access statistics for cached data, such as: first upload time; cumulative download count; and the range of source client IP addresses (which can be anonymized). This information can be used for subsequent cache lifecycle management (such as hot and cold data tiering), performance analysis, and resource optimization decisions.

[0088] Meanwhile, after successful storage, the server returns an upload success response to the client and updates the internal cache index service when necessary (such as building a high-speed cache directory in conjunction with Redis) to accelerate subsequent query hit speed.

[0089] To perform the corresponding steps in the above embodiments and various possible methods, the following provides an implementation of a game runtime cache resource sharing device 200 applied to a client and a game runtime cache resource sharing device 300 applied to a server. Further, please refer to... Figure 6 and 7 , Figure 6 and 7 These are functional block diagrams of a game runtime cache resource sharing device 200 applied to a client and a game runtime cache resource sharing device 300 applied to a server, respectively, provided in embodiments of the present invention. It should be noted that the basic principles and technical effects of the game runtime cache resource sharing device 200 applied to a client and the game runtime cache resource sharing device 300 applied to a server provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The game runtime cache resource sharing device 200 applied to a client includes: The first transceiver module 201 is used to send a configuration retrieval request to the server and receive the configuration file returned by the server.

[0090] The first processing module 202 is used to initialize multiple cache processing subclass instances that inherit from a preset base class according to the configuration file. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime. When any type of target cache task is triggered in the game, the content fingerprint of the target cache task is obtained, and a cache query request carrying the content fingerprint is sent to the server to query whether there is existing cache data that matches the content fingerprint. If the server returns a response indicating that there is, the existing cache data is downloaded from the server, and the target cache task is processed according to the existing cache data.

[0091] The game runtime cache resource sharing device 300 applied to the server includes: The second transceiver module 301 is used to receive the configuration acquisition request sent by the client and return the configuration file to the client so that the client can initialize multiple cache processing subclass instances that inherit from the preset base class according to the configuration file. Each cache processing subclass instance is used to handle different types of cache tasks during game runtime.

[0092] The second processing module 302 is used to receive a cache query request sent by the client carrying the content fingerprint of the target cache task, and to query whether there is existing cache data that matches the content fingerprint. The content fingerprint is obtained by the client when triggering any type of target cache task in the game. If there is existing cache data, a response is returned to the client to instruct the client to download the existing cache data from the server to process the target cache task.

[0093] Optionally, the above modules can be stored in the form of software or firmware. Figure 1 The memory 110 shown is either stored in or embedded in the operating system (OS) of the electronic device 100, and can be used by... Figure 1 The processor 120 executes the program. Meanwhile, the data and program code required to execute the above modules can be stored in the memory 110.

[0094] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. 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 marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0095] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

[0097] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A game running cache resource sharing method, characterized in that, The method is applied to a client in communication connection with a server, and comprises the following steps: sending a configuration obtaining request to the server and receiving a configuration file returned by the server; initializing a plurality of cache processing subclass instances inherited from a preset base class according to the configuration file, each of the cache processing subclass instances being used for processing different types of cache tasks during game running; when a target cache task of any type is triggered in the game, obtaining a content fingerprint of the target cache task, and sending a cache query request carrying the content fingerprint to the server to query whether there is existing cache data matching the content fingerprint; if an existing response is returned by the server, downloading the existing cache data from the server, and processing the target cache task according to the existing cache data.

2. The method of claim 1, wherein the game running cache resource sharing method is characterized by, The method further comprises the following steps: if a non-existing response is returned by the server, executing the target cache task and generating local cache data corresponding to the target cache task.

3. The method of claim 2, wherein the game running cache resource sharing method is characterized by, After the local cache data corresponding to the target cache task is generated, the method further comprises the following steps: if it is determined that the local cache data meets a preset uploading condition according to the type of the target cache task, uploading the local cache data to the server.

4. The method of claim 3, wherein the game running cache resource sharing method is characterized by, The step of uploading the local cache data to the server comprises the following steps: at a preset time period after each frame of game scene rendering is completed, uniformly scheduling all local cache data to be uploaded, and uploading the local cache data to the server in batches in an asynchronous manner.

5. The method of claim 3, wherein the game running cache resource sharing method is characterized by, The step of determining that the local cache data corresponding to the target cache task meets the preset uploading condition according to the type of the target cache task comprises the following steps: if the number of generated local cache data corresponding to the type of the target cache task is not less than a preset threshold, it is determined that the local cache data corresponding to the target cache task meets the preset uploading condition.

6. A game running cache resource sharing method, characterized in that, The method is applied to a server in communication connection with a client, and comprises the following steps: receiving a configuration obtaining request sent by the client, and returning a configuration file to the client, so that the client initializes a plurality of cache processing subclass instances inherited from a preset base class according to the configuration file, wherein each of the cache processing subclass instances is used for processing different types of cache tasks during game running; receiving a cache query request carrying a content fingerprint of a target cache task sent by the client, and querying whether there is existing cache data matching the content fingerprint, the content fingerprint being obtained by the client when a target cache task of any type is triggered in the game; if the existing cache data exists, returning an existing response to the client to instruct the client to download the existing cache data from the server to process the target cache task.

7. A game running cache resource sharing apparatus, characterized by comprising: a game running cache resource sharing unit configured to share a cache resource of a game running apparatus with another game running apparatus. The device is applied to a client in communication connection with a server, and comprises the following steps: a first transceiving module configured to send a configuration obtaining request to the server and receive a configuration file returned by the server; The first processing module is configured to initialize a plurality of cache processing subclass instances inherited from a preset base class according to the configuration file, each of the cache processing subclass instances being configured to process a cache task of a different type during game running; when a target cache task of any type is triggered in the game, a content fingerprint of the target cache task is obtained, and a cache query request carrying the content fingerprint is sent to the server to query whether there is existing cache data matching the content fingerprint; if there is an existing cache data, the existing cache data is downloaded from the server, and the target cache task is processed according to the existing cache data.

8. A game running cache resource sharing apparatus, characterized by, The application is applied to a server, and the server is in communication connection with a client. The second receiving module is configured to receive a configuration obtaining request sent by the client, and return a configuration file to the client, so that the client initializes a plurality of cache processing subclass instances inherited from a preset base class according to the configuration file, wherein each of the cache processing subclass instances is configured to process a cache task of a different type during game running. The second processing module is configured to receive a cache query request carrying a content fingerprint of a target cache task sent by the client, query whether there is existing cache data matching the content fingerprint, and return an existing response to the client if there is the existing cache data, so as to instruct the client to download the existing cache data from the server to process the target cache task, wherein the content fingerprint is obtained by the client when a target cache task of any type is triggered in the game.

9. An electronic device, comprising: The computer program is executed by the processor to implement the game running cache resource sharing method of any one of claims 1-5 or the game running cache resource sharing method of claim 6.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the game running cache resource sharing method of any one of claims 1-5 or the game running cache resource sharing method of claim 6.

Images