View. Inflate (context, layoutResId, root) encapsulates the layoutinflater. from(context).inflate(layoutResId, root, attachToRoot)

The following method is eventually called, which results in different results depending on the parameters passed in

    public View inflate(XmlPullParser parser, @Nullable ViewGroup root, boolean attachToRoot) {
        synchronized(mConstructorArgs) { View result = root; . ViewGroup.LayoutParams params =null;

                    if(root ! =null) {
                        // Create layout params that match root, if supplied
                        params = root.generateLayoutParams(attrs);
                        if(! attachToRoot) {// Set the layout params for temp if we are not
                            // attaching. (If we are, we use addView, below)temp.setLayoutParams(params); }}if(root ! =null && attachToRoot) {
                        root.addView(temp, params);
                    }
                    
                    if (root == null || !attachToRoot) {
                        result = temp;
                    }
                }

            returnresult; }}Copy the code

Layoutinflater.inflate (layoutResId, layoutResId, root) is called when view.inflate (context, layoutResId, root) is invoked Root) and then call layoutinflater.inflate (layoutResId, root, root! = null).

Root == null when you call view.inflate (context, layoutResId, root) is actually equivalent to layoutinflater.from (context).inflate(layoutResId, null, False), while root! = null equivalent to layoutinflater.from (context).inflate(layoutResId, root, true) View (context, layoutResId, root) and LayoutInflater. From (context).inflate(layoutResId, root, The similarities and differences of attachToRoot (attachToRoot) are actually discussed in the case of different root and attachToRoot parameters.

1 differences in representation on direct code

1.1 root == null.attachToRoot == false(As long asrootfornull.attachToRootIt doesn’t matter what value I pick. I pick it herefalse)

This is the layoutinflater.from (context).inflate(layoutResId, null, false) when the view.inflate (context, layoutResId, null) is invoked. The inflate method posted at the beginning of this article is executed, executing the corresponding logic

  View result = root;
    
  if (root == null| |! attachToRoot) { result = temp; }return result;
Copy the code

Return the view itself. The view is the view generated by parsing the layoutResId layout.

1.2 root ! = null.attachToRoot == true

This is the layoutinflater.from (context).inflate(layoutResId, root, true) when view.inflate (context, layoutResId, NULL) is invoked. The inflate method posted at the beginning of this article is executed, executing the corresponding logic

    View result = root;

    if(root ! =null) {
        // Create layout params that match root, if supplied
        params = root.generateLayoutParams(attrs);
    }

    if(root ! =null && attachToRoot) {
        root.addView(temp, params);
    }

    return result;
Copy the code

Set the parsed LayoutParams (with the width and height information declared in the XML corresponding to layoutResId) to the view and add it to root. Return the view’s parent layout root.

1.3 root ! = null.attachToRoot == false

You can only call layoutinflater.from (context).inflate(layoutResId, root, false) directly. Static inflaters in the View cannot do this. The logic executed in the inflate method posted at the top of this article is

    View result = root;

    if(root ! =null) {
        // Create layout params that match root, if supplied
        params = root.generateLayoutParams(attrs);
        if(! attachToRoot) {// Set the layout params for temp if we are not
            // attaching. (If we are, we use addView, below)temp.setLayoutParams(params); }}return result;
Copy the code

Set the parsed LayoutParams to the view (with the width and height information declared in the XML for layoutResId) and return the view itself.

2. Differences in process and control

The difference between the root and attachToRoot parameters that you can see will determine whether the view will be added to root, whether the view will be set with parsed LayoutParams, or even the return value.

But the difference that matters the most here is whether or not the view is set to parsed LayoutParams, which is the difference we care about the most. Why is that?

From the previous analysis, we know that return can be divided into the view itself and the parent layout of the view root. When we do reference, we must be clear about when to return what.

There is no difference between view.inflate and layoutinflater.inflate; they may return both values in either case.

Whether a view is added to the root is influenced by the attachToRoot parameter, which the developer passed in to control itself. The developer explicitly knows that they want to control when the view is added to the container, the object, and the added time is when the view is inflate (attachToRoot == True) or whenever (attachToRoot == False).

When we pass attachToRoot == true and inflater, we add the view to Root and parse the LayoutParams. It fits our expectations (the layout_width, layout_height, width and height values we declared in the layout XML). AttachToRoot == false, root is null, there is no parsed LayoutParams in the view, When we addView ourselves, we will give a default LayoutParams(WRAP_CONTENT, WRAP_CONTENT) that overrides the width and height of the layout XML declaration, invalidating our Settings.

conclusion

Inflate: By now we know why some experienced people say don’t use view.inflate but layoutinflater.inflate, The view.inflate (context, layoutResId, NULL) invalidates the width and height information we declare in the layoutResId layout (MATCH_PARENT or concrete width and height), You can substitute layoutinflater.from (context).inflate(layoutResId, root, false), which does not have this problem.