Window一本满足

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()方法

 @Override    public void setContentView(View view, ViewGroup.LayoutParams params) {        if (mContentParent == null) {            installDecor();        } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {            mContentParent.removeAllViews();        }        if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {            view.setLayoutParams(params);            final Scene newScene = new Scene(mContentParent, view);            transitionTo(newScene);        } else {            mContentParent.addView(view, params);        }        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()看到这行代码

 mContentParent.addView(view, params);

这个view就是我们通过Layout布局传递进来的界面。是不是一切都通畅了？window中有一个DecorView，mContentParent是DecorView的一部分，最终用户view通过mContentParent的addView()方法传递到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通信。

完结撒花~