Shulou(Shulou.com)06/02 Report--

Editor to share with you how the UI drawing process is, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to understand it!

Preface

In android, we often encounter all kinds of problems when drawing UI and don't know how to solve them. Sometimes, when we need to develop and change custom components, we need to make our own adjustments, or the idea to achieve a custom special effect is not clear. To achieve the most basic part of playing with UI is to have a comprehensive and in-depth understanding of UI drawing process. So next we will take you to a comprehensive analysis of the overall drawing system of UI.

Idea: android program starts-→ Activity loads and completes lifecycle-→ setContentView- → graphics drawing

Doubt:

How is the 1.Android program started and how is the Activity life cycle called?

two。 How does our setContentView load the UI file in Activity onCreate?

How is 3.UI drawn?

Answer:

1.Android program flow

As we all know, if our java program wants to open, we need to rely on the main method, that is, our program entry (main thread) to enter, but in our daily process of developing android programs, we do not find the existence of the main method, so how does the android start to run?

Friends who are familiar with may know that there is a class called ActivityThread in android, which represents the main thread in android, and in this class we have seen the familiar main method. Can we now think that when our android opens app, the main of the current class is called first, that is, this is our starting point?

You can see here that Activity calls an attach () method

The first thing we may have to consider here is what getService came up with.

When we get inside, we'll find out

In this, the ActivityManagerService service of the system is called, and a Binder interface is given.

So here, we can think of the binder communication mechanism in android, so in fact, our ActivityManager is managed by system service calls and is called in the binder interface, which is why we say that Activity is cross-process access.

So after we understand that we can get ActivityManager at this time, we go back to attach and move on, and we will find that we have called an attachApplication method (see figure 2). What is this method for? In fact, the function of attachApplication here is that ActivityThread obtains it through attach, then associates it with applciationThread, stores activity-related information in applciationThread, and makes corresponding preparations for various states of apllicationThread, which is called activity.

At this point we need to pay attention to what has been done in ApplicationThread?

When we open the ApplicationThread, we see a bunch of schedle methods, and the names of these methods actually show us that they represent the plan execution methods that are called when a certain state of the Activity is executed.

At this point we will see a scheduleLaunchActivity method that is called when the plan is loaded

I found a very interesting thing here.

On this, we will see an ActivityClientRecord object, which is actually our Activity

And it seems that each method has done something that we are very familiar with, and sendMessage () sends out the currently created Activity.

When we get here, we will find that eventually we are calling the message communication mechanism of Handler, that is to say, we can sum up here.

When the state of Activity changes, a corresponding message will be sent.

And when I receive it, I can find that different handlerXXXActivity methods are called here in different states when it is sent.

Here, we seem to have found traces of the life cycle of Activity, so in fact, so far, we can draw a conclusion.

During the operation of Application, the state transition of Activity is actually accomplished through the Handler message mechanism.

In Application, you just send it, and the message mechanism is responsible for calling it, because in the main method, our Looper rotational trainer is always training in rotation.

And when we were loading Activity, we called a performLaunchActivity () method, and I found traces of our onCreate call in the middle.

That is to say, so far we can understand what the whole process of Application loading Activity is all about.

So the next thing we need to focus on is what the setContentView we wrote in onCreate did.

2.setContentView

In onCreate, we often use setContentView to set up our own layout files or view, so what exactly does he do in this process? By looking at the source code, I found the final location of the PhoneWindow class through a series of clues.

At this time, we will see that he has done two things, one is installDecor and the other is inflate. It is not difficult to guess that he is parsing the layout file. We think she is initializing something.

When he came in, he found that he had initialized two things, one called mDecor and the other called mContentParent.

We see that mDecor is a DecorView.

MContentParent is a ViewGroup.

Through the translation of notes, we can actually know exactly what these two are for.

/ / This is the view in which the window contents are placed. It is either (this is the view where the contents of the window are placed)

/ / mDecor itself, or a child of mDecor where the contents go. (it is either mDecor itself or a subclass of mDecor.)

/ / This is the top-level view of the window, containing the window decor. (this is the top-level View in the middle of the window, containing the decor of the window)

One represents the top-level view, and the other is used to hold the contents of the view below it.

As we moved on, we found that in the generateLayout method, we found that a large number of requestFeature calls were made here, that is, our requestFeature

Then at the bottom of my door, I will find that I am doing something.

At present, the layout file is loaded and a view is generated, but it doesn't seem to be our own.

So we need to find out what he loaded.

This is what I found a more interesting component.

I saw a note like this on this.

/ / This is an optimized layout for a screen, with the minimum set of features

Enabled.

This is an optimized layout of the screen with the smallest feature set enabled.

Through annotation and some data analysis, a relatively cramped result is obtained.

This is a default rendering of DecorView, and then our own layout is rendered on her FrameLayout.

So here we can now understand that installDector actually initializes two view containers, and then loads the R resources and features of the system, resulting in a basic layout.

So let's go back to another method we focused on earlier, mLayoutInflater.inflate (layoutResID, mContentParent).

This method is easier to understand.

We can get a message on this note.

/ / Inflate a new view hierarchy from the specified xml resource. (get the attempted hierarchy from the specified view, which means that you are now loading your own resources)

And the specific process will not be pasted with the code. I'll give you a picture.

Well, here we can understand that setContentView actually does two core things, that is, loading the environment configuration and its own layout. Then the next thing we need to consider is, how on earth did he draw on the interface?

How is 3.UI drawn?

Through the previous two chapters, we learned about the program's call to the activity life cycle and the origin of our view resources. This is what we need to find. Where is the starting point of our drawing?

When ActivityThread started, I found that after loading the handleLaunchActivity method and calling the performLaunchActivity method, I called a handleResumeActivity, and here I found the beginning of the drawing process.

Through the previous process, we know that after the onCreate trip is completed, all resources will be handed over to WindowManager for safekeeping.

Here, we give our VIew to WindowManager, where addView is called

After entering addView, we found a piece of code like this, he put the view, parameters and a ViewRoot object of our door in a container, so here we can find that all the related objects are saved.

MViews saves the View object, DecorView

MRoots saves ViewRootImpl objects associated with the top-level View

MParams holds the layout parameter that creates the top-level View.

And the WindowManagerGlobal class is also responsible for communicating with WMS.

And at this point, there's a key code, root.setView, which gives our parameters and the view to ViewRoot at the same time, so let's take a look at what setView in ViewRoot does.

Finally, I found a step for me to understand here.

Here we will see that the setting of view.assignParent is this, that is to say, in view, parent is actually ViewRoot

So in setContentView, you call a setLayoutParams () that is the ViewRoot of the call.

In ViewRoot, we found the call of setLayoutParams and preformLayout to the requestLayout method.

I found the call to the scheduleTraversals method in requestLayout and the access to doTraversal in scheduleTraversals, and finally accessed performTraversals (), and in this, I found the call to the overall drawing process.

At present, it is used in turn.

UI drawing first goes back to measure the layout, and then the layout is placed, and when all the layout measurements are placed, the drawing is carried out.

The above is all the content of this article "what is the UI drawing process?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.