window的类型
什么是window？通俗的来说，window就是系统划分的一个窗口，其本身是不可见的，是一个用来存储view的容器。
在Android系统中，window一共有三种类型，分别是System Window、Application Window以及Sub Window
各个类型的window如图所示，其中值得一提的是sub window，他们必须依附于另一种window之上，我们比较常用的就有dialog以及popwindow
Activity、Window、View的关系
view是我们眼睛具体看到界面；window本身是不可见的，本质上它只是系统划分的一个窗口，是用来放置view的容器；而activity则是一个管理者，维护整个环节的运行，统一的管理所有view的绘制流程。
如果用贴窗花来类比Android系统，那么activity就是剪窗花的人，window是窗子，view是窗花。
Application Window创建过程
Window、WindowManager、WindowManagerService
我们查看Activity的源码，发现其中有2个成员变量与window相关
private Window mWindow;
private WindowManager mWindowManager;
顾名思义，WindowManager是Window的管理类，但是它并不是真正的管理类。因为在android中，存在着很多很多的window，其管理者必然是一个系统级的、跨进程的服务，也就是WindowManagerService。那么WindowManager又做了什么呢？其实它可以算作一个拉皮条的，是window与wms之间通信的桥梁。
Window的初始化
开始分析源码，可以发现mWindow是在Activity的attach()方法中初始化的
mWindow = new PhoneWindow(this, window);
继续往下看，在最后，可以看见wm也是在其中初始化的。
mWindow.setWindowManager((WindowManager)context.getSystemService(Context.WINDOW_SERVICE),mToken, mComponent.flattenToString(),(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
if (mParent != null) {
mWindow.setContainer(mParent.getWindow());
}
mWindowManager = mWindow.getWindowManager();
那么attach()方法又是在什么时候被执行的呢？开动脑筋想一想，当然是在onCreate()之前啦。前面说过window是view的容器，那么在onCreate()将view添加进来之前，window肯定已经准备就绪了。具体这部分代码的分析就放在下篇activity启动流程之中。
View的加载
有道友不知道setContentView()吗？我们来看看activity中该方法的实现
public void setContentView(@LayoutRes int layoutResID) {
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
}
getwindow()会返回mWindow的实例，也就是调用了PhoneWindow的setContentView()方法
public void setContentView(int layoutResID) {
// Note: FEATURE_CONTENT_TRANSITIONS may be set in the process of installing the window
// decor, when theme attributes and the like are crystalized. Do not check the feature
// before this happens.
if (mContentParent == null) {
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}
if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
mLayoutInflater.inflate(layoutResID, mContentParent);
}
mContentParent.requestApplyInsets();
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
cb.onContentChanged();
}
}
当mContentParent为空时，首先会调用installDecor()方法。查看该方法，可以看到有一个叫mDecor的玩意儿，这东西是什么呢？
// This is the top-level view of the window, containing the window decor.
private DecorView mDecor;
官方注释是这么说的，mDecor是window中最顶层的view，也就是根view，是window中的第一个容器。查看DecorView的源码，也可以知道它是继承自FrameLayout。换句说中，我们所写的layout布局一定是放在DecorView中。
继续阅读installDecor()方法：
private void installDecor() {
if (mDecor == null) {
mDecor = generateDecor();
...
}
if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
...
}
}
当mDecor为空时，会调用generateDecor()方法初始化mDecor。这个方法很简单，就是直接new了一个DecorView对象并返回。
之后当mContentParent为空时，会以刚刚创建的mDecor为参数，通过generateLayout()方法给mContentParent赋值。
到此为止，mContentParent已经有值了，回到之前的setContentView()看到这行代码
mLayoutInflater.inflate(layoutResID, mContentParent);
这个layoutResID就是我们通过Layout布局资源。是不是一切都通畅了？window中有一个DecorView，mContentParent是DecorView的一部分，最终用户view通过mLayoutInflater的inflate()方法传递到DecorView中。
Window的显示过程
到现在为止，window已经创建并与activity绑定了，view也已经加载进window中了，是时候去看看window是如何显示在用户手机屏幕上了。
通过之前的分析可以知道，window是由系统服务WindowManagerService统一管理的。在activity的源码中，我们找不到它是如何通过wms添加到手机屏幕中的，既然如此，不妨换个思路，去看看其他类型window的源码。
PopupWindow
popupwindow是通过showAtLocation()显示在界面上的，直接查看该方法源码：
public void showAtLocation(IBinder token, int gravity, int x, int y) {
...
TransitionManager.endTransitions(mDecorView);
detachFromAnchor();
mIsShowing = true;
mIsDropdown = false;
mGravity = gravity;
final WindowManager.LayoutParams p = createPopupLayoutParams(token);
preparePopup(p);
p.x = x;
p.y = y;
invokePopup(p);
}
代码中间有一个叫WindowManager.LayoutParams的玩意儿，它继承自ViewGroup.LayoutParams，其存放了window在屏幕上显示时的各种参数。
在文章最开始时说window有三种类型，其实就是在WindowManager.LayoutParams中看到的。在此处我只是将三种大类列出来，每一个类别还有很多子类别，其中有一些是我们可以使用的，另一些是系统级别的。
/**
* Start of window types that represent normal application windows.
*/
public static final int FIRST_APPLICATION_WINDOW = 1;
/**
* Start of types of sub-windows. The {@link #token} of these windows
* must be set to the window they are attached to. These types of
* windows are kept next to their attached window in Z-order, and their
* coordinate space is relative to their attached window.
*/
public static final int FIRST_SUB_WINDOW = 1000;
/**
* Start of system-specific window types. These are not normally
* created by applications.
*/
public static final int FIRST_SYSTEM_WINDOW = 2000;
WindowManager.LayoutParams通过createPopupLayoutParams(token)方法进行初始化。这个方法很简单，就是将LayoutParams中的一系列参数进行赋值。
p.gravity = computeGravity();
p.flags = computeFlags(p.flags);
p.type = mWindowLayoutType;
p.token = token;
p.softInputMode = mSoftInputMode;
p.windowAnimations = computeAnimationResource();
传进去的参数token又是什么呢？
private WindowManager.LayoutParams createPopupLayoutParams(IBinder token)
原来token是一个IBinder对象，这里就很好理解了，window通过跨进程的windowManagerService进行统一的管理，那么wms必然需要某个标识来区分每一个window，而token显然就是这个标识。
接着看 preparePopup(p)方法。
if (mBackground != null) {
mBackgroundView = createBackgroundView(mContentView);
mBackgroundView.setBackground(mBackground);
} else {
mBackgroundView = mContentView;
}
最开始就说过，sub window必须依附在父window之上，而preparePopup(p)就是用来给popupwindow创建根view的。到此为止，window已经创建并被赋值了各种参数，根view也创建好了，剩下应该就是通过wms进行管理了，我们看最后一个方法invokePopup(p)
private void invokePopup(WindowManager.LayoutParams p) {
...
final PopupDecorView decorView = mDecorView;
decorView.setFitsSystemWindows(mLayoutInsetDecor);
...
mWindowManager.addView(decorView, p);
...
}
显而易见，最终让window显示在屏幕上的，是mWindowManager.addView(decorView, p)
mWindowManager是一个接口，找到其被实例化的地方
mWindowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
系统在开启的时候，会初始化很多的SystemService，此处通过aidl获取相关的系统服务，即WindowManagerImpl。
接着去找WindowManagerImpl的addView()，可以看到其最终调用了WindowManagerGlobal的addView()，这个方法很长，我挑重点展示一下：
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
...
//注释1
// 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);
}
}
}
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
//注释2
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
}
// do this last because it fires off messages to start doing things
try {
//注释3
root.setView(view, wparams, panelParentView);
} catch (RuntimeException e) {
...
}
}
首先看注释2，其中有三个集合， mViews、mRoots、mParams分别用来存放某个window的decorView，ViewRootImpl渲染器以及LayoutParams参数，且这三者的顺序是一一对应的。
接着看注释1，if语句中判断当前window的类型是否是sub window，如果是的话，就遍历mRoots集合，找到其中与当前window参数中token相同的window，并将其设置为当前window的父window。
之前说过这个token是一个IBinder对象，是用来在跨进程通信中确定window身份的。那么它具体是个什么玩意儿呢？
public void showAtLocation(View parent, int gravity, int x, int y) {
showAtLocation(parent.getWindowToken(), gravity, x, y);
}
从上面的代码可以知道，token就是当前window的父window的标识。原来如此，所以在windowManagerGlobal.addView()中，只要mRoots中某个window的token与当前window的layoutParams中的token相同，那么它就是当前window的父window。
最后看注释3，在前面已经获取了decorview，layoutParams以及panelParentView，所以现在就可通过ViewRootImpl的setView方法对屏幕进行渲染绘制了！
ViewRootImpl
setView这个方法比较长，选择其中跟window相关的最关键的代码
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(),mDisplay.getDisplayId(),mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,mAttachInfo.mOutsets, mInputChannel);
这里有一个叫做mWindowSession的东西。熟悉web的同学一定知道，session和cookie是服务器端与客户端用来进行身份识别的，其中session存放在服务器端，cookie存放在客户端。那么为啥在android系统里还会出现session呢？
在文章最开始就说过了，整个window的管理是一个进程间的管理，系统的windowManagerService就相当于服务器端，用户的每一个window所对应的windowManager就相当于客户端。因此这个IWindowSession就是wms用来识别不同wm的“身份证”。
再来看看IWindowSession初始化的地方，在ViewRootImpl的构造方法中，有这样一段
mWindowSession = WindowManagerGlobal.getWindowSession();
OK，回去找WindowManagerGlobal
public static IWindowSession getWindowSession() {
...
IWindowManager windowManager = getWindowManagerService();
sWindowSession = windowManager.openSession(
new IWindowSessionCallback.Stub() {
@Override
public void onAnimatorScaleChanged(float scale) {
ValueAnimator.setDurationScale(scale);
...
return sWindowSession;
}
}
艾玛，这不就是典型的AIDL嘛，首先看这里的windowManager
IWindowManager windowManager = getWindowManagerService();
不要被它的名字所欺骗，其实它是WindowManagerService的IBinder引用，不信就点进去看看getWindowManagerService，其中有这样一行代码
sWindowManagerService = IWindowManager.Stub.asInterface(
ServiceManager.getService("window"));
这儿就不多做解释了，对AIDL不太清楚的同学移步Binder恐怖如斯
现在我们已经获取了WindowManagerService的IBinder引用，接下来就是通过AIDL调用远程端的openSession方法。显而易见，我们要去wms中查看这个方法到底做了什么：
@Override
public IWindowSession openSession(IWindowSessionCallback callback, IInputMethodClient client,
IInputContext inputContext) {
...
Session session = new Session(this, callback, client, inputContext);
return session;
}
很简单，就是根据客户端创建了一个session并返回。顺带一提，wms是通过ArraySet来存放客户端的所有session信息的，有诗为证：
final ArraySet<Session> mSessions = new ArraySet<>();
回过神，现在我们带着获取到的session回到最开始的ViewRootImpl中，也就是res = mWindowSession.addToDisplay()。既然mWindowSession是服务端wms的一个IBinder引用，那么同上，我们要去wms中寻找addToDisplay这个方法。
遗憾的是，addToDisplay不见了！幸好天无绝人之路，虽然没有了addToDisplay，但是我们可以在wms中找到一个叫addWindow的方法。来对比一下这两家伙的参数。
addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(),mDisplay.getDisplayId(),mAttachInfo.mContentInsets,
mAttachInfo.mStableInsets,mAttachInfo.mOutsets, mInputChannel);
addWindow(Session session, IWindow client, int seq,
LayoutParams attrs, int viewVisibility, int displayId,
Rect outContentInsets, Rect outStableInsets, Rect outOutsets,
InputChannel outInputChannel)
巧不巧？你就说巧不巧！addWindow就比addToDisplay多了一个session参数。原来如此，客户端调用了IBinder的addToDisplay之后，会传入当前客户端的session,最终通过AIDL在服务端调用了addWindow方法。
那么这个addWindow又干了些什么呢？这就涉及到具体的绘制流程了，代码太复杂没法细看，总结起来就是一句话，判断各种权限、window的状态以及window的类型，之后对window进行绘制，最终将window绑定的结果返回给ViewRootImpl。
要注意的是，到此为止，window绘制完毕了，但是window中的view还是空空如也。而ViewRootImpl在获取到window的绑定结果后，如果成功，就会开始进行一系列的view的绘制流程。这部分的内容相当变态，咱们有缘再见吧。
Application Window显示过程
经过前面一大段的哔哔，Sub Window的显示过程已经说清楚了。还记得为什么我们要去看sub window的显示过程吗？因为Application Window的显示过程在activity里面找不到啊。但是在文章的末尾，这种坑怎么能不填呢？
遗憾的是，Application Window的显示过程和activity的生命周期有关，这部分的内容也是相当变态，需要有缘再见。所以先不要知道为什么，只要记住在ActivityThread中有一个叫handleResumeActivity()的方法，其中有这样一段：
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (a.mVisibleFromClient) {
a.mWindowAdded = true;
wm.addView(decor, l);
}
有没有一种便秘通畅的感觉？这段代码将window的类型设置为TYPE_BASE_APPLICATION，然后通过wm.addView(decor, l)开始和windowManagerService通信。
完结撒花~
