A standby power consumption optimization method and device based on a mobile operating system
By collecting user behavior and application data on mobile terminal devices, using machine learning algorithms to generate wake lock scores, and dynamically managing wake locks, the energy consumption problem of mobile terminal devices in standby mode is solved, achieving a balance between power consumption optimization and user experience.
Patent Information
- Application Number
- CN202511862010.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-11
- Publication Date
- 2026-02-24
- Estimated Expiration
- 2045-12-11
AI Technical Summary
In existing technologies, mobile terminal devices still consume a lot of energy in standby mode, resulting in shorter usage time, and forced sleep may affect user experience.
By collecting user behavior data and application runtime data, machine learning algorithms are used to generate wake lock scores, dynamically manage wake lock usage, and optimize standby power consumption.
It achieves both power saving and a good user experience, avoiding the rigidity of relying solely on manual rules, and making wake lock management more scientific, dynamic, and personalized.
Smart Images

Figure CN121300607B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of mobile operating system technology, specifically relating to a standby power consumption optimization method and apparatus based on a mobile operating system. Background Technology
[0002] With the widespread use of mobile terminal devices such as smartphones and tablets, they are receiving increasing attention and popularity from users. When using these mobile terminal devices, the duration of use has become an important part of the user experience and is attracting more and more attention from users.
[0003] In the prior art, since the touch screen of the mobile terminal device consumes a large amount of energy, when the user does not need to use the mobile terminal device, they often use the standby function to turn off the touch screen of the mobile terminal device, so that the mobile terminal device is in a screen-off standby state. When the user needs to use the mobile terminal device, they use the wake-up function to start the touch screen of the mobile terminal device in the standby state to work normally, so as to save the power consumption of the mobile terminal device and extend the usage time of the mobile terminal device.
[0004] However, in existing standby solutions, even when the touchscreen is off, the mobile device remains active in standby mode, consuming significant amounts of power and failing to effectively extend its usage time. This is because installed applications can request wake-up locks to prevent background processes from going to sleep, leading to wasted energy and unnecessary power consumption. However, forcing all applications to go to sleep could also negatively impact user experience. Summary of the Invention
[0005] The purpose of this invention is to provide a standby power consumption optimization method and device based on a mobile operating system, which intelligently manages the use of wake-up lock according to user operating habits and device power consumption, thereby optimizing standby power consumption.
[0006] To achieve the above objectives, the technical solution of the present invention is as follows:
[0007] A standby power consumption optimization method based on a mobile operating system includes:
[0008] S1. Collect user behavior data, application running data, and device status data of the mobile operating system of the mobile terminal device under the same historical timeline;
[0009] S2. Convert the collected data into numerical feature vectors;
[0010] S3. The numerical feature vector is used to train the dependency scoring model, and the dependency score of each application is output from 0 to 100.
[0011] S4. Calculate the wake-up lock score for each application based on the dependency score. Wake-up lock score = dependency score × 10. When an application requests a wake-up lock after the user turns off the screen, determine whether the application's wake-up lock score is sufficient to support the execution duration of the current wake-up. If it is insufficient, immediately release the wake-up lock and clear the score. If it is sufficient, execute the application's current wake-up normally and use the remaining wake-up lock score for the next wake-up within the current screen-off time until the score is cleared. After the score is cleared, the application cannot request a wake-up lock again within the current screen-off time.
[0012] Furthermore, in step S1, user behavior data includes application launch / exit time, notification clicks, manual cleanup, screen on and screen off events; application running data includes foreground / background dwell time, wake lock application and release records; device status data includes battery level, charging status, network type, and device temperature.
[0013] Furthermore, step S2 includes:
[0014] S201. Data cleaning and correction: processing missing and outlier values in the collected data;
[0015] S202, Feature extraction: Extracting statistical features from user behavior data, application running data, and device status data;
[0016] S203. Feature standardization: Map all feature values to the [0,1] interval;
[0017] S204. Feature vector generation: The feature vector is constructed using all the features of each application within a statistical period.
[0018] Furthermore, the dependency scoring model described in step S3 adopts the LightGBM model and is set on the server side; the server side is trained with feature vectors converted from the collected large sample data, and the model is fine-tuned by collecting data from mobile terminal devices once in each statistical period.
[0019] Furthermore, step S4 specifically includes:
[0020] S401. Calculate the application's wake-up lock score N, where N = dependency score × 10;
[0021] S402. Calculate the maximum time window Tmax corresponding to the wake-up lock integral N when the screen is off; Tmax=N×M; where M is a global proportional coefficient, and different values of M are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold.
[0022] S403. Calculate Tmax-Trun, where Trun is the execution duration of the application after this wake-up.
[0023] S404. If Tmax - Trun is less than or equal to 0, immediately release the wake-up lock and clear the integral N; if Tmax - Trun is greater than 0, execute the application's wake-up normally and calculate the remaining integral N. 剩余 N 剩余 =N-(Tmax-Trun) / M, and use the remaining integral for the next wake-up during this screen-off period.
[0024] Furthermore, in step S3, while training the dependency scoring model, an auxiliary model is also trained. The auxiliary model adopts the Q-Learning reinforcement learning algorithm, with the application's dependency score, the mobile terminal device's battery status, screen status, and the application's wake-up lock score as the state set, and adjusting the behavior weight as the action. Rewards and penalties are calculated through standby time improvement and abnormal wake-up counts to form a dynamic optimization mechanism for the wake-up lock score; wherein the wake-up lock score N = dependency score × 10.
[0025] Furthermore, the dynamic optimization mechanism calculates the application's dynamic points. When the user turns off the screen and the application requests a wake-up lock, the dynamic points of the application are used to determine whether they are sufficient to support the execution duration of the current wake-up. If not, the wake-up lock is released immediately and the dynamic points are cleared to zero. If they are sufficient, the application's current wake-up is executed normally, and the remaining dynamic points are used for the next wake-up within the current screen-off time, until the dynamic points are cleared to zero. After the dynamic points are cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
[0026] Preferred, including:
[0027] S411. Calculate the application's wake-up lock score N, N = dependency score × 10; then calculate the dynamic score N′, N′ = N + (behavior weight × scenario coefficient); where the behavior weight is obtained through the auxiliary model; when the mobile terminal device's battery is below the low battery threshold, set the scenario coefficient to reduce the behavior weight; when the mobile terminal device is charging, set the scenario coefficient to increase the behavior weight; when the mobile terminal device's battery is above the high battery threshold, the score is frozen, and the application does not consume points when requesting a wake-up lock.
[0028] S412. Calculate the maximum time window Tmax corresponding to the dynamic integral N′ when the screen is off; Tmax=N′×M; where M is the global scaling factor, and different values of M are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold.
[0029] S413. Calculate Tmax-Trun, where Trun is the execution duration of the application after this wake-up.
[0030] S404. If Tmax - Trun is less than or equal to 0, immediately release the wake-up lock and clear the dynamic integral N′; if Tmax - Trun is greater than 0, execute the application's wake-up normally and calculate the remaining integral N. 剩余 N 剩余 =N′-(Tmax-Trun) / M, and use the remaining integral for the next wake-up during this screen-off period.
[0031] Furthermore, the Q-table of the auxiliary model Q-Learning reinforcement learning algorithm is stored in the form of a sparse matrix, and data is automatically collected and updated when the mobile terminal device is charging, using Wi-Fi, and with the CPU idle.
[0032] In another aspect, the present invention provides a standby power consumption optimization device based on a mobile operating system, comprising:
[0033] Data Acquisition Layer: Collects user behavior data, application running data, and device status data of mobile terminal devices' mobile operating systems within the same historical timeline;
[0034] Feature engineering layer: transforms the collected data into numerical feature vectors;
[0035] Model training layer: The numerical feature vectors are used to train the dependency scoring model, which outputs a dependency score of 0-100 for each application.
[0036] Inference Application Layer: Calculate the wake-up lock score for each application based on the dependency score. Wake-up lock score = dependency score × 10. When an application requests a wake-up lock after the user turns off the screen, determine whether the application's wake-up lock score is sufficient to support the execution duration of the current wake-up. If not, immediately release the wake-up lock and clear the score. If sufficient, execute the application's current wake-up normally and use the remaining wake-up lock score for the next wake-up within the current screen-off time, until the score is cleared to zero. After the score is cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
[0037] Compared with the prior art, the present invention has the following beneficial effects:
[0038] This invention introduces intelligent algorithms to statistically analyze and model user behavior when using applications, and combines machine learning algorithms to automatically and dynamically generate an points system. The application points result drives the duration control of the wake-up lock when the screen is off, making the wake-up lock management strategy more scientific, dynamic and personalized, in line with the actual usage patterns of users. While saving power, it maintains a good user experience and realizes an intelligent standby power consumption optimization scheme, avoiding the rigidity of simply relying on manual rules. Attached Figure Description
[0039] Figure 1 This is a flowchart illustrating Embodiment 1 of the present invention;
[0040] Figure 2 This is a flowchart illustrating Embodiment 2 of the present invention;
[0041] Figure 3 This is a schematic diagram of the structure of Embodiment 3 of the present invention. Detailed Implementation
[0042] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.
[0043] The present invention will now be described in detail with reference to specific embodiments and accompanying drawings.
[0044] Example 1:
[0045] like Figure 1 As shown, the standby power consumption optimization method based on a mobile operating system proposed in Embodiment 1 includes:
[0046] S1. Collect user behavior data, application running data, and device status data of the mobile operating system of the mobile terminal device under the same historical timeline.
[0047] This step collects three types of core information data through the mobile operating system hooks and status sensors of the mobile terminal device:
[0048] User behavior data: application launch / exit time, notification clicks, manual cleanup, screen on and screen off events;
[0049] Application runtime data: foreground / background dwell time, wake lock request and release records;
[0050] Device status data: battery level, charging status, network type, and device temperature.
[0051] For example, in this step, data collection adopts a strategy of local caching and batch uploading. Logs are first written to a circular buffer (with a preset data storage capacity; for example, the circular buffer can store 1000 data entries). When the mobile terminal device is in charging + WiFi mode, or when the buffer's cache exceeds 80%, the data in the circular buffer is transmitted to the server in batches. If the collected data consists of high-frequency behavioral events, sampling can be performed at certain intervals, such as 5 seconds. Low-frequency behavioral events are recorded in full to balance power consumption and data integrity.
[0052] S2. Convert the collected data into numerical feature vectors.
[0053] The server transforms the collected raw data into numerical feature vectors that can be used for model training to reflect user behavior patterns, device status, and power consumption characteristics. The transformation process includes four steps: feature extraction, data cleaning, standardization, and feature vector generation, as detailed below:
[0054] 1. Data cleaning and correction:
[0055] This step mainly deals with missing and outlier values in the collected raw data.
[0056] Missing value handling:
[0057] For missing points in the time series, the mean of the two preceding and following points is used to fill them; non-continuous terms are set to zero.
[0058] Outlier detection:
[0059] Use the 3σ principle to correct outliers that are outside the normal range.
[0060] 2. Feature extraction:
[0061] Statistical features are extracted from three types of data: user actions, application operation, and device status. An example is shown below:
[0062]
[0063] 3. Feature standardization:
[0064] To eliminate dimensional differences among different features, Min-Max normalization is used:
[0065] Map all extracted feature values to the interval [0,1].
[0066] 4. Feature vector generation:
[0067] The feature vector is constructed using all features of each application within a statistical period (for example, a statistical period can be 7 days):
[0068] F = [f1, f2, f3, ..., fn], where each of f1, f2, f3, ..., fn corresponds to a statistical feature in the table above, and n is the feature dimension (approximately 10–20 dimensions in this embodiment).
[0069] Example:
[0070] Fapp=[0.75,0.20,0.15,0.80,0.60,0.40,0.25,0.10]; Fapp represents the feature vector of the app. The final generated feature vector is input into the dependency scoring model described in the following steps for model training. The training objective is to output an application dependency score of 0–100 for subsequent integral calculation.
[0071] S3. The numerical feature vector is used to train the dependency scoring model, and the dependency score of each application is output from 0 to 100.
[0072] The dependency scoring model uses the LightGBM model and is set on the server side;
[0073] After the server converts the collected raw data of a large sample into feature vectors, it trains the LightGBM model on the feature vectors of each application and outputs an application dependency score of 0-100.
[0074] Raw data is collected once per statistical period to fine-tune the dependency scoring model.
[0075] S4. Calculate the wake-up lock score for each application based on the dependency score. Wake-up lock score = dependency score × 10. When an application requests a wake-up lock after the user turns off the screen, determine whether the application's wake-up lock score is sufficient to support the execution duration of the current wake-up. If it is insufficient, immediately release the wake-up lock and clear the score. If it is sufficient, execute the application's current wake-up normally and use the remaining wake-up lock score for the next wake-up within the current screen-off time until the score is cleared. After the score is cleared, the application cannot request a wake-up lock again within the current screen-off time.
[0076] This step is the inference application stage after the model has been trained.
[0077] First, calculate the wake-up lock score for each application based on the dependency score:
[0078] N = Dependency score × 10; N represents the wake-up lock score.
[0079] When the user requests a wake-up lock in the application after the screen is off, calculate the maximum time window Tmax corresponding to the wake-up lock integral N when the screen is off.
[0080] Tmax = N × M;
[0081] Where M is the global proportionality coefficient, different M values are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when it is less than the judgment threshold; Exemplarily, in this embodiment, the judgment threshold is set to 50% of the battery level of the mobile terminal device. When the current battery level is greater than or equal to 50%, M = 0.1; when the current battery level is less than 50%, M = 0.05.
[0082] Then calculate the remaining points:
[0083] N 剩余 = N - (Tmax - Trun) / M; where N 剩余 represents the remaining points, and Trun is the execution duration after the application is woken up this time;
[0084] If the remaining points are less than or equal to 0, immediately release the wake lock and clear the points N; if the remaining points are greater than 0, normally execute the current wake-up of the application, and use the remaining points for the next wake-up within the current screen-off time until the points are cleared. (If the screen-off time is long, the APP may apply for the wake lock multiple times).
[0085] After the points are cleared, the application cannot apply for the wake lock again within the current screen-off time. After the screen-off ends, re-execute this step S4 during the next screen-off.
[0086] [[ID= (20)]]Taking a certain application APP as an example, if the dependency score is deduced to be 7.5 according to steps S1 - S3, and the battery level during the current screen-off is 60%.
[0087] The wake lock points N = 7.5 × 10 = 75;
[0088] The coefficient M = 0.1, and the maximum time window Tmax = 75 × 0.1 = 7.5 seconds;
[0089] Calculate Tmax - Trun, where Trun is the execution duration after the application is woken up this time;
[0090] If the actual execution time after waking up is 30 seconds and Trun > Tmax, immediately release the wake lock and clear the points;
[0091] If the actual execution time after waking up is 5 seconds and Trun < Tmax, then calculate
[0092] the remaining points and save them, N 剩余 [[ID = 40]]= 75 - (7.5 - 5) / 0.1 = 50, and store these 50 points as the remaining points for the next wake-up of this APP during the current screen-off time.
[0093] In this embodiment, blacklists and whitelists can also be set for applications. Applications added to the blacklist are not allowed to set wake locks and are all forced to be unwakeable; applications added to the whitelist are not subject to the limitations of this method when using wake locks.
[0094] This embodiment introduces an intelligent behavior statistics and analysis mechanism, combined with machine learning algorithms to automatically generate an points system, enabling scientific, dynamic, and personalized management of wake-up locks. This intelligent management solution for sleep locks ensures both power saving and user experience, avoiding the rigidity of relying solely on manual rules.
[0095] Example 2:
[0096] This embodiment is a further optimization based on the method described in Embodiment 1, adding a dynamic optimization mechanism for wake-up lock points to further optimize wake-up lock management.
[0097] In this embodiment, steps S1 and S2 are the same as in Embodiment 1, while steps S3 and S4 are optimized into steps S3' and S4', as follows: Figure 2 As shown, it includes:
[0098] S3' The numerical feature vector is used to train the dependency scoring model, which outputs a dependency score of 0-100 for each application; at the same time, an auxiliary model is also trained to form a dynamic optimization mechanism for wake-up lock integral.
[0099] The dependency scoring model uses the LightGBM model and is set on the server side;
[0100] After the server converts the collected raw data of a large sample into feature vectors, it trains the LightGBM model on the feature vectors of each application and outputs an application dependency score of 0-100.
[0101] Raw data is collected once per statistical period to fine-tune the dependency scoring model.
[0102] The auxiliary model employs the Q-Learning reinforcement learning algorithm, using the application's dependency score, the mobile terminal device's battery status, screen status, and the application's wake-up lock score as the state set. Adjusting behavioral weights is the action, and rewards and penalties are calculated based on improvements in standby time and the number of abnormal wake-ups. The wake-up lock score is calculated by multiplying the dependency score by 10.
[0103] After training, the model is converted to TensorFlow Lite format for deployment. The Q-table of the Q-Learning reinforcement learning algorithm is stored in the form of a sparse matrix. When the mobile terminal device is charging, using Wi-Fi, and with the CPU idle, data is automatically collected and uploaded to the server for model updates.
[0104] S4' Calculate the application's dynamic points through the dynamic optimization mechanism. When the user turns off the screen and the application requests a wake-up lock, determine whether the application's dynamic points are sufficient to support the execution duration of this wake-up. If not, immediately release the wake-up lock and clear the dynamic points. If sufficient, execute the application's wake-up normally and use the remaining dynamic points for the next wake-up within the current screen-off time until the dynamic points are cleared. After the dynamic points are cleared, the application cannot request a wake-up lock again within the current screen-off time.
[0105] This step is the inference application stage after the dependency scoring model and auxiliary model have been trained.
[0106] First, calculate the wake-up lock score for each application based on the dependency score:
[0107] N = Dependency score × 10; N represents the wake-up lock score.
[0108] Then calculate the dynamic integral N′, N′=N+(behavior weight × scene coefficient); where the behavior weight is obtained through an auxiliary model; when the mobile terminal device's battery level is below the low battery threshold, a scene coefficient is set to reduce the behavior weight; when the mobile terminal device is charging, a scene coefficient is set to increase the behavior weight; when the mobile terminal device's battery level is above the high battery threshold, the integral is frozen, and no integral is consumed when the application requests a wake-up lock; for example, in this embodiment, the scene coefficient is set to 0.5 when the mobile terminal device's battery level is below 20%, thereby halving the behavior weight; the scene coefficient is set to 1.2 when the mobile terminal device is charging, thereby increasing the behavior weight by 20%; when the mobile terminal device's battery level is above 80%, the integral is frozen, and no integral is consumed when the application requests a wake-up lock after freezing.
[0109] When the user requests a wake-up lock in the application after the screen is off, calculate the maximum time window Tmax corresponding to the wake-up lock integral N when the screen is off.
[0110] Tmax = N′ × M; where M is a global proportional coefficient. Different M values are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold. For example, in this embodiment, the judgment threshold is set to 50% battery level of the mobile terminal device. When the current battery level is greater than or equal to 50%, M = 0.1; when the current battery level is less than 50%, M = 0.05.
[0111] Then calculate Tmax-Trun, where Trun is the execution duration of the application after this wake-up;
[0112] If Tmax - Trun is less than or equal to 0, the wake-up lock is immediately released and the dynamic integral N′ is cleared; if Tmax - Trun is greater than 0, the application's wake-up process is executed normally, and the remaining integral N is calculated. 剩余 N 剩余 =N′-(Tmax-Trun) / M, and use the remaining points for the next wake-up during this screen-off period, until the points are cleared. (If the screen-off period is long, the app may request the wake-up lock multiple times).
[0113] After the points are cleared, the application cannot request a wake-up lock during the current screen-off period. This step S4' will be executed again during the next screen-off period after the screen-off ends.
[0114] This embodiment further establishes a dynamic optimization mechanism for wake-up lock integration, making wake-up lock management more scientific, dynamic, and personalized. While saving power, it maintains a good user experience, achieving a more intelligent standby power consumption optimization scheme.
[0115] Example 3:
[0116] This embodiment proposes a standby power consumption optimization device based on a mobile operating system, such as... Figure 3 As shown, it includes:
[0117] Data Acquisition Layer: Collects user behavior data, application running data, and device status data of mobile terminal devices' mobile operating systems within the same historical timeline;
[0118] Feature engineering layer: transforms the collected data into numerical feature vectors;
[0119] Model training layer: The numerical feature vectors are used to train the dependency scoring model, which outputs a dependency score of 0-100 for each application.
[0120] Inference Application Layer: Calculate the wake-up lock score for each application based on the dependency score. Wake-up lock score = dependency score × 10. When an application requests a wake-up lock after the user turns off the screen, determine whether the application's wake-up lock score is sufficient to support the execution duration of the current wake-up. If not, immediately release the wake-up lock and clear the score. If sufficient, execute the application's current wake-up normally and use the remaining wake-up lock score for the next wake-up within the current screen-off time, until the score is cleared to zero. After the score is cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
[0121] In the data acquisition layer, user behavior data includes application launch / exit time, notification clicks, manual cleanup, and screen-on and screen-off events; application running data includes foreground / background dwell time and wake-lock request and release records; device status data includes battery level, charging status, network type, and device temperature.
[0122] The feature engineering layer includes:
[0123] Data cleaning and correction module: processes missing and outlier values in the collected data;
[0124] Feature extraction module: Extracts statistical features from user behavior data, application runtime data, and device status data;
[0125] Feature standardization module: Maps all feature values to the [0,1] interval;
[0126] Feature vector generation module: Constructs a feature vector from all features of each application within a statistical period.
[0127] The dependency scoring model in the model training layer adopts the LightGBM model and is set on the server side. The server side is trained with feature vectors transformed from the collected large sample data, and the model is fine-tuned by collecting data from mobile terminal devices once every statistical period.
[0128] The inference application layer includes:
[0129] Indicator Calculation Module: Calculates the application's wake-up lock score N, where N = dependency score × 10;
[0130] Time window module: Calculates the maximum time window Tmax corresponding to the wake-up lock integral N when the screen is off; Tmax=N×M; where M is a global proportional coefficient, and different values of M are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold;
[0131] Calculation module: Calculates Tmax - Trun, where Trun is the execution duration of the application after this wake-up.
[0132] The decision module determines whether to immediately release the wake-up lock and reset the integral N if Tmax - Trun is less than or equal to 0. If Tmax - Trun is greater than 0, the application will execute the current wake-up normally and the remaining integral N will be calculated. 剩余 N 剩余 =N-(Tmax-Trun) / M, and use the remaining integral for the next wake-up during this screen-off period.
[0133] Optimization plan:
[0134] In the model training layer, an auxiliary model is trained simultaneously with the dependency scoring model. The auxiliary model uses the Q-Learning reinforcement learning algorithm, with the application's dependency score, the mobile terminal device's battery status, screen status, and the application's wake-up lock score as the state set, and adjusting the behavior weights as actions. Rewards and penalties are calculated by increasing standby time and the number of abnormal wake-ups, forming a dynamic optimization mechanism for the wake-up lock score; where the wake-up lock score N = dependency score × 10.
[0135] The inference application layer calculates the application's dynamic points through the dynamic optimization mechanism. When the user turns off the screen and the application requests a wake-up lock, it determines whether the application's dynamic points are sufficient to support the execution duration of the current wake-up. If not, the wake-up lock is immediately released and the dynamic points are cleared to zero. If they are sufficient, the application's current wake-up is executed normally, and the remaining dynamic points are used for the next wake-up within the current screen-off time, until the dynamic points are cleared to zero. After the dynamic points are cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
[0136] The inference application layer includes:
[0137] The points calculation module calculates the application's wake-up lock points N, where N = dependency score × 10; then it calculates the dynamic points N′, where N′ = N + (behavior weight × scenario coefficient); where the behavior weight is obtained through an auxiliary model; when the mobile terminal device's battery level is below the low battery threshold, the scenario coefficient that weakens the behavior weight is set; when the mobile terminal device is charging, the scenario coefficient that increases the behavior weight is set; when the mobile terminal device's battery level is above the high battery threshold, the points are frozen, and no points are consumed when the application requests a wake-up lock.
[0138] Time window module: Calculates the maximum time window Tmax corresponding to the dynamic integral N′ when the screen is off; Tmax=N′×M; where M is a global scaling factor, and different values of M are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold;
[0139] Calculation module: Calculates Tmax - Trun, where Trun is the execution duration of the application after this wake-up.
[0140] The judgment module determines whether to immediately release the wake-up lock and clear the dynamic integral N′ if Tmax - Trun is less than or equal to 0; otherwise, it executes the application's wake-up normally and calculates the remaining integral N. 剩余 N 剩余 =N′-(Tmax-Trun) / M, and use the remaining integral for the next wake-up during this screen-off period.
[0141] Among them, the Q-table of the auxiliary model Q-Learning reinforcement learning algorithm is stored in the form of a sparse matrix, and is automatically updated by collecting data when the mobile terminal device is in a state of charging + Wi-Fi + CPU idle.
[0142] The standby power consumption optimization device based on the mobile operating system proposed in this embodiment can realize the standby power consumption optimization method based on the mobile operating system proposed in Embodiment 1 or 2, and has the same technical effect as Embodiment 1 and 2.
[0143] The above-described embodiments are merely preferred embodiments of the present invention and are only used to help understand the method and core ideas of this application. The scope of protection of the present invention is not limited to the above embodiments, and all technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.
Claims
1. A method for optimizing standby power consumption based on a mobile operating system, characterized in that, include: S1. Collect user behavior data, application running data, and device status data of the mobile operating system of the mobile terminal device under the same historical timeline; S2. Convert the collected data into numerical feature vectors; S3. The numerical feature vector is used to train the dependency scoring model, and the dependency score of each application is output from 0 to 100. S4. Calculate the wake-up lock score for each application based on the dependency score. Wake-up lock score = dependency score × 10. When a user turns off the screen and an application requests a wake-up lock, the system determines whether the application's wake-up lock points are sufficient to support the execution duration of the current wake-up. If not, the wake-up lock is immediately released and the points are cleared to zero. If the points are sufficient, the application's current wake-up is executed normally, and the remaining wake-up lock points are used for the next wake-up within the current screen-off time, until the points are cleared to zero. After the points are cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
2. The standby power consumption optimization method based on a mobile operating system according to claim 1, characterized in that, In step S1, user behavior data includes application launch / exit time, notification clicks, manual cleanup, screen on and screen off events; application running data includes foreground / background dwell time, wake lock application and release records; device status data includes battery level, charging status, network type, and device temperature.
3. The standby power consumption optimization method based on a mobile operating system according to claim 1, characterized in that, Step S2 includes: S201. Data cleaning and correction: processing missing and outlier values in the collected data; S202, Feature extraction: Extracting statistical features from user behavior data, application running data, and device status data; S203. Feature standardization: Map all feature values to the [0,1] interval; S204. Feature vector generation: The feature vector is constructed using all the features of each application within a statistical period.
4. The standby power consumption optimization method based on a mobile operating system according to claim 1, characterized in that, The dependency scoring model mentioned in step S3 adopts the LightGBM model and is set on the server side. The server side is trained with feature vectors converted from the collected large sample data, and the model is fine-tuned by collecting data from mobile terminal devices once every statistical period.
5. The standby power consumption optimization method based on a mobile operating system according to claim 1, characterized in that, Step S4 specifically includes: S401. Calculate the application's wake-up lock score N, where N = dependency score × 10; S402. Calculate the maximum time window Tmax corresponding to the wake-up lock integral N when the screen is off; Tmax=N×M; where M is a global proportional coefficient, and different values of M are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold. S403. Calculate Tmax-Trun, where Trun is the execution duration of the application after this wake-up. S404. If Tmax - Trun is less than or equal to 0, immediately release the wake-up lock and clear the integral N; if Tmax - Trun is greater than 0, execute the application's wake-up normally and calculate the remaining integral N. 剩余 N 剩余 =N-(Tmax-Trun) / M, and use the remaining integral for the next wake-up during this screen-off period.
6. The standby power consumption optimization method based on a mobile operating system according to claim 1, characterized in that, In step S3, while training the dependency scoring model, an auxiliary model is also trained. The auxiliary model adopts the Q-Learning reinforcement learning algorithm, with the application's dependency score, the mobile terminal device's battery status, screen status, and the application's wake-up lock score as the state set, and adjusting the behavior weight as the action. Rewards and penalties are calculated by increasing standby time and the number of abnormal wake-ups, forming a dynamic optimization mechanism for the wake-up lock score; where the wake-up lock score N = dependency score × 10.
7. The standby power consumption optimization method based on a mobile operating system according to claim 6, characterized in that, The dynamic optimization mechanism calculates the application's dynamic points. When the application requests a wake-up lock after the user turns off the screen, it is determined whether the application's dynamic points are sufficient to support the execution duration of the current wake-up. If not, the wake-up lock is immediately released and the dynamic points are cleared to zero. If they are sufficient, the application's current wake-up is executed normally, and the remaining dynamic points are used for the next wake-up within the current screen-off time, until the dynamic points are cleared to zero. After the dynamic points are cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
8. The standby power consumption optimization method based on a mobile operating system according to claim 7, characterized in that, include: S411. Calculate the application's wake-up lock integral N, where N = dependency score × 10; Then calculate the dynamic integral N′, N′=N+(behavior weight × scene coefficient); The behavior weights are obtained through an auxiliary model; when the battery level of the mobile terminal device is below the low battery threshold, a scenario coefficient is set to reduce the behavior weight; when the mobile terminal device is charging, a scenario coefficient is set to increase the behavior weight; when the battery level of the mobile terminal device is above the high battery threshold, the points are frozen; and no points are consumed when the application requests a wake-up lock. S412. Calculate the maximum time window Tmax corresponding to the dynamic integral N′ when the screen is off. Tmax = N′ × M; Where M is the global proportional coefficient, and different M values are set when the current battery level of the mobile terminal device is greater than or equal to the judgment threshold and when the battery level is less than the judgment threshold; S413. Calculate Tmax-Trun, where Trun is the execution duration of the application after this wake-up. S404. If Tmax - Trun is less than or equal to 0, immediately release the wake-up lock and clear the dynamic integral N′; if Tmax - Trun is greater than 0, execute the application's wake-up normally and calculate the remaining integral N. 剩余 N 剩余 =N′-(Tmax-Trun) / M, and use the remaining integral for the next wake-up during this screen-off period.
9. The standby power consumption optimization method based on a mobile operating system according to claim 6, characterized in that, The Q-table of the auxiliary model Q-Learning reinforcement learning algorithm is stored in sparse matrix form and is automatically updated when the mobile terminal device is charging, using Wi-Fi, and with the CPU idle.
10. A standby power consumption optimization device based on a mobile operating system, characterized in that, include: Data Acquisition Layer: Collects user behavior data, application running data, and device status data of mobile terminal devices' mobile operating systems within the same historical timeline; Feature engineering layer: transforms the collected data into numerical feature vectors; Model training layer: The numerical feature vectors are used to train the dependency scoring model, which outputs a dependency score of 0-100 for each application. Inference Application Layer: Calculate the wake-up lock score for each application based on the dependency score. Wake-up lock score = dependency score × 10. When an application requests a wake-up lock after the user turns off the screen, determine whether the application's wake-up lock score is sufficient to support the execution duration of the current wake-up. If not, immediately release the wake-up lock and clear the score. If sufficient, execute the application's current wake-up normally and use the remaining wake-up lock score for the next wake-up within the current screen-off time, until the score is cleared to zero. After the score is cleared to zero, the application cannot request a wake-up lock again within the current screen-off time.
Citation Information
Patent Citations
Mobile terminal power consumption optimization method and device based on user behavior analysis
CN110167121A
Dynamic battery power consumption optimization method based on machine learning
CN120224352A