本节书摘来自异步社区《Android 源码设计模式解析与实战》一书中的第2章，第2.8节无名英雄——深入理解LayoutInflater，作者 何红辉 , 关爱民，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.8 无名英雄——深入理解LayoutInflater
LayoutInflater在我们的开发中扮演着重要的角色，但很多时候我们都不知道它的重要性，因为它的重要性被隐藏在了Activity、Fragment等组件的光环之下。
LayoutInflater是一个抽象类，具体代码如下：
public abstract class LayoutInflater {
// 代码省略
}既然是抽象不是具体的，那我们必须把这个深藏功与名的“家伙”找出来！需要先从layoutInflater的起源开始。在上文中知道，在加载ContenxtImpl时会通过如下代码将LayoutInflater的ServiceFetcher注入到容器中，具体代码如下：
registerService(LAYOUT_INFLATER_SERVICE, new ServiceFetcher() {
public Object createService(ContextImpl ctx) {
return PolicyManager.makeNewLayoutInflater(ctx.getOuterContext());
}
});这里调用了PolicyManager. makeNewLayoutInflater方法，继续往下看看：
public final class PolicyManager {
// Policy实现类
private static final String POLICY_IMPL_CLASS_NAME =
"com.android.internal.policy.impl.Policy";
private static final IPolicy sPolicy;
static {
// 通过反射构造Policy对象
try {
Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME);
sPolicy = (IPolicy)policyClass.newInstance();
}
// catch 代码段
}
private PolicyManager() {}
// 这里就是创建PhoneWindow对象的地方
public static Window makeNewWindow(Context context) {
return sPolicy.makeNewWindow(context);
}
// 通过sPolicy创建LayoutInflater
public static LayoutInflater makeNewLayoutInflater(Context context) {
return sPolicy.makeNewLayoutInflater(context);
}
}PolicyManager中通过反射构造了Policy实现类，这个类实现了IPolicy接口，通过这种形式将具体的Policy类对外进行隐藏实现。PolicyManager实际上是一个代理类，具体的功能通过sPolicy对象进行实现，我们看看sPolicy对应的Policy类，也就是com.android.internal.policy.impl.Policy：
public class Policy implements IPolicy {
// 代码省略
// 创建PhoneWindow，这就是Activity中Window的具体实现类
public Window makeNewWindow(Context context) {
return new PhoneWindow(context);
}
// 创建LayoutInflater,具体类为PhoneLayoutInflater,这才是我们要关注的地方
public LayoutInflater makeNewLayoutInflater(Context context) {
return new PhoneLayoutInflater(context);
}
}
此时，已经很清楚了，真正LayoutInflater的实现类就是PhoneLayoutInflater。我们继续深入看看PhoneLayoutInflater的源代码：
public class PhoneLayoutInflater extends LayoutInflater {
// 内置View类型的前缀，如TextView的完整路径是android.widget.TextView
private static final String[] sClassPrefixList = {
"android.widget.",
"android.webkit."
};
// 代码省略
@Override protected View onCreateView(String name, AttributeSet attrs) throws ClassNot FoundException {
// 在View名字的前面添加前缀来构造View的完整路径，例如，类名为TextView，那么TextView完整
//路径是android.widget.TextView
for (String prefix : sClassPrefixList) {
try {
View view = createView(name, prefix, attrs);
if (view != null) {
return view;
}
} catch (ClassNotFoundException e) {
// 省略
}
}
return super.onCreateView(name, attrs);
}
}代码不多，核心的程序语句就是覆写了LayoutInflater的onCreateView方法，该方法就是在传递进来的View名字前面加上“android.widget.”或者“android.webkit.”前缀用以得到该内置View类（如TextView、Button等都在android.widget包下）的完整路径。最后，根据类的完整路径来构造对应的View对象。
具体是一个怎样的流程呢？以Activity的setContentView为例，先来看看这个函数的实现：
public void setContentView(View view) {
getWindow().setContentView(view);
initActionBar();
}Activity的setContentView方法实际上调用的是Window的setContentView，而Window是一个抽象类，上文提到Window的具体实现类是PhoneWindow，我们看看PhoneWindow中对应的方法：
@Override
public void setContentView(int layoutResID) {
// 1. 当mContentParent为空时先构建DecorView
// 并且将DecorView包裹到mContentParent中
if (mContentParent == null) {
installDecor();
} else {
mContentParent.removeAllViews();
}
// 2. 解析layoutResID
mLayoutInflater.inflate(layoutResID, mContentParent);
// 代码省略
}在分析之前，我们来看看一个Window的View层级图，如图2-2所示。
从图2-2中，我们看到mDecor中会加载一个系统定义好的布局，这个布局中又包裹了mContentParent，而这个mContentParent就是我们设置的布局，并将添加到parent区域。在PhoneWindow的setContentView方法中也验证了这点，首先会构建mContentParent这个对象，然后通过LayoutInflater的inflate函数将指定布局的视图添加到mContentParent中。那么就先来看看inflate方法：
public View inflate(int resource, ViewGroup root) {
// root不为空，则会从resource布局解析到View，并添加到root中
return inflate(resource, root, root != null);
}
public View inflate(int resource, ViewGroup root, boolean attachToRoot) {
// 获取xml资源解析器
XmlResourceParser parser = getContext().getResources().getLayout(resource);
try {
return inflate(parser, root, attachToRoot);
} finally {
parser.close();
}
}
// 参数1为xml解析器，参数2为要解析布局的父视图，参数3为是否将要解析的视图添加到父视图中
public View inflate(XmlPullParser parser, ViewGroup root, boolean attachToRoot) {
synchronized (mConstructorArgs) {
final AttributeSet attrs = Xml.asAttributeSet(parser);
Context lastContext = (Context)mConstructorArgs[0];
// Context对象
mConstructorArgs[0] = mContext;
// 存储父视图
View result = root;
try {
// Look for the root node.
int type;
// 找到root元素
while ((type = parser.next()) != XmlPullParser.START_TAG &&
type != XmlPullParser.END_DOCUMENT) {
// Empty
}
// 代码省略
final String name = parser.getName();
// 1. 解析merge标签
if (TAG_MERGE.equals(name)) {
rInflate(parser, root, attrs, false);
} else {
// 2. 不是merge标签那么直接解析布局中的视图
View temp;
if (TAG_1995.equals(name)) {
temp = new BlinkLayout(mContext, attrs);
} else {
// 3. 这里就是通过xml的tag来解析layout根视图
// name就是要解析的视图的类名，如RelativeLayout
temp = createViewFromTag(root, name, attrs);
}
ViewGroup.LayoutParams params = null;
if (root != null) {
// 生成布局参数
params = root.generateLayoutParams(attrs);
// 如果attachToRoot为false,那么将给temp设置布局参数
if (!attachToRoot) {
temp.setLayoutParams(params);
}
}
// 解析temp视图下的所有子View
rInflate(parser, temp, attrs, true);
// 如果Root不为空，且attachToRoot为true，那么将temp添加到父视图中
if (root != null && attachToRoot) {
root.addView(temp, params);
}
// 如果root为空或者attachToRoot为false,那么返回的结果就是temp
if (root == null || !attachToRoot) {
result = temp;
}
}
}
// 省略catch, finaly代码
return result;
}上述的inflate方法中，主要有下面几步:
（1）解析xml中的根标签（第一个元素）；
（2）如果根标签是merge，那么调用rInflate进行解析，rInflate会将merge标签下的所有子View直接添加到根标签中；
（3）如果标签是普通元素，那么运行到代码3，调用createViewFromTag对该元素进行解析；
（4）调用rInflate解析temp根元素下的所有子View，并且将这些子View都添加到temp下；
（5）返回解析到的根视图。
我们先从简单的地方理解，即解析单个元素的createViewFromTag，看看如下代码：
View createViewFromTag(View parent, String name, AttributeSet attrs) {
if (name.equals("view")) {
name = attrs.getAttributeValue(null, "class");
}
try {
View view;
// 1. 用户可以通过设置LayoutInflater的factory来自行解析View，默认这些Factory都为
//空, 可以忽略这段
if (mFactory2 != null) view = mFactory2.onCreateView(parent, name, mContext, attrs);
else if (mFactory != null) view = mFactory.onCreateView(name, mContext, attrs);
else view = null;
// 代码省略
// 2. 没有Factory的情况下通过onCreateView或者createView创建View
if (view == null) {
// 3. 内置View控件的解析
if (-1 == name.indexOf('.')) {
view = onCreateView(parent, name, attrs);
} else {
// 4. 自定义控件的解析
view = createView(name, null, attrs);
}
}
return view;
}
// 省略catch块
}本程序重点就在代码2，以及以后的代码，createViewFromTag会将该元素的parent及名字传递过来。当这个tag的名字中没有包含“.”（在名字中查找“.”返回-1）时，LayoutInflater会认为这是一个内置的View，例如，我们在xml中声明一个内置View时大概是这样的：
<TextView
android:id="@+id/my_textview "
android:layout_width="60dp"
android:layout_height="60dp" />这里的TextView就是xml元素的名字，因此，在执行infate时就会调用代码3处的onCreateView来解析这个TextView标签。当我们自定义View时，在xml中必须写View的完整路径，例如：
<com.dp.custom.MyView
android:id="@+id/my_custom_view "
android:layout_width="fill_parent"
android:layout_height="fill_parent" />此时，就会调用代码注释4的createView来解析该View。为什么要这么处理，它们之间又有什么不同呢？
在上文的PhoneLayoutInflater中我们知道，PhoneLayoutInflater覆写了onCreateView方法，也就是代码3处的onCreateView，该方法就是在View标签名的前面设置一个“android.widget.”前缀，然后再传递给createView进行解析。也就是说内置View和自定义View最终都调用了createView进行解析，只是Google为了让开发者在xml中更方便定义View，只写View名称而不需要写完整的路径。在LayoutInflater解析时如果遇到只写类名的View，那么认为是内置的View控件，在 onCreateView方法中会将“android.widget.”前缀传递给createView方法，最后，在createView中构造View的完整路径来进行解析。如果是自定义控件，那么必须写完整的路径，此时调用createView且前缀为null进行解析。
关于createView的解释已经有很多，我们还是看下面的代码吧：
// 根据完整路径的类名通过反射机制构造View对象
public final View createView(String name, String prefix, AttributeSet attrs)
throws ClassNotFoundException, InflateException {
// 1. 从缓存中获取构造函数
Constructor<? extends View> constructor = sConstructorMap.get(name);
Class<? extends View> clazz = null;
try {
// 2. 没有缓存构造函数
if (constructor == null) {
// 如果prefix不为空，那么构造完整的View路径，并且加载该类
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
// 代码省略
// 3. 从Class对象中获取构造函数
constructor = clazz.getConstructor(mConstructorSignature);
// 4. 将构造函数存入缓存中
sConstructorMap.put(name, constructor);
} else {
// 代码省略
}
Object[] args = mConstructorArgs;
args[1] = attrs;
// 5. 通过反射构造View
final View view = constructor.newInstance(args);
if (view instanceof ViewStub) {
// always use ourselves when inflating ViewStub later
final ViewStub viewStub = (ViewStub) view;
viewStub.setLayoutInflater(this);
}
return view;
}
// 省略各种catch、finaly代码
}createView相对比较简单，如果有前缀，那么构造View的完整路径，并且将该类加载到虚拟机中，然后获取该类的构造函数并且缓存起来，再通过构造函数来创建该View的对象，最后将View对象返回，这就是解析单个View的过程。而我们的窗口中是一棵视图树，LayoutInflater需要解析完这棵树，这个功能就交给了rInflate方法，具体代码如下：
void rInflate(XmlPullParser parser, View parent, final AttributeSet attrs,
boolean finishInflate) throws XmlPullParserException, IOException {
// 1. 获取树的深度，深度优先遍历
final int depth = parser.getDepth();
int type;
// 2. 挨个元素解析
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_INCLUDE.equals(name)) { // 解析include标签
parseInclude(parser, parent, attrs);
} else if (TAG_MERGE.equals(name)) { // 解析merge标签，抛出异常，因为merge标签
//必须为根视图
throw new InflateException("<merge /> must be the root element");
} else if (TAG_1995.equals(name)) {// 闪烁视图,这里可以不用管
// 代码省略
} else {
// 3. 根据元素名进行解析
final View view = createViewFromTag(parent, name, attrs);
final ViewGroup viewGroup = (ViewGroup) parent;
final ViewGroup.LayoutParams params = viewGroup.generateLayoutParams (attrs);
// 递归调用进行解析，也就是深度优先遍历
rInflate(parser, view, attrs, true);
// 将解析到的View添加到viewGroup中，也就是它的parent
viewGroup.addView(view, params);
}
}
if (finishInflate) parent.onFinishInflate();
}rInflate通过深度优先遍历来构造视图树，每解析到一个View元素就会递归调用rInflate，直到这条路径下的最后一个元素，然后再回溯过来将每个View元素添加到它们的parent中。通过rInflate的解析之后，整棵视图树就构建完毕。当调用了Activity的onResume之后，我们通过setContentView设置的内容就会出现在我们的视野中。
