[MUSIC PLAYING]
So by now you know that there is a lot
of things that go into rendering a frame on Android.
And when frame rate starts to suffer,
top priority is figuring out which
thing has gone off the rails.
My name is Colt McAnlis.
And in order to help you track down
where your frame problems are coming from,
the M release of Android has updated its GPU profiling tool.
Now if you recall, back in season one of Android
Performance Patterns, we talked about the profile GPU tool
along with the three phases of rendering pipeline
that it measured-- recording a display list,
submitting it to the GPU, and waiting for the GPU
to finish its work.
But let's face it.
Things are a little bit more complex
than that, which is why, in the M release of Android,
this tool has been expanded to show you
eight different sections of your rendering frame,
conveniently and uniquely colored
for easy identification.
Now, you're already familiar with the first three phases
here as update, execute, and process.
We talked about those before.
They still report the same information.
So we're pretty much good to go here.
More interesting are some of the new stages that
haven't been reported before.
Firstly is Sync & Upload.
This value generally measures the time
it takes to upload bitmap information to the GPU.
A large graph segment here means that your app
is spending a lot of time doing that,
like if you suddenly grab 50 new thumbnails
or you're uploading an 8 megapixel image.
Shrinking this bar usually means things
like reducing the number of visible images
or reducing and resizing large images before uploading them
to the GPU.
Of course, then there's Layout and Measure phase,
which report exactly what you'd expect-- the amount of time
spent per frame executing on layout and on measure callbacks
in your view hierarchy.
High values here indicate that you have a super complex view
hierarchy.
And thus performing lots of measure and layout
phases across a bunch of views.
Or you might be the victim of things
like double taxation in the wrong spots in your view
hierarchy.
And shrinking this bar means doing
stuff we've already talked about like reducing view hierarchy
complexity and using view objects that can reduce
the chances of double taxation.
Next is the Animation phase, which
just shows how long it took to evaluate all the animators that
were running that frame, the most common of which
being things like object animator,
view property animator, and transitions.
If this number is high-- like above 2 milliseconds
or so-- check to see if your app uses any custom animators
or if some unintended work is happening
as a result of your properties being updated.
I mean, you'd hate to end up in a situation
where updating a property causes a pause due to disk
I/O every frame or something like that.
And then, of course, there's Input Handling.
This basically measures how long the application
spent handling input events or, perhaps more accurately,
how long the application spent executing your code
inside an input event callback.
If this number is high, this indicates
that the app is spending a long time processing the user's
input, meaning that you might want to offload or optimize
that work to a different thread.
And finally, there's Misc Time and Vsync Delay.
If you've ever seen the logs from Choreographer
about, like, (DEEP VOICE) missed vsync by blah, blah, blah,
skipping, blah, blah, blah, frames, that's that this thing.
Basically, it's the stuff that might
be occurring on the UI thread between two consecutive frames
of rendering.
If this value is high, chances are
you've got some callbacks and tents or other work
happening that might be ideal to push off to another thread.
But with all these colors crammed together on the screen,
it's a little tough to make out which
ones are causing the problem.
That's why, if a frame spikes above the 60
millisecond threshold, you'll notice that its bar is
drawn more opaque.
And it's wider than the bars around it.
This will hopefully make it a little easier on your eyes
to pick out.
See, as the platform evolves and developers get more skilled,
it's only natural that the tools will evolve alongside it, which
is why you should check out the rest of the Android Performance
Patterns content so you can stay up to date with the latest
performance tools.
And don't forget to join the Google+ community to get advice
from other great engineers.
So keep calm, profile your code, and always remember,
perf matters.
[MUSIC PLAYING]