[MUSIC PLAYING]
One of the most frequent performance problems
your users will notice is how your app
reacts when moving from a great network connection
to a bad one.
My name is Colt McAnlis.
And if your app isn't properly adapting to network latency
during the day, your users will blame your app rather than
their connection.
The truth is that the internet is
made of a bunch of crazy moving parts, or a series of tubes,
if you're a senator.
Anyhow, basically, requests made from your phone
have to hit a local cell tower, which
then gets routed to the service provider's server.
And then, it may hit a local data proxy for that provider,
before going out onto the Internet
and connecting the main data server, which then needs
to decode the response, fetch the data,
and then send that back, only to return the data back
to your cache's ISP server, and then finally to the phone itself.
Basically, it's a lot of moving parts,
and a bottleneck can be anywhere.
And since you don't control all those stages,
the best you can do is make sure that your application properly
adjusts to how it works based on the connectivity of the device.
This involves two things. Number one,
getting information about the speed
and performance of the network, and number two,
designing your app to respond to changes in bad latency environments.
Now, the first is easier to do than you might think.
Simply grab the connection manager
and determine if you're on a mobile network.
>From there, a quick call to grab the network subtype
gives you an enumeration for what type of network
you're connected to.
A handy lookup table then lets you know what kind of network
you're dealing with, and what to expect
as the best possible bandwidths and latency.
But in truth, that value gives you the best case scenario.
See, in the wild, you're going to get much worse results.
Even though your user might be on an LTE network,
there may be a problem with a slow data server,
resulting in maybe double the time it
would normally take on that network for that request.
So a more accurate, although more complex,
solution is to evaluate the time it takes to grab responses
from your network.
For example, if you know that all
of your thumbnails in your list view are 128 by 128 pixels,
then you have a general sense they should be about 1K
in size, which should, on the given network only
take a certain amount of time to download.
You can then average the true cost of these fetches over time
to give you a better sense of what the real network conditions are
and how they are changing as the user moves through their day.
Once you get this information, you then need to
decide how to design your app to handle it.
As a simple approach, you can define two thresholds and three
buckets of classification.
If your latency is less than, say, a lower threshold of 60
milliseconds to fetch an asset, then your user
is on a great connection.
You may be able to be more aggressive about the amount
of data that you pre-fetch and less of aggressive
about things like caching.
However, if it takes less than the upper threshold,
then you may not be in the best spot.
So you need to become more aggressive about batching
and caching, and take advantage of how often you request data.
And if they're above the max threshold,
well then, you should find ways to defer requests until later,
when there might be a better network connection,
or change the UI so that not fetching all
the thumbnail images isn't such a huge, jarring problem.
But the truth is, that these thresholds
won't work for every user.
And in fact, you're going to need
to put a bit of elbow grease in to find the correct thresholds
for the 50th percentile, 90th percentile, and 99th percentile
of the connections that your users are actually on,
which is actually a pretty large engineering
project, but critically important for your app
to remain responsive and magical in high latency environments.
Now rather than waiting for the users
to focus on slow connections to complain,
it's better to start designing and testing bad bandwidth
on your app early.
You can test how high latency impacts your applications
by throttling the bandwidth when you're running the Android Emulator.
Or you can check out third party apps
like AT&T's Network Attenuator.
In both cases, you can see how your app responds
when latency goes sky high, which you should
be doing with everything.
Honestly, testing performance on the slowest hardware, worst
networks, and most insane conditions,
is the best way to ensure a stable, consistent performance
for your users.
Of course, you'll need to watch the rest of our
Android Performance Pattern videos
to see what to fix.
And join our Google+ community
to get advice from other developers
in the same boat.
Trust me, your users will thank you.
So keep calm.
Profile your code.
And always remember, perf matters.
[MUSIC PLAYING]