这篇文章我不会去走一遍这几位的源码，只是提出几个关于他们的问题，附上我的理解，是自己的一个笔记，也希望能帮到有同样困惑的同学。
WindowManagerGlobal跟ViewRootImpl跟DocerView的关系
这个问题其实网上很多人写过了，这里分享一下我的理解：
WindowManagerImpl中持有了WindowManagerGlobal，也就是实际逻辑都是用的WindowManagerGlobal，而WindowManagerGlobal是单例的，其中维护了
//WindowManagerGlobal.java
@UnsupportedAppUsage
private final ArrayList<View> mViews = new ArrayList<View>();
@UnsupportedAppUsage
private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
里面按照顺序存了整个app中的View和相对应的ViewRootImpl，所以Global这个名字就是顾名思义，整个app就一个全局的，维护了所有的View，需要就来这里取并且分发对应的ViewRootImpl对对应的View做对应的操作。
但是这里有个问题，mViews存在的意义是什么呢？我可以直接通过RootViewImpl拿到对应的DecorView啊~
一个app可以存在几个WindowManagerImpl，几个WindowManagerGlobal? 有几个DecorView，几个ViewRootImpl，几个PhoneWindow？
看了上面的问题，其实我们知道的是WindowManagerImpl可以存在多个，很多使用的地方都可以拿到，可以直接new或者 (WindowManagerImpl)outerContext.getSystemService(WINDOW_SERVICE);拿到，但是实际实现类WindowManagerGlobal是单例的。
而且既然知道了WindowManagerGlobal有mViews和mRoots，其实我们可以猜到DecorView和ViewRootImpl应该也是存在多个的，但是他们之间是什么关系呢？
既然WindowManagerGlobal是个单例，那我们应该可以反射调用它的getInsatance()方法获取全局的对象，那同样也可以得到mViews跟mRoots的值，我们发现ViewRootImpl中有一个mWindow的变量应该是PhoneWindow，那我们同样可以反射获取到。
纸上得来终觉浅，让我们写个代码来验证一下，一个Activity中存在一个Dialog和一个PopupWindow的时候是怎么表现的。
public static void testWindowManagerGlobal() throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, IllegalAccessException, InstantiationException, NoSuchFieldException {
Class clazz = Class.forName("android.view.WindowManagerGlobal");
Field mViewsField = clazz.getDeclaredField("mViews");
mViewsField.setAccessible(true);
Field mRootsField = clazz.getDeclaredField("mRoots");
mRootsField.setAccessible(true);
Field mParamsField = clazz.getDeclaredField("mParams");
mParamsField.setAccessible(true);
Method instanceMedthod = clazz.getMethod("getInstance");
Object mGlobal = instanceMedthod.invoke(null);
Object mViews = mViewsField.get(mGlobal);
Object mRoots = mRootsField.get(mGlobal);
if (mViews instanceof List) {
for (Object o : (List) mViews) {
printDecorView(o);
}
}
if (mRoots instanceof List) {
for (Object o : (List) mRoots) {
printViewRootImpl(o);
}
}
}
public static void printViewRootImpl(Object viewRootImpl) throws NoSuchFieldException, IllegalAccessException {
Field mViewField = viewRootImpl.getClass().getDeclaredField("mView");
mViewField.setAccessible(true);
Object mViewObject = mViewField.get(viewRootImpl);
LogUtil.d("printViewRootImpl->" + viewRootImpl + " View:" + mViewObject.toString());
}
public static void printDecorView(Object decorView) throws IllegalAccessException {
StringBuffer sb = new StringBuffer(decorView.toString());
Field mWindowField = null;
try {
mWindowField = decorView.getClass().getDeclaredField("mWindow");
mWindowField.setAccessible(true);
Object mWindowObject = mWindowField.get(decorView);
sb.append(" PhoneWindow->").append(mWindowObject.toString());
} catch (NoSuchFieldException e) {
e.printStackTrace();
sb.append(" PhoneWindow->").append(decorView.getClass().toString());
}
LogUtil.d("printDecorView->:" + sb.toString());
}
打印结果如下：
D: printDecorView->:DecorView@b67e275[MainActivity] PhoneWindow->com.android.internal.policy.PhoneWindow@db9420a
D: printDecorView->:DecorView@7bc5a7b[TestWindowActivity] PhoneWindow->com.android.internal.policy.PhoneWindow@4e63098
D: printDecorView->:DecorView@66130f1[TestWindowActivity] PhoneWindow->com.android.internal.policy.PhoneWindow@fb174d6
D: printDecorView->:android.widget.PopupWindow$PopupDecorView{3ac2357 V.E...... R.....I. 0,0-0,0} PhoneWindow->class android.widget.PopupWindow$PopupDecorView
D: printViewRootImpl->android.view.ViewRootImpl@dc6eb2d View:DecorView@b67e275[MainActivity]
D: printViewRootImpl->android.view.ViewRootImpl@b280862 View:DecorView@7bc5a7b[TestWindowActivity]
D: printViewRootImpl->android.view.ViewRootImpl@659df3 View:DecorView@66130f1[TestWindowActivity]
D: printViewRootImpl->android.view.ViewRootImpl@e567ab0 View:android.widget.PopupWindow$PopupDecorView{3ac2357 V.E...... R.....I. 0,0-0,0}
那我们根据结果看来：
WindowManagerGlobal的mViews和mRoots管理对应的DecorView和ViewRootImpl，DecorView和ViewRootImpl是一一对应的。- Acticity跟Dialog都有自己一一对应的 DecorView-ViewRootImpl-PhoneWindow，PopupWindow也会有自己的DecorView，区别是popupWindow的DecorView是
android.widget.PopupWindow$PopupDecorView，PopupWindow并没有对应的PhoneWindow。
所以，结论就是一个app可以存在多个WindowManagerImpl，有且只有一个WindowManagerGlobal，多个DecorView，多个ViewRootImpl，多个PhoneWindow。DecorView跟ViewRootImpl的数量是相同的而且是一一对应的，但是PhoneWindow的数量可能会少于ViewRootImpl的数量.
ViewRootImpl是怎么成为root的？
这里我们需要知道一个接口ViewParent，顾名思义，它是所有的ViewGroup都需要实现的一个接口，这样来实现view树的一个层级结构。
我们先看一下普通的view是怎么设置mParent的呢？代码在ViewGroup:
//ViewGroup.java
// Child views of this ViewGroup
private View[] mChildren;
// Number of valid children in the mChildren array, the rest should be null or not
// considered as children
private int mChildrenCount;
private void addViewInner(View child, int index, LayoutParams params,
boolean preventRequestLayout) {
...
if (preventRequestLayout) {
child.assignParent(this);
} else {
child.mParent = this;
}
...
}
在addView的时候代码设置了child的mParent是自己，设置了childview的mParent是当前ViewGroup，同时把childview放到mChildren属性里面，这样就关联起来了。
requestLayout也是ViewParent的一个方法，大部分的ViewGroup以及LinearLayout、RelativeLayout都没有重写requestLayout方法，都是使用的View的requestLayout定义：
public void requestLayout() {
...
if (mParent != null && !mParent.isLayoutRequested()) {
mParent.requestLayout();
}
...
}
一直调用parent的requestLayout方法，既然ViewGroup都没有重写，那就得往上一直到最顶层的view，需要关注最顶层的view的requestLayout方法都是怎么写的，那最顶层的View是谁呢？首先想到DecorView，但是DecorView也并没有重写requestLayout。那还有谁呢？我们发现ViewRootImpl其实并没有继承自View，但是它竟然实现了requestLayout方法！
所以不是View出身的ViewRootImpl到底是怎么成为一众View的爹的呢？
也就是ViewRootImpl是怎么成为DecorView的parent的，是怎么关联起来的？
调用栈如下(不画图了，没几行)：
ActivityThread:handleResumeActivity
|- WindowManagerGlobal:addView
|- ViewRootImpl:setView
view.assignParent(this);
ViewRootImpl#setView调用了view.assignParent(this);，将自己设置成了view也就是DecorView的parent。
其实最顶层的View还是DecorView，ViewRootImpl只是说实现了ViewParent方法用来做View的事件处理跟分发。
ViewRootImp 很重要，它有2个主要作用：
(1). 实现 android 的 View 系统的逻辑，发起布局、绘制等操作；
(2). 连接 应用窗口 和 服务端 WMS 的桥梁。它里面有一个内部类 H 实现了 IWindow 接口（Bn端）。对应就是 WMS 里面 WindowState 当中的 mClient（Bp端）。
setContentView发生了什么
第一个Hello World就知道需要把布局用一个setContentView()方法设置进去就可以显示，那到底这个方法发生了什么? 为什么一些Window相关的flag必须要在setContentView()之前设置，否则就不起作用呢？
我们先大致走完setContentView的整个流程，再来把每个我们关注的细节逐个击破。
#Activity.java
public void setContentView(@LayoutRes int layoutResID) {
getWindow().setContentView(layoutResID);
}
public void setContentView(View view) {
getWindow().setContentView(view);
}
...
public Window getWindow() {
return mWindow;
}
而mWindow是什么呢？我们搜mWindow = 关键字，发现在Activity的attach(...)方法里面，mWindow = new PhoneWindow(this, window, activityConfigCallback);
也就是说实际上调用了PhoneWindow的setContentView方法。
我们用AndroidStudio查看源码的时候可能查看不了PhoneWindow，因为它是
com.android.internal包下的，也就是所谓的隐藏API，不希望coder调用的，但是并不耽误我们查看并理解它的原理。 我们查找的时候只需要双击Shift并勾选右上角Include Non-project items
PhoneWindow.java
public void setContentView(View view, ViewGroup.LayoutParams params) {
...
if (mContentParent == null) {
installDecor();
}
...
mLayoutInflater.inflate(layoutResID, mContentParent);
...
}
private void installDecor() {
mForceDecorInstall = false;
if (mDecor == null) {
mDecor = generateDecor(-1);
...
} else {
mDecor.setWindow(this);
}
if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
...
}
}
protected DecorView generateDecor(int featureId) {
...
return new DecorView(context, featureId, this, getAttributes());
}
这里我们只看关键代码：
上面的代码判断如果mDecor==null就去创建DecorView，DecorView是Activity的一个rootView，不存在的时候直接new出来，然后判断mContentParent是否为null，在generateLayout(mDecor)中创建mContentParent，
也就是android.R.id.content这个我们耳熟能详的id，后面会根据类型再去创建R.id.decor_content_parent或者R.id.title。
installDecor做完了之后会继续执行mLayoutInflater.inflate(layoutResID, mContentParent);，这个我们就很熟悉了，也就是把 layoutResID对应的xml加载成view并add到mContentParent下面。
