Processing method, device and equipment for applying skin resources and readable storage medium

Abstract

The embodiment of the invention relates to the technical field of software development, and discloses an application skin resource processing method, device and equipment and a readable storage medium, and the method comprises the steps: responding to a received skin design draft, analyzing the skin design draft, obtaining resource metadata, and storing the resource metadata in a database; the resource metadata comprises at least one of an application image resource, an application skin color resource and an application text resource; based on a dynamically configured rule base, determining a storage path and a name conversion rule corresponding to each type of resource metadata; on the basis of the name conversion rule, performing name conversion on each piece of resource metadata; and writing the resource metadata after name conversion into a storage path corresponding to the resource metadata. By applying the technical scheme of the invention, the full-process automatic processing of the skin resources can be realized, and the resource processing efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of software development technology, specifically to a method, apparatus, device, and readable storage medium for processing application skin resources. Background Technology

[0002] In the field of mobile internet application development, the multi-skin function of Android applications has become an important means to improve user experience and enhance product competitiveness.

[0003] Currently, existing multi-skin resource processing technologies are still mainly based on manual or semi-automated operations. In the manual processing mode, developers need to repeatedly perform resource extraction, copying and naming for each skin package.

[0004] However, existing manual or semi-automated multi-skin resource processing technologies are inefficient. Summary of the Invention

[0005] In view of the above problems, embodiments of the present invention provide a method, apparatus, device and readable storage medium for processing skin resources, which solves the problem of low efficiency in manual processing of skin resources in the prior art.

[0006] According to one aspect of the present invention, a method for processing skin resources is provided, the method comprising:

[0007] In response to receiving a skin design draft, the skin design draft is parsed to obtain resource metadata, which includes at least one of application image resources, application skin color resources, and application text resources;

[0008] Based on a dynamically configured rule base, the storage path and name conversion rules corresponding to each type of resource metadata are determined;

[0009] Based on the aforementioned name conversion rules, the names of each resource metadata are converted;

[0010] Write the renamed resource metadata into the storage path corresponding to the resource metadata.

[0011] According to another aspect of the present invention, a processing apparatus for applying skin resources is provided, the apparatus comprising:

[0012] The parsing module is used to parse the skin design draft in response to receiving the skin design draft and obtain resource metadata, wherein the resource metadata includes at least one of application image resources, application skin color resources and application text resources;

[0013] The determination module is used to determine the storage path and name conversion rules corresponding to each type of resource metadata based on a dynamically configured rule base;

[0014] The conversion module is used to convert the names of various resource metadata based on the name conversion rules;

[0015] The writing module is used to write the name-converted resource metadata into the resource file in the storage path.

[0016] According to another aspect of the present invention, an electronic device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, the executable instruction causing the processor to perform the operation as described above.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction that causes an electronic device or apparatus to perform the operation of the above-described method:

[0018] This invention automatically parses skin design drafts to obtain resource data, automatically renames and adjusts the resources based on rules, and then automatically writes the renamed resources into resource files in the corresponding storage path. This avoids the problem of resource mismatch caused by errors in traditional manual copying, and significantly improves the processing efficiency of skin resources.

[0019] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0021] Figure 1 A flowchart illustrating the method for processing skin resources provided in this application embodiment;

[0022] Figure 2 This is a schematic diagram of the skin design draft parsing method provided in an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the resource writing process provided in an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of the resource update method provided in the embodiments of this application;

[0025] Figure 5 This is a schematic diagram of the skin pack update process provided in an embodiment of this application;

[0026] Figure 6 This is a structural diagram of the skin resource processing system provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the workflow of the skin resource processing system provided in the embodiments of this application;

[0028] Figure 8 A schematic diagram of the structure of the skin resource processing device provided in the embodiments of this application;

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

[0030] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0031] The multi-skin feature of Android applications refers to allowing users or developers to change the overall visual style of an application by changing resource packages (such as colors, images, fonts, etc.) without modifying the application code. This feature is widely used in the following scenarios: (1) Brand customization: providing brand-specific user interface (UI) styles for different customers or partners. (2) User personalization: supporting users to select themes (such as dark / light mode, holiday themes, etc.). Traditional multi-skin resource processing technology is mainly based on manual or semi-automated operations, which has problems such as low efficiency and easy operation errors.

[0032] To address the aforementioned issues, this application provides a method, apparatus, device, and readable storage medium for processing application skin resources. It automatically parses the skin design draft to obtain application image resources, application skin color resources, and application text resources. Then, based on pre-configured rules, it renames and adjusts the application image resources, application skin color resources, and application text resources, and writes them to resource files in corresponding storage paths. This achieves fully automated skin resource processing, improving its efficiency and accuracy.

[0033] Figure 1This is a flowchart illustrating a method for processing application skin resources according to an embodiment of this application. The method is executed by an electronic device, which, exemplarily, can refer to a computer device. Figure 1 As shown, the method includes the following steps:

[0034] Step 110: In response to receiving the skin design draft, parse the skin design draft and obtain resource metadata.

[0035] The resource metadata includes at least one of the following: application image resources, application skin color resources, and application text resources.

[0036] Step 120: Based on the dynamically configured rule base, determine the storage path and name conversion rules corresponding to each type of resource metadata.

[0037] Step 130: Based on the name conversion rules, perform name conversion on the metadata of each resource.

[0038] Step 140: Write the renamed resource metadata into the resource file in the storage path.

[0039] Traditional multi-skin resource processing techniques include manual and semi-automated processing. Taking manual processing as an example, operators need to manually select resources such as images, color values, text strings, and layout files from the design draft, and then copy them one by one to the corresponding skin package's Android resource directory (i.e., the res directory). This process is not only repetitive, tedious, and time-consuming, but also prone to resource mismatch problems due to human error. For example, icons unique to a certain skin may be mistakenly copied to other skin packages, or the naming format may not conform to Android specifications, resulting in frequent problems such as blurry icons and application startup errors on high-resolution devices. Manual operation is highly prone to resource omissions and path errors. In the resource copying and naming stages, errors often occur due to fatigue or negligence, greatly increasing the cost of subsequent testing and repair.

[0040] Compared to the manual processing of multiple skin resources mentioned above, this application embodiment improves resource screening efficiency by automatically parsing the skin design drafts and obtaining resource data. Furthermore, by configuring rules in advance in the rule base and automatically renaming resources based on those rules, it avoids naming formats that do not conform to Android specifications. In addition, by automatically writing the renamed resources into resource files under the corresponding storage path, it avoids the problem of resource mismatch caused by errors in traditional manual copying, significantly improving the processing efficiency of skin resources and reducing possible errors during the processing.

[0041] Regarding step 110, the skin design draft can be output from UI design software to an electronic device. Different UI design software (such as Adobe Photoshop, Sketch, and Figma) output skin design drafts in different formats. For example, the UI design draft can be the native file format (Photoshop Document, PSD) output by Adobe Photoshop, simply referred to as a PSD file. Another example is the file format output by the vector graphics editing tool Sketch, simply referred to as a Sketch file. Yet another example is the file format output by the cloud-based online collaborative design tool Figma, simply referred to as a Figma file.

[0042] For skin design drafts output by different UI design software, corresponding parsing strategies can be adopted to improve parsing efficiency. During the parsing process, the type characteristics of resources can be automatically analyzed and identified. For example, small transparent background images in skin design drafts can be identified as "application image resources", single color values ​​without fixed sizes can be identified as "application skin color resources", and those containing text content and font information can be identified as "application text resources".

[0043] Resource metadata is formed by integrating the resource and its various related information. For example, after parsing the resource and its various parameters and attribute information, it is uniformly stored as resource metadata in a standardized JSON format. That is, the resource metadata obtained after parsing contains core information such as the corresponding resource type (e.g., image, color, or text), identification information (e.g., image name), attribute parameters (e.g., image size, color value, or font), and relationships. For example, "application image resource" can include not only a small image with a transparent background, but also the name, size, and resolution of that small image. This lays the data foundation for subsequent resource processing steps and ensures the accuracy of resource processing.

[0044] For step 120, a flexibly configurable "rule engine" can be set up, and a corresponding rule library can be built for it. The rule library should include at least target address mapping rules and name conversion rules. Then, the "rule engine" will automatically determine how each resource in the skin design draft is stored and named in the Android project based on the rules configured in the rule library.

[0045] The target address mapping rules are used to indicate the storage paths corresponding to different types of resources. For example, application image resources need to be stored in the res / drawable-{dpi} / directory, where dpi represents resolution. Based on different resolutions, the res / drawable directory can be divided into multiple subdirectories corresponding to different resolutions, and then the application image resource is stored in the corresponding subdirectory according to its own resolution. Another example is that the target address mapping rules indicate that application skin color resources need to be stored in the res / values / colors.xml file, while application text resources need to be stored in the res / values / strings.xml file.

[0046] The name conversion rules are used to convert the names of various resources into the standard Android project name format according to the rules. In practice, developers can customize these conversion rules to adapt to the naming conventions of different projects.

[0047] In this embodiment, the rules in the rule base are not fixed but dynamically configurable. For example, developers can add or modify rules through a visual interface. For instance, if a project requires a special naming format or file storage location, only a new rule configuration needs to be added, without modifying the system code. Rule configurations can also be exported as files for sharing among different projects.

[0048] Regarding step 130, as mentioned above, name conversion rules are used to convert the original name of a resource into a standard name format. For example, suppose there is a resource in the skin design draft with an initial name of "TopNav_BgColor". Based on the name conversion rules, it needs to be automatically converted into the standard naming format of "top_nav_bg_color".

[0049] Regarding step 140, taking configuring the navigation bar background color in the application as an example, if the skin design draft has a blue background with an initial name of "TopNav_BgColor", its processing procedure is as follows:

[0050] 1. After parsing the skin design draft, the resource metadata is obtained: the resource type is "color", the original name is "TopNav_BgColor", and the color value is "#FF5722";

[0051] 2. The system inputs this resource metadata into the aforementioned "rule engine";

[0052] 3. The "rule engine" can identify, based on resource feature information, the type of the resource's metadata, whether it is an application skin color resource;

[0053] 4. Configure "Name Conversion Rules" to convert the original name "TopNav_BgColor" to the standard naming format "top_nav_bg_color";

[0054] 5. Configure the "Target Address Mapping Rules" to store the application's skin resources in the "res / values / colors.xml" file;

[0055] 6. Display the final resource processing results: Create records in colors.xml<colorname=“top_nav_bg_color”> #FF5722.

[0056] Figure 2 This is a schematic diagram of the skin design draft parsing method provided in an embodiment of this application, such as... Figure 2 As shown, it includes the following steps:

[0057] Step 210: Identify the design tool for the skin design draft based on its file format;

[0058] Step 220: Use the plugin interface of the design tool to parse the skin design draft and obtain resource metadata.

[0059] The above embodiments mentioned that traditional skin resource processing technology also has a semi-automatic approach. This semi-automatic approach mainly relies on script tools to assist in resource migration (i.e., automatically migrating resources to the corresponding storage path). However, it cannot complete the parsing of skin design drafts, still requiring manual pre-processing of skin design drafts and resource extraction, which is prone to manual extraction errors. Based on this, in this embodiment, a multi-source design draft intelligent parsing engine is built, employing differentiated parsing strategies for skin design drafts of different file formats to achieve accurate and efficient extraction of resource metadata.

[0060] Regarding step 210, when designers use different skin design tools to design skins for Android applications, the file formats of the skin design drafts output by different skin design tools are different. For example, design tools include Adobe Photoshop, Sketch, and Figma. Adobe Photoshop is image processing software, and its output skin design drafts are PSD files; Sketch is a vector graphics editing tool focused on UI design, and its output skin design drafts are Sketch files; Figma is a cloud-based online collaborative design tool, and its output skin design drafts are Figma files.

[0061] Regarding step 220, for parsing PSD files, the PhotoshopScripting Application Programming Interface (API) provided by Adobe Photoshop can be used as the plugin interface. For parsing Sketch files, the Sketch Plugin API provided by Sketch can be used as the plugin interface. For Figma files, the REST API provided by the Figma Open Platform can be used as the plugin interface.

[0062] In this embodiment, by building a multi-source design draft intelligent parsing engine, a differentiated parsing strategy is adopted for skin design drafts of different file formats. The corresponding design tool provides a plugin interface to parse the skin design drafts, which solves the problems of low efficiency and error in manual skin design draft processing, and realizes accurate and efficient extraction of resource metadata.

[0063] Furthermore, based on the above embodiments, in some embodiments, the parsing process for skin design drafts of different file formats is different, as detailed below:

[0064] (1) If the skin design draft is a PSD file, the Photoshop Scripting API (JavaScript) provided by Adobe Photoshop can be used to extract the attribute information of each layer by traversing the layer tree structure, and then parse the resource metadata based on this. For example, using the Photoshop Scripting API (JavaScript), the app.activeDocument.layers interface can be called to obtain the layer collection, the layer name can be identified by layer.name, the layer size information can be obtained by layer.bounds, the text content can be extracted by layer.textItem.contents, and the fill color value can be obtained by layer.fillColor (converted to HEX file format). For smart object layers, the layer.duplicate() method can be used to export them as bitmap resources.

[0065] `app.activeDocument.layers` is a core property in the Adobe Photoshop scripting API, representing the collection of all layers in the currently active document. This property allows access to each layer in the document, supporting operations such as traversal, adding, deleting, modifying, and querying. `layer.name` is a property of the layer object used to get or set the layer's name. `layer.bounds` describes the bounding rectangular area of ​​the layer's content, containing position and size information; its purpose is to return a rectangular object representing the valid range of the layer's content. `layer.textItem.contents` is a property of text layers used to get or set the text content. `layer.fillColor` is the fill color property of the layer object used to set or return the layer's fill color. The `layer.duplicate()` method is a method of the layer object used to copy the current layer and create a new layer. These properties and methods constitute the core functionality of the Adobe Photoshop scripting API (i.e., the plugin interface provided by First Design Tools).

[0066] (2) If the skin design draft is a Sketch file, the Sketch Plugin API provided by the Sketch design tool can be used to write a plugin in Objective-C to obtain document data. Call MSDocument.currentDocument() to get the current document, iterate through document.pages() and page.layers() to get all layers, use layer.frame() to get the position and size, layer.style().fills() to get the fill style, and layer.text() to get the text properties. Vector graphics are converted to Portable Network Graphics (PNG) bitmaps using the layer.export() interface.

[0067] Objective-C, an object-oriented programming language, allows you to write Sketch plugins. `MSDocument.currentDocument()` is a global method provided by the Sketch plugin API, used to retrieve the currently edited document object. `document.pages()` is a method of the `MSDocument` object, used to retrieve all pages in the document. `page.layers()` is a method of the `MSPage` object, used to retrieve all layers on a specified page. `layer.frame()` is a property of the `MSLayer` object, representing the layer's bounding box. `layer.style().fills()` is a style property of the `MSLayer` object, used to retrieve the layer's fill style. `layer.text()` is a property of the `MSLayer` object, used to retrieve the text content of a text layer. `layer.export()` is a method of the `MSLayer` object, used to export a layer as an image.

[0068] (3) If the skin design draft is a Figma file, the document data can be obtained through the REST API provided by the Figma Open Platform. Send a GET request to obtain the complete node tree structure, parse the nodes object in the JSON response, and extract the name, type, absoluteBoundingBox and other attributes of each node. The color value is obtained through fills[0].color and converted to HEX format, the text content is extracted from the characters field, and the font information is obtained from the style object.

[0069] In some embodiments, when the skin design draft contains resource formats not directly supported by Android, such as Scalable Vector Graphics (SVG), traditional semi-automatic scripts cannot automatically complete format conversion and resolution adaptation. Therefore, for application image resources, the screen density of the device display screen running the Android application can be obtained, and based on this screen density and a preset scaling algorithm, multiple versions of application image resources can be generated, each with a different image resolution.

[0070] Format conversion can be achieved through the aforementioned API interfaces. For example, scalable vector graphics can be converted to PNG bitmaps using the layer.export() interface.

[0071] In addition, after generating multiple versions of application image resources, a suitable target format can be used for compression first. If the subsequent Android application does not support the target format, it can be automatically converted to a compatible format.

[0072] For example, when generating application image resources at different resolutions, a mapping from the pixel coordinates of the target image to the pixel coordinates of the original image can be established based on the ratio between the target resolution and the original resolution. For resolution scaling scenarios, the target pixels need to be mapped to non-integer coordinates of the original image (e.g., when scaling from 1080P to 720P, the target pixels are mapped to the virtual positions of the original image). For scaling scenarios, multiple target pixels may be mapped to the same pixel region of the original image.

[0073] In addition, the preset scaling algorithms may include nearest neighbor interpolation and bilinear interpolation, etc.

[0074] In this embodiment, by automatically completing the format conversion and generating multiple versions of the application image resources based on the Android screen density using an intelligent scaling algorithm, it is possible to automatically adapt to different screen densities.

[0075] Furthermore, as mentioned above, a flexibly configurable "rule engine" can be set up, and a corresponding rule base can be built for it. The rule base contains dynamically configurable rules. Based on this, in some embodiments, if the resource metadata is an application image resource, and the application image resource includes multiple versions (each version has a different image resolution), then a path mapping rule can be built based on the image resolution to determine the storage path corresponding to the application image resource of that version.

[0076] For example, if the application image resources are divided into two versions, with the first version having a resolution of 300 dots per inch (DPI) and the second version having a resolution of 500 DPI, then the first version of the application image resources can be stored in the res / drawable-{dpi=300} / directory, and the second version of the application image resources can be stored in the res / drawable-{dpi=500} / directory.

[0077] In this embodiment of the application, by configuring a rule base and constructing mapping rules between application image resources and storage path supports, the automatic construction of the application skin package res directory structure and the automatic writing of application image resources can be realized, eliminating the need for manual copying to the corresponding directories one by one, thus improving the processing efficiency of application image resources.

[0078] Figure 3 This is a schematic diagram of the resource writing process provided in the embodiments of this application, such as... Figure 3 As shown, it includes the following steps:

[0079] Step 310: Based on the basic resource metadata in the basic skin package, construct the resource files in the storage path;

[0080] Step 320: Determine whether there is redundant metadata in each resource metadata after name conversion. Redundant metadata is the same as basic resource metadata.

[0081] Step 330: If redundant metadata exists, skip writing the redundant metadata.

[0082] In practical applications, an application may have multiple skin packages for users to switch between, achieving personalized skin customization. During skin package development, a base skin package can be pre-built. This base skin package has a `res` directory, under which multiple storage paths can be created. Different resource files are created in different storage paths, and corresponding basic resource metadata is written to them. Subsequently, only the required skin resources need to be added to the various storage paths within the `res` directory to generate a completely new skin package. This improves efficiency and allows for the rapid generation of multiple new skin packages.

[0083] However, traditional multi-skin resource processing technology lacks an intelligent and differentiated management mechanism for skin package resources. In multi-skin projects, there are often a large number of skin resources that are the same as the basic skin package. When processing manually or semi-automatically, these duplicate resources will be copied and deployed repeatedly for no reason, which will occupy storage space and reduce processing efficiency.

[0084] In this embodiment, to address the issues of redundant resource copying and deployment, which occupy storage space and reduce processing efficiency, when writing the metadata of each resource into the base skin package to build a brand new skin package, it can first compare it with the basic resource metadata in the base skin package, and only write the differentiated skin resources (i.e., redundant metadata is directly skipped), thus avoiding redundant storage, improving resource generation efficiency and storage utilization, and also improving efficiency.

[0085] For example, if a 500dpi application image resource is stored in the res / drawable-{dpi=500} / directory of the basic skin package, and the resource metadata is the same as the 500dpi application image resource when writing the resource metadata, then it will not be written to the res / drawable-{dpi=500} / directory of the basic skin package, and will be skipped directly.

[0086] Among them, algorithms such as hash value comparison and file content similarity detection can be used to quickly and accurately determine whether the resource metadata is duplicated with the basic metadata in the basic skin package.

[0087] In this embodiment, by writing only differentiated skin resources, the redundant resource management function is realized, which enables intelligent optimization of resources. Compared with traditional resource processing technology, it can save storage space, improve resource processing efficiency, reduce maintenance costs, and comprehensively improve the development efficiency of skin packages and the quality of skin resources.

[0088] Furthermore, Figure 4 This is a schematic diagram of the resource update method provided in the embodiments of this application, such as... Figure 4 As shown, it includes the following steps:

[0089] Step 410: Check if the basic resource metadata in the basic skin package has been updated;

[0090] Step 420: If the basic resource metadata is updated, then the resource files in the storage path are updated synchronously.

[0091] Traditional manual or semi-automatic methods of processing skin resources result in redundant resources in new skin packages generated based on the base skin package after resources are deleted or modified. These redundant resources cannot be automatically cleaned up, which can easily cause resource conflicts and further affect the stability and maintenance efficiency of the application.

[0092] In this implementation, a version number can be configured for the base skin package. When the basic resource metadata in the base skin package is updated, the version number will change accordingly, thereby detecting whether the base skin package has been updated.

[0093] Once a change in the version number of the base skin package is detected, an efficient file difference comparison algorithm can be used to accurately locate the changed base resource metadata in the base skin package (e.g., base resource metadata has been deleted, added, or modified). The changed base resource metadata then needs to be updated in the resource files of the application skin package.

[0094] For example, if a base skin package contains a 500dpi application image resource in its res / drawable-{dpi=500} / directory, and an application skin package is built from this base skin package, the application skin package's res / drawable-{dpi=500} / directory will also contain the corresponding 500dpi application image resource. If the 500dpi application image resource in the base skin package is updated, then the 500dpi application image resource in the application skin package's res / drawable-{dpi=500} / directory will also need to be updated accordingly.

[0095] In this embodiment, when resources are deleted or modified in the base skin package, the resource files in the application skin package are updated synchronously, which realizes the automatic update of resources, avoids resource conflicts caused by using resources before the update, ensures the stability of the application, and also improves the maintenance efficiency of the application skin.

[0096] Furthermore, Figure 5 This is a schematic diagram of the skin pack update process provided in the embodiments of this application, such as... Figure 5 As shown, it includes the following steps:

[0097] Step 510: Monitor whether the skin design draft has been updated;

[0098] Step 520: If the skin design draft has been updated, parse the updated skin design draft to obtain the updated resource metadata;

[0099] Step 530: Based on the updated resource metadata and rule base, determine the storage path and name conversion rules corresponding to the updated resource metadata;

[0100] Step 540: Based on the name conversion rules corresponding to the updated resource metadata, perform name conversion on the updated resource metadata and write it into the resource file in the storage path corresponding to the updated resource metadata.

[0101] In practical applications, skin design drafts may be adjusted and updated. For example, the color of the application navigation bar may need to be adjusted and updated. This will cause the resource metadata that has been parsed and processed to no longer be applicable. The system will then need to re-parse the updated skin design draft, wasting system resources.

[0102] In this embodiment, in order to meet the development needs of rapid iteration of mobile applications, if the skin design draft is updated, only the updated resource metadata can be extracted, and then resource processing operations can be performed on it to update the entire application skin package.

[0103] Specifically, the system can monitor the status of skin design drafts in real time through intelligent version comparison and incremental update mechanisms, and identify changes in the skin design drafts by comparing file hash values ​​and timestamps. When a skin design draft is updated, only the changed resources are re-executed through the parsing, mapping, and generation processes.

[0104] If the update of the skin design draft only involves updating the original resource metadata, then only the parsing, mapping and generation process can be re-executed for the updated or changed differentiated resource metadata, and the updated resource metadata can replace the corresponding old resource metadata in the project directory (i.e., the res directory) storage path. If there is new resource metadata, the system can generate the new resource metadata according to the initialization, mapping and generation process, add it to the storage path corresponding to the project directory, and update the resource index and configuration file of the project directory to ensure that the project can correctly identify and use the new skin resources.

[0105] Additionally, if the basic resource metadata in the base skin package changes during this process, redundant resources in the project directory can be cleaned up, and subsequent resource parsing strategies can be adjusted to ensure that the resources in the project directory remain streamlined and consistent with the latest skin design.

[0106] In this embodiment of the application, during the skin design draft update process, automated resource parsing, mapping and generation can completely replace repetitive manual labor, making it easy to quickly update skin resources and meet the development needs of rapid iteration of mobile applications.

[0107] Figure 6 This is a structural diagram of the skin resource processing system provided in the embodiments of this application, such as... Figure 6 As shown, it includes an input layer 61, a processing layer 62, and an output layer 63. The processing layer 62 specifically includes a design draft parsing module 621, a basic skin package resource management module 622, a mapping rule engine 623, an incremental update module 624, and a resource generation module 625. Each layer interacts with the other through standardized interfaces.

[0108] For input layer 61, it supports batch import of skin design files in file formats such as PSD, Sketch, and Figma. The system automatically recognizes the file format to prepare for subsequent parsing.

[0109] The design draft parsing module 621 can call the corresponding parsing library to deeply parse the skin design draft, extract metadata of all types of resources, and generate a resource information library.

[0110] For the mapping rule engine 623, it is used to read resource metadata and generate resource storage paths, names and configuration writing instructions based on the rule base.

[0111] The resource generation module 625 can create a res directory structure according to instructions, and complete resource format conversion, adaptation, and configuration file generation. During the generation process, it interacts in real time with the basic skin package resource management module 622 to determine whether the resource metadata is duplicated with the basic skin package. If it is duplicated, the writing is skipped, and only the differentiated resources are written.

[0112] The incremental update module 624 monitors changes to skin design drafts, compares version differences, and triggers a differentiated update process. When it detects deletion or modification of basic resource metadata in the basic skin package, it collaborates with the basic skin package resource management module 622 to scan the res directory of each skin package, delete redundant resources, and update the resource resolution strategy.

[0113] The basic skin package resource management module 622 is used to store the resource information of the basic skin package, provide resource comparison, redundant resource detection and cleanup instructions, and parsing strategy control functions, serving as the core module for realizing differentiated updates and redundant management.

[0114] Output layer 63 is used to output the res directory of each skin package that conforms to the Android specification. It contains complete and non-redundant resource files and configuration files, which can be directly integrated into the project.

[0115] Figure 7 This is a schematic diagram of the workflow of the skin resource processing system provided in the embodiments of this application, such as... Figure 7 As shown, it includes the following steps:

[0116] Step 710, Initialization Phase. This is used to import the skin design draft and parse out the resource metadata.

[0117] Step 720, Mapping and Generation Stage. This stage is used to match rules in the rule base and write differentiated resource metadata based on those rules.

[0118] Step 730: Monitor changes to the skin design draft.

[0119] Step 740, Dynamic Update and Expansion Phase. This phase handles changes to the skin design draft, cleaning up redundant resources.

[0120] During the initialization phase, users import multiple skin design drafts and basic skin package design drafts. The design draft parsing module automatically identifies the file format, calls the corresponding parser to extract resource metadata, builds a resource information database, and stores the resource information in the basic skin package in the basic skin package resource management module.

[0121] When parsing skin design drafts in multiple formats, for PSD files, the layer structure and styles can be parsed using the Adobe official library; for Sketch files, vector graphics can be obtained through the API and converted into bitmaps; and for Figma files, real-time resource data can be obtained through open interfaces to ensure parsing accuracy.

[0122] During the parsing process, information such as the resource's identifier and version is recorded to facilitate subsequent comparison and update processing with the basic skin package resources.

[0123] During the mapping and generation phases, the mapping rule engine reads resource metadata and matches it with rule generation instructions. The resource generation module creates folders in the `res` directory of each skin package according to these instructions. During resource format conversion, size adaptation, and configuration file writing, the resource generation module compares the resources to be output with the basic skin package resources in the basic skin package resource management module, outputting only the differentiated resources to avoid duplicate generation.

[0124] This includes the use of Extensible Markup Language (XML) structured storage rules, enabling the creation of a graphical interface or customizable configuration files. This allows developers to add resource type mappings, adjust naming templates, and define configuration writing rules. The system dynamically loads these rules, flexibly adapting to different project needs. Additionally, the rule base includes configuration options for comparing and differentiating basic skin package resources.

[0125] In addition, for application image resources, intelligent scaling algorithms can generate multiple versions based on Android screen density, prioritizing compression with appropriate formats and automatically converting to compatible formats if not supported. Font resources are converted to specified formats and styles are defined to ensure compatibility across devices. During resource generation, algorithms such as hash value comparison and file content similarity detection can quickly and accurately determine whether resources are duplicates of the base skin package. During incremental updates, efficient file difference comparison algorithms are used to precisely locate changed resources, achieving efficient differentiated updates and redundant resource cleanup.

[0126] During the dynamic update and expansion phases, the incremental update module monitors the skin design file status in real time after the program is executed. When a change in the skin design is detected, it automatically compares the differences between the old and new versions. If only existing skin package resources are updated, the parsing, mapping, and generation process is re-executed for the updated or changed differentiated resources, and the updated resources replace the corresponding old resources in the project directory. If new skin resources are added, the system will generate the resources for the new skin package according to the initialization, mapping, and generation process, add them to the project directory, and update the resource index and configuration files in the project directory to ensure that the project can correctly identify and use the new skin resources. During this process, if the resources in the basic skin package change, the basic skin package resource management module will work with the incremental update module to clean up redundant resources in each skin package in the project directory and adjust the subsequent resource parsing strategy to ensure that the resources in the project directory remain streamlined and consistent with the latest design.

[0127] This system employs real-time monitoring and intelligent comparison technologies. Utilizing a file system event listening mechanism, it captures modifications and creations of skin design draft files in real time. By calculating file hash values ​​using a hash algorithm and comparing them with timestamps, it quickly and accurately identifies changes to skin design drafts. Simultaneously, by developing a dedicated resource difference comparison algorithm, it can efficiently analyze the specific content and scope of changed resources, providing an accurate basis for subsequent processing.

[0128] In addition, after the system outputs the res directories of each skin package conforming to Android specifications, these resources are placed uniformly into the designated project directory. During the integration process, the system performs integrity checks on the resources to ensure that all skin package resources are accurately integrated into the corresponding locations in the project directory, preparing for subsequent program execution.

[0129] This tool utilizes an automated resource index and configuration file generation system. When a new skin resource is added to the project directory, the resource index is automatically updated, clearly defining the location and relationships of each resource within the project. Simultaneously, it intelligently modifies configuration files based on resource changes, ensuring the project can correctly load and use resources. During resource replacement and redundancy cleanup, the tool also synchronously updates relevant indexes and configurations, guaranteeing consistently orderly resource management within the project directory.

[0130] In this embodiment, the pain points of manual processing of multiple skin resources are solved by a fully automated skin resource processing flow and intelligent mechanism. It replaces repetitive manual labor, greatly improves processing efficiency, avoids human error, and significantly improves the accuracy of resource processing. In addition, by designing an intelligent incremental update mechanism, the system can quickly respond to design changes. Finally, based on the differentiated update and redundant resource management functions of the basic skin package, intelligent optimization of resources is achieved, which can save storage space, improve processing efficiency, reduce maintenance costs, and comprehensively improve development efficiency and resource quality.

[0131] Figure 8 This is a schematic diagram of the structure of the skin resource processing device provided in an embodiment of this application. Figure 8 As shown, the processing apparatus 800 includes:

[0132] The parsing module 810 is used to parse the skin design draft in response to receiving the skin design draft and obtain resource metadata, which includes at least one of application image resources, application skin color resources and application text resources.

[0133] The determination module 820 is used to determine the storage path and name conversion rules corresponding to each type of resource metadata based on a dynamically configured rule base;

[0134] The conversion module 830 is used to convert the names of various resource metadata based on name conversion rules;

[0135] The write module 840 is used to write the name-converted resource metadata into the resource file in the storage path.

[0136] In this embodiment, by automatically parsing the skin design draft and obtaining resource data, the efficiency of resource screening can be improved. By configuring rules in the rule base in advance and automatically adjusting the naming of resources based on the rules, the naming format can be avoided from not conforming to Android specifications. In addition, by automatically writing the renamed resources into the resource files under the corresponding storage path, the problem of resource mismatch caused by errors in traditional manual copying can be avoided, which significantly improves the processing efficiency of skin resources and reduces possible errors in the processing.

[0137] In one alternative approach, the parsing module can specifically be used for:

[0138] A design tool that identifies and generates skin design drafts based on the file format of skin design drafts;

[0139] The skin design drafts are analyzed using the plugin interface of the design tool.

[0140] In one alternative approach, the parsing module can specifically be used for:

[0141] Obtain the image obtained by parsing the skin design draft, as well as the screen density of the application display screen;

[0142] Based on screen density and a preset scaling algorithm, images are scaled to obtain application image resources with different image resolutions.

[0143] In one alternative approach, determining the specific module can be used for:

[0144] Obtain the image resolution of each application's image resources;

[0145] Based on image resolution, determine the storage path for image resources of each application.

[0146] In one alternative approach, the write module can specifically be used for:

[0147] Based on the basic resource metadata in the base skin package, construct the resource files in the storage path;

[0148] Determine whether there is redundant metadata in the metadata of each resource after name conversion. Redundant metadata is the same as the basic resource metadata.

[0149] If redundant metadata exists, the writing process for redundant metadata is skipped.

[0150] In one alternative approach, the resource update module is used for:

[0151] Check if the basic resource metadata in the base skin package has been updated;

[0152] If the basic resource metadata is updated, the resource files in the storage path will be updated synchronously.

[0153] In one alternative approach, a design update module is also included for:

[0154] Monitor whether the skin design drafts have been updated;

[0155] If the skin design draft is updated, the updated skin design draft will be parsed to obtain the updated resource metadata;

[0156] Based on the updated resource metadata and rule base, determine the storage path and name conversion rules corresponding to the updated resource metadata;

[0157] Based on the name conversion rules corresponding to the updated resource metadata, the updated resource metadata is name converted and written to the storage path corresponding to the updated resource metadata.

[0158] Figure 9 The diagram provided is a schematic representation of an electronic device structure according to an embodiment of this application. The specific embodiments of this invention do not limit the specific implementation of the electronic device. Figure 9 As shown, the electronic device may include: one or more processors 901 and a communication interface 903; the one or more processors 901 are used to perform the steps in the above method embodiments.

[0159] The electronic device may also include a memory 902 and a communication bus 904.

[0160] The processor 901, communication interface 903, and memory 902 communicate with each other via communication bus 904. Communication interface 903 is used for communication with other network elements such as clients or other servers. The processor 901 executes program 905, specifically performing the relevant steps in the above method embodiments.

[0161] Specifically, program 905 may include program code comprising computer-executable instructions. Processor 901 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The electronic device may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0162] Memory 902 is used to store program 905. Memory 902 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0163] Specifically, program 905 can be called by processor 901 to cause the electronic device to perform the following operations:

[0164] In response to receiving a skin design draft, the skin design draft is parsed to obtain resource metadata, which includes at least one of application image resources, application skin color resources, and application text resources;

[0165] Based on a dynamically configured rule base, the storage path and name conversion rules corresponding to each type of resource metadata are determined;

[0166] Based on the name conversion rules, the names of each resource metadata are converted;

[0167] Write the renamed resource metadata to the storage path corresponding to the resource metadata.

[0168] This invention provides a computer-readable storage medium storing at least one executable instruction that, when executed on an electronic device or encryption device, causes the electronic device or encryption device to perform the method described in any of the above-described method embodiments. The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, this invention is not directed to any particular programming language.

[0169] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0170] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0171] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0172] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for processing skin resources, characterized in that, The method includes: In response to receiving a skin design draft, the skin design draft is parsed to obtain resource metadata, which includes at least one of application image resources, application skin color resources, and application text resources; Based on a dynamically configured rule base, the storage path and name conversion rules corresponding to each type of resource metadata are determined; Based on the aforementioned name conversion rules, the names of each resource metadata are converted; Write the renamed resource metadata into the storage path corresponding to the resource metadata.

2. The method according to claim 1, characterized in that, The process of parsing the skin design draft includes: A design tool that identifies and generates the skin design draft based on its file format. The skin design draft is parsed using the plugin interface of the design tool.

3. The method according to claim 1, characterized in that, Obtaining the application image resources includes: Obtain the image obtained by parsing the skin design draft, and the screen density of the application display screen; Based on the screen density and the preset scaling algorithm, the image is scaled to obtain application image resources with different image resolutions.

4. The method according to claim 2, characterized in that, Determining the storage path corresponding to the application image resources includes: Obtain the image resolution of each application's image resources; Based on the image resolution, the storage path for each application's image resources is determined.

5. The method according to claim 1, characterized in that, The step of writing the name-converted resource metadata into the storage path corresponding to the resource metadata includes: Based on the basic resource metadata in the base skin package, construct the resource files in the storage path; Determine whether there is redundant metadata in each resource metadata after name conversion, wherein the redundant metadata is the same as the basic resource metadata; If the redundant metadata exists, the writing process for the redundant metadata is skipped.

6. The method according to claim 5, characterized in that, The method further includes: Detect whether the basic resource metadata in the basic skin package has been updated; If the basic resource metadata is updated, the resource files in the storage path are updated synchronously.

7. The method according to claim 1, characterized in that, The method further includes: Monitor whether the skin design draft has been updated; If the skin design draft is updated, the updated skin design draft is parsed to obtain the updated resource metadata; Based on the updated resource metadata and the rule base, determine the storage path and name conversion rules corresponding to the updated resource metadata; Based on the name conversion rules corresponding to the updated resource metadata, the updated resource metadata is name converted and written to the storage path corresponding to the updated resource metadata.

8. A processing device utilizing skin resources, characterized in that, The device includes: The parsing module is used to parse the skin design draft in response to receiving the skin design draft and obtain resource metadata, wherein the resource metadata includes at least one of application image resources, application skin color resources and application text resources; The determination module is used to determine the storage path and name conversion rules corresponding to each type of resource metadata based on a dynamically configured rule base; The conversion module is used to convert the names of various resource metadata based on the name conversion rules; The writing module is used to write the name-converted resource metadata into the resource file in the storage path.

9. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on an electronic device or apparatus, causes the electronic device or apparatus to perform the operation of the method as described in any one of claims 1-7.

Images