How does Android draw your UI?
Understanding 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 is the hardware is doing, you have got a good chance of using it poorly. when it comes to reading your application, Understand how Android utilizing the GPU, Can go a long way to understanding your performance problems. The main question now is this
How does your activity get drawn to screen? or rather, how do 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
Rasterisation is the task of taking an image described in a vector graphics format and converting it into a raster image. The rasterised image may then be displayed on a computer display.
This is the process of taking some high-level object like a string or a button or bath or shape and turning it into pixels in the texture or on the screen.
Now Rasterization is timeconsuming process.
And as such, there is a special piece of hardware in your mobile device that’s designed to make it happen a lot faster, the Graphical processing unit or GPU.
The GPU itself is designed to use a specific set of primitives, 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 draw anything to the screen.
This is done with common API on android know as OpenGL ES, which means that any time your UI objects like buttons or paths or checkboxes, need to be drawn in the screen they first need to be converted on CPU to polygons and textures before being passed off to the GPU to rasterize, and as you 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 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 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 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.
Resources:
