Method, device, terminal equipment and readable storage medium for controlling application startup

Abstract

The application discloses a control method and device for application starting, a terminal device and a readable storage medium. The method comprises the following steps: obtaining a starting request of a target application; in response to the starting request, obtaining context data of the starting request, current system state data and historical starting data of the target application; determining a target probability according to the context data, the current system state data and the historical starting data, wherein the target probability is used to represent a starting probability of the target application; and controlling the starting of the target application according to the target probability. The method can control the starting of the target application in combination with the context data related to the starting request, the current system state data and the historical starting data of the target application, thereby avoiding unnecessary background wake-up behavior, reducing the resource occupation caused by invalid application starting, reducing the overall power consumption of the system and improving the running efficiency and system fluency of the mobile terminal.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a control method, apparatus, terminal device, and readable storage medium for application startup. Background Technology

[0002] In current mobile operating systems, automatic background app launches and mutual app wake-ups have become common operating modes. While these methods enhance app connectivity, they also introduce numerous unnecessary launch behaviors, especially in scenarios where users don't actively trigger them. Some apps frequently initiate launch requests based on their own business needs, leading to frequent background app restarts. During this process, the mobile terminal experiences increased CPU scheduling pressure, continuously rising memory usage, and frequent network resource usage, resulting in increased battery consumption and system response latency. Summary of the Invention

[0003] This application provides a method, apparatus, terminal device, and readable storage medium for controlling application startup. It can control the startup of a target application by combining context data related to the startup request, current system status data, and historical startup data of the target application, thereby avoiding unnecessary background wake-up behavior, reducing the resource occupation of invalid application startups, reducing overall system power consumption, and improving the operating efficiency and system smoothness of the mobile terminal.

[0004] The technical solution adopted by this invention to solve the problem is as follows: On the one hand, this application provides a method for controlling application startup, including: Obtain the startup request of the target application; In response to a startup request, obtain the startup request context data, current system state data, and historical startup data of the target application; The target probability is determined based on context data, current system status data, and historical startup data. The target probability is used to characterize the startup probability of the target application. The activation of the target application is controlled based on the target probability.

[0005] In some implementations of this application, the target probability is determined based on context data, current system state data, and historical startup data, including: Determine startup characteristics based on contextual data, current system status data, and historical startup data; The feature input will be activated to pre-train a prediction model, which will then output the target probability.

[0006] In some embodiments of this application, startup characteristics are generated based on context data, current system state data, and historical startup data, including: Statistical characteristics were obtained by analyzing historical startup data. Encode the context data to obtain context features; Encode the current system state data to obtain system state characteristics; Startup characteristics are generated based on statistical features, contextual features, and system state features.

[0007] In some embodiments of this application, the launch of the target application is controlled based on the target probability, including: Determine the initiation strategy based on the target probability; The startup of the target application is controlled according to the startup policy.

[0008] In some embodiments of this application, the initiation strategy is determined based on the target probability, including: When the target probability is greater than or equal to the first probability threshold, the activation strategy is determined to be the first strategy, where the first strategy represents the immediate activation of the target application; When the target probability is less than the second probability threshold, the launch strategy is determined to be the second strategy, where the second strategy represents prohibiting the launch of the target application; When the target probability is greater than or equal to the second probability threshold and less than the first probability threshold, the startup strategy is determined based on the current system state data.

[0009] In some embodiments of this application, the current system status data includes memory status data and CPU status data. Based on the current system status data, a startup strategy is determined, including: When the memory status data is greater than the memory threshold and the CPU status data is less than the CPU threshold, the startup strategy is determined to be the first strategy. When the memory state data is less than or equal to the memory threshold, or the CPU state data is greater than or equal to the CPU threshold, the startup strategy is determined to be the third strategy, where the third strategy represents delaying the startup of the target application.

[0010] In some embodiments of this application, after controlling the launch of the target application based on the target probability, the following are included: After the target application is launched, a conditioning sample is generated based on the user's operational behavior data of the target application; The prediction model is trained based on the adjusted samples; Based on user behavior data related to the target application, adjustment samples are generated, including: When the user's action behavior data on the target application is the first action data, an adjustment sample is generated based on the launch feature and positive sample label; the first action data represents the user switching the target application to the foreground in the first time period after the target application is launched; When the user's operational behavior data on the target application is the second behavior data, an adjustment sample is generated based on the startup characteristics and negative sample labels; the second behavior data represents that the user did not switch the target application to the foreground in the first period after the target application was launched.

[0011] Secondly, embodiments of the present invention also provide an application launch control device, comprising: The first acquisition module is used to acquire the startup request of the target application; The second acquisition module is used to acquire the context data of the startup request, the current system status data, and the historical startup data of the target application in response to the startup request. The determination module is used to determine the target probability based on context data, current system state data, and historical startup data, where the target probability is used to characterize the startup probability of the target application. The control module is used to control the launch of the target application based on the target probability.

[0012] Thirdly, this application also provides a terminal device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the application initiation control method of any of the first aspects.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to execute the steps of the application startup control method of any of the first aspects.

[0014] The beneficial effects of this invention are as follows: When a startup request of a target application is received, context data, current system status data, and historical startup data of the target application related to the startup request are obtained, and the startup probability of the target application is comprehensively judged based on the above information, so as to control the startup of the target application. This allows the system to identify potential redundant or unreasonable startup requests before startup, thereby avoiding unnecessary background wake-up behavior, reducing the occupation of CPU, memory, and network resources by invalid application startup, reducing the overall power consumption of the system, and improving the operating efficiency and system smoothness of the mobile terminal. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of a scenario for the application startup control system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating one embodiment of the application startup control method provided in this invention. Figure 3 This is a flowchart illustrating a specific embodiment of the control application startup provided in this invention. Figure 4 This is a schematic block diagram of the application launch control device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an embodiment of the terminal device provided in this invention. Detailed Implementation

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

[0018] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of the stated features.

[0019] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0020] It should be noted that since the method in this application embodiment is executed in a terminal device, the processing objects of each terminal device exist in the form of data or information, such as time, which is essentially time information. It can be understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the terminal device can process them. Specific details will not be elaborated here.

[0021] This application provides a control method, apparatus, terminal device, and readable storage medium for application startup, which will be described in detail below.

[0022] Please see Figure 1 , Figure 1 This is a schematic diagram of a scenario for an application launch control system provided in an embodiment of this application. The application launch control system may include a terminal device 100, which integrates an application launch control device, such as... Figure 1 Terminal devices in the process.

[0023] In this embodiment, the terminal device 100 is mainly used to obtain a startup request for a target application; in response to the startup request, it obtains context data of the startup request, current system state data, and historical startup data of the target application; based on the context data, current system state data, and historical startup data, it determines a target probability, wherein the target probability is used to characterize the startup probability of the target application; based on the target probability, it controls the startup of the target application. The startup of the target application can be controlled by combining the context data related to the startup request, the current system state data, and the historical startup data of the target application, thereby avoiding unnecessary background wake-up behavior, reducing the resource occupation of invalid application startups, reducing the overall power consumption of the system, and improving the operating efficiency and system smoothness of the mobile terminal.

[0024] In this embodiment, the terminal device 100 can be an independent server, a server network, or a server cluster. For example, the terminal device 100 described in this embodiment includes, but is not limited to, a computer, a network host, a single network server, a set of multiple network servers, or a cloud server composed of multiple servers. The cloud server is composed of a large number of computers or network servers based on cloud computing.

[0025] It is understood that the terminal device 100 used in the embodiments of this application can be a device that includes both receiving and transmitting hardware, that is, a device having receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. Such a device may include: cellular or other communication devices having a single-line display, a multi-line display, or a cellular or other communication device without a multi-line display. Specifically, the terminal device 100 may be a desktop terminal or a mobile terminal, and the terminal device 100 may also be one of a mobile phone, tablet computer, laptop computer, etc.

[0026] Those skilled in the art will understand that Figure 1 The application environment shown is merely one application scenario of the solution in this application and does not constitute a limitation on the application scenario of the solution in this application. Other application environments may include those that are more specific to this application. Figure 1 The number of more or fewer terminal devices shown, for example Figure 1 Only one terminal device is shown in the image. It is understood that the control system launched by this application may also include one or more other services, which are not specified here.

[0027] In addition, such as Figure 1 As shown, the control system launched by this application may also include a memory 200 for storing data, such as context data, current system status data, historical startup data, etc.

[0028] It should be noted that, Figure 1 The schematic diagram of the application launch control system shown is merely an example. The application launch control system and scenario described in this application embodiment are for the purpose of more clearly illustrating the technical solutions of this application embodiment and do not constitute a limitation on the technical solutions provided in this application embodiment. As those skilled in the art will know, with the evolution of application launch control systems and the emergence of new business scenarios, the technical solutions provided in this application embodiment are also applicable to similar technical problems.

[0029] First, this application provides an application startup control method. The execution subject of this application startup control method is an application startup control device, which is applied to a terminal device. The application startup control method includes: obtaining a startup request of a target application; in response to the startup request, obtaining context data of the startup request, current system state data, and historical startup data of the target application; determining a target probability based on the context data, current system state data, and historical startup data, wherein the target probability is used to characterize the startup probability of the target application; and controlling the startup of the target application based on the target probability.

[0030] like Figure 2 The diagram shown is a flowchart of an embodiment of the application startup control method in this application. The application startup control method may include the following steps S201 to S204, as detailed below: Step S201: Obtain the startup request of the target application.

[0031] In one specific embodiment, a startup request refers to a request signal initiated by any entity in the operating system of a smart mobile terminal, intending to put an application or its components into a running state. This request can originate from user operation or be automatically triggered by the system or other applications. In actual operating systems, besides users directly launching applications by clicking their icons, there are also widespread non-user-triggered startup scenarios. For example, an application may automatically start after booting to perform initialization tasks, a social application may wake up its own process to update content after receiving a push notification, or a map application may be called by a food delivery application to complete location services. These are typical cases of application self-starting or inter-application related startup. In addition, there is a special startup scenario triggered by the user, such as a user clicking an application to trigger file download or data synchronization. However, this operation itself does not need to immediately display the interface. Instead, it is desirable for the application to perform the task in the background first, and then present the foreground interface when the task is completed or when the user switches to the application later.

[0032] In one specific embodiment, hook functions can be set in key processes of the system framework layer. For example, when methods such as startActivity(), startService(), and sendBroadcast() of ActivityManagerService are called, the startup request can be intercepted and recorded, thereby capturing the original request information for application startup. After obtaining the request, its source and intent can be preliminarily judged. For startup requests that are clearly triggered directly by the user and need to be displayed as the foreground interface immediately, they can be allowed to continue executing the original startup process to ensure user experience. For requests that are not triggered by the user, or for scenarios that are triggered by the user but are suitable for background execution, the subsequent step S202 is used for further analysis.

[0033] By setting up this step, different types of requests are identified and routed at the source of application startup, and startup behaviors that were originally treated indiscriminately in the system are classified and processed. This provides a foundation for subsequent fine-grained control, and can intercept potentially redundant background startup behaviors without affecting the user's active operation experience.

[0034] Step S202: In response to the startup request, obtain the context data of the startup request, the current system status data, and the historical startup data of the target application.

[0035] In one specific embodiment, in response to a launch request, multi-dimensional data related to the launch request is further acquired, including context data, current system state data, and historical launch data of the target application. Context data refers to information describing the environment and triggering conditions of this launch request, specifically including: the current time, the name of the application initiating the launch request and the name of the target application being launched, the specific component name initiating the request (such as Activity or Service), the Action string in the Intent, the Category list, and the data URI carried. The latter three types of data further describe the specific purpose and data content of the launch. Current system state data characterizes the device's operating load when the launch request is initiated, specifically including: total CPU utilization, available memory, battery percentage, and device temperature status. Historical launch data originates from previously recorded user behavior data related to the target application, specifically including: when users typically launch the application, the distribution of usage time, etc., reflecting users' long-term usage preferences and patterns.

[0036] Step S203: Determine the target probability based on context data, current system status data, and historical startup data, whereby the target probability is used to characterize the startup probability of the target application.

[0037] In one specific embodiment, the target probability can be used to characterize the rationality or necessity of launching a target application to the user in the foreground under the current context. Contextual data can reveal the direct triggering reason for this launch request; for example, if an instant messaging application is woken up by receiving a message, it has high rationality within a specific time period. Current system state data provides resource constraints; for example, when CPU utilization is high or battery power is low, even if a launch request exists, it may not be suitable for immediate execution. Historical launch data reflects the user's long-term behavioral patterns; for example, if a user usually uses a video application at night, its launch probability should be relatively high during that time period. By comprehensively analyzing these three types of data, a more refined probability assessment of the current launch request can be performed, so that the obtained target probability not only considers "whether it is triggered," but also "whether it is appropriate" and "whether it conforms to user habits."

[0038] This step transforms the original simple judgment based on rules or thresholds into a probability assessment based on the fusion of multiple factors. It avoids the one-sidedness caused by relying on a single factor for judgment, and uses a data-driven approach to characterize user needs and system status, thereby improving the accuracy and flexibility of the judgment. This enables the system to have the ability to make forward-looking assessments of startup behavior and reduce misjudgments and omissions.

[0039] Step S204: Control the activation of the target application based on the target probability.

[0040] In one specific embodiment, a corresponding processing strategy can be adopted for the startup request based on the probability result. For example, when the target probability is high, the startup request is considered to meet the user's current needs or system conditions, and the startup process is allowed to continue. When the target probability is low, the startup can be restricted or delayed to avoid unnecessary resource consumption.

[0041] This step does not limit the specific implementation of the control strategy. Its key is to use the target probability as the basis for decision-making to achieve differentiated processing of application startup behavior. Through this step, the aforementioned analysis results can be transformed into actual system behavior, effectively reducing low-value or redundant background startup behaviors, thereby reducing the ineffective consumption of CPU, memory, and battery resources, while avoiding system lag caused by frequent wake-ups, ultimately improving the overall operating efficiency and user experience of mobile terminals.

[0042] In one specific implementation, the target probability is determined based on context data, current system state data, and historical startup data, including: determining startup features based on context data, current system state data, and historical startup data; inputting the startup features into a pre-trained prediction model, and having the prediction model output the target probability.

[0043] In one specific embodiment, startup features can be understood as the result of processing and expressing context data, current system state data, and historical startup data; essentially, it is a set of structured information that can characterize the current startup request status. In a concrete implementation, context data, system state data, and historical startup data can be cleaned, encoded, and fused to form a vector-like data structure composed of multiple numerical or coded elements. Each dimension corresponds to a specific feature. For example, time information can be converted into numerical or periodic coded features, application names can be mapped to discrete features through identifiers, and system resource status can be directly represented using continuous numerical values. In this way, data that was originally diverse in type and inconsistent in structure can be uniformly transformed into an input form that the model can process, thereby fully expressing the multidimensional features of a startup request.

[0044] After determining the feature vectors, they are input into a pre-trained prediction model. Before system deployment, sample data can be used to learn the model parameters, enabling them to capture the mapping relationship between input features and output results. The prediction model is an algorithmic model that can automatically output prediction results based on input features. In this scheme, the prediction model outputs a scalar probability value P, satisfying 0 ≤ P ≤ 1. This probability value represents the likelihood that the background initiation behavior will be recognized or actually needed by the user in the short term under the current circumstances. Because the input data in this scheme is mainly structured "tabular features," that is, a feature set composed of multiple types of data (numerical, categorical, etc.), and Gradient Boosting Decision Tree (GBDT) has good performance in handling such heterogeneous features, while having relatively low requirements for feature preprocessing, it is suitable for running on resource-constrained mobile terminals. Therefore, a GBDT-like model can be used as the basic structure of the prediction module. The prediction model file can be pre-installed in the system partition in the form of ".model" or ".json", thereby avoiding the delay and uncertainty caused by loading external resources at runtime. This also helps to ensure the stability and real-time performance of system-level functions.

[0045] In one specific implementation, startup features are generated based on context data, current system state data, and historical startup data. This includes: performing statistics on historical startup data to obtain statistical features; encoding context data to obtain context features; encoding current system state data to obtain system state features; and generating startup features based on the statistical features, context features, and system state features.

[0046] In one specific embodiment, historical startup data can be aggregated and quantified to obtain statistical features. For example, the number of times the target application was triggered to start within a certain period of time (e.g., 1 hour), the number and frequency of startup requests initiated by a certain initiating application, etc., can be statistically obtained, reflecting the intensity or trend of the corresponding behavior. Contextual features can also be obtained by encoding contextual data related to startup requests. For example, time periods, days of the week, initiating application identifiers, or action types in Intents can be encoded, and then the information can be converted into corresponding numbers or characters. System status features can be obtained by encoding current device operating status data. Specifically, for time-related features, the number of hours in a day (0-23) or the number of days in a week (0-6) can be "normalized," that is, mapped to the [0,1] interval through linear transformation, making data of different dimensions comparable. For categorical data, such as application package names or Intent Action strings, one-hot encoding or hash encoding can be used for representation.

[0047] After processing various types of data, statistical features, contextual features, and system state features are combined to generate a fixed-length feature vector. For example, a 20-dimensional vector can be constructed, where some dimensions represent time information (such as normalized time periods and days of the week), some dimensions represent system resource status (such as CPU, memory, and battery power), other dimensions represent historical behavior statistics (such as the number of launches in the past hour), and several dimensions are used to represent the encoded results of discrete events (such as Intent actions or application identifiers). In this way, data from different sources and of different types are uniformly integrated into a fixed-structure, semantically clear input representation, which can then be directly used as input to the prediction model.

[0048] By employing statistical, coding, and normalization techniques, the raw data is transformed into standardized feature vectors. This not only preserves the core features of various information types but also eliminates the impact of differences in units and data formats on the model, enabling the predictive model to more effectively learn the relationships between different features. Simultaneously, the use of a fixed-length vector structure ensures the consistency and stability of the model input, facilitating efficient inference on terminal devices.

[0049] In one specific implementation, the launch of the target application is controlled according to the target probability, including: determining a launch strategy based on the target probability; and controlling the launch of the target application according to the launch strategy.

[0050] In one specific embodiment, a startup strategy is a control rule or processing method formulated based on a target probability, used to guide the system on how to respond to the current startup request. In other words, the startup strategy is the bridge connecting the "prediction result" and "system execution," transforming abstract probability judgments into concrete operational instructions. In a specific implementation, the system can classify and judge the current startup request based on the magnitude of the target probability. For example, when the target probability is high, it indicates that the startup behavior has high rationality and necessity in the current context and system state, and the corresponding startup strategy may be to allow the target application to continue executing the startup process; when the target probability is low, it indicates that the startup behavior is less likely to be needed by the user in the short term, and the corresponding startup strategy may tend to restrict the execution of the startup request. The system can intervene in the application startup process before the startup behavior actually occurs, based on the determined startup strategy. This process does not change the way the startup request itself is generated, but rather adjusts its execution path at the system level, thereby achieving management of application behavior.

[0051] In one specific implementation, determining the startup strategy based on the target probability includes: when the target probability is greater than or equal to a first probability threshold, determining the startup strategy as a first strategy, wherein the first strategy represents immediately starting the target application; when the target probability is less than a second probability threshold, determining the startup strategy as a second strategy, wherein the second strategy represents prohibiting the startup of the target application; and when the target probability is greater than or equal to the second probability threshold and less than the first probability threshold, determining the startup strategy based on the current system state data.

[0052] In one specific embodiment, the probability space can be divided into three intervals—high, medium, and low—using a first probability threshold and a second probability threshold, so that different strategy categories can be adopted to process the startup request respectively, wherein the first probability threshold is greater than the second probability threshold.

[0053] Specifically, when the target probability is greater than or equal to the first probability threshold, it indicates that the launch request has high rationality and necessity in the current context. Therefore, the launch strategy is determined to be the first strategy, i.e., immediately launch the target application. Immediate launch can be understood as allowing the application to enter the running state according to the normal process without any additional restrictions or delays, thus ensuring that potential user needs can be responded to in a timely manner. When the target probability is less than the second probability threshold, it indicates that the launch request is less likely to be needed by the user under the current conditions. Therefore, the launch strategy is determined to be the second strategy, i.e., prohibit the launch of the target application. Prohibiting launch means intercepting the launch request at the system level, preventing it from continuing to execute, thereby avoiding unnecessary resource consumption. It should be noted that prohibiting launch is limited to the operation on this launch request, not to continuously prohibit the launch of the target application or the initiator from launching other applications in the future. For the intermediate range between the two thresholds, i.e., when the target probability is greater than or equal to the second probability threshold but less than the first probability threshold, the current system state data is introduced as a further decision-making basis. Within this range, by combining the system state for judgment, a more flexible strategy selection can be achieved. For example, when system resources are sufficient, even if the probability is at a moderate level, the restrictions can be appropriately relaxed to allow startup; while when resources are scarce, the startup request can be suppressed.

[0054] In one specific implementation, the current system state data includes memory state data and CPU state data. Based on the current system state data, a startup strategy is determined, including: when the memory state data is greater than the memory threshold and the CPU state data is less than the CPU threshold, the startup strategy is determined to be the first strategy; when the memory state data is less than or equal to the memory threshold, or the CPU state data is greater than or equal to the CPU threshold, the startup strategy is determined to be the third strategy, wherein the third strategy represents delaying the startup of the target application.

[0055] In one specific embodiment, the current system status data may include memory status data and CPU status data. Memory status data is used to characterize the amount of available memory in the current system, such as the proportion of available memory to total memory or the remaining memory capacity; CPU status data is used to characterize the current load level of the processor, such as CPU utilization. Memory threshold and CPU threshold are pre-set threshold values ​​for the above two indicators, used to distinguish whether resources are in a sufficient or strained state. Specifically, the memory threshold may be 30%, and the CPU threshold may be 70%.

[0056] Specifically, when memory status data is greater than the memory threshold and CPU status data is less than the CPU threshold, the system is considered to be in a relatively resource-sufficient state, meaning there is ample memory and low processor load. Even if the target probability is in the middle range, the startup strategy can be set to the first strategy, allowing the target application to start. However, when memory status data is less than or equal to the memory threshold, or CPU status data is greater than or equal to the CPU threshold, it indicates that the system is under strain in at least one critical resource dimension. In this case, the startup strategy is set to the third strategy, namely, delayed startup of the target application. Delayed startup means not immediately executing the startup request, but postponing it to a later point in time. This time can be dynamically set based on system load, for example, by reassessing the system status after a short period and deciding whether to execute the startup, thus avoiding introducing additional load when resources are strained. Delayed startup emphasizes adjusting the startup timing, rather than completely prohibiting startup. It differs from "prohibiting startup" in that this strategy still retains the possibility of execution, only postponing the execution time.

[0057] This embodiment uses a combined assessment of two core resources, memory and CPU, to delay application startup when either resource is strained, effectively covering various performance bottleneck scenarios. For example, when CPU utilization is high, even if memory is sufficient, launching new applications may slow down system response; similarly, when memory is insufficient, even with low CPU load, frequent memory reclamation or process killing may occur. When both memory and CPU load are low, it indicates insufficient system resources, necessitating a delay in application startup. Furthermore, different delay times can be set for the three scenarios (insufficient memory and high CPU load, sufficient memory and high CPU load, and insufficient memory and low CPU load). For instance, a longer delay time can be set when both indicate resource insufficiency, while a shorter delay time can be set when only one indicates resource insufficiency.

[0058] This embodiment enables flexible control over application startup behavior while ensuring system stability. On one hand, allowing startup when resources are sufficient avoids the degradation of user experience caused by excessive restrictions; on the other hand, employing a delay strategy when resources are scarce effectively alleviates instantaneous load pressure and reduces stuttering, frame drops, or increased power consumption caused by resource contention. Furthermore, since delayed startup is not a permanent block but rather reserves space for subsequent execution, potential user needs can still be met after the system load recovers. Therefore, this solution achieves a balance between performance and user experience, further improving the smoothness of mobile terminal operation and resource utilization efficiency.

[0059] In one specific implementation, after controlling the launch of the target application based on the target probability, the process includes: after the target application is launched, generating adjustment samples based on user behavior data of the target application; training the prediction model based on the adjustment samples; further, generating adjustment samples based on user behavior data of the target application includes: when the user behavior data of the target application is first behavior data, generating adjustment samples based on launch features and positive sample labels; the first behavior data indicates that the user switches the target application to the foreground within the first time period after the target application is launched; when the user behavior data of the target application is second behavior data, generating adjustment samples based on launch features and negative sample labels; the second behavior data indicates that the user does not switch the target application to the foreground within the first time period after the target application is launched.

[0060] In one specific embodiment, existing predictive models can be continuously optimized by monitoring user actions after application launch. User action data for the target application refers to records of user interactions with the application after it is allowed to launch, such as whether the application is switched from the background to the foreground or whether it is actually used. Adjustment samples are data units used to fine-tune the model's parameters during model usage. They typically consist of features and labels. The features, i.e., the aforementioned generated launch features, describe the environment and conditions of the launch request, while the labels characterize whether the result of the launch behavior meets the user's needs. Positive and negative sample labels correspond to launch behavior results considered reasonable and unreasonable, respectively.

[0061] Specifically, whether a user actually uses the application can be used as a key criterion for judging the rationality of a launch. For example, after a system-allowed launch occurs, if the user actively switches the target application to the foreground and uses it within a preset first time period (e.g., 5 minutes), the launch can be considered to meet the user's needs, and this sample is marked as a positive sample, with the corresponding label indicating that the target probability should approach 1. Conversely, if the target application continues to run in the background for more than this time window after launch, and the user does not perform any operation on it, and it is eventually even cleaned up and reclaimed by the system, then the launch has not generated any practical value and should be marked as a negative sample, with the corresponding label indicating that the target probability should approach 0. In this process, "first behavioral data" can be understood as the data performance of the user's positive usage behavior of the application in a short period of time, while "second behavioral data" corresponds to the situation where the user does not use it effectively. By associating the above behavioral results with the launch characteristics at the time, a set of adjustment samples with clear supervisory signals can be constructed.

[0062] Furthermore, the generated adjustment samples are used to retrain or fine-tune the prediction model, enabling it to continuously adapt to users' personalized usage habits. That is, based on an existing model, the model parameters are slightly updated using newly collected data, rather than being trained from scratch, thereby improving the model's adaptability while maintaining efficiency. Specifically, the prediction model in the mobile smart device can be slightly updated during idle time (while charging overnight).

[0063] As a specific embodiment, such as Figure 3 As shown, when a startup request is initiated by an application in the operating system, the request is first captured by a hook function pre-set in the system framework layer and intercepted at the application startup process entry point. If it is determined that the startup request is not triggered by the user, the startup will not be executed immediately. Instead, multi-source data collection will be performed to obtain context data related to the request (such as trigger source, Intent information, etc.), current system status data (such as CPU, memory, power, etc.), and historical behavior data (such as the user's past usage of the application).

[0064] After obtaining the raw data, the feature engineering phase begins. Data from different sources and with different structures undergoes unified processing, including normalization, encoding, and feature combination, ultimately generating a fixed-length feature vector to characterize the overall feature state of this launch request. Subsequently, this feature vector is input into a pre-trained prediction model for inference calculations. The model outputs a target probability, representing the likelihood that the user needs or approves of this launch behavior in the current context.

[0065] Based on this probability result, a corresponding startup strategy is further generated through a dynamic strategy mechanism. This strategy is not fixed, but is determined comprehensively based on the dynamic strategy table, probability range, and the current resource status of the system, thereby achieving flexible decision-making. Then, in the decision execution phase, the system actually controls the startup request according to the generated strategy. Possible execution results include directly allowing the application to start, delaying the startup, or directly blocking the startup, thereby avoiding unnecessary resource consumption. As shown in Table 1, if the target probability is less than 0.4, it means that the possibility of the user agreeing to the startup is small, so the application startup is prohibited regardless of whether system resources are sufficient; if the target probability is greater than or equal to 0.85, it means that the possibility of the user agreeing to the startup is large, so the application starts immediately regardless of whether system resources are sufficient; if the target probability is between 0.4 and 0.85, the startup decision is determined comprehensively based on system resources. Specifically, when memory usage is greater than 30% and CPU load is less than 70%, system resources are considered sufficient, and the application can be started; if either memory or CPU load indicates insufficient system resources, the application startup is delayed.

[0066] Table 1. Dynamic Strategy Table

[0067] After completing the control process, the system can continue to record and analyze subsequent user behavior. For example, after an application is allowed to launch, the system monitors whether the user switches it to the foreground and actually uses it within a certain period, thus determining whether the launch was "effective." Based on these feedback behaviors, the system generates corresponding adjustment samples, i.e., positive or negative samples, to reflect the reasonableness of the prediction. Finally, when the device is idle, these samples are used to fine-tune and update the prediction model, continuously optimizing the model parameters to better adapt to the user's personalized usage habits.

[0068] To better implement the application startup control method in the embodiments of this application, based on the application startup control method, the embodiments of this application also provide an application startup control device, such as... Figure 4 As shown, the application startup control device 400 includes: The first acquisition module 410 is used to acquire the startup request of the target application; The second acquisition module 420 is used to acquire the context data of the startup request, the current system status data, and the historical startup data of the target application in response to the startup request. The determination module 430 is used to determine the target probability based on context data, current system state data and historical startup data, wherein the target probability is used to characterize the startup probability of the target application; The control module 440 is used to control the launch of the target application based on the target probability.

[0069] In this embodiment, when a startup request for a target application is received, context data, current system status data, and historical startup data of the target application related to the startup request are obtained. Based on the above information, a comprehensive judgment is made on the startup probability of the target application to control the startup of the target application. This allows the system to identify potential redundant or unreasonable startup requests before startup, thereby avoiding unnecessary background wake-up behavior, reducing the occupation of CPU, memory, and network resources by invalid application startups, reducing the overall power consumption of the system, and improving the operating efficiency and system smoothness of the mobile terminal.

[0070] In some embodiments of this application, the determining module 430 determines the target probability based on context data, current system state data, and historical startup data, including: Determine startup characteristics based on contextual data, current system status data, and historical startup data; The feature input will be activated to pre-train a prediction model, which will then output the target probability.

[0071] In some embodiments of this application, the determining module 430 generates startup features based on context data, current system state data, and historical startup data, including: Statistical characteristics were obtained by analyzing historical startup data. Encode the context data to obtain context features; Encode the current system state data to obtain system state characteristics; Startup characteristics are generated based on statistical features, contextual features, and system state features.

[0072] In some embodiments of this application, the control module 440 controls the launch of the target application based on the target probability, including: Determine the initiation strategy based on the target probability; The startup of the target application is controlled according to the startup policy.

[0073] In some embodiments of this application, the control module 440 determines a launch strategy based on the target probability, including: When the target probability is greater than or equal to the first probability threshold, the activation strategy is determined to be the first strategy, where the first strategy represents the immediate activation of the target application; When the target probability is less than the second probability threshold, the launch strategy is determined to be the second strategy, where the second strategy represents prohibiting the launch of the target application; When the target probability is greater than or equal to the second probability threshold and less than the first probability threshold, the startup strategy is determined based on the current system state data.

[0074] In some embodiments of this application, the current system status data includes memory status data and CPU status data. The control module 440 determines a startup strategy based on the current system status data, including: When the memory status data is greater than the memory threshold and the CPU status data is less than the CPU threshold, the startup strategy is determined to be the first strategy. When the memory state data is less than or equal to the memory threshold, or the CPU state data is greater than or equal to the CPU threshold, the startup strategy is determined to be the third strategy, where the third strategy represents delaying the startup of the target application.

[0075] In some embodiments of this application, after the control module 440 controls the launch of the target application based on the target probability, it includes: After the target application is launched, a conditioning sample is generated based on the user's operational behavior data of the target application; The prediction model is trained based on the adjusted samples; Based on user behavior data related to the target application, adjustment samples are generated, including: When the user's action behavior data on the target application is the first action data, an adjustment sample is generated based on the launch feature and positive sample label; the first action data represents the user switching the target application to the foreground in the first time period after the target application is launched; When the user's operational behavior data on the target application is the second behavior data, an adjustment sample is generated based on the startup characteristics and negative sample labels; the second behavior data represents that the user did not switch the target application to the foreground in the first period after the target application was launched.

[0076] This application embodiment also provides a terminal device that integrates any of the application launch control devices provided in this application embodiment. The terminal device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor as steps in the application startup control method of any of the embodiments described above.

[0077] This application also provides a terminal device that integrates any of the application launch control devices provided in this application. For example... Figure 5 As shown, it illustrates a structural schematic diagram of the terminal device involved in the embodiments of this application. Specifically: The terminal device may include components such as a processor 501 with one or more processing cores, a memory 502 with one or more computer-readable storage media, a power supply 503, and an input unit 504. Those skilled in the art will understand that... Figure 5The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 501 is the control center of the terminal device. It connects various parts of the terminal 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 502, and by calling data stored in the memory 502, thereby providing overall monitoring of the terminal device. Optionally, the processor 501 may include one or more processing cores; preferably, the processor 501 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 501.

[0078] The memory 502 can be used to store software programs and modules. The processor 501 executes various functional applications and data processing by running the software programs and modules stored in the memory 502. The memory 502 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 terminal device, etc. In addition, the memory 502 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 502 may also include a memory controller to provide the processor 501 with access to the memory 502.

[0079] The terminal device also includes a power supply 503 that supplies power to the various components. Preferably, the power supply 503 can be logically connected to the processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 503 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0080] The terminal device may also include an input unit 504, 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.

[0081] Although not shown, the terminal device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 501 in the terminal device loads the executable files corresponding to the processes of one or more applications into the memory 502 according to the following instructions, and the processor 501 runs the applications stored in the memory 502 to realize various functions, as follows: Obtain the startup request of the target application; In response to a startup request, obtain the startup request context data, current system state data, and historical startup data of the target application; The target probability is determined based on context data, current system status data, and historical startup data. The target probability is used to characterize the startup probability of the target application. The activation of the target application is controlled based on the target probability.

[0082] 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.

[0083] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the application startup control methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Obtain the startup request of the target application; In response to a startup request, obtain the startup request context data, current system state data, and historical startup data of the target application; The target probability is determined based on context data, current system status data, and historical startup data. The target probability is used to characterize the startup probability of the target application. The activation of the target application is controlled based on the target probability.

[0084] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0085] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

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

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

Claims

1. A control method for application startup, characterized in that, include: Obtain the startup request of the target application; In response to the startup request, obtain the context data of the startup request, the current system status data, and the historical startup data of the target application; Based on the context data, the current system state data, and the historical startup data, a target probability is determined, wherein the target probability is used to characterize the startup probability of the target application; The launch of the target application is controlled based on the target probability.

2. The application startup control method according to claim 1, characterized in that, Determining the target probability based on the context data, the current system state data, and the historical startup data includes: The startup characteristics are determined based on the context data, the current system status data, and the historical startup data; The activation features are input into a pre-trained prediction model, which then outputs the target probability.

3. The application startup control method according to claim 2, characterized in that, The step of generating startup features based on the context data, the current system state data, and the historical startup data includes: Statistical characteristics were obtained by analyzing the historical startup data. The context data is encoded to obtain context features; The current system state data is encoded to obtain system state characteristics; The startup features are generated based on the statistical features, the context features, and the system state features.

4. The application startup control method according to claim 1, characterized in that, The step of controlling the launch of the target application based on the target probability includes: Based on the target probability, determine the activation strategy; The launch of the target application is controlled according to the launch strategy.

5. The application startup control method according to claim 4, characterized in that, The step of determining the activation strategy based on the target probability includes: When the target probability is greater than or equal to a first probability threshold, the activation strategy is determined to be a first strategy, wherein the first strategy represents the immediate activation of the target application; When the target probability is less than the second probability threshold, the launch strategy is determined to be the second strategy, wherein the second strategy indicates that the target application is prohibited from being launched; When the target probability is greater than or equal to the second probability threshold and less than the first probability threshold, the startup strategy is determined based on the current system state data.

6. The application startup control method according to claim 5, characterized in that, The current system status data includes memory status data and CPU status data. Determining the startup strategy based on the current system status data includes: When the memory status data is greater than the memory threshold and the CPU status data is less than the CPU threshold, the startup strategy is determined to be the first strategy. When the memory status data is less than or equal to the memory threshold, or the CPU status data is greater than or equal to the CPU threshold, the startup strategy is determined to be the third strategy, wherein the third strategy represents delaying the startup of the target application.

7. The application startup control method according to claim 2, characterized in that, After launching the target application based on the target probability, the process includes: After the target application is launched, an adjustment sample is generated based on the user's operational behavior data of the target application; The prediction model is trained based on the adjusted samples; The step of generating adjustment samples based on user behavior data of the target application includes: When the user's operation behavior data on the target application is the first behavior data, the adjustment sample is generated according to the launch feature and positive sample label, wherein the first behavior data represents that the user switches the target application to the foreground in the first time period after the target application is launched; When the user's operation behavior data on the target application is the second behavior data, the adjustment sample is generated based on the launch feature and negative sample label, wherein the second behavior data indicates that the user did not switch the target application to the foreground during the first time period after the target application was launched.

8. A control device for application startup, characterized in that, include: The first acquisition module is used to acquire the startup request of the target application; The second acquisition module is used to acquire, in response to the startup request, the context data of the startup request, the current system status data, and the historical startup data of the target application; The determination module is used to determine the target probability based on the context data, the current system state data, and the historical startup data, wherein the target probability is used to characterize the startup probability of the target application; The control module is used to control the launch of the target application based on the target probability.

9. A terminal device, characterized in that, The terminal device includes: one or more processors, a memory, and one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the application launch control method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to execute the steps of the application startup control method according to any one of claims 1 to 7.

Images