File access method and device, electronic equipment, storage medium and program product

Abstract

The application discloses a file access method and device, a storage medium, equipment and a program product. The method comprises the following steps: in response to a file access request for a target file under a target path, determining a target file loader; if the loader type of the target file loader is a scatter file loader, judging whether the target path matches predetermined target path information; and if it is determined that the target path matches the target path information, loading the target file through the target file loader to access the target file. In this way, the target file loader is determined in response to the file access request, the path matching verification is first performed on the scatter file loader, and the target file is loaded through the scatter file loader after the path matching passes, so that the triggering of a large number of unnecessary underlying file access operations is avoided, the number of high-time-consuming system calls is reduced, and the time cost in the file access process is reduced to a certain extent, so that the effectiveness and execution efficiency of the file access are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a file access method, a file access device, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In related technologies, different loaders in a virtual file system exhibit performance differences of orders of magnitude. Specifically, scattered file loaders typically rely on the operating system's file interface for file access, with each call taking milliseconds. Package file loaders, on the other hand, typically use in-memory hash indexes for file access, with each lookup taking microseconds. However, when accessing files, indiscriminate traversal across different loaders results in numerous high-overhead and inefficient system calls being executed on scattered file loaders, leading to inefficient file access and negatively impacting the user experience to some extent. Summary of the Invention

[0003] This application provides a file access method, a file access device, a computer-readable storage medium, an electronic device, and a computer program product. By responding to a file access request, a target file loader is determined. The path matching verification is first performed on the scattered file loader. After the path matching is successful, the target file is loaded through the scattered file loader. This avoids triggering a large number of unnecessary low-level file access operations to a certain extent, reduces the number of time-consuming system calls, and thus reduces the time overhead in the file access process to a certain extent, improving the effectiveness and execution efficiency of file access.

[0004] On one hand, embodiments of this application provide a file access method, the method comprising: In response to a file access request for a target file under the target path, determine the target file loader; If the loader type of the target file loader is a scattered file loader, it is determined whether the target path matches the pre-determined target path information, wherein the scattered file loader is used to load files stored in the form of independent files, and the target path information is used to indicate the paths that the scattered file loader is allowed to load. If the target path is determined to match the target path information, the target file is loaded by the target file loader to access the target file.

[0005] On the other hand, embodiments of this application provide a file access device, the device comprising: The loader determination module is used to determine the target file loader in response to a file access request for a target file under the target path; The path matching judgment module is used to determine whether the target path matches the pre-determined target path information if the loader type of the target file loader is a scattered file loader; wherein, the scattered file loader is used to load files stored in the form of independent files, and the target path information is used to indicate the paths that the scattered file loader is allowed to load. The file loading and access module is used to load the target file through the target file loader to access the target file if it is determined that the target path matches the target path information.

[0006] On the other hand, embodiments of this application provide an electronic device, which includes a processor and a memory. The memory stores a computer program, and the processor executes the file access method as described in any of the above embodiments by calling the computer program stored in the memory.

[0007] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the file access method as described in any of the above embodiments.

[0008] On the other hand, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the file access method as described in any of the above embodiments.

[0009] The file access method, file access device, computer-readable storage medium, electronic device, and computer program product provided in this application embodiment, in this application embodiment, by responding to a file access request for a target file under a target path, determines the corresponding target file loader. When the loader type of the target file loader is a scattered file loader, the scattered file loader first performs a matching judgment between the target path and the pre-determined target path information. When the target path matches the target path information, the target file is loaded through the scattered file loader. This realizes the control of the access scope of the scattered file loader. Compared with the scheme of directly loading the file without performing path verification on the scattered file loader, the invalid millisecond-level system calls of the scattered file loader are replaced with microsecond-level path matching operations, effectively filtering out unnecessary path requests. This avoids triggering a large number of unnecessary underlying file access operations to a certain extent, reduces the number of time-consuming system calls, simplifies the data processing flow of file access, and thus reduces the time overhead in the file access process to a certain extent, improving the effectiveness and execution efficiency of file access. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating the file access method provided in an embodiment of this application.

[0012] Figure 2 This is a schematic diagram illustrating the dynamic management of target path information provided in an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of the cache file hierarchy promotion operation process provided in the embodiments of this application.

[0014] Figure 4 This is a schematic diagram of the three-level file caching system architecture and file hierarchy flow provided in the embodiments of this application.

[0015] Figure 5 This is a schematic diagram illustrating the cache file eviction and hierarchy degradation operation process provided in an embodiment of this application.

[0016] Figure 6 This is a schematic diagram illustrating the overall process of file access provided in the embodiments of this application.

[0017] Figure 7 This is a schematic diagram of the overall architecture for file access provided in the embodiments of this application.

[0018] Figure 8 This is a schematic diagram of a file access process based on target path information filtering provided in an embodiment of this application.

[0019] Figure 9 This is a timing diagram of the file access process provided in the embodiments of this application.

[0020] Figure 10 A schematic diagram showing the comparison of the time taken to detect the existence of files with or without matching target path information, provided in an embodiment of this application.

[0021] Figure 11 This is a schematic diagram of the structure of a file access device provided in an embodiment of this application.

[0022] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] 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, and 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.

[0024] This application provides a file access method, a file access device, a computer-readable storage medium, an electronic device, and a computer program product. Specifically, the file access method of this application can be executed by an electronic device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, smart TV, wearable smart device, smart vehicle terminal, etc. The terminal can also include a client, which can be a browser client, instant messaging client, or mini-program, etc. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0025] It should be noted that, in this embodiment, the executing entity of the file access method can be a terminal device or a server. The terminal device can be a local terminal device or a client device in a cloud platform. This embodiment does not limit the type of executing entity.

[0026] For example, when the file access method operates on a terminal device, the terminal device may include a display screen and a processor. The display screen is used to present a graphical user interface (GUI) and receive instructions generated by the user interacting with the GUI. The processor is used to store applications, generate the GUI, respond to instructions, and control the display of the GUI on the display screen. When the user operates the GUI through the display screen, the GUI can control the local content of the terminal device in response to the received operation instructions. The terminal device can provide the GUI to the user in various ways, such as rendering it on the terminal device's display screen or presenting the GUI through holographic projection.

[0027] For example, when the file access method runs on a server, it can be implemented and executed based on a cloud system. The cloud system includes servers and client devices. The application's runtime and the graphical user interface (GUI) presentation are separate. The storage and execution of the file access method are completed on the server, while the GUI presentation is completed on the client. The client is mainly used for data reception, transmission, and GUI presentation. For example, the client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, PDA, personal digital assistant, or head-mounted display device. However, the terminal device for data processing is the server in the cloud. During this process, the user operates the client to send instructions to the server. The server executes the instructions, encodes and compresses the GUI data, returns it to the client via the network, and finally, the client decodes and outputs the GUI.

[0028] It should be noted that, in this embodiment, the executing entity of the file access method can be a terminal device or a server. The terminal device can be a local terminal device or a client device in the aforementioned cloud system. This embodiment does not limit the type of executing entity.

[0029] The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0030] In applications such as game engines and large-scale clients, virtual file systems are the underlying infrastructure supporting stable application operation. In practice, game engines and large-scale clients typically contain tens of thousands to hundreds of thousands of resource files, stored in various formats. For example, they can be categorized as packaged files and scattered files. Packaged files combine multiple resource files into a single file, using a hash index for microsecond-level fast file retrieval. Scattered files are stored independently on the disk, requiring access through the operating system's file interface; a single file existence check takes milliseconds. There is a performance gap of 100 to 1000 times between scattered file loaders and packaged file loaders. However, the virtual file systems use the same traversal scheduling strategy for different loaders, resulting in numerous high-overhead and inefficient system calls being executed on scattered file loaders, leading to inefficient file access and negatively impacting user experience.

[0031] To alleviate these issues, some solutions utilize the operating system kernel to maintain directory entry caches and file metadata caches to accelerate repeated system calls to the same file path. Examples include the directory entry cache in the Linux Virtual File System (Linux VFS) and the cache in the Windows New Technology File System (Windows NTFS). However, the caching strategy is controlled by the kernel, and applications cannot actively manage it based on business semantics. Furthermore, the operating system (OS) cache is shared by all processes and cannot provide priority guarantees for processes like game processes. In addition, the OS cache is unaware of the architectural differences between scattered file loaders and package file loaders, and cannot make optimization decisions at the virtual file system's loader scheduling layer, impacting file access efficiency.

[0032] Furthermore, some solutions employ a resource catalog mechanism, loading a full list of resources upon application startup. This list is used to locate the bundle path of a resource and perform file access checks. Examples include Unity's Addressables and Asset Bundle systems. Other solutions create a full file path index when mounting a package (PAK), relying on this index to retrieve resources. Examples include Unreal Engine's PAK system. However, this full-index strategy requires scanning all resources at startup, making it difficult to adapt to dynamic business scenarios such as hot updates. It lacks runtime dynamic adjustment capabilities and cannot flexibly adjust file search strategies according to business stages.

[0033] In addition, some solutions maintain an ordered linked list of loaders and traverse all loaders in the linked list to complete file access detection during file access. However, in related technologies, more than 95% of file detection in game scenarios is ultimately hit in the package file loader, and calls to the scattered file loader are almost all ineffective overhead. This solution traverses all loaders indiscriminately, without distinguishing the performance characteristics of loader types. A large number of access requests are executed on the scattered file loader, resulting in low file access efficiency and affecting the user experience to some extent.

[0034] For the above issues, please refer to Figure 1 , Figure 1 This is a flowchart illustrating a file access method provided in an embodiment of this application. It should be noted that the steps shown may be executed in a logical order different from that shown in the flowchart. The method includes: 110: In response to a file access request for a target file under the target path, determine the target file loader; 120: If the target file loader is a loader type, determine whether the target path matches the pre-determined target path information. The loader is used to load files stored as independent files, and the target path information is used to indicate the paths that the loader is allowed to load. 130: If the target path is determined to match the target path information, load the target file through the target file loader to access the target file.

[0035] Specifically, in application scenarios such as game engines and large-scale clients, virtual file systems typically host tens of thousands to hundreds of thousands of resource files. These files are stored in various formats, generally categorized as independently stored scattered files and packaged files. In related technologies, during file access, the virtual file system indiscriminately schedules all loaders, failing to differentiate between the performance of scattered file loaders and package file loaders. However, scattered file loaders rely on operating system interfaces to perform file detection, which takes milliseconds, while package file loaders perform file detection via memory hash indexes, taking microseconds. The performance difference between the two is significant, and since most files are actually stored in package files, the scattered file loader's detection operations are largely ineffective. These numerous milliseconds of invalid system calls slow down file access efficiency, waste system resources, and fail to meet the performance requirements of high-frequency file access. To address the aforementioned issues, this application provides a file access method that implements differentiated scheduling for different types of loaders. By responding to file access requests for target files under a target path, the corresponding target file loader is determined. When the target file loader is a scattered file loader, the scattered file loader first performs a matching judgment between the target path and pre-determined target path information. When the target path matches the target path information, the target file is loaded through the scattered file loader, effectively avoiding invalid and high-overhead system calls and improving the efficiency of file access.

[0036] In some embodiments, a file access request can be understood as an operation instruction initiated by the client to read or check the existence of a specified file, typically carrying the file's storage path information.

[0037] In some embodiments, the target path can be understood as the storage path carried in the file access request for locating the target file.

[0038] In some embodiments, the target file can be understood as the file to be read or detected that the file access request points to.

[0039] In some embodiments, the target file loader can be understood as a functional module in a virtual file system responsible for reading and locating files, and different loaders are adapted to different file storage formats.

[0040] In some embodiments, a scattered file loader can be understood as a loader used to load files stored as independent files. The scattered file loader needs to call the underlying interface of the operating system to complete the location and reading of the files, and the operation time is in the millisecond range.

[0041] In some embodiments, the loader type can be understood as a category of file loaders based on the file storage format they are adapted to, such as scattered file loaders, package file loaders, network file loaders, etc.

[0042] In some embodiments, a package file can be understood as a whole file formed by merging and packaging multiple independent files. Sub-files are managed internally through a hash index, and there is no need to call the operating system interface during loading, resulting in higher search efficiency.

[0043] In some embodiments, the target path information can be understood as a pre-defined set of paths used to define the range of paths from which the scattered file loader can perform operations to legally load files, thus serving as a path filter.

[0044] In some embodiments, the content of the target path information can be customized according to the actual business scenario.

[0045] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: When a client initiates a file access request for a target file under the target path, the electronic device selects the target file loader that matches the current file access requirement from the set of loaders in the virtual file system according to the preset loader scheduling rules.

[0046] After determining the target file loader, first identify the loader type of the target file loader and determine whether the target file loader is a scattered file loader, so as to distinguish the processing logic of different loaders.

[0047] If the target file loader is a scattered file loader, then based on the pre-determined target path information, the target path is compared and matched with the path entries in the target path information to further verify whether the target path matches the pre-set target path information.

[0048] If the comparison result is a match, it indicates that the current target path belongs to a legal path that the scatter file loader allows to load. The scatter file loader is then called to complete the location and reading operation of the target file through the underlying interface of the operating system.

[0049] If the comparison result is a mismatch, the current shuffle loader is skipped directly, and no operating system interface calls are executed.

[0050] Thus, in this embodiment, by responding to file access requests for target files under the target path, the corresponding target file loader is determined. If the loader type of the target file loader is a scattered file loader, the scattered file loader first performs a matching judgment between the target path and the pre-determined target path information. When the target path matches the target path information, the target file is loaded through the scattered file loader. This achieves control over the access scope of the scattered file loader. Compared with the scheme of directly loading files without performing path verification on the scattered file loader, the invalid millisecond-level system calls of the scattered file loader are replaced with microsecond-level path matching operations, effectively filtering out unnecessary path requests. This avoids triggering a large number of unnecessary underlying file access operations to a certain extent, reduces the number of time-consuming system calls, simplifies the data processing flow of file access, and thus reduces the time overhead in the file access process to a certain extent, improving the effectiveness and execution efficiency of file access.

[0051] In some embodiments provided in this application, the loader types include a scattered file loader and a package file loader, wherein the package file loader is used to load files in a package file; The method also includes: If the loader type of the target file loader is a package file loader, the target file is loaded through the target file loader to access the target file.

[0052] Specifically, in large-scale client scenarios such as games, resource files are typically divided into independently stored scattered files and merged packaged files. Scattered file loaders call the operating system interface to access scattered files, with a single detection taking milliseconds. Packaged file loaders access packaged files through memory hash indexes, with a single detection taking microseconds. However, related technical solutions often indiscriminately traverse both types of loaders without distinguishing performance differences, resulting in excessive invalid calls from scattered file loaders, low file access efficiency, and an inability to meet the access needs of high-frequency resources. Based on the above problems, some embodiments provided in this application explicitly distinguish between scattered file loaders and packaged file loaders. Packaged file loaders are directly loaded without additional filtering, while scattered file loaders undergo path matching filtering. This approach, to some extent, balances the performance advantages of both types of loaders and improves file access efficiency.

[0053] In some embodiments, the package file loader can be understood as a functional module for loading packaged files. It can detect and load files through memory hash indexes without calling the operating system interface, and the time taken for a single operation is in the microsecond range.

[0054] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: When a client initiates an access request for a target file under the target path, the electronic device first determines the corresponding target file loader according to the preset scheduling rules. The target file loader, as the module that performs file access, adapts to different file storage formats.

[0055] Subsequently, the electronic device identifies the type of the target file loader. If the identification result is a scattered file loader, it verifies whether the target path conforms to the allowed access path range based on the pre-set target path information. If the path match is successful, it calls the operating system interface to perform the file loading operation.

[0056] If the identification result is a package file loader, the built-in interface of the package file loader is directly called to quickly locate the target file and complete the loading through the memory hash index. The hash index lookup takes only microseconds and does not rely on the call of the underlying interface of the operating system.

[0057] Thus, in this embodiment, file loaders are divided into two categories: scattered file loaders and package file loaders, and processed differently. Path matching verification is performed on scattered file loaders before loading, while loading is performed directly on package file loaders. This achieves differentiated scheduling based on loader type. Compared to a scheme that performs the same verification and calling process on both types of loaders indiscriminately, this approach adapts to the performance characteristics of different loaders, reduces unnecessary verification steps during package file loading to a certain extent, fully leverages the fast lookup advantage of package file loaders, simplifies the data processing flow, and thereby improves the efficiency and adaptability of file access to a certain degree.

[0058] In some embodiments provided in this application, the target path information includes at least one directory path, which is used to indicate the directory range of files that the scatter loader is allowed to load; Step 120 above includes: Determine if at least one directory path exists as a prefix or substring of the target path; If it exists, determine if the target path matches the target path information; If it does not exist, it is determined that the target path does not match the target path information.

[0059] Specifically, the logic of related path matching methods is complex and time-consuming. Furthermore, the path matching rules are vague, failing to accurately define the effective path range of the file loader, resulting in poor filtering and difficulty in effectively reducing invalid system calls. Based on these problems, some embodiments provided in this application explicitly define the target path information as consisting of directory paths, simplifying the path matching rules to a check of the inclusion relationship between the target path and the directory path. By determining whether there is a prefix or substring matching relationship between the target path and the directory path, valid request paths that the file loader can handle are filtered out. File loading operations are only performed on matching paths, filtering out call requests from invalid paths, effectively improving the filtering efficiency and effectiveness of file access.

[0060] In some embodiments, a directory path can be understood as a path identifier that identifies a specific directory level location in a storage device, and is a basic component of target path information.

[0061] In some embodiments, a prefix can be understood as a character segment whose starting part of a path string is completely identical to another path string, and can be used to determine the directory hierarchy to which the path belongs.

[0062] In some embodiments, a substring can be understood as a portion of a path string that completely contains the path string of another directory, used to determine whether the target path belongs to the specified directory.

[0063] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: The target path information, which serves as a pre-configured filtering benchmark, consists of one or more directory paths and can be customized according to business scenarios.

[0064] When the client initiates an access request for the target file under the target path, and it is determined that the target file loader is a scattered file loader, the target path in the access request is extracted, and the pre-determined target path information is retrieved. Each directory path in the target path information is traversed in sequence, and the matching relationship between the target path and each directory path is checked one by one. It is checked whether there is a directory path that is a prefix of the target path, or whether the target path includes the directory path as a substring.

[0065] If any of the above matching conditions exist, it is determined that the target path matches the target path information, and the target file is loaded by the scatter file loader to complete the access operation.

[0066] In some embodiments, an early termination mechanism may be used during the traversal process described above. When the target path is found to contain any directory path, the traversal is stopped and it is determined that the target path matches the target path information.

[0067] If, after traversing all directory paths, there is no prefix or substring matching relationship between the target path and the directory path, it is determined that the target path and the target path information do not match, and the file loader is skipped directly without performing any file loading related operations through the file loader.

[0068] To more clearly illustrate the configuration composition of the target path information provided in the embodiments of this application, please refer to the following exemplary description: In some embodiments, the target path information consists of one or more directory paths. The judgment logic is to detect whether the target path uses the directory path as a prefix or substring, thereby defining the legal search range of the scattered file loader. Only when a match is successful will the scattered file loader be called to perform file existence detection and reading operations.

[0069] In some embodiments, the target path information can be configured as a pre-registered complete list of file paths, and a full path exact comparison rule is used during matching: The complete path of the target to be detected is compared character by character with each file path in the list. If the paths are completely consistent, a match is determined, and the scattered file loader is allowed to perform subsequent operations. If the paths are inconsistent, the current scattered file loader is skipped.

[0070] The embodiments of this application are applicable to fine-grained management scenarios where only a few fixed scattered files need to be allowed and the entire directory does not need to be opened. The underlying layer can use a hash set to store the path list to ensure the efficiency of matching queries.

[0071] In some embodiments, target path information can be batch matched using path pattern rules with wildcards, supporting general wildcard syntax: The question mark (?) matches a sequence of characters of any length, while the question mark (?) matches a single character.

[0072] For example, configure rules res / The .txt option matches all files in the res directory that have the .txt extension, and patch / ??.mesh matches resource files in the patch directory whose names are two characters long and whose extensions are .mesh.

[0073] During the judgment, the target path is matched with multiple wildcard rules one by one. A match is determined when any rule is matched. The embodiments of this application can flexibly adapt to the batch resource management needs that are classified by file name, suffix, and path level.

[0074] Furthermore, in some embodiments, the target path information can be matched using path regular expression rules. Constraints such as path format, character range, and hierarchical structure are defined by writing regular expressions; for example, regular expressions can be used to limit the matching to only resource paths with numeric names under the hot-update directory.

[0075] The matching process is as follows: substitute the complete target path into the regular expression to complete the validation; if the validation passes, the scattered file loader is enabled.

[0076] The embodiments of this application are adapted to business scenarios with complex path naming rules and complex format filtering, and have stronger path filtering capabilities compared with basic wildcards.

[0077] In addition, in some embodiments, the target path information consists of a pre-configured set of allowed file extensions, enabling finer control at the file type level. The matching logic is as follows: First, extract the file extension from the end of the target path, which is the sequence of characters after the last path separator and the last period.

[0078] The extracted extensions are then compared with entries in the set of allowed extensions in a case-insensitive, precise manner.

[0079] If a matching extension is found, the target path is determined to match the target path information, allowing the scatter loader to perform subsequent operations.

[0080] If no matching extension is found, the current scatter loader is skipped.

[0081] This application's embodiments are applicable to business scenarios that only require opening specific types of scattered files. For example, during game startup, only JSON or XML format configuration files need to be loaded, and during runtime, only LOG format log files need to be loaded. The underlying layer can use a hash set to store the set of allowed file extensions, with a single match taking only a few microseconds, comparable to the efficiency of directory prefix matching. This allows control over the range of file types loaded from scattered files, avoiding the potential risk of invalid calls caused by opening the entire directory.

[0082] For example, during normal game operation, the allowed extension set can be configured to include only json and xml, which can filter out most invalid system calls for non-configuration file types, while ensuring that the dynamic hot update capability of the configuration file is not affected.

[0083] Furthermore, the embodiments of this application can be used in conjunction with the directory path set embodiments to form a dual filtering mechanism of directory and extension. For example, the allowed directory can be configured as patch / res, while allowing extensions of json and xml. The patch loader is only allowed to perform operations when the target path simultaneously belongs to the directory and the extension meets the requirements, further improving filtering accuracy and application security.

[0084] In addition, target path information can be stored using different underlying data structures based on differences in matching logic: Prefix / substring matching, wildcards, and regular expression rules can be stored using ordered arrays or tree structures.

[0085] For precise file path matching, hash set storage is preferred.

[0086] Meanwhile, all types of target path information support static initialization configuration and runtime dynamic addition, deletion, start and stop control to maintain compatibility with the dynamic scheduling capabilities of file access.

[0087] Thus, in this embodiment, a target path information containing at least one directory path is pre-configured for the scattered file loader. When the target file loader is a scattered file loader, the inclusion relationship between the target path and the directory path in the target path information is checked. If there is a prefix or substring matching relationship between the target path and the directory path, it is determined that the target path matches the target path information. If there is no prefix or substring matching relationship between the target path and the directory path, it is determined that the target path does not match the target path information. This limits the file detection range of the scattered file loader. Compared with the scheme of directly calling the scattered file loader to perform system-level file detection for all access paths, it can quickly filter out access requests that are not within the preset directory range. The originally time-consuming operating system file interface call operation is replaced with the extremely time-efficient path string inclusion comparison operation, which effectively reduces the number of invalid system calls of the scattered file loader, reduces the input and output overhead in the file access process to a certain extent, and improves the running efficiency of file existence detection and access in the scattered file loading scenario.

[0088] In some embodiments provided in this application, the method further includes: In response to the first configuration instruction for the target path information, add new directory paths to the target path information and / or remove existing directory paths from the target path information.

[0089] Specifically, in related file access schemes, the target path information is mostly statically configured, with the directory path fixed during application initialization and unmodifiable after runtime. However, when business scenarios change, the static target path information cannot adapt to the new business scenarios, resulting in invalid matches or the filtering of valid scattered files, thus reducing the accuracy of file access filtering. Based on the above problems, in some embodiments provided in this application, a first configuration instruction is introduced to dynamically add new directory paths and / or remove existing directory paths to the target path information during application runtime, updating the filtering benchmark in real time. This adapts to dynamic changes in business scenarios without requiring application restarts, ensuring to a certain extent that the filtering rules always align with the actual business scenario.

[0090] In some embodiments, the first configuration instruction can be understood as an operation instruction issued by the application at runtime to modify the target path information, including operation instructions for adding or removing directory paths and corresponding path parameters.

[0091] To more clearly illustrate the file access method provided in the embodiments of this application, please also refer to... Figure 2 and the following exemplary description, Figure 2 This is a schematic diagram illustrating the dynamic management of target path information provided in the embodiments of this application, namely: During the application initialization phase, the basic static configuration of the target path information, i.e. the directory whitelist, is completed in advance. The default directory path, i.e. the scattered file search directory path, is written through the file system configuration to build the initial filtering benchmark for file access requests.

[0092] During application operation, the electronic device continuously listens for the first configuration command for the target path information.

[0093] When the electronic device receives the first configuration instruction for adding a type, it extracts the directory path to be added, automatically performs path standardization processing, and adds the standardized directory path to the target path information set to complete the directory path addition operation.

[0094] When a first configuration instruction of the removal type is received, the electronic device extracts the specified directory path to be deleted, then matches the target path information, i.e. the directory path already in the directory whitelist, and deletes the entry that matches the specified directory path.

[0095] Furthermore, once the above target path information configuration is modified, the updated target path information takes effect immediately without requiring an application restart. All subsequent file access requests will be based on the latest set of directory paths for path matching.

[0096] Thus, in this embodiment, by responding to the first configuration instruction for the target path information, new directory paths are dynamically added to the target path information or existing directory paths are removed. This enables flexible adjustment of the path set matched by the scattered file loader. Compared to a solution where path information is fixed and cannot be changed, dynamically configuring the target path information allows for real-time adaptation to dynamic business scenarios such as hot updates and version iterations. Furthermore, adding valid directories and / or removing invalid directories improves the accuracy of file access request filtering to a certain extent, avoiding the problems of false filtering of valid scattered files and false matching of invalid paths. At the same time, dynamic modification can update the access scope of the scattered file loader without restarting the system, which improves the adaptability and flexibility of file access rules to a certain extent, ensures the stability of file access performance, and meets the needs of efficient file access in dynamic scenarios with large-scale clients.

[0097] In some embodiments provided in this application, step 120 above includes: If the target file loader's loader type is a scattered file loader, and the target path information is enabled and not empty, determine whether the target path matches the target path information.

[0098] Specifically, in related technologies, the filtering function continuously performs path matching judgments without setting pre-triggered conditions. Even when the target path information is disabled, invalid path matching is still performed. Furthermore, when the target path information is empty, there is no effective filtering benchmark, making the matching operation meaningless. Based on these problems, some embodiments provided in this application add dual pre-conditions to the path matching judgment. Matching judgment between the target path and the target path information is only performed when the target path information is enabled and not empty, effectively reducing resource waste caused by invalid matching.

[0099] In some embodiments, the enabled state can be understood as the working state of the target path information; when enabled, the filtering function is active, and when disabled, the filtering function is turned off.

[0100] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: When the client initiates a file access request and determines that the target file loader is a scattered file loader, it first verifies the enabled status of the target path information to determine whether the filtering function is enabled. At the same time, it verifies whether the target path information is not empty, that is, whether the target path information set contains a valid directory path.

[0101] When the target path information is enabled and not empty, the electronic device initiates a path matching process, comparing the target path with the directory paths in the target path information to see if there is an inclusion relationship, and decides whether to perform the scattered file loading operation based on the comparison results.

[0102] If any of the above conditions are not met, the path matching process is skipped directly, and the file loader is allowed to perform file detection by default without any additional logic processing.

[0103] Thus, in this embodiment, when the target file loader is a scattered file loader and the target path information is enabled and not an empty scattered file loader, the matching judgment between the target path and the preset path information is then performed. This achieves accurate triggering of the matching judgment condition. Compared with the scheme that does not distinguish between the enabled status of the target path information and whether the content is empty and directly performs the matching judgment, it effectively avoids invalid matching and verification operations, reduces unnecessary data processing steps to a certain extent, reduces the computational overhead in the file access process, and improves the processing efficiency and operational stability of file access.

[0104] In some embodiments provided in this application, the method further includes: In response to a second configuration instruction for the target path information, the target path information is configured to be enabled or disabled.

[0105] Specifically, in the file filtering mechanisms of related technologies, the enabled or disabled state of target path information is fixed, making it impossible to switch flexibly during application operation. Furthermore, switching the filtering state requires restarting the application or modifying configuration files. However, restarting interrupts business operations, making it difficult to meet the needs of dynamic scenarios such as debugging, hot updates, and emergency repairs. Based on the above problems, some embodiments provided in this application introduce a second configuration instruction to dynamically receive state switching instructions during application runtime, configuring the target path information to an enabled or disabled state in real time. The switching operation does not require restarting the application and takes effect immediately, flexibly adapting to different business scenarios such as formal operation, debugging, and emergency repairs, thus improving the dynamic control capability of the solution.

[0106] In some embodiments, the second configuration instruction can be understood as an operation instruction issued at runtime for switching the enabled or disabled state of target path information, including state switching parameters.

[0107] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: During application initialization, the target path information is enabled by default, and the filtering function works normally, meeting the high-efficiency filtering requirements of the production scenario.

[0108] During application operation, the electronic device continuously listens for a second configuration command targeting the target path information.

[0109] When a second configuration command of the disabled type is received, the target path information is switched to a disabled state. The state switch is completed instantly without interrupting any business processes. In addition, after the state switch, the path matching judgment logic is automatically turned off, the scattered file loader no longer performs filtering operations, and directly performs file detection, adapting to business scenarios that require full traversal of the scattered file loader, such as debugging and emergency repair.

[0110] When the second configuration command of the enabled type is received, the target path information is switched back to the enabled state, the filtering function is restored to normal, and all subsequent file access requests will re-execute path matching filtering, returning to the efficient filtering logic of the formal operation mode.

[0111] Understandably, the above state switching process does not require restarting the application, has no business interruption, and does not require reloading resources. The switching time is only in the microsecond range, which will not affect the file access performance. At the same time, the state switching is seamlessly connected with the pre-verification logic. After the state change, it immediately takes effect on all subsequent file access processes, without delay or state inconsistency issues. It can flexibly adapt to various dynamic business scenarios such as formal operation, development debugging, hot update, and emergency repair, and to a certain extent, it balances the efficiency of filtering with the flexibility of scenario adaptation.

[0112] Thus, in this embodiment, by responding to the second configuration instruction corresponding to the target path information, the target path information is configured to be enabled or disabled, thereby achieving flexible start and stop control of the scattered file path filtering function. Compared with the solution where the path filtering function is fixed to be enabled or disabled and cannot be switched as needed, it can adapt to the operational needs of different business stages. In scenarios where filtering is not required, the filtering function can be disabled to avoid unnecessary matching operations, and in scenarios where filtering is required, the filtering function can be enabled to reduce invalid system calls. To a certain extent, it balances the efficiency and adaptability of file access. At the same time, the filtering strategy can be quickly switched without modifying the underlying logic, which reduces the operational cost of strategy adjustment to a certain extent and improves the dynamic control capability of the solution.

[0113] In some embodiments provided in this application, step 110 above includes: In response to a file access request, determine whether the target file has been deleted; If it is determined that the target file has not been deleted, the target file loader is determined.

[0114] Specifically, in the file access process, there is no prior check to determine whether the target file has been deleted. All file access requests directly proceed to subsequent processes such as loader determination, path matching, and file loading. However, a large number of invalid requests for deleted files still consume system computing power to perform operations such as loader traversal, path comparison, and system calls, wasting system resources, increasing the average file access time, slowing down access efficiency, and degrading user experience. Based on the above problems, in some embodiments provided in this application, before determining the file loader, it is prioritized to determine whether the target file has been deleted. Only when it is determined that the target file has not been deleted does the determination of the target file loader and subsequent operations continue, filtering invalid requests in advance and effectively reducing subsequent invalid operations.

[0115] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: When a client initiates a file access request for a target file under the target path, the target path in the file access request is first extracted, and the target file is checked to see if it has been deleted.

[0116] If the target file is determined to be a deleted file, the current file access process is terminated directly, and no further operations are performed, effectively avoiding the waste of computing power.

[0117] If the target file is determined to be an undeleted file, the process proceeds to the target file loader determination stage, and the subsequent logic of loader type identification, path matching, and file loading is executed normally.

[0118] Thus, in this embodiment, after responding to a file access request, it is first determined whether the target file has been deleted. Only when it is determined that the target file has not been deleted is the target file loader determined. This achieves pre-filtering of deleted files. Compared with the scheme of directly entering the loader determination process without performing deletion judgment, it can intercept invalid file access requests in advance, avoid performing redundant data processing steps such as subsequent loader matching on deleted files, reduce unnecessary computational overhead to a certain extent, simplify the file access process, and improve the response speed and processing efficiency of file access.

[0119] In some embodiments provided in this application, the step of determining whether the target file has been deleted includes: Determine whether the target path belongs to a pre-determined set of deleted file paths; When the target path is determined to belong to the set of deleted file paths, the target file is determined to have been deleted. If the target path is determined not to belong to the set of deleted file paths, the target file is determined not to have been deleted.

[0120] Specifically, in the file access process, determining whether a target file has been deleted often involves directly querying disk storage, traversing file directories, or reading file metadata. This approach is time-consuming and inefficient, and disk queries are easily affected by disk read / write pressure, resulting in poor stability and an inability to quickly and accurately determine the file's deletion status. To address these issues, some embodiments provided in this application pre-build and maintain a set of deleted file paths in memory. Upon receiving a file access request, the system directly queries this set of deleted file paths to determine whether the target path belongs to it. This allows for a rapid determination of whether the target file has been deleted without requiring disk input / output operations, thus improving efficiency to some extent.

[0121] In some embodiments, the set of deleted file paths can be understood as a set of all target paths corresponding to deleted files that are pre-maintained in memory, typically stored using a hash data structure.

[0122] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: During application operation, electronic devices continuously maintain a set of deleted file paths. This set of deleted file paths is usually stored using a hash data structure, which has the characteristics of fast insertion, deletion and search.

[0123] When a file is deleted, the target path corresponding to that file is automatically extracted, standardized, and stored in the deleted file path set. When a deleted file is recovered, the corresponding path is automatically removed from the deleted file path set, ensuring that the contents of the deleted file path set are synchronized with the actual file deletion status in real time.

[0124] Upon receiving an access request for a target file under the target path, the target path is first extracted from the access request, and a search operation is performed in the set of deleted file paths in memory.

[0125] In some embodiments, the above lookup operation can be performed by hash matching, which takes only microseconds.

[0126] If the target path matches any path in the set of deleted file paths, the target file is determined to have been deleted; otherwise, the target file is determined not to have been deleted.

[0127] The above determination results can be directly used in subsequent processes. If the target file is determined to have been deleted, the current file access will be terminated. If the target file is determined not to have been deleted, the subsequent target file loader determination operation will continue.

[0128] Thus, in this embodiment, the target path is compared with a pre-determined set of deleted file paths to determine whether the target file has been deleted. When the target path is determined to belong to the set of deleted file paths, the target file is determined to be deleted; when the target path is determined not to belong to the set of deleted file paths, the target file is determined not to be deleted. This achieves rapid identification of deleted files. Compared with schemes that directly perform file loading or existence detection operations, there is no need to call the underlying file interface. The file status can be determined simply by matching the path set. This reduces time-consuming system calls to a certain extent, lowers the initial processing overhead of file access, simplifies the file status determination logic, improves the response speed of file access requests, and avoids the occupation of system resources by invalid operations.

[0129] In some embodiments provided in this application, the method further includes: When it is determined that the target file has been deleted, a message indicating that access to the target file failed will be displayed.

[0130] Specifically, in the file access process, after determining that the target file has been deleted and terminating the access request, no clear prompt information is provided to the client. This prevents the client from promptly understanding the reason for the file access failure and from taking targeted measures to address the failure. Based on the above problems, in some embodiments provided in this application, after determining that the target file has been deleted, a corresponding access failure prompt information is generated and fed back to the client or upper-layer application, clearly informing them of the reason for the file deletion failure and terminating the subsequent file access process. This facilitates the upper-layer application in quickly perceiving the anomaly and taking appropriate action.

[0131] In some embodiments, the access failure message can be understood as text or structured information used to inform the client that access to the target file failed and the reason for the failure.

[0132] In addition, in some embodiments, the format of the access failure message can be customized according to the actual application scenario.

[0133] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: Upon receiving a file access request from a client, the system first quickly determines whether the target file has been deleted by querying the set of deleted file paths.

[0134] When the determination result is that the target file has been deleted, a standardized access failure message is generated. This access failure message can clearly indicate that the reason for the access failure is that the target file has been deleted. The format is adapted to the parsing requirements of the upper layer application and there is no redundant content.

[0135] Next, the generated access failure message is fed back to the client or upper-layer application that initiated the request through a preset data channel, and all processes of this file access are terminated, releasing temporarily occupied memory, threads and other system resources to avoid idle waste of system resources.

[0136] Thus, in this embodiment of the application, when it is determined that the target file has been deleted, a prompt message indicating that the target file access failed is directly fed back. This provides clear feedback on the file deletion status. Compared with solutions that do not provide specific feedback and only return vague access results, by feeding back the access failure prompt message, the access requester can quickly know the specific reason why the file cannot be accessed. This avoids, to some extent, the repeated initiation of invalid loading or retry operations, reduces the consumption of system resources, simplifies the troubleshooting process, improves the clarity and user-friendliness of file access interaction, and optimizes the file access experience.

[0137] In some embodiments provided in this application, step 110 above includes: In response to a file access request, determine whether the target file is stored in the target cache space; When it is determined that the target file is not stored in the target cache space, the target file loader is determined.

[0138] Specifically, in related technologies, after receiving a file access request, the process typically proceeds directly to the target file loader determination stage and relies on disk reads to retrieve the file. However, disk input / output operations take milliseconds, and repeatedly reading the same frequently accessed file generates a large number of invalid disk accesses, increasing the average file access time and resulting in low overall access efficiency, thus impacting the user experience. Based on these issues, in some embodiments provided in this application, before determining the file loader, it is first determined whether the target file is stored in the target cache space. When it is determined that the target file is not stored in the target cache space, the target file loader determination operation is performed, which reduces disk input / output operations to a certain extent and improves file access efficiency.

[0139] In some embodiments, the target cache space can be understood as a storage space in memory allocated for temporarily storing file data that has been successfully read, with an access speed greater than that of a disk.

[0140] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: During application operation, the target cache space continuously caches file data that has been successfully read, forming a memory-level file cache pool.

[0141] When a client initiates a file access request for a target file under the target path, the target path in the request is extracted first, and a query operation is performed in the target cache space.

[0142] In some embodiments, a query operation may be performed based on the target path and the path mapping relationship stored in the cache.

[0143] In some embodiments, the query process is a comparison of in-memory data, which takes microseconds and requires no disk operation.

[0144] Finally, if the target file is determined to be stored in the target cache space, no loader needs to be determined; the file data is read directly from the cache. If the target file is determined not to be stored in the target cache space, the process of determining the target file loader is executed, followed by loader type identification, path matching, file loading, and other operations.

[0145] Thus, in this embodiment, when responding to a file access request, it is first determined whether the target file is stored in the target cache space. If the target file is not stored in the cache space, the determination operation of the target file loader is performed. This achieves pre-cache verification for file access. Compared with the scheme that directly enters the loader determination process, the target file is directly obtained when the cache is hit, without the need to perform time-consuming operations such as loader matching, path verification, and underlying file access. This reduces the processing time of file access to a certain extent, avoids the repeated execution of file loading-related processes, and makes full use of the fast access characteristics of the cache. In this way, the file access efficiency is improved to a certain extent, the disk read and write pressure is reduced, and the lifespan of the storage device is extended.

[0146] In some embodiments provided in this application, the method further includes: When it is determined that the target file is stored in the target cache space, the target file is accessed through the target cache space.

[0147] Specifically, in the file access process, after determining that the target file has been stored through a cache lookup, a cumbersome file reading process still needs to be performed. This prevents the efficient and direct retrieval of the cached file, thus failing to fully leverage the high-speed access advantage of the cache and resulting in limited improvement in file access efficiency. Based on the above problems, in some embodiments provided in this application, after determining that the target file has been stored through a cache lookup, the target file data is directly read from the target cache space without performing disk-related operations. This fully leverages the high-speed access advantage of the cache and improves the access efficiency of frequently accessed files.

[0148] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: During application runtime, the target cache space continuously caches the read file data, forming a memory-level file storage pool.

[0149] When a client initiates a file access request, a cache lookup is performed first. If the target file is found to be stored in the target cache space, the storage location of the target file in the cache is quickly located based on the mapping relationship between the target path and the path in the cache, and the complete file data is read directly.

[0150] In some embodiments, the reading process may be a process such as copying data into memory, which takes microseconds.

[0151] Finally, after the file data is read, the file data is returned directly to the client, completing the file access operation.

[0152] Thus, in this embodiment, when it is determined that the target file is stored in the target cache space, the target file is accessed directly through the target cache space, thereby achieving fast file reading in cache hit scenarios. Compared with the scheme that still needs to perform redundant steps such as loader matching, path verification and underlying file access after a cache hit, there is no need to call time-consuming system interfaces or hash lookup operations. The file data is directly obtained from the cache space, which reduces the processing time of file access to a certain extent, reduces the consumption of system resources, makes full use of the high-speed reading characteristics of the cache, and thus improves the response speed and running efficiency of file access to a certain extent.

[0153] In some embodiments provided in this application, the method further includes: After successfully accessing the target file, the target file is written to the target cache space.

[0154] Specifically, the caching mechanisms of related technical solutions can only read files from the cache and do not store newly loaded files in the cache. The cached content cannot be dynamically updated, resulting in a low cache hit rate and an inability to continuously improve file access efficiency, thus affecting client performance and user experience. Based on the above problems, in some embodiments provided in this application, after successful access to the target file, the file data is automatically written to the target cache space, dynamically constructing a file cache pool. Subsequent accesses can directly read from the cache without repeated disk loading, reducing invalid input / output operations and improving cache hit rate and file access efficiency.

[0155] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: When the application runs, the target cache space is initially empty, with no cached data stored.

[0156] When a client initiates a file access request, a cache lookup is performed first. If it is determined that the target cache space does not store the target file, the process of determining the loader, identifying the type, and matching the path is entered, and the target file is loaded from the disk through the target file loader.

[0157] Once the file loading is complete and file access is deemed successful, the file data and corresponding target path of the target file are obtained. The target file data is then written to the target cache space according to the cache storage rules. At the same time, a mapping relationship between the target path and the file data is established to ensure that subsequent queries can be accurately matched.

[0158] Thus, in this embodiment, after successfully accessing the target file, the target file is written to the target cache space, thereby achieving cache retention of file data. Compared with the scheme of not caching after successful file access, this provides cache data support for subsequent access to the same file. Subsequent accesses can directly read the file from the cache without having to perform time-consuming operations such as loader matching, path verification, and underlying file reading again. This reduces the repetitive file loading process and system calls to a certain extent, fully reuses the acquired file data, reduces the overall overhead of file access, and improves the response speed and processing efficiency in high-frequency file access scenarios.

[0159] In some embodiments provided in this application, the step of writing the target file to the target cache space after successful access to the target file includes: After successfully accessing the target file, if the target file is smaller than or equal to the preset file size threshold, the target file will be written to the target cache space.

[0160] Specifically, the caching mechanism of the relevant technical solutions has no file size limit. However, storing large files in the cache will occupy a large amount of cache space, reducing the number of files that can be stored in the cache space, thus leading to a decrease in cache hit rate and low cache space utilization, failing to effectively utilize the caching function of the target cache space. Based on the above problems, in some embodiments provided in this application, a preset file size threshold is set, storing only small files smaller than or equal to the threshold in the target cache space, while large files are loaded directly from the disk, thus avoiding large files occupying too much cache space and improving cache hit rate and space utilization to a certain extent.

[0161] In some embodiments, the preset file size threshold can be understood as a custom, pre-defined upper limit for file size based on device memory size, business scenario requirements, etc., used to filter files that can be written to the cache. For example, the default value is 10MB on a personal computer (PC) and 2MB on a mobile device. Setting it to 0 indicates that there is no limit to the size of cached files.

[0162] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: If the client initiates a file access request and it is determined that the target file is not stored in the target cache space, the target file is read from the disk through the target file loader. After the target file is read, it is determined whether the file access was successful. If the file is successfully read, the cache write process is triggered.

[0163] Next, before writing to the cache, the actual storage capacity of the target file is obtained and compared with the preset file size threshold.

[0164] If the target file size is less than or equal to the preset file size threshold, a cache write operation is performed to map the target file data and the corresponding path information into the target cache space, thus completing the cache replenishment.

[0165] If the target file size is greater than the preset file size threshold, the cache writing process is skipped, the target file is returned directly to the client, and the temporary memory occupied by the file data is released.

[0166] Thus, in this embodiment, when the target file is successfully accessed and is less than or equal to a preset file size threshold, the target file is written to the target cache space. This achieves filtering of cache writes. Compared to the scheme of indiscriminately writing all successfully accessed files to the cache, this effectively avoids the problem of the cache space being crowded by a small number of large files. This allows the cache space to be used to store small-sized hot files first, which improves the cache space utilization and cache hit rate to a certain extent. At the same time, it reduces the storage overhead and data processing time caused by writing large files to the cache to a certain extent. Thus, it balances the cache acceleration effect and the reasonable allocation of cache resources to a certain extent, and optimizes file access performance.

[0167] In some embodiments provided in this application, the target cache space includes multiple sub-cache spaces, each sub-cache space corresponding to a space priority; The steps described above for determining whether the target file is stored in the target cache space include: Based on the space priority from high to low, determine in turn whether each sub-cache space stores the target file.

[0168] Specifically, in related technologies, file caching is often a single, unified space without hierarchical division or priority differentiation. Searching for a target file requires traversing the entire cache space, and the search time increases with the cache capacity. Furthermore, high-frequency (hot) files and low-frequency (cold) files are stored together, with hot files lacking a dedicated high-priority storage area and easily overwritten by low-frequency files, resulting in unstable cache hit rates. A single cache cannot achieve differentiated management of file access frequency, leading to low search efficiency, poor retention of hot files, and an inability to adapt to scenarios involving high-frequency file access from a large number of clients. Based on these problems, in some embodiments provided in this application, the target cache space is divided into multiple sub-cache spaces, each corresponding to a different space priority. The sub-cache spaces are searched sequentially according to priority from high to low, quickly locating the target file and effectively improving cache search efficiency and hot file hit rate.

[0169] In some embodiments, a sub-cache space can be understood as multiple independent cache regions divided from the target cache space, each region having a fixed space priority and storing file data independently.

[0170] In some embodiments, space priority can be understood as the access priority level pre-set for each sub-cached space. The higher the priority, the higher the frequency of access to the stored file and the higher the priority for searching during queries.

[0171] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: The target cache space is pre-divided into multiple independent sub-cache spaces. Each sub-cache space is configured with a unique space priority. The higher the priority value, the higher the access frequency of the stored file. High-priority sub-cache spaces are used to store high-frequency hot files, while low-priority sub-cache spaces store medium-frequency or low-frequency files.

[0172] After the client initiates a file access request, the cache lookup process is triggered. The lookup must follow the order of space priority from high to low. First, the highest priority sub-cache space is searched to determine whether the target file is stored. If it is not found, the next highest priority sub-cache space is searched, and so on, until all sub-cache spaces have been traversed.

[0173] During the retrieval process, each sub-cache space typically uses hash mapping for storage, and the search time is in the microsecond range. Prioritizing the retrieval of high-priority sub-cache spaces can quickly hit hot files without traversing all sub-cache spaces.

[0174] If the target file is not found in any of the sub-cache spaces, it is determined that the cache has missed, and the subsequent loader determination process continues.

[0175] Thus, in this embodiment, by dividing the target cache space into multiple sub-cache spaces with different priorities, and querying the sub-cache spaces sequentially in descending order of priority, hierarchical scheduling of cache queries is achieved. Compared to a scheme that traverses the cache space without priority, the multi-priority sub-cache space design stores high-frequency hot files in high-priority cache spaces and low-frequency files in low-priority cache spaces. During queries, the high-priority sub-cache spaces accessed most frequently are retrieved first, which to some extent improves the cache hit probability of high-frequency files, reduces the number of invalid queries, and shortens the cache retrieval time. This aligns with the distribution characteristics of file access frequency. At the same time, the priority division distinguishes file access frequency, effectively avoiding the mixing of high-frequency and low-frequency files, providing a foundation for subsequent cache optimization, ensuring the cache priority of hot files, reducing the probability of hot files being mistakenly evicted to some extent, improving the stability of the cache hit rate, and adapting to the cache management needs of files with different access frequencies.

[0176] In some embodiments provided in this application, the method further includes: When it is determined that the first sub-cache space among multiple sub-cache spaces contains the target file, if the space priority corresponding to the first sub-cache space is lower than the highest space priority, the target file is moved from the first sub-cache space to the second sub-cache space, where the space priority corresponding to the second sub-cache space is higher than that of the first sub-cache space.

[0177] Specifically, in a multi-level caching architecture, file storage levels are fixed, and there is no file priority promotion mechanism. Even when file access frequency increases, it remains stored in a low-priority cache space, failing to dynamically adapt to changes in file access frequency. To address these issues, some embodiments provided in this application add a hierarchy promotion mechanism to the multi-level cache. When a target file hits the low-priority first sub-cache space, the target file is moved to the higher-priority second sub-cache space. This allows high-frequency files to gradually aggregate towards higher-priority caches, dynamically matching file access frequency and ensuring that hot files are stored in high-priority cache areas, thereby improving cache lookup efficiency and hit rate.

[0178] In some embodiments, the first sub-cache space can be understood as the current sub-cache space that hits the target file.

[0179] In some embodiments, the second sub-cached space can be understood as a sub-cached space with higher priority than the first sub-cached space, used to store files that are accessed more frequently.

[0180] To more clearly illustrate the file access method provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 5 And the following exemplary description, Figure 3 This is a schematic diagram of the cache file hierarchy promotion operation process provided in the embodiments of this application. Figure 4 This is a schematic diagram of the three-level file caching system architecture and file hierarchy flow provided in the embodiments of this application. Figure 5 This is a schematic diagram of the cache file eviction and hierarchy degradation operation process provided in the embodiments of this application, namely: In practical applications, the target cache space, i.e., the three-level file caching system, is pre-divided into multiple sub-cache spaces, i.e., multiple cache levels. Each sub-cache space is assigned a differentiated space priority, i.e., cache priority, according to the access frequency. The priorities are sorted from high to low. High-priority sub-cache spaces are used to store high-frequency hot files, while low-priority sub-cache spaces store medium-frequency or low-frequency files.

[0181] When a client initiates a file access request, the sub-cache spaces are searched in descending order of priority. When the target file is found in the first sub-cache space, the priority level of the first sub-cache space is determined.

[0182] If the first sub-cache space is the highest priority (i.e., the hot layer), no migration operation is required, and the file data can be read directly.

[0183] In some embodiments, if the first sub-cache space has the highest priority, after a cache hit, the Least Recently Used (LRU) list also needs to be updated to move the target file to the head of the list.

[0184] If the priority of the first sub-cache space is lower than that of the highest priority (i.e., it is a warm or cold layer), then the target file data and path mapping relationship are extracted from the first sub-cache space, the target file data is written to the second sub-cache space with higher priority, and the LRU list of the second sub-cache space is updated synchronously after the cache writing is completed, marking the file as the most recently accessed.

[0185] Finally, the original target file data is deleted from the first sub-cached space, the corresponding storage space is released, and the hierarchical promotion operation is completed.

[0186] Thus, in this embodiment, when it is determined that the first sub-cached space among multiple sub-cached spaces stores the target file, if the space priority corresponding to the first sub-cached space is lower than the highest space priority, the target file is moved from the first sub-cached space to the second sub-cached space. This achieves dynamic adjustment of the file priority in the target cache space, ensuring that frequently accessed files are always in the high-priority cache area. Compared to a scheme where the file priority in the cache is fixed, by dynamically adjusting the storage location of cached files, the target file is upgraded to a high-priority cache space after the access frequency of the target file increases. This ensures to a certain extent that frequently accessed hot files are always stored in the cache area with the highest query priority, avoiding the problem of hot files being mistakenly eliminated due to long-term storage in low-priority spaces, improving cache query efficiency, and thus ensuring the stability of hot file caching to a certain extent, improving cache hit rate, and dynamically adapting to real-time changes in file access frequency, realizing intelligent cache management.

[0187] In some embodiments provided in this application, the method further includes: When it is detected that the remaining space in the third sub-cache space among multiple sub-cache spaces is insufficient, the file with the longest time since the last access in the third sub-cache space is moved to the fourth sub-cache space. The space corresponding to the third sub-cache space has a higher priority than the fourth sub-cache space. When it is detected that the remaining space in the fifth sub-cache space among multiple sub-cache spaces is insufficient, the file with the longest time since the last access in the fifth sub-cache space is deleted. The space priority corresponding to the fifth sub-cache space is the lowest space priority.

[0188] Specifically, the multi-priority caching in related technical solutions lacks a reasonable eviction and degradation mechanism. When cache space is insufficient, files are directly deleted, which can easily lead to the accidental deletion of hot files. Furthermore, direct file deletion causes frequent cache rebuilding, increasing disk reads and file access time, resulting in poor cache space stability and low utilization. Based on these problems, some embodiments provided in this application employ a hierarchical eviction strategy. When high-priority sub-cache space is insufficient, the least recently accessed file is downgraded to a low-priority sub-cache space. When the lowest-priority sub-cache space is insufficient, the least recently accessed file is directly deleted. This effectively avoids the accidental deletion of hot files, rationally allocates cache resources, and improves cache hit rate and stability to a certain extent.

[0189] In some embodiments, the third sub-cached space can be understood as a higher-priority sub-cached space used to store frequently accessed files.

[0190] In some embodiments, the fourth sub-cached space can be understood as a sub-cached space with a lower priority than the third sub-cached space, used to store infrequently accessed files.

[0191] In some embodiments, the fifth sub-cache space can be understood as the lowest priority sub-cache space, used to store infrequent or newly arrived files.

[0192] To more clearly illustrate the file access method provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 5 And the following exemplary description, namely: The target cache space, i.e., the three-level file cache system, is pre-divided into multiple sub-cache spaces, i.e., cache levels. The space priorities, i.e., cache priorities, are set from high to low according to the access frequency. The high-priority sub-cache space (hot layer), i.e. the third sub-cache space, stores frequently accessed files; the medium-priority sub-cache space (warm layer), i.e. the fourth sub-cache space, stores medium-frequency accessed files; and the lowest-priority sub-cache space (cold layer), i.e. the fifth sub-cache space, stores newly arrived or infrequently accessed files.

[0193] Electronic devices monitor the remaining capacity of each sub-cache space in real time. When the remaining space of the third sub-cache space, i.e. the hot layer, is insufficient, a cache degradation process is triggered. Based on the LRU strategy, the file with the longest time since the last access in the third sub-cache space is selected and the file data is moved to the fourth sub-cache space, i.e. the warm layer, thus releasing the capacity of the third sub-cache space and effectively avoiding the direct deletion of frequently accessed files.

[0194] In some embodiments, during actual execution, when moving files, it is also necessary to synchronously update the LRU list of the fourth sub-cached space, i.e., the warm layer, place the moved file at the head of the list and mark the file as the most recently accessed file to ensure the orderly management of intermediate frequency files.

[0195] In addition, during the process of moving file data to the fourth sub-cache space, i.e., the warm layer, if the space capacity of the fourth sub-cache space is insufficient, the above-mentioned degradation process is first performed on the fourth sub-cache space, i.e., the warm layer. Based on the LRU policy, the file with the longest time since the last access in the fourth sub-cache space is selected, and the file data is moved to the fifth sub-cache space, i.e., the cold layer, thus releasing the space capacity of the fourth sub-cache space, i.e., the warm layer.

[0196] When the remaining space in the fifth sub-cache space, i.e. the cold layer, is insufficient, the cache eviction process is triggered. Based on the LRU policy, the least accessed files in the fifth sub-cache space, i.e. the cold layer, are selected, and the file data is directly deleted and the storage space is released. Files in the lowest priority space are low-frequency or newly added files, and their deletion has a low impact on the cache hit rate.

[0197] Thus, in this embodiment, when the high-priority sub-cache space is insufficient, the least recently accessed file is downgraded to a lower-priority sub-cache, and when the lowest-priority sub-cache space is insufficient, the least recently accessed file is directly deleted. This achieves hierarchical eviction management of the cache space. Compared to the scheme of directly deleting files when the cache space is insufficient, the high-priority cache prioritizes the retention of frequently accessed files, while low-frequency files are downgraded, temporarily stored, and then evicted. This avoids the problem of accidental deletion of high-frequency hot files to a certain extent, reasonably releases cache space, reduces the time consumption caused by repeated loading of high-frequency files, and at the same time, the lowest-priority cache directly cleans up invalid low-frequency files, effectively reducing cache redundancy. This, in turn, optimizes the efficiency of cache resource allocation to a certain extent, improves the stability and hit rate of the cache, and ensures the advantage of fast access to high-frequency files.

[0198] In some embodiments provided in this application, the step of determining the target file loader in response to a file access request for a target file under the target path includes: In response to a file access request, the first file loader in the file loader chain is identified as the target file loader, wherein the file loader chain is used to indicate multiple file loaders arranged in a preset order; The method also includes: If the target file is not accessed through the target file loader, update the target file loader to the file loader following the target file loader in the file loader chain.

[0199] Specifically, in the file access process, multiple file loaders do not have a fixed traversal order and are mostly random or unordered, resulting in low loading efficiency. Furthermore, the process is easily interrupted if a single loader fails to load, and it cannot automatically switch to the next loader, leading to a low file access success rate and making it unsuitable for scenarios where multiple loaders work together. Based on these problems, some embodiments provided in this application construct an ordered file loader chain, arranging multiple loaders in a preset order. During file access, loading attempts begin from the first loader at the head of the chain, and if the access fails, it automatically switches to the next loader. Through ordered traversal and automatic fallback attempts, loading efficiency and success rate are effectively improved, enhancing the stability of the file access process.

[0200] In some embodiments, the file loader chain can be understood as an ordered linked list consisting of multiple file loaders in a preset order, defining the order in which the file loaders attempt to load files.

[0201] In some embodiments, the preset order can be understood as the loader arrangement order preset according to business characteristics such as loader performance and file hit rate.

[0202] To more clearly illustrate the file access method provided in the embodiments of this application, please also refer to... Figure 6 and the following exemplary description, Figure 6 The overall process diagram for file access provided in the embodiments of this application is as follows: During the application initialization phase, the loader order is pre-defined based on characteristics such as loader performance, file hit rate, and business priority, and a file loader chain, i.e., a multi-level loader chain, is constructed to form an ordered linked list structure.

[0203] After the client initiates a file access request, the first file loader in the file loader chain is directly extracted, and this first file loader is determined as the initial target file loader. Loading operations, such as file search and file reading, are then performed. If the loading is successful, the file data is returned directly, and the file access is completed.

[0204] If the target file is not found, the target file loader is updated to the next loader in the loader chain, and the loading attempt continues.

[0205] If the target file is not accessed by a subsequent loader, the switching logic described above is repeated, traversing the loader chain in turn until the loading is successful or all loaders have finished trying.

[0206] To more clearly illustrate the ordered linked list structure of the multi-level loader chain provided in this application embodiment, please refer to the following exemplary description, which prioritizes higher-performance loaders based on the single search time of different types of loaders: Package file loaders achieve O(1) complexity lookup through memory hash indexes, with a single lookup taking only 1 to 10 microseconds. In contrast, scattered file loaders need to call the operating system file interface to perform disk I / O operations, with a single lookup taking 0.1 to 1 millisecond. The performance difference between the two is 100 to 1000 times, so all package file loaders are ranked before all scattered file loaders.

[0207] The specific sorting order is as follows: Main resource pack loader → Extension resource pack loader → DLC resource pack loader → Working directory file loader → Patch directory file loader → Cache directory file loader.

[0208] The sorting method in this embodiment is applicable to the normal operation phase of the game, at which point most of the resource files are packaged in NPK format, and scattered files account for only a very small number.

[0209] By adopting this order, the vast majority of file access requests will be directly hit in the package file loader, without having to traverse the subsequent high-overhead scattered file loader. This can reduce the average time for file existence detection from 3000 microseconds to about 30 microseconds, resulting in a performance improvement of about 100 times.

[0210] To more clearly illustrate the ordered linked list structure of the multi-level loader chain provided in this application embodiment, please refer to the following exemplary description, which sorts the loaders, including the latest version files, at the front based on file version priority and business importance: In game hot update scenarios, the scattered files in the patch directory are corrections and updates to the original package files. They have a higher version priority and must be loaded first to overwrite the old version resources in the original package.

[0211] The specific sorting order is as follows: Emergency Hot Update Patch Directory Loose File Loader → Regular Hot Update Patch Directory Loose File Loader → Temporary Debug Directory Loose File Loader → Main Resource Pack Loader → Extended Resource Pack Loader → Working Directory Loose File Loader → Cache Directory Loose File Loader.

[0212] The sorting method in this application embodiment is applicable to business scenarios that require frequent release of temporary patches during game hot updates. It can ensure, to a certain extent, that the latest patch files are loaded first, avoiding the problem of loading incorrect version resources.

[0213] Meanwhile, since the patch directory usually only contains a small number of incremental update files, the actual number of calls to the scatter loader is limited, and it will not have a significant impact on overall performance.

[0214] To more clearly illustrate the ordered linked list structure of the multi-level loader chain provided in this application embodiment, please refer to the following exemplary description using a sorting strategy dynamically adjusted at application runtime as an example: This application adopts a runtime dynamically adjusted sorting strategy, which calculates the file hit rate of each loader in real time, that is, the number of times the loader successfully loads a file divided by the total number of attempts. The order of the loader chain is automatically adjusted according to the change in hit rate, and the loader with the higher hit rate is moved forward.

[0215] The specific implementation logic is as follows: The application maintains a hit rate statistics module, which calculates the hit rate of each loader periodically in 10-minute intervals.

[0216] If the hit rate of a certain scatter loader is greater than or equal to 30%, then the scatter loader is moved after all package loader ...

[0217] If the hit rate of a certain package file loader is less than or equal to 50%, then that package file loader will be moved after other package file loaders.

[0218] If the hit rate of a loader is less than or equal to 5% for three consecutive statistical windows, then the loader will be temporarily moved to the end of the loader chain.

[0219] The sorting method described in this application is applicable to applications with diverse business scenarios, such as large games that include multiple independent levels or functional modules. Different levels may rely on different resource packs or scattered file directories, and dynamic sorting can automatically adapt to such business changes.

[0220] For example, in a certain battle level, a large number of special effects resources are located in the special effects expansion pack. The application automatically adjusts the special effects resource pack loader to be after the main resource pack loader, which effectively improves the resource loading speed of that level.

[0221] To more clearly illustrate the ordered linked list structure of the multi-level loader chain provided in the embodiments of this application, please refer to the following exemplary description taking the priority sorting of dedicated loaders based on file type as an example: This application's embodiments address the access characteristics and performance requirements of different file types by setting up dedicated file loaders and prioritizing their placement. For example, configuration files are typically small, scattered files in JSON or XML format, but require fast loading during startup. Audio files have extremely high requirements for loading latency and are usually packaged in a dedicated audio resource package, while large model files are packaged in a separate model resource package.

[0222] The specific sorting order is as follows: Configuration file-specific scattered file loader → Audio resource package loader → UI resource package loader → Model resource package loader → General scattered file loader → General package file loader → Network file loader.

[0223] The sorting method in this application embodiment is applicable to applications with diverse file types and significant differences in access characteristics between different file types. It can specifically optimize the loading speed of key file types. For example, placing the configuration file loader at the front can effectively shorten the configuration loading time when the game starts, and prioritizing the audio resource package loader can ensure low latency and smoothness of audio playback, effectively avoiding problems such as sound stuttering or desynchronization.

[0224] Thus, in this embodiment, by selecting the first file loader in the file loader chain as the target file loader in a preset order, and switching subsequent file loaders in sequence when the target file is not accessed, the orderly scheduling of file loaders is achieved. Compared with the scheme of indiscriminately trying all file loaders at the same time, this effectively avoids the waste of resources caused by multiple loaders loading in parallel. The sequential switching logic is simple, and the next file loader is only tried when the current file loader fails, which effectively reduces unnecessary loading operations, reduces file access overhead to a certain extent, improves file loading efficiency, and adapts to the performance differences of different file loaders.

[0225] In some embodiments provided in this application, the method further includes: When loading the target file by the last file loader in the file loader chain fails, a message indicating that the target file access failed is displayed.

[0226] Specifically, in the file access process, after the file loader chain has traversed all loaders and all have failed to load, there is no clear termination mechanism or result feedback. This can easily lead to the file access process being blocked indefinitely, wasting system resources. Furthermore, the lack of failure feedback makes it impossible for upper-layer applications to handle access anomalies specifically, making it difficult to troubleshoot file loading failures and reducing system maintainability. Based on the above problems, in some embodiments provided in this application, a termination feedback mechanism is set at the end of the file loader chain traversal. When the last file loader fails to load, a message indicating that the target file access has failed is generated and fed back, terminating the file access process. This effectively avoids invalid retries of file access, allowing upper layers to quickly detect and handle anomalies, and saving system resources.

[0227] To more clearly illustrate the file access method provided in the embodiments of this application, please refer to the following exemplary description: When the application is running, the file loader chain arranges multiple file loaders in a preset order. After a file access request is triggered, the process starts from the first file loader at the head of the chain to attempt to load the target file.

[0228] When the first file loader fails to load, it automatically switches to the next subsequent file loader, and traverses all file loaders in the file loader chain in turn, continuously trying to load the file.

[0229] Meanwhile, during the traversal process, the progress of the file loader traversal is recorded in real time, and it is identified whether the current file loader is the last file loader in the file loader chain.

[0230] After the last file loader performs the loading operation, the loading result is determined: if the loading is successful, the file data is returned directly, and the access is completed.

[0231] If loading fails, a standardized target file access failure message will be generated, clearly indicating the reason why all file loaders failed to load.

[0232] Finally, the access failure message is fed back to the client or upper-layer application that initiated the request through a preset data channel, and the entire file access process is terminated, releasing the temporary memory, threads and other system resources occupied by this access, thus avoiding resource idleness and waste.

[0233] Thus, in this embodiment, when all file loaders in the file loader chain fail to load the target file, a failure message is directly displayed, clearly indicating the abnormal file access result. Compared to solutions that do not provide clear feedback after failure, this approach can promptly terminate the invalid loading process, avoiding resource waste caused by continuous loading attempts, reducing unnecessary system overhead, ensuring system stability, and enabling the requester to quickly understand the reason for file loading failure, avoiding invalid retries. This simplifies the file access exception handling process, improves the clarity of file access interaction, and ensures system operating efficiency.

[0234] To more clearly illustrate the file access method provided in the embodiments of this application, please also refer to... Figures 2 to 10 and the following exemplary description, Figure 7 This is a schematic diagram of the overall architecture for file access provided in an embodiment of this application. Figure 8 This is a schematic diagram of a file access process based on target path information filtering provided in an embodiment of this application. Figure 9 This is a timing diagram of the file access process provided in an embodiment of this application. Figure 10 A comparison chart showing the time consumption for file existence detection with and without target path information matching, provided in this application embodiment, is as follows: Before an electronic device executes a file access method, it first completes the full-link initialization configuration. During application initialization, a file loader chain is constructed based on loader performance, file hit rate, and business priority ranking. The first file loader in the file loader chain is determined as the target file loader. At the same time, the target cache space is initialized and divided into the highest priority sub-cache space (hot layer), the medium priority sub-cache space (warm layer), and the lowest priority sub-cache space (cold layer).

[0235] In some embodiments, the target cache space may include multiple sub-cache spaces with different space priorities. Each sub-cache space is configured with an LRU list to manage the access order of files. During a query, the target file is determined in each sub-cache space in descending order of space priority.

[0236] In addition, in some embodiments, the multiple sub-caches of the target cache space have a clear capacity ratio: the highest priority sub-caches (hot layer) on the PC side account for 10%, the medium priority sub-caches (warm layer) account for 20%, and the lowest priority sub-caches (cold layer) account for 70%. On the mobile side, the hot layer accounts for 20%, the warm layer accounts for 20%, and the cold layer accounts for 60%.

[0237] In addition, it is necessary to initialize the target path information, i.e., the directory whitelist, through static configuration, support path standardization processing, i.e., automatically appending a separator to the end of the directory, and configure a global switch to lay the foundation for subsequent dynamic control.

[0238] When an electronic device receives a file access request (i.e., a file existence check request or a file open request), it first queries the set of deleted file paths (i.e., the set of deleted file paths) to determine if the target path belongs to this set, thus identifying whether the target file has been deleted. If the target file is determined to be deleted, an access failure message is immediately displayed, terminating the access process. This pre-filtering mechanism can intercept access requests for deleted files in advance, effectively avoiding subsequent invalid cache lookups and loader traversal operations.

[0239] If the target file is determined not to have been deleted, the electronic device searches the hot, warm, and cold layers in descending order of space priority. If the target file is found in any sub-cache space, a promotion operation is triggered: a cold layer hit is promoted to a warm layer, a warm layer hit is promoted to a hot layer, and a hot layer hit updates the LRU list to the head. The cached file data is then returned directly.

[0240] In some embodiments, the cache hit latency is in the microsecond range, which effectively improves file access efficiency compared to the millisecond latency of disk I / O.

[0241] If none of the three levels of cache are hit, the file loader chain traversal process will begin.

[0242] When traversing the file loader chain, the target file loader is determined one by one in a preset order. If the target file loader is a package file loader or a network file loader, the target file is loaded directly through the loader without any additional filtering operations.

[0243] If the target file loader is a working directory loader, cache directory loader, patch directory loader, or other scattered file loader, then the target path information filtering, i.e., the whitelist filtering mechanism, is enabled. This whitelist filtering mechanism supports switching between global enabled and disabled states, and the filtering judgment is only performed when the target path information is enabled and not empty.

[0244] Next, a whitelist matching process is performed to determine if the target path matches the target path information. This involves checking if at least one directory path contains a directory path that serves as a prefix or substring of the target path. Only when the target path contains a whitelisted directory is a system call invoked to load the target file via an operating system interface.

[0245] If the path is determined to be mismatched, the current scattered file loader is skipped directly, and system calls are not executed, thereby reducing invalid input and output overhead. This filtering mechanism can reduce more than 95% of invalid system calls, effectively improving file access efficiency.

[0246] For example, such as Figure 10 As shown, the performance difference between having and not having target path information matching is verified by comparing the average time of a single file access call, corresponding to four file access scenarios: A. no whitelist, B. whitelist mismatch, C. whitelist match, and D. direct hit on the package file.

[0247] In scenario A (no whitelist), all file loader loaders need to be traversed and multiple system calls need to be executed. Each detection takes about 3000 microseconds and there are a large number of invalid and high-overhead calls. In scenario B (whitelist mismatch), all file loader loader loaders are skipped directly. There is no system call overhead and each detection takes only tens of microseconds, which is close to zero-cost filtering. In scenario C (whitelist matching), only a small number of valid system calls are executed on the matching path. Each detection takes about 1000 microseconds, which is about 2 / 3 less than the time taken in scenario without whitelist. In scenario D (direct hit of package file), the lookup is done using hash index O(1), and each detection takes less than 100 microseconds, which is the optimal access time.

[0248] In addition, after any loader in the file loader chain successfully loads the file, the target file data is read and the file size threshold, i.e., the single file limit, is checked. For example, it is 10MB on PC and 2MB on mobile.

[0249] If the file size does not exceed the preset file size threshold, the file will be written to the lowest priority sub-cache space, i.e., the cold layer.

[0250] In addition, if the cold layer space is insufficient during cache writing, the cache eviction process is triggered, and the least recently accessed file is deleted according to the LRU policy. If the warm layer and hot layer space are insufficient during cache writing, the level degradation process is triggered, and the least recently accessed file is downgraded to a low-priority sub-cache space. The LRU list of each level is updated synchronously to ensure the orderly management of the cache.

[0251] Next, if the current target file loader does not access the target file, the target file loader is updated to the next loader in the file loader chain, and the loader type identification, filtering judgment, and loading operations are repeated. When the last loader in the file loader chain fails to access the target file, an access failure message is displayed, and the current access process is terminated.

[0252] In addition, in some embodiments, the electronic device has asynchronous file access capability. In multi-threaded mode, file access requests can be submitted to high-priority computing threads for execution to avoid blocking the main thread. When multi-threading is disabled, the asynchronous interface can automatically degrade to synchronous execution, which can adapt to different operating environments.

[0253] Furthermore, during application operation, electronic devices can dynamically add / remove target path information entries in response to the first configuration command, and switch the global whitelist switch in response to the second configuration command, to adapt to different business stages such as hot updates and normal gaming. Simultaneously, the target cache space can dynamically adjust the file hierarchy based on the access frequency of the target file, preventing low-frequency files from crowding out hot-frequency files, effectively ensuring cache hit rate, and achieving efficient and flexible operation across the entire file access chain.

[0254] To facilitate better implementation of the file access method of this application embodiment, this application embodiment also provides a file access device. Please refer to... Figure 11 , Figure 11 A schematic diagram of the structure of a file access device provided in an embodiment of this application. The file access device 200 may include: The loader determination module 210 is used to determine the target file loader in response to a file access request for a target file under the target path; The path matching judgment module 220 is used to determine whether the target path matches the pre-determined target path information if the loader type of the target file loader is a scattered file loader; wherein, the scattered file loader is used to load files stored in the form of independent files, and the target path information is used to indicate the paths of files that the scattered file loader is allowed to load; The file loading and access module 230 is used to load the target file through the target file loader to access the target file if the target path is determined to match the target path information.

[0255] In some embodiments, the loader type includes a scattered file loader and a package file loader, wherein the package file loader is used to load files in a package file; the file loading access module 230 can also be used to load the target file through the target file loader to access the target file if the loader type of the target file loader is a package file loader.

[0256] In some embodiments, the target path information includes at least one directory path, which is used to indicate the directory range of files that the scatter file loader is allowed to load; the path matching judgment module 220 can also be used to determine whether there is a directory path in the at least one directory path that serves as a prefix or substring of the target path. If it exists, the target path is determined to match the target path information; if it does not exist, the target path is determined not to match the target path information.

[0257] In some embodiments, the path matching determination module 220 can also be used to add new directory paths to the target path information and / or remove existing directory paths in the target path information in response to a first configuration instruction for the target path information.

[0258] In some embodiments, the path matching judgment module 220 can also be used to determine whether the target path matches the target path information if the loader type of the target file loader is a scattered file loader, the target path information is enabled and not empty.

[0259] In some embodiments, the path matching determination module 220 can also be used to configure the target path information as enabled or disabled in response to a second configuration instruction for the target path information.

[0260] In some embodiments, the loader determination module 210 can also be used to determine whether the target file has been deleted in response to a file access request, and to determine the target file loader when it is determined that the target file has not been deleted.

[0261] In some embodiments, the loader determination module 210 can also be used to determine whether the target path belongs to a pre-determined set of deleted file paths. When the target path belongs to the set of deleted file paths, the target file is determined to be deleted. When the target path does not belong to the set of deleted file paths, the target file is determined not to be deleted.

[0262] In some embodiments, the loader determination module 210 can also be used to provide a prompt message indicating that the target file access failed when it is determined that the target file has been deleted.

[0263] In some embodiments, the loader determination module 210 can also be used to determine whether a target file is stored in the target cache space in response to a file access request, and to determine the target file loader when it is determined that no target file is stored in the target cache space.

[0264] In some embodiments, the loader determination module 210 can also be used to access the target file through the target cache space when it is determined that the target cache space stores the target file.

[0265] In some embodiments, the file loading access module 230 can also be used to write the target file to the target cache space after successful access to the target file.

[0266] In some embodiments, the file loading access module 230 can also be used to write the target file to the target cache space if the target file is less than or equal to a preset file size threshold after successful access to the target file.

[0267] In some embodiments, the target cache space includes multiple sub-cache spaces, each sub-cache space corresponding to a space priority; the loader determination module 210 can also be used to determine whether each sub-cache space stores the target file in descending order of space priority.

[0268] In some embodiments, the loader determination module 210 can also be used to move the target file from the first sub-cached space to the second sub-cached space when it is determined that the first sub-cached space among multiple sub-cached spaces stores the target file, if the space priority corresponding to the first sub-cached space is lower than the highest space priority, wherein the space priority corresponding to the second sub-cached space is greater than that of the first sub-cached space.

[0269] In some embodiments, the loader determining module 210 can also be used to move the file with the longest time since the last access in the third sub-cached space to the fourth sub-cached space when it is detected that the remaining space in the third sub-cached space among the multiple sub-cached spaces is insufficient, and to delete the file with the longest time since the last access in the fifth sub-cached space when it is detected that the remaining space in the fifth sub-cached space among the multiple sub-cached spaces is insufficient, wherein the space priority corresponding to the third sub-cached space is higher than that of the fourth sub-cached space, and the space priority corresponding to the fifth sub-cached space is the lowest space priority.

[0270] In some embodiments, the loader determination module 210 can also be used to determine the first file loader in the file loader chain as the target file loader in response to a file access request. If the target file is not accessed through the target file loader, the target file loader is updated to the file loader after the target file loader in the file loader chain. The file loader chain is used to indicate multiple file loaders arranged in a preset order.

[0271] In some embodiments, the loader determination module 210 can also be used to provide a prompt message indicating that the target file access failed when loading the target file through the last file loader in the file loader chain fails.

[0272] Each unit in the aforementioned file access device can be implemented entirely or partially through software, hardware, or a combination thereof. Each unit can be embedded in or independent of the processor in the electronic device in hardware form, or stored in the memory of the electronic device in software form, so that the processor can invoke and execute the operations corresponding to each unit.

[0273] The file access device 200 can be integrated into a terminal or server that has memory and a processor and thus computing power, or the file access device 200 can be the terminal or server.

[0274] Optionally, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0275] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may be a terminal or a server. Figure 12 As shown, the electronic device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figures does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0276] The processor 301 is the control center of the electronic device 300. It connects various parts of the electronic device 300 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 302, and calling data stored in the memory 302, it executes various functions of the electronic device 300 and processes data, thereby performing overall processing of the electronic device 300.

[0277] In this embodiment, the processor 301 in the electronic device 300 loads the instructions corresponding to the processes of one or more computer programs into the memory 302 according to the following steps, and the processor 301 runs the computer programs stored in the memory 302 to realize various functions: In response to a file access request for a target file under the target path, determine the target file loader; If the target file loader is a loader of type scatter file loader, determine whether the target path matches the pre-determined target path information. Here, the scatter file loader is used to load files stored as independent files, and the target path information is used to indicate the paths that the scatter file loader is allowed to load. If the target path is determined to match the target path information, the target file is loaded by the target file loader to access the target file.

[0278] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0279] Optional, such as Figure 12 As shown, the electronic device 300 also includes: a display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 12 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0280] The display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program. Optionally, the touch panel may include a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, and transmits the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 301, and can receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel according to the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0281] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0282] Audio circuitry 305 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another electronic device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

[0283] The input unit 306 can be used to receive input numbers, characters, or object feature information (such as fingerprints, irises, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0284] Power supply 307 is used to supply power to various components of electronic device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0285] although Figure 12 As not shown in the diagram, the electronic device 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0286] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the file access methods of the embodiments of this application; for brevity, these will not be elaborated further here.

[0287] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the file access method of this application embodiment. For brevity, further details are omitted here.

[0288] This application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the file access method of this application; for brevity, further details are omitted here.

[0289] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0290] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0291] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0292] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0293] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0294] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0296] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0298] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived 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.

Claims

1. A file access method, characterized in that, The method includes: In response to a file access request for a target file under the target path, determine the target file loader; If the loader type of the target file loader is a scattered file loader, determine whether the target path matches the pre-determined target path information; wherein, the scattered file loader is used to load files stored in the form of independent files, and the target path information is used to indicate the paths that the scattered file loader is allowed to load. If the target path is determined to match the target path information, the target file is loaded by the target file loader to access the target file.

2. The file access method according to claim 1, characterized in that, The loader type includes the scattered file loader and the package file loader, wherein the package file loader is used to load files in the package file; The method further includes: If the loader type of the target file loader is a package file loader, the target file is loaded through the target file loader to access the target file.

3. The file access method according to claim 1, characterized in that, The target path information includes at least one directory path, which is used to indicate the directory range of files that the scatter loader is allowed to load. The step of determining whether the target path matches the pre-determined target path information includes: Determine whether there exists a directory path in the at least one directory path that serves as a prefix or substring of the target path; If it exists, determine whether the target path matches the target path information; If it does not exist, it is determined that the target path does not match the target path information.

4. The file access method according to claim 3, characterized in that, The method further includes: In response to a first configuration instruction for the target path information, a new directory path is added to the target path information and / or an existing directory path is removed from the target path information.

5. The file access method according to claim 1, characterized in that, If the loader type of the target file loader is a scattered file loader, determining whether the target path matches the pre-determined target path information includes: If the loader type of the target file loader is a scattered file loader, and the target path information is enabled and not empty, determine whether the target path matches the target path information.

6. The file access method according to claim 5, characterized in that, The method further includes: In response to a second configuration instruction for the target path information, the target path information is configured to be enabled or disabled.

7. The file access method according to claim 1, characterized in that, The step of determining the target file loader in response to a file access request for a target file under the target path includes: In response to the file access request, determine whether the target file has been deleted; If it is determined that the target file has not been deleted, the target file loader is determined.

8. The file access method according to claim 7, characterized in that, The determination of whether the target file has been deleted includes: Determine whether the target path belongs to a pre-determined set of deleted file paths; When it is determined that the target path belongs to the set of deleted file paths, it is determined that the target file has been deleted; If it is determined that the target path does not belong to the set of deleted file paths, it is determined that the target file has not been deleted.

9. The file access method according to claim 7 or 8, characterized in that, The method further includes: When it is determined that the target file has been deleted, a message indicating that access to the target file failed will be displayed.

10. The file access method according to claim 1, characterized in that, The step of determining the target file loader in response to a file access request for a target file under the target path includes: In response to the file access request, determine whether the target file is stored in the target cache space; When it is determined that the target file is not stored in the target cache space, the target file loader is determined.

11. The file access method according to claim 10, characterized in that, The method further includes: When it is determined that the target file is stored in the target cache space, the target file is accessed through the target cache space.

12. The file access method according to claim 10, characterized in that, The method further includes: After successfully accessing the target file, the target file is written to the target cache space.

13. The file access method according to claim 12, characterized in that, The step of writing the target file to the target cache space after successful access to the target file includes: After successfully accessing the target file, if the target file is less than or equal to a preset file size threshold, the target file is written to the target cache space.

14. The file access method according to claim 10, characterized in that, The target cache space includes multiple sub-cache spaces, and each sub-cache space corresponds to a space priority. The step of determining whether the target file is stored in the target cache space includes: According to the space priority from high to low, determine in turn whether each of the sub-cache spaces stores the target file.

15. The file access method according to claim 14, characterized in that, The method further includes: When it is determined that the first sub-cached space among the plurality of sub-cached spaces stores the target file, if the space priority corresponding to the first sub-cached space is lower than the highest space priority, the target file is moved from the first sub-cached space to the second sub-cached space; wherein, the space priority corresponding to the second sub-cached space is higher than that of the first sub-cached space.

16. The file access method according to claim 14, characterized in that, The method further includes: When it is detected that the remaining space in the third sub-cached space among the multiple sub-cached spaces is insufficient, the file with the longest time since the last access in the third sub-cached space is moved to the fourth sub-cached space, wherein the space priority corresponding to the third sub-cached space is higher than that of the fourth sub-cached space; When it is detected that the remaining space of the fifth sub-cached space among the plurality of sub-cached spaces is insufficient, the file with the longest time since the last access in the fifth sub-cached space is deleted, wherein the space priority corresponding to the fifth sub-cached space is the lowest space priority.

17. The file access method according to claim 1, characterized in that, The step of determining the target file loader in response to a file access request for a target file under the target path includes: In response to the file access request, the first file loader in the file loader chain is determined as the target file loader, wherein the file loader chain is used to indicate multiple file loaders arranged in a preset order; The method further includes: If the target file is not accessed through the target file loader, the target file loader is updated to the file loader following the target file loader in the file loader chain.

18. The file access method according to claim 17, characterized in that, The method further includes: When loading the target file by the last file loader in the file loader chain fails, a message indicating that access to the target file has failed is displayed.

19. A file access device, characterized in that, The device includes: The loader determination module is used to determine the target file loader in response to a file access request for a target file under the target path; The path matching judgment module is used to determine whether the target path matches the pre-determined target path information if the loader type of the target file loader is a scattered file loader; wherein, the scattered file loader is used to load files stored in the form of independent files, and the target path information is used to indicate the paths that the scattered file loader is allowed to load. The file loading and access module is used to load the target file through the target file loader to access the target file if it is determined that the target path matches the target path information.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the file access method according to any one of claims 1-18.

21. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program, and the processor executing the file access method according to any one of claims 1-18 by calling the computer program stored in the memory.

22. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the file access method according to any one of claims 1-18.

Images