Moe Tanabian, Software Development Manager, a2z Development Center Inc., an Amazon.com company, is our guest blogger for this post.  Moe recently presented on this topic during the Android Developers Conference (AnDevCon) in May.

One of the challenging issues of building mobile devices and applications is energy consumption management. In order to support users’ mobility, and their various uses of their devices, it is necessary to make light and reliable battery-powered devices with batteries that last longer.

Smartphones and tablets are getting faster, their screens are getting bigger and brighter, their CPUs run on faster clocks, and their daily usage time is getting longer as users use them for a wider variety of functions.

The advances in battery technology have been much slower than the evolution of device technologies and their usage patterns. In fact, most modern mobile devices are powered by battery technologies that are over a decade old. That is why most efforts to prolong battery life are focused on making hardware and software more power efficient.

Knowing about power consumption and the behavior of applications on mobile devices is fundamental in making batteries last longer. There are four factors that determine how much energy a mobile device, and by extension a mobile app, consumes: The battery, the device hardware, the software that runs on the device, and the user workload.

We know that batteries and battery technologies have been slow in getting more energy dense while most hardware is getting more power-hungry. Let’s look at how we can optimize software to lower power consumption and to adapt to user behavior and workload—from an app developer’s perspective.

Power Consumption Measurement

The first step toward optimization is to measure power consumption of an application. We can use direct and indirect methods to measure the energy that an application consumes.

Direct method: Ina direct method, a relevant use case is run on the device, and using a high sampling frequency logging power-meter, an amp-meter or a volt-meter the drawn power from battery is logged. These logs are analyzed later to determine how much power was consumed to complete the use case. Figure 1 shows how a mobile device is connected for direct power measurement.

Indirect model based method: In an indirect or predictive mode based method, first we develop a power consumption model of the device based on its power consuming components. In atypical mobile device, these components include the CPU, the screen and screen illuminator, memory and flash, Wi-Fi, Bluetooth and cellular radios, GPS receiver, and available sensors on the device such as accelerometer and gyroscope as they are shown in Figure 2.

The total power that is consumed by a device (P_t) is the sum of the power consumed by the main components, plus a constant k. For the component i (for example the screen brightness) the drawn power can be modeled as the product of an associated system variable C_i, and the component’s coefficient B_i  for the time that the component is active, which is the test duration. This forms a regression estimation model that can be trained using training data observed from a direct method measurement for all components of interest.

Once the model is trained and k and B_i are determined, it can be used to estimate power consumed for a particular use case by simply plugging in the collected values of C_i from logs.

Logging and Instrumentation for Power Consumption

Instrumentation is one of the basic ways to understand the power consumption behavior of mobile device software. With adequate logging, areal-time service can deduce where and how power is consumed. Good power consumption logging covers instrumentation of the following points and events:

• Logging an associated system variable for each component that is considered important from power consumption perspective. Examples are when the screen turns on or off, the display brightness level, CPU utilization along with CPU clock, Wi-Fi, cellular, and Bluetooth radio parameters such as on/off state and TX power if available, state of sensors on the device, and finally, state of the battery.

• Important internal events that can change the running state of the app including timers, and power manager related events. For example when the device changes its state from Idle to suspend or active, or when the screen is turned off or when its brightness changes.

• Externally driven notifications and events such as incoming calls, SMS and other type of messaging.

• Logging instrumentation should have enough data in the logs, that at the time of post-processing, it should be clear which device, which user, and which session the log belongs to, and of course, without compromising the user’s privacy.

• Another important factor is the frequency of logging. It’s a good practice to make logs granular enough so that post-processing can reveal useful information about the power that is being consumed across different components for apps that are of interest. At the same time, logging too frequently itself can put excessive overhead on the device which not only will skew the results, it will lower device’s performance and shortens its battery life. Determining the optimum logging frequency depends on the target’s device’s capability, and the power manager’s internal timers and behavior. A good rule of thumb when logging is to try not to impact user experience in a demanding application, such as CPU/GPU intensive games. For most modern mobile devices, a logging power consumption variable at a frequency of 0.2-1Hz should provide enough granularity while avoiding excessive load on the device and user experience.

Power Consumption Optimization in Mobile Applications

Optimizing for power consumption requires a holistic approach that touches most decisions about designing and developing a mobile application. Ultimately, better battery life provides a better user experience and makes for more satisfied users.

The best way to optimize for battery life is to identify the most offending areas in the software and optimize them first. What constitutes the most power-consuming features greatly depends on what features users use most,and this varies from user by user. Best battery life optimization mechanisms are the ones that recognize users’ usage patterns and adapt the optimizations accordingly. In this section I’ll introduce general practices that can improve power consumption in a mobile application.

• Avoid accessing the disk and network too frequently. These are expensive operations when it comes to power consumption. Instead, try to batch up your disk reads and writes, and network operations and do them less frequently. It requires a lot less power to send 3 MB of data every 30 minutes than breaking it up into 30 iterations and sending 100KB every minute. This is because the power manager on the device minimizes power consumption by aggressively turning off major power consuming components such as radios and screen, when they are idle for a period of time. If the user or an application triggers a component frequently—for example, by sending data on a network in the case of the Wi-Fi radio—the power manager will have to turn on the radio and this can drain the battery very quickly. The same applies for CPU utilizations. Group CPU intensive tasks together and run them in bulk as much as possible, rather than in multiple chunks. This allows the CPU to go to sleep more often and save battery.

• Avoid using exact time timers and requesting high precision locations from location services. Similarly, avoid reading other sensors such as the compass and accelerometer too frequently.

• Avoid complex 2D and 3D UI, especially in multi-layer UI designs. Many graphic processors are not able to optimize complex graphics adequately and spend valuable cycles drawing parts of the screen that are not visible to the user because either they are outside of the visible area, or they are hidden behind other overlapping layers. Simple UI design has the additional of benefit of being very fast, and that’s user-friendly. Additionally, complex UI generally lowers FPS (frames per second), which degrades user experience.

• Design simple user interactions and avoid providing users with a complex set of choices and UI elements. Humans are not very efficient when they have to select among too many choices. Our response time increases substantially when we have to pick a selection among many. This is called cognitive latency and a good UI design minimizes cognitive latency. This in turn minimizes the time that the user spends on a fully rendered UI and lit up screen and it lowers power consumption.

• A darker UI is more power efficient than brighter UI.

• While this may sound obvious, it’s often neglected: avoid running unnecessary code. If your application transitions into the background and there’s no user interaction, stop listening to events, timers, and any other trigger that can unnecessarily wake up the application. For example, if your application receives stock tickers from a server and this triggers a UI update, avoid updating the UI if the application is in the background state. An even better practice is to halt the network connection and re-establish it again when the user brings the application back to the foreground.

References

1. Pro Android Apps Performance Optimization(Professional Apress) by Hervé Guihot
2. iOS App Programming Guide; http://developer.apple.com/library/ios/DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/iPhoneAppProgrammingGuide.pdf
3. Design and testing for longer battery life in Android Devices and Applications by Moe Tanabian, http://www.slideshare.net/mometan/an-devconii-moetanabianssh