Any time a developer considers integrating a new SDK, they’ve got a few concerns to address in order to protect their reputation, brand, and customer satisfaction. Is the SDK bulky and big? Will it play nicely with our own code and other SDKs? Will it kill the battery?
Ahhh…this last point always raises a few questions. The success of Reveal Mobile’s technology relies upon two app level permissions. We use Bluetooth beacons and lat/long data to build location based mobile audiences, which do have an impact on battery life.
Smart developers know to ask the questions their customers will ask.
Doesn’t leaving your Bluetooth on all the time drain your battery?
Don’t apps that request location from a phone drain the battery quickly?
The sentiment boils down to: If our customers see us draining battery, they delete our app. We’ve lost them forever.
Companies with SDKs will all claim their product doesn’t significantly drain battery. In this post we back up that claim with data.
We approached this by using a 3rd party developer to run our SDK through a series of tests. To test iOS devices they used Apple’s Instruments tool. This makes it easy to isolate the specific tasks using the battery, in this case the Reveal Mobile SDK. The test on iOS was conducted on an iPad Air model A1475 running iOS 10.0.2
In the image below you’ll see what happens when an app fires up using our SDK. There’s a spike of activity at the initial startup, which then quickly settles down to a constant low mark. The SDK uses a small amount of energy to send periodic updates to the server.
Testing battery usage on Android isn’t quite as simple, but Google does provide a few tools. The development team gathered the information from the logs using the battery historian scripts provided by Google.
The test began by running the screen on a Nexus 9 running android 7.0 for 30 minutes to establish baseline of battery usage. Next, the developers started the Reveal Mobile internal testing app, letting it run for 30 minutes.
In the image below you’ll notice the top row of “battery_level” shows that the battery drain didn’t significantly change by running the test app, and therefore the SDK. (what are those time differences?)
Looking farther down the page, find the ble_scan line. The operating system does regularly scan for Bluetooth Low Energy (BLE) signals when idle, and you can see that increase when we launch. These small increases reflect the impact on battery life.
Where do we net out? Over a 24 hour period the Reveal Mobile SDK will account for approximately 0.05 – 0.2% of battery usage. This minimal drain is intentional, for all of the concerns stated above. We take a cautious approach to Bluetooth and location usage, as well as how frequently the SDK pushes updates to the server.
If you run your own tests, we’d love to hear how our SDK performs in your app. Having that feedback helps us refine our performance even further.