Application file aggregation processing method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses an application file aggregation processing method and device, a storage medium and electronic equipment, and the method comprises the steps: determining a main application file package and a to-be-aggregated application file package for a target application, performing resource definition information analysis on a first resource definition file of a main application file package and a second resource definition file of a to-be-aggregated application file package to obtain a first resource mapping relation and first resource item information for the first resource definition file and second resource item information of the second resource definition file, and based on the first resource mapping relationship, the first resource item information and the second resource item information, carrying out resource identification merging to obtain a target resource definition file of a target application, and performing resource identifier updating on an original resource index file in the to-be-aggregated application file package based on the target resource definition file to obtain an aggregated resource index file.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to an application file aggregation processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] In application package aggregation scenarios, to quickly implement complex functions, developers typically need to integrate multiple third-party software development kits (SDKs), feature plugins, or independent resource packages into the main application file. During this process, to ensure the uniqueness of all resources within the application (such as UI layouts, images, strings, etc.), the system assigns a unique resource identifier (ID) to each resource. These IDs and their definitions are usually recorded in resource definition files (such as the public.xml file).

[0003] However, in existing technologies, different application packages are developed independently, and their internal resource identifiers (IDs) are also generated independently. When these packages are aggregated, a "resource ID conflict" problem easily arises where different resources use the same ID. To resolve this conflict, a manual approach is commonly used, where developers manually compare each resource definition file, modify conflicting IDs one by one, and delve into the compiled code files to find and update all references to the old IDs. This manual approach is not only extremely labor-intensive and inefficient, but also prone to errors due to oversight, leading to resource loading anomalies or even crashes during runtime in the final aggregated application file. This results in poor reliability and severely impacts development efficiency and application stability. Summary of the Invention

[0004] This specification provides an application file aggregation processing method, apparatus, storage medium, and electronic device, the technical solutions of which are as follows:

[0005] Firstly, embodiments of this specification provide an application file aggregation processing method, the method comprising:

[0006] Identify the main application file package and the application file packages to be aggregated for the target application;

[0007] The resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated is parsed to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file.

[0008] Based on the first resource mapping relationship, the first resource item information and the second resource item information, the resource identifiers are merged to obtain the target resource definition file of the target application;

[0009] Based on the target resource definition file, the resource identifier of the original resource index file in the application file package to be aggregated is updated to obtain the aggregated resource index file.

[0010] In one feasible implementation, the step of parsing the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, to obtain the first resource mapping relationship, the first resource item information, and the second resource item information of the second resource definition file for the first resource definition file, includes:

[0011] The first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated are parsed to obtain the first resource item information for the first resource definition file and the second resource item information for the second resource definition file.

[0012] The first resource definition file is parsed to obtain the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier under the first resource type. A first resource mapping relationship is constructed based on the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier.

[0013] In one feasible implementation, the step of merging resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file for the target application includes:

[0014] Based on the first resource mapping relationship and the second resource item information, the conflict identifier is re-updated to obtain the updated first resource mapping relationship and the updated second resource item information;

[0015] Identify the re-update identifier resource item in the second resource item information, merge the re-update identifier resource item into the first resource item information, and generate the merged target resource item information;

[0016] A target resource definition file is generated based on the target resource item information and the first resource mapping relationship.

[0017] In one feasible implementation, the step of re-updating the conflict identifier based on the first resource mapping relationship and the second resource item information to obtain the updated first resource mapping relationship and the updated second resource item information includes:

[0018] Traverse each second resource item in the second resource item information and perform conflict identifier detection on the second resource item based on the first resource mapping relationship;

[0019] If there is a first type of resource item with the same resource type and the same resource name in the first resource mapping relationship, then the first type of resource item is ignored and updated.

[0020] If there is a second type of resource item with the same resource type but a different resource name in the first resource mapping relationship, then a first new resource identifier is generated for the second type of resource item based on the maximum value of the resource identifier of the same resource type, and the identifier of the first type of resource item is updated based on the first new resource identifier;

[0021] If there are third-type resource items with different resource types and names in the first resource mapping relationship, then a second newly added resource identifier is generated for the third-type resource item based on the block identifier of the highest resource type, and the identifier of the second-type resource item is updated based on the second newly added resource identifier.

[0022] In one feasible implementation, generating a first new resource identifier for the second type of resource item based on the maximum value of resource identifiers of the same resource type includes:

[0023] Obtain the maximum value of resource identifiers of the same resource type in the first resource mapping relationship, generate a first new resource identifier based on the maximum value of the resource identifier based on the preset identifier entry offset, and update the first new resource identifier to the maximum value of the resource identifier of the same resource type in the first resource mapping relationship.

[0024] In one feasible implementation, generating a second new resource identifier for the third type of resource item based on the highest resource type block identifier includes:

[0025] Determine the highest resource type block identifier, construct a new identifier segment for the new resource type corresponding to the third type resource item based on the preset identifier block offset and the highest resource type block identifier, assign a second new resource identifier to the third type resource item based on the new identifier segment, and record the second new resource identifier and the new resource type of the third type resource item in the first resource mapping relationship.

[0026] In one feasible implementation, the step of updating the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file includes:

[0027] Identify the original resource index file in the application file package to be aggregated;

[0028] Based on the target resource definition file, a resource index identifier mapping lookup table is determined for the application file package to be aggregated;

[0029] Based on the resource index identifier mapping table, the original resource index file is traversed, and the resource item identifier of the original resource index file is updated.

[0030] Secondly, embodiments of this specification provide an application file aggregation processing apparatus, the apparatus comprising:

[0031] The determination module is used to determine the main application file package and the application file packages to be aggregated for the target application.

[0032] The parsing module is used to parse the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, so as to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file;

[0033] The aggregation module is used to merge resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file of the target application;

[0034] The aggregation module is used to update the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file.

[0035] In one feasible implementation, the step of parsing the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, to obtain the first resource mapping relationship, the first resource item information, and the second resource item information of the second resource definition file for the first resource definition file, includes:

[0036] The first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated are parsed to obtain the first resource item information for the first resource definition file and the second resource item information for the second resource definition file.

[0037] The first resource definition file is parsed to obtain the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier under the first resource type. A first resource mapping relationship is constructed based on the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier.

[0038] In one feasible implementation, the step of merging resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file for the target application includes:

[0039] Based on the first resource mapping relationship and the second resource item information, the conflict identifier is re-updated to obtain the updated first resource mapping relationship and the updated second resource item information;

[0040] Identify the re-update identifier resource item in the second resource item information, merge the re-update identifier resource item into the first resource item information, and generate the merged target resource item information;

[0041] A target resource definition file is generated based on the target resource item information and the first resource mapping relationship.

[0042] In one feasible implementation, the step of re-updating the conflict identifier based on the first resource mapping relationship and the second resource item information to obtain the updated first resource mapping relationship and the updated second resource item information includes:

[0043] Traverse each second resource item in the second resource item information and perform conflict identifier detection on the second resource item based on the first resource mapping relationship;

[0044] If there is a first type of resource item with the same resource type and the same resource name in the first resource mapping relationship, then the first type of resource item is ignored and updated.

[0045] If there is a second type of resource item with the same resource type but a different resource name in the first resource mapping relationship, then a first new resource identifier is generated for the second type of resource item based on the maximum value of the resource identifier of the same resource type, and the identifier of the first type of resource item is updated based on the first new resource identifier;

[0046] If there are third-type resource items with different resource types and names in the first resource mapping relationship, then a second newly added resource identifier is generated for the third-type resource item based on the block identifier of the highest resource type, and the identifier of the second-type resource item is updated based on the second newly added resource identifier.

[0047] In one feasible implementation, generating a first new resource identifier for the second type of resource item based on the maximum value of resource identifiers of the same resource type includes:

[0048] Obtain the maximum value of resource identifiers of the same resource type in the first resource mapping relationship, generate a first new resource identifier based on the maximum value of the resource identifier based on the preset identifier entry offset, and update the first new resource identifier to the maximum value of the resource identifier of the same resource type in the first resource mapping relationship.

[0049] In one feasible implementation, generating a second new resource identifier for the third type of resource item based on the highest resource type block identifier includes:

[0050] Determine the highest resource type block identifier, construct a new identifier segment for the new resource type corresponding to the third type resource item based on the preset identifier block offset and the highest resource type block identifier, assign a second new resource identifier to the third type resource item based on the new identifier segment, and record the second new resource identifier and the new resource type of the third type resource item in the first resource mapping relationship.

[0051] In one feasible implementation, the step of updating the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file includes:

[0052] Identify the original resource index file in the application file package to be aggregated;

[0053] Based on the target resource definition file, a resource index identifier mapping lookup table is determined for the application file package to be aggregated;

[0054] Based on the resource index identifier mapping table, the original resource index file is traversed, and the resource item identifier of the original resource index file is updated.

[0055] Thirdly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0056] Fourthly, embodiments of this specification provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0057] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0058] In one or more embodiments of this specification, the automated process described herein fundamentally solves the problems of inefficiency and high error rates caused by manual operation in the prior art. Through automated resource definition information parsing, precise resource identifier merging, and synchronous updates of the compiled resource index file, the previously labor-intensive and tedious comparison, modification, and verification work is transformed into a highly efficient and accurate automated process that requires no manual intervention. In particular, the automated synchronous updates of the resource index file (smali file) completely eliminate the risk of omissions or errors that are easily caused by manual code modification, thereby ensuring the final consistency between resource definitions and code references, and greatly improving the stability and reliability of the aggregated target application.

[0059] Furthermore, it significantly improves the integration efficiency and engineering level of application packages. Integration work that might have previously taken hours or even days is reduced to minutes or even seconds, significantly lowering development and maintenance costs. More importantly, the end-to-end automation capabilities provided by this solution allow for seamless integration into modern continuous integration / continuous deployment processes, supporting large-scale, repeatable batch aggregation tasks. This not only solves the challenges of single-integration but also optimizes the entire software development and release lifecycle management, giving it scalability and engineering advantages that are completely unmatched by existing manual methods. Attached Figure Description

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

[0061] Figure 1 This is a flowchart illustrating an application file aggregation processing method provided in the embodiments of this specification;

[0062] Figure 2 This is a schematic diagram of a resource definition information parsing and processing method provided in an embodiment of this specification;

[0063] Figure 3 This is a schematic diagram of a resource identifier merging process provided in the embodiments of this specification;

[0064] Figure 4 This is a schematic diagram of a conflict identifier re-update process provided in the embodiments of this specification;

[0065] Figure 5 This is a schematic diagram of a resource index update process provided in the embodiments of this specification;

[0066] Figure 6 This is a schematic diagram of the structure of an application file aggregation processing device provided in the embodiments of this specification;

[0067] Figure 7 This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification;

[0068] Figure 8 This is a schematic diagram of the operating system and user space structure provided in the embodiments of this specification;

[0069] Figure 9 yes Figure 8 Architecture diagram of the Android operating system in China;

[0070] Figure 10 yes Figure 8 Architecture diagram of the iOS operating system. Detailed Implementation

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

[0072] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device 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 devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0073] The present specification will now be described in detail with reference to specific embodiments.

[0074] In one embodiment, such as Figure 1As shown, an application file aggregation processing method is proposed. This method can be implemented using a computer program and can run on an application file aggregation processing device based on the von Neumann architecture. This computer program can be integrated into an application or run as a standalone utility application. The application file aggregation processing device can be an electronic device, including but not limited to: personal computers, tablets, handheld devices, in-vehicle devices, wearable devices, computing devices, or other processing devices connected to a wireless modem. Terminal devices can be called by different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user equipment, cellular phone, cordless phone, device in a 5G network or future evolved network, etc.

[0075] Specifically, the application's file aggregation processing method includes:

[0076] S102: Determine the main application file package and the application file package to be aggregated for the target application;

[0077] Main application package: This package is the foundation and carrier of this aggregation process, also known as the "first application file". It is usually a relatively complete application entity corresponding to the target application, such as a compiled Android Application Package (APK), or a project directory containing its complete source code, resource files, and configuration files. During the aggregation process, the resources and functions of other packages will be incorporated into this main application package.

[0078] Application package to be integrated: This package is one or more external functional or resource modules that need to be integrated into the main application package. It can take the form of a third-party software development kit (SDK), a standalone functional plugin, a pure resource pack, or any other form of application module containing independent resource definitions.

[0079] Target application: At least the application corresponding to the main application package.

[0080] In a specific embodiment, the process of executing step S102 can be referred to as follows:

[0081] First, the "application file aggregation processing method" can be initiated manually or automatically. As the entry point and data preparation stage of this method, this step aims to establish a clear operational object and initial context for all subsequent automated processing flows.

[0082] Secondly, when the aggregation process starts, the "input reception and object establishment" logic is executed. The system receives the path information of the two independent application file packages from the outside, which specifies the two independent application file packages. Based on this information, the system establishes the two file packages as follows: one is the "main application file package" which serves as the basis for aggregation and the target of merging, and the other is the "application file package to be aggregated" which needs to be integrated into the main application file package.

[0083] Optionally, after identifying the processing target, a "validity verification" step can be performed to verify the received path information, ensuring that the paths of the "main application file package" and the "application file package to be aggregated" are valid, the target files or directories exist, and the system has the necessary permissions to perform subsequent read and write operations on these files. This verification aims to ensure the stability and reliability of the entire aggregation process.

[0084] S104: Parse the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file;

[0085] Resource definition file: This refers to a specific file in the application package used to declare resources and their corresponding unique identifiers (IDs). In the Android development ecosystem, this usually refers to the res / values / public.xml file, which explicitly lists the type, name, and ID value of each public resource in Extensible Markup Language (XML) format.

[0086] Resource definition information parsing: refers to the process by which the processing system reads and analyzes the contents of the resource definition file, and systematically extracts the key information of each resource entry according to its inherent syntactic structure.

[0087] The first resource mapping relationship: This is the content of the resource files in the root main application package, a structured data collection created in memory, such as a hash table or nested dictionary. Its core function is to provide an efficient query benchmark for subsequent conflict detection. This data structure is usually indexed by the resource type (type) and stores a list of names of all resources under that type (nameList) and the currently known maximum resource ID value (maxId).

[0088] First / Second Resource Item Information: This refers to the data object formed after the entire content of the first and second resource definition files is parsed into memory, preserving the original file hierarchy structure. It is an XML Document Object Model (DOM) tree or ElementTree. This data object not only contains the attribute information of all resource items but also allows the program to directly modify it in memory (such as updating IDs) and perform structural operations (such as adding new nodes). It is the direct object for subsequent merging and file generation.

[0089] In a specific embodiment, the process of executing step S104 can be referred to as follows:

[0090] First, valid references to the "main application file package" and the "application file package to be aggregated" have been obtained. The unstructured resource definition information based on physical files in these two file packages is transformed into structured memory data objects that are easy for the program to analyze, compare and modify automatically.

[0091] Secondly, upon receiving the "processing context" transmitted by S102, the system executes the "resource definition information parsing" logic, locates and reads the first resource definition file in the "main application file package" and the second resource definition file in the "application file package to be aggregated", and traverses all resource definition elements in each file, and performs an "attribute extraction" operation on each element to obtain key information such as "resource type", "resource name" and "resource identifier (ID)".

[0092] Secondly, while extracting information, a "data structure construction" process is performed, which generates two types of in-memory data objects for different purposes: one is the "first resource mapping relationship" constructed only for the first resource definition file. It is an efficient key-value query structure that stores a list of resource names and maximum ID values ​​under the resource type as an index, providing a benchmark for subsequent conflict detection; the other is the "first resource item information" and "second resource item information" constructed for the first and second resource definition files respectively. These are tree-like data objects that retain the complete hierarchical structure of the original files, allowing subsequent steps to directly modify them in memory.

[0093] Finally, after both resource definition files have been fully parsed and converted into corresponding memory data objects, the final output is a structured data set containing "first resource mapping relationship," "first resource item information," and "second resource item information." This set will be passed as a whole to the subsequent step S106 for performing the core resource identifier merging and reallocation processing.

[0094] S106: Based on the first resource mapping relationship, the first resource item information and the second resource item information, the resource identifiers are merged to obtain the target resource definition file of the target application;

[0095] Resource ID merging: This term does not refer to simple file content concatenation, but rather a complex and intelligent processing flow that includes conflict detection, ID reallocation, node merging, and verification. Its goal is to generate a logically correct, aggregated set of resource definitions where all IDs are unique.

[0096] First, this step assumes that the previous step S104 has been successfully completed, and the system has converted the two resource definition files into structured memory data objects, namely "first resource mapping relationship," "first resource item information," and "second resource item information." This step is the core of the entire method and is executed by a "merging module." Its purpose is to intelligently resolve resource conflicts and generate a unified, conflict-free target resource definition file.

[0097] Secondly, upon receiving the data object transmitted by S104, the merging module executes the "conflict detection and ID reallocation" logic. It traverses each resource item in the "second resource item information" (the memory tree of the package to be merged) and uses the "first resource mapping relationship" (the resource map of the main application package) for comparison and decision-making.

[0098] 1. If a resource item to be processed already exists in the "first resource mapping relationship" in terms of its type and name, the system will determine that it is a conflicting resource and ignore it to ensure that the resource definition of the main application package takes priority.

[0099] 2. If a resource item is a new, non-conflicting resource, the system will assign it a brand-new, globally unique resource identifier (ID). The allocation strategy is as follows: if the resource type already exists, the maximum ID of that type in the "First Resource Mapping Relationship" will be incremented by 1; if the resource type is new, a completely new ID range will be allocated for it using bitwise operations. After allocation, the new ID will be directly updated to the corresponding node in the "Second Resource Item Information," and the "First Resource Mapping Relationship" will also be updated in real time to include the information of this new resource.

[0100] Next, after completing the ID reallocation of all pending resource items, the system executes the "Resource Item Information Merging" sub-step. This process, based on the "First Resource Item Information" (the memory tree of the main application package), appends one by one all resource item nodes in the "Second Resource Item Information" that have been identified as new and updated with the new IDs to the memory tree of the "First Resource Item Information." After this operation, the "First Resource Item Information" logically becomes a complete set of "Target Resource Item Information" containing all non-conflicting resources from both packages.

[0101] Optionally, before generating the final file, the system may perform a "uniqueness check." It traverses the merged "target resource item information" memory tree, using the characteristics of a Set data structure to check for duplicate IDs, ensuring the absolute correctness of the final product. After the check passes, the system serializes the memory tree, generating and outputting a "target resource definition file." This file will be passed to the subsequent step S108 as the final basis for updating code references.

[0102] S108: Based on the target resource definition file, update the resource identifier of the original resource index file in the application file package to be aggregated to obtain the aggregated resource index file.

[0103] The original resource index file refers to the unmodified code file in the "application file package to be aggregated" that contains hard-coded references to old resource IDs. In the Android development environment, this typically refers to the smali file (e.g., R$string.smali) corresponding to R.java (the resource index file) after compilation.

[0104] Aggregated resource index file: refers to the file or collection of files obtained after the "original resource index file" has been processed in this step, and all the old resource ID references in it have been updated to new IDs that are consistent with the "target resource definition file".

[0105] In a specific embodiment, the process of executing step S108 can be referred to as follows:

[0106] First, the previous step S106 successfully generated a unified "target resource definition file" containing all non-conflicting resources. This step is the closed-loop link in the entire automated process and is executed synchronously. Its core purpose is to ensure that the internal code logic of the "application file package to be aggregated" can correctly reference the resources that have been reassigned with new IDs during the merging process.

[0107] Secondly, upon receiving the target resource definition file generated by S106, the "final ID mapping table construction" logic is executed synchronously. This authoritative, final resource definition file is parsed, and a structured ID mapping table for efficient querying is created. Optionally, the key of this mapping table consists of the resource's "type" and "name," while the value is the globally unique resource identifier (ID) that is finally determined in the target resource definition file.

[0108] Next, after constructing the final ID mapping table, the system performs a "code file identifier update," at which point it locates and iterates through all the "raw resource index files" in the "application file package to be aggregated." For each file, the module reads its content line by line and uses preset matching rules (e.g., a precise regular expression) to find the specific line of code that defines the resource ID. Once a match is found, the "name" of the resource is extracted from that line of code. Then, using the final ID mapping table constructed in the previous step, the new ID corresponding to that resource name is retrieved, and this new ID value precisely replaces the original, old ID value in the line of code.

[0109] Finally, once all relevant original resource index files have undergone the above lookup and replace process, and all hard-coded references to the old resource IDs within them have been updated to the new IDs, this step is complete. The final output is the "aggregated resource index file." This output is actually a collection of the original files, but its contents have been safely modified to ensure that the code logic and resource definitions remain completely synchronized and consistent in the aggregated target application, thus avoiding runtime errors caused by ID mismatches.

[0110] In the embodiments described herein, the automated process fundamentally solves the problems of low efficiency and high error rate caused by manual operation in the prior art. Through automated resource definition information parsing, precise resource identifier merging, and synchronous updates of the compiled resource index file, the previously labor-intensive and tedious comparison, modification, and verification work is transformed into a highly efficient and accurate automated process that requires no manual intervention. In particular, the automated synchronous updates of the resource index file (smali file) completely eliminate the risk of omissions or errors that are easily caused by manual code modification, thereby ensuring the final consistency between resource definitions and code references, and greatly improving the stability and reliability of the aggregated target application.

[0111] Furthermore, it significantly improves the integration efficiency and engineering level of application packages. Integration work that might have previously taken hours or even days is reduced to minutes or even seconds, significantly lowering development and maintenance costs. More importantly, the end-to-end automation capabilities provided by this solution allow for seamless integration into modern continuous integration / continuous deployment processes, supporting large-scale, repeatable batch aggregation tasks. This not only solves the challenges of single-integration but also optimizes the entire software development and release lifecycle management, giving it scalability and engineering advantages that are completely unmatched by existing manual methods.

[0112] Optional, please see Figure 2 , Figure 2This is a flowchart illustrating a resource definition information parsing process proposed in this specification. Specifically, the process of parsing the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, to obtain the first resource mapping relationship and first resource item information for the first resource definition file, and the second resource item information for the second resource definition file, can be performed as follows:

[0113] S202: Perform resource file item parsing on the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated to obtain the first resource item information for the first resource definition file and the second resource item information for the second resource definition file;

[0114] Resource file item parsing: refers to an automated process that reads a text-based file with a specific syntactic structure (such as XML) and transforms its contents into a hierarchical data structure that a program can understand and manipulate in memory.

[0115] First / Second Resource Item Information: This refers to the structured data copy formed in computer memory after the first and second resource definition files have undergone the above parsing process. It is not just simple text content, but a tree-like object model (such as a DOM tree) that can be traversed, queried, and modified by programs, completely representing the structure and data of the original file.

[0116] In a specific embodiment, the following approach can be referenced:

[0117] First, the previous step S102 has been successfully completed, and valid paths to the first and second resource definition files in the "main application file package" and the "application file package to be aggregated" have been obtained. The core task of this step is to load these two physical files completely and structurally into the system memory, forming object entities that can be directly manipulated by the program, thus preparing for subsequent deep analysis and information extraction.

[0118] Secondly, upon receiving the file path, the system executes the "resource file item parsing" logic for both the first and second resource definition files. This logic typically involves a standard XML (Extensible Markup Language) parser, which can read the entire text content of the file and, strictly following the syntax and hierarchical structure of XML, construct a tree-like data model in memory that completely corresponds to the original file's content and structure.

[0119] Secondly, during the construction of the memory model, every XML tag in the file, such as <public>The file, along with all its attributes such as type, name, and id, is transformed into corresponding nodes and attributes in the memory model. This process is lossless, ensuring that all information in the original file is completely preserved so that subsequent steps can access or modify any part.

[0120] Finally, this step is complete once the file parsing unit has finished processing the two files. Its final output consists of two independent, in-memory objects that retain all the original file information: "First Resource Item Information" and "Second Resource Item Information." These two objects (e.g., an XML element tree) form the basis for all subsequent in-memory modification, comparison, and merging operations and are passed to the next step, S204, from which the "First Resource Mapping Relationship" for conflict detection is extracted.

[0121] S204: Parse the resource items in the first resource definition file to obtain the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier under the first resource type. Construct a first resource mapping relationship based on the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier.

[0122] Resource item parsing (in this step): refers to the process of traversing, analyzing, and extracting information from the memory data objects (not physical files) generated by S202. Its purpose is to further extract data from the structured memory tree for constructing specific lookup tables (i.e., mapping relationships).

[0123] First Resource Mapping: This is an in-memory data structure (such as a hash table or nested dictionary) specifically built for fast lookup in the first resource definition file (main application package). It uses the resource type as the key, and its value typically contains two parts of information: a list of names of all resources under that type, and the maximum value among all resource IDs under that type.

[0124] In a specific embodiment, the process of executing step S204 can be referred to as follows:

[0125] First, the previous step S202 has been successfully completed, and the system has obtained the "first resource item information" (i.e., the tree-like data object of the resource definition file of the main application file package in memory). The core task of this step is to further refine and organize a baseline data structure for subsequent efficient querying and conflict detection, namely the "first resource mapping relationship," based on parsing this memory object.

[0126] Secondly, upon receiving the "first resource item information," the system systematically executes the "resource item deep parsing and information organization" logic. It traverses every resource definition element in the "first resource item information" memory tree. During this traversal, it precisely extracts three basic pieces of information from each element: "first resource type," "first resource name," and "first resource identifier."

[0127] Secondly, while extracting basic information, the system performs a maximum value tracking and update step, maintaining a memory structure indexed by "first resource type". When processing a resource item, it compares its "first resource identifier" value with the "maximum resource identifier value" recorded in the memory structure for the corresponding resource type. If the identifier value of the current resource item is larger, the system updates the record, ensuring that at the end of the traversal, the memory structure stores the actual maximum ID value that has appeared for each resource type.

[0128] Finally, after traversing and processing all resource items in the "First Resource Item Information," this step is complete. Its final output is a detailed and structured "First Resource Mapping Relationship." This data structure not only completely records the types and names of all resources in the main application file package but also accurately stores the current ID limit for each type. This "First Resource Mapping Relationship" will be passed to the subsequent step S106 as the core basis for conflict judgment and new ID allocation.

[0129] In the embodiments of this specification, a highly efficient and intelligent data preprocessing mechanism is implemented through steps S202 and S204. First, through the resource file item parsing in step S202, the unstructured resource definition information, originally based on physical files, is successfully transformed into a structured "resource item information" object that the program can directly access and manipulate in memory. This transformation is a necessary prerequisite for realizing all subsequent automated logical judgments and processing, avoiding repeated and inefficient I / O read and write operations on files.

[0130] Furthermore, in step S204, based on parsing the main application file package, a "first resource mapping relationship" containing the "maximum value of resource identifiers" is constructed with great foresight. This data structure is not merely a simple list of raw information, but an optimized query benchmark specifically designed to serve subsequent conflict detection and ID allocation algorithms. It enables the system to determine the existence of resource conflicts with extremely high efficiency in subsequent steps and to instantly obtain key data for calculating new IDs, thereby significantly improving the performance and intelligence level of the entire aggregation processing flow and laying a solid foundation for the accurate and rapid execution of subsequent steps.

[0131] Optional, please see Figure 3 , Figure 3 This is a flowchart illustrating a resource identifier merging process proposed in this specification. Specifically, the process of merging resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file for the target application can be performed in the following ways:

[0132] S302: Based on the first resource mapping relationship and the second resource item information, perform conflict identifier re-update to obtain the updated first resource mapping relationship and the updated second resource item information;

[0133] Conflicting identifier re-update: A comprehensive process that first identifies which resource identifiers (IDs) will conflict (i.e., resources that need to be ignored), and then recalculates and assigns a globally unique ID to the new resources that do not conflict but need to be integrated.

[0134] Updated First Resource Mapping / Second Resource Item Information: This refers to the new state of the original memory data object after this step. The "Updated First Resource Mapping" includes information on all non-conflicting resources in the main application and the application to be aggregated; while the "Updated Second Resource Item Information" refers to the memory tree of the application package to be aggregated, where the IDs of the resources to be merged have been replaced with newly assigned IDs.

[0135] In one specific embodiment, the process of executing step S302 may include the following sub-steps:

[0136] First, S104 has been successfully completed. The system has obtained the "first resource mapping relationship" as the decision-making basis and the "second resource item information" (the memory tree of the application file package to be aggregated) as the main processing object. This step is the most critical intelligent decision-making and data preprocessing link in the entire merging process. Its fundamental purpose is to resolve all potential resource ID conflicts in advance before performing any actual file merging action, and to assign a secure, globally unique ID to all new resources that need to be accepted.

[0137] Secondly, upon receiving input data, the "conflict detection and ID re-update" logic is executed. This involves iterating through each resource item in the "second resource item information" and comparing and making decisions using the "first resource mapping relationship." The decision-making logic follows these rules:

[0138] For conflicting resource items: If a resource item to be processed has a combination of "resource type" and "resource name" that can be found in the "first resource mapping relationship", then the system determines that it is a conflicting resource. In this case, the module will ignore the resource item, that is, it will not perform any operation and will directly jump to the judgment of the next resource item.

[0139] For newly added resource items: If the resource item does not conflict, the system will generate a completely new resource identifier for it. The specific generation strategy is as follows:

[0140] When a resource type already exists: the system retrieves the currently recorded maximum value of the resource identifier for that type from the "first resource mapping relationship", and adds 1 to it to obtain the new ID.

[0141] When the resource type is brand new: the system will use bitwise operations to calculate and allocate a brand new ID range based on the maximum ID already used for all types, and use the starting value of this range as the new ID.

[0142] Furthermore, after generating a new ID for a newly added resource item, the system immediately performs a "double update" operation to ensure real-time synchronization of data status. On one hand, it modifies the ID attribute of the current resource item node in the "second resource item information" in memory, updating it to the newly generated ID value; on the other hand, it also synchronously updates the "first resource mapping relationship," adding the name and new ID of the newly added resource item, and updating the "maximum value of resource identifier" record for the corresponding resource type.

[0143] Finally, after the ID allocation module has traversed and processed all resource items in the "Second Resource Item Information," this step is complete. Its final output consists of two memory data objects whose content has been safely updated: "Updated First Resource Mapping" and "Updated Second Resource Item Information." At this point, all non-conflicting resources in the "Updated Second Resource Item Information" now carry the correct, final IDs for merging in the next step.

[0144] S304: Determine the re-update identifier resource item in the second resource item information, merge the re-update identifier resource item into the first resource item information, and generate the merged target resource item information;

[0145] Re-updated resource identifiers: These refer to resource items in the "Application File Package to be Aggregated" resource set that, after the conflict detection in step S302, were determined to be non-conflicting and reassigned with new resource identifiers (IDs). These are the valid resources that ultimately need to be merged into the main application file package.

[0146] Target resource item information: This refers to a unified, aggregated memory data object formed after the "first resource item information" (the memory tree of the main application file package) has incorporated all "re-updated identifier resource items." It represents the content and structure of the final "target resource definition file" before its generation.

[0147] In one specific embodiment, the process of executing step S304 may include the following sub-steps:

[0148] First, the previous step S302 has been successfully completed. The system now has an "updated second resource item information," in which all resource items to be integrated have been assigned new, conflict-free resource identifiers (IDs). The core task of this step is to physically (in memory) merge these securely processed resource items into the resource structure of the main application file package, forming a unified resource set.

[0149] Secondly, upon receiving the processing result from S302, the system executes the "resource item determination and merging" logic. This unit traverses the "updated second resource item information" (i.e., the memory tree of the package to be aggregated). During this process, it determines which "re-updated identifier resource items" need to be merged. In an optional implementation, all resource items that were not "ignored" in stage S302 are considered "re-updated identifier resource items".

[0150] Secondly, for each node identified as a "re-updated identifier resource item," the node merging unit performs a "structured append" operation. It appends this resource item node (containing the updated ID and all other attributes) as a complete, independent element to the root node of the "first resource item information" (i.e., the memory tree of the main application package). This operation is a structured addition that safely expands the content of the "first resource item information" without altering its original structure.

[0151] Finally, once all the "re-updated identifier resource items" in the "updated second resource item information" have been successfully appended to the "first resource item information," this step is complete. At this point, the "first resource item information" has logically evolved into a complete "target resource item information" containing all non-conflicting resources of the main application and the application to be aggregated. This merged memory tree object is the direct blueprint for generating the final physical file and is passed to the subsequent step S306.

[0152] S306: Generate a target resource definition file based on the target resource item information and the first resource mapping relationship.

[0153] Generating a target resource definition file: This refers to the process of converting processed, merged, and verified structured data objects (target resource item information) in memory into a text file that conforms to a specific file format (such as XML) and can be physically stored and read.

[0154] In one specific embodiment, the process of executing step S306 may include the following sub-steps:

[0155] First, the previous step S304 has been successfully completed, and the system has built a unified "target resource item information" (i.e., the merged memory tree) in memory that contains all non-conflicting resources. This step is the final stage of the entire resource identifier merging process, and its core task is to persistently write the final result in memory to a physical file to form the final deliverable.

[0156] Secondly, upon receiving the "target resource item information" transmitted by S304, an optional "final integrity and uniqueness check" sub-step can be executed to enhance stability. This check logic iterates through all resource nodes in the "target resource item information" and reconfirms that all resource identifiers (IDs) are globally unique. This serves as a safeguard to prevent any unexpected errors during the S304 memory merging process, ensuring that the final generated file content is absolutely correct.

[0157] Next, after successful verification, the system executes the "file serialization and writing" logic, which calls a standard XML (Extensible Markup Language) writer or serialization tool. This tool receives "target resource item information" (memory tree) as input and converts it into a formatted text string strictly according to XML syntax. Subsequently, the system writes the content of this text string to the user-specified output path, thereby creating a new physical file.

[0158] Finally, once the file is successfully written to disk, this step is complete. The final output is a brand new, complete "Target Resource Definition File" with conflict-free IDs. This "Target Resource Definition File" is the final product of step S106 and will serve as the direct basis and authoritative data source for subsequent steps such as step S108, which involves synchronizing and updating code files.

[0159] This specification describes a highly intelligent and reliable resource identifier merging mechanism implemented through steps S302 to S306. Step S302, "conflicting identifier re-update," is the core of the entire merging process. Through precise resource classification (conflicting, newly added but existing types, entirely new types) and differentiated ID allocation strategies, it ensures that every resource to be integrated receives an absolutely secure and globally unique identifier. This proactive, rule-based preprocessing method fundamentally eliminates the risk of ID conflicts introduced by blind merging, guaranteeing the accuracy of the merging results.

[0160] Building upon this, steps S304 and S306 together ensure the robustness of the entire merging process and the reliability of the final product. By first performing a structural node merging in memory (S304), and then persisting the fully verified final memory object as a physical file (S306), this invention completely separates data processing from file generation. This step-by-step, methodical strategy ensures that the final generated target resource definition file is not only complete and correct in content, but also valid and error-free in structure, thus providing an absolutely reliable data benchmark for subsequent code synchronization and update steps.

[0161] Optional, please see Figure 4 , Figure 4 This is a flowchart illustrating a conflict identifier re-update process proposed in this specification. Specifically, the process involves re-updating the conflict identifier based on the first resource mapping relationship and the second resource item information to obtain the updated first resource mapping relationship and the updated second resource item information. The following method can be used as a reference:

[0162] S402: Traverse each second resource item in the second resource item information and perform conflict identifier detection on the second resource item based on the first resource mapping relationship;

[0163] Conflict identifier detection: This refers to an automated process that checks whether the "type-name" combination of a resource from an external source (the application package to be aggregated) has already been used in the baseline resource set (the main application package). Its purpose is to identify resource items whose definitions would be duplicated or conflict if directly merged.

[0164] In one specific embodiment, the process of executing step S402 may include the following sub-steps:

[0165] First, the "conflicting identifier re-update" process of S302 has been initiated, and the system has obtained the "first resource mapping relationship" as the decision-making basis and the "second resource item information" (the memory tree of the application file package to be aggregated) as the processing object. This step is the entry point of the ID re-update process, and its core task is to start a traversal loop to systematically analyze and judge each resource item in the "second resource item information".

[0166] Secondly, once the traversal loop starts, for the current "second resource item" in the loop, the detection unit will extract the two key attributes of "resource type" and "resource name" from the memory data object of the resource item as query conditions.

[0167] Next, using the above query criteria, a search is performed in the "First Resource Mapping Relationship". This search operation aims to determine whether there exists a resource in the main application package's resource set that has the same type and name as the currently pending resource item. This is an exact match query process used to identify direct naming conflicts.

[0168] Finally, the output of this step is a judgment result. This result will clearly indicate whether there is a conflict between the currently pending "second resource item" and the resource set of the main application file package. This judgment result will serve as the basis for decision-making, directly determining whether the subsequent process enters one of the three mutually exclusive processing branches: S404 (conflict handling), S406 (same type new addition handling), or S408 (new type new addition handling).

[0169] S404: If there is a first type resource item with the same resource type and the same resource name in the first resource mapping relationship, then the first type resource item is ignored and updated.

[0170] First type of resource item: In the context of this step, it refers to a resource item from the application package to be aggregated that is identified during the detection process of S402 and whose "resource type" and "resource name" are exactly the same as a resource in the main application package.

[0171] Ignore update processing: This refers to a clear processing strategy where, when a complete conflict in resource definition is detected, the system will proactively abandon all processing of that resource item from the application package to be aggregated, without adopting, modifying, or merging it, in order to ensure the priority of resources with the same name and type in the main application package.

[0172] In one specific embodiment, the process of executing step S404 may include the following sub-steps:

[0173] First, the conflict identifier detection result of the previous step S402 is "There is a resource with the same resource type and the same resource name". This judgment result clearly indicates that the "second resource item" currently being traversed from the "application file package to be aggregated" has a direct naming conflict with a resource item that already exists in the "main application file package".

[0174] Secondly, when the system receives this "complete conflict" judgment result, it will trigger the "ignore update processing" logic. This logic is the core embodiment of the conflict resolution strategy of this invention, and its principle is "primary application file package priority". Under this logic, the system will not perform any ID reallocation, information modification or merging operations on the current conflicting resource item from the "second resource item information".

[0175] Furthermore, when performing the ignore handling, the system's processing flow suspends all subsequent operations on the currently conflicting resource item. It neither updates the "first resource mapping relationship" nor modifies anything in the "second resource item information." This ensures the integrity and authority of the original resource definitions and their IDs in the "main application file package," preventing interference from external resources with the same name during the aggregation process.

[0176] Finally, this step is complete. The final result is that the conflicting "second resource item" is effectively "skipped" or "discarded." The entire process then returns directly to the S402 traversal loop and begins a new round of conflict identifier detection for the next "second resource item."

[0177] S406: If there is a second type of resource item with the same resource type but different resource name in the first resource mapping relationship, then generate a first new resource identifier for the second type of resource item based on the maximum value of the resource identifier of the same resource type, and update the identifier of the first type of resource item based on the first new resource identifier;

[0178] The second type of resource item refers to a resource item that is identified during the S402 detection process, whose "resource type" already exists in the main application file package, but whose "resource name" is brand new and comes from the application file package to be aggregated.

[0179] The first newly added resource identifier: refers to the brand-new, unique resource identifier (ID) calculated and assigned to the above-mentioned "second type resource item" through the "incremental allocation of IDs of the same type" logic in this step.

[0180] In one specific embodiment, the process of executing step S406 may include the following sub-steps:

[0181] First, the conflict identifier detection result of the previous step S402 is "There is a resource of the same type but a different name". This judgment result clearly indicates that the "second resource item" currently being processed from the "application file package to be aggregated" has a type that already exists in the "main application file package", but its name is brand new. Therefore, it is a new resource that needs to be safely merged into an existing resource type.

[0182] Secondly, upon receiving this judgment result, the system will trigger the "incremental allocation of IDs of the same type" logic. The system will use the "resource type" of the currently processed resource item as the query condition to search in the "first resource mapping relationship" to obtain the "maximum value of resource identifiers" currently recorded for that resource type. This value represents the upper limit of all allocated IDs for that type in the main application file package.

[0183] Next, after obtaining the "maximum value of resource identifier," the system calculates and generates a completely new and unique ID value based on this value, using a preset identifier entry offset (e.g., by incrementing by 1). This is the "first newly added resource identifier." Subsequently, the system performs an "identifier update" operation, which is a dual update process: on the one hand, it modifies the ID attribute of the current resource item node in the "second resource item information" in memory, updating it to the newly generated "first newly added resource identifier"; on the other hand, it also simultaneously updates the "first resource mapping relationship," adding the name of this newly added resource item to the name list of the corresponding type and updating its "maximum value of resource identifier" to this newly generated ID.

[0184] Finally, this step is complete. Through this step, a new resource item is successfully assigned a new ID that will not conflict with any existing resources, and the system's core data structures ("first resource mapping relationship" and "second resource item information") have also been updated synchronously, preparing for subsequent merging operations. Subsequently, the entire processing flow will directly return to the traversal loop of S402 and begin a new round of conflict identifier detection for the next "second resource item".

[0185] In one feasible implementation, generating a first new resource identifier for the second type of resource item based on the maximum value of resource identifiers of the same resource type can be:

[0186] Obtain the maximum value of resource identifiers of the same resource type in the first resource mapping relationship, generate a first new resource identifier based on the maximum value of the resource identifier based on the preset identifier entry offset, and update the first new resource identifier to the maximum value of the resource identifier of the same resource type in the first resource mapping relationship.

[0187] Preset ID entry offset: This refers to a pre-set value used to calculate the next available ID. In the most common incremental allocation strategy, this offset can be set to an integer such as 1.

[0188] First, the system has initiated the "incremental allocation of IDs of the same type" logic and has identified the resource type of the "second type resource item" currently pending processing.

[0189] Secondly, the system performs a "maximum value retrieval" operation. It uses the current resource type as an index to query the "first resource mapping relationship" and accurately retrieves the "maximum value of resource identifier" currently recorded for that resource type.

[0190] Next, after obtaining the "maximum value of resource identifier," the "new identifier generation and status update" logic is executed. It performs an arithmetic operation (e.g., addition) between the obtained "maximum value of resource identifier" and a "preset identifier entry offset" to calculate a completely new ID value, which is the "first newly added resource identifier." Then, and crucially, the system immediately updates this newly generated "first newly added resource identifier" in the "first resource mapping relationship" with the new "maximum value of resource identifier" for that resource type. This real-time update operation ensures that the next time an ID needs to be assigned to a resource of the same type, the "maximum value of resource identifier" used by the system is always the latest and highest, thus guaranteeing the continuity and uniqueness of ID allocation.

[0191] Finally, this step is complete. Its final output is a unique "first newly added resource identifier" calculated for the current "second type resource item". Simultaneously, the system's "first resource mapping relationship" has been dynamically updated, preparing for processing subsequent resources of the same type.

[0192] S408: If there are third type resource items with different resource types and different resource names in the first resource mapping relationship, then generate a second new resource identifier for the third type resource item based on the block identifier of the highest resource type, and update the identifier of the second type resource item based on the second new resource identifier.

[0193] Third type of resource item: In the context of this step, this term specifically refers to a resource item from the application package to be aggregated that is identified during the detection process of S402 and whose resource type is completely absent in the main application package.

[0194] Highest Resource Type Block Identifier: This refers to the highest value among all known resource types representing type (TT). It marks the boundary of the current ID allocation space.

[0195] The second newly added resource identifier: refers to the new resource identifier (ID) calculated and allocated for the above-mentioned third type resource item through the new type ID block allocation logic in this step, which serves as the starting point of a new type block.

[0196] In one specific embodiment, the process of executing step S408 may include the following sub-steps:

[0197] First, the conflict identifier detection result of the previous step S402 is "resource type is brand new". This means that the "second resource item" currently being processed from the "application file package to be aggregated" does not have any record of its type in the "first resource mapping relationship". This indicates that the resource item introduces a brand new resource type that has never existed in the main application file package, and a separate ID space needs to be allocated for it.

[0198] Secondly, upon receiving this judgment result, the system will trigger the "new type ID block allocation" logic. One of the system's "ID calculation units" will first determine a global "highest resource type block identifier." In a preferred embodiment, this is done by obtaining the largest global ID value among all resource types recorded in the "first resource mapping relationship," and then extracting its high 16 bits (representing the packet and type PPTT portion) through bitwise operations (e.g., right shift by 16 bits).

[0199] Next, after determining the "highest resource type block identifier," the ID calculation unit calculates a completely new, never-before-used type block identifier based on this value, using a preset identifier block offset (e.g., adding 1 to it). Subsequently, the system converts this new type block identifier into a complete 32-bit ID through another bitwise operation (e.g., shifting left by 16 bits), with the lower 16 bits typically being 0; this is the "second newly added resource identifier." Immediately afterward, the system performs an "identifier update," modifying the ID attribute of the current resource item node in the "second resource item information" to the newly generated ID; simultaneously, it creates a completely new entry for this new type in the "first resource mapping relationship," recording its name and ID information.

[0200] Finally, this step is complete. Through this step, a brand new resource type has been successfully assigned a unique and secure ID range, ensuring strict isolation at the ID level from all existing resource types. Subsequently, the entire processing flow will directly return to the S402 traversal loop and begin a new round of conflict identifier detection for the next "second resource item".

[0201] In one feasible implementation, the step of generating a second new resource identifier for the third type resource item based on the highest resource type block identifier can be performed in the following manner:

[0202] Determine the highest resource type block identifier, construct a new identifier segment for the new resource type corresponding to the third type resource item based on the preset identifier block offset and the highest resource type block identifier, assign a second new resource identifier to the third type resource item based on the new identifier segment, and record the second new resource identifier and the new resource type of the third type resource item in the first resource mapping relationship.

[0203] in:

[0204] Preset identifier block offset: This refers to a pre-set value used to calculate the next available type block. In a constantly increasing allocation strategy, this offset is typically set to an integer of 1.

[0205] New identifier range: This refers to a unique, continuous range of ID numbers created for a completely new resource type through bitwise operations. The "Second New Resource Identifier" generated in this step is the starting value of this range.

[0206] First, the system has initiated the new type ID block allocation logic and identified the "third type resource item" to be processed and its new resource type.

[0207] Secondly, the system performs the "highest type block determination operation," which queries the IDs of all resource items in the first resource mapping relationship and finds the global maximum value. Then, through a bitwise operation (specifically, shifting 16 bits to the right), the high 16 bits of the global maximum ID are extracted, thus obtaining the highest resource type block identifier.

[0208] Next, after determining the highest resource type block identifier, the logic for constructing a new identifier segment is executed. The obtained "highest resource type block identifier" is arithmetically performed (e.g., addition) with a "preset identifier block offset" to obtain a new type block identifier that is numerically larger. Then, the system uses another bitwise operation (specifically, a left shift of 16 bits) to construct this new type block identifier into a "new identifier segment" representing the starting point of the new ID segment. Based on this segment, the system assigns its starting ID to the currently pending "third type resource item" as the "second new resource identifier".

[0209] Finally, after allocating the "Second New Resource Identifier," the system performs a "Mapping Relationship Update" operation. This creates a completely new entry for this "New Resource Type" in the "First Resource Mapping Relationship," and records the newly allocated "Second New Resource Identifier" and the name of the resource item in this new entry. This operation ensures that the system's state is updated in real time, preparing for the subsequent allocation of IDs for other resource items belonging to the same new type.

[0210] This specification describes how steps S402 to S408 collectively construct an extremely precise and logically complete automated conflict handling and ID allocation engine. Through the systematic traversal and detection in S402, combined with the three mutually exclusive processing branches S404, S406, and S408, this engine ensures that every possible resource scenario (i.e., complete conflict, addition of the same type, or introduction of a completely new type) is accurately identified, and the most appropriate, pre-defined processing rules are applied. This systematic, binary decision-making process completely replaces the ambiguity and uncertainty of manual judgment, fundamentally guaranteeing zero errors in resource merging decisions.

[0211] Furthermore, by employing two differentiated ID generation strategies—"ID increment" in S406 and "ID block allocation" in S408—a highly robust and forward-looking ID space management mechanism is achieved. It not only securely extends IDs sequentially within existing resource types but also allocates dedicated, completely isolated ID number ranges for entirely new resource types through bitwise operations. This ensures that the final generated resource ID set is not only globally unique at present but also has a clear and rational internal structure, providing a stable and scalable ID management foundation for long-term application iteration and the aggregation of more diverse resource packages in the future.

[0212] Optional, please see Figure 5 , Figure 5 This is a schematic diagram of a resource index update process proposed in this specification. Specifically, the process of updating the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file can be referred to as follows:

[0213] S502: Determine the original resource index file in the application file package to be aggregated;

[0214] The original resource index file refers to the unmodified smali file in the "application file package to be aggregated" that contains hard-coded references to the old resource IDs and is compiled from R.java (the resource index file). These files are the direct targets of automated update operations.

[0215] Okay, as you instructed, I will elaborate on step S502 in the required patent drafting style.

[0216] In one specific embodiment, the process of executing step S502 may include the following sub-steps:

[0217] First, the entire resource merging and generation process is complete, and the system is about to begin synchronizing and updating the code files. The core task of this step is to accurately locate all the code files that need to be checked and modified, defining a clear and limited scope for subsequent automated update operations to improve processing efficiency and avoid accidental operations.

[0218] Secondly, when this step is triggered, the system receives the root directory path of the "application file package to be aggregated" as its starting point and scans and searches in the directory and its subdirectories according to preset rules to identify the target file.

[0219] Furthermore, the preset rule is based on the naming convention and storage location of the target files. In the Android development environment, this rule can be set to: search for all files in a specified code directory (e.g., a directory named smali) whose filenames begin with a specific prefix (e.g., R$) and end with a specific suffix (e.g., .smali). Through this rule, the system can accurately identify all "raw resource index files" directly related to the resource ID definition.

[0220] Finally, once the file locating unit has completed its traversal scan of the specified directory, this step is considered complete. Its final output is a list containing the absolute paths of all identified original resource index files that conform to preset rules. This list will be passed to the subsequent step S506 as the precise set of files that need to be processed one by one.

[0221] S504: Determine a resource index identifier mapping table for the application file package to be aggregated based on the target resource definition file;

[0222] Resource index identifier mapping table: This refers to a data structure built in memory for fast lookup. It establishes a clear correspondence between the descriptive information of a resource (type and name) and its final, globally unique numerical identifier (ID).

[0223] In a specific embodiment, the process of executing step S504 may include the following sub-steps:

[0224] First, this step assumes that S106 has successfully generated a unique "target resource definition file" containing all aggregated resources. The core task of this step is to create a data structure, namely a "resource index identifier mapping table," based on this final and authoritative resource definition, for efficient querying and containing the correspondence between the old and new IDs. This mapping table is the sole basis for subsequent code file update operations.

[0225] Secondly, when this step is triggered, the system receives the path to the "target resource definition file" as input and calls an XML parser to read and analyze the entire contents of the file.

[0226] Secondly, during the parsing process, each resource definition element in the file is traversed (e.g., each...). <public>(Labels). For each element, its "resource type," "resource name," and ultimately determined "resource identifier (ID)" are precisely extracted. Based on these three pieces of information, a structured mapping table is constructed in memory. In an optional implementation, this table is a nested key-value data structure, with a query path designed as [resource type] -> [resource name] -> [final resource ID]. This structure enables subsequent steps to perform extremely fast query operations.

[0227] Finally, this step is complete once all resource items in the "Target Resource Definition File" have been fully parsed and recorded in the mapping table. The final output is a comprehensive and efficient "Resource Index Identifier Mapping Table".

[0228] S506: Based on the resource index identifier mapping table, traverse the original resource index file and perform resource item identifier update processing on the original resource index file.

[0229] Resource item identifier update processing: refers to an automated find and replace process that locates specific statements in a specified code file that hardcode old resource IDs and updates these old ID values ​​to new, correct ID values ​​based on an authoritative mapping table.

[0230] In one specific embodiment, the process of executing step S506 may include the following sub-steps:

[0231] First, this step assumes that S502 has determined the list of "original resource index files" to be processed, and S504 has successfully constructed an authoritative "resource index identifier mapping table". This step is the final modification action, aiming to safely and accurately replace all hard-coded references to the old resource IDs in the code files with the new IDs.

[0232] Secondly, once this step is triggered, a traversal loop is started, which processes each file in the "raw resource index file" list determined by S502 one by one. For the currently processed file, the system first parses the corresponding "resource type" from its filename (for example, parses the string type from R$string.smali).

[0233] Next, after determining the resource type of the current file, the system executes the "file content update" logic. It reads the file content line by line, scanning each line using a preset matching rule (e.g., a regular expression that recognizes resource ID declaration syntax). If a line of code is successfully matched, the system extracts the "resource name" defined in that line. Using the "resource type" parsed from the filename and the "resource name" extracted from the code line, the system performs a precise lookup in the "resource index identifier mapping table" built by S504 to obtain the new ID corresponding to the resource. Once the new ID is obtained, it replaces the old ID value in that line of code.

[0234] Finally, once all lines of a file have been scanned and processed, the system writes the updated content (including both modified and unmodified lines) back to the original file, completing the modification of that single file. After traversing and updating all files in the list, this step is complete, and the entire application file aggregation processing method ends. Its final output is a collection of "aggregated resource index files" whose content has been fully synchronized.

[0235] In this specification, steps S502 to S506 collectively implement a highly accurate and complete automated code synchronization mechanism. Step S502, through precise identification of file naming rules, ensures that only code files directly related to the resource ID are included in the processing scope, avoiding accidental operations on irrelevant files. Step S504, by parsing the final "target resource definition file," constructs an ID mapping table, ensuring that all update operations are based on a unique and authoritative data source, fundamentally guaranteeing the accuracy of ID replacement.

[0236] More importantly, step S506 puts the above preparations into practice. Through automated traversal, matching, and replacement, the originally error-prone and labor-intensive manual code modification process is transformed into a fast and reliable automated workflow. This set of steps together constitutes the key "closed loop" of the entire aggregation processing method. It ensures that changes at the resource level can be perfectly synchronized to the code implementation level, thereby guaranteeing the functional integrity and operational stability of the final aggregation application and completely solving the major defect in existing technologies that leads to program crashes due to manual synchronization oversights.

[0237] The following will combine Figure 6 This specification provides a detailed description of the application file aggregation processing apparatus provided in the embodiments. It should be noted that... Figure 6 The application file aggregation processing device shown is used to execute this specification. Figures 1-5 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figures 1-5 The example shown.

[0238] Please see Figure 6 This diagram illustrates the structure of an application file aggregation processing device according to an embodiment of this specification. The application file aggregation processing device 1 can be implemented as all or part of a user terminal through software, hardware, or a combination of both. According to some embodiments, the application file aggregation processing device 1 includes a determining module 11, a parsing module 12, and an aggregation module 13, specifically used for:

[0239] Module 11 is used to determine the main application file package and the application file package to be aggregated for the target application;

[0240] The parsing module 12 is used to parse the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, so as to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file;

[0241] The aggregation module 13 is used to merge resource identifiers based on the first resource mapping relationship, the first resource item information and the second resource item information to obtain the target resource definition file of the target application;

[0242] The aggregation module 13 is used to update the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file.

[0243] In one feasible implementation, the step of parsing the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, to obtain the first resource mapping relationship, the first resource item information, and the second resource item information of the second resource definition file for the first resource definition file, includes:

[0244] The first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated are parsed to obtain the first resource item information for the first resource definition file and the second resource item information for the second resource definition file.

[0245] The first resource definition file is parsed to obtain the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier under the first resource type. A first resource mapping relationship is constructed based on the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier.

[0246] In one feasible implementation, the step of merging resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file for the target application includes:

[0247] Based on the first resource mapping relationship and the second resource item information, the conflict identifier is re-updated to obtain the updated first resource mapping relationship and the updated second resource item information;

[0248] Identify the re-update identifier resource item in the second resource item information, merge the re-update identifier resource item into the first resource item information, and generate the merged target resource item information;

[0249] A target resource definition file is generated based on the target resource item information and the first resource mapping relationship.

[0250] In one feasible implementation, the step of re-updating the conflict identifier based on the first resource mapping relationship and the second resource item information to obtain the updated first resource mapping relationship and the updated second resource item information includes:

[0251] Traverse each second resource item in the second resource item information and perform conflict identifier detection on the second resource item based on the first resource mapping relationship;

[0252] If there is a first type of resource item with the same resource type and the same resource name in the first resource mapping relationship, then the first type of resource item is ignored and updated.

[0253] If there is a second type of resource item with the same resource type but a different resource name in the first resource mapping relationship, then a first new resource identifier is generated for the second type of resource item based on the maximum value of the resource identifier of the same resource type, and the identifier of the first type of resource item is updated based on the first new resource identifier;

[0254] If there are third-type resource items with different resource types and names in the first resource mapping relationship, then a second newly added resource identifier is generated for the third-type resource item based on the block identifier of the highest resource type, and the identifier of the second-type resource item is updated based on the second newly added resource identifier.

[0255] In one feasible implementation, generating a first new resource identifier for the second type of resource item based on the maximum value of resource identifiers of the same resource type includes:

[0256] Obtain the maximum value of resource identifiers of the same resource type in the first resource mapping relationship, generate a first new resource identifier based on the maximum value of the resource identifier based on the preset identifier entry offset, and update the first new resource identifier to the maximum value of the resource identifier of the same resource type in the first resource mapping relationship.

[0257] In one feasible implementation, generating a second new resource identifier for the third type of resource item based on the highest resource type block identifier includes:

[0258] Determine the highest resource type block identifier, construct a new identifier segment for the new resource type corresponding to the third type resource item based on the preset identifier block offset and the highest resource type block identifier, assign a second new resource identifier to the third type resource item based on the new identifier segment, and record the second new resource identifier and the new resource type of the third type resource item in the first resource mapping relationship.

[0259] In one feasible implementation, the step of updating the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file includes:

[0260] Identify the original resource index file in the application file package to be aggregated;

[0261] Based on the target resource definition file, a resource index identifier mapping lookup table is determined for the application file package to be aggregated;

[0262] Based on the resource index identifier mapping table, the original resource index file is traversed, and the resource item identifier of the original resource index file is updated.

[0263] It should be noted that the application file aggregation processing device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the application file aggregation processing method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the application file aggregation processing device and the application file aggregation processing method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0264] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0265] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-5 The application file aggregation processing method described in the illustrated embodiment can be found in the following documentation for its specific execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0266] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1-5 The application file aggregation processing method described in the illustrated embodiment can be found in the following documentation for its specific execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0267] Please refer to Figure 7 This diagram illustrates a structural block diagram of an electronic device provided in an exemplary embodiment of this specification. The electronic device in this specification may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0268] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 110 may integrate one or more of the following: central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately using a communication chip.

[0269] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include a non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described below, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems. The data storage area may also store data created by the electronic device during use, such as phonebook data, audio and video data, chat log data, etc.

[0270] See Figure 8 As shown, the memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in the user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have high requirements for disk read speed; in animation rendering scenarios, third-party applications have high requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly to the specific application scenario of the third-party application.

[0271] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0272] Taking the Android operating system as an example, the programs and data stored in memory 120 are as follows: Figure 9 As shown, the memory 120 can store the Linux kernel layer 320, the system runtime library layer 340, the application framework layer 360, and the application layer 380. The Linux kernel layer 320, system runtime library layer 340, and application framework layer 360 belong to the operating system space, while the application layer 380 belongs to the user space. The Linux kernel layer 320 provides low-level drivers for various hardware components of the electronic device, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, and power management. The system runtime library layer 340 provides support for key features of the Android system through several C / C++ libraries. For example, the SQLite library provides database support, the OpenGL / ES library provides 3D graphics support, and the Webkit library provides browser kernel support. The system runtime library layer 340 also provides the Android runtime library, which mainly provides core libraries that allow developers to write Android applications using the Java language. The Application Framework Layer 360 provides various APIs that may be used when building applications. Developers can also use these APIs to build their own applications, such as activity management, window management, view management, notification management, content provider, package management, call management, resource management, and location management. At least one application runs in the Application Layer 380. These applications can be native applications that come with the operating system, such as contacts, SMS, clock, and camera apps; or third-party applications developed by third-party developers, such as games, instant messaging, and photo editing apps.

[0273] Taking the operating system as an example (iOS), the programs and data stored in memory 120 are as follows: Figure 10 As shown, the iOS system includes: Core OS layer 420, Core Services layer 440, Media layer 460, and Cocoa Touch layer 480. Core OS layer 420 includes the operating system kernel, drivers, and low-level program frameworks. These low-level program frameworks provide hardware-level functionality for use by the program frameworks located in Core Services layer 440. Core Services layer 440 provides system services and / or program frameworks required by applications, such as Foundation framework, account framework, advertising framework, data storage framework, network connectivity framework, geolocation framework, motion framework, etc. Media layer 460 provides applications with audiovisual interfaces, such as interfaces related to graphics and images, audio technology, video technology, and AirPlay (wireless playback of audio and video transmission technologies). Cocoa Touch layer 480 provides various commonly used interface-related frameworks for application development and is responsible for user touch interaction on electronic devices. Examples include local notification services, remote push services, advertising frameworks, game tool frameworks, message user interface (UI) frameworks, UIKit frameworks, map frameworks, and so on.

[0274] exist Figure 10 The framework shown includes, but is not limited to, the base framework in the core service layer 440 and the UIKit framework in the touchable layer 480. The base framework provides many basic object classes and data types, offering the most basic system services to all applications, and is independent of the UI. The UIKit framework, on the other hand, provides a basic UI class library for creating touch-based user interfaces. iOS applications can use the UIKit framework to provide their UI, thus providing the application's infrastructure for building user interfaces, drawing, handling user interaction events, responding to gestures, and so on.

[0275] The methods and principles for implementing data communication between third-party applications and the operating system in the iOS system can be found in the Android system, and will not be repeated here.

[0276] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined into a touch screen, which is used to receive touch operations from the user using a finger, stylus, or any suitable object on or near it, and to display the user interface of various applications. The touch screen is usually located on the front panel of the electronic device. The touch screen can be designed as a full-screen, curved screen, or irregularly shaped screen. The touch screen can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; this specification does not limit this aspect.

[0277] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WiFi) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0278] In the embodiments of this specification, the executing entity for each step can be the electronic device described above. Optionally, the executing entity for each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0279] The electronic device described in this specification can also be equipped with a display device. This display device can be any device capable of displaying information, such as a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), or a plasma display panel (PDP). Users can use the display device on the electronic device to view displayed text, images, videos, and other information. The electronic device can be a smartphone, tablet computer, gaming device, AR (Augmented Reality) device, automobile, data storage device, audio playback device, video playback device, laptop, desktop computing device, or wearable device such as a smartwatch, smart glasses, smart helmet, smart bracelet, smart necklace, or smart clothing.

[0280] exist Figure 7 In the illustrated electronic device, the processor 110 can be used to call the application program stored in the memory 120 and specifically perform the following operations:

[0281] Identify the main application file package and the application file packages to be aggregated for the target application;

[0282] The resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated is parsed to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file.

[0283] Based on the first resource mapping relationship, the first resource item information and the second resource item information, the resource identifiers are merged to obtain the target resource definition file of the target application;

[0284] Based on the target resource definition file, the resource identifier of the original resource index file in the application file package to be aggregated is updated to obtain the aggregated resource index file.

[0285] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0286] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.< / public> < / public>

Claims

1. A method for processing application file aggregation, characterized in that, The method includes: Identify the main application file package and the application file packages to be aggregated for the target application; The resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated is parsed to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file. Based on the first resource mapping relationship, the first resource item information and the second resource item information, the resource identifiers are merged to obtain the target resource definition file of the target application; Based on the target resource definition file, the resource identifier of the original resource index file in the application file package to be aggregated is updated to obtain the aggregated resource index file.

2. The method according to claim 1, characterized in that, The step of parsing the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, to obtain the first resource mapping relationship, the first resource item information, and the second resource item information of the second resource definition file for the first resource definition file, includes: The first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated are parsed to obtain the first resource item information for the first resource definition file and the second resource item information for the second resource definition file. The first resource definition file is parsed to obtain the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier under the first resource type. The first resource mapping relationship is constructed based on the first resource type, the first resource name, the first resource identifier, and the maximum value of the resource identifier.

3. The method according to claim 1, characterized in that, The process of merging resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file for the target application includes: Based on the first resource mapping relationship and the second resource item information, the conflict identifier is re-updated to obtain the updated first resource mapping relationship and the updated second resource item information; Identify the re-update identifier resource item in the second resource item information, merge the re-update identifier resource item into the first resource item information, and generate the merged target resource item information; A target resource definition file is generated based on the target resource item information and the first resource mapping relationship.

4. The method according to claim 3, characterized in that, The step of re-updating the conflict identifier based on the first resource mapping relationship and the second resource item information to obtain the updated first resource mapping relationship and the updated second resource item information includes: Traverse each second resource item in the second resource item information and perform conflict identifier detection on the second resource item based on the first resource mapping relationship; If there is a first type of resource item with the same resource type and the same resource name in the first resource mapping relationship, then the first type of resource item is ignored and updated. If there is a second type of resource item with the same resource type but a different resource name in the first resource mapping relationship, then a first new resource identifier is generated for the second type of resource item based on the maximum value of the resource identifier of the same resource type, and the identifier of the first type of resource item is updated based on the first new resource identifier; If there are third-type resource items with different resource types and names in the first resource mapping relationship, then a second newly added resource identifier is generated for the third-type resource item based on the block identifier of the highest resource type, and the identifier of the second-type resource item is updated based on the second newly added resource identifier.

5. The method according to claim 4, characterized in that, The step of generating a first new resource identifier for the second type of resource item based on the maximum value of the resource identifier of the same resource type includes: Obtain the maximum value of resource identifiers of the same resource type in the first resource mapping relationship, generate a first new resource identifier based on the maximum value of the resource identifier based on the preset identifier entry offset, and update the first new resource identifier to the maximum value of the resource identifier of the same resource type in the first resource mapping relationship.

6. The method according to claim 4, characterized in that, The step of generating a second new resource identifier for the third type of resource item based on the highest resource type block identifier includes: Determine the highest resource type block identifier, construct a new identifier segment for the new resource type corresponding to the third type resource item based on the preset identifier block offset and the highest resource type block identifier, assign a second new resource identifier to the third type resource item based on the new identifier segment, and record the second new resource identifier and the new resource type of the third type resource item in the first resource mapping relationship.

7. The method according to claim 1, characterized in that, The step of updating the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file includes: Identify the original resource index file in the application file package to be aggregated; Based on the target resource definition file, a resource index identifier mapping lookup table is determined for the application file package to be aggregated; Based on the resource index identifier mapping table, the original resource index file is traversed, and the resource item identifier of the original resource index file is updated.

8. An application file aggregation processing device, characterized in that, The device includes: The determination module is used to determine the main application file package and the application file packages to be aggregated for the target application. The parsing module is used to parse the resource definition information of the first resource definition file of the main application file package and the second resource definition file of the application file package to be aggregated, so as to obtain the first resource mapping relationship, the first resource item information and the second resource item information of the second resource definition file for the first resource definition file; The aggregation module is used to merge resource identifiers based on the first resource mapping relationship, the first resource item information, and the second resource item information to obtain the target resource definition file of the target application; The aggregation module is used to update the resource identifier of the original resource index file in the application file package to be aggregated based on the target resource definition file to obtain the aggregated resource index file.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed as method steps as claimed in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 7.

Images