Android layoutinflator loading layout details and example code

Android layoutinflator loading layout details

For students with some Android development experience, they must have used layoutinflator. Inflator () to load layout files, but they do not necessarily study its principle, such as

1. Why can layouteinflator load layout files? 2. After loading the layout file, how does it become a view for us to use? 3. When we define the view, if we need to use it in the layout, we must implement the construction method with attributeset parameter. Why?

Since it is put forward in this article, it shows that these three problems are closely related to layoutinflator. During our analysis, we will answer these questions one by one.

Let's go step by step. First, when we need to load the view from the layout, we will call this method

1. How to create layoutinflator?

What's worth saying? If you open layoutinflator.java, you will naturally understand that layoutinflator is an abstract class, and the abstract class cannot be instantiated directly, that is, the object we create must be an implementation class of layoutinflator.

We enter the layoutinflator. From method and you can see

Well, it's the system service obtained! It's obtained from context. I haven't eaten pork and I haven't seen pigs running. When it comes to context objects, nine times out of ten it's contextimpl objects, so we go directly to contextimpl.java and find the getsystemservice method

Um... Go to the systemserviceregistry.java file again

According to the code, our service is from system_ SERVICE_ Fetchers is obtained from the HashMap. If you look at the code, you will find that the HashMap is assigned in the static module. Many system services, such as activityservice and alarmservice, are registered in the HashMap. As you can see from the layoutinflator.from method, we found context.layout_ INFLATER_ Service corresponding to service

Well, the protagonist is finally on the stage - phonelayouteinflator. The layouteinflator we get is the object of this class.

Well, the result of this part is that we found the phonelayoutinflator. We'll talk about its specific role later.

2. Inflator method analysis

This is the most important method, because it is this method that converts our layout into a view object. This method is directly defined in the layoutinflator abstract class

One of the parameters passed in is the ID of the layout and the other is whether to specify the parentview. We have to look at the real implementation

We first obtain the resources object from the context, and then obtain an XML file parser xmlresourceparser through the res.getlayout (resource) method (the XML file parser in Android will not be discussed in detail here, so as not to go too far. Students who do not know can find relevant materials on the Internet for reading), This actually loads the XML file that defines the layout.

Then, another inflate method continues to be called

This is a little longer. I have slightly removed some code that has nothing to do with logic and added comments. If I have the patience to read it, I should be able to understand it. There are two main parts here. The first is the method of rinflatchildren, which actually takes out all nodes layer by layer, and then converts them into view objects through the createviewfromtag method. So the focus is on how to convert it into a view object.

3.createViewFromTag

We follow up the code layer by layer and end up here

In order to facilitate understanding, the irrelevant code is removed. We can see that it is actually the createview method called to convert from XML node to view. If the name does not contain '.', call the oncreateview method; otherwise, call the createview method directly.

The oncreateview method is duplicated in the phonelayouteinflator above, and the method will eventually call createview whether overridden or not. The only difference should be that the full class name of the system view is provided by oncreateview. If it is a custom control, the full class name is used in the layout file.

4. Createview method

This code mainly does two things

First, load the class into memory according to the classname, and then get the specified constructor constructor. The constructor is specified by passing in the parameter type and quantity. Here, the mconstructorsignature is passed in

That is, the passed in parameters are context and attributeset. Did you suddenly wake up!!! This is why when we customize the view, we must override the view (context, attributeset, attrs) to use our view in the layout.

Second, use the obtained constructor to create a view instance.

5. Answer questions

Remember the three questions we mentioned above? Now let's answer them one by one:

1. Why can layouteinflator load layout files?

Because the layoutinflator actually loads XML files through an XML parser, and the format of the layout file is XML, it can be read.

2. After loading the layout file, how does it become a view for us to use?

After the layouteinflator loads the contents in the XML file, the name of each tag is taken out through reflection, and the corresponding class name is generated. Then, the constructor function of the class is obtained through reflection, and the parameters are context and attributeset. Then create the view object through the constructor.

3. When we define the view, if we need to use it in the layout, we must implement the construction method with attributeset parameter. Why?

When the layoutinflator parses the XML file, it will convert the content in the XML into an attributeset object, which contains the attribute values set in the XML file. You need to take out these attribute values in the constructor and assign them to the attributes of the instance.

Thank you for reading, hope to help you, thank you for your support to this site!