Window表示一个窗口的概念，在日常开发中直接接触Window的机会并不多，但是在某些特殊时候我们需要在桌面上显示一个类似悬浮窗的东西，那么这种效果就需要用到Window来实现。Window是一个抽象类，它的具体实现是PhoneWindow。创建一个Window是很简单的事，只需要通过WindowManager即可完成。WindowManager是外界访问Window的入口，Window的具体实现位于WindowManagerService中，WindowManager和WindowManagerService的交互是一个IPC过程。Android中所有的视图都是通过Window来呈现的，不管是Activity,Dialog还是Toast，他们的视图实际上都是附加在Window上的，因此Window实际是View的直接管理者。View的事件分发机制也可以知道，单击事件由Window传递给DecorView，然后再由DecorView传递给我们的View，就连Activity的设置视图的方法setContentView在底层也是通过Window来完成的。
WindowManager.LayoutParams中的flags和type这两个参数比较重要。
Flags参数表示Window的属性，它有很多选项，通过这些选项可以控制Window的显示特性。
FLAG_NOT_FOCUSABLE:表示Window不需要获取焦点，也不需要接收各种输入事件。此标记会同时启用FLAG_NOT_TOUCH_MODAL最终事件会直接传递给下层的具有焦点的Window。
FLAG_NOT_TOUCH_MODAL:在此模式下，系统会将当前Window区域以外的单击事件传递给底层的Window，当前Window区域以内的单击事件则自己处理。这个标记很重要，一般来说都需要开启此标记，否则其他Window将无法接收到单击事件。
FLAG_SHOW_WHEN_LOCKED:开启此模式可以让Window显示在锁屏的界面上。
Type参数表示Window的类型，Window有三种类型，分别是应用Window，子Window和系统Window。应用类Window对应着一个Activity。子Window不能单独存在，它需要附属在特定的父Window之中，比如常见的一些Dialog就是一个子Window。系统Window是需要声明权限在能创建的Window，比如Toast和系统状态栏这些都是系统Window。
Window是分层的，每个Window都有对应的z-ordered,层级大的会覆盖在层级小的Window的上面，这和HTML中的z-index的概念是完全一致的。在三类Window中，应用Window的层级范围是1-99，子Window的层级范围是1000-1999，系统Window的层级范围是2000-2999，这些层级范围对应着WindowManager.LayoutParams的type参数。如果想要Window位于所有Window的最顶层，那么采用较大的层级即可。很显然系统Window的层级是最大的。因为系统类型的Window是需要检查权限的，如果不在AndroidManifest中使用相应的权限，那么创建Window的时候就会报错。
WindowManager所提供的功能很简单，常用的只有三个方法，即添加View，更新View和删除View，这三个方法定义在ViewManager中，而WindowManager继承了ViewManager。
对开发者来说，WindowManager常用的就只有这三个功能而已，但是这三个功能已经足够我们使用了。它可以创建一个Window并向其添加View，还可以更新Window中的View，另外如果想要删除一个Window，那么只需要删除它里面的View即可。WindowManager操作Window的过程更像是在操作Window中的View。常见的那种可以拖动的Window效果，其实是很好实现的，只需要根据手指的位置来设定LayoutParams中的x和y的值即可改变Window的位置。首先给View设置onTouchListener。mFloatingButton.setOnTouchListener(this)然后再onTouch方法中不断更新View的位置即可。
Window的内部机制
Window是一个抽象的概念，每一个Window都对应着一个View和一个ViewRootImpl，Window和View通过ViewRootImpl来建立联系，因此Window并不是实际存在的，它是以View的形式存在。这点从WindowManager的定义也可以看出，它提供的三个接口方法addView，updateViewLayout以及removeView都是针对View的，这说明View才是Window存在的实体。在实际使用中无法直接访问Window，对Window的访问必须通过WindowManager。
Window的添加过程
Window的添加过程需要通过WindowManager的addView来实现，WindowManager是一个接口，它的真正实现是WindowMangerImpl类。WindowManagerImpl并没有直接实现Window的三大操作，而是全部交给了WindowManagerGlobal来处理，WindowManagerGlobal以工厂的形式向外提供自己的实例，在在WindowManagerGlobal中有如下一段代码：private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance()。WindowManagerImp这种共工作模式是典型的桥接模式，将所有的操作全部委托给WindowManagerGlobal来实现。WindowManagerGlobal的addView方法主要分为以下几步：
1.检查参数是否合法，如果是子Window那么还需要调整一些布局参数
2.创建ViewRootImpl并将View添加到列表中：WindowManagerGlobal内部有几个列表比较重要，mViews存储的是所有Window所对应的View，mRoots存储的是所有Window所对应的ViewRootImpl,mParams存储的是所有Window所对应的布局参数，而mDyingViews则存储了那些正在被删除的View对象，或者说是那些已经调用removeView方法但是删除操作还未完成的Window对象。
3.通过ViewRootImpl来更新界面并完成Window的添加过程
Window的删除过程
Window的删除过程和添加过程一样，都是先通过WindowManagerImpl后，再进一步通过WindowManagerGlobal来实现的。
如果是异步删除，那么就返送一个MSG_DIE的消息，ViewRootImp中的Handler会处理此消息并调用doDie方法，如果是同步删除（立即删除）那么就不发消息直接调用doDie方法，这就是这两种删除方式的区别。在doDie内部会调用dispatchDetachedFromWindow方法，真正删除View的逻辑在dispathcDetachedFromWindow方法的内部实现，dispatchDeatachedFromWindow方法主要做四件事：
1.垃圾回收相关的工作，比如清除数据和消息，移除回调。
2.通过Session的remove方法删除Window：mWindowSession.remove(mWindow),这同样是一个IPC过程，最终会调用WindowManagerService的removeWindow方法。
3.调用View的dispathcDetachedFromWindow方法，在内部会调用View的onDetachedFromWindow（）以及onDetachedFromWindowInternal()。对于onDetachedFromWindow（）大家一定不陌生，当View从Window中移除时，这个方法就会被调用，可以在这个方法内部做一些资源回收的工作，比如终止动画，停止线程等。
4.调用WindowManagerGlobal的doRemoveView方法刷新数据，包括mRoots，mParams以及mDyingViews，需要将当前Window所关联的这三类对象从列表中删除。
Window的更新过程
updateViewLayout方法做的事情就比较简单了，首先它需要更新View的LayoutParams并替换掉老的LayoutParams，接着再更新ViewRootImpl中的LayoutParams这一步是通过ViewRootImpl的setLayoutParams方法来实现的。在ViewRootImpl中会通过scheduleTraversals方法来对View重新布局，包括测量，布局，重绘这三个过程，除了View本身的重绘以外，ViewRootImpl还会通过WindowSession来更新Window的视图，这个过程最终是由WindowManagerService的relayoutWindow()来具体实现的，同样是一个IPC过程。
Window的创建过程
View是Android中的视图的呈现方式，但是View不能单独存在，他必须附着在Window这个抽象的概念上面，因此有视图的地方就有Window。那些地方有视图呢？这个读者都比较清楚，Android中可以提供视图的地方有Activity,Dialog，Toast除此之外，还有一些依托Window而实现的视图，比如PopUpWindow，菜单，它们也是视图，有视图的地方就有Window,因此Activity,Dialog,Toast等视图都对应着一个Window。
Activity的Window创建过程
Actiity的启动过程很复杂，最终会由ActivityThread中的performLaunchActivity()来完成整个启动过程。在这个方法内部会通过类加载器创建Activity的实例对象，并调用其attach方法为其关联运行过程中所依赖的一系列上下文环境变量。
在Activity的attach方法里，系统会创建Activity所属的Window对象并为其设置回调接口，Window对象的创建是通过PolicyManager的makeNewWindow方法实现的。由于Activity实现了Window的Callback接口，因此当Window接收到外界的状态改变时就会回调Activity的方法。
Activity的Window是通过PolicyManager是一个工厂方法来创建的，PolicyManager是一个策略类，其中实现的几个工厂方法全部在策略接口Ipolicy中声明了。PolicyManager的真正实现是Policy类，Policy类中的makeNewWindow方法如下，可以发现Window的具体实现的确是PhoneWindow。
public Window makeNewWindow(Context context){
return new PhoneWindow(context);
}
Activity将具体实现交给了Window处理，而Window的具体实现是PhoneWindow，所以只需要看PhoneWindow的相关逻辑即可。PhoneWindow的setContentView方法如下几步：
1.如果没有DecorView，那么就创建它
DecorView是一个FrameLayout，DecorView是Acitivty中的顶级View，一般来说它的内部包含标题栏和内部栏，但是这个会随着主题的变换而发生改变。不管怎么样，内容栏是一定要存在的，并且内容栏具体固定的id，那就是“content”，它的完整id是android.R.id.content。DecorView的创建过程由installDecor方法来完成，在方法内部会通过generateDecor方法来直接创建DecorView，这个时候DecorView还知识一个空白的FrameLayout。
2.将View添加到DecorView的mContentParent中
3.回调Activity的onContentChanged方法通知Activity视图已经发生改变。
经过上面的三个步骤，到这里为止DecorView已经被创建并初始化完毕，Activity的布局文件也已经成功添加到了DecorView的mContentParent中，但是这个时候DecorView还没有被WindowManager正式添加到Window中。这里需要正确理解Window的概念，Window更多表示的是一种抽象的功能集合，虽然说早在Activity的attach方法中Window就已经被创建了，但是这个时候由于DecorView并没有被WindowManager识别，所以这个时候的Window无法提供具体功能，因为它还无法接受外界的输入信息。在AcitivityThread的handleResumeActivity方法中，首先会调用Activity的onResume方法，接着会调用Activity的makeVisible(),正是在makeVisible方法中，DecorView真正地完成了添加和显示这两个过程，到这里Activity的视图才能被用户看到。
Dialog的Window创建过程
Dialog的Window的创建过程和Activity类似，有如下几步
1.创建Window
Dialog的Window的创建同样是通过PolicyManager的makeNewWindow方法来完成的，创建后的对象实际上就是PhoneWindow，这个过程和Activity的Window的创建过程是一致的。
2.初始化DecorView并将Dialog的视图添加到DecorView中
3.将DecorView添加到Window中并显示
Dialog的Window创建和Activity的Window创建过程很类似，二者几乎没有什么区别。当Dialog被关闭时，它会通过WindowManager来移除DecorView：mWindowManager.removeViewImmediate(mDecor)。普通的Dialog有一个特殊之处，那就是必须采用Activity的Context，如果采用Application的Context，那么就会报错。
应用token一般只有Activity拥有，所以这里只需要用Activity作为Context来显示对话框即可。系统Window比较特殊，它可以不需要token。系统Window的层级有很多值，可以选用TYPE_SYSTEM_OVERLAY来指定对话框的Window类型为系统Window.不要忘记在AndroidManifest文件中声明权限从而可以使用系统Window.
Toast的Window创建过程
Toast和Dialog不同，它的工作过程稍显复杂，首先Toast也是基于Window来实现的，但是由于Toast具有定时取消这一功能，所以系统采用了Handler。在Toast的内部有两类IPC过程，第一类是Toast访问NotificationManagerService，第二类是NotificationManagerService回调Toast里的TN接口。
Toast属于系统Window，它内部的视图由两种方式指定，一种是系统默认的样式，另一种是通过setView方法来指定一个自定义View，不管如何，它们都对应Toast的一个View类型的内部成员mNextView。Toast提供了show和cancel分别用于显示和隐藏Toast，它们的内部是一个IPC过程。显示和隐藏Toast都需要通过NMS来实现，由于NMS运行在系统的进程中，所以只能通过远程调用的方式来显示和隐藏Toast。需要注意的是TN这个类，它是一个Binder类，在Toast和NMS进行IPC的过程中，当NMS处理Toast的显示或隐藏请求时会跨进程回调TN中的方法，这个时候由于TN运行在Binder线程池中，所以需要通过Handler将其切换到当前线程中。这里的当前线程是指发送Toast请求所在的线程，注意，由于这里使用了Handler，所以这意味着Toast无法在没有Looper的线程中弹出，这是因为Handler需要使用Looper才能完成切换线程的功能。
Toast的显示过程调用了NMS中的enqueueToast方法，NMS的enqueueToast方法的第一个参数表示当前应用的包名，第二个参数tn表示远程回调，第三个参数表示Toast的时长。enqueueToast首先将Toast请求封装为ToastRecord对象并将其添加到一个名为mToastQueue的队列中。mToastQueue其实是一个ArrayList。对于非系统应用来说，mToastQueue中最多能同时存在50个ToastRecord，这样做是为了防止DOS(Denial of Service)。如果不这么做，试想一下，如果我们通过大量的循环去连续弹出Toast，这将会导致其他应用没有机会弹出Toast，那么对于其他应用的Toast请求，系统的行为就是拒绝服务，这就是拒绝服务攻击的含义，这种手段常用于网络攻击中。
正常情况下，一个应用不可能达到上限，当ToastRecord被添加到mToastQueue中后，NMS就会通过showNextToastLocked方法来显示当前的Toast。Toast的显示是由ToastRecord的callback来完成的，这个callback实际上就是Toast中的TN对象的远程Binder，通过callback来访问TN中的方法是需要跨进程来完成的，最终被调用的TN中的方法会运行在发起Toast请求的应用的Binder线程池中。
Toast显示以后，NMS还会通过scheduleTimeoutLocked方法来发送一个延时消息，具体的延时取决于Toast的时长。LONG_DELAY是3.5s，SHORT_DELAY是2s。延迟相应的时间后，NMS会通过cancelToastLocked方法来隐藏Toast并将其从mToastQueue中移除，这个时候如果mToastQueue中还有其他Toast，那么NMS就继续显示其他Toast。
Toast的隐藏也是通过ToastRecord的callback来完成的，这同样也是一次IPC过程。Toast的显示和影响过程实际上是通过Toast中的TN这个类来实现的，它有两个方法show和hide，分别对应Toast的显示和隐藏。由于这两个方法是被NMS以跨进程的方式调用的，因此它们运行在Binder线程池中，为了将执行环境切换到Toast请求所在的线程，在它们的内部使用了Handler。
show和hide方法中的mShow和mHide是两个Runnable，它们内部分别调用了handleShow和handleHide方法。由此可见，handleShow和handleHide才是真正完成显示和隐藏Toast的地方。TN的handlerShow中会将Toast的视图添加到Window中。 而NT的handleHide中会将Toast的视图从Window中移除。到这里Toast的Window的创建过程已经分析完了。