从这节起开始介绍view系列的文章，先从介绍Window，PhoneWindow相关类开始。
关于Window，PhoneWindow，DecorView，WindowManager这几个类相关的文章确实很多，但是我感觉对于它们的讲解都存在一些偏差。这几个类本身也是具有“迷惑性”的，因此我希望通过这篇文章能把它们及它们之间的关系介绍清楚。
通过本节您可以了解PhoneWindow，Window，DecorView，WindowManager，WindowManagerImpl，WindowManagerGlobal这些类及它们之间的关系
1.Window
Window类不是真正的窗口
Window这个类是一个让人很迷惑的类，在我刚接触这个类的时候，看到它的名字我非常确信它就是一个窗口一个“名副其实的窗口”。还有与它有关系的WindowManager，WindowManagerImpl这两个类，当看到这两个类的时候立马让我想到了WindowManagerService这个类，WindowManagerService作为一个服务运行在系统进程中管理所有的窗口，我天真的认为WindowManager和WindowManagerImpl就是与WindowManagerService相对应的类是提供与WindowManagerService进行binder通信的类。
当看了源码以后，我才发现上面的观点完全有问题，首先Window类它是”名不符实“，为什么这样说呢？Window类中没有measure（测量）相关方法，也没有layout（布局）相关的方法，甚至没有draw（绘制）相关的方法，甚至也没有最基本的width和height属性。我的理解是这样的既然作为一个窗口，那它就应该有上面提到的这些方法和属性。
别看WindowManagerService是管理所有的窗口，或者别看它的名字里面包含了Window这个词，但是Window类和WindowManagerService没有任何的关系（它俩谁也不认识谁），WindowManagerService中添加一个窗口的方法叫addWindow,别看方法名有Window这个词，这个方法添加的不是Window这个类，它的签名如下：
public int addWindow(Session session, IWindow client, LayoutParams attrs, int viewVisibility,
int displayId, int requestUserId, InsetsState requestedVisibility,
InputChannel outInputChannel, InsetsState outInsetsState,
InsetsSourceControl[] outActiveControls)
在调用WindowManager的addView方法的时候，也是根本和Window类没关系的，addView方法只是需要View和LayoutParams这两个参数，addView方法的签名如下：
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
}
Window类只是一个封装类
为了能帮助大家更深入的理解，现有如下假设：
- 没有Window类
- Activity中没有setContentView方法
- 框架层在第一次调用Activity的onResume方法之前把调用WindowManager的addView方法去掉（这样就需要开发者自己调用WindowManager的addView方法）
在上面假设的情况下，那我们看下在Activity是如何创建和显示View的，伪代码如下：
public class MainActivity extends Activity{
private View mRootView;
private WindowManager.LayoutParams mLayoutParams;
private boolean mIsFirstResume = false;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//把activity_main.xml解析出来
View rootView = getLayoutInflater().inflate(R.layout.activity_main);
WindowManager.LayoutParams layoutParams = new WindowManager.LayoutParams();
//设置flags
layoutParams.flags = WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
//设置窗口类型
layoutParams.type = WindowManager.LayoutParams.TYPE_APPLICATION;
//设置layoutParams的各种属性
layoutParams.format = PixelFormat.TRANSPARENT;
layoutParams.gravity = Gravity.TOP | Gravity.LEFT;
layoutParams.x = 0;
layoutParams.y = 0;
layoutParams.width = ViewGroup.LayoutParams.MATCH_PARENT;
layoutParams.height = ViewGroup.LayoutParams.MATCH_PARENT;
mRootView = rootView;
mLayoutParams = layoutParams;
}
@Override
protected void onResume() {
super.onResume();
//只有在第一次进入onResume的时候才去执行下面逻辑
if(mIsFirstResume){
mIsFirstResume = false;
//调用WIndowManager的addView方法，开始mRootView的显示
getWindowManager().addView(mRootView, mLayoutParams);
}
}
}
在Activity的onCreate方法中做以下事情：
- 调用LayoutInflater的inflate方法把activity_main.xml中的各种信息解析出来，获取到rootView
- 初始化WindowManager.LayoutParams的各种属性
在Activity的onResume方法中做以下事情：
- 在第一次进入onResume方法的时候，通过getWindowManager().addView(mRootView, mLayoutParams)这段代码 mRootView最终会被显示在屏幕上
其实在Android中View显示出来最根本的做法就是：调用WindowManager的addView方法，在Activity调用setContentView方法就可以设置View，其实是框架层把这些逻辑都封装了起来，从而感觉不到WindowManager的addView方法的存在。
上面的伪代码中的activity_main.xml中分为“标题栏”和“内容区域”，说实话上面的伪代码为MainActivity设置View还可以接受。
那现在问题来了，假如这时候需要为n个Activity设置View，那如果每个Activity都重复MainActivity里面的操作肯定不可取，作为一个合格的程序员这时候肯定想到了封装，把inflate rootView的操作和为WindowManager.LayoutParams设置各种属性的操作统统都封装到一个类中，这个类就叫做TempWindow吧，Activity直接使用这个封装类即可，这样使用起来方便多了。
TempWindow伪代码如下
class TempWindow{
private View mRootView;
private WindowManager.LayoutParams mLayoutParams;
TempWindow(Context context, int layoutResId){
View rootView = getLayoutInflater().inflate(layoutResId);
WindowManager.LayoutParams layoutParams = new WindowManager.LayoutParams();
//设置flags
layoutParams.flags = WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
//设置窗口类型
layoutParams.type = WindowManager.LayoutParams.TYPE_APPLICATION;
//设置layoutParams的各种属性
layoutParams.format = PixelFormat.TRANSPARENT;
layoutParams.gravity = Gravity.TOP | Gravity.LEFT;
layoutParams.x = 0;
layoutParams.y = 0;
layoutParams.width = ViewGroup.LayoutParams.MATCH_PARENT;
layoutParams.height = ViewGroup.LayoutParams.MATCH_PARENT;
mRootView = rootView;
mLayoutParams = layoutParams;
}
}
TempWindow解决了重复代码的问题，但是还有不方便的地方，每个Activity的布局文件都是分为：标题栏和内容区域两部分，Activity之间标题栏的差别其实并不大，但是每个Activity的布局文件都需要去写标题栏和内容区域，这确实太不方便了。
可以把标题栏拆到一个单独的layout文件中，那每个Activity的布局文件中都去include标题栏布局文件，这种办法确实可以解决问题，但是还是需要每个布局文件去include标题栏布局,这还不是最优解。那有没有更方便的方法呢？当然有了：可以写一个布局文件，暂且称它为root布局，它包含了标题栏和内容区域的父View，root.xml伪代码如下：
标题栏区域
结合上面的root.xml，再把TempWindow改造下：
public class TempWindow{
public View mRootView;
public WindowManager.LayoutParams mLayoutParams;
private View mContentView;
TempWindow(Context context){
//从root.xml中解析出rootView
View rootView = getLayoutInflater().inflate(R.layout.root);
//根据R.id.content_view从rootView中找出View并赋值给mContentView，
mContentView = rootView.findViewById(R.id.content_view);
WindowManager.LayoutParams layoutParams = new WindowManager.LayoutParams();
//设置flags
layoutParams.flags = WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
//设置窗口类型
layoutParams.type = WindowManager.LayoutParams.TYPE_APPLICATION;
//设置layoutParams的各种属性
layoutParams.format = PixelFormat.TRANSPARENT;
layoutParams.gravity = Gravity.TOP | Gravity.LEFT;
layoutParams.x = 0;
layoutParams.y = 0;
layoutParams.width = ViewGroup.LayoutParams.MATCH_PARENT;
layoutParams.height = ViewGroup.LayoutParams.MATCH_PARENT;
mRootView = rootView;
mLayoutParams = layoutParams;
}
//Activity调用这个方法把 自己的布局文件加入mContentView中
public void setContentView(int layoutResId){
View contentView = getLayoutInflater().inflate(layoutResId);
//把解析出来的contentView作为mContentView的子View加入mContentView中
mContentView.addView(contentView);
}
}
在Activity中使用新的TempWindow
public class MainActivity extends Activity{
private TempWindow mTempWindow;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mTempWindow = new TempWindow(this);
mTempWindow.setContentView(R.layout.activity_main);
}
@Override
protected void onResume() {
super.onResume();
//只有在第一次进入onResume的时候才去执行下面逻辑
if(mIsFirstResume){
mIsFirstResume = false;
//调用WIndowManager的addView方法，开始mRootView的显示
getWindowManager().addView(mTempWindow.mRootView, mTempWindow.mLayoutParams);
}
}
}
使用改造后的TempWindow是不是很方便，Activity中直接初始化一个TempWindow并且在onCreate方法里面直接调用TempWindow的setContentView方法就完事了。
TempWindow把公共的不易变化的内容都封装起来，比如初始化WindowManager.LayoutParams（它在一个app内的Activity应该都是一样的），标题栏（在Activity中也是一致的），界面的背景等。Activity只需要关注变化的部分也就是它们自己的内容View即可，TempWindow的setContentView方法叫作ContentView而不是RootView可以看出该 方法就是添加内容View的。Activity中的setContentView方法与TempWindow的setContentView方法意思是一样的。
其实就想通过介绍TempWindow的封装改造过程来间接的介绍Window类，当然Window类的功能肯定要比TempWindow更多，比如还包含了UI的background，点击事件的分发等。
Window类重要属性和方法介绍
FEATURE_开头的属性
凡是以”FEATURE_“开头的静态常量都是定义当前窗口具有什么特性（比如界面是带有标题栏呢，还是节目带有action bar）
- FEATURE_OPTIONS_PANEL：代表创建action bar的menu
- FEATURE_NO_TITLE：代表不显示标题栏
- FEATURE_PROGRESS：如果显示标题栏，则标题栏中显示进度条
- FEATURE_LEFT_ICON：如果显示标题栏，则标题栏显示左icon
- FEATURE_CUSTOM_TITLE：代表自定义标题栏
- FEATURE_ACTION_BAR：代表显示action bar
- FEATURE_CONTENT_TRANSITIONS：代表内容变化的时候的动画
上面只是列了一些常用的feature，其他的一些大家可以自行去看代码，一切都在代码里面
setFlags方法
它的方法定义如下：
public void setFlags(int flags, int mask) {
final WindowManager.LayoutParams attrs = getAttributes();
attrs.flags = (attrs.flags&~mask) | (flags&mask);
mForcedWindowFlags |= mask;
dispatchWindowAttributesChanged(attrs);
}
该方法的参数主要来自于WindowManager.LayoutParams.FLAG_开头的常量，比如设置窗口为全屏，可以使用下面代码设置：
setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN);
requestFeature方法
方法定义如下：
public boolean requestFeature(int featureId) {
final int flag = 1<该方法设置当前窗口的特性，比如设置窗口没有标题栏可以这样用：requestFeature(FEATURE_NO_TITLE)。它的参数就是上面的以FEATURE_开头的属性，该方法必须在setContentView方法调用之前才有效
findViewById方法
方法定义如下：
public T findViewById(@IdRes int id) {
return getDecorView().findViewById(id);
}
该方法作用就是根据view的id来查找到对应的View，咱们在Activity经常使用findViewById这个方法，其实最终会调用到Window的findViewById方法，而Window中又会调用到DecorView的findViewById方法。
getDecorView方法
方法定义如下：
public abstract @NonNull View getDecorView();
该方法是一个抽象方法，获取DecorView，子类去实现
小结
Window类它不是真正的窗口，和WindowManagerService没有任何关系，它只是一个封装类把公共的不易变化的内容都封装起来（比如把标题栏，UI background等封装起来），让Activity只关注content View即可，添加显示content View更简单（只需要调用Activity的setContentView方法即可，不需要关心关心WindowManager.LayoutParams这些属性的设置）
Window类的使用者可不是单单只有Activity，还有Dialog等
2.DecorView
先从下面的关于DecorView两幅图开始
上图展示的是一个Activity的界面绘制在屏幕上的效果图和界面的每个部分所对应的View；下图展示的上图界面的View层级关系。
下面就结合上面的两幅图来详细的介绍DecorView。
DecorView的子View
从上面两幅图可以看出DecorView是整个View层级最顶层View，它包含的直接子View有navigationBarBackground，statusBarBackground，LinearLayout
navigationBarBackground
看它的名字就知道，它与navigationBar的background有关系，它就是一个View，主要的作用就是用来设置navigationBar的背景色。它的高度是固定不变的（如上面DecorView的两幅图中的上图），DecorView中会设置它的高度，它位于整个屏幕的底部，但是它的颜色是可以自定义的，比如您可以根据自己app的需求把它设置为黑色或者别的颜色。并且是可以隐藏navigation bar的，这样就间接的隐藏了navigationBarBackground（navigation bar都已经隐藏了，navigationBarBackground当然没有存在的必要了）。
statusBarBackground
它的作用是设置status bar的背景色，和navigationBarBackground类似，它的高度在DecorView中会被设置，它位于整个屏幕的最顶部，它的颜色值是可以自定义的（如上面的上图它的颜色设置为蓝色），自定义它的颜色值主要是在themes.xml样式文件中设置，如下代码：
status bar也是可以隐藏的，比如在全屏观看视频的时候，status bar会被隐藏，随之statusBarBackground也会隐藏。
navigationBarBackground和statusBarBackground它们被设计出来的主要目的是：为了能让开发者控制status bar和navigation bar的背景色，这样就可以让整个界面更加的协调一致了。
navigationBarBackground和statusBarBackground能改变status bar和navigation bar背景色的主要原理是：Activiity中DecorView它的大小与屏幕大小一致。status bar和navigation bar的层级想对于Activity中DecorView要高很多（在z轴上的值要大很多），并且它们的背景都是透明的，因此status bar和navigation bar是“漂浮于“DecorView上的。这样在DecorView中修改navigationBarBackground和statusBarBackground它们的色值，从而以障眼法的方式看上去status bar和navigation bar的背景色被修改了，其实并没有。
contentRoot
如上面DecorView的两幅图中的上图，contentRoot它的高度是从DecorView的顶部到navigationBarBackground这段距离，如上面DecorView的两幅图中的下图，contentRoot它对应的是LinearLayout。contentRoot对应的就是上面提到的Window类中的不同主题类型的布局文件中的root view。不同的主题类型：比如有带标题栏的主题，带action bar的主题，或者只有内容的主题。
它包含View主要分为两部分：标题栏/action bar和contentParent。
标题栏/action bar开发者基本上不用，开发者一般都是自己来封装自己的标题栏。contentParent：在调用Activity的setContentView方法的时候设置的content view最终会被添加到contentParent中，并且它的id是：com.android.internal.R.id.content。
DecorView会根据各种情况比如窗口设置了全屏，隐藏了navigation bar或者隐藏了status bar等 来设置contentRoot的margin top/left/bottom/right的值,相关设置代码如下：
WindowInsets updateColorViews(WindowInsets insets, boolean animate) {
WindowManager.LayoutParams attrs = mWindow.getAttributes();
int sysUiVisibility = attrs.systemUiVisibility | getWindowSystemUiVisibility();
省略代码......
final WindowInsetsController controller = getWindowInsetsController();
// IME is an exceptional floating window that requires color view.
final boolean isImeWindow =
mWindow.getAttributes().type == WindowManager.LayoutParams.TYPE_INPUT_METHOD;
if (!mWindow.mIsFloating || isImeWindow) {
//consumingNavBar代表是否占据navigation bar的位置
boolean consumingNavBar =
((attrs.flags & FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS) != 0
&& (sysUiVisibility & SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION) == 0
&& decorFitsSystemWindows
&& !hideNavigation)
|| forceConsumingNavBar;
// If we didn't request fullscreen layout, but we still got it because of the
// mForceWindowDrawsBarBackgrounds flag, also consume top inset.
// If we should always consume system bars, only consume that if the app wanted to go to
// fullscreen, as othrewise we can expect the app to handle it.
//是否是全屏显示
boolean fullscreen = (sysUiVisibility & SYSTEM_UI_FLAG_FULLSCREEN) != 0
|| (attrs.flags & FLAG_FULLSCREEN) != 0
|| !(controller == null || controller.isRequestedVisible(ITYPE_STATUS_BAR));
//consumingStatusBar代表是否占据status bar的位置
boolean consumingStatusBar = (sysUiVisibility & SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN) == 0
&& decorFitsSystemWindows
&& (attrs.flags & FLAG_LAYOUT_IN_SCREEN) == 0
&& (attrs.flags & FLAG_LAYOUT_INSET_DECOR) == 0
&& mForceWindowDrawsBarBackgrounds
&& mLastTopInset != 0
|| (mLastShouldAlwaysConsumeSystemBars && fullscreen);
//下面计算 consumed top/right/bottom/left 值
//如果占据status bar的位置则consumedTop的值为mLastTopInset，mLastTopInset的值为status bar的高度
int consumedTop = consumingStatusBar ? mLastTopInset : 0;
int consumedRight = consumingNavBar ? mLastRightInset : 0;
//如果占据navigation bar位置，则consumedBottom设置为mLastBottomInset，mLastBottomInset代表navigation bar的高度值
int consumedBottom = consumingNavBar ? mLastBottomInset : 0;
int consumedLeft = consumingNavBar ? mLastLeftInset : 0;
//开始对mContentRoot的layoutparmas设置
if (mContentRoot != null
&& mContentRoot.getLayoutParams() instanceof MarginLayoutParams) {
MarginLayoutParams lp = (MarginLayoutParams) mContentRoot.getLayoutParams();
if (lp.topMargin != consumedTop || lp.rightMargin != consumedRight
|| lp.bottomMargin != consumedBottom || lp.leftMargin != consumedLeft) {
//对mContentRoot的top/right/bottom/left的margin分别设置
lp.topMargin = consumedTop;
lp.rightMargin = consumedRight;
lp.bottomMargin = consumedBottom;
lp.leftMargin = consumedLeft;
mContentRoot.setLayoutParams(lp);
if (insets == null) {
// The insets have changed, but we're not currently in the process
// of dispatching them.
requestApplyInsets();
}
}
if (insets != null) {
insets = insets.inset(consumedLeft, consumedTop, consumedRight, consumedBottom);
}
}
省略代码......
return insets;
}
DecorView是啥？
DecorView继承了FrameLayout类，DecorView是一个窗口中整个View层级最顶层View。正如其名”装饰View“它也确实有如此的功能，DecorView通过navigationBarBackground和statusBarBackground这两个View搭建了”装饰“了navigation bar和status bar的功能。使用者就可以根据自己的需求来”装饰“navigation bar和status bar的样子了。如果想隐藏它们也是可以的。DecorView同样有”装饰“contentRoot的功能，可以对contentRoot的上下左右margin值进行设置，来修改contentRoot的显示边界。
DecorView既然是一个窗口中整个View层级最顶层View，那很多非常重要的事情肯定是先通知到它，它作为顶级View然后在把相应的通知分发给它的子View，孙子View等等。ViewRootImpl类作为一个具有非常丰富功能的超级顶级类，它的其中最重要的mView属性它的值指向的就是DecorView。
ViewRootImpl中比如有点击事件发生的时候，就会调用DecorView的dispatchPointerEvent方法，DecorView最终会把点击事件分发到它的对应子View，看谁能处理这个事件。比如绘制事件发生的时候，会调用到DecorView的updateDisplayListIfDirty方法，DecorView开始递归调用它的子View，孙子View去进行绘制。
DecorView就介绍到此，下面介绍PhoneWindow。
3.PhoneWindow
PhoneWindow类是Window类的唯一子类，它实现了Window类中的一些方法比如实现了getDecorView()方法，会返回一个DecorView。很多的功能已经在Window类介绍过了，在此介绍下PhoneWindow是如何实现不同的特性窗口的。
不同特性的窗口
PhoneWindow类中实现不同特性的窗口的代码主要在generateLayout方法中，那就来看下这方法
protected ViewGroup generateLayout(DecorView decor) {
//获取各种window相关的属性，放入TypedArray中
TypedArray a = getWindowStyle();
省略代码......
//如果设置了Window_windowIsFloating，则代表是一个float类型的窗口，Dialog就是这种类型的窗口
mIsFloating = a.getBoolean(R.styleable.Window_windowIsFloating, false);
int flagsToUpdate = (FLAG_LAYOUT_IN_SCREEN|FLAG_LAYOUT_INSET_DECOR)
& (~getForcedWindowFlags());
//mIsFloating为true（Dialog的时候该值为true），则调用setLayout方法设置WindowManager.LayoutParams attrs的width和height属性为WRAP_CONTENT
if (mIsFloating) {
setLayout(WRAP_CONTENT, WRAP_CONTENT);
setFlags(0, flagsToUpdate);
} else {
setFlags(FLAG_LAYOUT_IN_SCREEN|FLAG_LAYOUT_INSET_DECOR, flagsToUpdate);
getAttributes().setFitInsetsSides(0);
getAttributes().setFitInsetsTypes(0);
}
//如果R.styleable.Window_windowNoTitle为true，则代表是不需要标题栏的窗口，则调用requestFeature(FEATURE_NO_TITLE)
if (a.getBoolean(R.styleable.Window_windowNoTitle, false)) {
requestFeature(FEATURE_NO_TITLE);
} else if (a.getBoolean(R.styleable.Window_windowActionBar, false)) {
// Don't allow an action bar if there is no title.
//不需要action bar的窗口
requestFeature(FEATURE_ACTION_BAR);
}
省略其他的feature设置代码......
//下面代码设置各种flag值，比如全屏了，status bar/navigation bar为透明了等
if (a.getBoolean(R.styleable.Window_windowFullscreen, false)) {
setFlags(FLAG_FULLSCREEN, FLAG_FULLSCREEN & (~getForcedWindowFlags()));
}
if (a.getBoolean(R.styleable.Window_windowTranslucentStatus,
false)) {
setFlags(FLAG_TRANSLUCENT_STATUS, FLAG_TRANSLUCENT_STATUS
& (~getForcedWindowFlags()));
}
if (a.getBoolean(R.styleable.Window_windowTranslucentNavigation,
false)) {
setFlags(FLAG_TRANSLUCENT_NAVIGATION, FLAG_TRANSLUCENT_NAVIGATION
& (~getForcedWindowFlags()));
}
省略代码.....
//设置Dialog的窗口的dim属性
if (a.getBoolean(R.styleable.Window_backgroundDimEnabled,
mIsFloating)) {
/* All dialogs should have the window dimmed */
if ((getForcedWindowFlags()&WindowManager.LayoutParams.FLAG_DIM_BEHIND) == 0) {
params.flags |= WindowManager.LayoutParams.FLAG_DIM_BEHIND;
}
if (!haveDimAmount()) {
params.dimAmount = a.getFloat(
android.R.styleable.Window_backgroundDimAmount, 0.5f);
}
}
省略代码......
//下面的代码就很有意思了，根据features去获取布局文件（layoutResource）
int layoutResource;
int features = getLocalFeatures();
//如果当前的窗口特性的标题栏是包含left icon或者right icon的，则进入下面的逻辑
if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON))) != 0) {
//悬浮类型的窗口，则进入下面逻辑（Dialog会走这）
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogTitleIconsDecorLayout, res, true);
layoutResource = res.resourceId;
} else {
layoutResource = R.layout.screen_title_icons;
}
// XXX Remove this once action bar supports these features.
removeFeature(FEATURE_ACTION_BAR);
// System.out.println("Title Icons!");
} else if ((features & ((1 << FEATURE_PROGRESS) | (1 << FEATURE_INDETERMINATE_PROGRESS))) != 0
&& (features & (1 << FEATURE_ACTION_BAR)) == 0) {
// Special case for a window with only a progress bar (and title).
// XXX Need to have a no-title version of embedded windows.
//如果是FEATURE_PROGRESS或者FEATURE_INDETERMINATE_PROGRESS特性的并且没有FEATURE_ACTION_BAR的窗口，则使用R.layout.screen_progress的布局文件
layoutResource = R.layout.screen_progress;
// System.out.println("Progress!");
} else if ((features & (1 << FEATURE_CUSTOM_TITLE)) != 0) {
//如果是自定义的特性的窗口，则进入这
// Special case for a window with a custom title.
// If the window is floating, we need a dialog layout
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogCustomTitleDecorLayout, res, true);
layoutResource = res.resourceId;
} else {
//使用R.layout.screen_custom_title布局文件
layoutResource = R.layout.screen_custom_title;
}
// XXX Remove this once action bar supports these features.
removeFeature(FEATURE_ACTION_BAR);
} else if ((features & (1 << FEATURE_NO_TITLE)) == 0) {
//如果是没有标题栏的特性的窗口，则进入这的逻辑
// If no other features and not embedded, only need a title.
// If the window is floating, we need a dialog layout
if (mIsFloating) {
TypedValue res = new TypedValue();
getContext().getTheme().resolveAttribute(
R.attr.dialogTitleDecorLayout, res, true);
layoutResource = res.resourceId;
} else if ((features & (1 << FEATURE_ACTION_BAR)) != 0) {
//如果是action bar特性的窗口，则使用R.layout.screen_action_bar布局文件
layoutResource = a.getResourceId(
R.styleable.Window_windowActionBarFullscreenDecorLayout,
R.layout.screen_action_bar);
} else {
layoutResource = R.layout.screen_title;
}
// System.out.println("Title!");
} else if ((features & (1 << FEATURE_ACTION_MODE_OVERLAY)) != 0) {
layoutResource = R.layout.screen_simple_overlay_action_mode;
} else {
//默认使用R.layout.screen_simple布局文件
// Embedded, so no decoration is needed.
layoutResource = R.layout.screen_simple;
}
//mDecor它的类型是DecorView，调用onResourcesLoaded方法会把layoutResource解析出来，并且add view到mDecor中，这样DecorView中就有子View了
mDecor.onResourcesLoaded(mLayoutInflater, layoutResource);
//contentParent View它的id值是ID_ANDROID_CONTENT，因为上面已经把layoutResource对应的View加入到了DecorView中，因此调用findViewById可以找到contentParent View
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
省略代码......
}
PhoneWindow主要根据下面的步骤来生成不同特性的窗口：
1.获取样式信息并设置feature
会从themes.xml样式文件中获取到对应的信息，比如根据R.styleable.Window_windowIsFloating获取的值为true，则代表当前的窗口是float类型的（Dialog就是这种类型的），比如根据R.styleable.Window_windowNoTitle获取的值为true，则代表当前的窗口是不需要标题栏的。获取到对应的样式信息后，调用requestFeature方法来设置窗口特性。
因此这也是在themes.xml样式文件中能控制生成什么样特性窗口的原因
2.获取样式信息并设置flag
比如上面的样式文件中，设置了”android:windowFullscreen“的值为true，则PhoneWindow类中会解析到R.styleable.Window_windowFullscreen的值，并且调用 setFlags(FLAG_FULLSCREEN, FLAG_FULLSCREEN & (~getForcedWindowFlags())) 方法设置窗口为全屏显示。
其他的样式文件中的设置也如此类似，因此这也是在themes.xml样式文件中能控制窗口的flag值的原因。
3.获取布局文件
上面的各种信息都设置完毕后，就可以根据最后的features信息来断定是使用哪个布局文件了。
比如如果是FEATURE_PROGRESS或者FEATURE_INDETERMINATE_PROGRESS特性的并且没有FEATURE_ACTION_BAR的窗口，则使用R.layout.screen_progress布局文件
screen_progress.xml的代码如下：
//圆形progress
//内容View
在比如默认特性的窗口，它的布局文件是R.layout.screen_simple,它的内容是特别简单的，它的代码如下：
PhoneWindow根据不同的features去加载使用不同的布局文件。
4.contentRoot添加到DecorView
这里的contentRoot对应的就是上一步 根据不同的features去加载使用不同的布局文件 的根View（调用LayoutInflater的inflate方法是可以把布局文件的所有View都解析出来的），调用DecorView的addView方法就可以把contentRoot添加到DecorView中。
到此关于PhoneWindow生成不同特性的窗口就介绍完了。
4.WindowManager
WindowManager它是一个接口，从它的名字来看以为它和WindowManagerService（简称WMS）能有那么一点点的关系，但是你错了，它和WMS没有办毛钱关系。它做了一件”偷梁换柱”的事情，那这个事情是啥事情呢，下面就来聊下。
WindowManager和WindowManagerService没有任何关系
大家都知道我们是可以通过Context的getSystemServiceName方法获取到各种服务的，比如下面代码
//获取ActivityManager
ActivityManager activityManager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
如上代码，通过调用getSystemService(Context.ACTIVITY_SERVICE)方法是可以获取到ActivityManager的实例，这个ActivityManager就是ActivityManagerService的binder代理类，调用ActivityManager的方法最后通过binder调用是可以到达ActivityManagerService的对应方法的。
同理我们也可以使用如下代码获取到WindowManager
WindowManager windowManager = (WindowManager) getSystemService(Context.WINDOW_SERVICE);
但是获取的这个WindowManager却和WindowManagerService没有任何关系，更谈不上与WMS通信了。
那我们就来看下为啥它们之间没有关系，从Context的getSystemService方法开始说起，Context是一个抽象类，ContextImpl类继承了Context，它也实现了getSystemService方法，如下代码
@Override
public Object getSystemService(String name) {
if (vmIncorrectContextUseEnabled()) {
// Check incorrect Context usage.
if (WINDOW_SERVICE.equals(name) && !isUiContext()) {
final String errorMessage = "Tried to access visual service "
+ SystemServiceRegistry.getSystemServiceClassName(name)
+ " from a non-visual Context:" + getOuterContext();
final String message = "WindowManager should be accessed from Activity or other "
+ "visual Context. Use an Activity or a Context created with "
+ "Context#createWindowContext(int, Bundle), which are adjusted to "
+ "the configuration and visual bounds of an area on screen.";
final Exception exception = new IllegalAccessException(errorMessage);
StrictMode.onIncorrectContextUsed(message, exception);
Log.e(TAG, errorMessage + " " + message, exception);
}
}
//从SystemServiceRegistry获取服务
return SystemServiceRegistry.getSystemService(this, name);
}
上面方法最终调用了SystemServiceRegistry的getSystemService方法
public static Object getSystemService(ContextImpl ctx, String name) {
if (name == null) {
return null;
}
//从SYSTEM_SERVICE_FETCHERS中获取
final ServiceFetcher fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
省略代码......
return ret;
}
SYSTEM_SERVICE_FETCHERS是一个Map类型，在当前方法中是直接从SYSTEM_SERVICE_FETCHERS中获取，那肯定就有往SYSTEM_SERVICE_FETCHERS中注册的地方
static{
省略其他的注册代码......
//看到没有，这个地方注册了Context.WINDOW_SERVICE，它的最终会返回一个WindowManagerImpl实例
registerService(Context.WINDOW_SERVICE, WindowManager.class,
new CachedServiceFetcher() {
@Override
public WindowManager createService(ContextImpl ctx) {
return new WindowManagerImpl(ctx);
}});
registerService(Context.USER_SERVICE, UserManager.class,
new CachedServiceFetcher() {
@Override
public UserManager createService(ContextImpl ctx) throws ServiceNotFoundException {
IBinder b = ServiceManager.getServiceOrThrow(Context.USER_SERVICE);
IUserManager service = IUserManager.Stub.asInterface(b);
return new UserManager(ctx, service);
}});
省略其他的注册代码......
}
各种服务的注册是在SystemServiceRegistry类的静态块中进行的，在注册window服务的时候Context.WINDOW_SERVICE，最终会返回一个WindowManagerImpl实例。看下别的服务的注册比如Context.USER_SERVICE，它最终会返回UserManagerService的binder代理类IUserManager，并且封装到Usermanager中。
从上面分析可知道，最终通过调用getSystemService(Context.WINDOW_SERVICE)获取的WindowManager，它是WindowManagerImpl类型的实例，WindowManagerImpl实现了WindowManager接口，因此WindowManagerImpl和WindowManagerService没有任何关系，也更不会与WMS进行binder通信了。
LayoutParams
LayoutParams类定义了很多与布局相关的很多属性比如width/height等，还定义了很多的常量，现在就介绍几个关键的属性。
窗口类型
为了对窗口有一个统一的管理，每种窗口都有它自己的type值，可以根据type值的大小来决定窗口的显示层级（在Z轴上的值）type值越大窗口显示的层级越大（离用户更近），这样如Toast就会显示在Activity的界面之上。
同时也可以根据type值的范围对窗口进行分类，大致可以划分为三类：应用程序级别的窗口，子窗口级别的窗口，系统级别的窗口。它们的type值是越来越大的。
应用程序级别的窗口：它的type值的范围是从1--99
TYPE_BASE_APPLICATION：1
TYPE_APPLICATION ：2 Activity对应的窗口
TYPE_APPLICATION_STARTING：3 应用程序第一次启动的时候，白色背景的窗口
TYPE_DRAWN_APPLICATION：4
LAST_APPLICATION_WINDOW：99子窗口级别的窗口：它的type值的范围是从1000--1999
TYPE_APPLICATION_PANEL：1000
TYPE_APPLICATION_MEDIA：1001
TYPE_APPLICATION_SUB_PANEL：1002
LAST_SUB_WINDOW：1999系统级别的窗口：它的type值范围是从2000--2999
TYPE_STATUS_BAR：2000 status bar
TYPE_SEARCH_BAR：2001 search bar
TYPE_SYSTEM_ALERT：2003 比如电量不足界面
TYPE_TOAST：2005 toast
LAST_SYSTEM_WINDOW：2999
上面的这些type值都定义在LayoutParams类中，只是选取了其中一部分。LayoutParams有一个type属性，它的值就取自上面的这些值，type属性的值并不是想用那个就用哪个是有要求的，比如当前窗口是应用程序级别，则它的type值就不能是2000以上的，因为2000以上是系统就级别的窗口，并且使用2000以上的窗口是需要权限的。
各种FLAG
LayoutParams中定义了各种类型的FLAG常量，它们用来控制窗口的一些特性
- FLAG_KEEP_SCREEN_ON：设置了这个flag，则不会锁屏
- FLAG_FULLSCREEN：代表窗口是全屏
上面列举了常用的两个，当然还有很多，LayoutParams的flags属性会持有这些FLAG值
关于LayoutParams类的介绍到此为止。
WindowManager的关键方法
下面三个关键方法都是从ViewManager继承来的
addView
它的声明如下：
public void addView(View view, ViewGroup.LayoutParams params);
这是个抽象方法，WindowManagerImpl实现了这个方法，它的主要作用是添加一个View和它的LayoutParams
updateViewLayout
它的声明如下：
public void updateViewLayout(View view, ViewGroup.LayoutParams params);
同样也是抽象方法，WindowManagerImpl实现了这个方法，它的作用是更新某个View和它的LayoutParams
removeView
它的声明如下：
public void removeView(View view);
同样也是抽象方法，WindowManagerImpl实现了这个方法，它的作用是移除View
上面的三个方法都很View有关系，比如addView方法主要是把一个View（它肯定是根View）和它对应的LayoutParams（View的layout相关的属性都在这个类中，比如width和height，还比如上面介绍的type和flags）进行添加，到底add到什么地方，后面会详细介绍到。
小结
WindowManager从名字上来看是不是管理Window的，应该和Window类有关系，最起码应该有addWindow，removeWindow这类的方法，但是其实不然，WindowManager和Window类没有关系，上面提到的三个方法也都和Window类没有关系，甚至它也没有addWindow，removeWindow这些方法。哈哈是不是世界观被侮辱了。还是上面提到的Window类的存在就是为了给开发者带来方便，android中添加和显示View的最终方法是WindowManager的addView方法，它的参数是View和LayoutParams，和Window类无关。
5.WindowManagerGlobal
WindowManagerGlobal这个类从它的名字中的Global可以看出在一个进程中肯定只存在一个实例。下面是它的生成单例的方法
public static WindowManagerGlobal getInstance() {
synchronized (WindowManagerGlobal.class) {
if (sDefaultWindowManager == null) {
sDefaultWindowManager = new WindowManagerGlobal();
}
return sDefaultWindowManager;
}
}
还记得上面提到的WindowManagerImpl类吗？通过调用getSystemService(Context.WINDOW_SERVICE)返回的就是WindowManagerImpl实例，这时候调用它的addView方法最终会调用到WindowManagerGlobal类的addView方法，addView方法的代码如下：
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow, int userId) {
省略代码......
ViewRootImpl root;
View panelParentView = null;
synchronized (mLock) {
// Start watching for system property changes.
if (mSystemPropertyUpdater == null) {
mSystemPropertyUpdater = new Runnable() {
@Override public void run() {
synchronized (mLock) {
for (int i = mRoots.size() - 1; i >= 0; --i) {
mRoots.get(i).loadSystemProperties();
}
}
}
};
SystemProperties.addChangeCallback(mSystemPropertyUpdater);
}
int index = findViewLocked(view, false);
if (index >= 0) {
if (mDyingViews.contains(view)) {
// Don't wait for MSG_DIE to make it's way through root's queue.
mRoots.get(index).doDie();
} else {
throw new IllegalStateException("View " + view
+ " has already been added to the window manager.");
}
// The previous removeView() had not completed executing. Now it has.
}
// If this is a panel window, then find the window it is being
// attached to for future reference.
if (wparams.type >= WindowManager.LayoutParams.FIRST_SUB_WINDOW &&
wparams.type <= WindowManager.LayoutParams.LAST_SUB_WINDOW) {
final int count = mViews.size();
for (int i = 0; i < count; i++) {
if (mRoots.get(i).mWindow.asBinder() == wparams.token) {
panelParentView = mViews.get(i);
}
}
}
//生成ViewRootImpl的实例，赋值给root
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
//把view，root，params存储到各自的列表中
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// do this last because it fires off messages to start doing things
try {
//调用ViewRootImpl的setView方法，设置View，params等参数，这个方法被调用后开始了View的绘制等流程
root.setView(view, wparams, panelParentView, userId);
} catch (RuntimeException e) {
// BadTokenException or InvalidDisplayException, clean up.
if (index >= 0) {
removeViewLocked(index, true);
}
throw e;
}
}
}
addView方法主要做了以下几件事情：
- 各种异常判断
- 生成ViewRootImpl的实例
- 把root，view（这个view通常是DecorView类型），params等存储到各自的列表中
- 调用ViewRootImpl的setView方法，这个方法被调用后就开启了View的绘制流程，ViewRootImpl会和WMS建立交互，ViewRootImpl依据vsync机制进行View的绘制工作，并且把绘制的buffer通过binder调用传递给SurfaceFlinger进程，进行渲染等操作
小结
WindowManagerGlobal在一个进程中存在一个实例，它的addView方法中会把的View（View一般是DecorView类型），LayoutParams，ViewRootImpl这些值保存起来，并且最终会调用ViewRootImpl的setView方法开启View的绘制等流程。它的removeView方法中会把保持的View，LayoutParams，ViewRootImpl这些值移除。
因为通过调用getSystemService(Context.WINDOW_SERVICE)返回的就是WindowManagerImpl实例，那如果想与WMS（WindowManagerService）交互的话该怎么进行呢？
WindowManagerGlobal类中给出了结果，如果需要与WMS通信，需要从WMS获取一个Session的binder代理实例，这个代理实例在一个进程中只存在一个，如下代码：
@UnsupportedAppUsage
private static IWindowManager sWindowManagerService;
@UnsupportedAppUsage
private static IWindowSession sWindowSession;
@UnsupportedAppUsage
public static IWindowSession getWindowSession() {
synchronized (WindowManagerGlobal.class) {
//sWindowSession为null，则去获取
if (sWindowSession == null) {
try {
// Emulate the legacy behavior. The global instance of InputMethodManager
// was instantiated here.
// TODO(b/116157766): Remove this hack after cleaning up @UnsupportedAppUsage
InputMethodManager.ensureDefaultInstanceForDefaultDisplayIfNecessary();
//先获取WindowManagerService的binder代理对象，这个对象是可以通过binder与WMS进行通信的
IWindowManager windowManager = getWindowManagerService();
//调用WMS的openSession方法，获取Session的binder代理对象
sWindowSession = windowManager.openSession(
new IWindowSessionCallback.Stub() {
@Override
public void onAnimatorScaleChanged(float scale) {
ValueAnimator.setDurationScale(scale);
}
});
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
return sWindowSession;
}
}
@UnsupportedAppUsage
public static IWindowManager getWindowManagerService() {
synchronized (WindowManagerGlobal.class) {
if (sWindowManagerService == null) {
//获取WMS的binder代理对象
sWindowManagerService = IWindowManager.Stub.asInterface(
ServiceManager.getService("window"));
try {
if (sWindowManagerService != null) {
ValueAnimator.setDurationScale(
sWindowManagerService.getCurrentAnimatorScale());
sUseBLASTAdapter = sWindowManagerService.useBLAST();
}
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
return sWindowManagerService;
}
}
如上代码，WindowManagerGlobal的getWindowSession方法返回Session的binder代理对象，这样就可以调用对应的方法与Session进行通信，最终与WMS进行通信。
6.总结
DecorView类：继承了FrameLayout类，DecorView是一个窗口中整个View层级最顶层View。正如其名”装饰View“它也确实有如此的功能，DecorView通过navigationBarBackground和statusBarBackground这两个View搭建了”装饰“了navigation bar和status bar的功能。使用者就可以根据自己的需求来”装饰“navigation bar和status bar的样子了。如果想隐藏它们也是可以的。DecorView同样有”装饰“contentRoot的功能，可以对contentRoot的上下左右margin值进行设置，来修改contentRoot的显示边界。DecorView也是为Activity服务的，正是因为有了Window和PhoneWindow类，DecorView才有意义。
Window类，PhoneWindow类：它们就是封装类，主要作用是帮助开发者在Activity/Dialog中更方便快捷的添加显示View，并且提供了不同特性的窗口（比如有带标题栏的窗口，有带action bar的窗口，有带progress和title功能的窗口），Window类和WindowManagerService类没有任何的关系，虽然WindowManagerService中有addWindow的方法，但是这个方法也和Window类没有关系。DecorView的显示最终要调用WindowManager的addView方法，把DecorView和PhoneWindow中获取的LayoutParams作为addView的参数。
WindowManager接口，WindowManagerImpl类，WindowManagerGlobal类：它们是与addView，updateView，removeView功能有关系的类。调用getSystemService(Context.WINDOW_SERVICE)方法获取的是WindowManagerImpl实例，WindowManagerImpl实现了WindowManager接口，但是真正干活的不是WindowManagerImpl，而是WindowManagerGlobal，WindowManagerGlobal在一个进程中只存在一个实例，它会把View（View一般是DecorView类型），LayoutParams，ViewRootImpl这些值保存起来，它会与ViewRootImpl进行交互最终开启View的显示绘制流程。
这三个类与Window类没有关系，它们的名字中都有管理Window的功能，按道理来说它们应该有类似于addWindow/removeWindow/updateWindow相关的方法来进行与Window相关的操作，但是它们中却没有与Window类相关的方法，添加/更新/移除相关的方式是addView，updateView，removeView。
WindowManger接口和WindowManagerImpl类和WindowManagerService服务也没有任何的关系。