Application program optimization method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an application program optimization method and device, electronic equipment and a storage medium. The method comprises the following steps: collecting resource calling data of an application program on user equipment; identifying a to-be-optimized resource set based on the resource calling data; executing optimization processing on the to-be-optimized resource set to obtain an optimized target application program; wherein the optimization processing comprises resource removal or resource relocation. Compared with a traditional static analysis method, the method has the advantages that through a data analysis mode driven by user behaviors, the risk of function missing possibly caused by blind deletion of resources is avoided, and more accurate and safer application program optimization is realized. Besides, for the resources which are used at low frequency but are still necessary to be reserved, the optimization of the initial packet volume is realized while the functional integrity is maintained through a processing mode of resource relocation instead of simple deletion, and the relationship between the user experience and the resource efficiency is balanced.

Description

Technical Field

[0001] This disclosure relates to the field of application development technology, and in particular to application optimization methods, apparatus, electronic devices, and storage media. Background Technology

[0002] This section is intended to provide background or context for embodiments of the invention as set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] With the rapid development of the mobile internet, the complexity of application functions is constantly increasing, and the number of resource files such as code, images, audio, and video is growing exponentially. Related technologies for reducing application size include code obfuscation and compression, resource file optimization, and modular decomposition of functions. However, these methods have some limitations: static analysis tools struggle to cover the dynamic differences in actual user scenarios; while dynamic loading schemes can reduce the initial package size, they may increase user waiting time, affecting the user experience; third-party libraries integrated into applications often contain redundant resources that are not actually called, and due to a lack of precise monitoring, all resources are often retained to avoid compatibility risks, leading to unnecessary package expansion. Furthermore, related technologies lack global analysis of resource dependencies, which may lead to accidental deletion of resources and cause functional abnormalities. Summary of the Invention

[0004] In this context, embodiments of the present invention aim to provide an application optimization method, apparatus, electronic device, and storage medium to at least partially address the aforementioned problems existing in the related art.

[0005] In a first aspect of the present invention, an application optimization method is provided, comprising: collecting resource call data of the application on a user device; identifying a set of resources to be optimized based on the resource call data; performing optimization processing on the set of resources to be optimized to obtain an optimized target application; wherein the optimization processing includes resource removal or resource relocation.

[0006] In a second aspect of the present invention, an application optimization apparatus is provided, comprising: a data acquisition module for acquiring resource call data of an application on a user device; a data analysis module for identifying a set of resources to be optimized based on the resource call data; and a resource optimization module for performing optimization processing on the set of resources to be optimized to obtain an optimized target application; wherein the optimization processing includes resource removal or resource relocation.

[0007] In a third aspect of the present invention, an electronic device is provided, comprising: a memory storing computer-executable instructions executable by a processor; and a processor for executing the computer-executable instructions to perform the steps in any of the above-described application optimization methods.

[0008] In a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps of any of the above-described application optimization methods.

[0009] This disclosure obtains the true state of resource usage by collecting actual resource call data of the application on the user's device, rather than relying solely on inferences from static code analysis. Based on this dynamically collected resource call data, unused or infrequently used resources in the application can be accurately identified, thus forming a targeted set of resources to be optimized. Performing optimization processing such as removal or relocation on these resources can effectively reduce the application package size while ensuring the integrity of application functionality, thereby reducing user download waiting time, reducing device storage space usage, and improving application installation conversion rate and user retention rate. Compared with traditional static analysis methods, this solution, through a user behavior-driven data analysis model, avoids the risk of functional loss that may result from blindly deleting resources, achieving more accurate and secure application optimization. Furthermore, for infrequently used but still necessary resources, resource relocation rather than simple deletion optimizes the initial package size while maintaining functional integrity, balancing user experience and resource efficiency. Attached Figure Description

[0010] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein:

[0011] Figure 1 A schematic diagram illustrating the implementation environment of an application optimization method provided in this embodiment of the disclosure;

[0012] Figure 2 A flowchart illustrating an application optimization method provided in this disclosure embodiment;

[0013] Figure 3 This is a schematic diagram of the structure of an application optimization device provided in an embodiment of the present disclosure;

[0014] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure.

[0015] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0019] Figure 1A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a graphical user interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing application services in this exemplary embodiment; it may be a single server or a cluster of multiple servers. For example, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this disclosure can be executed by any one or more of the terminal device 110 and the server 120.

[0020] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications can run under the cloud interaction system, such as cloud gaming. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0021] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0022] With the rapid development of the mobile internet, the functionality of apps is becoming increasingly complex, and the number of resource files they contain, such as code, images, audio, and video, is growing exponentially. Excessively large app installation packages lead to longer download times and excessive device storage space consumption, significantly reducing user download willingness and retention rates. Statistics show that for every 10MB increase in package size, the conversion rate of potential users may decrease by 5%-10%. Therefore, reducing app size has become one of the core optimization directions in mobile application development.

[0023] Common methods for reducing package size in related technologies include code obfuscation and compression (such as ProGuard), resource file optimization (such as WebP format conversion), and modular functional decomposition (such as dynamic loading or on-demand downloading). However, these methods have the following limitations:

[0024] Static analysis solutions rely on developers manually marking or static code scanning to identify redundant resources, which makes it difficult to cover the dynamic differences in actual user scenarios. For example, some low-frequency functional modules may have low usage rates but may have to be retained due to legal compliance requirements; while some redundant resources (such as legacy files of obsolete functions) may not be detected by static analysis tools due to complex call chains.

[0025] While adopting a dynamic loading scheme for functional modules can reduce the initial package size, it requires additional design of resource loading logic, increases the number of network requests and waiting time for users, and may even lead to function interruption and affect the fairness of APP use.

[0026] In app development, numerous third-party libraries are often integrated (such as advertising SDKs and analytics tools). These libraries typically contain redundant resources that are not actually used (such as multilingual files and image resources for different screen densities). Due to a lack of precise monitoring of the usage of these third-party library resources, related technologies often choose to retain all resources to avoid compatibility risks, resulting in an unnecessary increase in the app package size.

[0027] Furthermore, the relevant technologies lack a global analysis of resource dependencies. For example, a low access rate for a certain function page may be due to a hidden entry point or a user experience defect, rather than the redundancy of the function itself. Directly deleting the relevant resources may cause the function to become unusable.

[0028] In view of this, this disclosure aims to provide a dynamic, data-driven package size reduction solution that can accurately identify removable resources based on real user behavior data, and at the same time combine resource call chain analysis and third-party library compatibility verification to minimize package size while ensuring functional integrity.

[0029] See Figure 2According to one embodiment of this disclosure, an application optimization method is provided, comprising: collecting resource call data of the application on a user device; identifying a set of resources to be optimized based on the resource call data; performing optimization processing on the set of resources to be optimized to obtain an optimized target application; wherein the optimization processing includes resource removal or resource relocation. In this way, by analyzing real user behavior data to identify optimizable resources, precise reduction in application size is achieved, effectively reducing the installation package size and increasing user download willingness and application performance.

[0030] Optionally, an application refers to a software program that can run on mobile devices, tablets, or other computing devices, especially mobile applications (APPs). These applications typically contain a large number of resource files, such as images, audio, video, animations, style sheets, and scripts. With feature iterations and version updates, the number of these resource files grows exponentially, causing the application installation package size to continuously expand.

[0031] Optionally, resource call data refers to detailed records of the actual use of various resource files during the application's operation on the user's device. This data includes, but is not limited to, the resource's unique identifier (e.g., resource ID), call timestamp, call frequency, call context (e.g., the page or functional module it resides on), and relevant information about the calling device (e.g., device model, system version). By embedding resource reference hooks, these call events can be automatically captured and related information recorded when application resources are loaded. Resource call data reflects the actual resource usage when users interact with the application in real-world scenarios. Compared to traditional static analysis methods, this data collection based on dynamic behavior can more accurately reflect the actual value of resources. This provides a data-driven scientific basis for resource optimization decisions, avoiding the misjudgments and blind spots that may result from traditional static analysis.

[0032] Optionally, the set of resources to be optimized refers to the set of resource files that can be optimized after analyzing resource call data. Based on the call status of resources within a specified time period (e.g., 30 days), the set of resources to be optimized can generally be divided into two categories: first, resources that are not called at all, which have no user access records during the sampling period and may be related to legacy code or deprecated functions; second, low-frequency call resources, which are called very few times during the sampling period (e.g., less than 3 times in 30 days), representing functions or scenarios that are rarely used by users.

[0033] Optionally, the identification of the resource set to be optimized can also be combined with user behavior data analysis. For example, the frequency of use can be statistically analyzed using user behavior tracking points, and the tracking data can be correlated with resource usage data. This provides a more comprehensive understanding of resource usage, enabling more rational decisions during the optimization process. For instance, if a certain function page has a low access rate, but some resources on that page are used frequently, these resources can be packaged separately to reduce the size of the main package.

[0034] Optionally, the identification of the resource set to be optimized can also be combined with intelligent analysis using machine learning algorithms. For example, machine learning algorithms can be used to perform cluster analysis on resource call data to identify different types of resource usage patterns. This can more accurately identify low-frequency and unused resources, thus enabling more reasonable decisions during the optimization process. For instance, if a resource is rarely called on multiple user devices, it may be considered to migrate that resource to a dynamically loaded module.

[0035] Optionally, optimization processing refers to the specific optimization operations performed on the identified set of resources to be optimized, mainly including two processing methods: resource removal and resource relocation. Resource removal means completely deleting the relevant resource files to be optimized from the application, directly reducing the application's size. Resource relocation, on the other hand, targets the relevant resource files to be optimized (such as those used infrequently but still used by a certain user group), separating them from the main package and reorganizing them into independent resource modules that can be downloaded on demand, such as Android's Dynamic Feature Module or resource packages supported by a custom resource loading framework. The download is only triggered when the user first accesses the relevant function. In this way, by combining these two optimization processing strategies, the initial installation package size can be significantly reduced, improving the user download conversion rate, while ensuring the integrity of application functions and the continuity of user experience.

[0036] Optionally, this method is applicable to various mobile applications, including but not limited to social media apps, e-commerce apps, games, utility apps, and enterprise office apps. Different types of applications may require adjustments to specific optimization parameters based on their characteristics. For example, social media apps may need to retain more multimedia resources to support rich interactive experiences, e-commerce apps may need to retain product image resources to ensure smooth browsing, and game apps may need to differentiate between basic scene resources and optional level resources for differentiated processing. The core principles and processes of this method remain consistent across different application types, but parameters can be adjusted and strategies optimized according to the characteristics of the application during specific implementation to ensure maximum optimization results. In this way, through flexible adaptation, the method can serve a wide range of application scenarios, improving the user experience and market competitiveness of various applications.

[0037] Optionally, in actual implementation, resource call data collection can employ various technical solutions. On the Android platform, resource loading interception can be achieved by overriding the load method of the Resources class; on the iOS platform, relevant resource loading methods can be hooked using Method Swizzling technology.

[0038] In an optional implementation, collecting resource call data from the application on the user device includes: capturing resource call events through a monitoring mechanism embedded in the application; and recording resource call information, which includes at least the resource identifier, call time, and environment information. This enables comprehensive and accurate monitoring of application resource usage. By capturing and recording resource call events, a complete understanding of the application's actual resource usage on the user device can be obtained, providing accurate data support for subsequent resource optimization.

[0039] Optionally, a monitoring mechanism refers to a resource call interception and recording system embedded in the application's underlying framework. Specifically, this involves setting hook functions along the application's resource loading path. When the application performs a resource loading operation, the hook function is automatically triggered, recording relevant call information. For Android applications, the monitoring mechanism is typically implemented by overriding resource acquisition methods such as `getDrawable()` and `getString()` in the `Resources` class; for iOS applications, it can replace the `imageNamed:` method of `UIImage` or the relevant resource loading methods of `NSBundle` using Method Swizzling technology. The monitoring mechanism is designed with a lightweight principle to minimize the performance impact on the application's main thread, primarily through asynchronous processing, reasonable caching strategies, and trigger frequency control. In this way, a low-intrusive monitoring mechanism can collect comprehensive resource usage data without affecting the normal operation of the application.

[0040] Optionally, the implementation of the monitoring mechanism needs to be planned during the application development phase. Typically, AOP (Aspect-Oriented Programming) is used, inserting monitoring code along the critical path of resource loading. This design decouples the monitoring logic from the business logic, facilitating maintenance and updates. In practice, appropriate Hook techniques need to be used for different platforms (Android / iOS / Web) to ensure that all types of resource loading requests can be captured.

[0041] Optionally, a resource invocation event refers to a point in time when an application accesses or loads a specific resource at runtime. Each resource invocation event contains at least four dimensions of information: who invoked it (the invocation source, such as a specific code path or component), what was invoked (the resource object), when it was invoked (the point in time), and under what circumstances it was invoked (the context). Resource invocation events are captured in two ways: direct capture and inferred capture. Direct capture targets resources that the application actively requests to load, such as images, audio, and layouts explicitly called in the code; inferred capture targets resources that are automatically loaded by the system, such as automatically referenced dependency styles and system-generated resource variants. To ensure the accuracy of the data statistics, the monitoring mechanism will handle duplicate calls appropriately. For example, multiple calls to the same resource within a short period of time (such as 100 milliseconds) may only be recorded once, but a call count will be added to the record. In this way, through fine-grained capture of resource invocation events, the resource usage patterns of the application can be comprehensively reflected.

[0042] Optionally, when recording resource call information, the resource identifier is a unique identifier for each resource, which can be the resource file name, path, or ID. The call time refers to the specific timestamp when the resource was called, accurate to the millisecond level, so that subsequent analysis can accurately understand the resource's usage frequency and time distribution. Environmental information includes, but is not limited to, the following: device information (such as device model, operating system version, screen resolution, memory size, etc.), network status (such as WiFi, mobile data, offline, etc.), application status (such as running in the foreground, running in the background, just switched from the background to the foreground, etc.), user interaction context (such as the current interface, the operation performed, session duration, etc.), and region and language settings. This information helps developers better understand the resource usage scenarios, thereby making more reasonable decisions during the optimization process.

[0043] Optionally, recording resource call information refers to saving captured resource call events and related data in a structured form for subsequent processing and analysis. The recording process includes three stages: data serialization, local storage, and reporting preparation. In the data serialization stage, resource call events are converted into a compact binary or JSON format to reduce storage space usage. In the local storage stage, the serialized data is written to the application's dedicated log file or a lightweight database (such as SQLite), using a circular buffer strategy to manage storage space and prevent excessive log size from consuming device storage. In the reporting preparation stage, log data is packaged according to a preset reporting strategy (such as reaching a specific data volume, a specific time interval, or a specific trigger condition) and prepared for reporting to the data processing module. To ensure data integrity, the recording mechanism also includes exception handling logic, such as attempting to save collected data when the application crashes and restoring and reporting it upon the application's next startup. Furthermore, the recording system implements data compression and batch processing capabilities, significantly reducing the consumption of log data on device storage and network transmission. Thus, through an efficient recording mechanism, the complete collection and reliable storage of resource call data are ensured.

[0044] Optionally, environmental information collection follows the principle of minimum necessity, collecting only information directly related to resource optimization and avoiding excessive collection of user privacy data. Before data reporting, environmental information undergoes anonymization to remove sensitive information that could identify individuals. Furthermore, environmental information collection considers compatibility with different devices to ensure standardized data can be obtained across various device environments. In this way, rich environmental information records enable multi-dimensional resource usage analysis, identifying resource usage patterns and optimization opportunities in specific scenarios.

[0045] Optionally, the monitoring mechanism can be implanted during the application's cold start phase, injecting Hook logic through dynamic loading. This approach has two major advantages over static compile-time implantation: first, it avoids impacting the main package size (the injected code only increases by about 50KB); second, it supports hot-update monitoring strategies. In practice, the monitoring SDK is first loaded in `Application.attachBaseContext()`, and then key class methods are dynamically replaced using `ClassLoader`.

[0046] Optionally, the monitoring mechanism also includes an adaptive sampling control strategy, dynamically adjusting the monitoring intensity based on application operation. During critical application phases (such as initial startup, critical function operations, or when system memory is low), the monitoring frequency is automatically reduced to ensure a good user experience; while during non-interactive phases (such as when the application goes into the background or the user pauses operation), the monitoring intensity is increased to obtain more comprehensive data. The monitoring mechanism also sets differentiated sampling strategies for different types of resources: higher monitoring priority is applied to large resources (such as high-definition images and video resources); lower monitoring frequency may be used for system resources and third-party library resources.

[0047] In an optional implementation, collecting resource call data from the application on the user's device includes: dynamically adjusting the sampling strategy based on the number of online users. The sampling strategy controls the scope and frequency of the collected resource call data. This dynamic adjustment of the data collection and reporting strategy based on the number of online users ensures that the collected data reflects the actual usage of users without negatively impacting the user experience.

[0048] Optionally, the online user base refers to the total number of active users currently using the application, which can be determined by the number of unique device identifiers recorded by the application's backend server. In practical applications, the online user base can be calculated using different metrics such as daily active users (DAU), hourly active users, or real-time online users. For example, large applications may have tens of millions of daily active users, medium-sized applications may have millions, while small applications may only have tens of thousands or hundreds of thousands. By monitoring this user base data in real time, the system can dynamically adjust its resource allocation data collection strategy to ensure that the collected data is representative without excessively impacting system performance. This maintains system stability even in the event of a sudden surge in user numbers.

[0049] Optionally, online user scale refers to the total number of active users currently using the application, which can be determined by the number of unique device identifiers recorded by the application's backend server. In practical applications, online user scale can be calculated using different metrics such as daily active users (DAU), hourly active users, or real-time online users. For example, large applications may have tens of millions of daily active users, medium-sized applications may have millions of daily active users, while small applications may only have tens of thousands or hundreds of thousands of daily active users. By monitoring this user scale data in real time, the resource allocation data collection strategy can be dynamically adjusted to ensure that the collected data is representative without excessively impacting system performance and user experience. In this way, even in the event of a sudden increase in user scale, system stability can be maintained.

[0050] Optionally, a sampling strategy is a set of rules used to determine which user devices to collect resource usage data from, what types of resource usage data to collect, and at what frequency. A sampling strategy can include multiple dimensions such as sampling rate settings, user selection rules, resource type configuration, and sampling interval settings. The sampling rate can be a fixed percentage (e.g., 10% of users) or a dynamic percentage (automatically adjusted based on user scale); user selection rules can be based on methods such as random sampling, stratified sampling, or weighted sampling; different sampling strategies can be set for different resources (e.g., images, videos, audio, layout files, etc.); the sampling interval can be a fixed period (e.g., reporting every 5 minutes) or a dynamic period (adjusted based on resource usage frequency). By configuring these parameters appropriately, the impact on user device performance can be minimized while ensuring data representativeness. This way, valuable resource usage data can be obtained while ensuring a good user experience.

[0051] Optionally, the scope of resource call data can include the range of user devices to be collected, the type and quantity of resource call information, including but not limited to resource ID, resource type, resource size, call timestamp, call context information, and call method stack. For example, when the number of users exceeds a certain threshold, only resource call data from a subset of users is collected; or, when the number of online users is small (e.g., less than 100,000 users), the system can collect complete resource call information, including detailed call context and stack information; while when the number of users is large (e.g., more than 1 million users), the system may only collect core information such as resource ID, resource type, and call timestamp to reduce data transmission volume and processing burden. This dynamic adjustment strategy ensures that sufficiently valuable data is obtained under various user scales while avoiding system overload. In this way, the data requirements for resource optimization are met, while also ensuring the stability and reliability of the system.

[0052] Optionally, the data collection frequency can include the time interval for collecting resource call data from user devices, the time interval for reporting the collected resource call data to the data analysis module, etc., and can be measured in minutes, hours, or days. The data collection frequency setting directly affects data real-time performance and system load. When the number of online users is small, the system can use a higher collection frequency (e.g., once every 5 minutes) to obtain more real-time and granular resource call data; when the number of users increases, the system can reduce the collection frequency (e.g., once every 15 minutes or hour) to reduce network transmission and server processing pressure. Furthermore, the system can set different collection frequencies based on the importance of the resources. For example, resource call data for core functional modules may require a higher collection frequency, while resources for non-critical functional modules can use a lower collection frequency. This allows for optimization of system resource utilization while ensuring data quality.

[0053] Optionally, the sampling strategy can be adjusted through local caching and downsampling strategies. Specifically, the application can cache resource call data locally and then report it in batches when a preset data volume threshold or time interval is reached; or it can actively collect cached resource call data from user devices according to the sampling strategy; or it can collect user-reported resource call data in real time, cache it on a designated storage device (e.g., a backend server), and collect the resource call data to be analyzed from the cached data according to the sampling strategy. Downsampling strategies adjust the sampling range and frequency based on the user base. For example, when the number of users is less than 100,000, resource call data can be sampled in full at a higher frequency; when the number of users exceeds 100,000, the sampling frequency and range can be reduced, such as randomly selecting resource call data from 10 out of every 100 users for reporting. This ensures that when the number of users is large, data reporting does not place an excessive burden on user devices, while still obtaining representative data.

[0054] Optionally, the sampling strategy can also be adjusted using a formula. For example, the sampling ratio can be determined using the formula (y=\min(1,\frac{2000000}{x})), where (x) is the current number of online users and (y) is the sampling ratio. When the number of users is small, the sampling ratio is close to 1, meaning all users are reported; when the number of users is large, the sampling ratio gradually decreases to reduce the frequency of data reporting. In this way, the frequency of data reporting can be dynamically adjusted to ensure that the collected data reflects the actual usage of users at different user scales without significantly impacting the user experience.

[0055] Optionally, the sampling strategy can also be adjusted based on resource type. For example, different sampling ratios can be set for different types of resources such as images, videos, animations, and scripts. A lower sampling ratio can be used for videos and animations that consume more resources, while a higher sampling ratio can be used for images and scripts that consume fewer resources. This ensures that the collected data reflects the user's actual usage across different resource types without significantly impacting the user experience.

[0056] Optionally, sampling strategies can be adjusted in conjunction with user behavior. For example, different sampling strategies can be set for different user groups. A higher sampling rate can be used for active users to obtain more data about them; a lower sampling rate can be used for inactive users to reduce the frequency of data reporting. In this way, it can be ensured that the collected data better reflects the actual usage of different user groups, thus providing a more accurate basis for resource optimization.

[0057] In an optional implementation, identifying the set of resources to be optimized based on resource call data includes: obtaining the complete resource set of the application; determining the subset of resources called within a specified time period based on the resource call data; and performing set operations on the complete resource set and the resource subset to obtain the set of resources to be optimized. This efficient identification of optimizable resources through set operations ensures the accuracy and comprehensiveness of resource optimization, effectively avoiding omissions or misjudgments.

[0058] Optionally, obtaining the complete resource set of the application refers to extracting a list of all resource files included in the current version from the application's version management repository (such as Git, SVN, etc.), including but not limited to image resources (such as .png, .jpg, .webp, etc.), layout files (such as .xml files for Android, .xib or .storyboard files for iOS), audio files (such as .mp3, .wav, etc.), video files (such as .mp4, etc.), font files (such as .ttf, .otf, etc.), script files (such as .js, etc.), and other types of resource files. This ensures that the resource optimization process starts with a comprehensive overview of the application's resources, providing a complete foundation for subsequent comparative analysis.

[0059] Optionally, the complete set of application resources can be obtained through various technical means, such as: parsing the compiled application package and extracting the resource mapping table using resource compilation tools (such as aapt for Android and Asset Catalog for iOS); traversing the project source code directory and scanning all files in resource folders (such as the res directory for Android and Assets.xcassets for iOS); and generating a resource manifest by analyzing the resource paths referenced in build scripts (such as Gradle and Xcode build configurations). This ensures that the obtained resource set is consistent with the resources ultimately packaged into the application, avoiding omissions or the inclusion of extra resources.

[0060] Optionally, the complete resource set includes not only the application's own resources but also resource files from third-party libraries or SDKs. For these external resources, the system scans the resource manifests of dependent libraries or parses the compiled resource packages to include them in the complete resource set. For example, for Android applications, the system parses resources in AAR files; for iOS applications, the system analyzes resource bundles contained in the Framework. This ensures that the optimization process considers all resources that may affect the application size, including both directly and indirectly introduced resources.

[0061] Optionally, determining the subset of resources invoked within a specified time period based on resource call data involves analyzing resource usage logs reported from user devices to statistically analyze the call activity of each resource within a specific observation period (e.g., the last 30 days, the last quarter, etc.), forming a list of actually used resources. The system cleans and aggregates the reported raw call logs, removing duplicate records and abnormal data, and groups them by resource identifier, calculating statistical indicators such as the number of calls, call frequency, first call time, and most recent call time for each resource. This data-driven approach objectively reflects the actual usage of application resources, avoiding the subjective judgment biases that may exist in traditional static analysis methods.

[0062] Optionally, determining the subset of resources invoked within a specified time period based on resource call data involves analyzing collected resource usage data to statistically analyze the call activity of each resource within a specific observation period (e.g., the last 30 days, the last quarter, etc.), forming a list of actually used resources. This specifically includes cleaning and aggregating the reported raw call logs, removing duplicate records and abnormal data, grouping them by resource identifier, and calculating statistical indicators such as the number of calls, call frequency, first call time, and most recent call time for each resource. This data-driven approach objectively reflects the actual usage of application resources, avoiding the subjective judgment biases that may exist in traditional static analysis methods.

[0063] Optionally, the length of the specified time period should be set considering the application's usage cycle characteristics, typically covering typical usage scenarios and seasonal variations. For example, for frequently used daily utility applications, a shorter time period (e.g., 14-30 days) might be chosen; for applications with obvious periodicity (e.g., holiday-related applications), a longer time period (e.g., 3-6 months) is needed to cover the complete usage cycle. This ensures the representativeness and completeness of resource call data, avoiding misjudgments due to inappropriate time period selection.

[0064] Optionally, when performing set operations, the system considers resource variants. For example, in Android applications, the same resource may have multiple variants for different screen densities (such as hdpi, xhdpi, xxhdpi, etc.); in iOS applications, the same image resource may have 1x, 2x, 3x, etc., versions with different resolutions. The system treats these variants as different representations of the same resource, and considers the resource to be used as long as any of these variants is invoked. This avoids resource usage judgment biases caused by device diversity.

[0065] Optionally, the results of set operations are further correlated with resource size information to calculate the impact of each unused or infrequently used resource on the application package size. The system prioritizes larger, unused, or infrequently used resources, as optimizing these resources will result in a more significant reduction in package size. For example, optimizing an unused high-resolution video file (potentially occupying several MB of space) is far more valuable than optimizing an unused small icon (potentially occupying only a few KB of space). This comprehensive evaluation from both resource size and usage frequency dimensions makes optimization more targeted and efficient.

[0066] In an optional implementation, performing set operations on the complete resource set and resource subsets to obtain the resource set to be optimized includes: determining the unused resource subset based on the set operation result; determining the low-frequency called resource subset based on the call frequency of each resource in the called resource subset within a specified time period; and merging the unused resource subset and the low-frequency called resource subset to obtain the resource set to be optimized. In this way, by accurately distinguishing between unused resources and low-frequency used resources, refined management of resource optimization is achieved, providing a scientific basis for subsequent differentiated processing.

[0067] Optionally, set operations can be performed on the complete resource set and the resource subset. Specifically, this involves performing a set difference operation (subtracting the called resource subset from the complete resource set) to obtain a list of resources that were not called during the observation period. Furthermore, frequency analysis is performed on the called resource subset, identifying low-frequency called resources based on preset thresholds (e.g., fewer than 3 calls within 30 days). In this way, through mathematical set operations, resource categories with different usage frequencies are accurately identified, providing a clear data foundation for subsequent optimization strategy development.

[0068] Optionally, the definition of the "specified time period" allows for flexible configuration of the observation window. It is generally recommended to use an observation period of at least 30 days to cover the entire business cycle of the application, including daily use, periodic activities, and seasonal features. For applications with significant business seasonality (such as e-commerce platform promotional seasons or game limited-time events), the observation period can be extended to 90 days or longer to ensure that all potential periodic resource usage patterns are captured. The starting point of the observation period is usually chosen during a period of stable application version development, avoiding major version updates or the initial stages of feature iterations, to obtain more representative user behavior data. Furthermore, multi-period overlay analysis is supported. By comparing resource usage across different time windows, truly long-term unused resources can be identified, eliminating the interference of short-term fluctuations on the analysis results. This improves the accuracy and reliability of resource optimization decisions and avoids the accidental deletion of potentially valuable seasonal resources.

[0069] Optionally, the determination method for the "low-frequency resource subset" is a dynamic calculation system based on resource call frequency thresholds. First, the absolute number of calls for each resource during the observation period is calculated. Then, a comprehensive score is generated by combining user coverage (the proportion of unique users calling the resource out of the total number of users) and relative frequency (the proportion of the resource's call count out of the total number of all resource calls). The score uses a weighted calculation model: Score = α × (number of calls / maximum number of calls) + β × user coverage + γ × relative frequency, where α, β, and γ are configurable weight parameters with default values ​​of 0.5, 0.3, and 0.2, respectively. Resources with scores below a preset threshold (default 0.05) are classified as low-frequency resources. To adapt to the characteristics of different application types, differentiated thresholds can be set according to resource type (such as images, audio, video, layout files, etc.), and the baseline can be automatically adjusted according to the application scale. This allows for more accurate identification of resources that are used but have extremely low usage frequency, providing a scientific basis for subsequent resource relocation strategies.

[0070] Optionally, for the "merge" operation, metadata tags are added to each resource to distinguish whether it originates from the unused subset or the low-frequency used subset. These tags will guide subsequent differentiated processing strategies. For resources from the unused subset, a resource removal strategy is recommended by default; while for resources from the low-frequency used subset, a resource relocation strategy is preferred. Simultaneously, the merging process retains complete contextual information for each resource, including resource type, size, version history, most recent modifier, and associated functional module, providing ample reference for subsequent manual review and automated processing. The system also performs conflict detection on the merge results to ensure that the same resource is not assigned conflicting processing strategies. The merged set of resources to be optimized will be provided with a sorted view based on multiple dimensions such as resource size, resource type, or functional module, facilitating the prioritization of high-yield targets. This provides a structured set of optimization objects while ensuring data integrity, laying the foundation for subsequent processing flows.

[0071] Optionally, the generation of the "set of resources to be optimized" can also incorporate resource importance assessment. In addition to usage frequency, the potential impact range of each resource is calculated, including its reference count in the code, its relevance to core functions, and its impact on application startup performance. The assessment uses a multi-dimensional matrix model: ResourceScore = w1 × FrequencyScore + w2 × ImpactScore + w3 × SizeScore, where FrequencyScore represents usage frequency, ImpactScore represents impact range, and SizeScore represents resource size (larger resources score higher because removal yields more significant benefits). The weight parameters w1, w2, and w3 can be adjusted according to different application types and optimization goals. By setting a scoring threshold, key resources with low usage frequency but high potential impact can be automatically filtered out, preventing them from being included in the set of resources to be optimized. Furthermore, a visual score distribution chart is provided to help the development team intuitively understand the distribution of resource value and assist in formulating more precise optimization strategies. This maximizes the reduction in application size while ensuring application functionality and user experience.

[0072] Optionally, more refined resource classification and management strategies can be developed during actual project implementation. For example, for game applications, resources can be further divided into multiple levels such as core gameplay resources, UI interface resources, special effects resources, and audio resources. Different frequency thresholds and optimization strategies are adopted for resources at different levels. For core gameplay resources, even if the usage frequency is relatively low, they are tended to be retained in the main package to ensure a smooth experience; while for enhanced resources such as special effects and background music, more aggressive optimization strategies can be adopted. Resources are automatically mapped to different categories through file naming rules, storage paths, or resource tags. The classification results affect the resource's scoring weight and processing strategy, making the optimization process more aligned with product characteristics. In addition, by analyzing resource usage trends between versions, resources with a declining usage frequency can be identified and marked in advance, providing forward-looking suggestions for optimization in future versions. In this way, through refined classification and management strategies, resource optimization becomes more intelligent and targeted, achieving better optimization results.

[0073] In an optional implementation, the optimization process for the resource set to be optimized includes: determining the resource subset to be removed and the resource subset to be migrated based on the resource set; performing resource removal processing on the resource subset to be removed; and performing resource relocation processing on the resource subset to be migrated. In this way, by subdividing the resource set to be optimized into two subsets, to be removed and to be migrated, and adopting different processing strategies accordingly, it is possible to thoroughly clean up completely unnecessary resources to maximize the slimming effect, while retaining low-frequency but still usable resources and optimizing their loading methods, thereby achieving optimal package size control while ensuring functional integrity.

[0074] Optionally, the set of resources to be optimized refers to all resources that can be optimized based on user behavior data analysis, including completely unused resources and resources with extremely low usage frequency. Based on the actual value and importance of the resources, these resources need to be further divided into two subsets: those that can be completely removed and those that need to be retained but can be relocated. This refined classification approach avoids the "one-size-fits-all" approach of traditional package reduction methods, enabling the development of the most reasonable optimization strategy for different resource characteristics. This maximizes the reduction of package size while ensuring the complete usability of application functions. In actual implementation, a decision model can be built based on multi-dimensional data such as resource usage frequency, last access time, resource size ratio, and functional module correlation. Machine learning algorithms can be used to automatically recommend the optimal resource classification scheme, and manual confirmation can further improve classification accuracy.

[0075] Optionally, the subset of resources to be removed typically refers to resources that are not called at all during the monitoring period, or whose call frequency is extremely low and which have no critical functional dependencies. These resources may be redundant files left over from previous version iterations, replaced old design elements, or alternative resources reserved for specific scenarios but rarely triggered. When determining the subset of resources to be removed, in addition to considering resource usage frequency data, static code analysis results can be combined to identify potential indirect reference relationships, thus avoiding the accidental deletion of resources that may be dynamically loaded. Furthermore, by analyzing the size and type of resources, resources with large footprints and extremely low usage (such as high-definition video footage and large animation files) can be prioritized for inclusion in the subset of resources to be removed, achieving the most efficient weight reduction benefits.

[0076] Optionally, the subset of resources to be migrated refers to resources that are used less frequently but still have practical value, or are strongly relevant to specific scenarios. For example, resources required by functional modules accessible only during specific holidays, for users in certain regions, or for premium members. Although their overall usage frequency is low, they are still significant to specific user groups. These resources are not suitable for direct deletion but are better optimized through resource relocation. The core idea of ​​resource relocation is to separate these resources from the main package, build independent resource modules or subpackages, and design a reasonable on-demand loading mechanism so that these resources are only downloaded and used when truly needed. This approach reduces the initial installation package size, improves the user's first download experience, and ensures the complete availability of all functions, achieving an optimal balance between user experience and package size.

[0077] Optionally, during the process of optimizing the resource set, the logical relationships between resources can also be considered, and functionally related resources can be uniformly grouped into the same subset for processing. This clustering approach based on functional modules helps maintain the clarity and consistency of the application's internal structure. For example, for a low-frequency used functional module, all resource files involved in the module (including images, layout files, audio, etc.) will be analyzed to assess the overall value and space occupied by the module, and then a decision will be made on whether to move the entire module out or migrate it as an independent subpackage. This "module-based" approach, compared to processing individual resource files piecemeal, better ensures the integrity of functions and the consistency of user experience, while also simplifying subsequent maintenance work and enabling the development team to more clearly understand and manage the application's resource structure.

[0078] Optionally, a multi-layered decision-making mechanism can be introduced in the process of determining the subsets of resources to be removed and migrated, comprehensively considering technical indicators and business needs. First, preliminary resource classification suggestions are generated based on objective data (such as usage frequency and space occupancy). Second, a secondary screening is conducted using a business rules engine, for example, marking core brand materials and legally compliant documents as essential resources to retain. Finally, the suggestions are presented to relevant responsible parties for final confirmation through a visual decision-making platform. During this process, intelligent recommendation functions can also be provided, offering optimal handling solutions for different types of resources based on historical optimization cases and performance data, helping decision-makers complete resource classification more quickly and accurately. Records of each decision-making process and its results can also serve as empirical data, continuously optimizing the algorithm model and improving the accuracy and efficiency of subsequent resource classification.

[0079] In an optional implementation, performing resource removal processing on the subset of resources to be removed includes placing the resources to be removed from the subset in an isolation area; monitoring for anomalies related to each resource to be removed during an observation period; completely removing the resources to be removed from the application from which no anomalies occurred during the observation period; and restoring the resources to be removed from the application to their original state from which anomalies occurred during the observation period. This gradual removal strategy effectively avoids the risk of accidental deletion and ensures the integrity of application functionality.

[0080] Optionally, the specific steps for removing the resource subset to be moved out include: First, moving the resources in the subset to an isolated area, which can be a temporary directory, to observe their behavior over a period of time. If no anomalies related to these resources occur during the observation period, these resources can be completely removed from the application. If anomalies occur during the observation period, it indicates that these resources still affect certain functions of the application, and in this case, these resources need to be restored to their original state. This gradual removal strategy can effectively avoid functional abnormalities caused by accidental resource deletion.

[0081] Optionally, placing resources to be removed from the subset of resources into an isolation zone is a secure and controllable resource handling mechanism. This isolation zone is a specially designed temporary storage space within the application or during the build process, used to temporarily store resources marked for removal but whose safety has not yet been confirmed. Isolation zones are typically implemented using virtual links or redirection mechanisms; the resource files physically still exist within the isolation zone, but are marked as "isolated" during the application compilation and packaging phase. Isolation zones can be organized and managed according to resource type (images, audio, layout files, etc.) or functional module (login module, payment module, social sharing module, etc.). Each isolated resource retains its original path information and metadata so that it can be accurately restored when needed. This allows for rapid location and restoration of relevant resources when resource removal is observed to potentially cause problems, ensuring the stable operation of the application.

[0082] Optionally, the observation period refers to the time window from when a resource is placed in the isolation area until it is finally confirmed whether it can be safely removed. This period is typically set to 7 to 30 days, and the specific duration can be dynamically adjusted based on the application's release cycle, user scale, and resource importance. The core principle of the observation period design is to ensure coverage of the application's typical usage cycle and various edge scenarios, such as weekends and weekdays, peak user activity times in different time zones, major holidays, or marketing campaigns. During the observation period, the application continues to run and collect user interaction data, while maintaining access to the isolated resource. However, these access events are logged in the background as a basis for judging abnormal situations. For applications with strong seasonality or obvious usage cycles, the observation period may need to be extended to cover the entire business cycle to ensure that resource usage is not misjudged due to an excessively short time window. In this way, by scientifically and reasonably setting the observation period, the identification of truly safe-to-remove resources can be maximized while ensuring application stability and user experience.

[0083] Optionally, monitoring anomalies related to each resource to be removed refers to continuously tracking and recording all abnormal events related to the isolated resource during the observation period using various technical means, including but not limited to: resource request failure logs, user interface rendering anomaly reports, function operation interruption feedback, application crash records, etc. This monitoring mechanism is usually implemented by the client and server in cooperation. The client is responsible for capturing and reporting local anomalies, while the server is responsible for aggregating and analyzing them and establishing a correlation model between resources and anomalies. To improve monitoring accuracy, a resource access interception mechanism is implemented. When an application attempts to access resources in the isolated area, the context information of the access request (such as access time, user operation path, device environment, etc.) is recorded, and the resource request is correctly guided to the actual storage location through a resource mapping table, ensuring that application functions are not affected while accurately counting the actual resource calls. The monitoring scope is also extended to related dependent resources, because some resources may not be directly called but accessed indirectly through other resources. In this way, a comprehensive anomaly monitoring mechanism can capture various potential resource dependencies, greatly improving the security and accuracy of resource removal decisions.

[0084] Optionally, completely removing resources from the application that did not exhibit any anomalies during the observation period means that after completing the specified observation period, for resources that did not trigger any access requests or anomaly records, a final removal operation will be performed. This includes deleting related files from the source code repository, updating the resource reference table and build configuration, and officially removing these resources in the next application release. Complete removal operations are typically executed by automated scripts to ensure consistency and traceability. Before removal, a detailed resource report is generated, recording key information for each removed resource, such as resource type, size, last modification time, and responsible party, and this information is archived for future reference. For large or numerous resources, the impact on the application package size after removal is assessed, and the optimization effect is highlighted in the removal report. In this way, a standardized resource removal process ensures application stability while quantifying the effectiveness of package optimization, providing data support for continuous resource management.

[0085] Optionally, restoring resources to their original state during the observation period that exhibit abnormal behavior means that when an abnormal event related to a specific isolated resource is detected, a resource restoration mechanism is automatically triggered. This mechanism moves the resource from the isolation area back to its original location and updates related references, ensuring that the application's functional integrity is not affected. The restoration process includes not only restoring the resource file itself but also restoring its normal state in the resource index table and its references in the build configuration. For resources that exhibit abnormal behavior, a detailed anomaly report is generated, recording the anomaly type, frequency of occurrence, scope of impact, and possible cause analysis, helping the development team understand the actual importance and use cases of the resource. These restored resources are marked as "necessary resources" and excluded from the resource set to be removed during subsequent resource optimization processes, avoiding resource fluctuations caused by repeated evaluations. Simultaneously, a dedicated usage pattern analysis is established for these resources to explore the possibility of optimizing them as on-demand loading resources, rather than simply retaining or deleting them. In this way, through an intelligent resource restoration mechanism, the functional integrity of the application is ensured, and a more refined decision-making basis is provided for future resource optimization strategies.

[0086] In an optional implementation, performing resource relocation processing on the subset of resources to be migrated includes classifying the resources to be migrated within the subset; configuring the resources to be migrated as independent resource modules according to their categories; and setting the on-demand loading trigger conditions for the independent resource modules. In this way, by classifying and configuring infrequently used but still necessary resources for on-demand loading, the initial package size of the application can be reduced while ensuring that these resources are still accessible when necessary, thereby achieving the goal of package reduction while maintaining functional integrity.

[0087] Optionally, the specific steps for performing resource relocation processing on the subset of resources to be migrated include: First, classifying these resources according to their usage scenarios or functional modules. Then, configuring these resources as independent resource modules, which can be downloaded on demand via dynamic loading. For example, this can be achieved using Android App Bundle or a custom resource loading framework. Finally, setting the on-demand loading trigger conditions for these independent resource modules, such as when a specific page is accessed, a feature is enabled, or a region-restricted feature is used. This ensures that these low-frequency resources are loaded only when needed, thereby reducing the size of the initial installation package.

[0088] Optionally, classifying the resources to be migrated within the subset refers to categorizing low-frequency resources based on their usage scenarios, functional attributes, and business relevance. For example, resources can be categorized by usage scenario into "holiday event resources," "region-specific function resources," and "advanced function resources"; or by resource type into "multimedia resource groups," "interface element resource groups," and "auxiliary function resource groups." During the classification process, business logic analysis and user behavior data can be incorporated to ensure that resources within the same category have similar usage trigger conditions and business relevance, facilitating more rational subsequent modular encapsulation. This scientific resource classification ensures a more accurate and efficient loading strategy after resource migration, improving the resource call hit rate.

[0089] Optionally, configuring resources to be migrated as independent resource modules by category refers to the process of encapsulating resources of the same category into independently loadable resource packages using specific technical means based on the aforementioned classification results. On the Android platform, dynamic feature modules can be created using Android App Bundle technology, with each module containing resource files of a specific category. On the iOS platform, on-demand resource downloads can be achieved through On-Demand Resources technology. For cross-platform applications, a custom resource loading framework can be implemented, using a resource mapping table and a remote resource server to achieve dynamic resource scheduling. The encapsulation process of independent resource modules includes steps such as resource file migration, dependency restructuring, and resource reference path updates, ensuring that the original code's calls to these resources can seamlessly switch to the new loading method. In this way, modularizing resources allows for more flexible resource management strategies, reducing the initial package size while improving application loading speed.

[0090] Optionally, setting on-demand loading trigger conditions for individual resource modules refers to defining a set of rules for when each resource module should be downloaded from the server and loaded into the application. Trigger conditions can be based on various factors, such as user interaction events (e.g., first click on a specific function button), environmental conditions (e.g., entering a specific geographical location or time zone), time nodes (e.g., the arrival of a specific holiday), and user attributes (e.g., reaching a required membership level). Setting trigger conditions requires balancing user experience and resource utilization efficiency, avoiding significant waiting times for users when they need the function while ensuring that unnecessary resources are not downloaded prematurely. This can be optimized through predictive loading strategies (e.g., preloading during idle periods before a user might need it) or background progressive loading (slowly loading without affecting foreground operations). In this way, reasonable trigger condition settings can ensure the ideal state of "loading only when needed, and being usable immediately after loading," improving user experience while minimizing the initial package size.

[0091] Optionally, performing resource relocation processing on the subset of resources to be migrated may also include version management of the resources. For example, a version number can be set for each independent resource module. When a resource is updated, a new version number can be released, and the latest version of the resource can be automatically downloaded when a user accesses the relevant function. This ensures that users always use the latest resources, improving the stability and reliability of the app.

[0092] In an optional implementation, determining the subset of resources to be removed and the subset of resources to be migrated based on the set of resources to be optimized includes: performing static analysis on the resource code corresponding to the set of resources to be optimized to determine resource dependencies; and determining the subset of resources to be removed and the subset of resources to be migrated based on the resource dependencies. In this way, by gaining a deeper understanding of the dependencies between resources through static analysis techniques, resources that can truly be safely removed or migrated can be identified more accurately, avoiding functional anomalies caused by ignoring hidden dependencies.

[0093] Optionally, static analysis refers to the process of examining program attributes by analyzing the program's code structure, syntax, and semantics without actually executing the program. In resource optimization scenarios, static analysis is mainly used to identify the ways and paths in which resources are referenced in the code, including hard-coded references, references in XML layout files, references in style sheets, and indirect references through dynamic methods such as reflection. By comprehensively scanning these different types of references, a complete resource reference graph can be established, avoiding the problem of accidentally deleting resources due to the omission of some implicit references. In this way, it can be ensured that the functional integrity of the application is not compromised during resource optimization, thus improving the reliability of optimization operations.

[0094] Optionally, resource dependencies refer to the network of references and referenced relationships between resources in an application, including direct dependencies and indirect dependencies. Direct dependencies refer to situations where a resource is explicitly referenced in code or configuration files, such as an image resource explicitly referenced in a layout file. Indirect dependencies refer to situations where a resource is indirectly called through an intermediary, such as a resource dynamically loaded by a component. Analyzing resource dependencies requires considering both static references at the code level and dynamic references that may be triggered at runtime, constructing a multi-dimensional dependency network. By establishing a complete resource dependency graph, the scope of influence of each resource can be clearly identified, providing data support for subsequent resource handling decisions.

[0095] Optionally, the subset of resources to be removed refers to the set of resources that, after verification through both static analysis and dynamically collected data, are confirmed to be safe for removal. These resources typically have the following characteristics: they are not called or are called very infrequently in user behavior data; they are not found to be referenced by any code or other resources in static analysis; they are not part of critical functional modules; and their removal will not affect the core functionality and user experience of the application. Determining the subset of resources to be removed requires comprehensive consideration of factors such as resource usage frequency, dependency complexity, and functional importance, employing a conservative strategy to ensure the safety of the removal operation. This minimizes the package size while keeping the risk within an acceptable range.

[0096] Optionally, the subset of resources to be migrated refers to those resources that, although used infrequently, still have the potential to be called, or whose dependencies are complex and unsuitable for direct removal. These resources typically have the following characteristics: low but not zero call frequency in user behavior data; conditional or indirect references found in static analysis; functions serving specific scenarios or user groups; and complex dependencies with other resources. Migrating these resources to independent modules instead of deleting them directly can optimize the initial package size and application startup performance through an on-demand loading mechanism while ensuring functional integrity. This achieves the goal of package reduction while ensuring all functions are available when needed, providing a better user experience.

[0097] Optionally, specific methods for determining resource dependencies include using static analysis tools to scan the codebase and identify various forms of resource references. For example, Android Lint tools can detect resource references in layout files, code parsers can analyze resource reference statements in Java or Kotlin code, and custom resource scanners can retrieve dynamic resource references in string concatenation formats. During the scanning process, each identified resource reference is recorded as an edge in a dependency graph, connecting the referrer (such as code files or layout files) and the referenced resource (such as images or strings). In this way, through comprehensive static analysis, a resource dependency network in the application can be constructed, providing a reliable basis for resource optimization decisions.

[0098] Optionally, when determining the subsets of resources to be removed and migrated based on resource dependencies, special attention needs to be paid to dynamically generated resource references. These references are typically implemented through string concatenation or reflection, such as `getResources().getIdentifier("icon_"+type,"drawable",getPackageName())`, which static analysis tools struggle to accurately track. Therefore, a conservative strategy is needed: resources that may have dynamic references (such as a series of resources with names conforming to a specific pattern) should be marked and categorized by default as subsets to be migrated rather than subsets to be removed, to avoid accidental deletion. This allows for safer handling of resources with potential dynamic reference risks and avoids functional anomalies caused by insufficient analysis.

[0099] Optionally, the process of determining the subsets of resources to be removed and migrated based on resource dependencies involves multiple decision-making steps. First, resource call data is cross-validated with the dependency graph to identify resources that are both unused or infrequently used in user behavior data and not depended on by other important modules in the dependency graph; these are initially categorized as candidates for removal. Second, the importance and potential risks of each candidate resource are assessed, such as the criticality of its functional module and the potential impact of its removal. Finally, based on the comprehensive evaluation results, resources are classified into three categories: to be removed (safely deleted), to be migrated (relocated to dynamic modules), or to be retained (not processed for now). This multi-dimensional decision-making process ensures that resource optimization effectively reduces package size without affecting the application's functional integrity and stability.

[0100] Optionally, resource dependency analysis also includes the identification and handling of third-party library resources. Many third-party libraries (such as advertising SDKs, statistical analysis tools, and social sharing components) carry a large number of resource files that they may not actually use. By using methods such as code signature recognition and package name prefix matching, application resources are distinguished into proprietary resources and third-party library resources, and specific processing strategies are designed for third-party library resources. This effectively solves the resource redundancy problem caused by third-party libraries and further optimizes the application package size.

[0101] In an optional implementation, determining the subset of resources to be removed and the subset of resources to be migrated based on resource dependencies includes: generating a display interface based on resource dependencies; receiving resource processing plans submitted through the display interface; and determining the subset of resources to be removed and the subset of resources to be migrated based on the resource processing plans. In this way, by combining visual display with a manual confirmation mechanism, the professional judgment and background knowledge of developers can be combined to improve the accuracy and controllability of resource processing decisions, further reducing the risks that automated processing may bring.

[0102] Optionally, generating a display interface based on resource dependencies involves using the resource dependency graph data obtained in the previous steps to construct an intuitive and visual user interface to showcase the call and called relationships between various resources. This interface can graphically present the hierarchical dependency structure between resources, such as using a directed graph to represent the call chain between resource nodes, where nodes represent different resources and lines represent dependencies. The interface can also use color coding to distinguish resource usage frequency (e.g., red for unused resources, yellow for low-frequency resources, and green for high-frequency resources) and can annotate each resource node with detailed information, such as resource type, size, number of calls, last call time, and its functional affiliation in the application. This allows technical personnel to intuitively understand the complexity and usage of resource dependencies, facilitating more accurate processing decisions.

[0103] Optionally, the resource dependency display interface can not only show static dependencies but also integrate dynamic usage data to form a multi-dimensional comprehensive evaluation view. For example, the interface can compare potential dependencies discovered through static code analysis with actual user usage data. When a resource has a reference path in static analysis but is never called in actual user data, it will be highlighted with a specific marker (such as a dotted line connection or a warning icon) to indicate this "zombie dependency." The display interface can also show resource usage trends through a timeline function to help determine whether a resource is used seasonally or idle for a long time. For resources imported from third-party libraries, the interface will specifically mark the source information and display the version and update status of the third-party library to assist in assessing the risk of removal. In this way, the comprehensive display of multi-dimensional data can provide a more comprehensive basis for decision-making and reduce the risk of misjudgment.

[0104] Optionally, after identifying resources that are not used or are used very infrequently, the last modification record of these resource files can be queried through a version control system (such as Git). The person responsible for the modification is identified as the confirmer, and their information is displayed on the interface. Direct approval notifications can be sent through the interface. The interface allows each responsible person to annotate and comment on the resources they are responsible for, recording the reasons for retaining or deleting the resources. For resources with complex dependencies, a multi-person co-signature process can be initiated, requiring relevant module leaders to jointly confirm the handling plan. The interface can also integrate project management, assigning resource optimization tasks to corresponding iteration cycles and providing progress tracking functionality. This robust collaboration mechanism ensures that resource handling decisions are fully evaluated and verified, reducing the risk of misjudgments due to poor communication.

[0105] Optionally, the interface provides multiple processing options buttons for each resource item, such as "Remove Immediately" (for redundant resources with no confirmed dependencies), "Migrate to Subpackage" (for resources used infrequently but functionally necessary), "Retain Resource" (for resources used infrequently but necessary for critical scenarios), and "Delay Processing" (for resources with complex dependencies requiring further analysis). The confirming personnel can select resources individually or in batches and add notes to each processing decision, such as explaining the business reasons for retaining a resource or marking test points requiring special attention after removal. All processing decisions, their operators, operation times, and notes can be recorded to form a complete decision audit trail.

[0106] Optionally, based on the confirmer's choice, resources can be divided into subsets of resources to be removed and subsets of resources to be migrated for subsequent processing. For example, after parsing the confirmed resource processing plans, resources marked "remove immediately" are assigned to the subset of resources to be removed, and resources marked "migrate to subpackage" are assigned to the subset of resources to be migrated. During the classification process, a secondary dependency check is performed to ensure that the processing decision for a single resource does not conflict with other resources. For example, if resource A is marked for removal but resource B (marked for retention) is found to have a dependency on A, a conflict will be automatically indicated and a reassessment will be required. For complex resources (such as resource packages containing multiple sub-files), it is supported to split them according to the processing plan, and assign different sub-files to the subsets to be removed or migrated respectively. In this way, precise resource classification lays the foundation for subsequent optimization processing, ensuring that processing operations are consistent with decision-making. Figure 1 To.

[0107] Optionally, intelligent suggestions for resource handling solutions can be provided based on historical data and machine learning algorithms. By analyzing historical resource optimization operations and their results (such as which resource removal caused problems, and which resource migration and subpackaging were effective), a correlation model between resource characteristics and optimal handling methods can be established. When technicians view the resources to be handled through the interface, handling suggestions are automatically provided, such as "Removal Recommendation: This type of resource has a 99% historical safe removal rate" or "Retention Recommendation: Similar resource removal has caused crashes in specific scenarios." The intelligent suggestion function also considers the application's release cycle and importance, tending to provide conservative suggestions before major version releases and offering more optimization space in daily iterations. Technicians can adopt or ignore these suggestions, and their decision feedback becomes training data for the model. In this way, through a human-machine collaborative decision-making model, continuous improvement in resource optimization efficiency can be achieved while ensuring safety.

[0108] In an optional implementation, the method further includes: performing automated testing on the target application to detect test anomalies; and automatically reverting to the application before optimization when the proportion of test anomalies exceeds a threshold. This automated testing verification and rollback mechanism ensures that resource optimization operations do not affect the stability of core functions, providing a secure and reliable weight reduction guarantee.

[0109] Optionally, automated testing refers to the technical means of programmatically simulating various user operation paths within an application to comprehensively verify whether the application functions correctly. Automated testing can be implemented based on various testing frameworks. For example, on the Android platform, Espresso, UI Automator, or MonkeyRunner can be used, while on the iOS platform, cross-platform tools such as XCTest or Appium can be used. These testing frameworks can simulate user interactions such as clicking, swiping, and text input, and can capture application behaviors such as interface responses and page transitions, thereby verifying the integrity of the application after resource optimization.

[0110] Optionally, the test anomaly ratio can be defined as the ratio of the number of test cases with anomalies to the total number of test cases. This metric reflects the overall stability of the application and can be calculated using the formula "Anomaly Ratio = (Number of Anomaly Test Cases / Total Number of Test Cases) × 100%". In resource optimization scenarios, test cases should cover the core functional paths of the application, edge scenarios, and specific functional modules related to the resources being optimized to ensure representative sampling. The test anomaly ratio directly affects subsequent decisions; for example, a high anomaly ratio usually indicates that the optimization plan has significant risks and requires rollback or adjustment.

[0111] Optionally, the threshold is a critical standard for judging whether the proportion of test anomalies is acceptable. Its setting needs to balance product quality requirements and optimization goals. The threshold can be configured differently based on factors such as application type, user scale, and business sensitivity. For example, financial applications may need a stricter threshold (e.g., 1%), while utility applications may tolerate a relatively higher threshold (e.g., 5%). When determining the threshold, the baseline anomaly rate (i.e., the proportion of test anomalies before optimization) should also be considered to avoid incorrectly attributing anomalies caused by non-optimization factors to resource optimization. The threshold can be dynamically adjusted, gradually tightening as optimization experience accumulates and the testing system improves, driving continuous improvement in application quality.

[0112] Optionally, automatic recovery refers to a rollback mechanism automatically triggered by the system when the detected anomaly rate exceeds a preset threshold, restoring the application to its pre-optimization state. The automatic recovery process includes operations such as resource file restoration, configuration rollback, and version tag updates, and is typically integrated into a continuous integration / continuous deployment (CI / CD) pipeline. Automatic recovery mechanisms emphasize timeliness and reliability, ensuring rapid response after issues are discovered and minimizing the impact on development and release processes. Through deep integration with version control systems (such as Git) and build tools (such as Maven and Gradle), automatic recovery enables one-click operations, significantly reducing human intervention costs and error risks.

[0113] Corresponding to the above method embodiments, this invention provides an application optimization device, see [link to relevant documentation]. Figure 3 The device includes: a data acquisition module for acquiring resource call data of the application on the user device; a data analysis module for identifying a set of resources to be optimized based on the resource call data; and a resource optimization module for performing optimization processing on the set of resources to be optimized to obtain the optimized target application; wherein the optimization processing includes resource removal or resource relocation.

[0114] In an optional implementation, the data acquisition module includes an event capture unit for capturing resource call events through a monitoring mechanism embedded in the application; and a recording unit for recording resource call information, which includes at least the resource identifier, call time, and environment information.

[0115] In an optional implementation, the data acquisition module includes a dynamic sampling unit, which is used to dynamically adjust the sampling strategy according to the number of online users. The sampling strategy is used to control the range of resource call data and the acquisition frequency.

[0116] In an optional implementation, the data analysis module includes a resource acquisition unit for acquiring the complete resource set of the application; a call analysis unit for determining the subset of resources called within a specified time period based on resource call data; and a set operation unit for performing set operations on the complete resource set and the resource subset to obtain the resource set to be optimized.

[0117] In an optional implementation, the set operation unit includes an uncalled resource determination subunit, used to determine an uncalled resource subset based on the set operation result; a low-frequency resource determination subunit, used to determine a low-frequency called resource subset based on the calling frequency of each resource in the called resource subset within a specified time period; and a merging subunit, used to merge the uncalled resource subset and the low-frequency called resource subset to obtain a resource set to be optimized.

[0118] In an optional implementation, the resource optimization module includes a resource classification unit for determining the resource subsets to be removed and the resource subsets to be migrated based on the resource set to be optimized; a removal processing unit for performing resource removal processing on the resource subsets to be removed; and a relocation processing unit for performing resource relocation processing on the resource subsets to be migrated.

[0119] In an optional implementation, the removal processing unit includes an isolation subunit for placing the resources to be removed from the subset of resources to be removed into an isolation area; a monitoring subunit for monitoring abnormal conditions related to each resource to be removed during the observation period; a removal execution subunit for completely removing the resources to be removed from the application that did not exhibit any abnormal conditions during the observation period; and a recovery subunit for restoring the resources to be removed that exhibited abnormal conditions during the observation period to their original state.

[0120] In an optional implementation, the relocation processing unit includes a classification subunit for classifying the resources to be migrated in the subset of resources to be migrated; a modularization subunit for configuring the resources to be migrated as independent resource modules according to their categories; and a trigger condition setting subunit for setting the on-demand loading trigger conditions for the independent resource modules.

[0121] In an optional implementation, the resource classification unit includes a static analysis subunit, used to perform static analysis on the resource codes corresponding to the resource set to be optimized to determine resource dependencies; and a classification decision subunit, used to determine the resource subset to be removed and the resource subset to be migrated based on the resource dependencies.

[0122] In an optional implementation, the classification decision subunit includes an interface generation subunit for generating a display interface based on resource dependencies; and a scheme receiving subunit for receiving resource processing schemes submitted through the display interface and determining the resource subsets to be removed and the resource subsets to be migrated based on the resource processing schemes.

[0123] In an optional implementation, the apparatus further includes a testing module for performing automated tests on the target application to detect test anomalies; and a rollback module for automatically reverting to the application before optimization when the proportion of test anomalies exceeds a threshold.

[0124] The application optimization device provided in this disclosure has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0125] It should be noted that although several units / modules or sub-units / modules of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0126] This invention also provides an electronic device, such as... Figure 4 As shown, the electronic device includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor. The processor executes the computer-executable instructions to implement any application optimization method of the embodiments of this disclosure. For specific implementation methods and the resulting technical effects, please refer to the method embodiments, which will not be repeated here.

[0127] Figure 4 This is a schematic diagram of the structure of an electronic device. The electronic device 1100 includes a processor 1101 with one or more processing cores, a memory 1102 with one or more computer-readable storage media, and a computer program stored in the memory 1102 and executable on the processor. The processor 1101 and the memory 1102 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0128] The processor 1101 is the control center of the electronic device 1100. It connects various parts of the electronic device 1100 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 1102, and calling data stored in the memory 1102, it executes various functions of the electronic device 1100 and processes data, thereby performing overall monitoring of the electronic device 1100.

[0129] Optionally, the electronic device 1100 further includes: a touch display screen 1103, a radio frequency circuit 1104, an audio circuit 1105, an input unit 1106, and a power supply 1107. The processor 1101 is electrically connected to the touch display screen 1103, the radio frequency circuit 1104, the audio circuit 1105, the input unit 1106, and the power supply 1107. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0130] This invention also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute any application optimization method of this disclosure embodiment when run by a processor. For specific implementation methods and the resulting technical effects, please refer to the method embodiments, which will not be repeated here.

[0131] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal device, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0132] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0133] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An application optimization method, characterized in that, include: Collect resource call data of the application on the user's device; Based on the resource call data, identify the set of resources to be optimized; The optimization process is performed on the set of resources to be optimized to obtain the optimized target application. The optimization process includes resource removal or resource relocation.

2. The method according to claim 1, characterized in that, The data collected by the application on the user device includes: Resource call events are captured through a monitoring mechanism embedded in the application; Record resource call information, which includes at least the resource identifier, call time, and environment information.

3. The method according to claim 1, characterized in that, The data collected by the application on the user device includes: The sampling strategy is dynamically adjusted based on the number of online users. The sampling strategy is used to control the range and frequency of resource call data collected.

4. The method according to claim 1, characterized in that, The process of identifying the set of resources to be optimized based on the resource call data includes: Obtain the complete resource set of the application; Based on the resource call data, determine the subset of resources that were called within the specified time period; The set of resources to be optimized is obtained by performing set operations on the complete set of resources and the subset of resources.

5. The method according to claim 4, characterized in that, The step of performing set operations on the complete resource set and the resource subset to obtain the resource set to be optimized includes: Based on the results of set operations, determine the subset of resources that were not invoked; Based on the call frequency of each resource in the called resource subset within the specified time period, determine the low-frequency call resource subset; The subset of unused resources and the subset of low-frequency used resources are combined to obtain the set of resources to be optimized.

6. The method according to claim 1, characterized in that, The optimization process performed on the set of resources to be optimized includes: Based on the set of resources to be optimized, determine the subset of resources to be removed and the subset of resources to be migrated; Perform resource removal processing on the subset of resources to be removed; Perform resource relocation processing on the subset of resources to be migrated.

7. The method according to claim 6, characterized in that, The process of performing resource removal on the subset of resources to be removed includes: Place the resources to be removed from the subset of resources to be removed into an isolation area; Monitor for anomalies related to each resource to be removed during the observation period; Completely remove the resources to be removed from the application that did not exhibit any abnormalities during the observation period; Restore any resources that exhibit abnormal behavior during the observation period to their original state.

8. The method according to claim 6, characterized in that, The process of performing resource relocation on the subset of resources to be migrated includes: The resources to be migrated in the subset of resources to be migrated are classified. Configure the resources to be migrated as independent resource modules according to their categories; Configure the on-demand loading trigger conditions for the independent resource module.

9. The method according to claim 6, characterized in that, The step of determining the subset of resources to be removed and the subset of resources to be migrated based on the set of resources to be optimized includes: Static analysis is performed on the resource code corresponding to the set of resources to be optimized to determine resource dependencies; Based on the resource dependencies, the resource subsets to be removed and the resource subsets to be migrated are determined.

10. The method according to claim 9, characterized in that, The process of determining the subset of resources to be removed and the subset of resources to be migrated based on the resource dependencies includes: Based on the aforementioned resource dependencies, a display interface is generated; Receive resource processing solutions submitted through the display interface, and determine the resource subsets to be removed and the resource subsets to be migrated based on the resource processing solutions.

11. The method according to claim 1, characterized in that, The method further includes: Perform automated tests on the target application and detect test anomalies; When the percentage of test anomalies exceeds the threshold, the application will automatically revert to its pre-optimization state.

12. An application optimization device, characterized in that, include: The data acquisition module is used to collect resource call data of the application on the user's device; The data analysis module is used to identify a set of resources to be optimized based on the resource call data. The resource optimization module is used to perform optimization processing on the set of resources to be optimized to obtain the optimized target application. The optimization process includes resource removal or resource relocation.

13. An electronic device, characterized in that, include: Memory stores computer-executable instructions that can be executed by a processor; A processor for executing the computer-executable instructions to implement the method as claimed in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1-11.

Images