安卓开发中，最常见的就是在 Activity 的 onCreate 方法中调用 setContentView 后，开始一系列的 findViewById、 setOnClickListener、setText 等等视图相关的操作，在调用 setContentView 方法后整个 Activity 的视图树就形成了，也就是说我们在 xml 布局文件中写的布局都 “转化” 成了我们在代码中可以操作的一个个 View、ViewGroup 对象。似乎一切都是那么的顺理成章。但是仔细想一下下边这些问题就会发现原来掌握的知识还远远不够：
1、视图树是怎么形成的？
2、视图树是靠什么结构存起来的（ViewGroup 和 View 的存储关系）？
3、addView、removeView、detachView 是怎样影响视图树的？
4、setContentView后视图树形成了，这个时候所有的视图经过 measure、layout、draw三大过程了吗？
一、视图树形成过程
在 Activity 中调用 setContentView 后，最终会走到这里：
public void setContentView(int resId) {
this.ensureSubDecor();
//contentParent是一个系统的继承自 FrameLayout 的ViewGroup，我们自己的xml布局文件就是放在这个contentParent中
ViewGroup contentParent = (ViewGroup)this.mSubDecor.findViewById(16908290);
contentParent.removeAllViews();
//关键代码
LayoutInflater.from(this.mContext).inflate(resId, contentParent);
this.mOriginalWindowCallback.onContentChanged();
}最终会通过 LayoutInflater 的 inflate 方法，将系统的 contentParent 以及我们的布局id传入，由此开始生成视图树。inflate有多个不同参数的重载：
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root) {
return inflate(resource, root, root != null);
}
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {
// 省略无关代码
final Resources res = getContext().getResources();
final XmlResourceParser parser = res.getLayout(resource);
return inflate(parser, root, attachToRoot);
}这里会根据我们的 xml 布局文件生成一个 XmlResourceParser 对象，这个对象的作用就类似于 ArrayList 的 Iterator 迭代器，通过迭代器去遍历访问整个 xml 文件的中各个节点信息。更详细的安卓Pull解析这里就不说了。最终方法走到了另一个重载的 inflate 方法。
public View inflate(XmlPullParser parser, @Nullable ViewGroup root, boolean attachToRoot) {
synchronized (mConstructorArgs) {
//省略了很多无关的代码。。。
final Context inflaterContext = mContext;
// 注释1
final AttributeSet attrs = Xml.asAttributeSet(parser);
View result = root;
try {
// 注释2
int type;
while ((type = parser.next()) != XmlPullParser.START_TAG &&
type != XmlPullParser.END_DOCUMENT) {
// Empty
}
final String name = parser.getName();
// 注释3
if (TAG_MERGE.equals(name)) {
if (root == null || !attachToRoot) {
throw new InflateException("<merge /> can be used only with a valid "
+ "ViewGroup root and attachToRoot=true");
}
rInflate(parser, root, inflaterContext, attrs, false);
} else {
// 注释4
final View temp = createViewFromTag(root, name, inflaterContext, attrs);
ViewGroup.LayoutParams params = null;
if (root != null) {
// 注释5
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);
}
}
// 注释6
rInflateChildren(parser, temp, attrs, true);
// 注释7
if (root != null && attachToRoot) {
root.addView(temp, params);
}
// 注释8
if (root == null || !attachToRoot) {
result = temp;
}
}
} catch (XmlPullParserException e) {
}
//省略无关代码
return result;
}
}我对 inflate 的代码做了精简只保留了主线上的代码。先看 注释1，调用了 Xml.asAttributeSet(parser)， 源码很简单：
public static AttributeSet asAttributeSet(XmlPullParser parser) {
return (parser instanceof AttributeSet)
? (AttributeSet) parser
: new XmlPullAttributes(parser);
}这个 parser 对象是我们在上一个inflate重载方法中生成的，他是一个 XmlResourceParser 对象，而 XmlResourceParser 就是直接实现的 AttributeSet 接口， 所以上边的方法就是直接将 parser 强转为父类并返回。所以回到 注释1， attrs 和 parser 实际上是指向同一个内存地址的两个引用。这句话很重要，因为当 parser 调用 next 方法向下查找节点时， attrs 实际上也指向下一个节点了，因为这两个引用指向的是同一个对象。再看 注释2，调用了parser.next() 方法此时布局解析器指向第一个节点，然后调用 parser.getName() 就可以获得当前节点的名称，例如：LinearLayout。注释3判断当前的节点是否为 merge 标签，暂时先考虑简单的情况，直接看 注释4，获取到当前节点的名字以及attr(布局文件的属性)信息后，开始创建View：
View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
boolean ignoreThemeAttr) {
try {
View view;
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;
}
}省略了很多代码，直接看关键代码处，通过 判断条件： -1 == name.indexOf(’.’) ，这句代码是什么意思呢？name 是我们在布局文件中写的标签，想一想如果是系统的控件例如 TextView、Button等都是直接使用的，如果是我们自定义的View，那在布局文件中就需要完整的包名：
<TextView />
<Button />
<com.study.CustomButton />看到没，这个判断条件就是判断这个标签是系统的View 还是自定义的 View。如果是自定义的View那么就执行 createView 方法，如果是系统View，就执行 onCreateView，先来看 onCreateView：
protected View onCreateView(String name, AttributeSet attrs)
throws ClassNotFoundException {
return createView(name, "android.view.", attrs);
}哦！原来也是调用的 createView，只不过第二个参数加上了 android.view 这个包名，而如果是自定义View的时候，第二个参数传的是 null。这可以得出什么结论呢？如果是系统空间，包名 + name 就可以得到这个系统控件的全类名。如果是自定义控件，因为name中已经是全类名了，所以第二个参数直接传null。为什么需要全类名呢？继续往下看：
public final View createView(String name, String prefix, AttributeSet attrs)
throws ClassNotFoundException, InflateException {
Constructor<? extends View> constructor = sConstructorMap.get(name);
Class<? extends View> clazz = null;
//关键代码1
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
constructor = clazz.getConstructor(mConstructorSignature);
constructor.setAccessible(true);
//关键代码2
final View view = constructor.newInstance(args);
return view;
}删减了很多代码，看 关键代码1，通过反射拿到了我们要创建的View的 class 对象，这下就知道为什么要全类名了吧？原来我们的View 树种中所有的View对象都是通过反射创建的。然后关键代码2通过调用构造方法创建实例对象并返回。
绕了一大圈，我们终于知道了布局文件中的标签是如何 “翻译” 成我们代码中的 View对象的了。现在重新回到 inflate 方法中，注释4通过 createViewFromTag 方法反射创建了View实例对象，在注释5处调用root.generateLayoutParams生成当前View的 LayoutParams 对象。root是ViewGroup的子类，所以直接看ViewGroup：
public LayoutParams generateLayoutParams(AttributeSet attrs) {
return new LayoutParams(getContext(), attrs);
}方法直接创建了一个LayoutParams对象，继续看LayoutParams的构造方法：
public LayoutParams(Context c, AttributeSet attrs) {
TypedArray a = c.obtainStyledAttributes(attrs, R.styleable.ViewGroup_Layout);
setBaseAttributes(a,
R.styleable.ViewGroup_Layout_layout_width,
R.styleable.ViewGroup_Layout_layout_height);
a.recycle();
}
protected void setBaseAttributes(TypedArray a, int widthAttr, int heightAttr) {
width = a.getLayoutDimension(widthAttr, "layout_width");
height = a.getLayoutDimension(heightAttr, "layout_height");
}原来我们在xml布局文件中写的 layout_width、layout_height 属性是在这里被解析的！！这样我们在布局文件中写的宽高属性就被解析保存在LayoutParams对象中了。继续回到 inflate 方法，当 attachToRoot 为 false 的时候，我们就把LayoutParams设置给当前生成的View对象。
先来一个简单的总结，到 注释5 为止，我们先根据布局文件生成了一个解析器 parser， 遍历解析器拿到第一个布局标签，根据这个布局标签的信息，通过反射的形式创建了一个View实例对象。然后继续解析当前标签的layout_width、layout_height属性并生成一个LayoutParams对象，当 attachToRoot 为 false 的时候，我们就把LayoutParams设置给当前生成的View对象。
好了，继续来看注释6，调用了 rInflateChildren 方法，从名字就可以看出，这个方法的作用就是以上一步中生成的 View 实例对象 temp 作为 parent，然后递归的去创建 temp 的所有子 View：
final void rInflateChildren(XmlPullParser parser, View parent, AttributeSet attrs,
boolean finishInflate) throws XmlPullParserException, IOException {
rInflate(parser, parent, parent.getContext(), attrs, finishInflate);
}继续调用了 rInflate ：
void rInflate(XmlPullParser parser, View parent, Context context,
AttributeSet attrs, boolean finishInflate) throws XmlPullParserException, IOException {
final int depth = parser.getDepth();
int type;
while (((type = parser.next()) != XmlPullParser.END_TAG ||
parser.getDepth() > depth) && type != XmlPullParser.END_DOCUMENT) {
final String name = parser.getName();
final View view = createViewFromTag(parent, name, context, attrs);
final ViewGroup viewGroup = (ViewGroup) parent;
final ViewGroup.LayoutParams params = viewGroup.generateLayoutParams(attrs);
rInflateChildren(parser, view, attrs, true);
viewGroup.addView(view, params);
}
}删掉了很多无关的代码，可以看到每一次 while 循环，都会创建一个 parent 的一级子View，并把这个一级的子View作为parent继续递归…每一次循环的最后都把创建的 view 添加到 parent 中。这样当这个方法执行完成后，以parent作为root，他所有的子View，以及子View的子View（孙子、重孙子。。。）等等所有的View就都创建并add到相应的父view中去了。
好了，再来做一个简单的总结。到注释6为止，我们先根据布局文件生成了一个解析器 parser， 遍历解析器拿到第一个布局标签，根据这个布局标签的信息，通过反射的形式创建了一个View实例对象 temp。然后继续解析当前标签的layout_width、layout_height属性并生成一个LayoutParams对象，当 attachToRoot 为 false 的时候，我们就把LayoutParams设置给当前生成的View对象。并且以 temp 作为根节点，再来一次递归把temp的所有子View也都实例化并add到相应的父View中，至此，我们的整棵View树已经创建完毕了！！布局文件中所有的 xml 标签都被翻译成了 View 对象，并且都被 add 到了相应的父View中。
再回到 inflate 方法，还剩下 注释7 和 注释8，回到Activity的setContentView方法中，在调用inflate方法的时候，会传入一个 contentParent 对象，还有印象吗？这个对象就是解析我们布局文件的时候传入的最根部的 root。所以注释7的判断是成立的，我们的xml布局文件中的跟标签所生成的View对象，最终会被add到contentParent中！！至此，我们的布局文件也就完全被 “翻译创建”，并被添加到contentParent中了。这样，一个页面中以 DectorView 作为最根部的视图，一直延伸到我们自己创建的布局文件，整棵树就完全创建成功了。到这里，第一个问题应该也解释清楚了。
二、视图树是靠什么结构存起来的（ViewGroup 和 View 的存储关系）
一棵完整的View树，拿到任意一个ViewGroup，都可以获取到他有哪些子View。相反拿到任意一个View，也都可以知道他的parent是谁。那么View树是如何保存这种链条关系的呢？上边分析源码的时候，多次提到 viewGroup.addView(view, params); 通过这个方法将子View 添加到他的父View中，直接看ViewGroup源码：
public abstract class ViewGroup extends View implements ViewParent, ViewManager {
// 所有子View
private View[] mChildren;
//子View的数量
private int mChildrenCount;
}首先看ViewGroup的类结构，内部通过一个 View数组保存所有的子View，所以这里可以猜想，addView 方法实际上就是将 View 添加到mChildren数组中，并且将mChildrenCount自增1。下面来看ViewGroup的add方法：
//第一个add重载方法
public void addView(View child) {
addView(child, -1);
}
//第二个add重载方法
public void addView(View child, int index) {
if (child == null) {
throw new IllegalArgumentException("Cannot add a null child view to a ViewGroup");
}
LayoutParams params = child.getLayoutParams();
if (params == null) {
params = generateDefaultLayoutParams();
if (params == null) {
throw new IllegalArgumentException("generateDefaultLayoutParams() cannot return null");
}
}
addView(child, index, params);
}
//第三个add重载方法
public void addView(View child, int index, LayoutParams params) {
requestLayout();
invalidate(true);
addViewInner(child, index, params, false);
}
//最终调用了addViewInner
private void addViewInner(View child, int index, LayoutParams params,
boolean preventRequestLayout) {
//省略无关代码
//index 默认是 -1 ，所以此处被赋值为mChildrenCount
if (index < 0) {
index = mChildrenCount;
}
addInArray(child, index);
if (preventRequestLayout) {
child.assignParent(this);
} else {
//关键代码
child.mParent = this;
}
}经过了多个重载方法，最终调用了addViewInner。addInArray方法很容易就可以想到，就是将child 添加到 mChildren 数组中。我们先来看下面的判断，preventRequestLayout为false，所以走下边的代码，直接将 this 也就是ViewGroup 赋值给 child 对象的 mParent 属性，那么 mParent 属性又是什么呢？
public class View {
protected ViewParent mParent;
}ViewParent 是一个接口，而ViewGroup正是实现了这个接口！在 addViewInner 方法中，对 View 的 mParent 进行了赋值。这样，任意一个View，都可以通过 mParent 找到他的直接父类！再回过头来看 addInArray 方法：
private void addInArray(View child, int index) {
View[] children = mChildren;
final int count = mChildrenCount;
final int size = children.length;
if (index == count) {
if (size == count) {
mChildren = new View[size + ARRAY_CAPACITY_INCREMENT];
System.arraycopy(children, 0, mChildren, 0, size);
children = mChildren;
}
//关键代码
children[mChildrenCount++] = child;
}
//省略代码。。。
}在addViewInner方法中，index 被赋值为mChildrenCount，所以这个方法就是判断当前mChildren数组是否需要扩容，并将child放到数组指定的位置上。
再来总结一波，通过 ViewGroup的addView方法，一共做了两件事：1.将view添加到ViewGroup的数组中。2.给View 的 mParent属性赋值为当前的ViewGroup对象。通过这两步，整个view树就像一个 “双向链表” 一样，从根部的root，可以找到最顶部的View，也可以从任意一个View，一直找到根部的root。 到这里，第二个问题也解释清楚了。
三、addView、removeView、detachView 是怎样影响视图的？
addView在上边已经说过了，下边主要来看一下detachView 和 removeView 有什么不同。先看detachView做了什么：
protected void detachViewFromParent(View child) {
removeFromArray(indexOfChild(child));
}
private void removeFromArray(int index) {
final View[] children = mChildren;
//省略代码。。。
children[index].mParent = null;
final int count = mChildrenCount;
if (index == count - 1) {
children[--mChildrenCount] = null;
} else if (index >= 0 && index < count) {
System.arraycopy(children, index + 1, children, index, count - index - 1);
children[--mChildrenCount] = null;
} else {
throw new IndexOutOfBoundsException();
}
}在 detachViewFromParent 中，直接回调了removeFromArray。这个方法做了两件事：1.将child的 mParent属性置为null。2.将child从mChildren数组中移除。这样就切断了View和ViewGroup的联系。但是这个方法会引起UI上的变化吗？答案是不会的，因为这个方法并没有触发界面重新绘制，所以UI是没有变化的。只是在调用getChildCount的时候返回的数量出现了变化。
再看removeView的时候都干了什么：
public void removeView(View view) {
if (removeViewInternal(view)) {
requestLayout();
invalidate(true);
}
}看到了 requestLayout 和 invalidate 两个方法，也就是说如果 removeViewInternal 方法返回 true，那么就会引起视图的刷新，UI也就改变了。所以看下removeViewInternal：
private boolean removeViewInternal(View view) {
final int index = indexOfChild(view);
if (index >= 0) {
removeViewInternal(index, view);
return true;
}
return false;
}只要当前要移除的child确实是ViewGroup的子View，那么就一定返回true，继续看重载方法：
private void removeViewInternal(int index, View view) {
// 省略很多代码
removeFromArray(index);
// 省略很多代码
}再来总结一波，当我们调用 detachViewFromParent 的时候，只是把要想要 detach 的 view 从数组中移除，这时候因为没有处罚界面的刷新，所以在UI上并没有变化。这个方法是 protected 访问权限的所以我们在外部并不能直接访问，那这个 detachViewFromParent 方法有什么用呢？如果你看过 RecyclerView 的源码，在 LayoutManager中有这样一个方法：detachAndScrapAttachedViews 。在RecyclerView 布局子View的时候，会执行这个方法先将 RecyclerView 中所有的子View 全部 detach 下来，再重新 add 进去。更详细的可以看 启舰的RecyclerView系列的文章。再来说 removeView 相比于 detachView 他又额外的调用了 requestLayout、invalidate 触发了界面的刷新。到这里第三个问题应该也解释清楚了。
四、setContentView后视图树形成，这个时候所有的视图经过 measure、layout、draw三大过程了吗？
如上面的分析，当我们在 Activity 的 onCreate 方法中调用了 setContentView 后，整个视图树就已经形成了。这个时候我们可以通过 findViewById 找到 View 对象，也可以 setOnClickListener 设置点击事件，但是实际上此时的 View 树处于一个万事俱备只欠东风的状态，这个 “东风” 也就是 ViewRootImpl 调用 performTraversals 方法开始界面的绘制。这里就又扯到Activity的启动流程了，直接给出结论了：在Activit的创建过程中，View 的真正测量是在 Activity 的 onResume 方法之后，也就是说我们在 onCreate、onResume方法之前，View还没有经过测量布局绘制，我们在onCreate、onResume方法中想获取 View 的宽、高是获取不到的！因为这时还没有经过测量。所以在setContentView后视图树形成，这个时候视图并没有经过 measure、layout、draw三大过程！
