Resource hierarchical mapping method, device and system for modular application
Patent Information
- Application Number
- CN202610729193.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-25
- Publication Date
- 2026-09-29
AI Technical Summary
尽管现有的资源管控技术能够实现资源ID的自动生成,然而其采用的全局扁平结构会导致资源管理混乱,缺乏必要的分层能力,且资源标识符无语义类型,这使得它难以契合静态强类型语言的编译要求;同时,由于其原生缺乏自动常量化机制,所依赖的第三方工具也往往不具备模块化架构的分层隔离能力,致使与构建系统深度耦合变得困难
可以使得资源管控具备分层能力,有利于提高应用资源管控效率和准确性,从而有利于推动模块化应用的顺利开发。
Smart Images

Figure CN122837822A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of application resource processing technology, and in particular to a resource layering mapping method, apparatus and system for modular applications. Background Technology
[0002] In the current field of modular application development, resource management faces multiple challenges. While existing resource management technologies can automatically generate resource IDs, their globally flat structure leads to chaotic resource management, a lack of necessary layering capabilities, and the absence of semantic types for resource identifiers, making them difficult to comply with the compilation requirements of statically typed languages. Furthermore, the lack of native automatic constant quantization mechanisms and the reliance on third-party tools often lack the layered isolation capabilities of modular architectures, making deep coupling with the build system difficult. These shortcomings collectively result in inefficient resource management, thereby increasing the development cost and error rate of modular applications. Therefore, providing a resource layering mapping technology solution for modular applications to improve the efficiency and accuracy of resource management is crucial. Summary of the Invention
[0003] This invention provides a resource layering mapping method, apparatus, and system for modular applications, which enables layered resource management, improves the efficiency and accuracy of application resource management, and thus facilitates the smooth development of modular applications.
[0004] To address the aforementioned technical problems, the first aspect of this invention discloses a resource layering mapping method for modular applications. The method is applied to a terminal device equipped with the modular application, and the terminal device is capable of communicating with a network-attached storage device. The method includes: Based on the build configuration file of the modular application to be processed, determine the basic information of all modules of the modular application; the basic information of each module includes at least the role classification information of that module; Based on the resource directory path information of all the modules, a resource scan operation is performed on all the modules to obtain a list of resource entries for all the modules; Based on the role classification flag information of all the modules, generate the class name information of all the modules, and based on the resource entry list and class name information of all the modules, generate the interface definition information of all the modules. Based on the resource entry list, class name information, and interface definition information of all modules, a target mapping operation is performed on all modules to obtain the source code file of the modular application; the source code file is used to perform hierarchical mapping operation of resource references on the modular application.
[0005] As an optional implementation, in the first aspect of the present invention, determining the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed includes: The original text content in the build configuration file of the modular application to be processed is read, and the original text content is subjected to fault-tolerant preprocessing operation to obtain the processed text content of the modular application; the fault-tolerant preprocessing operation includes at least one of single-line comment removal operation, multi-line comment removal operation and target symbol removal operation. The processed text content is parsed to obtain the parsed text of the modular application, and the basic array information in the parsed text is extracted. Based on the basic array information, determine the basic information of all modules of the modular application.
[0006] As an optional implementation, in the first aspect of the present invention, the resource scanning operation includes at least one of a declarative resource scanning operation, a file-based resource scanning operation, and a raw file resource scanning operation; The step of performing a resource scan on all modules based on their resource directory path information to obtain a list of resource entries for all modules includes: Based on the resource directory path information of all the modules, read the structured data files of all the modules, and extract the target array information of all the modules based on the structured data files of all the modules; Perform target element traversal on the target array information of all the modules to obtain the declarative resource scan fields of all the modules, and generate a resource entry list for all the modules based on the declarative resource scan fields of all the modules; and / or, Based on the resource directory path information of all the modules, read the first directory file of all the modules, and filter the first directory file of all the modules according to the preset first file filtering conditions to obtain the first filtered file of all the modules; The filenames of all the first-filtered files of all the modules are subjected to file extension removal to obtain the file-based resource scan fields of all the modules, and a list of resource entries for all the modules is generated based on the file-based resource scan fields of all the modules; and / or, Based on the resource directory path information of all the modules, read the second directory files of all the modules, and filter the second directory files of all the modules according to the preset second file filtering conditions to obtain the second filtered files of all the modules; Based on the complete filenames of the second filtered files of all the modules, determine the original file resource scan fields of all the modules, and generate a list of resource entries for all the modules based on the original file resource scan fields of all the modules.
[0007] As an optional implementation, in the first aspect of the present invention, generating class name information for all modules based on the role classification marker information of all modules includes: Based on the role classification flag information of all the modules, determine the module type corresponding to all the modules; For each module, when the module type corresponding to the module is a topic module, the class name information of the module is determined as the first class name; when the module type corresponding to the module is a business module, the class name information of the module is determined as the second class name. Wherein, when any of the business modules needs to use the module resources within the corresponding theme module, the business module directly references the module resources under the first category name of the theme module.
[0008] As an optional implementation, in the first aspect of the present invention, generating interface definition information for all modules based on the resource entry list and class name information of all modules includes: For each module, based on the resource entry list of the module, the resource entry information of the target resource category of the module is identified, and based on the resource entry information of the target resource category of the module, it is determined whether the resource entry information contains the target character; the resource entry list includes resource entry information of multiple resource categories; For each module, when it is determined that the resource entry information does not contain the target character, the interface definition information of the module is generated based on the resource entry information and the class name information of the module; when it is determined that the resource entry information contains the target character, the definition processing character corresponding to the target character is determined, and the interface definition information of the module is generated based on the definition processing character, the resource entry information and the class name information of the module.
[0009] As an optional implementation, in the first aspect of the present invention, the method further includes: Determine the file path corresponding to the source code file of the modular application, and determine whether there are similar code files in the file path that are similar to the source code file; When it is determined that the similar code file does not exist in the file path, the source code file is written to the file path; When it is determined that a similar code file exists in the file path, the degree of similarity between the source code file and the similar code file is determined, and it is determined whether the degree of similarity is less than or equal to a preset similarity threshold. When it is determined that the similarity is less than or equal to the similarity threshold, the source code file overwrites the similar code file and is written to the file path; When the similarity is determined to be greater than the similarity threshold, the operation of writing the source code file to the file path is skipped.
[0010] As an optional implementation, in the first aspect of the present invention, the method further includes: For each module, based on the module's resource directory path information and through a preset global registry, it is determined whether the module has registered a listener. For each module, when it is determined that the module has not registered the listener, the listening requirement parameters of the module are determined, and the listener of the module is registered in the global registry according to the listening requirement parameters; the listening requirement parameters include at least one of the following: listening debouncing callback parameters, listening configuration parameters, and listening event type parameters.
[0011] A second aspect of the present invention discloses a resource layering mapping apparatus for modular applications, the apparatus being applied to a terminal device on which the modular application is installed, and the terminal device being communicatively connected to a network-attached storage device, the apparatus comprising: A determination module is used to determine the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed; the basic information of each module includes at least the role classification information of that module; The scanning module is used to perform a resource scanning operation on all the modules based on the resource directory path information of all the modules, and obtain a list of resource entries for all the modules; The generation module is used to generate class name information for all modules based on the role classification flag information of all modules, and to generate interface definition information for all modules based on the resource entry list and class name information of all modules. The mapping module is used to perform target mapping operations on all the modules according to the resource entry list, class name information and interface definition information of all the modules, so as to obtain the source code file of the modular application; the source code file is used to perform hierarchical mapping operations on resource references of the modular application.
[0012] As an optional implementation, in a second aspect of the present invention, the method by which the determining module determines the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed specifically includes: The original text content in the build configuration file of the modular application to be processed is read, and the original text content is subjected to fault-tolerant preprocessing operation to obtain the processed text content of the modular application; the fault-tolerant preprocessing operation includes at least one of single-line comment removal operation, multi-line comment removal operation and target symbol removal operation. The processed text content is parsed to obtain the parsed text of the modular application, and the basic array information in the parsed text is extracted. Based on the basic array information, determine the basic information of all modules of the modular application.
[0013] As an optional implementation, in a second aspect of the present invention, the resource scanning operation includes at least one of a declarative resource scanning operation, a file-based resource scanning operation, and a raw file resource scanning operation; Specifically, the scanning module performs a resource scan on all modules based on their resource directory path information to obtain a list of resource entries for all modules. Based on the resource directory path information of all the modules, read the structured data files of all the modules, and extract the target array information of all the modules based on the structured data files of all the modules; Perform target element traversal on the target array information of all the modules to obtain the declarative resource scan fields of all the modules, and generate a resource entry list for all the modules based on the declarative resource scan fields of all the modules; and / or, Based on the resource directory path information of all the modules, read the first directory file of all the modules, and filter the first directory file of all the modules according to the preset first file filtering conditions to obtain the first filtered file of all the modules; The filenames of all the first-filtered files of all the modules are subjected to file extension removal to obtain the file-based resource scan fields of all the modules, and a list of resource entries for all the modules is generated based on the file-based resource scan fields of all the modules; and / or, Based on the resource directory path information of all the modules, read the second directory files of all the modules, and filter the second directory files of all the modules according to the preset second file filtering conditions to obtain the second filtered files of all the modules; Based on the complete filenames of the second filtered files of all the modules, determine the original file resource scan fields of all the modules, and generate a list of resource entries for all the modules based on the original file resource scan fields of all the modules.
[0014] As an optional implementation, in the second aspect of the present invention, the method by which the generation module generates class name information for all modules based on the role classification marker information of all modules specifically includes: Based on the role classification flag information of all the modules, determine the module type corresponding to all the modules; For each module, when the module type corresponding to the module is a topic module, the class name information of the module is determined as the first class name; when the module type corresponding to the module is a business module, the class name information of the module is determined as the second class name. Wherein, when any of the business modules needs to use the module resources within the corresponding theme module, the business module directly references the module resources under the first category name of the theme module.
[0015] As an optional implementation, in the second aspect of the present invention, the method by which the generation module generates interface definition information for all the modules based on the resource entry list and class name information of all the modules specifically includes: For each module, based on the resource entry list of the module, the resource entry information of the target resource category of the module is identified, and based on the resource entry information of the target resource category of the module, it is determined whether the resource entry information contains the target character; the resource entry list includes resource entry information of multiple resource categories; For each module, when it is determined that the resource entry information does not contain the target character, the interface definition information of the module is generated based on the resource entry information and the class name information of the module; when it is determined that the resource entry information contains the target character, the definition processing character corresponding to the target character is determined, and the interface definition information of the module is generated based on the definition processing character, the resource entry information and the class name information of the module.
[0016] As an optional implementation, in a second aspect of the invention, the determining module is further configured to: Determine the file path corresponding to the source code file of the modular application; The device further includes: The first judgment module is used to determine whether there is a similar code file in the file path that is similar to the source code file; The writing module is used to write the source code file to the file path when the first judgment module determines that the similar code file does not exist in the file path; The determining module is further configured to determine the degree of similarity between the source code file and the similar code file when the first determining module determines that the similar code file exists in the file path; The first judgment module is further configured to determine whether the similarity is less than or equal to a preset similarity threshold; The writing module is further configured to, when the first judgment module determines that the similarity is less than or equal to the similarity threshold, overwrite the similar code file with the source code file and write it to the file path; when the first judgment module determines that the similarity is greater than the similarity threshold, skip the operation of writing the source code file to the file path.
[0017] As an optional implementation, in a second aspect of the invention, the apparatus further includes: The second judgment module is used to determine, for each module, whether a listener has been registered for the module based on the module's resource directory path information and through a preset global registry. The determining module is further configured to, for each module, determine the listening requirement parameters of the module when the judging module determines that the module has not registered the listener; the listening requirement parameters include at least one of the following: listening debouncing callback parameters, listening configuration parameters, and listening event type parameters. The registration module is used to register the module's listener to the global registry according to the listening requirement parameters.
[0018] A third aspect of the present invention discloses a terminal device, the terminal device comprising: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the resource layering mapping method for modular applications disclosed in the first aspect of the present invention.
[0019] The fourth aspect of the present invention discloses a computer storage medium storing computer instructions, which, when invoked, are used to execute the resource layering mapping method for modular applications disclosed in the first aspect of the present invention.
[0020] The fifth aspect of the present invention discloses a resource layering mapping system for modular applications, the system comprising the resource layering mapping device for modular applications disclosed in the second aspect of the present invention, and a network-attached storage device communicatively connected to the device; or, the system comprising a terminal device disclosed in the third aspect of the present invention, and a network-attached storage device communicatively connected to the terminal device.
[0021] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: This enables layered resource management, which helps improve the efficiency and accuracy of application resource management, thereby facilitating the smooth development of modular applications. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 This is a flowchart illustrating a resource layering mapping method for modular applications disclosed in an embodiment of the present invention; Figure 2 This is a flowchart illustrating another resource layering mapping method for modular applications disclosed in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a resource layering mapping device for modular applications disclosed in an embodiment of the present invention; Figure 4 This is a schematic diagram of another resource layering mapping device for modular applications disclosed in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a terminal device disclosed in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a resource layering mapping system for modular applications disclosed in an embodiment of the present invention. Detailed Implementation
[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0025] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.
[0026] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0027] This invention discloses a resource layering mapping method, apparatus, and system for modular applications, which enables resource management to have layering capabilities, improves the efficiency and accuracy of application resource management, and thus facilitates the smooth development of modular applications.
[0028] Example 1 Please see Figure 1 , Figure 1 This is a flowchart illustrating a resource layering mapping method for modular applications disclosed in an embodiment of the present invention. Optionally, this method can be implemented by a resource layering mapping device, which can be integrated into a terminal device (such as a smart computer, smart tablet, etc.), or it can be a local server or cloud server used to process the resource layering mapping process for modular applications, etc. The embodiments of the present invention do not impose limitations. Figure 1 As shown, this method is applied to terminal devices with modular applications installed, and the terminal devices are capable of communicating with network-attached storage devices. This resource hierarchical mapping method for modular applications may include the following operations: 101. Based on the build configuration file of the modular application to be processed, determine the basic information of all modules of the modular application.
[0029] In this embodiment of the invention, the basic information of each module further includes at least the role classification identifier information (isTheme) of the module, and may also include the name information (name) of the module and the source code relative path information (srcPath).
[0030] 102. Based on the resource directory path information of all modules, perform a resource scan operation on all modules to obtain a list of resource entries for all modules.
[0031] In this embodiment of the invention, optionally, the resource scanning operation includes at least one of the following: declarative resource scanning operation (element type), file-based resource scanning operation (media type), and raw file resource scanning operation (rawfile type).
[0032] 103. Based on the role classification information of all modules, generate the class name information of all modules, and based on the resource entry list and class name information of all modules, generate the interface definition information of all modules.
[0033] 104. Based on the resource entry list, class name information, and interface definition information of all modules, perform target mapping operations on all modules to obtain the source code files of the modular application.
[0034] In this embodiment of the invention, the source code file can be understood as a file obtained by assembling the interface definitions of each module with the corresponding resource mapping attributes through a preset function mapping relationship. The source code file is used to perform hierarchical mapping operations for resource references in modular applications.
[0035] Furthermore, steps 101-104 above, as well as the various module processing steps below, can all select a matching trigger mode through the runtime context, such as single trigger mode, listener mode, and build system plugin mode.
[0036] In summary, it's important to note that the module auto-discovery mechanism based on the build configuration file allows developers to automatically generate resource mapping files for new modules during subsequent project synchronizations after they are created and registered in the build configuration, without requiring any additional configuration in the code generation tool. Module deletion follows the same principle—removing a module from the build configuration automatically exits the generation process. Project maintenance costs do not increase with the number of modules.
[0037] As can be seen, implementing the embodiments of the present invention can generate class name information for each module based on the role classification information of each module in the modular application. Then, combined with the resource entry list of each module obtained from resource scanning, interface definition information for each module is generated. Based on the resource entry list, class name information, and interface definition information of each module, target mapping operation is performed on each module to obtain the source code file of the modular application. In this way, resource management can have layered capabilities, which is conducive to improving the efficiency and accuracy of application resource management, thereby facilitating the smooth development of modular applications.
[0038] In an optional embodiment, the method further includes: Determine the file path corresponding to the source code file of the modular application, and determine whether there are similar code files in the file path that are similar to the source code file; When it is determined that no similar code file exists in the file path, the source code file is written to the file path; When it is determined that there are similar code files in the file path, the degree of similarity between the source code file and the similar code file is determined, and it is determined whether the degree of similarity is less than or equal to the preset similarity threshold. When the similarity is determined to be less than or equal to the similarity threshold, the source code file overwrites the similar code file and is written to the file path; If the similarity is determined to be greater than the similarity threshold, skip the operation of writing the source code file to the file path.
[0039] In this optional embodiment, the hash values of each code file to be compared in the source code file and the file path can be calculated using a hash algorithm to reflect the overall characteristics of the content of the source code file and each code file to be compared. At the same time, key code features such as function names, variable names, and control structures are extracted from the source code file and each code file to be compared. Based on the overall characteristics and key code features of the source code file and each code file to be compared, it can be determined whether there are similar code files in the file path that are similar to the source code file.
[0040] Furthermore, the source code file and similar code files can be converted into vector form using a cosine similarity algorithm. The cosine of the angle between the two vectors can then be calculated to determine the similarity between the source code file and the similar code files. The similarity value ranges from [0, 1], with values closer to 1 indicating higher similarity. This similarity threshold can be flexibly set according to the specific requirements of the project and the code update strategy.
[0041] It should be noted that this embodiment performs a full-text comparison of the code file before writing, does not touch the file system if the file content remains unchanged, and retains the original timestamp. The build system correctly skips the unchanged compilation unit. This strategy minimizes the compilation overhead related to resource mapping.
[0042] As can be seen, this optional embodiment can write the source code file to the file path when there are no similar code files in the file path, or when the similar code files and the source code files have low similarity; while when the similar code files and the source code files have high similarity, it is not necessary to write the source code file. This helps to improve the efficiency of writing source code files, and also helps to reduce the compilation overhead related to resource mapping to zero or a minimum. In this way, it not only improves the development efficiency of modular applications, but also reduces unnecessary system resource consumption, thereby strongly promoting the smooth development and continuous optimization of modular applications.
[0043] In another alternative embodiment, the method further includes: For each module, based on the module's resource directory path information and through a preset global registry, it is determined whether the module has registered a listener. For each module, when it is determined that the module has not registered a listener, the module's listening requirement parameters are determined, and the module's listener is registered in the global registry according to the listening requirement parameters.
[0044] In this optional embodiment, the listening requirement parameters may include at least one of the following: listening debouncing callback parameters, listening configuration parameters, and listening event type parameters.
[0045] For example, the listener registration process for each module can be understood as follows: After entering the resource directory path information for each module, the system checks whether the module already has a listener running through the global registry (Map structure, with the module name as the key). If it already exists, skip it to prevent the build system from repeatedly creating listeners when apply() is called multiple times in daemon mode; If it does not exist, then according to steps 101~104 and the above writing steps, the debouncing function is wrapped, such as a delay of 500ms. That is, if there are multiple file change events within 500ms, only one generation is triggered after the last event to avoid duplicate generation caused by batch file operations (such as copying multiple images at the same time). Then, register listeners for the module's resource directory. Configurations can include: not exiting due to lack of events, not triggering events for existing files, only listening for subsequent changes, ignoring hidden files starting with a specific symbol, and waiting n milliseconds without changes after a file is written before triggering an event to avoid reading incomplete files in the middle of the writing process, etc. Event types can include: file addition (add), file modification (change), file deletion (unlink), directory addition (addDir), directory deletion (unlinkDir), etc., all of which can trigger debouncing callbacks. Finally, register the listener to the global table to prevent duplicate creation.
[0046] As can be seen, this optional embodiment can register the module's listener in the global registry based on the module's listening requirement parameters when it is determined that the module has not registered a listener. This improves the accuracy and efficiency of the module's listener registration, and automatically starts file listening during the build phase without requiring manual triggering of the build. It also ensures that the module shares the same generation engine with the build artifacts, guaranteeing consistency and thus improving the user's application development experience.
[0047] Example 2 Please see Figure 2 , Figure 2 This is a flowchart illustrating another resource layering mapping method for modular applications disclosed in an embodiment of the present invention. Optionally, this method can be implemented by a resource layering mapping device, which can be integrated into a terminal device (such as a smart computer, smart tablet, etc.), or it can be a local server or cloud server used to process the resource layering mapping process for modular applications, etc., and the embodiments of the present invention do not impose limitations. Figure 2 As shown, this method is applied to terminal devices with modular applications installed, and the terminal devices are capable of communicating with network-attached storage devices. This resource hierarchical mapping method for modular applications may include the following operations: 201. Read the original text content from the build configuration file of the modular application to be processed, and perform fault-tolerant preprocessing on the original text content to obtain the processed text content of the modular application.
[0048] In this embodiment of the invention, optionally, the fault-tolerant preprocessing operation includes at least one of a single-line comment removal operation, a multi-line comment removal operation, and a target symbol removal operation.
[0049] When the fault-tolerant preprocessing includes single-line comment removal, multi-line comment removal, and target symbol removal, the fault-tolerant preprocessing can sequentially perform the following three regular expression replacement steps: (1) Remove single-line comments: Match and delete the content from / / to the end of the line; (2) Remove multi-line comments: Match and delete the content between / * ... * / ; (3) Remove trailing commas: Match the pattern of , followed by ] or}, and remove extra commas.
[0050] 202. Parse the processed text content to obtain the parsed text of the modular application, and extract the basic array information from the parsed text.
[0051] 203. Based on the basic array information, determine the basic information of all modules of the modular application.
[0052] In this embodiment of the invention, the module name in the basic information can be understood as: ug_theme, ug_login, entry, etc., the relative path of the source code can be understood as: . / modules / ug_theme, and the role classification flag can be understood as: marked as true when the module name matches the preset theme module name, otherwise as false.
[0053] It's important to note that role categories use a name matching strategy rather than a hard-coded list. The theme module name is a globally configured constant (default value: ug_theme), which users can modify to suit different projects. Fault-tolerant preprocessing ensures the tool is compatible with JSON5-formatted configuration files (allowing comments and trailing commas) without requiring an additional JSON5 parsing library.
[0054] 204. Based on the resource directory path information of all modules, perform a resource scan operation on all modules to obtain a list of resource entries for all modules.
[0055] 205. Based on the role classification information of all modules, generate the class name information of all modules, and based on the resource entry list and class name information of all modules, generate the interface definition information of all modules.
[0056] 206. Based on the resource entry list, class name information, and interface definition information of all modules, perform target mapping operations on all modules to obtain the source code files of the modular application.
[0057] In this embodiment of the invention, for other descriptions of steps 204-206, please refer to the detailed description of steps 102-104 in Embodiment 1. This embodiment of the invention will not repeat them.
[0058] As can be seen, implementing the embodiments of the present invention enables flexible, fault-tolerant preprocessing of the original text content to obtain the processed text content of the modular application. The processed text content is then parsed, and basic array information is extracted to determine the basic information of all modules in the modular application. This allows resource references to be upgraded from string literals to type-constrained constant attributes, immediately reporting errors when spelling errors or references to deleted resources occur during the compilation phase, without waiting until application runtime. Compared to existing technologies, where defects in string literal references require a complete chain of "encoding → compilation → packaging → installation → running → reproduction" to be discovered, the present invention moves the defect exposure stage forward, reducing defect repair costs by an order of magnitude.
[0059] In an optional embodiment, step 204 above, which involves performing a resource scan on all modules based on their resource directory path information to obtain a list of resource entries for all modules, includes: Based on the resource directory path information of all modules, read the structured data files of all modules, and extract the target array information of all modules based on the structured data files of all modules; Perform target element traversal on the target array information of all modules to obtain the declarative resource scan fields of all modules, and generate a list of resource entries for all modules based on the declarative resource scan fields of all modules; and / or, Based on the resource directory path information of all modules, read the first directory file of all modules, and filter the first directory file of all modules according to the preset first file filtering conditions to obtain the first filtered file of all modules. The filenames of all filtered files from all modules are processed by removing file extensions to obtain the file-based resource scan fields for all modules. Based on these fields, a list of resource entries for all modules is generated; and / or, Based on the resource directory path information of all modules, read the second directory files of all modules, and filter the second directory files of all modules according to the preset second file filtering conditions to obtain the second filtered files of all modules; Based on the complete filenames of the second filtered files of all modules, determine the original file resource scan fields of all modules, and generate a list of resource entries for all modules based on the original file resource scan fields of all modules.
[0060] In this optional embodiment, the three types of resource scanning—declarative resource scanning, file-based resource scanning, and raw file resource scanning—can be executed in parallel or sequentially.
[0061] Furthermore, the following explains each resource scanning method: (1) Declarative resource scanning Scanning objects: JSON files in the resources / base / element / directory, supporting types such as string.json (string), color.json (color), float.json (floating-point number), boolean.json (boolean value), and integer.json (integer). Handling method: S1. Read the corresponding JSON file (e.g., string.json); S2. Parse the JSON and extract an array with the resource type name as the key (e.g., json["string"]). S3. Iterate through each element in the array and extract its name field.
[0062] (2) File-based resource scanning Scan target: All files under the resources / base / media / directory; Handling method: S1. List all files in the directory; S2. Filtering conditions: Must be a regular file (not a directory), must not start with a dot (to exclude hidden files), must not end with .json (to exclude description files), etc. S3. For each file, extract the filename and remove the extension to get the resource name (e.g., icon_back.webp → icon_back), and then output the resource name.
[0063] (3) Original file resource scanning Scan targets: All files in the resources / rawfile / directory; Handling method: S1. List all files in the directory; S2. Filtering criteria: Must be a regular file, must not start with a period (.), etc. S3. Keep the complete filename (including the extension) as the resource name (e.g., data.json → data.json), and then output the resource name.
[0064] It should be noted that the output of the three types of scanners is uniformly in the {name:string} structure, which allows subsequent interface derivation and code generation pipelines to be unaware of the differences in the original storage format of the resources.
[0065] Furthermore, JSON declarative resources (string, color, float, boolean, integer), stand-alone file resources (media images), and raw file resources (rawfile) are uniformly abstracted into a standardized resource entry structure and processed through the same "interface deduction → code generation" pipeline. When the platform introduces new resource types, only the corresponding scanning adapter needs to be added; the generation pipeline does not need to be modified, and the system has good scalability.
[0066] As can be seen, this optional embodiment can comprehensively process the resource directory path information of all modules, employing one or more of declarative resource scanning, file-based resource scanning, and raw file resource scanning, performing resource scanning operations in parallel or sequentially. This improves the accuracy of obtaining the resource entry list for each module and eliminates the need for subsequent interface derivation and code generation pipelines to consider differences in the original storage format of resources, greatly simplifying the processing flow, improving system compatibility and scalability, and thus contributing to improved efficiency and quality of modular application development.
[0067] In another optional embodiment, step 205 above, which generates class name information for all modules based on the role classification flag information of all modules, includes: Based on the role classification information of all modules, determine the module type corresponding to each module; For each module, when the module type is a topic module, the module's class name is determined as the first class name; when the module type is a business module, the module's class name is determined as the second class name.
[0068] In this optional embodiment, when any business module needs to use the module resources within the corresponding topic module, the business module directly references the module resources under the first type of the topic module.
[0069] Furthermore, the first type of name can be a theme resource class name, and the second type of name can be a resource class name. The class name generated by the theme module (isTheme = true), such as TR (Theme Resource), is globally unique and can be exported through the module entry file for all business modules to depend on and reference. The class name generated by the business module (isTheme = false), such as R (Resource), is generated independently by each module and only contains resources from its own resource directory.
[0070] It's important to note that the R class in the business module does not contain any resource entries from the theme module. When a business module needs to use public theme resources, it directly references the TR class exported by the theme module through the module dependency mechanism (import {TR}from 'ug_theme'), rather than copying it in its own R file. This ensures that the public resource mapping is globally unique, with no multiple copies; and that when theme resources change, only the TR file needs to be regenerated, without affecting the business module's R file.
[0071] As can be seen, this optional embodiment can determine the corresponding module type based on the role classification information of each module, and generate distinctive class name information for both thematic modules and business modules. This achieves clear and effective isolation and management of thematic resources and business resources, and allows direct referencing of resources under class names exported by thematic modules through the module dependency mechanism. This reduces the occurrence of copying thematic resource entries within a single module, ensuring the uniqueness of public resource mappings globally, eliminating multiple copies, significantly reducing resource redundancy, and lowering code size and maintenance costs. Furthermore, when thematic resources change, only one file corresponding to the thematic module needs to be regenerated, ensuring that related files in business modules are not affected. This greatly improves system stability and maintainability, effectively guaranteeing the efficiency and reliability of modular application development.
[0072] In another optional embodiment, step 205 above, which generates interface definition information for all modules based on the resource entry list and class name information of all modules, includes: For each module, based on the module's resource entry list, the resource entry information of the module's target resource category is identified, and based on the resource entry information of the module's target resource category, it is determined whether the resource entry information contains the target character; the resource entry list includes resource entry information of multiple resource categories; For each module, when it is determined that the resource entry information does not contain the target character, the module's interface definition information is generated based on the resource entry information and the module's class name information; when it is determined that the resource entry information contains the target character, the definition processing character corresponding to the target character is determined, and the module's interface definition information is generated based on the definition processing character, the resource entry information, and the module's class name information.
[0073] In this optional embodiment, for example, the following processing procedure can be understood: For each non-empty resource category, a TypeScript interface definition is automatically generated.
[0074] Naming convention: I + class name + resource category (first letter capitalized).
[0075] Interface member generation rules: The name of each resource entry is used as the interface member name, and the member type is unified as the platform resource reference type Resource; If the resource name conforms to the identifier specification (composed of letters, numbers, underscores, and $, and does not start with a number), it can be used directly as the attribute name; If the resource name contains special characters (such as -, .), it will be automatically enclosed in quotation marks (e.g., 'my-icon': Resource). Example of generation: Input resource entry: [{name: "primary"}, {name: "text_color"}], class name TR, category color Output interface: interface ITRColor { primary: Resource text_color: Resource } It's important to note that this step is to meet the compilation constraints of statically typed, strongly typed declarative UI languages—these languages require that every object literal correspond to an explicitly declared class or interface, and do not allow anonymous object literals. Automatic interface inference avoids the workload of manually writing interface definitions, and the interface definition always remains consistent with the actual resources.
[0076] As can be seen, this optional embodiment can determine whether the resource entry information of the target resource category of the module contains the target character; if so, it directly generates the interface definition information of the module based on the resource entry information and the class name information of the module; if not, it determines the definition processing character corresponding to the target character, and generates the interface definition information of the module based on the definition processing character, the resource entry information, and the class name information of the module. This reduces the workload of manually writing interface definitions, reduces the occurrence of human errors, and thus improves development efficiency. At the same time, since the interface definition is dynamically generated based on actual resources, it can always maintain a high degree of consistency with the actual resources, effectively satisfying the compilation constraints of statically typed declarative UI languages, thereby providing a solid guarantee for the stable operation and efficient maintenance of modular applications.
[0077] Example 3 Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a resource layering mapping device for modular applications disclosed in an embodiment of the present invention. Figure 3 As shown, this device is applied to a terminal device equipped with modular applications, and the terminal device is capable of communicating with a network-attached storage device. This resource tiering mapping device for modular applications may include: Module 301 is used to determine the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed. The scanning module 302 is used to perform resource scanning operations on all modules based on the resource directory path information of all modules, and obtain a list of resource entries for all modules. The generation module 303 is used to generate class name information for all modules based on the role classification flag information of all modules, and to generate interface definition information for all modules based on the resource entry list and class name information of all modules. The mapping module 304 is used to perform target mapping operations on all modules based on the resource entry list, class name information, and interface definition information of all modules, so as to obtain the source code file of the modular application.
[0078] In this embodiment of the invention, the basic information of each module includes at least the role classification information of that module; the source code file is used for hierarchical mapping of resource references in modular applications.
[0079] It is evident that implementation Figure 3 The described resource layering mapping device for modular applications can generate class name information for each module based on the role classification information of each module in the modular application. Then, combined with the resource entry list of each module obtained from resource scanning, it generates interface definition information for each module. Based on the resource entry list, class name information, and interface definition information of each module, it performs target mapping operation on each module to obtain the source code file of the modular application. In this way, resource management can have layering capabilities, which is conducive to improving the efficiency and accuracy of application resource management, thereby facilitating the smooth development of modular applications.
[0080] In an optional embodiment, the determining module 301 is further configured to: Determine the file path corresponding to the source code file of the modular application; The device also includes: The first judgment module 305 is used to determine whether there is a similar code file in the file path that is similar to the source code file; The writing module 306 is used to write the source code file to the file path when the first judgment module 305 determines that there is no similar code file in the file path; The determining module 301 is also used to determine the degree of similarity between the source code file and the similar code file when the first determining module 305 determines that there is a similar code file in the file path; The first judgment module 305 is also used to determine whether the similarity is less than or equal to a preset similarity threshold. The writing module 306 is also used to overwrite the similar code file with the source code file and write it to the file path when the first judgment module 305 determines that the similarity is less than or equal to the similarity threshold; and to skip the operation of writing the source code file to the file path when the first judgment module 305 determines that the similarity is greater than the similarity threshold.
[0081] It is evident that implementation Figure 4The described resource layering mapping device for modular applications can write source code files to the file path when similar code files do not exist or the similarity between similar code files and source code files is small; conversely, when the similarity between similar code files and source code files is large, there is no need to write the source code files. This improves the efficiency of writing source code files and reduces the compilation overhead related to resource mapping to zero or even zero. This, in turn, improves the development efficiency of modular applications and reduces unnecessary system resource consumption, thus strongly promoting the smooth development and continuous optimization of modular applications.
[0082] In another alternative embodiment, the device further includes: The second judgment module 307 is used to determine, for each module, whether a listener has been registered based on the module's resource directory path information and through a preset global registry. The determination module 301 is also used to determine the listening requirement parameters of module 301 for each module when the determination module determines that the module has not registered a listener. Registration module 308 is used to register the module's listener to the global registry according to the listening requirement parameters.
[0083] In this optional embodiment, the listening requirement parameters include at least one of the following: listening debouncing callback parameters, listening configuration parameters, and listening event type parameters.
[0084] It is evident that implementation Figure 4 The described resource layering mapping device for modular applications can register a module's listener in the global registry based on the module's listening requirement parameters when it is determined that the module has not registered a listener. This improves the accuracy and efficiency of module listener registration, and automatically starts file listening during the build phase without requiring manual triggering of the build. It also ensures consistency by sharing the same generation engine with the build artifacts, thereby enhancing the user's application development experience.
[0085] In yet another optional embodiment, the method by which the determining module 301 determines the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed specifically includes: Read the original text content from the build configuration file of the modular application to be processed, and perform fault-tolerant preprocessing on the original text content to obtain the processed text content of the modular application. The processed text content is parsed to obtain the parsed text of the modular application, and the basic array information in the parsed text is extracted. Based on the basic array information, determine the basic information of all modules in the modular application.
[0086] In this optional embodiment, the fault-tolerant preprocessing operation includes at least one of a single-line comment removal operation, a multi-line comment removal operation, and a target symbol removal operation.
[0087] It is evident that implementation Figure 4 The described resource layering mapping device for modular applications can perform flexible, fault-tolerant preprocessing on the original text content to obtain the processed text content of the modular application. Then, the processed text content is parsed, and basic array information is extracted to determine the basic information of all modules in the modular application. This allows resource references to be upgraded from string literals to type-constrained constant attributes, immediately reporting errors when spelling errors or references to deleted resources occur during the compilation phase, without waiting until application runtime. Compared to existing technologies, where defects in string literal references require a complete chain of "encoding → compilation → packaging → installation → running → reproduction" to be discovered, this invention moves the defect exposure stage forward, reducing defect repair costs by an order of magnitude.
[0088] In yet another optional embodiment, the resource scanning operation includes at least one of a declarative resource scanning operation, a file-based resource scanning operation, and a raw file resource scanning operation; Specifically, the scanning module 302 performs a resource scan on all modules based on the resource directory path information of all modules to obtain a list of resource entries for all modules. Based on the resource directory path information of all modules, read the structured data files of all modules, and extract the target array information of all modules based on the structured data files of all modules; Perform target element traversal on the target array information of all modules to obtain the declarative resource scan fields of all modules, and generate a list of resource entries for all modules based on the declarative resource scan fields of all modules; and / or, Based on the resource directory path information of all modules, read the first directory file of all modules, and filter the first directory file of all modules according to the preset first file filtering conditions to obtain the first filtered file of all modules. The filenames of all filtered files from all modules are processed by removing file extensions to obtain the file-based resource scan fields for all modules. Based on these fields, a list of resource entries for all modules is generated; and / or, Based on the resource directory path information of all modules, read the second directory files of all modules, and filter the second directory files of all modules according to the preset second file filtering conditions to obtain the second filtered files of all modules; Based on the complete filenames of the second filtered files of all modules, determine the original file resource scan fields of all modules, and generate a list of resource entries for all modules based on the original file resource scan fields of all modules.
[0089] It is evident that implementation Figure 4 The described resource hierarchical mapping device for modular applications can comprehensively process the resource directory path information of all modules, employing one or more of declarative resource scanning, file-based resource scanning, and raw file resource scanning, executing resource scanning operations in parallel or sequentially. This improves the accuracy of obtaining the resource entry list for each module and eliminates the need for subsequent interface derivation and code generation pipelines to consider differences in the original storage format of resources, greatly simplifying the processing flow, improving system compatibility and scalability, and thus contributing to improved efficiency and quality in modular application development.
[0090] In another optional embodiment, the generation module 303 generates class name information for all modules based on the role classification flag information of all modules in the following specific ways: Based on the role classification information of all modules, determine the module type corresponding to each module; For each module, when the module type is a topic module, the module's class name is determined as the first class name; when the module type is a business module, the module's class name is determined as the second class name.
[0091] In this optional embodiment, when any business module needs to use the module resources within the corresponding topic module, the business module directly references the module resources under the first type of the topic module.
[0092] It is evident that implementation Figure 4 The described resource hierarchical mapping device for modular applications can determine the corresponding module type based on the role classification information of each module, and generate distinctive class names for both thematic modules and business modules. This achieves clear and effective isolation and management of thematic resources and business resources, and allows direct referencing of resources under class names exported by thematic modules through module dependency mechanisms. This reduces the occurrence of copying thematic resource entries within a single module, ensuring the uniqueness of public resource mapping globally, eliminating multiple copies, significantly reducing resource redundancy, and lowering code size and maintenance costs. Furthermore, when thematic resources change, only one file corresponding to the thematic module needs to be regenerated, ensuring that related files in business modules are unaffected. This greatly improves system stability and maintainability, effectively guaranteeing the efficiency and reliability of modular application development.
[0093] In another optional embodiment, the generation module 303 generates the interface definition information of all modules based on the resource entry list and class name information of all modules in the following specific ways: For each module, based on the module's resource entry list, the resource entry information of the module's target resource category is identified, and based on the resource entry information of the module's target resource category, it is determined whether the resource entry information contains the target character; the resource entry list includes resource entry information of multiple resource categories; For each module, when it is determined that the resource entry information does not contain the target character, the module's interface definition information is generated based on the resource entry information and the module's class name information; when it is determined that the resource entry information contains the target character, the definition processing character corresponding to the target character is determined, and the module's interface definition information is generated based on the definition processing character, the resource entry information, and the module's class name information.
[0094] It is evident that implementation Figure 4 The described resource layering mapping device for modular applications can determine whether the resource entry information of the target resource category of a module contains a target character. If so, it directly generates the module's interface definition information based on the resource entry information and the module's class name information. If not, it determines the definition processing character corresponding to the target character and generates the module's interface definition information based on the definition processing character, resource entry information, and the module's class name information. This reduces the workload of manually writing interface definitions, reduces the occurrence of human errors, and thus improves development efficiency. At the same time, since the interface definition is dynamically generated based on actual resources, it can always maintain a high degree of consistency with actual resources, effectively satisfying the compilation constraints of statically typed declarative UI languages, thereby providing a solid guarantee for the stable operation and efficient maintenance of modular applications.
[0095] Example 4 Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a terminal device disclosed in an embodiment of the present invention. Figure 5 As shown, the terminal device may include: Memory 401 storing executable program code; Processor 402 coupled to memory 401; The processor 402 calls the executable program code stored in the memory 401 to execute the steps in the resource layering mapping method for modular applications described in Embodiment 1 or Embodiment 2 of the present invention.
[0096] Example 5 This invention discloses a computer storage medium storing computer instructions, which, when invoked, are used to execute the steps in the resource layering mapping method for modular applications described in Embodiment 1 or Embodiment 2 of this invention.
[0097] Example 6 This invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform the steps in the resource layering mapping method for modular applications described in Embodiment 1 or Embodiment 2.
[0098] Example 7 Please see Figure 6 , Figure 6 This invention discloses a resource layering mapping system for modular applications. The system includes a resource layering mapping device 501 for modular applications disclosed in Embodiment 3 of this invention, and a network-attached storage device 502 communicatively connected to the device 501; or, the system includes a terminal device 501 disclosed in Embodiment 4 of this invention, and a network-attached storage device 502 communicatively connected to the terminal device 501.
[0099] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0100] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.
[0101] Finally, it should be noted that the resource layering mapping method, apparatus, and system for modular applications disclosed in the embodiments of the present invention are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A resource layering mapping method for modular applications, the method being applied to a terminal device on which the modular application is installed, and the terminal device being capable of communicating with a network-attached storage device, characterized in that, The method includes: Based on the build configuration file of the modular application to be processed, determine the basic information of all modules of the modular application; the basic information of each module includes at least the role classification information of that module; Based on the resource directory path information of all the modules, a resource scan operation is performed on all the modules to obtain a list of resource entries for all the modules; Based on the role classification flag information of all the modules, generate the class name information of all the modules, and based on the resource entry list and class name information of all the modules, generate the interface definition information of all the modules. Based on the resource entry list, class name information, and interface definition information of all modules, a target mapping operation is performed on all modules to obtain the source code file of the modular application; the source code file is used to perform hierarchical mapping operation of resource references on the modular application.
2. The resource layering mapping method for modular applications according to claim 1, characterized in that, The step of determining the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed includes: The original text content in the build configuration file of the modular application to be processed is read, and the original text content is subjected to fault-tolerant preprocessing operation to obtain the processed text content of the modular application; the fault-tolerant preprocessing operation includes at least one of single-line comment removal operation, multi-line comment removal operation and target symbol removal operation. The processed text content is parsed to obtain the parsed text of the modular application, and the basic array information in the parsed text is extracted. Based on the basic array information, determine the basic information of all modules of the modular application.
3. The resource layering mapping method for modular applications according to claim 2, characterized in that, The resource scanning operation includes at least one of the following: declarative resource scanning operation, file-based resource scanning operation, and raw file resource scanning operation. The step of performing a resource scan on all modules based on their resource directory path information to obtain a list of resource entries for all modules includes: Based on the resource directory path information of all the modules, read the structured data files of all the modules, and extract the target array information of all the modules based on the structured data files of all the modules; Perform target element traversal on the target array information of all the modules to obtain the declarative resource scan fields of all the modules, and generate a resource entry list for all the modules based on the declarative resource scan fields of all the modules; and / or, Based on the resource directory path information of all the modules, read the first directory file of all the modules, and filter the first directory file of all the modules according to the preset first file filtering conditions to obtain the first filtered file of all the modules; The filenames of all the first-filtered files of all the modules are subjected to file extension removal to obtain the file-based resource scan fields of all the modules, and a list of resource entries for all the modules is generated based on the file-based resource scan fields of all the modules; and / or, Based on the resource directory path information of all the modules, read the second directory files of all the modules, and filter the second directory files of all the modules according to the preset second file filtering conditions to obtain the second filtered files of all the modules; Based on the complete filenames of the second filtered files of all the modules, determine the original file resource scan fields of all the modules, and generate a list of resource entries for all the modules based on the original file resource scan fields of all the modules.
4. The resource layering mapping method for modular applications according to claim 3, characterized in that, The step of generating class name information for all modules based on their role classification identifiers includes: Based on the role classification flag information of all the modules, determine the module type corresponding to all the modules; For each module, when the module type corresponding to the module is a topic module, the class name information of the module is determined as the first class name; when the module type corresponding to the module is a business module, the class name information of the module is determined as the second class name. Wherein, when any of the business modules needs to use the module resources within the corresponding theme module, the business module directly references the module resources under the first category name of the theme module.
5. The resource layering mapping method for modular applications according to claim 4, characterized in that, The step of generating interface definition information for all modules based on the resource entry list and class name information of all modules includes: For each module, based on the resource entry list of the module, the resource entry information of the target resource category of the module is identified, and based on the resource entry information of the target resource category of the module, it is determined whether the resource entry information contains the target character; the resource entry list includes resource entry information of multiple resource categories; For each module, when it is determined that the resource entry information does not contain the target character, the interface definition information of the module is generated based on the resource entry information and the class name information of the module; when it is determined that the resource entry information contains the target character, the definition processing character corresponding to the target character is determined, and the interface definition information of the module is generated based on the definition processing character, the resource entry information and the class name information of the module.
6. The resource layering mapping method for modular applications according to any one of claims 1-5, characterized in that, The method further includes: Determine the file path corresponding to the source code file of the modular application, and determine whether there are similar code files in the file path that are similar to the source code file; When it is determined that the similar code file does not exist in the file path, the source code file is written to the file path; When it is determined that a similar code file exists in the file path, the degree of similarity between the source code file and the similar code file is determined, and it is determined whether the degree of similarity is less than or equal to a preset similarity threshold. When it is determined that the similarity is less than or equal to the similarity threshold, the source code file overwrites the similar code file and is written to the file path; When the similarity is determined to be greater than the similarity threshold, the operation of writing the source code file to the file path is skipped.
7. The resource layering mapping method for modular applications according to any one of claims 1-5, characterized in that, The method further includes: For each module, based on the module's resource directory path information and through a preset global registry, it is determined whether the module has registered a listener. For each module, when it is determined that the module has not registered the listener, the listening requirement parameters of the module are determined, and the listener of the module is registered in the global registry according to the listening requirement parameters; the listening requirement parameters include at least one of the following: listening debouncing callback parameters, listening configuration parameters, and listening event type parameters.
8. A resource hierarchical mapping device for modular applications, the device being applied to a terminal device on which the modular application is installed, and the terminal device being communicatively connected to a network-attached storage device, characterized in that, The device includes: A determination module is used to determine the basic information of all modules of the modular application based on the build configuration file of the modular application to be processed; the basic information of each module includes at least the role classification information of that module; The scanning module is used to perform a resource scanning operation on all the modules based on the resource directory path information of all the modules, and obtain a list of resource entries for all the modules; The generation module is used to generate class name information for all modules based on the role classification flag information of all modules, and to generate interface definition information for all modules based on the resource entry list and class name information of all modules. The mapping module is used to perform target mapping operations on all the modules according to the resource entry list, class name information and interface definition information of all the modules, so as to obtain the source code file of the modular application; the source code file is used to perform hierarchical mapping operations on resource references of the modular application.
9. A terminal device, characterized in that, The terminal device includes: Memory containing executable program code; A processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the resource layering mapping method for modular applications as described in any one of claims 1-7.
10. A computer storage medium, characterized in that, The computer storage medium stores computer instructions, which, when invoked, are used to execute the resource layering mapping method for modular applications as described in any one of claims 1-7.
11. A resource hierarchical mapping system for modular applications, characterized in that, The system includes a resource hierarchical mapping device for modular applications as described in claim 8, and a network-attached storage device communicatively connected to the device; or, The system includes a terminal device as described in claim 9, and a network-attached storage device communicatively connected to the terminal device.