A method, system, electronic device and medium for dynamic management of resource loading

Abstract

This invention relates to the field of computer programming technology, and in particular to a resource interception and dynamic adaptation method, system, electronic device, and medium. The dynamic resource loading management method includes: when the application starts, obtaining relevant information about the corresponding resource package; setting interceptors on the resource call path; when a resource call request is detected, parsing the request and obtaining the information of the resource to be called; obtaining current environment information and comparing it with preset environment information; if they are inconsistent, generating a path list including resource search paths sorted by priority based on the relevant information, the information of the resource to be called, and the current environment information; traversing the path list from high to low priority; if a resource can be obtained, it is used as the target resource and traversal stops; reading the binary data stream of the target resource, parsing it into an application-adaptive format, and returning it to the requester. This invention can simultaneously meet the application's dual requirements for architectural compatibility and intelligent resource adaptation.

Description

Technical Field

[0001] This invention relates to the field of computer programming technology, and in particular to a resource interception and dynamic adaptation method, system, electronic device, and medium. Background Technology

[0002] As mobile applications become increasingly feature-rich, the volume of their business code and various resources continues to grow, making dynamic sub-packaging and distribution technologies based on app stores the mainstream solution. For the Google Play ecosystem, there are currently two main typical solutions: PlayFeature Delivery (PFD) dynamic feature module distribution and Play Asset Delivery (PAD) resource package distribution.

[0003] The PFD (Programmable Rendering) solution splits the application into a main module and independent functional modules, enabling on-demand distribution of functions and reducing the initial installation size. However, this solution has strict one-way dependency constraints, requiring dynamic modules to depend on the main module and be at the upper level of the dependency hierarchy. This seriously conflicts with the layered and modular architecture of mainstream mobile applications, resulting in strong architectural intrusion and high costs for modification and adaptation.

[0004] The PAD solution separates large resources from the installation package and distributes them separately without involving adjustments to business code. It has good compatibility with the original architecture, but it lacks intelligent adaptation capabilities for resources of multiple languages, themes, screen densities, and other dimensions. Developers need to manually write a lot of adaptation logic, and it cannot achieve transparent replacement of resources without modifying business code, resulting in insufficient flexibility in resource iteration.

[0005] Both existing solutions have obvious limitations and cannot simultaneously meet the dual requirements of application for architectural compatibility and intelligent resource adaptation, thus hindering the development of dynamic, lightweight, and multi-scenario adaptation of mobile applications. Summary of the Invention

[0006] This invention provides a dynamic management method, system, electronic device, and medium for resource loading to solve the problem of not being able to simultaneously meet the dual requirements of application for architectural compatibility and intelligent resource adaptation.

[0007] This invention discloses a dynamic management method for resource loading, applied to an application installed in an electronic device, which is communicatively connected to a network attached storage device and accesses the network attached storage device through the application.

[0008] The dynamic management method for resource loading includes: When the application starts, obtain relevant information about the resource package corresponding to the application; An interceptor is set on the resource call path. When a resource call request is detected from the application, the resource call request is parsed to obtain the information of the resource to be called. Obtain current environment information and determine whether the current environment information is consistent with preset environment information; If not, then based on the relevant information, the resource information to be invoked, and the current environment information, a path list including a set of resource search paths sorted by priority is generated; Traverse the path list in descending order of priority and determine whether the resource search path currently being traversed can obtain the resource. If so, then the resource is taken as the target resource, and the traversal operation is stopped; The binary data stream of the target resource is read, parsed into a format matching the application, and then sent to the requester who sent the resource call request.

[0009] Optionally, the step of setting an interceptor on the resource path includes: Create a custom interface parsing factory that can identify and intercept all resource references in the interface description file and replace all default factories in the application with the custom interface parsing factory. Create a custom resource acquisition class, define a resource acquisition method in the custom resource acquisition class, the resource acquisition method is used to capture resource requests at the code layer, and replace all default classes in the application with the custom resource acquisition class.

[0010] Optionally, the step of parsing the resource request includes: The request source of the resource call request is obtained based on the interceptor type of the resource call request, and the request source includes static source and dynamic source; The processing rules corresponding to the resource call request are obtained based on the request source.

[0011] Optionally, the step of obtaining the resource information to be invoked includes: Identify the resource identifier of the resource call request, and obtain the name and type of the component to be called based on the resource identifier; Based on the name and type, determine whether the resource to be invoked needs to be intercepted; If not, then proceed with the step of obtaining the current environment information, and subsequent steps.

[0012] Optionally, the step of generating a path list including a set of priority-ordered resource lookup paths based on the relevant information, the resource information to be invoked, and the current environment information includes: Generate the optimal path based on the resource information to be invoked and the current environment information; Based on the optimal path, a degradation path is generated according to the degradation rule of first reducing density, then language, and finally topic, and the priority of each degradation path is obtained.

[0013] Optionally, the step of obtaining relevant information about the resource package corresponding to the application includes: Confirm the location of the resource package, establish an access link with the resource package, and preload the directory index of the resource package.

[0014] Optionally, after the step of traversing the path list in descending order of priority, the method includes: If the target resource package cannot be obtained by traversing all the resource search paths, then the built-in resource is invoked and used as the target resource.

[0015] The present invention also discloses an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0016] The present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0017] The present invention also discloses a dynamic management system for resource loading, including a network-attached storage device and an electronic device as described above, wherein the electronic device is equipped with an application program capable of performing the steps of the method described above.

[0018] The beneficial effects of the dynamic resource loading management method provided in this invention are as follows: By obtaining resource package information during the application startup phase and setting interceptors on the resource call path, unified monitoring and dynamic management of the resource call process are achieved. Based on the differences between the current operating environment and the preset environment, a multi-dimensional resource search path sorted by priority is automatically generated, and resources are matched and loaded sequentially according to priority. This achieves intelligent resource adaptation under multiple factors such as language, theme, and density. Through the dynamic resource parsing and formatted return mechanism, while maintaining flexible adaptability, it does not rely on a fixed directory structure or specific platform interface. It can take into account both the application's architectural compatibility and the intelligent requirements of resource loading, effectively improving resource loading efficiency and cross-environment adaptability stability, and meeting the unified resource management and high availability requirements of modern applications in multi-platform and multi-configuration scenarios. Attached Figure Description

[0019] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a flowchart illustrating an embodiment of the dynamic resource loading management method provided by the present invention; Figure 2 This is a schematic diagram illustrating an application scenario of the dynamic resource loading management method provided by the present invention; Figure 3 This is a schematic diagram of the internal structure of an electronic device in one embodiment of the present invention.

[0020] The labels for the attached figures are as follows: 10. Electronic devices; 20. Network-attached storage devices. Detailed Implementation

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0022] Please refer to the following: Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the dynamic resource loading management method provided by the present invention. Figure 2 This is a schematic diagram illustrating an application scenario of the dynamic resource loading management method provided by the present invention. Electronic device 10 establishes a communication connection with network attached storage device 20. An application program is installed on electronic device 10, and accesses network attached storage device 20 through this application program.

[0023] The goal of the dynamic resource loading management method provided by this invention is to incorporate dynamic external resources into a systematic management framework without altering the existing application architecture, while supporting automatic deep adaptation across multiple dimensions such as multi-language, multi-theme, and multi-density. By establishing a resource interception system during the application startup phase, and intelligently loading and matching resources based on environment information judgment and path priority strategies, transparent, dynamic, and multi-dimensional adaptation is achieved. The dynamic resource loading management method provided by this invention is more flexible, secure, and configurable than existing technologies, and requires almost no modification to existing application code.

[0024] The dynamic management method for resource loading provided by this invention specifically includes the following steps: S101: When the application starts, obtain relevant information about the resource package corresponding to the application.

[0025] In a specific implementation scenario, application startup occurs in three ways: upon initial installation, when the application resumes from a background process to the foreground, and after system environment parameters (such as language, theme, and screen display settings) are changed, requiring a restart. When the application starts, the resource interception and management module automatically activates to intercept and manage the application's resource calls. Dynamic management logic is loaded only during the application startup phase, without consuming additional resources during application runtime, ensuring no significant impact on application startup speed.

[0026] The system retrieves information about the resource package corresponding to the application, enabling rapid location of resources when they need to be accessed later. Specifically, it automatically identifies and locates the physical storage location of the resource package based on a pre-obtained storage path. Furthermore, it verifies the integrity of the resource package (by checking its checksum and version number to ensure it hasn't been tampered with or damaged). It requests and obtains read permissions for the resource package, establishing a dedicated access link to ensure efficient and secure reading of all resource files within the external resource package, avoiding resource lookup failures and loading timeouts due to insufficient permissions or a faulty link. This access link uses a long-lived connection mechanism; once established, it remains available until the application process terminates, ensuring rapid response for subsequent resource lookup and loading operations.

[0027] After establishing the resource package access link, the resource package directory index is preloaded immediately. The external resource package stores various resources (images, strings, colors, sizes, etc.) with multi-dimensional adaptation. To avoid traversing the entire resource package for every resource lookup, which consumes significant I / O resources and prolongs search time, the resource package is pre-parsed to extract the core information of all resources and generate a standardized directory index table. This directory index table contains key information such as each resource's unique identifier (resource ID, resource name), resource storage path, resource adaptation dimension (language, theme, screen density, etc.), resource size, and resource version number. A hash table structure is used for storage, supporting fast retrieval based on resource identifier, adaptation dimension, and other conditions. After the directory index table is preloaded, it is cached in the application's memory. Subsequent resource searches can directly locate the target resource's storage path through the index table without traversing the entire resource package, significantly improving resource search efficiency. Meanwhile, the update status of the resource package is synchronized in real time. If the resource package is updated (such as adding adapted resources or replacing existing resources), the directory index table will be automatically updated to ensure that the index information is consistent with the actual content of the resource package and avoid resource search errors.

[0028] The entire initialization process only loads the core management logic, without modifying the original application business code or intruding on the application's layered architecture. It perfectly retains the advantages of good compatibility of the traditional PAD solution architecture, while providing stable and efficient underlying support for subsequent multi-dimensional intelligent resource adaptation, achieving dual optimization of architecture compatibility and resource lookup efficiency.

[0029] S102: Set an interceptor on the resource call path. When a resource call request is detected in the application, parse the resource call request and obtain the information of the resource to be called through the interceptor.

[0030] In a specific implementation scenario, the entire execution path of the application acquiring resources is considered as the resource call path, encompassing both static resource call paths (interface description file parsing path) and dynamic resource call paths (code-level resource acquisition path). A dual-path interceptor deployment covers all static / dynamic resource call requests, preventing missed interceptions. The interceptors utilize a dual mechanism of event listening and method hooking to detect resource call request triggers in real time. Interceptor settings and request parsing do not modify the application's original business logic, maintaining the integrity of the application's layered architecture and resolving the issue of requiring manual modification of resource call logic in traditional PAD solutions.

[0031] In this embodiment, corresponding interceptors are set for static resource call paths and dynamic resource call paths, respectively. The static resource call path refers to the path in which resources are loaded when the application parses interface description files such as XML / Storyboard. Interception of static resource call paths can be achieved by replacing the core factory class for interface parsing. Specifically, a custom interface parsing factory is created based on the core interface of the native interface parsing factory, and the core method for creating interface elements is overridden, embedding resource interception logic within this method.

[0032] Interface description files (IDEs) typically exist as layout files, interface templates, or markup files, defining interface elements, display content, and their required resources. When the system's interface builder reads and parses this IDE description file, a custom interface parsing factory can intervene in the process, capturing and analyzing resource references such as images, text, colors, and styles based on resource interception logic. Through this static interception operation, the identification information of a resource can be obtained before the interface actually loads the resource, to determine whether there is a substitute resource or external resource package. If a corresponding substitute resource exists, the resource is replaced through a dynamic loading mechanism; if no substitute resource is detected, the system's default loading logic continues to be called to ensure normal interface rendering.

[0033] Replacing all default factories in the application with a custom UI parsing factory allows you to obtain a global instance during the application startup initialization phase and replace all default factories with custom factories. If a third-party factory already exists in the application, the custom UI parsing factory and the third-party factory can be integrated through the proxy pattern to ensure that the interception logic is executed first.

[0034] The custom interface parsing factory created by the above method is used as a static resource interceptor. It is fully compatible with the system interface parsing logic, and the replacement does not affect the original interface rendering effect. It is invisible to the application development layer and does not require modification of the original layout file or interface development logic.

[0035] Dynamic resource invocation paths refer to the chain of calls made by the application code layer to resource acquisition methods. The core is to achieve interception by replacing the system's default resource management class. Specifically, a custom resource acquisition class is created, ensuring that the resource acquisition methods of the custom class have completely identical method signatures to those of the system's default class, guaranteeing that the code layer is unaware of the invocation, and interception logic is embedded in all resource acquisition methods.

[0036] Based on interception logic, when resources are invoked at the application code level, a custom resource acquisition class captures resource request commands in real time. It can extract the identifier, type information, and call context of the accessed resource and analyze these parameters. Depending on the current runtime environment, resource package update status, and configuration policy, it determines whether the resource access request needs to be redirected to an external resource. If a corresponding external resource exists, the custom resource acquisition class loads and returns the target resource from the external resource package; if no match is found, the system's default loading logic is invoked, returning the built-in resource.

[0037] By registering a custom interface parsing factory in the interface layer and deploying a custom resource acquisition class in the logic layer, the simultaneous interception and centralized management of the call paths of interface resources and code resources are achieved. This solves the problem that the resource loading channels of the interface layer and the logic layer are independent and difficult to control in the existing technology, thereby improving the flexibility and reliability of the system in terms of dynamic resource replacement, runtime updates and cross-version compatibility.

[0038] The above method creates a custom resource acquisition class as a dynamic resource interceptor. It does not modify the resource call statements at the code level, but only replaces the implementation class at the underlying level. It supports synchronous / asynchronous resource acquisition and can be adapted to different code execution scenarios.

[0039] In this implementation scenario, static interceptors have a higher processing priority than dynamic interceptors to avoid the same resource being intercepted repeatedly. Both static and dynamic interceptors encapsulate the captured resource call requests into standardized ResourceRequest objects, which contain core information such as resource identifier, call source, and context, ensuring that they can be processed uniformly in the future.

[0040] In this embodiment, based on the type of interceptor triggered by the resource call request, the request source is accurately deduced and obtained. Request sources include static and dynamic sources. If a custom interface parsing factory (static interceptor) is triggered, the request is determined to be a static request originating from the parsing of the interface description file; if a custom resource acquisition class (dynamic interceptor) is triggered, the request is determined to be a dynamic request originating from an active call at the code layer. When the interceptor captures a resource call request, it automatically determines the request source and adds a source identifier to the resource call request based on the request source. The resource call scenarios for different request sources have fundamental differences (static sources focus on interface rendering efficiency, while dynamic sources focus on adaptation accuracy), therefore, dedicated processing rules need to be customized for each type of source. Customized processing for static / dynamic resource calls improves adaptation accuracy and solves the problem of the traditional PAD solution having a single adaptation logic.

[0041] Each resource in an application has a unique resource identifier (such as the resource number in Android). After the interceptor captures a resource call request, it extracts the original parameters of the resource call to obtain the resource identifier. If the request source is static, it can be extracted from the attribute values ​​in the UI description file; if the request source is dynamic, it can be extracted from the input parameters of the resource call method in the code layer. The interceptor parses this resource identifier and uses the application's built-in resource mapping table to find the resource's name and type (image / icon / string). Based on the name and type, it then determines whether multi-dimensional adaptation is needed (e.g., system buttons do not need adaptation, but the application login page background image does). Specifically, it determines whether the resource is a core resource developed by the application and requires multi-dimensional adaptation.

[0042] If the resource is a system resource, a third-party SDK resource, or a basic resource without adaptation requirements, the default resource loading path is used. Based on the resource identifier, the corresponding target resource is retrieved from the application's internal pre-built resource library or the system's default resource management unit, and instantiated according to the system's original loading order and parsing method. Custom resource loading logic is no longer called, nor are external resource packages or alternative resource sources accessed. Instead, resource data from the application's original path is directly used for loading, thus ensuring the compatibility and stability of resource access logic. After loading is complete, the acquired resource is returned to the caller to support subsequent UI rendering or program logic execution.

[0043] If the resource to be called is an application-developed image, string, color, size, or other resource that needs to be adapted, then the resource needs to be intercepted. The default resource loading process will be paused, and the resource will be adapted and loaded based on the resource to be called, that is, the source of the resource loading will be changed (the resource will be loaded from the resource package).

[0044] In one implementation scenario, the name and type of the resource to be invoked are obtained based on the resource identifier. Corresponding features are then obtained based on the name and type. If the features meet preset conditions, it can be determined whether the resource to be invoked needs to be intercepted. Features include type features, used to determine whether the resource to be invoked belongs to a core resource type requiring multi-dimensional adaptation, specifically including: visual resources: images, icons, layouts; content resources: strings, colors, sizes; style resources: themes, attributes. Features also include attribution features, used to determine whether the resource to be invoked belongs to the application's self-developed resources, rather than system-level resources or third-party SDK resources. Features also include scenario features, determining whether the scenario features indicate that the display effect of the resource to be invoked directly affects the user experience and needs to be dynamically adjusted according to device / user configuration (e.g., Japanese text needs to be displayed in a Japanese-speaking environment, and a dark background image needs to be displayed in dark mode).

[0045] S103: Obtain the current environment information and determine whether the current environment information is consistent with the preset environment information; if not, proceed to step S104.

[0046] In a specific implementation scenario, the current environment information is obtained, such as the language environment (the language currently used by the application), the theme environment (the current display theme of the application, such as dark / light theme), and screen density (the pixel density (dpi) of the device screen and its corresponding density level). Preset environment information is the application's default adaptation benchmark, typically based on the environment configuration of the application's mainstream target users. For example, preset language: Chinese (zh); preset theme: light mode (light); preset density: standard density (mdpi). The current environment information is determined to be consistent with the preset environment information only if all current environment information matches it.

[0047] If the current environment information is consistent with the preset environment information, the built-in default resources corresponding to the application will be loaded directly. The resources corresponding to the preset environment are already built into the application installation package, so there is no need to search for them from external resource packages. Resources can be returned quickly, improving efficiency.

[0048] S104: Generate a path list including a set of resource search paths sorted by priority based on relevant information, resource information to be called and current environment information.

[0049] In a specific implementation scenario, three types of parameters—relevant information, resource information to be invoked, and current environment information—are structurally integrated. A pre-defined degradation algorithm generates an ordered list of resource search paths, from the most precise fit to the default fallback, providing a clear retrieval order for subsequent searches of suitable resources within the resource package. Relevant information includes the request source (static / dynamic source) and corresponding processing rules; resource information to be invoked includes the resource identifier, resource type, and resource name; and current environment information includes the currently used language, theme, and screen density.

[0050] Based on the current environment, the system progressively degrades resources according to priority, starting with density, then language, and finally theme. The degradation depth is controlled by considering the processing rules of the request source, ultimately generating an ordered list of paths. An optimal path is generated based on the information of the resource to be invoked and the current environment. Then, based on the optimal path, degradation paths are generated according to the degradation rule of first reducing density, then language, and finally theme, and the priority of each degradation path is obtained.

[0051] Assume the target resource name is "login_bg" and the resource type is "png". Current runtime environment information includes: language is Japanese (language=ja), interface theme is dark theme (theme=dark), and display density is xxhdpi; preset environment information is: language is Chinese (language=zh), theme is light theme (theme=light), and display density is mdpi. Based on the current environment information, a corresponding environment adaptation baseline segment can be generated, namely "ja / dark / xxhdpi". Based on this, combined with the resource identifier for the initial location of the target resource, the highest priority path of the resource is obtained as "ja / dark / xxhdpi / login_bg.png", which corresponds to a resource file that completely matches the current environment. When this highest priority path is not matched, the system performs path fallback according to a preset degradation strategy. First, while keeping the language and theme unchanged, degradation matching is performed along the density dimension. The density is downgraded from xxhdpi to xhdpi, hdpi, and mdpi, generating the following suboptimal paths in sequence: (1) "ja / dark / xhdpi / login_bg.png", corresponds to the second priority; (2) "ja / dark / hdpi / login_bg.png", corresponds to the third priority; (3) "ja / dark / mdpi / login_bg.png", which corresponds to the fourth priority.

[0052] While keeping the theme as dark, the language is downgraded from ja to the preset language zh, and the density fallback matching process is restarted to generate the following path: (4) "zh / dark / xxhdpi / login_bg.png", corresponding to the fifth priority; (5) "zh / dark / xhdpi / login_bg.png", corresponding to the sixth priority; (6) "zh / dark / hdpi / login_bg.png", corresponding to the seventh priority; (7) “zh / dark / mdpi / login_bg.png”, which corresponds to the eighth priority.

[0053] The topic parameter is downgraded from dark to the preset topic light, and the language is fixed as zh. Then, a fallback matching is performed according to the density dimension to obtain the following fallback path: (8) "zh / light / xxhdpi / login_bg.png", corresponding to the ninth priority; (9) "zh / light / xhdpi / login_bg.png", corresponding to the tenth priority; (10) "zh / light / hdpi / login_bg.png", corresponding to the eleventh priority; (11) "zh / light / mdpi / login_bg.png" corresponds to the twelfth priority, and this path is the default fallback path.

[0054] S105: Traverse the path list in descending order of priority and determine whether the resource search path currently being traversed can obtain the resource; if so, proceed to step S106.

[0055] In a specific implementation scenario, the system iterates through the path list to the current resource lookup path (such as the highest priority resource lookup path), extracting information such as the complete string, priority level, and associated resource type of the resource lookup path. Using the current resource lookup path as the key, it queries the directory index of the preloaded resource package. If the key is not found in the directory index, or the resource status of the index record is invalid, it is determined that the path cannot retrieve the resource.

[0056] Move the traversal pointer to the resource search path with the next priority in the path list (e.g., move from priority 1 to priority 2), and repeat the above search steps.

[0057] In other implementation scenarios, if the key exists in the index table and the resource status is valid, the physical storage path of the resource package is concatenated with the current traversal path to generate the complete physical address of the resource. The system file API is called to determine whether the file exists, to verify that the application has read permissions for the file, to read the file characteristic value, and to verify that the file is not corrupted. If all verifications pass, it is determined that the resource can be obtained through the resource search path.

[0058] S106: Set the resource as the target resource and stop the traversal operation.

[0059] In a specific implementation scenario, the resource corresponding to the current resource search path is marked as the target resource, and key information such as the resource's physical address, adaptation dimension, and file size is recorded. The timer is stopped, the traversal context is cleared, and the remaining paths are no longer searched.

[0060] S107: Read the binary data stream of the target resource, parse the binary data stream into a format that matches the application, and then send it to the requester who sent the resource call request.

[0061] In a specific implementation scenario, the target resource is accessed based on a pre-established access link, and its corresponding binary data stream is read. During the reading process, byte data of the target resource is continuously acquired through the underlying input / output interface, and a complete data stream object is formed in the memory buffer for subsequent parsing and processing.

[0062] Subsequently, the binary data stream is parsed and converted to conform to the resource data format requirements of the application. Depending on the resource type, the parsing method may include image format conversion, text encoding recognition, color value decompression, and media file decapsulation. For example, when the resource type is an image file, the parsing unit decodes its binary data to generate an image object that the application can directly recognize; when the resource type is text, the binary data stream is parsed into a renderable text data structure according to the system's current character encoding standard. This parsing process ensures that the resource is compatible with the application's rendering engine or logic layer interface after loading.

[0063] After parsing, the parsed data object is encapsulated into a transmittable data unit and sent to the requester that initiated the resource call. This requester can be a UI rendering module, a script execution module, or a business logic layer component. Data transmission is completed through an internal resource result feedback interface, enabling the resource data to be directly recognized and used by the requester, thus completing the closed loop of the resource loading process.

[0064] In other implementation scenarios, when the path list traversal process is complete and no available target resource is found for any of the candidate paths, the built-in resource fallback process begins. Specifically, based on the resource identifier of the resource to be invoked, this identifier is mapped to the application's internal resource index table to determine the corresponding application built-in resource entry. Subsequently, the application's native resource management interface is called to perform an existence check on the built-in resource to verify whether the resource is pre-stored in the application's internal resource library.

[0065] If the verification result is positive, the resource loading process begins. By calling the native resource loading logic, the content of the built-in resource is read and parsed, enabling the resource to be loaded normally and returned to the resource requester, thereby ensuring the continuity and correctness of the resource call process.

[0066] If the verification result indicates that the resource does not exist (i.e., no corresponding resource is detected in the application's internal resource library), the system triggers a placeholder resource fallback mechanism. This mechanism can select to load a default placeholder file based on the resource type. For example, it loads a predefined placeholder image if an image resource is missing, and returns an empty string or an empty data object if text or data resources are missing. Through this fallback process, the application can maintain stable operation in abnormal scenarios such as missing resources or loading failures, avoiding program exceptions or crashes caused by null pointers or invalid references during interface rendering.

[0067] As described above, in this implementation scenario, by obtaining resource package information during the application startup phase and setting interceptors on the resource call path, unified monitoring and dynamic management of the resource call process are achieved. Based on the differences between the current operating environment and the preset environment, a multi-dimensional resource search path is automatically generated in order of priority, and resources are matched and loaded sequentially according to priority. This enables intelligent resource adaptation under multiple factors such as language, theme, and density. Through the dynamic resource parsing and formatted return mechanism, while maintaining flexible adaptability, it does not rely on a fixed directory structure or specific platform interface. It can take into account both the application's architectural compatibility and the intelligent requirements of resource loading, effectively improving resource loading efficiency and cross-environment adaptability stability, and meeting the unified resource management and high availability requirements of modern applications in multi-platform and multi-configuration scenarios.

[0068] Please see Figure 3 , Figure 3 A schematic diagram of the internal structure of an electronic device in one embodiment is shown. This electronic device can specifically be a terminal or a server. Figure 3As shown, the electronic device includes a processor, a memory, and a network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement a dynamic resource loading management method. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to implement a dynamic resource loading management method. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0069] In one embodiment, an electronic device is provided, including a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps described above.

[0070] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the steps described above.

[0071] The present invention also provides a dynamic management system for resource loading, which includes the electronic device and network-attached storage device described above. The electronic device has an application installed that can execute the steps of the method described above.

[0072] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0073] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0074] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Those skilled in the art can modify the technical solutions described in the above embodiments, or make equivalent substitutions for some of the technical features; and all such modifications and substitutions should fall within the protection scope of the appended claims of the present invention.

Claims

1. A dynamic management method for resource loading, characterized in that, The application is used in an electronic device that is communicatively connected to a network-attached storage device and accesses the network-attached storage device through the application. The dynamic management method for resource loading includes: When the application starts, obtain relevant information about the resource package corresponding to the application; An interceptor is set on the resource call path. When a resource call request is detected in the application, the resource call request is parsed and the information of the resource to be called is obtained through the interceptor. Obtain current environment information and determine whether the current environment information is consistent with preset environment information; If not, then based on the relevant information, the resource information to be invoked, and the current environment information, a path list including a set of resource search paths sorted by priority is generated; Traverse the path list in descending order of priority and determine whether the resource search path currently being traversed can obtain the resource. If so, then the resource is taken as the target resource, and the traversal operation is stopped; The binary data stream of the target resource is read, parsed into a format matching the application, and then sent to the requester who sent the resource call request.

2. The dynamic management method for resource loading according to claim 1, characterized in that, The step of setting an interceptor on the resource path includes: Create a custom interface parsing factory that can identify and intercept all resource references in the interface description file and replace all default factories in the application with the custom interface parsing factory. Create a custom resource acquisition class, define a resource acquisition method in the custom resource acquisition class, the resource acquisition method is used to capture resource requests at the code layer, and replace all default classes in the application with the custom resource acquisition class.

3. The dynamic management method for resource loading according to claim 2, characterized in that, The step of parsing the resource request includes: The source of the resource call request is obtained based on the interceptor type triggered by the resource call request, and the request source includes static source and dynamic source; The processing rules corresponding to the resource call request are obtained based on the request source.

4. The dynamic management method for resource loading according to claim 1, characterized in that, The step of obtaining the information of the resource to be invoked includes: Identify the resource identifier of the resource call request, and obtain the name and type of the resource to be called based on the resource identifier; Based on the name and type, determine whether the resource to be invoked needs to be intercepted; If not, then proceed with the step of obtaining the current environment information, and subsequent steps.

5. The dynamic management method for resource loading according to claim 1, characterized in that, The step of generating a path list including a set of priority-ordered resource search paths based on the relevant information, the resource information to be invoked, and the current environment information includes: Generate the optimal path based on the resource information to be invoked and the current environment information; Based on the optimal path, a degradation path is generated according to the degradation rule of first reducing density, then language, and finally topic, and the priority of each degradation path is obtained.

6. The dynamic management method for resource loading according to claim 1, characterized in that, The step of obtaining relevant information about the resource package corresponding to the application includes: Confirm the location of the resource package, establish an access link with the resource package, and preload the directory index of the resource package.

7. The dynamic resource loading management method according to any one of claims 1-6, characterized in that, After the step of traversing the path list in descending order of priority, the following is included: If the target resource cannot be obtained by traversing all the resource search paths, then the built-in resource is invoked and used as the target resource.

8. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The device stores a computer program that, when executed by a processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 7.

10. A dynamic management system for resource loading, characterized in that, It includes a network-attached storage device and the electronic device of claim 8, wherein the electronic device is equipped with an application program capable of performing the steps of the method of any one of claims 1 to 7.

Images