Cache key generation method, icon path acquisition method and electronic equipment

Abstract

The invention discloses a cache key generation method, an icon path acquisition method and electronic equipment, and the method comprises the steps: acquiring an icon information file, and extracting an application package name, a version number, an icon path and a priority type from the icon information file; and generating a composite cache key by using the application package name, the version number, the icon path and the priority type. According to the method, a simple file path is not used as a cache key any more, but the composite cache key is constructed by using the application package name, the version number, the icon path and the priority type, so that the cache hit rate of the icon is increased, and APK icon analysis cache can be executed efficiently, accurately and monitorably in a server environment.

Description

Technical Field

[0001] This invention relates to the field of mobile application development technology, and in particular to a method for generating cache keys, a method for obtaining icon paths, and an electronic device. Background Technology

[0002] On Android devices or in development environments, developers can easily obtain rendered icon bitmaps via system APIs, but this method heavily relies on the Android runtime environment. In server-side scenarios, due to the inability to call system APIs and the lack of a rendering engine, it's difficult to retrieve the required icon from the cache. Developers must then implement APK icon parsing and composition themselves, posing significant technical challenges. Furthermore, in related technologies that utilize caching for application icon parsing and composition, the cache key design is simple and lacks intelligent cache eviction strategies. This results in a low cache hit rate when the server searches for the application icon in the cache using the cache key, leading to low application icon parsing efficiency. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a cache key generation method, an icon path acquisition method, and an electronic device, thereby improving the cache hit rate of icons.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A cache key generation method, applied to a cloud server, the method comprising: Obtain the icon information file, and extract the application package name, version number, icon path, and priority type from the icon information file; A composite cache key is generated using the application package name, the version number, the icon path, and the priority type.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A method for obtaining icon paths, including the following steps: Receive an icon caching request, and generate a composite cache key based on the icon information file in the icon caching request using the cache key generation method; Check if the composite cache key exists in the cache. If it exists, retrieve the icon from the cache based on the composite cache key. If it does not exist, then the icon information file is parsed to obtain the icon, and the composite cache key and the icon are stored in the cache.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the above-described cache key generation method and icon path acquisition method.

[0007] The beneficial effects of this invention are as follows: It obtains an icon information file, extracts the application package name, version number, icon path, and priority type from the icon information file, and generates a composite cache key using the application package name, version number, icon path, and priority type. This application no longer uses a simple file path as the cache key, but instead constructs a composite cache key using the application package name, version number, icon path, and priority type. This not only improves the icon cache hit rate but also enables efficient, accurate, and monitorable execution of APK icon parsing and caching in a server-side environment. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the steps of a cache key generation method provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a cache key generation method provided in an embodiment of the present invention. Figure 3 A cache key structure diagram of a cache key generation method provided in an embodiment of the present invention; Figure 4 A flowchart illustrating the steps of an icon path acquisition method provided in an embodiment of the present invention; Figure 5 This is a flowchart illustrating an icon path acquisition method provided in an embodiment of the present invention. Figure 6 A flowchart illustrating the cache configuration management of an icon path acquisition method provided in this embodiment of the invention; Figure 7 A flowchart illustrating the cache performance monitoring of an icon path acquisition method provided in this embodiment of the invention; Figure 8 This is a flowchart illustrating the cache configuration update process for an icon path acquisition method provided in an embodiment of the present invention. Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] In related technologies, the cache key design for application icon parsing and synthesis using caching technology is simple and lacks an intelligent cache eviction strategy. This leads to a low cache hit rate when the server searches for the application icon in the cache using the cache key, resulting in low application icon parsing efficiency. Specifically, the following problems exist in APK icon parsing caching in related technologies: (1) Simple cache key design: Related technologies use simple file paths as cache keys, which cannot distinguish between different versions of the same application; (2) Single caching strategy: lack of intelligent cache eviction strategy, which can easily lead to memory overflow; (3) Low hit rate: The poor design of the cache key leads to a low cache hit rate; (4) Lack of performance monitoring: There is a lack of monitoring and statistical mechanisms for cache performance.

[0014] Therefore, there is an urgent need for an efficient, accurate, and monitorable APK icon parsing and caching technology in a server-side environment to support the massive processing needs of scenarios such as app stores and cloud testing platforms.

[0015] To address the aforementioned problems, this application provides a method for generating cache keys, a method for obtaining icon paths, and an electronic device. The cache key generation method of this application is described in detail below.

[0016] The cache key generation method in this application can be used to generate a cache key stored in the local cache for the application icon during the application icon parsing and compositing process. The electronic device in this application can be a mobile terminal, computer, IoT device, or embedded system, such as a mobile phone, tablet computer, laptop computer, or smartwatch.

[0017] The cache key generation method of this invention is described in detail below, with reference to the appendix. Figure 1 and attached Figure 2 This includes steps S110-S120.

[0018] S110. Obtain the icon information file and extract the application package name, version number, icon path, and priority type from it. The icon information file can be an Android application package (APK) file or an application manifest file. The application package name serves as a unique identifier for the application, such as "com.example.application". The version number identifies the application version, such as 1001. The icon path is the storage path of the icon resource within the application package, such as "res / drawable-hdpi / ic_launcher.png". The priority type is the icon resource format type, selected from, but not limited to, PNG format, adaptive icon format, vector icon format, and WEBP format.

[0019] S120. Generate a composite cache key using the application package name, version number, icon path, and priority type. This composite cache key serves as a unique identifier for the application's icon resource within the icon caching system.

[0020] In this way, by obtaining the icon information file and extracting the application package name, version number, icon path, and priority type from it, all the key information needed to generate the cache key can be accurately obtained from the application installation package. By generating a composite cache key using the application package name, version number, icon path, and priority type, and combining five-dimensional data of package name, version number, path, type, and timestamp with standardization and hashing, cache key conflicts are avoided at the source, effectively improving the icon cache hit rate. Moreover, it enables efficient, accurate, and monitorable execution of APK icon parsing and caching in a server-side environment.

[0021] In one embodiment of this application, step S120 includes steps S121 to S123.

[0022] S121. Standardize the application package name, format the version number, standardize the icon path, and encode the priority type to form the first cache key. Specifically, convert the application package name to all lowercase and replace empty or invalid values ​​with a predefined default value "unknown". For example, standardize "COM.EXAMPLE.APP" to "com.example.app". Directly convert the version number to string form. For example, format the integer version number 1001 as the string "1001". Replace the path separator in the icon path with an underscore character. For example, standardize "res / drawable / ic_launcher.png" to "res_drawable_ic_launcher.png". According to the predefined encoding mapping table, convert the icon type to the corresponding short code. For example, encode PNG type as "png" and adaptive icon type as "adaptive".

[0023] S122. Add a timestamp to the first cache key to generate the second cache key. Specifically, obtain the current system time or the timestamp of a preset time point, and append the timestamp to the end of the first cache key using a separator. The timestamp can use the Unix timestamp format, accurate to the second or millisecond level. For example: First cache key: "com.example.app_1001_res_drawable_ic_launcher.png_png", timestamp: "1640995200", then the second cache key generated by adding the timestamp to the first cache key is: "com.example.app_1001_res_drawable_ic_launcher.png_png_1640995200". S123. Calculate the hash value of the second cache key to generate a composite cache key. Specifically, the hash algorithm can be the MD5 message digest algorithm, or SHA-1, SHA-256, or other hash functions with good distribution characteristics. Convert the second cache key string into a byte sequence using UTF-8 character encoding. Calculate the byte sequence using the selected hash algorithm to generate a fixed-length hash value. Convert the calculated hash value byte array into a hexadecimal string representation. For example, after MD5 hashing the second cache key "com.example.app_1001_res_drawable_ic_launcher.png_png_1640995200", the composite cache key "d41d8cd98f00b204e9800998ecf8427e" is generated.

[0024] In this way, by standardizing application package names, formatting version numbers, standardizing icon paths, and encoding priority types, a first cache key is formed. By standardizing and orderly combining each information element, a first cache key with a unified format and defined structure is generated, effectively avoiding ambiguity caused by inconsistent information formats or unpredictable order. By adding a timestamp to the first cache key, a second cache key is generated. Introducing time-dimensional information into the cache key makes it time-sensitive, providing a technical foundation for implementing time-based cache invalidation strategies, version control strategies, and cache update mechanisms. By hashing the second cache key, a composite cache key is generated. Through hash transformation, the variable-length second cache key is converted into a fixed-length composite cache key. This not only solves the key length limitations imposed by storage systems such as file systems and databases, but also enhances the uniqueness, security, and storage efficiency of the cache key through the unidirectional and uniform distribution characteristics of hash algorithms.

[0025] In one embodiment of this application, step S121 includes: sequentially combining the standardized application package name, formatted version number, standardized icon path, and encoded priority type using a delimiter to form a first cache key. Specifically, refer to the appendix... Figure 3 Use underscores as delimiters and connect elements in the order of "package name_version number_icon path_type encoding". For example, normalized package name: "com.example.app", formatted version number: "1001", normalized icon path: "res_drawable_ic_launcher.png", type encoding: "png", combined to generate the first cache key: "com.example.app_1001_res_drawable_ic_launcher.png_png".

[0026] In this way, the standardized application package name, formatted version number, standardized icon path, and encoded priority type are connected and combined in sequence using a separator to form the first cache key. By using underscore characters as separators to connect each information element in sequence, problems caused by special characters in the cache key can be effectively avoided, and the consistency of the cache key can be ensured in different operating system environments.

[0027] In one embodiment of this application, an icon path acquisition method is also included, as shown in the attached document. Figure 4 and attached Figure 5 This includes steps H110 to H130.

[0028] H110: Receive icon caching request. Based on the icon information file in the icon caching request, generate a composite cache key using the cache key generation method described above. Specifically, when a user launches an application or the system needs to display an application icon, the caching system receives the icon caching request and calls the cache key generation method to generate the final composite cache key. For example, the composite cache key is "d41d8cd98f00b204e9800998ecf8427e".

[0029] H120. Check if a composite cache key exists in the cache. If it does, retrieve the icon from the cache based on the composite cache key. Specifically, use the generated composite cache key as the query keyword to perform a key-value matching query in the memory cache. When an entry that exactly matches the composite cache key is found in the memory cache, it is considered a cache hit. The memory cache uses the Least Recently Used (LRU) cache algorithm to manage the storage and access of icon bitmap objects in system memory. When a cache lookup hits, the system performs the following operations: using the composite cache key as the query keyword, perform a key-value matching operation in the hash table or mapping table of the memory cache data structure; when a cache entry that exactly matches the composite cache key is found in the memory cache, directly return the address reference of the icon bitmap object associated with the composite cache key in the heap memory; simultaneously update the last access timestamp and access frequency counter of the cache entry to maintain the sorting information required for the LRU eviction policy. For example, when querying the composite cache key "d41d8cd98f00b204e9800998ecf8427e", if a corresponding cache entry exists in the memory cache, a reference to the icon bitmap object (such as a Bitmap object) is returned directly.

[0030] H130. If not present, perform icon parsing on the icon information file to obtain the icon, and save the composite cache key and icon in the cache. Specifically, the steps for performing icon parsing include: locating the target icon resource file in the file system based on the resource path information recorded in the icon information file; identifying the storage format and encoding method of the icon information file, including but not limited to PNG, JPEG, WEBP, vector graphics, and adaptive icon formats; extracting key data information from the icon information file, including icon size, color depth, transparency information, and compression ratio; calling the corresponding decoder to decode the icon information file according to the identified icon format to generate renderable icon data; optimizing the decoded icon data according to the characteristics and performance requirements of the target display device, including size scaling, color space conversion, and transparency processing; and verifying the integrity and usability of the parsed icon data to ensure that the icon data meets the rendering requirements. Allocate storage space for new icon data in the cache storage area, and the size of the storage space is dynamically determined according to the actual size of the icon data; convert the parsed icon data into a serialization format suitable for cache storage; establish a mapping relationship between the composite cache key and the storage location of the icon data, and update the cache index structure; update the cache capacity usage statistics and trigger relevant cache management and eviction policy checks.

[0031] In this approach, by receiving icon caching requests, a composite cache key is generated based on the icon information file in the request using the aforementioned cache key generation method. This composite cache key is generated based on the multi-dimensional characteristics (package name, version number, path, type) of the icon information file, ensuring that multiple requests for the same icon always generate the same cache key, guaranteeing cache consistency. Simultaneously, the cache key can identify icons from different applications, versions, and types, preventing cache conflicts caused by similar package names or overlapping paths. Furthermore, it supports parallel caching of icons from multiple versions of the same application. The cache is checked for the existence of the composite cache key. If it exists, the icon is retrieved from the cache based on the composite cache key; otherwise, icon parsing is performed on the icon information file to obtain the icon. The composite cache key and the icon are stored in the cache. The uniqueness of the composite cache key greatly improves the cache hit rate. When a cache hit occurs, the memory address reference of the icon bitmap object is directly returned, reducing icon parsing calculations and significantly improving icon loading speed.

[0032] In one embodiment of this application, step H130 includes steps H131 to H132.

[0033] H131. Parse the icon information file to obtain the icon path, retrieve the icon based on the icon path, and return the icon. Specifically, based on the standardized icon path, perform a binary search in the resource index table of the application installer (APK) to locate the exact storage location of the icon resource, including the resource ID, file offset, and data length. For example, for the path "res / drawable-hdpi / ic_launcher.png", search for the corresponding resource entry in the resources.arsc file of the application installer (APK). Extract the raw byte data of the icon resource from the application installer (APK) based on the exact storage location of the icon resource. For example, read 8192 bytes of PNG format data at file offset 0x123456 in the application installer (APK) file. Based on the priority type, the corresponding decoder is invoked to decode the raw byte data and obtain the icon bitmap. For example, if the priority type is PNG format, a decoder (such as the libpng library or the Android BitmapFactory library) is invoked to decode it into an icon bitmap object (such as a Bitmap object). If the priority type is an adaptive icon, the foreground and background images are decoded separately, and a mask is applied to synthesize the final icon. If the priority type is a vector icon, SVG or XML vector data is parsed and rasterized into a bitmap of a specified resolution. The decoded icon bitmap is then processed with resizing, color space conversion, and transparency optimization to generate the final icon that meets display requirements.

[0034] H132. Associate the icon with the composite cache key and store it in the cache. Specifically, serialize the icon appropriately, for example, by directly storing a reference (such as a Java reference or Kotlin reference) to the icon bitmap object (such as a Bitmap object) in the memory cache. Store the serialized icon in the memory cache and establish a key-value association. For example, in the memory cache, call the HashMap.put() method to associate the composite cache key with the reference to the icon bitmap object. In practical applications, the memory cache also stores the icon's access timestamp (e.g., recording the cache creation time), icon size information (e.g., width, height, color depth), original resource path, and access statistics. The original resource path can be used for debugging and verification, and the access statistics are initialized to the first access state.

[0035] In this way, the icon path is obtained by parsing the icon information file, the icon is obtained according to the icon path, and the icon is returned. The icon is associated with the composite cache key and stored in the cache so that when the cache is hit in the future, the icon corresponding to the composite cache key can be matched immediately, which improves the efficiency of icon retrieval in the cache.

[0036] In one embodiment of this application, an icon path acquisition method further includes: checking whether the cache size exceeds a cache threshold; if so, executing a least recently used eviction policy until the cache size is less than or equal to the cache threshold. Specifically, before storing a new icon in the cache each time, the current memory or disk space occupied by the cache is checked, and a cache threshold is set, for example, a maximum memory usage of 512MB or a maximum number of entries of 10,000. The current usage of the cache is detected in real time or periodically. The cache threshold is a preset dynamic threshold, which can be limited by the total amount and proportion of available memory of the device, for example, not exceeding 25% of the available memory. Alternatively, the dynamic threshold can be set according to the remaining memory space to ensure that there is enough memory cache space for application operation. When the cache size is detected to exceed the threshold, for example, the current cache has 10,050 entries, exceeding the threshold of 10,000, a sorted linked list from least recently accessed to most recently accessed is constructed. Starting from the tail of the linked list, the least recently accessed cache entries are removed one by one. Each time an entry is removed, the current cache size statistics are updated. This process is repeated until the cache size is lower than the threshold (e.g., reduced to 9,500 entries). After the least recently used eviction policy is executed, the newly parsed icon and composite cache key are stored in the cache, and its access time is updated to the current time and placed at the head of the linked list.

[0037] In this way, by checking whether the cache size exceeds the cache threshold, if so, the least recently used eviction policy is executed until the cache size is less than or equal to the cache threshold. Before each cache storage operation, a capacity check is performed to ensure that there is enough cache space to cache new icons. The least recently used eviction policy evicts the least recently accessed cache entries to evict cache data that is least likely to be accessed again.

[0038] In one embodiment of this application, reference is made to the appendix. Figure 6Before step H110, the process includes: reading cache configuration parameters from the cache configuration; setting cache thresholds, cache expiration times, and cache eviction policies based on the cache configuration parameters; and starting monitoring to listen to cache performance status. Specifically, the cache system is initialized, and the cache manager performs a system self-check to verify whether the operating environment meets the minimum requirements of the cache system, including storage space availability checks, memory capacity verification, and permission configuration verification. A default configuration parameter set is loaded from a local cache configuration file (such as JSON, XML, or Properties format), the application's built-in default configuration file, or the system initialization settings file. This default configuration parameter set includes predefined minimum cache capacity, basic data expiration times, standard eviction policies, and basic monitoring parameters, forming the system baseline configuration. User-defined configuration parameters are read from a user-specified configuration source, which includes at least one of local configuration files, remote configuration servers, environment variables, or database storage configurations, to obtain configuration parameters customized by the user for specific application scenarios. The system validates the read user configuration parameters, including: checking if the format of the configuration parameters conforms to predefined specifications; verifying if numeric parameters are within the allowed value range; checking if the dependencies between related configuration parameters are satisfied; and ensuring that all required configuration parameters are provided and not null. When all user configuration parameters pass validation, the user configuration is deemed valid and used as the system's runtime configuration. When any user configuration parameter fails validation, the user configuration is deemed invalid, and the default configuration parameters are used as the system's runtime configuration. A configuration application decision log is generated, recording the configuration validity judgment results and specific reasons. Based on the determined valid configuration parameters, the system performs initialization operations on the core components of the caching system, including: allocating system memory space according to the configured cache capacity parameters; initializing the cache item storage container and index structure; and establishing a connection between the caching system and the underlying storage resources. The system sets the cache threshold, cache expiration time, and cache eviction policy according to the configuration parameters.

[0039] In this way, by reading the cache configuration parameters in the cache configuration, setting the cache threshold, cache expiration time and cache eviction policy according to the cache configuration parameters, and starting monitoring to listen to the cache performance status, it is possible to dynamically adjust resource allocation at runtime according to changes in cache configuration, and monitor and promptly discover and resolve performance issues in real time.

[0040] In one embodiment of this application, reference is made to the appendix. Figure 7 One method for obtaining icon paths also includes steps M110 to M130.

[0041] M110 performs statistics on cache hit rate, average response time, and memory usage. Specifically, during cache read and write operations, the following statistical information recording operations are performed synchronously: Precise timestamps are recorded for each cache operation, including the start and end times, and the operation time is calculated; statistical counters related to cache operations are updated. These counters include: a cache hit counter (recording the number of times data was successfully retrieved from the cache); a cache miss counter (recording the number of times requested data was not found in the cache); a cache write counter (recording the number of times data was written to the cache); a cache eviction counter (recording the number of times data was removed due to capacity limitations); and an error counter (recording the number of times operations failed). The hit rate percentage is calculated based on the ratio of cache hits to total accesses. The average response time is calculated based on the ratio of the total time of all cache operations to the number of operations. The ratio of the memory space occupied by the cache system to the total allocated memory space is monitored as memory usage.

[0042] M120 generates performance reports based on cache hit rate, average response time, and memory usage. Using cache hit rate, average response time, and memory usage as performance metrics, it generates performance reports according to a preset report template and format. The performance reports may include a summary of performance metric values, performance trend charts, and performance evaluation conclusions.

[0043] M130: Based on the performance report, adjust the cache eviction policy and update the configuration parameters. Specifically, refer to the appendix... Figure 8If the performance report displays a performance alarm, an alarm notification is issued, and new configuration parameters are set. The cache size, cache expiration time, and cache eviction policy are updated based on the new configuration parameters. The performance metrics in the current performance report are compared with preset alarm thresholds to determine if any performance anomalies exist. If all three conditions are met simultaneously—cache hit rate higher than the preset minimum hit rate threshold, average response time lower than the preset maximum response time threshold, and memory usage lower than the preset safe utilization rate threshold—it is considered a performance alarm-free system, allowing the monitoring system to continue operating normally and executing the next cycle of monitoring data collection and analysis. If any one of the following three conditions is met—cache hit rate lower than the preset minimum hit rate threshold, average response time higher than the preset maximum response time threshold, or memory usage exceeding the preset safe utilization rate threshold—a performance alarm is displayed in the performance report, and an alarm notification is issued. The alarm notification includes the alarm level, alarm metric, current value, threshold standard, and occurrence time, and is sent through preset notification channels, including email, SMS, system logs, and instant messaging. Adjust the cache eviction algorithm or related configuration parameters based on changes in cache hit rate, adjust the cache capacity allocation strategy based on changes in memory usage, adjust the data expiration time setting based on cache data access patterns, update the cache system's running configuration parameters based on the policy adjustment results, and record historical information on configuration changes, including change time, change content, change reason, and change effect.

[0044] This approach statistically analyzes cache hit rate, average response time, and memory usage to measure the complete time of each cache operation from start to finish. Cache hit rate reflects cache effectiveness, average response time comprehensively assesses cache processing speed, and memory usage monitoring prevents memory overflow risks. Performance reports are generated based on cache hit rate, average response time, and memory usage, converting raw statistical data into standardized performance metrics. This allows for comparison of current and historical data, quickly identifying trends and anomalies. Based on the performance reports, cache eviction policies are adjusted and configuration parameters are updated. Simultaneously, the three key metrics—hit rate, response time, and memory usage—are monitored. Alarm thresholds are dynamically adjusted based on historical data and system status, and alarm notifications are sent based on these thresholds for timely alarm handling. Updates to cache size, cache expiration time, and cache eviction policies based on new configuration parameters enable timely adjustments to cache configurations through alarms, facilitating performance optimization and problem diagnosis.

[0045] Please refer to the appendix. Figure 9The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored on the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the cache key generation method and the various steps in the icon path acquisition method described above.

[0046] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0047] In summary, this application utilizes five-dimensional data—application package name, version number, icon path, priority type, and timestamp—to standardize and orderly combine this data, generating cache keys with a unified format and defined structure. This effectively avoids ambiguity caused by inconsistent information formats or unpredictable order. The cache key can identify icons from different applications, versions, and types, preventing cache conflicts due to similar package names or overlapping paths. Furthermore, it supports parallel caching of multiple versions of icons for the same application and, through hashing, fundamentally avoids cache key conflicts, effectively improving the icon cache hit rate. When a cache hit occurs, the memory address reference of the icon bitmap object is directly returned, reducing icon parsing calculations and significantly improving icon loading speed. By performing a capacity check before each cache storage operation, sufficient cache space is ensured for caching new icons. A least recently used eviction policy evicts the least accessed cache entries, eliminating cache data least likely to be accessed again, effectively preventing memory overflow issues. Based on cache hit rate, average response time, and memory usage, a performance report is generated, converting raw statistical data into standardized performance metrics. This allows for comparison of current and historical data, quickly identifying trends and anomalies. Based on the performance report, cache eviction policies are adjusted and configuration parameters are updated. Simultaneously, three key metrics—hits rate, response time, and memory usage—are monitored. Alarm thresholds are dynamically adjusted based on historical data and system status, and alarm notifications are sent based on these thresholds, enabling timely alarm handling. The cache size, cache expiration time, and cache eviction policy are updated based on new configuration parameters, allowing for timely adjustments to cache configuration through alarms, facilitating performance optimization and problem diagnosis. Therefore, this application achieves efficient, accurate, and monitorable execution of APK icon parsing caching in a server-side environment.

[0048] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for generating cache keys, characterized in that, Applied to cloud servers, the method includes: Obtain the icon information file, and extract the application package name, version number, icon path, and priority type from the icon information file; A composite cache key is generated using the application package name, the version number, the icon path, and the priority type.

2. The cache key generation method according to claim 1, characterized in that, Generating a composite cache key using the application package name, the version number, the icon path, and the priority type includes: The application package name is standardized, the version number is formatted, the icon path is standardized, and the priority type is encoded and combined to form the first cache key; Add a timestamp to the first cache key to generate the second cache key; The second cache key is hashed to generate a composite cache key.

3. The cache key generation method according to claim 2, characterized in that, Encoding the application package name, version number format, icon path standardization, and priority type to form the first cache key includes: The standardized application package name, the formatted version number, the standardized icon path, and the encoded priority type are sequentially connected and combined using a separator to form the first cache key.

4. A method for obtaining icon paths, characterized in that, include: Receive an icon caching request, and generate a composite cache key based on the icon information file in the icon caching request using any one of the cache key generation methods described in claims 1 to 3; Check if the composite cache key exists in the cache. If it exists, retrieve the icon from the cache based on the composite cache key. If it does not exist, then the icon information file is parsed to obtain the icon, and the composite cache key and the icon are stored in the cache.

5. The icon path acquisition method according to claim 4, characterized in that, Performing icon parsing on the icon information file to obtain icons, and storing the composite cache key and the icon in the cache includes: Parse the icon information file to obtain the icon path, retrieve the icon based on the icon path, and return the icon; The icon is associated with the composite cache key and stored in the cache.

6. The icon path acquisition method according to claim 4, characterized in that, Also includes: Check if the cache size exceeds the cache threshold. If so, execute the least recently used eviction policy until the cache size is less than or equal to the cache threshold.

7. The icon path acquisition method according to claim 4, characterized in that, The process of receiving icon caching requests also includes: Read the cache configuration parameters from the cache configuration; Set the cache threshold, cache expiration time, and cache eviction policy according to the cache configuration parameters, and start monitoring to listen to the cache performance status.

8. The icon path acquisition method according to claim 4, characterized in that, Also includes: Statistics were compiled on cache hit rate, average response time, and memory usage. A performance report is generated based on the cache hit rate, the average response time, and the memory usage. Based on the performance report, adjust the cache eviction policy and update the configuration parameters.

9. The icon path acquisition method according to claim 8, characterized in that, Based on the performance report, adjusting the caching strategy and updating the configuration parameters includes: If the performance report displays a performance alarm, an alarm notification is issued and new configuration parameters are set; Update the cache size, cache expiration time, and cache eviction policy based on the new configuration parameters.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the cache key generation method according to any one of claims 1 to 3 and the icon path acquisition method according to any one of claims 4 to 9.

Images