Android开发知识（二十二）LayoutInflater装载xml布局过程的源码解析
文章目录
- 前言
- LayoutInflater实例
- LayoutInflater的装载过程
- include 标签解析
- merge 标签解析
- attachToRoot参数解析
- View创建过程
- （1）判断view标签
- （2） 主题相关判断
- （3）BlinkLayout判断
- （4）自定义View的创建规则
- （5）View的默认创建规则
- （6）View的创建过程
- ViewStub源码解析
- 结束语
前言
本篇讲解的是LayoutInflater的装载过程，其中会涉及到include、merge、ViewStub标签的源码解析。
我们对LayoutInflater的使用是再熟悉不过了，日常操作都是先调用from方法然后调用inflate方法。而对LayoutInflater是如何把一个xml布局文件加载到界面上的过程可能不是很了解。
LayoutInflater实例
说起LayoutInflater，我们最熟悉的写法是：
LayoutInflater.from(context).inflate(R.layout.xx,null);
LayoutInflater的from方法源码是：
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;
}
可以看出实际上是调用context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
而LayoutInflater本身是一个抽象类，它的具体实现类是在ContextImpl的getSystemService方法中被实例化。
通常在getSystemService方法得到的Object都是来自于SystemServiceRegistry中的static代码块中去registerService的：
registerService(Context.LAYOUT_INFLATER_SERVICE, LayoutInflater.class,
new CachedServiceFetcher() {
@Override
public LayoutInflater createService(ContextImpl ctx) {
return new PhoneLayoutInflater(ctx.getOuterContext());
}});
由此可以知道，我们用的LayoutInflater实例都是来自于PhoneLayoutInflater，并且from方法并不会创建一个新的实例。
但是一看PhoneLayoutInflater并没有几行代码，由此判断基本逻辑都是在LayoutInflater这个抽象类中，我们只要关注LayoutInflater就行了
LayoutInflater的装载过程
那它是怎么装载布局的呢？我们调用inflate方法，经过重载后会到它是三个参数的重载方法:
public View inflate(@LayoutRes int resource, @Nullable 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();
}
}
经过这个方法把xml文件载入进来，XmlResourceParser继承了XmlPullParser，可以看出解析xml布局是基于Pull解析的（不了解XML几个解析方式的最好先自行百度下），最终重载调用到这个inflate方法（只举例部分重要代码）：
public View inflate(XmlPullParser parser, @Nullable ViewGroup root, boolean attachToRoot) {
...
final Context inflaterContext = mContext;
//XmlResourceParser也是实现了AttributeSet接口，转成AttributeSet后相当于对属性的一种封装，方便属性的获取。
final AttributeSet attrs = Xml.asAttributeSet(parser);
View result = root;
...
final String name = parser.getName();
//根标签是否是merge标签
if (TAG_MERGE.equals(name)) {
//merge标签的布局必须传入父view，并且attachToRoot=true，不然xml中零零散散的view不知道要被添加到哪里
if (root == null || !attachToRoot) {
throw new InflateException("接下来rInflateChildren，用来装载子布局的，实际是调用了rInflate方法：
final void rInflateChildren(XmlPullParser parser, View parent, AttributeSet attrs,
boolean finishInflate) throws XmlPullParserException, IOException {
//注意这里的context有区别于merge标签时传的context了
rInflate(parser, parent, parent.getContext(), attrs, finishInflate);
}
到这里有个重要的发现，就是在inflate中判断了是不是merge布局，最终都会走向rInflate方法，
不同的是 如果是merge布局，那么rInflate方法中的第二个参数传递的是root，也就是来自我们调用的inflate(R.layout.xx,root,true);，然后最后一个参数finishInflate是false，而且context是来自于from(context)
如果不是merge布局。那么的第二个参数传递的是temp，也就是调用createViewFromTag后解析出根布局的view，最后一个参数finishInflate传的是true，Context传的是View的getContext()
那么rInflate方法如下：
void rInflate(XmlPullParser parser, View parent, Context context,
AttributeSet attrs, boolean finishInflate) throws XmlPullParserException, IOException {
//获取xml标签的层级
final int depth = parser.getDepth();
int type;
//pull解析结束条件
while (((type = parser.next()) != XmlPullParser.END_TAG ||
parser.getDepth() > depth) && type != XmlPullParser.END_DOCUMENT) {
if (type != XmlPullParser.START_TAG) {
continue;
}
final String name = parser.getName();
if (TAG_REQUEST_FOCUS.equals(name)) {
parseRequestFocus(parser, parent);
} else if (TAG_TAG.equals(name)) {
parseViewTag(parser, parent, attrs);
} else if (TAG_INCLUDE.equals(name)) {
if (parser.getDepth() == 0) {
throw new InflateException("我们关注else分支的代码，这里面也就是一个递归，不断的调用createViewFromTag反射创建出View，然后把创建的View添加到传进来的Parent View上，
在前面我们说的如果是merge布局的话则需要传一个root，因为merge布局文件中是没有父布局的，需要有个父布局可以来装载View
而如果不是merge的话，则传进来的是xml布局的根布局view。
include 标签解析
在里面中，判断遇到include 标签，则判断parser.getDepth() >0 就调用parseInclude方法
parser.getDepth()方法说明一下，指的也就是标签的层级(深度)
比如有下面的XML片段：
那么root就是第一层 parent就是第二层 child就是第三层
这里代码判断parser.getDepth()==0要抛出异常，说明 include标签是不能作为XML中的根标签的，换一种意思就是，include标签外面必须有包含的ViewGroup（当然这里还没体现出来一定得是ViewGroup，但在parseInclude方法里就判断了这个）
不过这里有点废话了 ，我们使用include一定是嵌在某个父布局里，要是XML要想就单单使用include的内容的话，那还不如直接引用那个xml文件了 何必新增个xml文件
在parseInclude方法与inflate方法有很大类似的逻辑，因为本身include标签也是去加载另外一个xml布局
parseInclude方法中比较长，我们挑几个重要的流程代码：
private void parseInclude(XmlPullParser parser, Context context, View parent,
AttributeSet attrs) throws XmlPullParserException, IOException {
//当然 能用inclde标签的一定是ViewGroup
if (parent instanceof ViewGroup) {
...
int layout = attrs.getAttributeResourceValue(null, ATTR_LAYOUT, 0);
if (layout == 0) {
final String value = attrs.getAttributeValue(null, ATTR_LAYOUT);
//如果include中没有带layout标签，则抛出异常。没有layout标签的include是没有灵魂的，连肉体都没有
if (value == null || value.length() <= 0) {
throw new InflateException("You must specify a layout in the"
+ " include tag: 另外注意rInflate方法最下面的：
if (finishInflate) {
parent.onFinishInflate();
}
如果finishInflate为true，则会调用View的onFinishInflate方法。
因为rInflate方法是递归调用的，由此得知onFinishInflate方法的调用时机就是：在整个XML布局解析完毕之后会回调每个View的onFinishInflate方法
通常我们自定义View的时候时就可以用到onFinishInflate方法来监听布局是否已经加载完成，以确保我们可以读取到View和属性，比如在XML使用自定义ViewGroup时，它的getChildAt()、findViewById()一定是在onFinishInflate方法之后使用
merge 标签解析
merge 标签解析并没有太多与其他xml不同的地方。
上面代码注释说了如果是带merge标签的xml则在进入rInflate方法时传了finishInflate为false，这不是不让merge标签里的View回调onFinishInflate
因为递归调用rInflateChildren时都一样是传true
这里传的false只是针对于载入merge标签的父布局，也就是root。为什么要为false呢？
因为使用merge标签有两种情况：
第一种是我们自定义组合视图时，比如LinearLayout。在里面进行inflate时一般会采用merge标签的xml，因为本身就是一个父布局了
另外一种就是XML中与include标签组合使用，比如我们定义一个merge标签的视图（注意此时是没有根布局的），然后在其它xml里面要引用这个merge的话
可以使用include把该xml包含进来，这样就达到了复用带merge标签里的布局内容，又不会因为要include一个xml进来时而多了一层父布局。
在第一种情况下，我们其实用不到finishInflate这个回调，因为调用完inflate方法后我们就可以使用findViewById了
但是第二种情况下，对于merge的父布局来讲本身就会调用被一次finishInflate方法了，那么在遇到merge时，对rInflate传入这个父布局要是再调用就重复了。
attachToRoot参数解析
到这里，还有个东西没说，就是我们的inflate方法：
LayoutInflater.from(context).inflate(R.layout.root,false);
第三个参数是啥作用？或许你已经明白，但是我们还是从源码的角度来解释它的作用
在上面，我并没有贴出inflate方法中关于第三个参数的相关代码，是因为想单独出来说，下面我们抽出这个方法涉及到这个参数的代码：
//这里我们讲过，merge标签必须要attachToRoot为true，为什么呢
if (TAG_MERGE.equals(name)) {
if (root == null || !attachToRoot) {
throw new InflateException("经过上面对几种情况的注释，相信已经差不多了解attachToRoot的影响了吧。
attachToRoot的作用也就是要不要附属到指定的父布局上
如果我们传入的root不为空，并且attachToRoot为true，则会把布局内容添加到root容器里
如果我们传入的root不为空，并且attachToRoot为false，那么同样不会添加到root容器里，但是也不会设置自身的LayoutParams
如果我们传入的root为空，那么attachToRoot为true，布局内容不会被添加到其他地方去，但是会设置自身的LayoutParams
如果我们传入的root为空，那么attachToRoot为false，布局内容不会被添加到其他地方去，同时也不会设置自身的LayoutParams
View创建过程
到这里我们已经对LayoutInflater在装载View的过程有个大概的了解了。
我们在其中一个叫做createViewFromTag的方法在上面都是一笔带过，这里挑出来专门大概讲一下。
createViewFromTag方法最终调用它的5个参数的重载方法：
View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
boolean ignoreThemeAttr) {
// 1
if (name.equals("view")) {
name = attrs.getAttributeValue(null, "class");
}
// 2
if (!ignoreThemeAttr) {
final TypedArray ta = context.obtainStyledAttributes(attrs, ATTRS_THEME);
final int themeResId = ta.getResourceId(0, 0);
if (themeResId != 0) {
context = new ContextThemeWrapper(context, themeResId);
}
ta.recycle();
}
//3
if (name.equals(TAG_1995)) {
// Let's party like it's 1995!
return new BlinkLayout(context, attrs);
}
try {
View view;
//4
if (mFactory2 != null) {
view = mFactory2.onCreateView(parent, name, context, attrs);
} else if (mFactory != null) {
view = mFactory.onCreateView(name, context, attrs);
} else {
view = null;
}
//5
if (view == null && mPrivateFactory != null) {
view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}
//6
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
if (-1 == name.indexOf('.')) {
view = onCreateView(parent, name, attrs);
} else {
view = createView(name, null, attrs);
}
} finally {
mConstructorArgs[0] = lastContext;
}
}
return view;
} catch (InflateException e) {
throw e;
} catch (ClassNotFoundException e) {
final InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + name, e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} catch (Exception e) {
final InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + name, e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
}
}
我在源码中标注了6个地方，一个一个描述
（1）判断view标签
从源码上看，当标签是view的话，就获取它的一个class属性，然后重新赋值给name
由此我们可以知道，这个view标签的用法应该是这样的：
想这样的话，name本身是view，而解析了class属性后，name就变成了LinearLayout，与我们定义：
作用是一样的。这个view标签我们几乎不会用到这样的写法，所以可能很多人还不知道view标签的作用
（2） 主题相关判断
从源码逻辑上看，是获取了theme的相关属性，如果有的话则重新包装一下Context，变成一个带主题的Context，也就是ContextThemeWrapper
这个主题会影响后面关于View的属性样式相关
（3）BlinkLayout判断
blink标签是一个会自动闪烁的布局容器，会被转化成BlinkLayout。
如果你有兴趣的话可以写个例子：
BlinkLayout是LayoutInflater里面的一个私有内部类，我们并不能直接使用它，而且我们日常也几乎用不到这个blink标签
它的内部也没有几句代码，点击进去看一下只是继承了下FrameLayout
内部封装了一个Handler用于定时调用invalidate、然后用一个不断交替的mBlinkState变量判断是否调用dispatchDraw来完成绘制
（4）自定义View的创建规则
这个从代码看上去貌似是用来生产View的工厂，那么mFactory和mFactory2是什么时候被赋值的
在AS上输入查找关键词： mFactory =
可以看到他们分别都有一个set方法：setFactory(Factory factory) 和 setFactory2(Factory2 factory)
setFactory如下：
public void setFactory(Factory factory) {
if (mFactorySet) {
throw new IllegalStateException("A factory has already been set on this LayoutInflater");
}
if (factory == null) {
throw new NullPointerException("Given factory can not be null");
}
mFactorySet = true;
if (mFactory == null) {
mFactory = factory;
} else {
mFactory = new FactoryMerger(factory, null, mFactory, mFactory2);
}
}
可以发现setFactory方法并不允许被重复调用的，不然会抛出异常
然后mFactory如果不为空的话，并没有直接赋值传进来的factory变量，而是创建了一个FactoryMerger
看setFactory2方法如下：
public void setFactory2(Factory2 factory) {
if (mFactorySet) {
throw new IllegalStateException("A factory has already been set on this LayoutInflater");
}
if (factory == null) {
throw new NullPointerException("Given factory can not be null");
}
mFactorySet = true;
if (mFactory == null) {
mFactory = mFactory2 = factory;
} else {
mFactory = mFactory2 = new FactoryMerger(factory, factory, mFactory, mFactory2);
}
}
可以发现setFactory2方法也是不允许被重复调用的，不然会抛出异常
而且逻辑也一样，mFactory如果不为空的话，并没有直接赋值传进来的factory变量，而是创建了一个FactoryMerger。
那么FactoryMerger是啥呢？从名字上看待了merge的字眼，看上去不难猜测出是合并这两个工厂的作用。
根据Factory接口的介绍我们明白了，Factory接口和Factory2接口都是用来给开发者自定义View的创建规则的。
而Factory2接口相比Factory接口，则重载了下接口方法，多传了个parent View进来
Factory2接口是在API 11的时候被加入进来的，因为Factory接口造成的问题是我们无法得知它的父 view是谁 从而限制了一些操作。
所以官方已经废弃了Factory接口，我们一般要采用的就是Factory2接口
关于这个Factory接口，谷歌是这么介绍的：
/**
* Hook you can supply that is called when inflating from a LayoutInflater.
* You can use this to customize the tag names available in your XML
* layout files.
*
**/
原来是做了个hook方便我们来自定义View的创建规则，比如说我故意要把该xml布局文件里面的TextView控件都换成Button
那么我们可以在Activity内这么写：
LayoutInflater.from(this).setFactory2(new LayoutInflater.Factory2() {
@Override
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
return null;
}
@Override
public View onCreateView(String name, Context context, AttributeSet attrs) {
if(name.equals("TextView")){
Button button = new Button(context,attrs);
return button;
}
return null;
}
});
既然是留给开发者自定义的，那么正常来讲这里factory和factory2都会为空，所以view还是空的
（5）View的默认创建规则
正常来说的话则会走第5步这个流程：
//5
if (view == null && mPrivateFactory != null) {
view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}
mPrivateFactory一看就是私有的工厂 不是给开发者用的。那么这个mPrivateFactory是什么时候被赋值的呢，搜索一下发现：
/**
* @hide for use by framework
*/
public void setPrivateFactory(Factory2 factory) {
if (mPrivateFactory == null) {
mPrivateFactory = factory;
} else {
mPrivateFactory = new FactoryMerger(factory, factory, mPrivateFactory, mPrivateFactory);
}
}
framework会自己调用这个共有方法，而对开发者是隐藏的。
它在Activity的attach方法中被用到：
final void attach(...){
mWindow.getLayoutInflater().setPrivateFactory(this);
}
设置了Activity自己，看来Activity是实现了这个接口了，找了下发现Activity实现了LayoutInflater.Factory2接口
我们看Activity是如何实现这个接口的：
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
if (!"fragment".equals(name)) {
return onCreateView(name, context, attrs);
}
return mFragments.onCreateView(parent, name, context, attrs);
}
@Nullable
public View onCreateView(String name, Context context, AttributeSet attrs) {
return null;
}
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
return mHost.mFragmentManager.onCreateView(parent, name, context, attrs);
}
这里一不小心引出了Fragment。
我们可以发现Activity并没有自己根据标签去创建View，而是判断如果是fragment标签的话则应用是走了Fragment的onCreateView生命周期方法
所以我们就可以知道，如果是fragment标签的话，则是Activity自己创建的
如果不是的话，Activity调用3个参数的onCreateView方法，直接返回null
所以默认情况下，还是会教给LayoutInflater自己来创建
（6）View的创建过程
既然我们得出了上面的结论，那么下面这个第6步的代码，默认情况下还是会走
// 6
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
if (-1 == name.indexOf('.')) {
view = onCreateView(parent, name, attrs);
} else {
view = createView(name, null, attrs);
}
} finally {
mConstructorArgs[0] = lastContext;
}
这里做了个判断，判断标签名字是否有带个小数点，我们不难猜测出，是因为我们往往自定义View的时候，在xml中布局的时候需要写出这个View的全称
所以这里判断是否带了个小数点，判断是否是自定义View。 如果不是自定义的话，走了onCreateView方法后最终也是到createView方法：
protected View onCreateView(String name, AttributeSet attrs)
throws ClassNotFoundException {
return createView(name, "android.view.", attrs);
}
可以发现，与自定义view调用createView方法不同的是，这里多传了个前缀"android.view."
足以看出，我们在XML中声明的自带的控件，会被系统自己加上个类名的前缀以反射出类名创建对象。
我们看一下createView方法：
public final View createView(String name, String prefix, AttributeSet attrs)
throws ClassNotFoundException, InflateException {
//取得缓存中已经加载过的class
Constructor constructor = sConstructorMap.get(name);
...
if (constructor == null) {
// 注意这里，默认prefix则会传进来android.view以构成控件类名全称
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
...
constructor = clazz.getConstructor(mConstructorSignature);
constructor.setAccessible(true);
//缓存已经加载过的类
sConstructorMap.put(name, constructor);
｝
...
//反射创建View实例
final View view = constructor.newInstance(args);
if (view instanceof ViewStub) {
// Use the same context when inflating ViewStub later.
final ViewStub viewStub = (ViewStub) view;
viewStub.setLayoutInflater(cloneInContext((Context) args[0]));
}
...
return view;
}
createView方法被我精简了大量代码，因为那些反射代码流程感觉没有太多需要说明的，这里只有一个重点，就是ViewStub登场了
ViewStub源码解析
我们可以看到，如果判断是ViewStub类的话，也只是克隆了一个LayoutInflater实例，并没有做其他操作。
我们知道ViewStub是可以用来懒加载视图的，当我们在xml布局中不需要一开始就显示的布局，我们可以采用ViewStub，当需要用到的时候再inflate进来
ViewStub类的代码也不多，它同样继承了View,所有也可以有View的特性，可以被其他父布局添加成一个子View
ViewStub类定义的一些重点源码如下：
public final class ViewStub extends View {
private WeakReference mInflatedViewRef;
private LayoutInflater mInflater;
public ViewStub(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
...
setVisibility(GONE);
setWillNotDraw(true);
}
public void setLayoutInflater(LayoutInflater inflater) {
mInflater = inflater;
}
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(0, 0);
}
@Override
public void draw(Canvas canvas) {
}
@Override
protected void dispatchDraw(Canvas canvas) {
}
public void setVisibility(int visibility) {
//mInflatedViewRef不为空则说明加载过了，直接调用view自己的setVisibility
if (mInflatedViewRef != null) {
View view = mInflatedViewRef.get();
if (view != null) {
view.setVisibility(visibility);
} else {
throw new IllegalStateException("setVisibility called on un-referenced view");
}
} else {
super.setVisibility(visibility);
//可见时装载布局
if (visibility == VISIBLE || visibility == INVISIBLE) {
inflate();
}
}
}
public View inflate() {
final ViewParent viewParent = getParent();
if (viewParent != null && viewParent instanceof ViewGroup) {
if (mLayoutResource != 0) {
final ViewGroup parent = (ViewGroup) viewParent;
final View view = inflateViewNoAdd(parent);
replaceSelfWithView(view, parent);
mInflatedViewRef = new WeakReference<>(view);
if (mInflateListener != null) {
mInflateListener.onInflate(this, view);
}
return view;
} else {
throw new IllegalArgumentException("ViewStub must have a valid layoutResource");
}
} else {
throw new IllegalStateException("ViewStub must have a non-null ViewGroup viewParent");
}
}
//替换坑位
private void replaceSelfWithView(View view, ViewGroup parent) {
final int index = parent.indexOfChild(this);
parent.removeViewInLayout(this);
final ViewGroup.LayoutParams layoutParams = getLayoutParams();
if (layoutParams != null) {
parent.addView(view, index, layoutParams);
} else {
parent.addView(view, index);
}
}
//装载资源布局界面
private View inflateViewNoAdd(ViewGroup parent) {
final LayoutInflater factory;
if (mInflater != null) {
factory = mInflater;
} else {
factory = LayoutInflater.from(mContext);
}
final View view = factory.inflate(mLayoutResource, parent, false);
if (mInflatedId != NO_ID) {
view.setId(mInflatedId);
}
return view;
}
}
ViewStub的代码很少，我们调了其中最重要的方法，我们可以知道，在创建的时候为ViewStub克隆了一个LayoutInflater实例赋值给了mInflater
我们发现在构建的时候，ViewStub自己便设置了setVisibility(GONE);和setWillNotDraw(true);
然后还在onMeasure里面传了宽高都是0的数值，并且draw和dispathDraw都是空方法。
这一切足以证明，ViewStub像是一个空袋子，与世无争什么都不干，就只在布局中占着个位置。
我们知道，我们要显示ViewStub内容的时候可以用inflate方法或者是setVisibility方法
我们看他的inflate方法流程，它会先调用inflateViewNoAdd方法来把指定的资源布局加载进来，然后用replaceSelfWithView方法来把自己从原先的父布局中的坑位中替换出来，给这个新加载的布局替换进去。
然后setVisibility方法其实也只是做了个判断，如果未装载，则在VISIBLE or INVISIBLE时调用inflate方法。
由此我们可以得知，原来ViewStub的懒加载原理是这样的，先不加载自己指定的xml到布局中，而是在布局中占了个坑位，没宽高也什么都不显示。
当需要加载的时候再加载布局资源进来，替换自己占的坑位
结束语
相信你在读完本篇后，一定会LayoutInfalter的装载过程有了一定的了解。
并且对布局优化的三个标签（include、merge、ViewStub）的原理理解更加深入。