We’ve been testing the battery impact of various iOS software configurations. In addition to being fast, secure, and beautiful, our new mobile GL technology needs be extremely battery efficient. This has involved a lot more mentions of pentalobe screws and Windows XP than is normal around the garage.
Collecting location probe data is a key part of how we’re making an amazing map. We’ve talked a lot about how we’re collecting, anonymizing, and aggregating this data, and how we keep it secure. There are many different ways to collect location data on iOS, all with different implications for battery life. CPU profiling is great for evaluating code’s efficiency, but doesn’t tell the whole story when GPS and radio are involved. And although Apple introduced features for tracking energy usage a while ago, their precision is limited. We can do better.
Batteries
Batteries are rated in milliamp-hours, which are what they sound like: a 1000 mAh capacity means that a battery can supply a current of 100 milliamps for ten hours or 200 mA for five. This arithmetically simple relationship–use half as much, last twice as long–doesn’t hold perfectly if you discharge the battery really quickly, but it’s otherwise pretty close to accurate. By measuring current draw over time, we can calculate an average power consumption rate. A battery’s capacity divided by that average gives us a good idea of how long a full charge will last.
So how do you measure current? Current, voltage and resistance are related, and if you know two of them you can figure out the third. If you have a very precisely calibrated resistor and an appropriate amplifier, you can assemble a circuit and use an oscilloscope to measure current-by-way-of-voltage millions of times per second. But a nice digital multimeter with USB out can do it too, and is considerably more portable. Our rig only samples at 7 Hz and 10 mA resolution, but that’s enough for our purposes.
Phones
It would be nice to avoid opening the phone and instead measure the current going through a charging cable. But the presence of a battery makes this unreliable: its reservoir of power smooths things out, and there’s no telling when the phone will decide to charge it. Measuring this way would be like putting a bowl of snacks next to a person and trying to guess how many calories he’s burning by observing if he eats anything. Instead, we have to pretend to be the battery, providing power and signals through the connector that the phone expects to see.
Phone batteries are made with lithium, which lights on fire if you treat it badly. So every lithium cell comes with built-in protection circuitry. These days they usually include some additional technology to monitor battery capacity more accurately. For an iPhone 5 it looks like this:
Photo by Larry Johnson
The iPhone checks for the presence of that fuel gauge chip at boot, so omitting this circuitry isn’t an option. It’d be unsafe, anyway. Our first step is to cut the strip of battery circuitry away from the electrochemical cell. It’s just taped/crimped on, so it’s not too difficult if you’re careful (you should probably keep a fire extinguisher nearby–do this at your own risk).
I was stuck for a while by the next step: every time the protection circuitry is energized it trips, rendering the system useless and making it seem like it’s fried. It turns out that I just needed to connect two pins briefly to reset the system. Jason Gin, battery blogger extraordinaire, was a big help in figuring this out.
Cars
The iPhone reportedly uses various unobservable tricks to minimize location collection when it’s stationary, and we needed to test both power consumption and the quality of collected trace data. This meant we had to test while in motion. A lot of Zipcar rides made it possible for us to move around while keeping access to a good power source. This is trickier than it sounds! When transmitting, the iPhone’s current needs can spike to several thousand milliamps. A battery can sustain this kind of intermittent surging, but it rules out many USB power systems.
We drove for ten minute test periods, having turned off notifications and location services for everything but the test app. Each test run started by booting up the iPhone, starting the app and allowing the handset to go to standby under default settings. We ended each run by powering down, then saving the collected data. In between runs we closed everything, deleted the app and installed whichever build we were testing next.
Results
We wound up with battery data that looks like this:
It’s a bit more legible with some smoothing:
[
These data series don’t overlap perfectly, but they’re close enough to identify patterns. The left-most section is booting up; the first gray section is where I activated the test app and waited for it to go to standby; and the final gray section is the shutdown sequence. If we normalize the sample rate and discard the first and last 25% of the data, we can derive numbers that represent the current draw of various background scenarios:
| test | mA | theoretical hours, stock battery |
|---|---|---|
| build 4 | 80.6 | 19.5 |
| build 13 | 186.7 | 8.4 |
| 109 (foreground only) | 57.4 | 27.4 |
This is old data, back from our very first test. It represents extremes: collecting way too much (build 13) and way too little (109). Two things were quickly apparent. First, background GPS collection is very battery intensive. Second, ~60 mA is the floor for iPhone life support. By way of comparison, that’s about 3 LEDs' worth of current. Remember, these numbers capture everything the iPhone is doing, including the normal systems that let it listen for text messages and calls. Subsequent tests also taught us that the marginal impact of background collection is too small to be observed after the first app that does so.
Data Powers Improvement
We’ve come a long way since those first three test runs. With a working methodology, we began testing how other apps with background capabilities stacked up. That led us to interviews with third-party engineers about their experiences, and subsequent tests with different versions of our own implementation.
In the end we hit the perfect balance between precision and power consumption, providing great data for mapping while using less than half the energy of GPS collection. Developers and users who need every last milliamp-hour will always be able to opt out of sharing data. But even when they don’t, apps powered by our soon-to-be-released SDK will have awesome performance with negligible battery impact, ensuring a full day’s charge for users and a better map for everybody.