A task optimization method, device and medium based on Android standby energy saving

Abstract

The present invention relates to a task optimization method, device and medium based on Android standby energy saving, which includes: changing the queue joining mechanism and setting the Wakeup attribute for the queue; when a new Alarm needs to join the queue, judging whether the Wakeup attribute of the queue to be joined is consistent with the type of the new Alarm, if consistent, joining the queue; otherwise, creating a new queue; changing the start time of the queue used by each queue to wake up the kernel to the end time; when a queue is a precise Alarm, the time for waking up the kernel of the adjacent Wakeup type queue behind it is modified to the queue start time minus the fuzzy time of the queue. The present invention reduces the number of times the kernel is woken up, thereby achieving the purpose of reducing internal friction.

Description

Technical Field

[0001] The present invention relates to the field of software development, and in particular to a task optimization method, device and medium based on Android standby energy saving. Background Art

[0002] AOSP is an open source Android operating system for mobile devices. Any developer can make any modifications to this open source code.

[0003] Alarm is a task type in Android, which is used to trigger at a specified time or after a specified time period. Application developers can use alarms to perform operations outside the life cycle, and can set long-term and repetitive tasks. It is widely used in scenarios such as timing and reminders. In standby mode, if an application wants to perform tasks or certain operations, it needs to set an Alarm to complete the corresponding operation. Because Alarm can wake up the CPU by setting the kernel wake-up time, so as to achieve the purpose of executing the job. At the same time, not all Alarms can wake up the CPU. Alarms are divided into Wakeup type and non-Wakeup type. Only Alarms belonging to the non-Wakeup type can wake up the CPU.

[0004] Android's low power mode saves power by limiting apps' access to the network and CPU when the user does not plug in a power source and the screen is off. During this period, non-wakeup alarms will not wake up the kernel, that is, they will not be triggered actively, but will be delayed until the next wakeup. At the same time, the system will exit the low power mode at a fixed time to execute these delayed alarms. This mechanism allows alarms that are not running during the low power mode to be triggered collectively after exiting the low power mode.

[0005] Although Android's low power mode can combine multiple task types together for triggering, this method simply postpones the task to a point in time for execution, and does not consider merging tasks without changing the execution time. This method will have a certain impact on the user experience.

[0006] Google's own Standby Bucket has a similar optimization mechanism. This mechanism sets the application to five levels, namely Active, Working set, Frequent, Rare, and Never, based on the time when the user last used an application and the frequency of using the application. Only Active does not restrict applications, and the other four levels of applications will have certain restrictions. The principle is to limit the number of application wake-ups in a period of time to reduce the number of task wake-ups, thereby achieving the purpose of saving energy. Although the Standby Bucket mechanism can restrict applications that are used less by users, it does not optimize applications that are used more by users, and these applications often have more tasks set. In actual observations, most applications will be in the Active state, so the energy saving effect may be very small. At the same time, users do not use some important applications so frequently, but they are very important to users. If the Standby Bucket mechanism sets them as non-Active applications and restricts their task scheduling, it will have a great impact on the user experience. Summary of the invention

[0007] In order to solve the above problems, the present invention proposes a task optimization method, device and medium based on Android standby energy saving.

[0008] The specific plan is as follows:

[0009] A task optimization method based on Android standby energy saving comprises the following steps:

[0010] Change the queue joining mechanism in BatchingAlarmStore, set the Wakeup attribute for the queue in BatchingAlarmStore, and the Wakeup attribute of the queue is consistent with the type of the Alarm in the queue; when a new Alarm needs to be added to the queue, determine whether the Wakeup attribute of the queue it needs to join is consistent with the type of the new Alarm. If consistent, add the queue; otherwise, create a new queue;

[0011] Change the start time mStart of each queue in BatchingAlarmStore used to wake up the kernel to the end time mEnd;

[0012] When a queue in BatchingAlarmStore is a precise alarm, the time for waking up the kernel of the adjacent Wakeup type queue behind it is changed from the queue's start time mStart to the queue's start time mStart minus the queue's fuzzy time; the queue's fuzzy time is calculated as: the product of the difference between the queue's end time mEnd and the start time mStart and the proportional coefficient; the proportional coefficient is set according to whether there is an Active Alarm in the queue and the system Doze state.

[0013] Furthermore, in the setting of the blur rate, when there is an Active Alarm in the queue and the system Doze state is Standard, the blur rate is set to 0%; when the system Doze state is Light Doze, the blur rate is set to 10%; when the system Doze state is Deep Doze, the blur rate is set to 20%.

[0014] Furthermore, in the setting of the blur rate, when there is no Active Alarm in the queue and the system Doze state is Standard, the blur rate is set to 0%; when the system Doze state is Light Doze, the blur rate is set to 20%; when the system Doze state is Deep Doze, the blur rate is set to 40%.

[0015] A task optimization terminal device based on Android standby energy saving includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the above-mentioned method of the embodiment of the present invention are implemented.

[0016] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method described above in an embodiment of the present invention are implemented.

[0017] The present invention adopts the above technical solution to reduce the number of times the core is awakened, thereby achieving the purpose of reducing internal friction. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 The figure is a schematic diagram of optimization of the priority of the Alarm selection queue in the first embodiment of the present invention.

[0019] Figure 2 FIG. 1 is a schematic diagram of optimizing the queue trigger time in the first embodiment of the present invention.

[0020] Figure 3 FIG. 1 is a schematic diagram of task-triggered fuzzy alignment optimization in Embodiment 1 of the present invention. DETAILED DESCRIPTION

[0021] To further illustrate various embodiments, the present invention provides drawings. These drawings are part of the disclosure of the present invention, which are mainly used to illustrate the embodiments and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these contents, ordinary technicians in this field should be able to understand other possible implementations and advantages of the present invention.

[0022] The present invention will now be further described with reference to the accompanying drawings and specific implementation methods.

[0023] Embodiment 1:

[0024] The embodiment of the present invention provides a task optimization method based on Android standby energy saving, including the following three optimization strategies.

[0025] (1) Alarm selection queue priority optimization

[0026] BatchingAlarmStore is a data structure for storing alarms. BatchAlarmStore contains multiple queues, and each queue contains several alarms. If the alarms are in the same queue, it means that they can be executed at the same time point. When the application sets a new alarm, it will be added to the queue through BatchingAlarmStore. First, it will look for a queue that can be added. The judgment basis is that each queue will maintain a start and end time, indicating that the alarms in the queue can be triggered in this time period. If the newly added alarm is in this time period, it can be added. If it is not in this time period, it will match the next queue until all queues are matched. If no match is found, a new queue will be created to join. The start and end time are set to the executable time period of the alarm.

[0027] The original mechanism in BatchingAlarmStore is that when a new Alarm is added, the new Alarm will first look for a queue that can be added (that is, it has an intersection with the trigger time of the existing Alarm in the queue), but joining the queue means that the start and end time of the queue (the range from the start time mStart to the end time mEnd) will most likely be reduced. If a new queue is created for storage, it will not affect the start and end time of the original queue. For this scenario, if the start and end time range is larger, it means that other Alarms are more likely to join. The addition of other Alarms will reduce the number of kernel wake-ups, that is, the number of CPU calls, thereby achieving the purpose of reducing energy consumption. Therefore, for a queue with Wakeup type Alarms, non-Wakeup type Alarms should not be added to shorten the start and end time of the queue. Wakeup type Alarms should be added. Although the start and end time are also shortened, it can reduce one CPU wake-up, which is a direct benefit. Similarly, for queues with non-Wakeup type Alarms, they will not wake up the core when in standby mode, so Wakeup type Alarms should not be added. If Wakeup type Alarms are added, the start and end times of the queue will be shortened, and the CPU wake-up will not be reduced, and energy consumption will not be reduced.

[0028] Based on the above principle, this embodiment changes the queue joining mechanism in BatchingAlarmStore in AOSP, sets the Wakeup attribute for the queue in BatchingAlarmStore, and the Wakeup attribute of the queue is consistent with the type of the Alarm in the queue, that is, when the first Alarm in the queue is of Wakeup type, the Wakeup attribute of the queue is set to indicate the Wakeup type; when the first Alarm in the queue is of non-Wakeup type, the Wakeup attribute of the queue is set to indicate the non-Wakeup type. When a new Alarm needs to be added to the queue, it is determined whether the Wakeup attribute of the queue it needs to join is consistent with the type of the new Alarm. If they are consistent, the queue is added; otherwise, a new queue is created and the new Alarm is added to the newly created queue.

[0029] Through the above optimization, the wakeup type alarms are aligned with each other, and the non-wakeup type alarms are aligned with each other, which reduces the number of CPU wake-up times and thus reduces energy consumption. Figure 1The figure shows a comparison before and after the queue priority optimization is implemented. In the left figure corresponding to the period before optimization, the four sub-figures correspond to the following four steps: 1. A non-Wakeup type Alarm is newly added, and the trigger time is 5min-10min; 2. A Wakeup type Alarm is newly added, and the trigger time is 8min-15min; 3. A Wakeup type Alarm is newly added, and the trigger time is 12min-20min; 4. When the task is triggered, the two Alarms in the first queue are triggered at 8min, because there is a Wakeup type Alarm, the CPU will be woken up; the Alarm in the second queue will be triggered at 12min, and because it is a Wakeup type Alarm, the CPU will be woken up; the final number of CPU wake-ups is 2. In the 4-side diagrams corresponding to the optimization, the four sub-diagrams correspond to the following four steps: 1. A non-Wakeup type Alarm is newly added, with a trigger time of 5min-10min; 2. A Wakeup type Alarm is newly added, with a trigger time of 8min-15min. Because the first queue is non-Wakeup type, a new queue is created to store it; 3. A Wakeup type Alarm is newly added, with a trigger time of 12min-20min. Because the first queue is non-Wakeup type and the second queue is Wakeup type, queue 2 is selected to join; 4. When the task is triggered, the Alarm in the first queue is triggered at 5min. Because it contains a non-Wakeup type Alarm, the CPU will not be woken up; the Alarm in the second queue will be triggered at 8min. Also, because it is a Wakeup type Alarm, the CPU will be woken up; the final number of CPU wake-ups is 1. Through the above optimization, the original 2 CPU wake-ups can be reduced to 1.

[0030] (2) Queue trigger time optimization

[0031] In the native mechanism of BatchingAlarmStore, the kernel wake-up time is set according to the start time mStart of the queue that was first triggered by BatchingAlarmStore. One problem with this method is that if a new alarm is added during the start and end time, and the queue has been triggered, it may increase the CPU wake-up. If the kernel wake-up time is changed from the queue's start time mStart to the end time mEnd, it can reduce the CPU wake-up by one, and there is no additional side effect, because the alarm in the queue can be triggered at the end time mEnd. Figure 2The figure shows a comparison before and after the optimization of the queue trigger time. In the left figure corresponding to the period before optimization, the three sub-figures correspond to the following three steps: 1. At the current time point, since mStart has been reached, the Alarm queue will be triggered, and the CPU will wake up at this time; 2. At the current time point, a new Alarm is added, and the trigger time is shown in the figure; 3. At the current time point, since mStart has been reached, the kernel is awakened, the CPU is awakened, and the Alarm in the queue is triggered, and the CPU is awakened once. In the right figure corresponding to the period after optimization, the three sub-figures correspond to the following three steps: 1. At the current time point, although mStart has been reached, our strategy is only triggered when mEnd is reached; 2. At the current time point, a new Alarm is added, and the trigger time is shown in the figure, and the start and end times of the two Alarms are merged; 3. At the current time point, since mEnd has been reached, the kernel is awakened, the CPU is awakened, and the Alarm in the queue is triggered, and the CPU is awakened once. In the figure below, the three sub-figures correspond to the following three steps: 1. At the current time point, although mStart has been reached, our strategy is only triggered when mEnd is reached. Figure 2 In the scenario shown, since the first queue (i.e., Batch) in the native mechanism is triggered once at the start time mStart, and then an Alarm is added, the trigger time of the Alarm is earlier than the end time mEnd of the first Batch, the native mechanism finally wakes up twice. After applying the optimization solution adopted in this embodiment, one wake-up can be reduced.

[0032] Based on the above principle, in this embodiment, the start time mStart of the queue used when waking up the kernel in BatchingAlarmStore is changed to the end time mEnd, which can effectively reduce the number of triggers and thus reduce energy consumption.

[0033] (3) Task-triggered fuzzy alignment optimization

[0034] In the native trigger mechanism of BatchingAlarmStore, when the trigger time is reached, the current system time is compared with the start and end time of the queue.

[0035] The modification made in this embodiment is to advance the start time mStart of the compared queue by a fuzzy time FuzzyTime. The fuzzy time FuzzyTime is only valid for Wakeup type queues. If the compared queue is a non-Wakeup type queue, it is invalid because there is no benefit. The calculation formula of the fuzzy time FuzzyTime is (mEnd-mStart)*FuzzyRatio, where FuzzyRatio represents the proportional coefficient of the fuzzy current queue. The proportional coefficient is obtained according to the current system Doze state (Standard, Light Doze and Deep Doze) and whether the queue contains an Active Standby Bucket. The corresponding relationship is shown in Table 1. That is, the comparison is between the current system time and the start time mStart of the queue minus the fuzzy time FuzzyTime of the queue. If the former is greater than the latter, the queue is triggered. This strategy will not affect the precise queue (there is only a precise Alarm in the queue), because the start and end time periods of the precise queue are 0, and the calculation is still compared with the current system time, so there is no risk of early triggering. Figure 3 The figure shows the comparison before and after the implementation of the task trigger fuzzy alignment optimization. In the left figure corresponding to the optimization, the three sub-graphs correspond to the following three steps: 1. At the current time point, since mStart has been reached, the Alarm queue will be triggered, and the CPU will wake up at this time; 2. At the current time point, since mStart has been reached, the kernel is awakened, the CPU wakes up, and the Alarm in the queue is triggered. The CPU is awakened twice; 3. Finally, the CPU is awakened twice. In the right figure corresponding to the optimization, the three sub-graphs correspond to the following three steps: 1. At the current time point, since mStart has been reached, the Alarm queue will be triggered, and the CPU will wake up at this time; 2. When calculating other Alarms, the calculation of FuzzyRatio will be triggered. Assuming that the current state is DeepDoze and there is no Alarm of the Active class in the Alarm, according to Table 1, the FuzzyRatio coefficient is 40% as a parameter for calculation; 3. Since FuzzyTime is less than the current time, the subsequent Alarms are triggered together, and the CPU finally wakes up once. In the example Figure 3In the scenario shown, the native mechanism can only trigger the precise alarm (i.e., the alarm whose start time is equal to the end time) separately, but because the trigger at one time point is difficult to align with other queues, the first precise alarm and the second queue are awakened separately. In the optimization scheme of this embodiment, the start time mStart of the queue that does not contain the precise alarm (mEnd is greater than mStart) is fuzzy, and the start time mStart is advanced by the time of FuzzyRatio*(mEnd-mStart). It is used for fuzzy alignment with the precise alarm. Therefore, the hit rate of alignment can be greatly improved, and finally one wake-up is reduced.

[0036] Table 1

[0037]

[0038] Based on the above principle, in the specific implementation process, when a queue in BatchingAlarmStore is a precise Alarm (that is, the queue contains only one precise Alarm), the time for waking up the kernel of the adjacent Wakeup type queue behind it is modified from the queue's start time mStart to the queue's start time mStart minus the queue's fuzzy time FuzzyTime.

[0039] Through the above optimization, the time point for judging the queue is fuzzy processed, and a fuzzy time is added to the current time point, thereby reducing the impact of the precise alarm and increasing the possibility of alignment.

[0040] This embodiment can perform special optimization for all alarms, and reduce the number of times the kernel is awakened by optimizing the added matching mechanism, triggering timing, and fuzzy alignment, thereby achieving the purpose of reducing internal friction.

[0041] Embodiment 2:

[0042] The present invention also provides a task optimization terminal device based on Android standby energy saving, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned method embodiment of embodiment 1 of the present invention when executing the computer program.

[0043] Further, as an executable solution, the task optimization terminal device based on Android standby energy saving can be a computing device such as a desktop computer, a notebook, a PDA, and a cloud server. The task optimization terminal device based on Android standby energy saving may include, but is not limited to, a processor and a memory. Those skilled in the art can understand that the composition structure of the task optimization terminal device based on Android standby energy saving is only an example of a task optimization terminal device based on Android standby energy saving, and does not constitute a limitation on the task optimization terminal device based on Android standby energy saving. It may include more or less components than the above, or a combination of certain components, or different components. For example, the task optimization terminal device based on Android standby energy saving may also include input and output devices, network access devices, buses, etc., and the embodiments of the present invention do not limit this.

[0044] Further, as an executable solution, the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the task optimization terminal device based on Android standby energy saving, and uses various interfaces and lines to connect the various parts of the entire task optimization terminal device based on Android standby energy saving.

[0045] The memory can be used to store the computer program and / or module, and the processor realizes various functions of the task optimization terminal device based on Android standby energy saving by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required for a function; the data storage area can store data created according to the use of the mobile phone, etc. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart MediaCard, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0046] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method in the embodiment of the present invention are implemented.

[0047] If the module / unit integrated in the task optimization terminal device based on Android standby energy saving is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory) and software distribution medium, etc.

[0048] Although the present invention has been specifically shown and described in conjunction with the preferred embodiments, it should be understood by those skilled in the art that various changes may be made to the present invention in form and details without departing from the spirit and scope of the present invention as defined by the appended claims, all of which are within the scope of protection of the present invention.

Claims

1. A task optimization method based on Android standby energy saving, characterized in that: include: Change the queue joining mechanism in BatchingAlarmStore, set the Wakeup attribute for the queue in BatchingAlarmStore, and the Wakeup attribute of the queue is consistent with the type of the Alarm in the queue; when a new Alarm needs to be added to the queue, determine whether the Wakeup attribute of the queue it needs to join is consistent with the type of the new Alarm. If consistent, add the queue; otherwise, create a new queue; Change the start time mStart of each queue in BatchingAlarmStore used to wake up the kernel to the end time mEnd of the queue; When a queue in BatchingAlarmStore is a precise alarm, the time for waking up the kernel of the adjacent wakeup type queue behind it is changed from the queue start time mStart to the queue start time mStart minus the queue fuzzy time; the calculation method of the queue fuzzy time is: the product of the difference between the queue end time mEnd and the start time mStart and the proportional coefficient; The proportional coefficient is set according to whether there is an Active Alarm in the queue and the Doze state of the system.

2. The task optimization method based on Android standby energy saving according to claim 1, characterized in that: In the setting of the proportional coefficient, when there is an Active Alarm in the queue and the system Doze state is Standard, set the proportional coefficient to 0%; when the system Doze state is Light Doze, set the proportional coefficient to 10%; when the system Doze state is Deep Doze, set the proportional coefficient to 20%.

3. The task optimization method based on Android standby energy saving according to claim 1 is characterized in that: In the setting of the proportional coefficient, when there is no Active Alarm in the queue and the system Doze state is Standard, the proportional coefficient is set to 0%; when the system Doze state is Light Doze, the proportional coefficient is set to 20%; when the system Doze state is Deep Doze, the proportional coefficient is set to 40%.

4. A task optimization terminal device based on Android standby energy saving, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and running on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 3 when executing the computer program.

5. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method as claimed in any one of claims 1 to 3 are implemented.

Images