In this article, I will provide an overview of how views created in code in XML are displayed on the phone screen in pixels. As you know, the architecture of the android operating system consists of 4 floors. When creating an application, we usually only care about the top layer is the application layer, so to create an application with the best performance, you need to know the parts below how to do the job. If you do not know what the hardware is doing, you will not be able to use it most effectively. Let’s first review the basics of a view’s life cycle

1. The life cycle of a view

One thing we all know for sure is that each view has its own life cycle. However, in a screen with multiple views, nested views, … then the life cycle of each view will be called? This is extremely important for us to create the best performance application. Let’s take a look at the lifecycle of a view

Each method in the view’s lifecycle will have different uses. Now let’s dive into the details of some of the most important methods. onMeasure () is a method called to determine the size requirements for this view and all its children. onLayout () is the method called when the view assigns size and location to all its children. o nDraw () is called when the view is ready to display its contents.

I will not go into details of every method. For more details, see this article .

2. Rasterization

Rasterization is the process of converting some objects such as a string of characters, buttons or polygons into pixels on a phone screen. Rasterization is a time-consuming process. So the GPU (Graphics Processing Unit) was born to speed up the rasterization process. The GPU is designed in a way that only uses specific objects like polygons etc. The CPU is responsible for providing content to the GPU before it can display everything on your screen.

The process of transferring data from CPU to GPU is done by a popular API called OpenGL ES. At any time, UI objects, such as buttons, links, etc., need to be drawn on the screen. First, they are converted into polygons and textures by the CPU, and then, they are converted to GPU for rasterize.

3. For example

Let’s look at a simple example of displaying a button on a screen. So here the button or any other UI object needs to first be converted into polygons and textures by the CPU before putting it into the GPU.

The process of converting UI objects into grids is very time consuming. And after conversion, the process of loading this information from the CPU to the GPU via the OpenGL ES API is also a time-consuming process.

These activities are not easy and very time consuming. When OpenGL ES uploads content to the GPU, the grid denoting the UI object is still on the GPU. So in the future, if you want to redraw the button on the screen, we’ll need to reference the existing grid and tell OpenGL ES how to draw.

Tip: Optimizing to display performance means getting as much data as possible on the GPU and leaving it there and referencing it for as long as possible without modification.

4. Display the list

When a view needs to be displayed, a display list is created for that view. When that view needs to be displayed on the screen, we need that view by sending its drawing commands to the GPU.

The displayed list contains all information to display the view on the GPU. It may contain GPU assets, GPUs that may be necessary or commands that need to be executed for two OpenGL to display each account individually.

In the future, if there is a change in the properties of the view, we just need to make that display list one more time. But in the future, if there is a visual change in the view, the previous display list is no longer valid – so we need to recreate the display list and perform it again to update the screen.

Tip: If at any time the content of the view changes, it will repeat the process of recreating and updating the display list. Therefore, the performance depends on the complexity of the view.

Suppose there is a change in the size of a view. Then, onMeasure() starts being called, it will ask every view in the hierarchy to see what their new dimensions are. And if there is a change in the position of the view, the therequestLayout () will be called. Or if a view group reposits its children, is called and traverses the entire hierarchy where every child needs to be located.

Because each phase takes its own time, it may not have a major impact. But in case there are other views or view groups depending on them, they can have an impact on performance.

Tip: So for apps to work better, we need to maintain a flat view hierarchy that reduces the time it takes to update the view. I think you’ve got a basic overview of how to display. If you want to know more about what components are used during rendering, what the display path is, and how synchronization happens between UI and hardware, please check on Android Android Internals to display View.

5. References

https://medium.com/better-programming/understand-how-view-renders-in-android-763f0adfb95c