Application management method and device, electronic equipment and computer readable storage medium

Abstract

The embodiment of the invention discloses an application management method and device, electronic equipment and a computer readable storage medium, and belongs to the technical field of application management.According to the embodiment of the invention, a dynamic loading path and a static loading path of a target application are obtained, and the static loading path and the dynamic loading path are fused; according to the embodiment of the invention, the target loading path of the target application is obtained, and the compressed file of the target application can be decompressed according to the target loading path in response to the starting instruction of the target application. Thus, by optimizing the loading path of the target application, the optimized target loading path can better adapt to the actual use scene of the target application, and meanwhile, the compressed file of the target application can be decompressed more efficiently and reasonably, so that the starting delay of the target application is effectively reduced, and the use experience of a user is improved.

Description

Technical Field

[0001] This application relates to the field of application management technology, specifically to an application management method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] With the popularization of smart devices, there are more and more applications installed on these devices. Due to the limited storage resources of the devices, when an application is not used for a long time, the target files used by the application are usually compressed to save storage space.

[0003] In related technologies, when an application starts, it typically decompresses all of the application's compressed files in a blocking manner in a fixed order. This decompression method leads to high application startup delays, which in turn affects the user experience. Summary of the Invention

[0004] This application provides an application management method, apparatus, electronic device, and computer-readable storage medium. By optimizing the loading path of the target application, the decompression efficiency of compressed files can be effectively improved, thereby reducing the startup delay of the target application.

[0005] In a first aspect, embodiments of this application provide an application management method, including:

[0006] Obtain the dynamic loading path and static loading path of the target application;

[0007] The static loading path and the dynamic loading path are merged to obtain the target loading path of the target application;

[0008] In response to the launch command of the target application, the compressed file of the target application is decompressed according to the target loading path.

[0009] In one embodiment, the method further includes:

[0010] Obtain the predicted usage probability of the target application, as well as the remaining storage space and device status of the target device;

[0011] When the predicted usage probability is less than a probability threshold, the remaining storage space is less than a storage space threshold, and the device status indicates that the target device is in an idle state, the target file corresponding to the target application is compressed to obtain the compressed file.

[0012] In one embodiment, the predicted probability is obtained based on the following method:

[0013] Obtain the geographic scene information corresponding to the location information of the target device, and determine the geographic matching degree between the target application and the geographic scene information;

[0014] Calculate the time decay value of the target application based on the unused time of the target application in the current statistical period;

[0015] By performing behavioral transfer analysis on user usage habits for the target application, the behavioral transfer probability of the target application can be obtained.

[0016] The predicted usage probability is determined based on the geographic matching degree, the time decay value, and / or the behavior transfer probability.

[0017] In one embodiment, the dynamic loading path is determined in the following manner:

[0018] Obtain the directed acyclic graph of the target application; the directed acyclic graph includes multiple loading paths, the loading paths are nodes of multiple sub-files in the target file corresponding to the target application, and the loading order relationship of the multiple sub-files is the edge;

[0019] The dynamic loading path is determined from the multiple loading paths in the directed acyclic graph based on the target parameters of the multiple sub-files.

[0020] In one embodiment, the target parameters include the loading time and the number of times the sub-file is depended upon;

[0021] The step of determining the dynamic loading path from multiple loading paths in the directed acyclic graph based on the target parameters of multiple sub-files includes:

[0022] For any of the loading paths, the loading time and the number of times each of the sub-files in the loading path is dependent are weighted to obtain the weighted path corresponding to the loading path;

[0023] The longest weighted path among the multiple weighted paths is determined as the dynamic loading path.

[0024] In one embodiment, the static loading path includes the static weights of multiple sub-files in the target file corresponding to the target application, and the dynamic loading path includes the dynamic weights of multiple sub-files.

[0025] The step of fusing the static loading path and the dynamic loading path to obtain the target loading path of the target application includes:

[0026] The dynamic weight and static weight of each sub-file are fused together to obtain the fused weight corresponding to each sub-file.

[0027] Based on the fusion weights corresponding to each of the multiple sub-files and the file dependencies corresponding to the dynamic loading path, the target loading path of the target application is obtained.

[0028] In one embodiment, decompressing the compressed file according to the target loading path includes:

[0029] Based on the target loading path, the decompression priority of multiple compressed sub-files in the compressed file is determined;

[0030] The compressed sub-file whose decompression priority is in the first priority range is determined as the first sub-file to be decompressed; the compressed sub-file whose decompression priority is in the second priority range is determined as the second sub-file to be decompressed; and the other files in the multiple compressed sub-files other than the first and second sub-files to be decompressed are determined as the third sub-files to be decompressed.

[0031] The first sub-file to be decompressed is decompressed. After the first sub-file to be decompressed is decompressed, the second sub-file to be decompressed is decompressed.

[0032] In response to the access request for the third sub-file to be decompressed, the third sub-file to be decompressed is decompressed.

[0033] Secondly, embodiments of this application provide an application management device, including:

[0034] The path acquisition module is used to obtain the dynamic loading path and static loading path of the target application;

[0035] The path fusion module is used to fuse the static loading path and the dynamic loading path to obtain the target loading path of the target application;

[0036] The file decompression module is used to decompress the compressed file of the target application in response to the launch command of the target application, according to the target loading path.

[0037] In one embodiment, the application management device further includes:

[0038] The information acquisition module is used to acquire the predicted usage probability of the target application, as well as the remaining storage space and device status of the target device;

[0039] The file compression module is used to compress the target file corresponding to the target application to obtain the compressed file when the predicted usage probability is less than a probability threshold, the remaining storage space is less than a storage space threshold, and the device status indicates that the target device is in an idle state.

[0040] In one embodiment, the application management device further includes:

[0041] The first parameter determination module is used to obtain the geographic scene information corresponding to the location information of the target device, and determine the geographic matching degree between the target application and the geographic scene information;

[0042] The second parameter determination module is used to calculate the time decay value of the target application based on the unused duration of the target application in the current statistical period.

[0043] The third parameter determination module is used to perform behavior transfer analysis on the user's usage habit information for the target application to obtain the behavior transfer probability of the target application.

[0044] A probability prediction module is used to determine the predicted usage probability based on the geographic matching degree, the time decay value, and / or the behavior transfer probability.

[0045] In one embodiment, the application management device further includes:

[0046] The path acquisition module is used to acquire the directed acyclic graph of the target application; the directed acyclic graph includes multiple loading paths, the loading paths are based on multiple sub-files in the target file corresponding to the target application as nodes, and the loading order relationship of the multiple sub-files as edges;

[0047] The path determination module is used to determine the dynamic loading path among the multiple loading paths in the directed acyclic graph based on the target parameters of the multiple sub-files.

[0048] In one embodiment, the target parameters include the loading time and the number of times the sub-file is depended upon; the path determination module includes:

[0049] The path weight determination submodule is used to perform a weighted calculation on the loading time and the number of times each of the multiple sub-files in the loading path for any loading path, so as to obtain the weighted path corresponding to the loading path.

[0050] The path determination submodule is used to determine the longest weighted path among the multiple weighted paths as the dynamic loading path.

[0051] In one embodiment, the static loading path includes the static weights of multiple sub-files in the target file corresponding to the target application, and the dynamic loading path includes the dynamic weights of multiple sub-files; the path fusion module includes:

[0052] The weight fusion submodule is used to perform fusion calculation on the dynamic weight and static weight of each sub-file to obtain the fusion weight corresponding to each sub-file.

[0053] The loading path generation submodule is used to obtain the target loading path of the target application based on the fusion weights corresponding to the multiple sub-files and the file dependencies corresponding to the dynamic loading path.

[0054] In one embodiment, the file decompression module includes:

[0055] The priority determination submodule is used to determine the decompression priority of multiple compressed sub-files in the compressed file based on the target loading path;

[0056] The file partitioning submodule is used to determine the compressed subfiles whose decompression priority is in the first priority range as the first subfiles to be decompressed, the compressed subfiles whose decompression priority is in the second priority range as the second subfiles to be decompressed, and the other files in the multiple compressed subfiles other than the first and second subfiles to be decompressed as the third subfiles to be decompressed.

[0057] The first decompression submodule is used to decompress the first sub-file to be decompressed, and after the first sub-file to be decompressed is decompressed, to decompress the second sub-file to be decompressed;

[0058] The second decompression submodule is used to decompress the third subfile in response to an access request for the third subfile to be decompressed.

[0059] Thirdly, embodiments of this application also provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the application management method described above.

[0060] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the application management method described above.

[0061] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described in embodiments of this application.

[0062] In summary, in this embodiment, by obtaining the dynamic and static loading paths of the target application and fusing them, the target loading path of the target application is obtained. This allows the application to respond to its startup command and decompress its compressed files according to the target loading path. By optimizing the target application's loading path, this embodiment better adapts to the actual usage scenarios of the target application and decompresses its compressed files more efficiently and effectively, thereby reducing startup latency and improving the user experience. Attached Figure Description

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

[0064] Figure 1 This is a schematic diagram illustrating the steps of an application management method provided in an embodiment of this application;

[0065] Figure 2 This is a schematic diagram of the structure of an application management device provided in an embodiment of this application;

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

[0067] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0068] It should be noted that after the application is installed, the application's configuration file usually includes a CSCP (ColdStart Critical Path). CSCP can be an XML configuration file that describes the file loading order and dependencies when the application starts.

[0069] In related technologies, the CSCP used when an application starts is usually a static loading path, that is, a predefined and fixed file loading path. When the application starts, it needs to blockily decompress all the application's compressed files in a fixed order indicated by the static loading path, which leads to high application startup delays and thus affects the user experience.

[0070] To address the issue of high application startup latency, this application aims to provide an application management method. This method obtains the dynamic and static loading paths of a target application and merges them to obtain the target loading path. Responding to the application's startup command, the method decompresses the application's compressed files according to the target loading path. This embodiment optimizes the target application's loading path, making it better suited to the application's actual usage scenarios. It also enables more efficient and reasonable decompression of the application's compressed files, thereby effectively reducing startup latency and improving the user experience.

[0071] Figure 1 A flowchart illustrating an embodiment of an application management method according to this application is shown. The entity executing this application management method may be an application management device, which may be integrated into any electronic device with data processing, network communication, and program execution functions. This electronic device may be a server or a terminal, etc.

[0072] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), as well as big data and artificial intelligence platforms.

[0073] The terminal can be a smartphone, tablet, laptop, desktop computer, smart home device, etc., but is not limited to these. The terminal and server can be connected directly or indirectly through wired or wireless communication, which is not limited herein.

[0074] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0075] In this embodiment, the description will be from the perspective of an application management device, which can be integrated into a server or terminal. To facilitate the explanation of the application management method of this application, the following will describe the application management device integrated into a terminal in detail, that is, the terminal will be used as the execution subject.

[0076] Reference Figure 1 This application illustrates an application management method, which may specifically include the following steps:

[0077] S101: Obtain the dynamic loading path and static loading path of the target application.

[0078] In this embodiment, the terminal can install multiple Apps (Applications, hereinafter referred to as applications), and the target application can be any of the multiple applications installed on the terminal.

[0079] It should be noted that the static load path refers to a fixed file load path predefined for the target application. This static load path reflects the various files that the target application may use during runtime.

[0080] In this embodiment, the terminal can parse the application package of the target application to extract the static loading path of the target application. For example, if the terminal uses the Android operating system, it can parse the AndroidManifest.xml file in the target application's APK (Android application package) and then extract the static loading path of the target application. <uses-library>The declared library dependencies are extracted in order to obtain the static loading path of the target application.

[0081] It should be noted that the dynamic loading path refers to the file loading path obtained by recording and analyzing the actual loading path of the target application during runtime. This dynamic loading path reflects the various files actually used by the target application during operation.

[0082] In this embodiment, the terminal can implant probes into the system to record file access events of the target application. Each file access event can be parsed to obtain an actual loading path. By filtering the actual loading paths corresponding to multiple file access events, the dynamic loading path that best meets the actual loading needs of the target application can be obtained. For example, a probe can be implanted in the openat() (a system call) of the Linux VFS (virtual file system) layer to record the file access events of the target application, thereby achieving dynamic awareness of the actual loading path.

[0083] In this embodiment, the dynamic loading path can change as the target application's file access events change. That is, if the target application has a new file access event, i.e., after the target application starts according to the new actual loading path, the dynamic loading path can be updated based on the new actual loading path.

[0084] S102: Merge the static loading path and the dynamic loading path to obtain the target loading path of the target application.

[0085] In this implementation, since the dynamic loading path describes the file loading order and dependencies during actual application use, the dynamic loading path may differ from the file loading order and dependencies in the static loading path. Therefore, the static and dynamic loading paths will be merged to obtain the final target loading path.

[0086] It should be noted that the target load path represents the file loading path that the target application will depend on upon its next startup. The target load path can be updated along with updates to the dynamic load path.

[0087] In this embodiment, by combining deterministic static loading paths and real-time dynamic loading paths, the generated target loading path will not miss critical files, and will prioritize loading files that are actually time-consuming and frequently depended on during the actual use of the target application, thereby achieving effective optimization of the target application's loading path.

[0088] S103: In response to the target application's startup command, decompress the target application's compressed file according to the target loading path.

[0089] In this embodiment, the launch command of the target application can be triggered based on the application's self-starting behavior, based on the user's click operation, or triggered by the associated launch behavior of other applications.

[0090] In this embodiment, when the terminal detects that the target application needs to be launched, it will decompress the compressed file of the target application according to the file loading order indicated by the target loading path to obtain the decompressed target file, which is used to support the normal operation of the target application. In this way, it can ensure that, while satisfying file dependencies, those critical files that have a greater impact on the decompression progress are loaded first, thereby optimizing the efficiency of the decompression process and enabling the application to complete decompression and enter a usable state more quickly.

[0091] In this embodiment, the loading path of the target application is optimized so that the optimized target loading path can better adapt to the actual usage scenario of the target application, and can decompress the compressed file of the target application more efficiently and reasonably, thereby effectively reducing the startup delay of the target application and improving the user experience.

[0092] In one feasible implementation, to compress the target files of the target application at an appropriate time, the application management method may further include the following steps:

[0093] S201: Obtain the predicted usage probability of the target application, as well as the remaining storage space and device status of the target device.

[0094] In this embodiment, the predicted usage probability can be obtained based on the associated usage information of the target application. This associated usage information may include the location information of the target device where the target application is located, the unused duration of the target application within the current statistical period, and the user's usage habits regarding the target application.

[0095] In this embodiment, the terminal can independently obtain the associated usage information of the target application, and then determine the predicted usage probability based on the associated usage information; or the terminal can receive the predicted usage probability determined by the server based on the associated usage information.

[0096] In this embodiment, by comprehensively analyzing the associated usage information, an accurate prediction of the predicted usage probability can be achieved.

[0097] In this embodiment, the target device refers to the terminal according to the target application. The terminal can monitor the remaining storage space of the target device in real time to determine whether the remaining storage space of the target device is sufficient. Specifically, the remaining storage space can be represented by the remaining storage capacity, for example, the remaining storage space can represent that the target device has 1GB of storage space remaining; it can also be represented by the proportion of the remaining storage capacity to the total storage capacity, for example, the remaining storage space can represent that the target device has 20% of the storage space remaining.

[0098] In this embodiment, the device state of the target device is used to reflect whether the target device is in an idle state. Specifically, the device state can be set to the target state when it is detected that the target device is in a charging state, a screen-off state, and / or a no-call state. This target state indicates that the target device is in an idle state.

[0099] S202: When the predicted usage probability is less than the probability threshold, the remaining storage space is less than the storage space threshold, and the device status indicates that the target device is in an idle state, the target file corresponding to the target application is compressed to obtain a compressed file.

[0100] In this embodiment, if the predicted usage probability of the target application is less than the probability threshold, it means that the user is likely not to use the target application; if the remaining storage space is less than the storage space threshold, it means that the remaining storage space of the target device is insufficient; if the device status indicates that the target device is in an idle state, it means that decompressing the target file at this time will not affect the user's normal use.

[0101] In this embodiment, by comprehensively considering the predicted usage probability, the remaining storage space of the target device, and the device status, the compression of the target file can be triggered at an appropriate time, thereby successfully completing the compression operation of the target file without affecting the user's use.

[0102] In this embodiment, compressing the target file corresponding to the target application may specifically include: obtaining the file types of multiple sub-files in the target file; for any sub-file, determining the compression algorithm for that sub-file based on its file type; and compressing the multiple sub-files based on their respective compression algorithms to obtain a compressed file.

[0103] In one example, considering the large number of .so files (e.g., libart.so) in the target file, the Zstd algorithm, with its higher compression ratio, can be used to compress the .so files, while the LZ4 algorithm, with its faster compression speed, can be used to compress the dex files (e.g., classes.dex) and odex files. Zstd is an open-source, high-performance lossless compression algorithm known for its excellent balance between compression ratio and speed, suitable for high-write-volume scenarios. LZ4 is a highly efficient lossless compression algorithm based on LZ77 theory, known for its extremely fast compression and decompression speeds, suitable for real-time data processing, network transmission, and other scenarios.

[0104] In this embodiment, by matching different compression algorithms to sub-files of different file types, the compression ratio and compression speed of the target file can be effectively improved, thereby improving the compression effect while effectively saving storage space on the target device.

[0105] In one feasible implementation, the predicted probability of use can be obtained based on the following steps:

[0106] S301: Obtain the geographic scene information corresponding to the location information of the target device, and determine the geographic matching degree between the target application and the geographic scene information.

[0107] It's important to note that geographic matching score represents the probability of a user using the target application based on their location. A lower geographic matching score indicates a lower probability of the user using the target application.

[0108] In this embodiment, considering that users have different needs for different types of applications under different geographical scenarios, for example, if a user is in a food street, there is a high demand for food-related applications; if a user is in a tourist area, there is usually a high demand for tourism-related applications. Therefore, the terminal can obtain the location information of the target device and identify the geographical scenario information corresponding to the location information, thereby determining whether the target application has a high degree of geographical matching with the geographical scenario information.

[0109] In practical implementation, the terminal can access map services such as Gaode Maps to obtain POI (Point of Interest) information in real time, and then construct a POI type mapping table. This POI type mapping table is used to reflect the correspondence between location information and geographic scene information. For example, geographic scene information can specifically include transportation hubs, commercial scenes, cultural and educational venues, and tourist attractions. Among them, the location information corresponding to transportation hubs can include airports, train stations, bus stops, etc.; the location information corresponding to commercial scenes can include shopping malls, restaurants, food courts, etc.; the location information corresponding to cultural and educational venues can include museums, schools, etc.; and the location information corresponding to tourist attractions can include various preset tourist attractions.

[0110] In this embodiment, geographic matching degree is dynamically calculated using geofencing. Specifically, the distance between the location information and the center of the geofence corresponding to the point of interest can be obtained. Then, based on the distance and the geofence radius, the geographic matching degree between the target application and the geographic scene information is calculated. Specifically, the geographic matching degree can be calculated according to the following formula:

[0111] Mg=1-d / R (1);

[0112] Where Mg represents the geographic matching degree; d represents the distance between the location information of the target device and the center of the geofence corresponding to the point of interest; and R represents the geofence radius.

[0113] In one example, if a user is detected at an airport check-in counter at airport A, the geographic scene information is determined to be a transportation hub. The target application is a travel application corresponding to the transportation hub. If the geofence radius of airport A is detected to be 200 meters, and the distance from the airport check-in counter to the center of the geofence is 10 meters, then the matching degree between the travel application and the transportation hub can be calculated using the following formula: Mg = 1 - 10 / 200 = 0.95. This means that the travel application corresponding to the transportation hub has a higher usage priority and should be retained first, while other applications unrelated to the transportation hub can use a preset lower matching degree.

[0114] In this embodiment, by analyzing the likelihood of use of the target application in terms of geographical location, applications that are unrelated to the geographical scene information corresponding to the location information can be compressed, while applications that match the geographical scene information corresponding to the location information can be retained.

[0115] S302: Calculate the time decay value of the target application based on the unused time of the target application in the current statistical period.

[0116] It's important to note that the time decay value represents the probability of a user using the target application over time. A lower time decay value indicates a lower probability of user use. The time decay value decreases as the duration of inactivity increases; that is, the longer the target application is inactive, the lower the likelihood of user use, and consequently, the smaller the time decay value.

[0117] In this implementation, the unused duration can be determined based on the difference between the current time and the last time of use within the current statistical period; if the target application has not been used within the current statistical period, the unused duration is the difference between the current time and the start time of the current statistical period.

[0118] In this implementation, considering that user preferences for applications may change over time—for example, an application that a user rarely used before may become frequently used during business trips—a dynamic sliding window mechanism will be introduced to improve the accuracy of the time decay value, automatically adjusting the statistical period based on the user's usage scenario.

[0119] In practice, the current statistical period can be updated based on a regular statistical window and a holiday extended window. Specifically, the regular statistical window can be fixed at 7 days; the holiday extended window is triggered when long holidays such as Spring Festival and National Day are detected, automatically extending the time window to 30 days.

[0120] In this embodiment, the time decay value of the target application can be calculated according to the following formula:

[0121] W t =e -λ.Δt (2);

[0122] Among them, W t λ represents the time decay value of the target application; λ represents the decay coefficient; Δt represents the unused time within the current statistical period.

[0123] In one example, λ is taken as 0.05 / s, and an application is not used for 3 days (259,200 seconds), then W can be calculated. t =e^(-0.05×259200)=2.2×10^-5. This indicates that the application has extremely low activity, and users are highly unlikely to use it.

[0124] In this embodiment, by analyzing the likelihood of using the target application over time, the time activity of the target application can be effectively identified.

[0125] S303: Perform behavioral transfer analysis on user usage habits for the target application to obtain the behavioral transfer probability of the target application.

[0126] It's important to note that behavioral transition analysis is a method for studying user behavior patterns and their changes. It involves observing users' behavioral states at different points in time (such as using or not using an app) and analyzing the transitions between these states. When a user's habits change, their behavioral transition patterns will also change accordingly. For example, if a user previously used an app frequently during a fixed period but then didn't use it for several consecutive days, this behavioral transition reflects a possible change in the user's habits, perhaps a decrease in interest in the app, or a change in usage needs, leading to prolonged inactivity of the app.

[0127] In practical implementation, the state transition probabilities of the target application can be calculated using a second-order Markov chain. A Markov chain is a stochastic process model used to describe the transition patterns of a system between different states. When calculating the transition probability of a given state, a second-order Markov chain considers not only the current state but also the previous state.

[0128] In one example, if a user hasn't used the target app for two consecutive days, based on a second-order Markov chain, the probability of the user using the app on the third day can be calculated as P(use | no use in the previous two days) = 15%. This means that in this case, the likelihood of the user resuming app use is relatively low; there's only a 15% probability of using it, while there's an 85% probability of remaining inactive. This reflects that the target app isn't particularly important to the user's life and they haven't developed a strong usage habit, or that the app's appeal is insufficient to motivate the user to use it again after a certain time interval.

[0129] In another example, if a user used the target application yesterday, then based on a second-order Markov chain, the probability that the user will use the target application today can be calculated as P(use | yesterday's use) = 70%. In other words, once a user used the application yesterday, there is a high probability that they will continue to use it today. This reflects that the target application may have a certain stickiness, or that the user's usage scenario is continuous, such as some work-related applications or daily tool applications, where users may form a habit of continuous use.

[0130] In this embodiment, by calculating the behavior transfer probability of the target application, the likelihood of a user using the target application can be accurately determined from the perspective of user habits.

[0131] S304: Determine the predicted usage probability based on geographic matching degree, time decay value and / or behavior transfer probability.

[0132] In this embodiment, the geographic matching degree, time decay value and behavior transfer probability can be normalized to transform the above parameters into the [0,1] interval.

[0133] In practice, the geographic matching degree, time decay value, and behavior transfer probability after normalization can be weighted to obtain the predicted usage probability of the target application.

[0134] In practical implementation, the normalized geographic matching degree, time decay value, and behavior transfer probability can be input into the pre-trained prediction model to obtain the predicted usage probability output by the prediction model. The prediction model can be trained based on a federated aggregation mechanism, where multiple terminals train a lightweight neural network model (3 fully connected layers) locally using training samples. A central server aggregates the model parameters uploaded by multiple terminals, updates the global model version to obtain the prediction model, and then distributes the prediction model to each terminal.

[0135] In this embodiment, by comprehensively predicting the probability of use based on time, location, and user behavior, it is possible to accurately identify low-frequency applications and thus accurately compress the target files corresponding to low-frequency applications, thereby saving terminal storage space.

[0136] In one feasible implementation, the dynamic loading path can be determined through the following steps:

[0137] S401: Obtain the directed acyclic graph of the target application.

[0138] It should be noted that a Directed Acyclic Graph (DAG) is a graph structure composed of vertices and directed edges. Its core characteristic is that it is acyclic, meaning that there is no path that starts from any vertex, goes through several edges, and returns to itself.

[0139] In this embodiment, by monitoring file access events of the target application during its startup process, a directed acyclic graph (DAG) of the target application can be obtained. This DAG includes multiple loading paths, where each loading path uses multiple sub-files within the target application's target file as nodes, and the loading order of these sub-files forms the edges. For example, if the target application accesses libB, libA, and libD sequentially, a loading path can be obtained as: libB→libA→libD.

[0140] S402: Determine the dynamic loading path among multiple loading paths in a directed acyclic graph based on the target parameters of multiple sub-files.

[0141] In this embodiment, the target parameters of a subfile represent parameters that reflect the importance of the subfile. Specifically, the target parameters may include the loading time of the subfile and the number of times it is depended upon.

[0142] In this embodiment, by analyzing the target parameters of multiple sub-files, a suitable dynamic loading path can be selected from multiple loading paths. This dynamic loading path includes all sub-files that are truly time-consuming and frequently depended upon.

[0143] In one feasible implementation, the step of determining a dynamic loading path among multiple loading paths in a directed acyclic graph based on the target parameters of multiple sub-files may specifically include the following sub-steps:

[0144] S402-1: For any loading path, perform a weighted calculation on the loading time and the number of times each sub-file in the loading path is depended upon, to obtain the weighted path corresponding to the loading path.

[0145] In this embodiment, loading time refers to the time consumed during the decompression and loading of the sub-file. This loading time is related to the size and type of the sub-file and the decompression algorithm.

[0146] In this implementation, the number of times a sub-file is depended on represents the number of times that sub-file is depended on by other files. The more times a file is depended on, the more important it is in the decompression process and the more crucial it is in influencing the loading of subsequent files.

[0147] In this embodiment, a first weighting coefficient can be assigned to the loading time of a sub-file, and a second weighting coefficient can be assigned to the number of times a sub-file is depended upon. Then, based on the first and second weighting coefficients, a weighted calculation is performed on the loading time and the number of times a sub-file is depended upon in the loading path to obtain the weighted path corresponding to the loading path. The sum of the first and second weighting coefficients is 1.

[0148] In this embodiment, the loading time and the number of dependencies are combined to calculate the weight, which can comprehensively consider the impact of the processing time of the sub-file itself and its dependency relationship with other sub-files on the entire decompression and loading process, thereby obtaining a weighted path that can reflect the importance of the path.

[0149] S402-2: The longest weighted path among multiple weighted paths is determined as the dynamic loading path.

[0150] In this implementation, by comprehensively considering the loading time and number of dependencies of each sub-file, and selecting the longest weighted path as the dynamic loading path, not only can the omission of key files be effectively avoided, but the overall startup time of the target application can also be shortened to the greatest extent.

[0151] In one feasible implementation, the static loading path includes the static weights of multiple sub-files in the target file corresponding to the target application, and the dynamic loading path includes the dynamic weights of multiple sub-files. The step of fusing the static loading path and the dynamic loading path to obtain the target loading path of the target application may specifically include the following sub-steps:

[0152] S102-1: Perform a fusion calculation on the dynamic weight and static weight of each sub-file to obtain the fusion weight corresponding to each sub-file.

[0153] In this embodiment, dynamic weight represents the weight of each sub-file in the dynamic loading path. During the decompression and loading process, the weight of each sub-file is dynamically adjusted based on factors such as real-time loading time and the number of times it is depended on, reflecting the priority of each file in the actual use scenario.

[0154] In this embodiment, static weight represents the weight of each sub-file in the static loading path. It can be preset according to the size, type, historical usage frequency, etc. of the sub-file, reflecting the importance of each file by default.

[0155] In this embodiment, a third weighting coefficient can be assigned to the dynamic weight of the sub-file, and a fourth weighting coefficient can be assigned to the static weight of the sub-file. Then, based on the third and fourth weighting coefficients, a weighted calculation is performed on the dynamic and static weights of the sub-file to obtain the corresponding fusion weight of the sub-file. The sum of the third and fourth weighting coefficients is 1.

[0156] S102-2: Based on the fusion weights of multiple sub-files and the file dependencies of the dynamic loading paths, the target loading path of the target application is obtained.

[0157] In this embodiment, since the file dependencies corresponding to the dynamically loaded path can reflect the file dependencies of the target application in actual use, the file dependencies corresponding to the dynamically loaded path will be used as the standard when performing path fusion. Then, the fusion weights of multiple sub-files will be comprehensively considered to obtain the final target loading path.

[0158] In this embodiment, by comprehensively considering the fusion weight of sub-files and the file dependencies corresponding to the dynamic loading path, the static loading path and the dynamic loading path are fused, so that the generated target loading path can better adapt to the actual use scenario and improve the loading performance of the application.

[0159] In one example, the static loading path of application A is: libA→libB→libC. Assigning static weights according to the declaration order, we get the static weights as: W_static(libA) = 3, W_static(libB) = 2, W_static(libC) = 1. The dynamic loading path of application A is: libB→libA→libD. The calculated dynamic weights (calculated as: loading time × 0.7 + number of dependencies × 0.3) are: W_dynamic(libB) = 56.9, W_dynamic(libA) = 71.5, W_dynamic(libD) = 105.6.

[0160] During the path fusion process, if a path conflict is found, that is, a conflict between libA→libB in the static path and libB→libA in the dynamic path, the file dependency relationship corresponding to the dynamically loaded path shall prevail. That is, the dependency of the dynamically loaded path shall override the dependency of the static loaded path, and other non-conflicting dependencies shall be retained (such as libB→libC in the static path).

[0161] With the dynamic weight of the sub-file set to 0.7 and the static weight to 0.3, and the fusion weight formula as: Wfinal = Wdynamic × 0.7 + Wstatic × 0.3, the fusion weight for each sub-file can be calculated as follows:

[0162] Wfinal(libA)=71.5×0.7+3×0.3=50.05+0.9=50.95;

[0163] Wfinal(libB)=56.9×0.7+2×0.3=40.83+0.6=41.4343;

[0164] Wfinal(libC) = 0 × 0.7 + 1 × 0.3 = 0.3; where libC only exists in the static loading path, so its dynamic weight is 0;

[0165] Wfinal(libD) = 105.6 × 0.7 + 0 × 0.3 = 73.92; where libD only exists in the dynamic loading path, so its static weight is 0.

[0166] Dependencies include:

[0167] libB→libA (dynamic overwriting);

[0168] libB→libC (statically reserved);

[0169] libA→libD (dynamically added).

[0170] During path fusion, nodes at the same level are sorted by weight:

[0171] Initial loadable node: libB (no dependencies, highest weight);

[0172] After libB is loaded, the available nodes are libA (weight 50.95) and libC (weight 0.3), with libA being the preferred choice.

[0173] After loading libA, load libD (weight 73.92);

[0174] Finally, libC is loaded;

[0175] Therefore, the final target loading path can be obtained as: libB.so→{libA.so, libC.so}→libD.so; where the file libA.so has a higher priority than the file libC.so.

[0176] After obtaining the target loading path, the target loading path can be stored in CSCP format. Then, when the target application needs to start, the target loading path can be read and the compressed file of the target application can be decompressed according to the target loading path.

[0177] In one feasible implementation, the step of decompressing the compressed file according to the target loading path in S103 may specifically include the following sub-steps:

[0178] S103-1: Determine the decompression priority of multiple compressed sub-files in the compressed file based on the target loading path.

[0179] In this embodiment, the decompression priority of the compressed sub-file reflects the degree to which the compressed sub-file affects the decompression progress during the decompression process.

[0180] In this embodiment, based on the loading order indicated by the target loading path, the decompression priority of multiple compressed sub-files in the compressed file can be obtained. Taking the target loading path as libA→libB→libC→libD as an example, libA has the first priority, libB has the second priority, libC has the third priority, and libD has the fourth priority.

[0181] S103-2: The compressed sub-file with the decompression priority in the first priority range is identified as the first sub-file to be decompressed, the compressed sub-file with the decompression priority in the second priority range is identified as the second sub-file to be decompressed, and the other files in the multiple compressed sub-files other than the first and second sub-files to be decompressed are identified as the third sub-files to be decompressed.

[0182] In this embodiment, the number and level of priorities in each priority range can be set according to actual needs. For example, when there are many compressed sub-files in the target file, multiple decompression priorities can be set in the priority range.

[0183] For example, the first priority range can be set to priority 1 to priority 3, and the compressed sub-files located at priority 1 to priority 3 are determined as the first sub-files to be decompressed; the second priority range can be set to priority 4 to priority 10, and the compressed sub-files located at priority 4 to priority 10 are determined as the second sub-files to be decompressed; while the compressed sub-files with a decompression priority of priority 10 or higher are determined as the third sub-files to be decompressed.

[0184] S103-3: Decompress the first sub-file to be decompressed. After the first sub-file to be decompressed is decompressed, decompress the second sub-file to be decompressed.

[0185] In this embodiment, when there are multiple first or second sub-files to be decompressed, multiple first or second sub-files to be decompressed can be decompressed in parallel to improve decompression efficiency.

[0186] In this embodiment, by prioritizing the decompression of the first sub-file to be decompressed, it can be ensured that the preceding files are decompressed first. The process of decompressing the first sub-file to be decompressed can be understood as the emergency decompression stage, which can usually be completed within 500ms. After the first sub-file to be decompressed is decompressed, the second sub-file to be decompressed, which is of lesser importance, can be understood as the fast decompression stage.

[0187] It should be noted that by splitting the first and second sub-files to be decompressed into two stages and decompressing them sequentially, the decompression efficiency can be effectively avoided by decompressing too many files at once.

[0188] S103-4: In response to an access request for a third sub-file to be decompressed, decompress the third sub-file to be decompressed.

[0189] It should be noted that the third sub-file to be decompressed represents a non-critical file of the target application. This third sub-file can be decompressed only when the target application accesses it. In other words, the process of decompressing the third sub-file can be understood as an on-demand decompression stage.

[0190] In this embodiment, by decompressing the compressed file in three stages (i.e., emergency decompression stage - fast decompression stage - on-demand decompression stage), it is possible to achieve reasonable and orderly decompression of multiple compressed sub-files, thereby improving decompression efficiency and shortening the startup time of the target application.

[0191] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of the application management device provided in the embodiments of this application. The application management device 200 includes:

[0192] The path acquisition module 201 is used to acquire the dynamic loading path and static loading path of the target application;

[0193] The path fusion module 202 is used to fuse static loading paths and dynamic loading paths to obtain the target loading path of the target application.

[0194] The file decompression module 203 is used to decompress the compressed file of the target application according to the target loading path in response to the target application's startup command.

[0195] In one embodiment, the application management device 200 further includes:

[0196] The information acquisition module is used to acquire the predicted usage probability of the target application, as well as the remaining storage space and device status of the target device.

[0197] The file compression module is used to compress the target file corresponding to the target application to obtain a compressed file when the predicted usage probability is less than the probability threshold, the remaining storage space is less than the storage space threshold, and the device status indicates that the target device is in an idle state.

[0198] In one embodiment, the application management device 200 further includes:

[0199] The first parameter determination module is used to obtain the geographic scene information corresponding to the location information of the target device, and determine the geographic matching degree between the target application and the geographic scene information.

[0200] The second parameter determination module is used to calculate the time decay value of the target application based on the unused time of the target application in the current statistical period.

[0201] The third parameter determination module is used to perform behavior transfer analysis on the user's usage habit information for the target application and obtain the behavior transfer probability of the target application.

[0202] The probability prediction module is used to determine the predicted usage probability based on geographic matching degree, time decay value and / or behavior transfer probability.

[0203] In one embodiment, the application management device 200 further includes:

[0204] The path acquisition module is used to obtain the directed acyclic graph of the target application. The directed acyclic graph includes multiple loading paths, with multiple sub-files in the target file corresponding to the target application as nodes and the loading order relationship of the multiple sub-files as edges.

[0205] The path determination module is used to determine the dynamic loading path from multiple loading paths in a directed acyclic graph based on the target parameters of multiple sub-files.

[0206] In one embodiment, the target parameters include the loading time of the sub-file and the number of times it is depended upon; the path determination module includes:

[0207] The path weight determination submodule is used to perform a weighted calculation on the loading time and the number of times each sub-file in the loading path is depended on for any loading path, so as to obtain the weighted path corresponding to the loading path.

[0208] The path determination submodule is used to determine the longest weighted path among multiple weighted paths as the dynamically loaded path.

[0209] In one embodiment, the static loading path includes the static weights of multiple sub-files in the target file corresponding to the target application, and the dynamic loading path includes the dynamic weights of multiple sub-files; the path fusion module 202 includes:

[0210] The weight fusion submodule is used to perform fusion calculation on the dynamic weight and static weight of each subfile to obtain the fusion weight corresponding to each subfile.

[0211] The load path generation submodule is used to obtain the target load path of the target application based on the fusion weights of multiple sub-files and the file dependencies corresponding to the dynamic load path.

[0212] In one embodiment, the file decompression module 203 includes:

[0213] The priority determination submodule is used to determine the decompression priority of multiple compressed sub-files in a compressed file based on the target loading path;

[0214] The file partitioning submodule is used to determine the compressed subfile with the decompression priority in the first priority range as the first subfile to be decompressed, the compressed subfile with the decompression priority in the second priority range as the second subfile to be decompressed, and the other files in the multiple compressed subfiles other than the first and second subfiles to be decompressed as the third subfile to be decompressed.

[0215] The first decompression submodule is used to decompress the first sub-file to be decompressed, and after the first sub-file to be decompressed is decompressed, it decompresses the second sub-file to be decompressed;

[0216] The second decompression submodule is used to decompress the third subfile in response to an access request for the third subfile to be decompressed.

[0217] By adopting the technical solution of this application embodiment, the static loading path and the dynamic loading path are integrated, so that the optimized target loading path can better adapt to the actual use scenario of the target application, and can decompress the compressed file of the target application more efficiently and reasonably, thereby effectively reducing the startup delay of the target application and improving the user experience.

[0218] Specific limitations regarding the application management device 200 can be found in the limitations of the application management method described above, and will not be repeated here. Each module in the aforementioned application management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0219] In addition, this application also provides an electronic device, such as Figure 3 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically:

[0220] The electronic device may include components such as a processor 301 with one or more processing cores and a memory 302 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 3 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. Wherein:

[0221] The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0222] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and data processing by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0223] In one embodiment, the electronic device further includes a power supply 303 for supplying power to the various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0224] In one embodiment, the electronic device may further include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0225] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302, thereby implementing the steps in any of the application management methods provided in the embodiments of this application.

[0226] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0227] In one embodiment, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0228] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of this application.

[0229] In some embodiments, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

[0230] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0231] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0232] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps in any of the application management methods provided in this application.

[0233] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0234] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0235] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the application management methods provided in this application, the beneficial effects that any of the application management methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0236] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0237] The above provides a detailed description of an application management method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. An application management method, characterized in that, The method includes: Obtain the dynamic loading path and static loading path of the target application; The static loading path and the dynamic loading path are merged to obtain the target loading path of the target application; In response to the launch command of the target application, the compressed file of the target application is decompressed according to the target loading path.

2. The application management method according to claim 1, characterized in that, The method further includes: Obtain the predicted usage probability of the target application, as well as the remaining storage space and device status of the target device; When the predicted usage probability is less than a probability threshold, the remaining storage space is less than a storage space threshold, and the device status indicates that the target device is in an idle state, the target file corresponding to the target application is compressed to obtain the compressed file.

3. The application management method according to claim 2, characterized in that, The predicted probability of use is obtained based on the following method: Obtain the geographic scene information corresponding to the location information of the target device, and determine the geographic matching degree between the target application and the geographic scene information; Calculate the time decay value of the target application based on the unused time of the target application in the current statistical period; By performing behavioral transfer analysis on user usage habits for the target application, the behavioral transfer probability of the target application can be obtained. The predicted usage probability is determined based on the geographic matching degree, the time decay value, and / or the behavior transfer probability.

4. The application management method according to claim 1, characterized in that, The dynamic loading path is determined in the following way: Obtain the directed acyclic graph of the target application; the directed acyclic graph includes multiple loading paths, the loading paths are nodes of multiple sub-files in the target file corresponding to the target application, and the loading order relationship of the multiple sub-files is the edge; The dynamic loading path is determined from the multiple loading paths in the directed acyclic graph based on the target parameters of the multiple sub-files.

5. The application management method according to claim 4, characterized in that, The target parameters include the loading time and the number of times the sub-file is depended upon; The step of determining the dynamic loading path from multiple loading paths in the directed acyclic graph based on the target parameters of multiple sub-files includes: For any of the loading paths, the loading time and the number of times each of the sub-files in the loading path is dependent are weighted to obtain the weighted path corresponding to the loading path; The longest weighted path among the multiple weighted paths is determined as the dynamic loading path.

6. The application management method according to claim 1, characterized in that, The static loading path includes the static weights of multiple sub-files in the target file corresponding to the target application, and the dynamic loading path includes the dynamic weights of multiple sub-files. The step of fusing the static loading path and the dynamic loading path to obtain the target loading path of the target application includes: The dynamic weight and static weight of each sub-file are fused together to obtain the fused weight corresponding to each sub-file. Based on the fusion weights corresponding to each of the multiple sub-files and the file dependencies corresponding to the dynamic loading path, the target loading path of the target application is obtained.

7. The application management method according to claim 1, characterized in that, The step of decompressing the compressed file according to the target loading path includes: Based on the target loading path, the decompression priority of multiple compressed sub-files in the compressed file is determined; The compressed sub-file whose decompression priority is in the first priority range is determined as the first sub-file to be decompressed; the compressed sub-file whose decompression priority is in the second priority range is determined as the second sub-file to be decompressed; and the other files in the multiple compressed sub-files other than the first and second sub-files to be decompressed are determined as the third sub-files to be decompressed. The first sub-file to be decompressed is decompressed. After the first sub-file to be decompressed is decompressed, the second sub-file to be decompressed is decompressed. In response to the access request for the third sub-file to be decompressed, the third sub-file to be decompressed is decompressed.

8. An application management device, characterized in that, include: The path acquisition module is used to obtain the dynamic loading path and static loading path of the target application; The path fusion module is used to fuse the static loading path and the dynamic loading path to obtain the target loading path of the target application; The file decompression module is used to decompress the compressed file of the target application in response to the launch command of the target application, according to the target loading path.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the application management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the application management method as described in any one of claims 1 to 7.

Images