My current project is a permanent presence application (I think, Tinder or Foursquare), and battery consumption is through the roof. We believe that the main power needs are GPS and WiFi antennas. We would like to be able to measure the energy consumption of an application in several different configurations.
But how to do that? We need a process that:
- It can be used with a phone disconnected from the computer (so we know that we use a battery, not power supply via USB),
- It has sufficient detail to allow us to correlate energy surges with application events (application launch, location update, sending analytics information to Mixpanel, etc.),
- You can run all night without a nanny,
- It can be exported as CSV or whatever for statistical analysis.
Enough list, I know.
These are the requirements, and here are the options that I know of:
1. Inclusion of non-loose energy diagnostics. Register on your iOS device and export to Tools
This is an obvious answer, but it has one gigantic flaw.
Pros:
- Uses battery instead of USB power.
- Excellent grit (1 s time series data, 20 levels of discrete energy consumption),
- Matches other device events, such as using a GPS antenna, etc.
Minuses:
2. Monitoring the connected phone using tools
Pros:
- The same excellent granularity and correlation with other events of the device.
- The battery cannot work.
Minuses:
- Do not use a battery, so energy consumption is not comparable to use in the real world.
- Tools do not even reliably show energy consumption. Sometimes it's just empty.
- Unable to export to CSV.
3. Using public Cocoa APIs to record energy consumption in our application - [UIDevice.currentDevice batteryLevel]
This is the most common answer to SO. I looked at Estimated battery life on iOS , iphone: calculating battery life and about a dozen others.
Pros:
- Arbitrary time between measurements.
- It can be saved even if the battery dies, writing to the disk somehow (CoreData, by default, a network, whatever).
- You can select any data format, for example CSV.
Minuses:
- Much more work than others.
- The open API gives you a battery level of up to 5% accuracy. This is essentially the time integral of the instantaneous energy consumption data that we get from approaches 1 and 2. Not granular enough to correlate with other device events (but, perhaps, enough to get a general estimate of the device’s battery life).
4. Using Cocoa Private APIs to Record Power Consumption
As we will only do this during development, it does not matter if Apple rejects the application to use the private API. Presumably there is a private API for this, since Apple can record data using Untethered Energy Diagnostics.
Pros:
- Arbitrary detailing, arbitrary file format, arbitrary persistence.
Minuses:
- Waaaaay has more work to figure out how to use it. Perhaps not even possible.
5. The combined approach
We could use raw diagnostics to quantify the marginal cost of energy for each action. "Well, a GPS rotating antenna occupies 150 mW • H. An estimated position takes 50 mW • H. Sending a Mixpanel event takes 25 mW • H unless we made another network call within the previous 30 seconds, in which case it takes 15 MW • H. " (all numbers are thought up on the spot.) Then we can use tethered monitoring to record when each of these actions happens, connect to a linear equation and estimate the amount of energy that it had to take.
Pros:
- Flexible. Arbitrary everything.
Minuses:
- Mathematics.
- It is very easy to skip nonlinear contributions. Getting something like E = k0 / (gps polling interval) + k1 * (number of analytics calls) is easy, but what if the cost of deploying both antennas is less than the sum of deploying them separately?
- Ignores any caching strategies that Apple can do internally in location services.
- Even remotely close to real-time use.
In any case, I got quite mad. Has anyone done this before? How?