Power consumption optimization practice of Douyin

Author: Gaoyuan Tang Zhongfeng

Power consumption optimization is an important topic in application experience optimization. High power consumption can cause users to have power anxiety and lead to a bad heating experience, which reduces users' willingness to use the product. Power consumption is a comprehensive and complex indicator involving the entire device for a long time and multiple scenarios, and is affected by many factors. Whether it is the quantitative analysis of power consumption, the monitoring of abnormal problems, or the active optimization of power consumption, it is very challenging for developers.

This article combines the power consumption optimization practice of Douyin to produce some experimental conclusions and optimization ideas. It summarizes the power consumption optimization of Android applications from several aspects, including the basic knowledge of power consumption, power consumption composition, power consumption analysis, and power consumption optimization.

Introduction to the basics of power consumption

First, let's review the concept of power consumption, which is easy to confuse with energy consumption. Let's explain why mobile phones use mA (current value) to represent power consumption levels and mAh (charge value in physical terms) to represent energy consumption levels. Let's first look at a few physical formulas.

P = I × U, E = P × T

• Energy consumption (E): energy loss, which refers to the total energy consumption of a computer system over a period of time, measured in joules (J)
• Power consumption (P): also known as power loss, refers to the energy consumption per unit time, reflecting the rate of energy consumption, the unit is watt (W)
• Current (I): refers to the current value of the mobile phone battery discharge, and the mobile phone usually uses mA as the unit
• Voltage (U): refers to the voltage value of the mobile phone battery discharge. The standard discharge voltage is 3.7V, the charge cut-off voltage is 4.35V, and the discharge cut-off voltage is 2.75V (using typical values ​​as an example, the battery voltage values ​​of different devices are different)
• Battery capacity: The commonly used unit is mAh, which is the number of charges in a unit sense, and actually represents the length of time the battery discharges at a typical voltage.

As shown in the power consumption test chart below, mobile phones usually operate at a constant typical voltage. For the convenience of calculation, the voltage is kept constant at 3.7V, then P = I × 3.7, E = I × 3.7 × T, that is, mA is used to represent power consumption and mAh is used to represent energy consumption.

Summary: For the same model, we use the change of battery capacity (mAh) to represent the total energy consumption over a period of time, and use the average current (mA) to represent the power consumption level; for example, a mobile phone with a 4000mAh battery consumes 11% of its power when using Douyin for 1 hour, with a power consumption (energy consumption) of 440mAh and an average current of 440mA.

Figure 1. Power consumption test diagram

Why do we need to optimize power consumption?

From the abstract, we have learned that high power consumption can cause users to have power anxiety and lead to a bad heating experience, thus reducing users' willingness to use the app. In addition to providing us with a better user experience and increasing user usage time, optimizing power consumption also has obvious social value. To use a popular term, it can contribute to the cause of carbon neutrality.

How to optimize power consumption

Different from common APM indicators such as Crash and ANR, power consumption is a comprehensive topic, and it is easy to be confused when analyzing it. Users have reported power consumption issues, which may be caused by high CPU load, frequent network access in the background, or animation leakage leading to high power consumption. Or our own business has not changed much, and it is simply the environmental factors that cause users to feel power consumption, such as lithium battery discharge attenuation caused by low temperature.

Our idea is to start from the device. The power consumption of the application can eventually be decomposed into the power consumption of the mobile phone devices, so we first break down the device power consumption of Douyin to see which devices are the main power consumers, and then see how to reduce the use of devices, so that we can be targeted.

Next, we will talk about how to carry out power consumption optimization from the aspects of power consumption composition, power consumption analysis, and power consumption optimization.

Power consumption

Here are the basic forms of mobile phone hardware, and each module is composed of complex devices. For example, the SoC, which is often called the power-consuming part, includes the super-large core, large core, small core, GPU, DDRC (memory interface), and various small IP cores in the peripheral area. Therefore, the power consumption of the whole machine can be finally broken down into the power consumption of each device, and the power consumption of the application is to calculate the power consumption generated by the devices it uses.

Taking the feed stream scene of Douyin as an example, we performed a device-level power consumption analysis of Douyin under the conditions of fixed brightness of 120nit, 7-level volume, and WiFi network. It can be seen that the power consumption of Douyin's feed is mainly concentrated in four modules: SOC (CPU, GPU, DDR), Display, Audio, and WIFI.

Device power consumption calculation

So how is the power consumption of these devices broken down? The principle is: first break down the power consumption factors of the device, establish a device power consumption model, and get a calculation formula for the device power consumption. By counting the usage data of the device at runtime and substituting it into the power consumption model, the power consumption of the device can be calculated. The power consumption of the application is allocated from the total power consumption of the device according to the comparison of application usage, so that the power consumption of the application device is obtained. Since there are many power consumption factors that affect the power consumption of the device, the complexity here is how to break down and model the power consumption factors. With accurate modeling, the next step is the process of manufacturer adaptation and calibration parameters.

Google provides a set of general device power consumption models and configuration solutions. OEM manufacturers can calibrate and configure parameters of their products according to the general solutions. As shown in the power consumption configuration in AOSP in the figure below, take the power consumption calculation of Wifi as an example. https://source.android.com/devices/tech/power/values

The modeling scheme provided by Google is to calculate the power consumption of WIFI in different states. The power consumption of WIFI in different states is very different. It is divided into wifi.on (corresponding to the benchmark current when wifi is turned on), wifi.active (corresponding to the benchmark current when wifi is transmitting data), wifi.scan (corresponding to the benchmark power consumption of a single wifi scan), and the power consumption of wifi data transmission (controller.rx, controller.tx, controller.idle). The power consumption of wifi is calculated based on the data sent and received by wifi. By counting the duration or number of these states and multiplying them by the corresponding current, the power consumption of the wifi device is obtained.

Since Google designs the device power consumption model based on universality, it can usually only roughly calculate the power consumption level of the device, and the error may be large for a specific product. Each OEM manufacturer usually has a power consumption statistics solution based on its own hardware, which can make a more detailed and accurate calculation of power consumption. Here we use wifi as an example: OEM manufacturers can model separately according to 2.4G and 5GWIFI, introduce the reference current change corresponding to the change of antenna signal, and count the frequency and duration of the wifi chip working, refine the model by frequency, etc. OEM manufacturers can design a more accurate power consumption model that is more suitable for their own equipment and calculate more accurate wifi power consumption. This depends on the hardware solution of the specific product.

Power consumption analysis

Through the above introduction to power consumption components, we can see that there are many factors that affect power consumption. When doing application power consumption analysis, we must have a method to accurately evaluate the power consumption level of the application and a method to decompose the power consumption components to find optimization points. The following is divided into two parts: power consumption evaluation and power consumption attribution analysis.

Power consumption evaluation

As mentioned in the previous article on power consumption basics, we use current values ​​to evaluate the power consumption level of applications. In offline scenarios, we control test conditions (such as fixed test model version, background cleaning, fixed brightness, volume, stable network signal conditions, etc.) to measure reliable and accurate current values ​​to evaluate the front-end and back-end power consumption of applications. In online scenarios, due to the complexity of user usage scenarios when the application exits the background (referring to the different foreground applications run by users), we only collect the current of the entire foreground machine for online version monitoring, and use other indicators, such as background CPU usage, to monitor the background power consumption. Below we introduce some commonly used power consumption evaluation methods.

PowerMonitor

At present, the most common way to evaluate the power consumption of the whole machine in the industry is to use PowerMonitor to connect an external power meter to collect current at high frequency and high precision for evaluation. It is often necessary to confirm the power consumption in detail, especially the current output in the background static state, screen off state, etc., manufacturer's access test, etc. The commonly used PowerMonitorAAA10F of Mosoon has a current range of 1uA to 6A, a current accuracy of 50uA, and a sampling period of 200us (5KHZ).

Battery Fuel Gauge

Although PowerMonitor has the most accurate measurement results, it is troublesome to disassemble the device. We can also directly read the statistical results of the battery meter through the interface provided by Google BatteryManager to obtain the current value.

The battery fuel gauge is responsible for estimating the battery capacity. Its basic functions are to monitor the voltage, charge/discharge current and battery temperature, and estimate the battery state of charge (SOC) and the battery's full charge capacity (FCC). There are two typical fuel gauges: voltage-type fuel gauges and current-type fuel gauges. The fuel gauges currently used in mobile phones are mainly current-type fuel gauges.

• Voltage type fuel gauge: Simply put, it detects the current voltage, then queries the voltage-battery capacity correspondence table to obtain a power estimate
• Current-type fuel gauge: Also called a coulomb meter, the principle is to connect a detection resistor to the battery's charge/discharge path. The ADC measures the voltage on the detection resistor and converts it into the current value of the battery being charged or discharged. The real-time counter (RTC) provides the current value to be integrated over time to know how many coulombs have flowed.

Android provides a BMS interface, which provides battery meter statistics through attributes.

• BATTERY_PROPERTY_CHARGE_COUNTER Remaining battery capacity in microampere hours
• BATTERY_PROPERTY_CURRENT_NOW Instantaneous battery current in microamperes
• BATTERY_PROPERTY_CURRENT_AVERAGE Average battery current in microamperes
• BATTERY_PROPERTY_CAPACITY The remaining battery capacity, displayed as an integer percentage
• BATTERY_PROPERTY_ENERGY_COUNTER Remaining energy in nanowatt hours

 import android.os.BatteryManager;
 import android.content.Context;
 BatteryManager mBatteryManager = (BatteryManager)Context.getSystemService(Context.BATTERY_SERVICE);
 Long energy = mBatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);
 Slog.i(TAG, "Remaining energy = " + energy + "nWh");

Take the Nexus 9 below as an example. This model uses the MAX17050 current-type fuel gauge with a resolution of 156.25uA and an update period of 175.8ms.

From the practical results, different mobile phones use different power meters, resulting in different units of current values ​​directly read out, so data conversion is required. In order to simplify the acquisition of battery data, we developed the Thor SDK, which only retains the collection process of indicators such as current, voltage, and power, and normalizes the data for different models. Users do not need to worry about the internal implementation, but only need to provide the data type and sampling period to return the required power consumption-related data regularly. We used Thor to compare PowerMonitor to verify data consistency, and the error was <5mA, meeting the needs of online monitoring.

In addition, we studied the power consumption impact of the Thor acquisition function itself. We can see that when the data is collected once per second, the average current increases by 0.59mA. Therefore, the power consumption impact of this solution is very low and it is suitable for online current collection.

Manufacturers’ own power consumption rankings

Power consumption ranking

The power consumption rankings provided by manufacturers can also be used to view the power consumption of applications over a period of time. For example, in the Huawei power consumption ranking below, the power consumption of hardware and software is separated, and the specific power consumption of applications is given. Other manufacturers OV also support specific power consumption, while Xiaomi only provides power consumption percentage and does not provide specific power consumption.

Access: Settings->Battery->Power Consumption Ranking

Power consumption attribution

From the power consumption evaluation, we can determine the overall power consumption of the application, but to determine the cause of high power consumption in a specific case, we need to select different tools for analysis. Currently, the tools that can be directly attributed to business code are mainly CPU-related tools, which is also the main direction of our current problem analysis. In the future, we will also build capabilities such as traffic attribution. Below I list the commonly used analysis tools.

Battery Historian

The analysis tool officially provided by Google requires first performing a power consumption test, then grabbing the bugreport.zip through adb, and then opening it through the web tool to provide coarse-grained power consumption attribution.

Essentially, it displays various service statistics in systemserver + phone status + kernel statistics (kernel wake-up). The estimation of application power consumption depends on the power_profile.xml configured by the manufacturer. It is more suitable for attributing power consumption issues of the entire machine, such as attributing high power consumption to a certain application.

For a single application, since the statistics of wakelock, alarm, gps, job, syncservice, background service running time, etc. are relatively detailed, it is more suitable for attributing background power consumption. For network anomalies and CPU anomalies, only high consumption can be seen, and it cannot be attributed to specific services. https://developer.android.com/topic/performance/power/setup-battery-historian?hl=zh-cn

AS Profiler

Compared to BatteryHistorian, which requires manual testing first and then adb capture, the Profiler that comes with AS provides a visual display of Energy. Using the debug version of the application, you can intuitively see the power consumption, which facilitates offline testing. It should be noted that the power consumption value displayed here is a fitting value calculated by GPS+network+CPU, not the actual power consumption value, but only represents the power consumption level.

Profiler simultaneously displays CPU usage, network power consumption, and memory information. It supports CPU and thread-level tracing. By actively recording traces, you can analyze the CPU usage of each thread and time-consuming functions. For easily reproducible CPU high load problems or time-consuming problems in fixed scenarios, this method can easily see the root cause. However, the trace display method is not suitable for occasional high CPU loads, and the large amount of information makes it difficult to grasp the key points.

Network Power Consumption can easily capture the upstream and downstream network requests, display the API details of the network requests, and divide them into threads. For frequent network access, it is easy to find the problem point. However, it currently only supports network requests through HttpURLConnection and OkHttp. If other network libraries are used, Profiler cannot track them.

You can see that the official tool has relatively complete functions, but it only supports the analysis of debug version apps. If you want to analyze the release version of apps, you need to use a rooted phone. In general, Profiler is more suitable for offline analysis of a fixed business scenario. https://developer.android.com/studio/profile/energy-profiler

Thread pool monitoring

It is possible to use the above tools to monitor CPU exceptions of a single thread. However, it is not easy to attribute asynchronous tasks such as thread pools, Handlers, AsyncTasks, etc. to specific businesses, especially the thread pools of network libraries. Since the executed network request logic is the same, it is not possible to attribute it to specific businesses just by capturing the thread stack. It is necessary to count the source code of the submitted task to find the real problem point.

We can use various mechanisms, such as thread pool modification and Java hook, to record and aggregate the task submitters in detail, which can help us analyze the time-consuming tasks in the thread pool.

Online CPU abnormality accurate monitoring

In addition to offline CPU analysis, when we are building online CPU exception monitoring, we consider that simply using the CPU usage threshold cannot accurately determine whether the process is in a CPU exception. For example, different CPU models have different performances, and the usage rate on some low-end CPUs is relatively high. For example, the system has different temperature control strategies and power saving strategies, which will limit the frequency of the mobile phone and migrate the CPU core of the task. In this case, the application will also have a higher CPU usage rate.

Therefore, we make precise judgments on the CPU usage threshold based on different variable factors (such as CPU model, CPU time of processes/threads on different cores, distribution of different frequencies, charging, power, memory, network status, etc.), and formulate refined CPU exception thresholds for different scenarios, different devices, and different businesses, thereby achieving high-precision CPU exception capture.

In addition, there are some attribution frameworks in the industry, which will not be introduced in detail here.

• Facebook BatteryMetrics: Collects data from multiple attribution points such as CPU/IO/Location. It is similar to the statistical behavior of the system BatteryStatsService and focuses on offline app power consumption evaluation and device decomposition.
• WeChat BatteryCanary: Provides thread and thread pool attribution capabilities. Compared with other tools, it adds statistics for foreground and background, screen on and off, charging and discharging, and foreground service statistics.

Power Optimization Practice

The above introduces the composition of power consumption and how to analyze the power consumption of our applications. Here we give an overall introduction to power consumption optimization. We expand the optimization ideas from the perspective of devices and list our optimization ideas and measures to reduce the use of devices and thus reduce power consumption. In addition, for some user-perceivable degradation of lossy services, we use low-power mode to alleviate users' power anxiety through more aggressive degradation methods when the battery is low, which increases the user's usage time.

The figure below lists the optimization ideas for each device. Some optimization ideas will benefit multiple devices. There is no particularly detailed distinction here, and they are divided into the main affected devices. For example, reducing the refresh area will benefit the GPU, CPU, and DDR. The main benefit is in GPU drawing, which is listed on the GPU in the figure below.

At the same time, we have listed some optimization solutions on the manufacturer's side, which applications usually do not need to pay attention to, such as reducing the screen refresh rate, TP scanning frequency, and low resolution of the whole machine. This can be more fine-tuned through cooperation with manufacturers, such as dynamically adjusting the screen refresh rate by scene, using 90HZ high refresh in the search list scene, and reducing the refresh rate to 30HZ in the short video scene in combination with frame rate alignment to obtain a more balanced power consumption and performance experience.

DISPLAY

The optimization of display power consumption is mainly achieved by downgrading or reducing the processing of devices such as screens, GPUs, CPUs, video decoders, TPs, etc., and using hardware processing as much as possible. For the screen, it mainly reduces the brightness, refresh rate, TP scanning frequency, etc.

Screen brightness

Screen brightness is the biggest source of screen power consumption. Brightness and power consumption are almost directly proportional, see the figure below:

It can be seen that whether it is an IPS screen or an OLED screen, as the screen brightness increases, the power consumption increases almost linearly. For OLED screens, white content consumes more power, while dark content consumes less power. The common way to reduce the brightness of an application is to actively reduce the brightness after entering the application, or use a dark UI mode to achieve the effect of reducing the screen brightness. Manufacturers will reduce the screen brightness through FOSS or CABC solutions.

Dark Mode

Based on the principle of the AMOLED screen itself, black has the lowest power consumption, so darker theme colors can be used as much as possible, ultimately achieving lower power consumption and allowing users to use the screen for longer.

Why does an AMOLED screen consume less power when displaying a black interface? This can be explained by the difference in the light-emitting principle between it and the traditional LCD screen.

LCD backlight display mainly relies on the backlight layer. The light-emitting layer is composed of a large number of LED bulbs, which display white light, and the polarization control of the liquid crystal layer displays RGB colors. In this case, black is no different from pixels of other colors. Although it does not look bright, it is still in a state of emitting light.

AMOLED screens don't have backlights at all. Instead, each small sub-pixel only emits a weak RGB light. If the screen needs to display black, it only needs to adjust the voltage to rotate the liquid crystal molecules to block the backlight to achieve the black effect, without lighting up any additional colors.

The following is a comparison of power consumption in color and black modes under different scenarios using the test application Reddit Sync. (Reference link: https://m.zol.com.cn/article/4895723.html#p4)

From the chart above, we can clearly see that in the case of a black background, the AMOLED screen consumes much less energy than a normal color background. In the Reddit Sync test, the average power consumption is reduced by about 40%.

The app can design its own dark mode theme and synchronize the dark mode switch of the mobile phone system. Currently, there are two modes for the background setting of Douyin as shown in the figure below. You can see that the classic mode is the dark mode, which corresponds to the dark theme. This can also be combined with the dark mode of the mobile platform.

FOSS

FOSS (Fidelity Optimized Signal Scaling) is a low-power solution for AMOLED screen adjustment provided by chip manufacturers. The corresponding solution on LCD screen is CABC (Content Adaptive Brightness Control). On the one hand, the screen brightness is reduced, and on the other hand, the grayscale value of the displayed content is adjusted, so that the display effect is not much different. Since the screen brightness is reduced, the power consumption gain is relatively large. Generally, it is about 0.2 hours, which means that the average use time of the mobile phone can be extended by about 0.2 hours.

It is known that the manufacturer's FOSS solution may cause discoloration or flickering in some scenes under certain parameters. If you encounter an unconfirmed flickering problem and cannot confirm the cause through internal positioning, you can consult with the manufacturer to eliminate it.

Lower refresh rate

At present, some mobile phones on the market support 60HZ, 90HZ, 120HZ, 144HZ, etc. High refresh rates bring improved fluency and better user experience, but higher power consumption. Generally speaking, in system application interfaces such as desktops and settings, the refresh rate will be consistent with the current system settings, while in specific applications, the refresh rate will be adjusted according to different scenarios. For example, Douyin, even on a high-refresh screen, the platform system generally chooses to let Douyin run at a 60HZ refresh rate, which is relatively low in power consumption.

PhoneArena has made some reference data to verify this point of view. They selected four products from two brands, all of which are high refresh rate models, and tested 60Hz and 120Hz refresh rates under the same conditions. The results show that the battery life of mobile phones at 120HZ refresh rate is indeed at least 10% shorter than that at 60HZ. Even the OnePlus 8 that supports 90Hz is worse than the 60HZ refresh rate.

Image source: https://www.sohu.com/a/394532665_115511

Reduce TP scanning frequency

Usually, in order to improve the click response speed in games, the TP scanning frequency will be increased, and the default scanning frequency will be used in other scenes. Douyin generally uses the default TP scanning frame rate.

GPU

The optimization idea of ​​GPU is mainly to reduce unnecessary drawing or reduce the drawing area, which is reflected in lower resolution, lower frame rate, fewer drawing layers, etc. In addition, video applications use SurfaceView instead of TextureView, which also has significant power consumption benefits. For complex calculations, we can choose devices with higher energy efficiency, such as using hardware drawing instead of software drawing, and using NPU instead of GPU to execute complex algorithms, which significantly reduces the overall power consumption.

Lower the resolution

Apply low resolution

Usually, games and specific applications run at a lower resolution in this mode. The size of the GPU drawing area and transmission area is reduced, and the power consumption of the GPU, CPU, and DDR transmission is reduced. The power consumption benefit is relatively large in the game scene. In offline tests on specific platforms, 1080p->720p is about 20mA, and 1440p->720p is about 40mA.

The principle is as follows: the application layer is drawn at a low resolution, enlarged to the screen resolution through the HWC channel, and synthesized with other layers before being displayed.

This function is usually set on the platform side. Non-gaming applications do not need to pay attention to it. Gaming applications can choose to set a low resolution themselves.

Some games, such as Tencent games (such as QQ Speed, Honor of Kings and Game for Peace), also have different resolution settings and run at low resolution by default, which can achieve lower power consumption.

Low resolution of the whole machine

All applications run at low resolution. The GPU drawing area and transfer area size are also reduced, reducing the power consumption of GPU, CPU and DDR transmission. The power consumption benefit is the same as the low resolution of the application, and ordinary applications also have power consumption benefits in this mode. Users switch from the system settings menu, and the application itself usually does not need to pay attention.

The principle is as follows: all layers are drawn at low resolution and synthesized at low resolution. After synthesis, they are enlarged to the screen resolution at one time by the scaler and then sent to the display. The scaler is the scaling hardware provided by the chip platform.

Reduce refresh area

The application layout animations are close in position, and a smaller area is laid out, with the smallest drawing area and refresh area, thus minimizing power consumption. Different scenarios have different benefits.

As shown in the two cases below, you can see that in the left picture, there are 3 animation areas (red framed areas), and the final Dirty area is a large red frame area with a larger area. In contrast, in the middle picture, the two red animation areas, after calculation, the Dirty large red frame area is smaller, and the GPU drawing area and refresh transmission area are both smaller, so relatively speaking, the power consumption is lower. From the power consumption data chart on the far right, it can be seen that the benefits are greater.

You can turn it on in the developer options: Settings -> Developer Options -> Show GPU view updates. When the refresh range is obviously inconsistent with the animation range, the animation layout is unreasonable. In this case, you need to analyze the writing problem at the code level and modify it.

Reduce drawing frequency

Usually used in games or application animations, it can reduce the GPU drawing frequency and subsequent refresh frequency. By reducing the animation drawing frequency, the power consumption of GPU, CPU and DDR can be reduced.

The power consumption at different frame rates is compared as follows. It can be seen that the power consumption at low frame rates is significantly lower than that at high frame rates.

In the Douyin application, low drawing frame rate can be achieved by actively reducing the frame rate of animations, etc. in Douyin. Reducing the frame rate in the music turntable animation and note animation in the Douyin recommendation interface can significantly reduce power consumption. In addition, 30HZ drawing can also be achieved through soft vsync provided by the manufacturer. Douyin cooperates with manufacturers in this part. SurfaceFlinger controls APP vsync. When the frame is reduced, the SurfaceFlinger vsync output is reduced to 30fps. Under certain conditions, the frame rate is actively reduced to extend the usage time.

Frame rate alignment

In the Douyin recommendation page, the entire interface can be drawn and refreshed at 30HZ by synchronizing the video and the animation after reducing the frequency. Otherwise, if the video 30hz and the animation 30 frames are staggered, the final drawing/refresh frequency is still 60 frames, which is not optimal. We adjusted the drawing process of various animations and aligned the overall drawing of the animation, which significantly reduced the overall frame rate.

Reduce overdraw

Overdraw describes that a pixel on the screen is drawn multiple times within the same frame. In a multi-layer overlapping UI structure, if the invisible UI is also drawing, some pixel areas will be drawn multiple times, which will also waste a lot of CPU and GPU resources.

You can debug overdraw as follows: open your phone, go to Settings -> Developer Options -> Debug GPU Overdraw -> Show GPU Overdraw. Overdraw will cause unnecessary resources to be wasted when the interface is displayed to render invisible backgrounds, or draw certain pixel areas multiple times, which will cause the interface to load or slide unsmoothly or drop frames, which means that the app is particularly stuck in terms of user experience. In order to improve the user experience and the smoothness of the application, it is still necessary to optimize overdraw.

The over-drawing of Douyin's feed page is very serious, with 5 layers of over-drawing. The left side of the picture below shows the transition drawing before optimization, and the right side shows the over-drawing after optimization. It can be seen that there is a significant improvement after optimization.

Using SurfaceView to play video

TextureView and SurfaceView are the two most commonly used video playback controls. The TextureView control is located on the main layer. The decoder passes the video frame to the TextureView object, which requires the GPU to draw it once before it can be displayed on the screen. Therefore, it consumes more power, more memory, and has a higher CPU occupancy.

The differences in control positions are as follows. It can be seen that SurfaceView has an independent Surface located on a separate layer, while TextureView is located on the main layer.

BufferQueue is the core of Android graphics architecture, with producers on one side and consumers on the other. From this perspective, the differences between SurfaceView and TextureView are as follows. It is easy to see that SurfaceView has a shorter process, uses less memory, and has no GPU drawing, so it saves more power.

Here are some revenue data after replacing TextureView with SurfaceView:

• From the CPU data, SurfaceView is 8%-13% better than TextureView.
• From the power consumption data, SurfaceView consumes about 20mA less than TextureView on average.

Hardware drawing and software drawing

Hardware rendering refers to rendering through the GPU. Android has supported hardware accelerated rendering since 3.0. It is much more efficient than software rendering in terms of UI display and rendering, but the GPU power consumption is relatively high. It is currently the default rendering method of the system.

Software drawing refers to drawing through the CPU. Android uses the Skia graphics library for drawing. See the figure below for the difference between the two.

Currently, hardware acceleration is enabled by default. You can specify software drawing by setting Activity, Application, Window, View, etc. If your application needs to specify software drawing for certain scenes, you need to evaluate performance, power consumption, etc. Reference link: https://developer.android.com/guide/topics/graphics/hardware-accel

NPU replaces GPU for complex algorithms

The newer SoC platforms now have NPU chips dedicated to AI computing. Using NPU instead of GPU to run some complex algorithms can effectively save GPU power consumption. For example, the super-resolution algorithm of video can bring a good experience to users. However, super-resolution has a great impact on GPU power consumption. In some platform tests, the power consumption of the whole machine can be 100mA higher. Choosing to replace GPU with NPU is an optimization method.

CPU

CPU optimization is the most common in power optimization. Most of the CPU anomalies we encounter are caused by dead loops. Using the power attribution tool introduced above, you can easily find the dead loop problem. In addition, high-frequency time-consuming functions have similar effects to dead loops. They can easily make the CPU core run at high frequencies, resulting in increased CPU power consumption. Another typical CPU problem is animation leakage. Leaking animation can increase power consumption by about 20mA.

Since the CPU consumes a lot of power, most mobile phone platforms will add various low-power DSPs to share the CPU's work and reduce power consumption. For example, for common video decoding, using hardware decoding will have better power consumption performance.

CPU High Load Optimization

Dead loop management

Dead loop is the most obvious CPU anomaly we encounter, usually manifested as a thread occupying a large core. When the thread usage reaches 100%, the phone will easily heat up and freeze.

Here is an example of an actual fixed infinite loop. In a code logic for cyclically packaging logs, the loop will be broken only after all logs are packaged. When an exception occurs in the db query, the exception handling branch does not break, resulting in an infinite loop.

 // The method logic has been trimmed, only the main logic is posted
 private JSONArray packMiscLog() {
 do {
 ......
 try {
 cursor = mDb.query(......);
 int n = cursor.getCount();
 ......
 if (start_id >= max_id) {
 break;
 }
 } catch (Exception e) {
 finally
 safeCloseCursor(cursor);
 }
 } while (true);
 return ret;
 }

Regarding the management of endless loops, we have summarized several common endless loop routines based on the actual problems we have solved.

 // Boundary conditions are not met, cannot break
 while (true) {
 ...
 if (shouldExit()) {
 break
 }
 }

 // Improper exception handling leads to an infinite loop
 while (true) {
 try {
 do something;
 break;
 } catch (e) {
 }
 }

 // Improper message processing causes the Handler thread to die.
 void handleMessage(Message msg) {
 //do something
 handler.sendEmptyMessage(MSG)
 }

Governance of high-frequency and time-consuming functions

In addition to the dead loop problem, another common problem we encounter is high-frequency time-consuming functions. By monitoring CPU anomalies online, we also found many points that can be optimized, such as the time consumption of the md5 compression algorithm, the unreasonable use of regular expressions, and the time consumption of using cmd to execute system commands. This kind of case-by-case repair has very good benefits.

Standardized use of background resources

Standard use of Alarm, Wakelock, and JobScheduler

The most common background CPU power consumption is the unreasonable use of background resources. Frequent alarm wakeups, long-term non-release of wakelock, and frequent execution of JobScheduler will keep the CPU awake, causing background power consumption. This behavior can easily lead the system to judge that the application is abnormally power-consuming in the background, and it will usually be cleaned up by the system or a high power consumption reminder will be issued.

We can view relevant statistical information through dumpsys alarm & dumpsys power & dumpsys jobscheduler, or analyze our own usage through BH background statistics.

With reference to Green Alliance's power consumption standard, the screen-off alarm should be triggered less than 12 times/h, that is, once every 5 minutes. Once every 5 minutes can ensure the survival of long links under data services. The manufacturer's background power consumption optimization will usually force the alarm to be triggered once every 5 minutes.

Partial wakelock in the background is usually restricted, and non-perceptible scenes (music, navigation, sports, etc.) will be forced to release the wakelock by the manufacturer. According to the Green Alliance standard, the cumulative lock is less than 5 minutes per hour when the screen is off. From practical experience, partial locks for more than 1 minute will be marked as long wakelocks. If the application has no perceptible business in the background and frequently locks, causing the system to be unable to sleep, the system will trigger forcestop cleaning.

For some scheduled tasks, JobScheduler can be used instead of Alarm. The advantage of Job is that it can combine multiple trigger conditions and choose the most appropriate time for the system to schedule its own background tasks. It is recommended to use charging + network available state to handle your own background tasks, which is the best experience for power consumption. If it is not in a charging scenario, setting conditions to trigger jobs frequently will also cause power consumption problems. It is worth mentioning that the Job must be terminated in time after execution. Because JobScheduler will hold a wakelock starting with *job/* during execution, and the maximum execution time is 10 minutes. If it is always in the execution state and does not end, it will cause the system to be unable to sleep.

Video hardware decoding replaces software decoding

Hard decoding is usually used to decode the hardware decoder built into the mobile phone platform to achieve video playback. The hard decoding speed based on dedicated chips is fast and the power consumption is low; in terms of soft decoding, FFMPEG's built-in H.264 and H.265 software decoding libraries are usually used for decoding.

The following table shows the power consumption of Samsung and Apple phones in the case of soft and hard solution respectively. It can be seen that the hard solution power consumption is significantly lower than the soft solution power consumption. Currently, Douyin uses hard solution by default.

Image source: http://www.noobyard.com/article/p-eedllxrr-qz.html

NETWORK

Network power consumption is an important part of application power consumption. The transmission and reception of a data packet will simultaneously pull the CPU and Modem/WIFI systems. Due to the CDRX characteristics of LTE (i.e., there is no data packet reception, it maintains an activation state for a certain period of time, and then goes to sleep, relying on operator configuration, usually 10 seconds), batch network access and reducing frequent network wake-ups are very helpful for network power consumption. In addition, optimizing compression algorithms to reduce data transmission also reduce network power consumption based on the basis.

In addition, network requests under weak signal conditions will increase the power of the antenna and trigger frequent network searches, resulting in higher network power consumption. Network request scheduling is carried out according to network quality and pre-caches network resources in advance, which can reduce network power consumption.

Long link heartbeat optimization

For the backend PUSH of the application, using the manufacturer's stable push link to replace its own long link can reduce power consumption. If it cannot be replaced, the long link keeps alive heartbeat can also be optimized and the heartbeat can be dynamically adjusted according to different network conditions. According to experience, it is usually 5 minutes for data services, and it is usually 20 minutes or more under WIFI networks.

Douyin optimizes the heartbeat for long links, and enters the background with a long link heartbeat time interval [4min, 28min], and the initial heartbeat is 4min. The dynamic heartbeat test strategy is adopted, and each step is 2min to determine the maximum heartbeat interval.

Doze mode adaptation

Since the system has multiple network restrictions for background applications, the most common one is Doze mode. After the mobile phone has been deactivated for a period of time, it will enter doze, restrict non-whitelist applications from accessing the network, and lift the restrictions during the window period. The window period is 30 seconds free of every 10 minutes. Therefore, before network access in the background, you should pay special attention to making judgments on the availability of the network, and choose the window period for network access to avoid wasting CPU resources due to being restricted.

Here is an example of power consumption in the background that Doze is not adapted. Users reported that Douyin has not been used in the foreground since the last time the phone was fully charged (24h), and the power consumption accounts for 31%. Analysis logs found that during the Doze restriction network, polling will be triggered to determine whether the network will recover in time. This logic does not adapt to Doze's window mode in the background, resulting in CPU power consumption caused by frequent attempts to network requests in the background.

AUDIO

Lower volume

The power consumption of audio is ultimately reflected in both Codec and SmartPA (power amplifier connected to the speaker). The most obvious thing to reduce Audio power consumption is to reduce the volume of audio, which is directly reflected in the loudness of the speaker.

Testing with 0-15 levels of volume, we can see that the volume has a huge impact on power consumption, especially after more than 10, the overall increase is very huge. Each level almost increases by a percentage of power consumption.

• 10-15:1:30ma
• 5-10:1:1.62ma
• 0-5:1:1.36ma

Adjust audio parameters

Since users have a clear feeling about volume, directly reducing the volume globally will bring a bad experience. Manufacturers usually design different audio parameters for different scenes, such as movie scenes, game scenes, navigation scenes, and dynamically adjust the high and low frequency configuration parameters of the audio, taking into account the effects and power consumption.

From this perspective, you can choose to cooperate with manufacturers to finely adjust audio parameters according to the content of the video played. For example, the movie clip type video uses the parameters of the movie scene, and the game video is switched to the configuration parameters of the game scene, so as to achieve the purpose of users to adjust the volume without any sense of the sound.

CAMERA

Camera is a big power consumer, especially high resolution and high frame rate recording, which will bring fast power consumption and temperature rise. After offline calculations, Camera's power consumption is 200mA+ in the on-site scene, accounting for more than 25% of the entire machine.

The idea of ​​optimizing Camera power consumption is mainly from the perspective of business downgrade, such as reducing the recording resolution, reducing the recording frame rate, etc. Previously, Douyin live broadcast and production end used 30 frames, but in the end, only 15 frames were used. The acquisition frame rate was actively lowered at the opening end, and the frame rate was set to 15 frames as needed, which significantly reduced the power consumption by 120ma.

SENSOR

The typical power consumption of sensor is very low, such as the typical power consumption of accelerometer we commonly use is only 180uA. However, the enablement of sensor will cause the CPU to wake up and load increase, especially when the application is back in the background. The abuse of sensor will significantly increase the standby power consumption. You can turn off unnecessary sensors at low power to reduce power consumption.

GPS

Accuracy, frequency, and interval are the three main factors affecting GPS power consumption. Among them, accuracy affects the working mode of positioning, frequency and interval affects the working duration. We can reduce GPS power consumption by optimizing these three.

Reduce accuracy

Android native positioning provides two modes: GPS positioning and network positioning. GPS positioning supports offline positioning, relying on satellites, positioning can be done without a network, with high accuracy, but high power consumption. Because it is necessary to enable the GPS positioning module in mobile devices, it will consume more power.

Network positioning (network positioning), fast positioning speed. As long as the network or base station requirements are met, instant positioning can be achieved anywhere, which is also met indoors; it consumes small power and consumes small power; but the positioning accuracy is poor and easy to be disturbed, and the positioning quality is poor in the base station or where there are small WiFi and weak signals, or it is impossible to locate; you must connect to the network to achieve positioning.

We can actively use low-precision network positioning when meeting the positioning requirements to reduce positioning power consumption. When Douyin enters the low-power mode, GPS is downgraded to network positioning and expands the positioning interval.

Reduce frequency & increase interval

In addition to actively controlling the frequency and interval in the business, it is also recommended to use the positioning service of the manufacturer. In order to optimize positioning power consumption, overseas GMS and domestic manufacturers have provided location service SDKs, which are essentially managed by system services, and dynamically adjust according to the power, signal, and the requesting party's delay accuracy requirements to achieve the balance between power consumption and positioning requirements. It provides low-power positioning capabilities such as passive positioning updates, obtaining the location information of the latest positioning, batch background position requests, etc.

Low power mode

Some of the above optimization measures have been implemented under normal scale. However, some of them are harmful to the user experience. We choose to do it in low-power scenarios to reduce power consumption, reduce user's battery anxiety, and obtain more time for users to use at low power.

In the pre-research on low-power mode, we listed many measures that can be taken. Through AB experiments, we removed negative downgrade methods for business, such as brightness reduction, volume reduction, etc. In addition, in terms of function triggering strategies, we compared the low-power pop-up reminder, added switch + Toast reminder in the settings, and automatic entry of low-power, and finally chose the best trigger method for the user experience of 30% of the battery without disturbance.

After experiments, it was found that some high-heat generation models can also obtain business benefits through the full operation of low-power mode. This shows that some lossy downgrades are accepted by users when it is prone to heat, and can replace business benefits. At present, the offline testing power consumption income of low-power mode is stable at more than 20mA.

Summarize

Power consumption optimization is a complex comprehensive topic, which not only involves the use of tools to disassemble and evaluate power consumption, monitor and manage abnormalities, but also includes actively mining optimization points for optimization. We have only done some of the optimization ideas listed above, and there are still some to be carried out, including the construction of power consumption attribution tools. We also have many points that can be optimized. We will continue to make efforts to produce more solutions, and consume less physical resources while meeting the needs of use, bringing a better power consumption experience to Douyin users.