Android应用setContentView与LayoutInflater加载解析机制源码分析

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】

1 背景

其实之所以要说这个话题有几个原因：

  1. 理解xml等控件是咋被显示的原理，通常大家写代码都是直接在onCreate里setContentView就完事，没怎么关注其实现原理。
  2. 前面分析《Android触摸屏事件派发机制详解与源码分析三(Activity篇)》时提到了一些关于布局嵌套的问题，当时没有深入解释。

所以接下来主要分析的就是View或者ViewGroup对象是如何添加至应用程序界面（窗口）显示的。我们准备从Activity的setContentView方法开始来说（因为默认Activity中放入我们的xml或者Java控件是通过setContentView方法来操作的，当调运了setContentView所有的控件就得到了显示）。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】

2 Android5.1.1（API 22）从Activity的setContentView方法说起

2-1 Activity的setContentView方法解析

Activity的源码中提供了三个重载的setContentView方法，如下：

    public void setContentView(int layoutResID) {
        getWindow().setContentView(layoutResID);
        initWindowDecorActionBar();
    }

    public void setContentView(View view) {
        getWindow().setContentView(view);
        initWindowDecorActionBar();
    }

    public void setContentView(View view, ViewGroup.LayoutParams params) {
        getWindow().setContentView(view, params);
        initWindowDecorActionBar();
    }

可以看见他们都先调运了getWindow()的setContentView方法，然后调运Activity的initWindowDecorActionBar方法，关于initWindowDecorActionBar方法后面准备写一篇关于Android ActionBar原理解析的文章，所以暂时跳过不解释。

2-2 关于窗口Window类的一些关系

在开始分析Activity组合对象Window的setContentView方法之前请先明确如下关系（前面分析《Android触摸屏事件派发机制详解与源码分析三(Activity篇)》时也有说过）。

看见上面图没？Activity中有一个成员为Window，其实例化对象为PhoneWindow，PhoneWindow为抽象Window类的实现类。

这里先简要说明下这些类的职责：

  1. Window是一个抽象类，提供了绘制窗口的一组通用API。
  2. PhoneWindow是Window的具体继承实现类。而且该类内部包含了一个DecorView对象，该DectorView对象是所有应用窗口(Activity界面)的根View。
  3. DecorView是PhoneWindow的内部类，是FrameLayout的子类，是对FrameLayout进行功能的修饰（所以叫DecorXXX），是所有应用窗口的根View 。

依据面向对象从抽象到具体我们可以类比上面关系就像如下：

Window是一块电子屏，PhoneWindow是一块手机电子屏，DecorView就是电子屏要显示的内容，Activity就是手机电子屏安装位置。

2-2 窗口PhoneWindow类的setContentView方法

我们可以看见Window类的setContentView方法都是抽象的。所以我们直接先看PhoneWindow类的setContentView(int layoutResID)方法源码，如下：

    public void setContentView(int layoutResID) {
        // Note: FEATURE_CONTENT_TRANSITIONS may be set in the process of installing the window
        // decor, when theme attributes and the like are crystalized. Do not check the feature
        // before this happens.
        if (mContentParent == null) {
            installDecor();
        } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
            mContentParent.removeAllViews();
        }

        if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
            final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
                    getContext());
            transitionTo(newScene);
        } else {
            mLayoutInflater.inflate(layoutResID, mContentParent);
        }
        final Callback cb = getCallback();
        if (cb != null && !isDestroyed()) {
            cb.onContentChanged();
        }
    }

可以看见，第五行首先判断mContentParent是否为null，也就是第一次调运）；如果是第一次调用，则调用installDecor()方法，否则判断是否设置FEATURE_CONTENT_TRANSITIONS Window属性（默认false），如果没有就移除该mContentParent内所有的所有子View；接着16行mLayoutInflater.inflate(layoutResID, mContentParent);将我们的资源文件通过LayoutInflater对象转换为View树，并且添加至mContentParent视图中（其中mLayoutInflater是在PhoneWindow的构造函数中得到实例对象的LayoutInflater.from(context);）。

再来看下PhoneWindow类的setContentView(View view)方法和setContentView(View view, ViewGroup.LayoutParams params)方法源码，如下：

    @Override
    public void setContentView(View view) {
        setContentView(view, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
    }

    @Override
    public void setContentView(View view, ViewGroup.LayoutParams params) {
        // Note: FEATURE_CONTENT_TRANSITIONS may be set in the process of installing the window
        // decor, when theme attributes and the like are crystalized. Do not check the feature
        // before this happens.
        if (mContentParent == null) {
            installDecor();
        } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
            mContentParent.removeAllViews();
        }

        if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
            view.setLayoutParams(params);
            final Scene newScene = new Scene(mContentParent, view);
            transitionTo(newScene);
        } else {
            mContentParent.addView(view, params);
        }
        final Callback cb = getCallback();
        if (cb != null && !isDestroyed()) {
            cb.onContentChanged();
        }
    }

看见没有，我们其实只用分析setContentView(View view, ViewGroup.LayoutParams params)方法即可，如果你在Activity中调运setContentView(View view)方法，实质也是调运setContentView(View view, ViewGroup.LayoutParams params)，只是LayoutParams设置为了MATCH_PARENT而已。

所以直接分析setContentView(View view, ViewGroup.LayoutParams params)方法就行，可以看见该方法与setContentView(int layoutResID)类似，只是少了LayoutInflater将xml文件解析装换为View而已，这里直接使用View的addView方法追加道了当前mContentParent而已。

所以说在我们的应用程序里可以多次调用setContentView()来显示界面，因为会removeAllViews。

2-3 窗口PhoneWindow类的installDecor方法

回过头，我们继续看上面PhoneWindow类setContentView方法的第6行installDecor();代码，在PhoneWindow中查看installDecor源码如下：

    private void installDecor() {
        if (mDecor == null) {
            mDecor = generateDecor();
            mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
            mDecor.setIsRootNamespace(true);
            if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
                mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
            }
        }
        if (mContentParent == null) {
            //根据窗口的风格修饰，选择对应的修饰布局文件，并且将id为content的FrameLayout赋值给mContentParent
            mContentParent = generateLayout(mDecor);
            //......
            //初始化一堆属性值
        }
    }

我勒个去！又是一个死长的方法，抓重点分析吧。第2到9行可以看出，首先判断mDecor对象是否为空，如果为空则调用generateDecor()创建一个DecorView(该类是

FrameLayout子类，即一个ViewGroup视图)，然后设置一些属性，我们看下PhoneWindow的generateDecor方法，如下：

    protected DecorView generateDecor() {
        return new DecorView(getContext(), -1);
    }

可以看见generateDecor方法仅仅是new一个DecorView的实例。

回到installDecor方法继续往下看，第10行开始到方法结束都需要一个if (mContentParent == null)判断为真才会执行，当mContentParent对象不为空则调用generateLayout()方法去创建mContentParent对象。所以我们看下generateLayout方法源码，如下：

    protected ViewGroup generateLayout(DecorView decor) {
        // Apply data from current theme.

        TypedArray a = getWindowStyle();

        //......
        //依据主题style设置一堆值进行设置

        // Inflate the window decor.

        int layoutResource;
        int features = getLocalFeatures();
        //......
        //根据设定好的features值选择不同的窗口修饰布局文件,得到layoutResource值

        //把选中的窗口修饰布局文件添加到DecorView对象里，并且指定contentParent值
        View in = mLayoutInflater.inflate(layoutResource, null);
        decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
        mContentRoot = (ViewGroup) in;

        ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
        if (contentParent == null) {
            throw new RuntimeException("Window couldn‘t find content container view");
        }

        //......
        //继续一堆属性设置，完事返回contentParent
        return contentParent;
    }

可以看见上面方法主要作用就是根据窗口的风格修饰类型为该窗口选择不同的窗口根布局文件。mDecor做为根视图将该窗口根布局添加进去，然后获取id为content的FrameLayout返回给mContentParent对象。所以installDecor方法实质就是产生mDecor和mContentParent对象。

在这里顺带提一下：还记得我们平时写应用Activity时设置的theme或者feature吗（全屏啥的，NoTitle等）？我们一般是不是通过XML的android:theme属性或者java的requestFeature()方法来设置的呢？譬如：

通过java文件设置：

requestWindowFeature(Window.FEATURE_NO_TITLE);

通过xml文件设置：

android:theme="@android:style/Theme.NoTitleBar"

对的，其实我们平时requestWindowFeature()设置的值就是在这里通过getLocalFeature()获取的；而android:theme属性也是通过这里的getWindowStyle()获取的。

所以这下你应该就明白在java文件设置Activity的属性时必须在setContentView方法之前调用requestFeature()方法的原因了吧。

我们继续关注一下generateLayout方法的layoutResource变量赋值情况。因为它最终通过View in = mLayoutInflater.inflate(layoutResource, null);和decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));将in添加到PhoneWindow的mDecor对象。为例验证这一段代码分析我们用一个实例来进行说明，如下是一个简单的App主要代码：

AndroidManifest.xml文件

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.yanbober.myapplication" >

    <application
        ......
        //看重点，我们将主题设置为NoTitleBar
        android:theme="@android:style/Theme.Black.NoTitleBar" >
        ......
    </application>

</manifest>

主界面布局文件：

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView android:text="@string/hello_world"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

</RelativeLayout>

APP运行界面：

看见没有，上面我们将主题设置为NoTitleBar，所以在generateLayout方法中的layoutResource变量值为R.layout.screen_simple，所以我们看下系统这个screen_simple.xml布局文件，如下：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true"
    android:orientation="vertical">
    <ViewStub android:id="@+id/action_mode_bar_stub"
              android:inflatedId="@+id/action_mode_bar"
              android:layout="@layout/action_mode_bar"
              android:layout_width="match_parent"
              android:layout_height="wrap_content"
              android:theme="?attr/actionBarTheme" />
    <FrameLayout
         android:id="@android:id/content"
         android:layout_width="match_parent"
         android:layout_height="match_parent"
         android:foregroundInsidePadding="false"
         android:foregroundGravity="fill_horizontal|top"
         android:foreground="?android:attr/windowContentOverlay" />
</LinearLayout>

布局中，一般会包含ActionBar，Title，和一个id为content的FrameLayout，这个布局是NoTitle的。

再来看下上面这个App的hierarchyviewer图谱，如下：

看见了吧，通过这个App的hierarchyviewer和系统screen_simple.xml文件比较就验证了上面我们分析的结论，不再做过多解释。

然后回过头可以看见上面PhoneWindow类的setContentView方法最后通过调运mLayoutInflater.inflate(layoutResID, mContentParent);或者mContentParent.addView(view, params);语句将我们的xml或者java View插入到了mContentParent（id为content的FrameLayout对象）ViewGroup中。最后setContentView还会调用一个Callback接口的成员函数onContentChanged来通知对应的Activity组件视图内容发生了变化。

2-4 Window类内部接口Callback的onContentChanged方法

上面刚刚说了PhoneWindow类的setContentView方法中最后调运了onContentChanged方法。我们这里看下setContentView这段代码，如下：

    public void setContentView(int layoutResID) {
        ......
        final Callback cb = getCallback();
        if (cb != null && !isDestroyed()) {
            cb.onContentChanged();
        }
    }

看着没有，首先通过getCallback获取对象cb（回调接口），PhoneWindow没有重写Window的这个方法，所以到抽象类Window中可以看到：

    /**
     * Return the current Callback interface for this window.
     */
    public final Callback getCallback() {
        return mCallback;
    }

这个mCallback在哪赋值的呢，继续看Window类发现有一个方法，如下：

    public void setCallback(Callback callback) {
        mCallback = callback;
    }

Window中的mCallback是通过这个方法赋值的，那就回想一下，Window又是Activity的组合成员，那就是Activity一定调运这个方法了，回到Activity发现在Activity的attach方法中进行了设置，如下：

    final void attach(Context context, ActivityThread aThread,
        ......
        mWindow.setCallback(this);
        ......
    }

也就是说Activity类实现了Window的Callback接口。那就是看下Activity实现的onContentChanged方法。如下：

    public void onContentChanged() {
    }

咦？onContentChanged是个空方法。那就说明当Activity的布局改动时，即setContentView()或者addContentView()方法执行完毕时就会调用该方法。

所以当我们写App时，Activity的各种View的findViewById()方法等都可以放到该方法中，系统会帮忙回调。

2-5 setContentView源码分析总结

可以看出来setContentView整个过程主要是如何把Activity的布局文件或者java的View添加至窗口里，上面的过程可以重点概括为：

  1. 创建一个DecorView的对象mDecor，该mDecor对象将作为整个应用窗口的根视图。
  2. 依据Feature等style theme创建不同的窗口修饰布局文件，并且通过findViewById获取Activity布局文件该存放的地方（窗口修饰布局文件中id为content的FrameLayout）。
  3. 将Activity的布局文件添加至id为content的FrameLayout内。

至此整个setContentView的主要流程就分析完毕。你可能这时会疑惑，这么设置完一堆View关系后系统是怎么知道该显示了呢？下面我们就初探一下关于Activity的setContentView在onCreate中如何显示的（声明一下，这里有些会暂时直接给出结论，该系列文章后面会详细分析的）。

2-6 setContentView完以后Activity显示界面初探

这一小部分已经不属于sentContentView的分析范畴了，只是简单说明setContentView之后怎么被显示出来的（注意：Activity调运setContentView方法自身不会显示布局的）。

记得前面有一篇文章《Android异步消息处理机制详解及源码分析》的3-1-2小节说过，一个Activity的开始实际是ActivityThread的main方法（至于为什么后面会写文章分析，这里站在应用层角度先有这个概念就行）。

那在这一篇我们再直接说一个知识点（至于为什么后面会写文章分析，这里站在应用层角度先有这个概念就行）。

当启动Activity调运完ActivityThread的main方法之后，接着调用ActivityThread类performLaunchActivity来创建要启动的Activity组件，在创建Activity组件的过程中，还会为该Activity组件创建窗口对象和视图对象；接着Activity组件创建完成之后，通过调用ActivityThread类的handleResumeActivity将它激活。

所以我们先看下handleResumeActivity方法一个重点，如下：

    final void handleResumeActivity(IBinder token,
            boolean clearHide, boolean isForward, boolean reallyResume) {
        // If we are getting ready to gc after going to the background, well
        // we are back active so skip it.
        ......
        // TODO Push resumeArgs into the activity for consideration
        ActivityClientRecord r = performResumeActivity(token, clearHide);

        if (r != null) {
            ......
            // If the window hasn‘t yet been added to the window manager,
            // and this guy didn‘t finish itself or start another activity,
            // then go ahead and add the window.
            ......
            // If the window has already been added, but during resume
            // we started another activity, then don‘t yet make the
            // window visible.
            ......
            // The window is now visible if it has been added, we are not
            // simply finishing, and we are not starting another activity.
            if (!r.activity.mFinished && willBeVisible
                    && r.activity.mDecor != null && !r.hideForNow) {
                ......
                if (r.activity.mVisibleFromClient) {
                    r.activity.makeVisible();
                }
            }
            ......
        } else {
            // If an exception was thrown when trying to resume, then
            // just end this activity.
            ......
        }
    }

看见r.activity.makeVisible();语句没？调用Activity的makeVisible方法显示我们上面通过setContentView创建的mDecor视图族。所以我们看下Activity的makeVisible方法，如下：

    void makeVisible() {
        if (!mWindowAdded) {
            ViewManager wm = getWindowManager();
            wm.addView(mDecor, getWindow().getAttributes());
            mWindowAdded = true;
        }
        mDecor.setVisibility(View.VISIBLE);
    }

看见没有，通过DecorView（FrameLayout，也即View）的setVisibility方法将View设置为VISIBLE，至此显示出来。

到此setContentView的完整流程分析完毕。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】

3 Android5.1.1（API 22）看看LayoutInflater机制原理

上面在分析setContentView过程中可以看见，在PhoneWindow的setContentView中调运了mLayoutInflater.inflate(layoutResID, mContentParent);，在PhoneWindow的generateLayout中调运了View in = mLayoutInflater.inflate(layoutResource, null);，当时我们没有详细分析，只是告诉通过xml得到View对象。现在我们就来分析分析这一问题。

3-1 通过实例引出问题

在开始之前我们先来做一个测试，我们平时最常见的就是ListView的Adapter中使用LayoutInflater加载xml的item布局文件，所以咱们就以ListView为例，如下：

省略掉Activity代码等，首先给出Activity的布局文件，如下：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <ListView
        android:id="@+id/listview"
        android:dividerHeight="5dp"
        android:layout_width="match_parent"
        android:layout_height="match_parent"></ListView>

</LinearLayout>

给出两种不同的ListView的item布局文件。

textview_layout.xml文件：

<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="100dp"
    android:layout_height="40dp"
    android:text="Text Test"
    android:background="#ffa0a00c"/>

textview_layout_parent.xml文件：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    xmlns:android="http://schemas.android.com/apk/res/android">

    <TextView xmlns:android="http://schemas.android.com/apk/res/android"
        android:layout_width="100dp"
        android:layout_height="40dp"
        android:text="Text Test"
        android:background="#ffa0a00c"/>

</LinearLayout>

ListView的自定义Adapter文件：

public class InflateAdapter extends BaseAdapter {
    private LayoutInflater mInflater = null;

    public InflateAdapter(Context context) {
        mInflater = LayoutInflater.from(context);
    }

    @Override
    public int getCount() {
        return 8;
    }

    @Override
    public Object getItem(int position) {
        return null;
    }

    @Override
    public long getItemId(int position) {
        return 0;
    }

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        //说明：这里是测试inflate方法参数代码，不再考虑性能优化等TAG处理
        return getXmlToView(convertView, position, parent);
    }

    private View getXmlToView(View convertView, int position, ViewGroup parent) {
        View[] viewList = {
                mInflater.inflate(R.layout.textview_layout, null),
//                mInflater.inflate(R.layout.textview_layout, parent),
                mInflater.inflate(R.layout.textview_layout, parent, false),
//                mInflater.inflate(R.layout.textview_layout, parent, true),
                mInflater.inflate(R.layout.textview_layout, null, true),
                mInflater.inflate(R.layout.textview_layout, null, false),

                mInflater.inflate(R.layout.textview_layout_parent, null),
//                mInflater.inflate(R.layout.textview_layout_parent, parent),
                mInflater.inflate(R.layout.textview_layout_parent, parent, false),
//                mInflater.inflate(R.layout.textview_layout_parent, parent, true),
                mInflater.inflate(R.layout.textview_layout_parent, null, true),
                mInflater.inflate(R.layout.textview_layout_parent, null, false),
        };

        convertView = viewList[position];

        return convertView;
    }
}

当前代码运行结果：

PS：当打开上面viewList数组中任意一行注释都会抛出异常（java.lang.UnsupportedOperationException: addView(View, LayoutParams) is not supported in AdapterView）。

你指定有些蒙圈了，而且比较郁闷，同时想弄明白inflate的这些参数都是啥意思。运行结果为何有这么大差异呢？

那我告诉你，你现在先别多想，记住这回事，咱们先看源码，下面会告诉你为啥。

3-2 从LayoutInflater源码实例化说起

我们先看一下源码中LayoutInflater实例化获取的方法：

    public static LayoutInflater from(Context context) {
        LayoutInflater LayoutInflater =
                (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        if (LayoutInflater == null) {
            throw new AssertionError("LayoutInflater not found.");
        }
        return LayoutInflater;
    }

看见没有？是否很熟悉？我们平时写应用获取LayoutInflater实例时不也就两种写法吗，如下：

    LayoutInflater lif = LayoutInflater.from(Context context);

    LayoutInflater lif = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

可以看见from方法仅仅是对getSystemService的一个安全封装而已。

3-3 LayoutInflater源码的View inflate(…)方法族剖析

得到LayoutInflater对象之后我们就是传递xml然后解析得到View，如下方法：

    public View inflate(int resource, ViewGroup root) {
        return inflate(resource, root, root != null);
    }

继续看inflate(int resource, ViewGroup root, boolean attachToRoot)方法，如下：

    public View inflate(int resource, ViewGroup root, boolean attachToRoot) {
        final Resources res = getContext().getResources();
        if (DEBUG) {
            Log.d(TAG, "INFLATING from resource: \"" + res.getResourceName(resource) + "\" ("
                    + Integer.toHexString(resource) + ")");
        }

        final XmlResourceParser parser = res.getLayout(resource);
        try {
            return inflate(parser, root, attachToRoot);
        } finally {
            parser.close();
        }
    }

这个方法的第8行获取到XmlResourceParser接口的实例（Android默认实现类为Pull解析XmlPullParser）。接着看第10行inflate(parser, root, attachToRoot);，你会发现无论哪个inflate重载方法最后都调运了inflate(XmlPullParser parser, ViewGroup root, boolean attachToRoot)方法，如下：

    public View inflate(XmlPullParser parser, ViewGroup root, boolean attachToRoot) {
        synchronized (mConstructorArgs) {
            Trace.traceBegin(Trace.TRACE_TAG_VIEW, "inflate");

            final AttributeSet attrs = Xml.asAttributeSet(parser);
            Context lastContext = (Context)mConstructorArgs[0];
            mConstructorArgs[0] = mContext;
            //定义返回值，初始化为传入的形参root
            View result = root;

            try {
                // Look for the root node.
                int type;
                while ((type = parser.next()) != XmlPullParser.START_TAG &&
                        type != XmlPullParser.END_DOCUMENT) {
                    // Empty
                }
                //如果一开始就是END_DOCUMENT，那说明xml文件有问题
                if (type != XmlPullParser.START_TAG) {
                    throw new InflateException(parser.getPositionDescription()
                            + ": No start tag found!");
                }
                //有了上面判断说明这里type一定是START_TAG，也就是xml文件里的root node
                final String name = parser.getName();

                if (DEBUG) {
                    System.out.println("**************************");
                    System.out.println("Creating root view: "
                            + name);
                    System.out.println("**************************");
                }

                if (TAG_MERGE.equals(name)) {
                //处理merge tag的情况（merge，你懂的，APP的xml性能优化）
                    //root必须非空且attachToRoot为true，否则抛异常结束（APP使用merge时要注意的地方，
                    //因为merge的xml并不代表某个具体的view，只是将它包起来的其他xml的内容加到某个上层
                    //ViewGroup中。）
                    if (root == null || !attachToRoot) {
                        throw new InflateException("<merge /> can be used only with a valid "
                                + "ViewGroup root and attachToRoot=true");
                    }
                    //递归inflate方法调运
                    rInflate(parser, root, attrs, false, false);
                } else {
                    // Temp is the root view that was found in the xml
                    //xml文件中的root view，根据tag节点创建view对象
                    final View temp = createViewFromTag(root, name, attrs, false);

                    ViewGroup.LayoutParams params = null;

                    if (root != null) {
                        if (DEBUG) {
                            System.out.println("Creating params from root: " +
                                    root);
                        }
                        // Create layout params that match root, if supplied
                        //根据root生成合适的LayoutParams实例
                        params = root.generateLayoutParams(attrs);
                        if (!attachToRoot) {
                            // Set the layout params for temp if we are not
                            // attaching. (If we are, we use addView, below)
                            //如果attachToRoot=false就调用view的setLayoutParams方法
                            temp.setLayoutParams(params);
                        }
                    }

                    if (DEBUG) {
                        System.out.println("-----> start inflating children");
                    }
                    // Inflate all children under temp
                    //递归inflate剩下的children
                    rInflate(parser, temp, attrs, true, true);
                    if (DEBUG) {
                        System.out.println("-----> done inflating children");
                    }

                    // We are supposed to attach all the views we found (int temp)
                    // to root. Do that now.
                    if (root != null && attachToRoot) {
                        //root非空且attachToRoot=true则将xml文件的root view加到形参提供的root里
                        root.addView(temp, params);
                    }

                    // Decide whether to return the root that was passed in or the
                    // top view found in xml.
                    if (root == null || !attachToRoot) {
                        //返回xml里解析的root view
                        result = temp;
                    }
                }

            } catch (XmlPullParserException e) {
                InflateException ex = new InflateException(e.getMessage());
                ex.initCause(e);
                throw ex;
            } catch (IOException e) {
                InflateException ex = new InflateException(
                        parser.getPositionDescription()
                        + ": " + e.getMessage());
                ex.initCause(e);
                throw ex;
            } finally {
                // Don‘t retain static reference on context.
                mConstructorArgs[0] = lastContext;
                mConstructorArgs[1] = null;
            }

            Trace.traceEnd(Trace.TRACE_TAG_VIEW);
            //返回参数root或xml文件里的root view
            return result;
        }
    }

从上面的源码分析我们可以看出inflate方法的参数含义：

  • inflate(xmlId, null); 只创建temp的View，然后直接返回temp。
  • inflate(xmlId, parent); 创建temp的View，然后执行root.addView(temp, params);最后返回root。
  • inflate(xmlId, parent, false); 创建temp的View，然后执行temp.setLayoutParams(params);然后再返回temp。
  • inflate(xmlId, parent, true); 创建temp的View，然后执行root.addView(temp, params);最后返回root。
  • inflate(xmlId, null, false); 只创建temp的View，然后直接返回temp。
  • inflate(xmlId, null, true); 只创建temp的View，然后直接返回temp。

到此其实已经可以说明我们上面示例部分执行效果差异的原因了（在此先强调一个Android的概念，下一篇文章我们会对这段话作一解释：我们经常使用View的layout_width和layout_height来设置View的大小，而且一般都可以正常工作，所以有人时常认为这两个属性就是设置View的真实大小一样；然而实际上这些属性是用于设置View在ViewGroup布局中的大小的；这就是为什么Google的工程师在变量命名上将这种属性叫作layout_width和layout_height，而不是width和height的原因了。），如下：

  • mInflater.inflate(R.layout.textview_layout, null)不能正确处理我们设置的宽和高是因为layout_width，layout_height是相对了父级设置的，而此temp的getLayoutParams为null。
  • mInflater.inflate(R.layout.textview_layout, parent)能正确显示我们设置的宽高是因为我们的View在设置setLayoutParams时params = root.generateLayoutParams(attrs)不为空。

    Inflate(resId , parent,false ) 可以正确处理，因为temp.setLayoutParams(params);这个params正是root.generateLayoutParams(attrs);得到的。

  • mInflater.inflate(R.layout.textview_layout, null, true)与mInflater.inflate(R.layout.textview_layout, null, false)不能正确处理我们设置的宽和高是因为layout_width，layout_height是相对了父级设置的，而此temp的getLayoutParams为null。
  • textview_layout_parent.xml作为item可以正确显示的原因是因为TextView具备上级ViewGroup，上级ViewGroup的layout_width，layout_height会失效，当前的TextView会有效而已。
  • 上面例子中说放开那些注释运行会报错java.lang.UnsupportedOperationException:

    addView(View, LayoutParams) is not supported是因为AdapterView源码中调用了root.addView(temp, params);而此时的root是我们的ListView，ListView为AdapterView的子类，所以我们看下AdapterView抽象类中addView源码即可明白为啥了，如下：

    /**
     * This method is not supported and throws an UnsupportedOperationException when called.
     *
     * @param child Ignored.
     *
     * @throws UnsupportedOperationException Every time this method is invoked.
     */
    @Override
    public void addView(View child) {
        throw new UnsupportedOperationException("addView(View) is not supported in AdapterView");
    }

这里不再做过多解释。

咦？别急，到这里指定机智的人会问，我们在写App时Activity中指定布局文件的时候，xml布局文件或者我们用java编写的View最外层的那个布局是可以指定大小的啊？他们最外层的layout_width和layout_height都是有作用的啊？

是这样的，还记得我们上面的分析吗？我们自己的xml布局通过setContentView()方法放置到哪去了呢？记不记得id为content的FrameLayout呢？所以我们xml或者java的View的最外层布局的layout_width和layout_height属性才会有效果，就是这么回事而已。

3-4 LayoutInflater源码inflate(…)方法中调运的一些非public方法剖析

看下inflate方法中被调运的rInflate方法，源码如下：

    void rInflate(XmlPullParser parser, View parent, final AttributeSet attrs,
            boolean finishInflate, boolean inheritContext) throws XmlPullParserException,
            IOException {

        final int depth = parser.getDepth();
        int type;
        //XmlPullParser解析器的标准解析模式
        while (((type = parser.next()) != XmlPullParser.END_TAG ||
                parser.getDepth() > depth) && type != XmlPullParser.END_DOCUMENT) {
            //找到START_TAG节点程序才继续执行这个判断语句之后的逻辑
            if (type != XmlPullParser.START_TAG) {
                continue;
            }
            //获取Name标记
            final String name = parser.getName();
            //处理REQUEST_FOCUS的标记
            if (TAG_REQUEST_FOCUS.equals(name)) {
                parseRequestFocus(parser, parent);
            } else if (TAG_TAG.equals(name)) {
                //处理tag标记
                parseViewTag(parser, parent, attrs);
            } else if (TAG_INCLUDE.equals(name)) {
                //处理include标记
                if (parser.getDepth() == 0) {
                    //include节点如果是根节点就抛异常
                    throw new InflateException("<include /> cannot be the root element");
                }
                parseInclude(parser, parent, attrs, inheritContext);
            } else if (TAG_MERGE.equals(name)) {
                //merge节点必须是xml文件里的根节点（这里不该再出现merge节点）
                throw new InflateException("<merge /> must be the root element");
            } else {
                //其他自定义节点
                final View view = createViewFromTag(parent, name, attrs, inheritContext);
                final ViewGroup viewGroup = (ViewGroup) parent;
                final ViewGroup.LayoutParams params = viewGroup.generateLayoutParams(attrs);
                rInflate(parser, view, attrs, true, true);
                viewGroup.addView(view, params);
            }
        }
        //parent的所有子节点都inflate完毕的时候回onFinishInflate方法
        if (finishInflate) parent.onFinishInflate();
    }

可以看见，上面方法主要就是循环递归解析xml文件，解析结束回调View类的onFinishInflate方法，所以View类的onFinishInflate方法是一个空方法，如下：

    /**
     * Finalize inflating a view from XML.  This is called as the last phase
     * of inflation, after all child views have been added.
     *
     * <p>Even if the subclass overrides onFinishInflate, they should always be
     * sure to call the super method, so that we get called.
     */
    protected void onFinishInflate() {
    }

可以看见，当我们自定义View时在构造函数inflate一个xml后可以实现onFinishInflate这个方法一些自定义的逻辑。

至此LayoutInflater的源码核心部分已经分析完毕。

4 总结

至此整个Activity的setContentView与Android的LayoutInflater相关原理都已经分析完毕。关于本篇中有些地方直接给出结论的知识点后面的文章中会做一说明。

setContentView整个过程主要是如何把Activity的布局文件或者java的View添加至窗口里，重点概括为：

  1. 创建一个DecorView的对象mDecor，该mDecor对象将作为整个应用窗口的根视图。
  2. 依据Feature等style theme创建不同的窗口修饰布局文件，并且通过findViewById获取Activity布局文件该存放的地方（窗口修饰布局文件中id为content的FrameLayout）。
  3. 将Activity的布局文件添加至id为content的FrameLayout内。

LayoutInflater的使用中重点关注inflate方法的参数含义：

  • inflate(xmlId, null); 只创建temp的View，然后直接返回temp。
  • inflate(xmlId, parent); 创建temp的View，然后执行root.addView(temp, params);最后返回root。
  • inflate(xmlId, parent, false); 创建temp的View，然后执行temp.setLayoutParams(params);然后再返回temp。
  • inflate(xmlId, parent, true); 创建temp的View，然后执行root.addView(temp, params);最后返回root。
  • inflate(xmlId, null, false); 只创建temp的View，然后直接返回temp。
  • inflate(xmlId, null, true); 只创建temp的View，然后直接返回temp。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】

时间： 2024-10-12 12:30:36

Android应用setContentView与LayoutInflater加载解析机制源码分析的相关文章

Openstack学习笔记之——Neutron-server服务加载与启动源码分析（三）

本文是在学习Openstack的过程中整理和总结,由于时间和个人能力有限,错误之处在所难免,欢迎指正! 在Neutron-server服务加载与启动源码分析(二)中搞定模块功能的扩展和加载,我们就回到Neutron-server服务加载与启动源码分析(一)中的_run_wsgi函数 <span style="font-size:14px;">def _run_wsgi(app_name): app = config.load_paste_app(app_name) ifno

Android Studio 3.5测试版加载SDK java源码

参考博客:http://blog.sina.com.cn/s/blog_c3eb50230102wt1g.html 1.下载adnroid-28的源码 在Android Studio中加载不到源码的下载链接,所在在Android Studio中下载不到源码. 所以,需要借助 android-sdk_r24.4.1-windows.zip 下载源码,这个zip的下载链接 https://dl.google.com/android/android-sdk_r24.4.1-windows.zip?ut

setContentView加载解析过程源码分析

Activity的setContentView方法 Activity的源码中提供了三个重载的setContentView方法,如下: public void setContentView(int layoutResID) { getWindow().setContentView(layoutResID); initWindowDecorActionBar(); } public void setContentView(View view) { getWindow().setContentView

Android图片加载库Picasso源码分析

图片加载在Android开发中是非常重要,好的图片加载库也比比皆是.ImageLoader.Picasso.Glide.Fresco均是优秀的图片加载库. 以上提到的几种图片加载库各有特色.用法与比较,网上已经很多了. 出于学习的角度,个人认为从Picasso入手较好.代码量小,同时API优美,很适合我们学习. 今天笔者就Picasso的源码进行分析,抛出一些图片加载的技术细节供园友参考. PS:建议园友先大致看一下源码. 我们对图片加载的要求 1.加载速度要快 2.资源消耗要低 3.加载图片不

别翻了，这篇文章绝对让你深刻理解java类的加载以及ClassLoader源码分析【JVM篇二】

目录 1.什么是类的加载(类初始化) 2.类的生命周期 3.接口的加载过程 4.解开开篇的面试题 5.理解首次主动使用 6.类加载器 7.关于命名空间 8.JVM类加载机制 9.双亲委派模型 10.ClassLoader源码分析 11.自定义类加载器 12.加载类的三种方式 13.总结 14.特别注意 @ 前言 你是否真的理解java的类加载机制?点进文章的盆友不如先来做一道非常常见的面试题,如果你能做出来,可能你早已掌握并理解了java的类加载机制,若结果出乎你的意料,那就很有必要来了解了解j

Android开发学习之路-Handler消息派发机制源码分析

注:这里只是说一下sendmessage的一个过程,post就类似的 如果我们需要发送消息,会调用sendMessage方法 public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); } 这个方法会调用如下的这个方法 public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMilli

android Listview分批加载+自动加载（附源码下载）

直接上代码,代码有注释: public class TestForListviewActivity extends Activity implements OnScrollListener { private ListView mListview = null; private View mFooterView; private PaginationAdapter mAdapter; private Handler handler=new Handler(); private boolean i

Android -- 消息处理机制源码分析(Looper,Handler,Message)

android的消息处理有三个核心类:Looper,Handler和Message.其实还有一个Message Queue(消息队列),但是MQ被封装到Looper里面了,我们不会直接与MQ打交道,因此我没将其作为核心类.下面一一介绍: Looper Looper的字面意思是“循环者”,它被设计用来使一个普通线程变成Looper线程.所谓Looper线程就是循环工作的线程.在程序开发中(尤其是GUI开发中),我们经常会需要一个线程不断循环,一旦有新任务则执行,执行完继续等待下一个任务,这就是Lo

Android 中View的绘制机制源码分析 二

尊重原创:http://blog.csdn.net/yuanzeyao/article/details/46842891 本篇文章接着上篇文章的内容来继续讨论View的绘制机制,上篇文章中我们主要讲解了View的measure过程,今天我们就来学习ViewGroup的measure过程,由于ViewGroup只是一个抽象类,所以我们需要以一个具体的布局来分析measure过程,正如我上篇文章说的,我打算使用LinearLayout为例讲解measure过程,如果你还没有读过上篇文章,那么建议你先