Android 开发艺术探索笔记（17）

Window的删除过程
Window的删除过程和添加差不多，也是实现WindowManagerImpl后，进一步桥接WindowManagerGlobal来实现。下面是WindowManagerGlobal的removeView实现：

这个逻辑比较清晰，就是用findViewLocked去查找View的索引，然后通过removeViewLocked去删除这个View。这个方法里通过ViewRootImpl来进行删除。
在WindowManager中提供了两种删除接口removeView、removeViewImmediate，它们分别表示异步删除和同步删除。一般我们都用异步方法，具体的删除时用到ViewRootImpl的die方法来。在异步删除的情况下，die方法只是发送了一个请求删除的操作的消息后立刻返回，这个View并没有完成删除操作，所以会添加到mDyingViews中，mDyingViews表示待删除的View列表。然后在die里面呢，如果是异步，就用发送消息，handler处理并调用doDie方法，而同步不会发送消息直接调用doDie。在doDie内部会调用dispatchDetachedFromWindow方法，这是真正删除Window的逻辑。它主要做四件事：

• 垃圾回收的相关工作，比如清楚数据
• 调用onDeatchFromWindow方法，在这个方法里结束进程、终止动画等
• 通过Session的remove方法删除Winodow，最终会调用WindowManagerService的removeWindow方法，这是个IPC过程
  
  • 调用doRemoveView方法刷新数据。

Window更新
跟之前两个一样，也是看WindowManagerGlobal的updateViewLayout方法。
就是用新的View的LayoutParams替换老的，接着再去更新ViewRootImpl中的LayoutParams。通过ViewRootImpl中的ScheduleTraversals方法对View进行重布局，除了本身的重绘以外，还回去通过Session来更新Window视图，最终也是到了WindowManagerService中，同样是IPC过程。

Window的创建
一共分为三个部分，因为Window一共有三中： 应用类Window（Activity）、子Window和系统Window。详细过程比较复杂，这里先做大概的了解。

Activity的创建
首先要分析Activity的启动过程，Activity的启动过程很复杂，最终会由ActivityThread中的PerformLaunchActivity()来完成，在这个方法的内部会通过类加载器创建Activity的实例对象，并调用其attach方法为其关联运行过程中所依赖的一系列上下文环境变量。代码如下：

在Activity的attach方法里，系统会创建Activity所属的Window对象并为其回调接口，Window对象的创建是通过PolicyManager的makeNewWindow方法实现的。由于Activity实现了Window的Callback接口，因此当Window接收到外界的状态改变时就会回调Activity方法。Callback接口中方法就很多，但是有几个确实我们非常熟悉的，比如onAttachedToWindow、onDetachedFromWindow、dispatchTouchEvent等等。代码如下：

可以看出Activity的Window是通过PolicyManager的一个工厂方法来创建的，PolicyManager实现的工厂方法全部在策略接口IPolicy：

这里的makeNewWindow返回的是一个PhoneWindow对象。到这里Activity的创建就完成了。
接着就是分析Activity怎么显示在视图上的，我们通过setContentView来看，它里面就是调用了Window即刚刚PhoneWindow的方法，它的方法大概如下：

• 如果没有DecorView，则创建它
  DecorView是一个FrameLayout，是顶级的Layout，包含一个标题栏和内容栏。DecorView的创建由installDecor完成，在方法内部通过generateDecor方法来直接创建DecorView，这个时候DecorView还只是一个空白的FrameLayout。
  
  为了初始化DecorView结构，PhoneWindow还需要通过generateLayout来加载具体的布局到DecorView中，具体的布局文件和系统版本以及主题有关，这个过程如下：
  
• 将View添加到DecorView的mContentParent中
  直接将Activity视图添加到DecorView的mContentParent:mLayoutInflater.inflater(layoutResID,mContentParent)。到此为止，Activity的布局文件已经添加到DecorView中了，
• 回调onContentChanged方法通知Activity视图已改变
  Activity中的onContentChanged方法是一个空实现，可以在子Activity中处理这个回调。

这个时候已经将DecorView添加到mContentParent中了，但是还没有正式的被WindowManager添加到Window中，所以它还无法从外界接收信息。在ActivityThread的handleResumeActivity方法中，首先会调用Activity的onResume方法，接着会调用Activity的makeVisable(),正式在makeVisable中，DecorView才真正地完成了添加和显示这两个过程，到这里Activity才能被看到。

Dialog的创建
跟Activity的创建差不多，也是用PolicyManager返回的PhoneWindow来创建。
接着初始化DecorView并将Dialog添加到DecorView中。
最后将DecorView添加到Window中并显示。
当其关闭时通过WindowManager来移除DecorView：mWindowManager.removeViewImmediate(mDecor)
普通Dialog有一个特殊之处，那就是必须采用Activity的Context，如果采用Application的Context，那就会报错，是因为没有应用token，而token只有Activity才有，所以只需要Activity作为Context来显示对话框。而系统Window就比较特殊，它不用使用token，因此当你给dialog设置层级，让它的层级和系统Window一样，它就可以不用Activity作为Context来显示。

Toast的创建
Toast是基于Window实现的，但是它有定时取消这一功能，所以它用到了Handler。Toast内部有两类IPC过程，一类是Toast访问NotificationManagerService，第二类是NotificationManagerService（NMS）回调Toast里的TN接口。
Toast是系统Window，它内部的视图有两种方式指定，一种是系统默认的样式，另一种是通过setView方式来自定义一个View，不管如何，它们都对应Toast的一个View类型的内部成员mNextView。Toast提供了show和cancel分别用于显示和隐藏Toast。它们内部是一个IPC过程。代码如下：

无论显示还是隐藏都要用到NMS，由于NMS运行在系统中，所以只能通过远程调用来实现show和cancel方法。TN是一个Binder类，它申请之后，NMS会回调，这个时候TN是在线程池中的，所以需要通过Hnadler将其切换到当前线程中。因为这里使用了Handler，所以Toast无法再没有Looper的线程中弹出。
NMS的enqueueToast三个参数分别为当前包名，回调的TN，持续的时间。enqueueToast首先将Toast请求封装为ToastRecord对象并为其添加到一个名为mToastQueue队列中，然后排队处理。然后NMS会通过showNextToastRecord方法来显示当前的Toast，Toast就是通过Callback完成的。最终回调TN的方法将Toast显示。
显示Toast之后，NMS还会通过scheduleTimeoutLocked方法来发送一个延迟信息，延迟时间为Toast的显示时长：

延迟相应时间后，NMS会通过cancelToastLocked来隐藏Toast并将其从mToastQueue中移除，然后轮到下一个Toast处理。隐藏Toast也是一次IPC过程，和显示类似。