这篇文章我不会去走一遍这几位的源码，只是提出几个关于他们的问题，附上我的了解，是自己的一个笔记，也期望能帮到有相同困惑的同学。
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下面。
