(music playing)
One of the unique features of mobile apps is location awareness.
Mobile users take their devices with them everywhere
and adding location awareness to your app offers users a more engaging experience.
My name is Colt McAnlis, and while all this fancy location data
is making your app more useful, misusing it can cost you big
with respect to battery life.
Now, a standard location request looks a little something like this.
And in the name of performance, let's take a look at the first two values,
namely the interval APIs.
SetInterval sets the rate in milliseconds at which your app
prefers to receive location updates. The lower the number,
then the more updates you get, and the more battery you burn as a result,
which means finding the right value to use for your interval
is an important balance.
Too fast and you'll be burning lots of battery for the GPS requests.
Too slow and your application won't be updating fast enough
to be helpful to the user. But you want to end up in a situation
where you can be more dynamic with how you interact with this hardware.
For example, if you notice the position has stayed the same for a while,
then there's a good chance that the user may be stationary for a long duration.
So try backing off the sampling interval to reduce the amount of battery churn
that comes with that process.
But it's also worth pointing out that other apps also affect the rate
in which updates are sent to your application.
In fact, the underlying system will send out updates at the fastest rate
that any application has requested with the SetintervalAPI across the system,
meaning that your app can end up receiving location events
at a faster frequency than the one requested by your app,
perhaps flooding you with location information
and doing a lot of other stuff you don't actually need to do.
Which is why the SetFastestInterval API is used.
Basically, this lets you throttle how often you get updates
that you might not be interested in or ready for.
So your app isn't wasting time updating and processing location events
when they're not actually being needed.
Now let's take a look at the whole setPriority thing.
You have to remember that the dominant way
your device resolves its physical location on Earth
is with the help of a global positioning system hardware.
Basically, there's a cascade of satellites hanging out
just right outside of Earth's atmosphere, whose whole job
is to communicate positional information to your device
based upon your movements.
Simply, the GPS hardware in your phone negotiates signals between the satellites
and tower data to pinpoint your position in space and time,
which as you might imagine, is a very battery-intensive operation.
But this isn't the only way you can get location data.
Besides the super expensive GPS, there's also the network provider,
which determines location based upon availability of cell tower
and Wi-Fi access points.
The result is that less accurate results are given to you,
but only a portion of the battery is used compared to the GPS version.
And, of course, there is the Passive Provider,
which is probably the most battery efficient.
When some other application makes a location request,
the results then get passed along to your app as well.
That way your device isn't sending out multiple location pings
and can spend more time saving battery.
Now, in order to make all of this more accessible
for your location API needs, you can control what types of networking
and battery drain you're wanting by using the setPriority option
of a location request.
And if you're already using activity recognition
to determine what the device or app is doing
or when it's not being used, you can leverage this data
to turn off location request queries or throttle them back
when they're not needed.
But in truth, balancing and bouncing all of those APIs depending on the state
is really a cumbersome process, that's why Android made it a lot easier.
By using the FusedLocationProvider API, you get a simplified interface
to all of this craziness, and Android will handle
all the grungy details on your behalf, saving you both battery as well as sanity
in your code base.
Now, if you're ever confused about how your application
is eating through battery, be sure to take a hard look
at the Battery Historian tool.
It will happily remind you of all the things you're doing wrong
and give you hints on how to get them fixed.
So don't get lost in the world of battery performance.
Make sure you check out the rest of the Android Performance Patterns videos
and join our Google+ community to ask questions
from other great performance experts.
So keep calm, profile your code, and always remember,
Perf Matters.
(music playing)