[MUSIC PLAYING]
COLT MCANLIS: Understanding how to make a great performing app
has everything to do with understanding
what's going on under the hood.
If you don't know what the hardware is doing,
you've got a good chance of using it poorly.
My name is Colt McAnlis, and when
it comes to rendering your application,
understanding how Android is utilizing the GPU
can go a long way to understanding your performance
problems.
The main question is this-- how does your activity actually
get drawn to the screen?
Or rather, how does all that crazy XML and markup language
turn into pixels that the user can see and understand?
At its core, this is done with a process known as rasterization.
This is the process of taking some high level
object like a string or a button or a path or a shape
and turning it into pixels in the texture or on your screen.
Now, rasterization is a really, really time consuming process.
And as such there's a special piece
of hardware in your mobile device
that's designed to make it happen a lot faster.
The graphics processing unit, or GPU,
was introduced to mainstream computers back in the '90s
to help accelerate the rasterization process.
The GPU itself is designed to use
a specific set of primitives, dominately polygons
and textures, or as you may call them, images.
And your CPU is responsible for feeding these primitives
to your GPU before it can actually
draw anything to the screen.
This is done with a common API on Android
known as OpenGL ES, which means that any time your UI
objects like buttons or paths or checkboxes
need to be drawn to the screen, they first
need to be converted on the CPU to polygons and textures
before being passed off to the GPU to rasterize.
And, as you would imagine, this process
of converting a UI object into a set of polygons and textures
is not really the fastest of operations.
Likewise, needing to upload it from the CPU to the GPU
really isn't that fast either, which makes sense then
that you would want to reduce the number of times you have
to convert an object as well as the number of times
you have to upload it for drawing.
Now, thankfully, OpenGL ES API allows
you to upload content to the GPU and leave it there.
When you'd like to draw a button again in the future,
you simply need to reference the mesh that's already
resident in GPU memory and just tell OpenGL how to draw it.
The general rule is this-- optimizing
for rendering performance means getting as much data on the GPU
as fast as possible and then leave it there
without modifying it for as long as possible.
See, every time you update a resource that's on the GPU,
you're losing precious processing time.
And this is a rule that the Android system lives by--
to make rendering performant.
For example, resources that are provided by your theme-- that
is bitmaps and drawables-- are grouped together
into a single texture and uploaded to the GPU
on your behalf alongside commonly used polygon meshes
like nine patches.
This means that any time you draw
a view that uses these resources,
we don't have to do any conversion.
See, all the content is already resident on the GPU,
making these type of views really fast to display.
However, this process gets more and more complex
as UI objects get more and more advanced.
For example, displaying images, means
loading these images on the CPU into memory
and then transferring them over to the GPU to draw.
Using paths creates a whole separate mass
as we might need to actually create
a chain of polygons in the CPU.
Or even make a masking texture on the GPU
that approximates the shape.
Drawing text is like a complete double whammy.
I mean, think about it.
On the CPU side we actually have to rasterize the glyphs
to a texture and then upload that over to the GPU,
and then go back and for each character in our string,
draw a rectangle that references those glyphs on the GPU memory.
And animations can make this whole thing even more complex.
See, depending on how you're changing your visuals,
you may have to incur all the overhead of updating your GPU
resources again and again and again every single frame.
And this doesn't even cover all the other crazy GPU performance
stuff.
For instance, rather than redrawing the whole application
every frame, Android saves performance
by only updating and drawing the area of the screen that's
actually been modified, not to mention all the CPU side
conversions and uploads that Android
has to go through to get everything
ready to render in a performant manner.
But here's the tricky part, in order
to provide a smooth, luscious user experience,
you have to accomplish all the code updates, GPU resource
updates, and final rendering in 16 milliseconds per frame
of your animation-- every frame.
Or at least that's the goal, which
is why you need to check out the rest of the Android Performance
Patterns content to help supercharge the rendering
pipeline in your application.
Oh, and don't forget to join our Google+ community for other
great tips and tricks and advice from more developers.
As always, keep calm, profile your code,
and remember, perf matters.
[MUSIC PLAYING]