【凯子哥带你学Framework】Activity界面显示全解析

前几天凯子哥写的Framework层的解析文章《Activity启动过程全解析》，反响还不错，这说明“写让大家都能看懂的Framework解析文章”的思想是基本正确的。

我个人觉得，深入分析的文章必不可少，但是对于更多的Android开发者——即只想做应用层开发，不想了解底层实现细节——来说，“整体上把握，重要环节深入“是更好的学习方式。因为这样既可以有完整的知识体系，又不会在浩瀚的源码世界里迷失兴趣和方向。

所以呢，今天凯子哥又带来一篇文章，接着上一篇的结尾，重点介绍Activity开启之后，Android系统对界面的一些操作及相关知识。

本期关键字

• Window
• PhoneWindow
• WindowManager
• WindowManagerImpl
• WindowManagerGlobal
• RootViewImpl
• DecorView
• Dialog
• PopWindow
• Toast

学习目标

• 了解Android中Activity界面显示的流程，涉及到的关键类，以及关键流程
• 解决在开发中经常遇到的问题，并在源码的角度弄清楚其原因
• 了解Framework层与Window相关的一些概念和细节

写作方式

老样子，咱们还是和上次一样，采用一问一答的方式进行学习，毕竟“带着问题学习”才是比较高效的学习方式。

进入正题

话说，在上次的文章中，我们解析到了从手机开机第一个zygote进程开启，到App的第一个Activity的onCreate()结束，那么我们这里就接着上次留下的茬，从第一个Activity的onCreate()开始说起。

onCreate()中的setContentView()到底做了什么？为什么不能在setContentView()之后设置某些Window属性标志？

一个最简单的onCreate()如下：

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}

通过上面几行简单的代码，我们的App就可以显示在activity_main.xml文件中设计的界面了，那么这一切到底是怎么做到的呢？

我们跟踪一下源码，然后就在Activity的源码中找到了3个setContentView()的重载函数：

public void setContentView(int layoutResID) {
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
} public void setContentView(View view) {
getWindow().setContentView(view);
initWindowDecorActionBar();
} public void setContentView(View view, ViewGroup.LayoutParams params) {
getWindow().setContentView(view, params);
initWindowDecorActionBar();
}


我们上面用到的就是第一个方法。虽然setContentView()的重载函数有3种，但是我们可以发现，内部做的事情都是基本一样的。首先是调用getWindow()获取到一个对象，然后调用了这个对象的相关方法。

咱们先来看一下，getWindow()到底获取到了什么对象。

private Window mWindow;public Window getWindow() {
return mWindow;
}

喔，原来是一个Window对象，你现在可能不知道Window到底是个什么玩意，但是没关系，你只要能猜到它肯定和咱们的界面显示有关系就得了，毕竟叫“Window”么，Windows系统的桌面不是叫“Windows”桌面么，差不多的东西，反正是用来显示界面的就得了。

那么initWindowDecorActionBar()函数是做什么的呢？

写了这么多程序，看名字也应该能猜出八九不离十了，init是初始化，Window是窗口，Decor是装饰，ActionBar就更不用说了，所以这个方法应该就是”初始化装饰在窗口上的ActionBar”，来，咱们看一下代码实现：

/**
* Creates a new ActionBar, locates the inflated ActionBarView,
* initializes the ActionBar with the view, and sets mActionBar.
*/
private void initWindowDecorActionBar() {
Window window = getWindow(); // Initializing the window decor can change window feature flags.
// Make sure that we have the correct set before performing the test below.
window.getDecorView(); if (isChild() || !window.hasFeature(Window.FEATURE_ACTION_BAR) || mActionBar != null) {
return;
} mActionBar = new WindowDecorActionBar(this);
mActionBar.setDefaultDisplayHomeAsUpEnabled(mEnableDefaultActionBarUp); mWindow.setDefaultIcon(mActivityInfo.getIconResource());
mWindow.setDefaultLogo(mActivityInfo.getLogoResource());
}

哟，没想到这里第一行代码就又调用了getWindow()，接着往下调用了window.getDecorView()，从注释中我们知道，在调用这个方法之后，Window的特征标志就被初始化了，还记得如何让Activity全屏吗？

@Override public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState); requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(WindowManager.LayoutParams.FILL_PARENT, WindowManager.LayoutParams.FILL_PARENT); setContentView(R.layout.activity_main);
}

而且这两行代码必须在setContentView()之前调用，知道为啥了吧？因为在这里就把Window的相关特征标志给初始化了，在setContentView()之后调用就不起作用了！

如果你还不确定的话，我们可以再看下window.getDecorView()的部分注释

/**
* Note that calling this function for the first time "locks in"
* various window characteristics as described in
* {@link #setContentView(View, android.view.ViewGroup.LayoutParams)}
*/
public abstract View getDecorView();

“注意，这个方法第一次调用的时候，会锁定在setContentView(）中描述的各种Window特征” 
所以说，这也同样解释了为什么在setContentView()之后设置Window的一些特征标志，会不起作用。如果以后遇到类似问题，可以往这方面想一下。

Activity中的findViewById()本质上是在做什么？

在上一个问题里面，咱们提到了一个很重要的类——Window，下面先简单看一下这个类的几个方法：

public abstract class Window { public abstract void setContentView(int layoutResID); public abstract void setContentView(View view); public abstract void setContentView(View view, ViewGroup.LayoutParams params); public View findViewById(int id) {
return getDecorView().findViewById(id);
}
}

哇塞，有个好眼熟的方法，findViewById()！

是的，你每次在Activity中用的这个方法，其实间接调用了Window类里面的方法！

public View findViewById(int id) {
return getWindow().findViewById(id);
}

不过，findViewById()的最终实现是在View及其子类里面的，所以getDecorView()获取到的肯定是一个View对象或者是View的子类对象：

public abstract View getDecorView();

Activity、Window中的findViewById()最终调用的，其实是View的findViewById()。

public class View implements Drawable.Callback, KeyEvent.Callback,
AccessibilityEventSource { public final View findViewById(int id) {
if (id < 0) {
return null;
}
return findViewTraversal(id);
} protected View findViewTraversal(int id) {
if (id == mID) {
return this;
}
return null;
}
}

但是，很显然，最终调用的肯定不是View类里面的findViewTraversal()，因为这个方法只会返回自身。 
而且，findViewById()是final修饰的，不可被重写，所以说，肯定是调用的被子类重写的findViewTraversal()，再联想到，我们的界面上有很多的View，那么既能作为View的容器，又是View的子类的类是什么呢？很显然，是ViewGroup！

public abstract class ViewGroup extends View implements ViewParent, ViewManager { @Override
protected View findViewTraversal(int id) {
if (id == mID) {
return this;
} final View[] where = mChildren;
final int len = mChildrenCount; for (int i = 0; i < len; i++) {
View v = where[i]; if ((v.mPrivateFlags & PFLAG_IS_ROOT_NAMESPACE) == 0) {
v = v.findViewById(id); if (v != null) {
return v;
}
}
} return null;
}
}

所以说，在onCreate()中调用findViewById()对控件进行绑定的操作，实质上是通过在某个View中查找子View实现的，这里你先记住，这个View叫做DecorView，而且它位于用户窗口的最下面一层。

Window和PhoneWindow是什么关系？WindowManager是做什么的？

话说，咱们前面介绍Window的时候，只是简单的介绍了下findViewById()，还没有详细的介绍下这个类，下面咱们一起学习一下。

前面提到过，Window是一个抽象类，抽象类肯定是不能实例化的，所以咱们需要使用的是它的实现类，Window的实现类有哪些呢？咱们从Dash中看下Window类的文档

Window只有一个实现类，就是PhoneWindow！所以说这里扯出了PhoneWindow这个类。

而且文档还说，这个类的一个实例，也就是PhoneWindow，应该被添加到Window Manager中，作为顶层的View，所以，这里又扯出了一个WindowManager的概念。

除此之外，还说这个类提供了标准的UI策略，比如背景，标题区域，和默认的按键处理等等，所以说，咱们还知道了Window和PhoneWindow这两个类的作用！

所以说，看文档多重要呀！

OK，现在咱们已经知道了Window和唯一的实现类PhoneWindow，以及他们的作用。而且我们还知道了WindowManager，虽然不知道干嘛的，但是从名字也可以猜出是管理Window的，而且还会把Window添加到里面去，在下面的模块中，我会详细的介绍WindowManager这个类。

Activity中，Window类型的成员变量mWindow是什么时候初始化的？

在每个Activity中都有一个Window类型的对象mWindow，那么是什么时候初始化的呢？

是在attach()的时候。

还记得attach()是什么时候调用的吗？是在ActivityThread.performLaunchActivity()的时候：

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) { Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
} catch (Exception e) {
...ignore some code...
} try { ...ignore some code... activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.voiceInteractor); ...ignore some code... } catch (Exception e) { } return activity;
}

在attach()里面做了些什么呢？

public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, KeyEvent.Callback,
OnCreateContextMenuListener, ComponentCallbacks2,
Window.OnWindowDismissedCallback { private Window mWindow; final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, IVoiceInteractor voiceInteractor) { ...ignore some code... //就是在这里实例化了Window对象
mWindow = PolicyManager.makeNewWindow(this);
//设置各种回调
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
mWindow.getLayoutInflater().setPrivateFactory(this); //这就是传说中的UI线程，也就是ActivityThread所在的，开启了消息循环机制的线程，所以在Actiivty所在线程中使用Handler不需要使用Loop开启消息循环。
mUiThread = Thread.currentThread(); ...ignore some code... //终于见到了前面提到的WindowManager，可以看到，WindowManager属于一种系统服务
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()是Activity实例化之后，调用的第一个函数，在这个时候，就实例化了Window。那么这个PolicyManager是什么玩意？

mWindow = PolicyManager.makeNewWindow(this);

来来来，咱们一起RTFSC(Read The Fucking Source Code)！

public final class PolicyManager {
private static final String POLICY_IMPL_CLASS_NAME =
"com.android.internal.policy.impl.Policy"; private static final IPolicy sPolicy;
static {
// Pull in the actual implementation of the policy at run-time
try {
Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME);
sPolicy = (IPolicy)policyClass.newInstance();
} catch (ClassNotFoundException ex) {
throw new RuntimeException(
POLICY_IMPL_CLASS_NAME + " could not be loaded", ex);
} catch (InstantiationException ex) {
throw new RuntimeException(
POLICY_IMPL_CLASS_NAME + " could not be instantiated", ex);
} catch (IllegalAccessException ex) {
throw new RuntimeException(
POLICY_IMPL_CLASS_NAME + " could not be instantiated", ex);
}
} private PolicyManager() {} public static Window makeNewWindow(Context context) {
return sPolicy.makeNewWindow(context);
} }

“Policy”是“策略”的意思，所以就是一个策略管理器，采用了策略设计模式。而sPolicy是一个IPolicy类型，IPolicy实际上是一个接口

public interface IPolicy {}


所以说，sPolicy的实际类型是在静态代码块里面，利用反射进行实例化的Policy类型。静态代码块中的代码在类文件加载进类加载器之后就会执行，sPolicy就实现了实例化。

那我们看下在Policy里面实际上是做了什么

public class Policy implements IPolicy { //看见PhoneWindow眼熟么？还有DecorView，眼熟么？这就是前面所说的那个位于最下面的View，findViewById()就是在它里面找的
private static final String[] preload_classes = {
"com.android.internal.policy.impl.PhoneLayoutInflater",
"com.android.internal.policy.impl.PhoneWindow",
"com.android.internal.policy.impl.PhoneWindow$1",
"com.android.internal.policy.impl.PhoneWindow$DialogMenuCallback",
"com.android.internal.policy.impl.PhoneWindow$DecorView",
"com.android.internal.policy.impl.PhoneWindow$PanelFeatureState",
"com.android.internal.policy.impl.PhoneWindow$PanelFeatureState$SavedState",
}; //由于性能方面的原因，在当前Policy类加载的时候，会预加载一些特定的类
static {
for (String s : preload_classes) {
try {
Class.forName(s);
} catch (ClassNotFoundException ex) {
Log.e(TAG, "Could not preload class for phone policy: " + s);
}
}
} //终于找到PhoneWindow了，我没骗你吧，前面咱们所说的Window终于可以换成PhoneWindow了~
public Window makeNewWindow(Context context) {
return new PhoneWindow(context);
}}

PhoneWindow.setContentView()到底发生了什么？

上面说了这么多，实际上只是追踪到了PhoneWindow.setContentView()，下面看一下到底在这里执行了什么：

@Override
public void setContentView(int layoutResID) {
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);
}
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
cb.onContentChanged();
}
} @Override
public void setContentView(View view) {
setContentView(view, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
} @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);
}
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
cb.onContentChanged();
}
}

当我们第一次调用serContentView()的时候，mContentParent是没有进行过初始化的，所以会调用installDecor()。

为什么能确定mContentParent是没有初始化的呢？因为mContentParent就是在installDecor()里面赋值的

private void installDecor() { if (mDecor == null) {
mDecor = generateDecor();
...
} if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
}}

在generateDecor()做了什么？返回了一个DecorView对象。

protected DecorView generateDecor() {
return new DecorView(getContext(), -1);
}

还记得前面推断出的，DecorView是一个ViewGroup的结论吗？看下面，DecorView继承自FrameLayout，所以咱们的推论是完全正确的。而且DecorView是PhoneWindow的私有内部类，这两个类关系紧密！

public class PhoneWindow extends Window implements MenuBuilder.Callback {
private final class DecorView extends FrameLayout implements RootViewSurfaceTaker {}
}

咱们再看一下在对mContentParent赋值的generateLayout(mDecor)做了什么

protected ViewGroup generateLayout(DecorView decor) { ...判断并设置了一堆的标志位... //这个是我们的界面将要采用的基础布局xml文件的id
int layoutResource; //根据标志位，给layoutResource赋值
if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
layoutResource = R.layout.screen_swipe_dismiss;
} ...我们设置不同的主题以及样式，会采用不同的布局文件... else {
//我们在下面代码验证的时候，就会用到这个布局，记住它哦
layoutResource = R.layout.screen_simple;
} //要开始更改mDecor啦~
mDecor.startChanging();
//将xml文件解析成View对象，至于LayoutInflater是如何将xml解析成View的，咱们后面再说
View in = mLayoutInflater.inflate(layoutResource, null);
//decor和mDecor实际上是同一个对象，一个是形参，一个是成员变量
decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
mContentRoot = (ViewGroup) in;
//这里的常量ID_ANDROID_CONTENT就是 public static final int ID_ANDROID_CONTENT = com.android.internal.R.id.content;
//而且，由于是直接执行的findViewById()，所以本质上还是调用的mDecor.findViewById()。而在上面的decor.addView()执行之前，decor里面是空白的，所以我们可以断定，layoutResource所指向的xml布局文件内部，一定存在一个叫做“content”的ViewGroup
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
if (contentParent == null) {
throw new RuntimeException("Window couldn't find content container view");
} ...... mDecor.finishChanging();
//最后把id为content的一个ViewGroup返回了
return contentParent;
}

当上的代码执行之后，mDecor和mContentParent就初始化了，往下就会执行下面的代码，利用LayoutInflater把咱们传进来的layoutResID转化成View对象，然后添加到id为content的mContentParent中

mLayoutInflater.inflate(layoutResID, mContentParent);

所以到目前为止，咱们已经知道了以下几个事实，咱们总结一下：

• DecorView是PhoneWindow的内部类，继承自FrameLayout，是最底层的界面
• PhoneWindow是Window的唯一子类，他们的作用就是提供标准UI，标题，背景和按键操作
• 在DecorView中会根据用户选择的不同标志，选择不同的xml文件，并且这些布局会被添加到DecorView中
• 在DecorView中，一定存在一个叫做“content”的ViewGroup，而且我们在xml文件中声明的布局文件，会被添加进去

既然是事实，那么怎么才能验证一下呢？

如何验证上一个问题

首先，说明一下运行条件：

//主题
name="AppTheme" parent="@android:style/Theme.Holo.Light.NoActionBar"//编译版本
android {
compileSdkVersion 19
buildToolsVersion '19.1.0' defaultConfig {
applicationId "com.socks.uitestapp"
minSdkVersion 15
targetSdkVersion 19
versionCode 1
versionName "1.0"
}
}dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:19.1.0'
}//Activity代码
public class MainActivity extends Activity { @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
}//activity_main.xml
<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:gravity="center"
android:text="Hello World!"
android:textSize="20sp" />

OK，咱们的软件已经准备好了，采用的是最简单的布局，界面效果如下：

下面用Hierarchy看一下树状结构：

第一层，就是上面的DecorView，里面有一个线性布局，上面的是ViewStub，下面就是id为content的ViewGroup，是一个FrameLayout。而我们通过setContentView()设置的布局，就是TextView了。

能不能在源码里面找到源文件呢？当然可以，这个布局就是screen_simple.xml

frameworks/base/core/res/res/layout/screen_simple.xml

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fitsSystemWindows="true"
android:orientation="vertical">
<ViewStub android:id="@+id/action_mode_bar_stub"
android:inflatedId="@+id/action_mode_bar"
android:layout="@layout/action_mode_bar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:theme="?attr/actionBarTheme" />
<FrameLayout
android:id="@android:id/content"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:foregroundInsidePadding="false"
android:foregroundGravity="fill_horizontal|top"
android:foreground="?android:attr/windowContentOverlay" />
</LinearLayout>

所以，即使你不调用setContentView()，在一个空Activity上面，也是有布局的。而且肯定有一个DecorView，一个id为content的FrameLayout。

你可以采用下面的方式获取到DecorView，但是你不能获取到一个DecorView实例，只能获取到ViewGroup。

下面贴上这个图，你就可以看明白了(转自 工匠若水)

ViewGroup view = (ViewGroup) getWindow().getDecorView();

• 1

我们通过setContentView()设置的界面，为什么在onResume()之后才对用户可见呢？

有开发经验的朋友应该知道，我们的界面元素在onResume()之后才对用户是可见的，这是为啥呢？

那我们就追踪一下，onResume()是什么时候调用的，然后看看做了什么操作就Ok了。

这一下，我们又要从ActivityThread开始说起了，不熟悉的快去看前一篇文章《Activity启动过程全解析》](http://blog.csdn.net/zhaokaiqiang1992/article/details/49428287)。

话说，前文说到，我们想要开启一个Activity的时候，ActivityThread的handleLaunchActivity()会在Handler中被调用

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) { //就是在这里调用了Activity.attach()呀，接着调用了Activity.onCreate()和Activity.onStart()生命周期，但是由于只是初始化了mDecor，添加了布局文件，还没有把
//mDecor添加到负责UI显示的PhoneWindow中，所以这时候对用户来说，是不可见的
Activity a = performLaunchActivity(r, customIntent); ...... if (a != null) {
//这里面执行了Activity.onResume()
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed); if (!r.activity.mFinished && r.startsNotResumed) {
try {
r.activity.mCalled = false;
//执行Activity.onPause()
mInstrumentation.callActivityOnPause(r.activity);
}
}
}
}

所以说，ActivityThread.handleLaunchActivity执行完之后，Activity的生命周期已经执行了4个(onCreate、onStart()、onResume、onPause())。

下面咱们重点看下handleResumeActivity()做了什么

final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume) { //这个时候，Activity.onResume()已经调用了，但是现在界面还是不可见的
ActivityClientRecord r = performResumeActivity(token, clearHide); if (r != null) {
final Activity a = r.activity;
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
//decor对用户不可见
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
//这里记住这个WindowManager.LayoutParams的type为TYPE_BASE_APPLICATION，后面介绍Window的时候会见到
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION; if (a.mVisibleFromClient) {
a.mWindowAdded = true;
//终于被添加进WindowManager了，但是这个时候，还是不可见的
wm.addView(decor, l);
} if (!r.activity.mFinished && willBeVisible
&& r.activity.mDecor != null && !r.hideForNow) {
//在这里，执行了重要的操作！
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
}
}

从上面的分析中我们知道，其实在onResume()执行之后，界面还是不可见的，当我们执行了Activity.makeVisible()方法之后，界面才对我们是可见的


if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE);


OK，其实讲到了这里，关于Activity中的界面显示应该算是告一段落了，我们知道了Activity的生命周期方法的调用时机，还知道了一个最简单的Activity的界面的构成，并了解了Window、PhoneWindow、DecorView、WindowManager的存在。

但是我还是感觉不过瘾，因为上面只是在流程上大体上过了一遍，对于Window、WindowManager的深入了解还不够，所以下面就开始讲解Window、WindowManager等相关类的稍微高级点的知识。

前面看累了的朋友，可以上个厕所，泡个咖啡，休息下继续往下看。

ViewManager、WindowManager、WindowManagerImpl、WindowManagerGlobal到底都是些什么玩意？

WindowManager其实是一个接口，和Window一样，起作用的是它的实现类

public interface WindowManager extends ViewManager { //对这个异常熟悉么？当你往已经销毁的Activity中添加Dialog的时候，就会抛这个异常
public static class BadTokenException extends RuntimeException {
public BadTokenException() {
} public BadTokenException(String name) {
super(name);
}
} //其实WindowManager里面80%的代码是用来描述这个内部静态类的
public static class LayoutParams extends ViewGroup.LayoutParams
implements Parcelable {
}
}

WindowManager继承自ViewManager这个接口，从注释和方法我们可以知道，这个就是用来描述可以对Activity中的子View进行添加和移除能力的接口。

/** Interface to let you add and remove child views to an Activity. To get an instance
* of this class, call {@link android.content.Context#getSystemService(java.lang.String) Context.getSystemService()}.
*/
public interface ViewManager
{
public void addView(View view, ViewGroup.LayoutParams params);
public void updateViewLayout(View view, ViewGroup.LayoutParams params);
public void removeView(View view);
}

那么我们在使用WindowManager的时候，到底是在使用哪个类呢？

是WindowManagerImpl。

public final class WindowManagerImpl implements WindowManager {}

• 1

怎么知道的呢？那我们还要从Activity.attach()说起

话说，在attach()里面完成了mWindowManager的初始化

final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, IVoiceInteractor voiceInteractor) { mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0); mWindowManager = mWindow.getWindowManager(); }

那我们只好看下(WindowManager)context.getSystemService(Context.WINDOW_SERVICE)是什么玩意了。

这里要说明的是，context是一个ContextImpl对象，这里先记住就好，以后再细说。

class ContextImpl extends Context { //静态代码块，完成各种系统服务的注册
static { ...... registerService(WINDOW_SERVICE, new ServiceFetcher() {
Display mDefaultDisplay;
public Object getService(ContextImpl ctx) {
Display display = ctx.mDisplay;
if (display == null) {
if (mDefaultDisplay == null) {
DisplayManager dm = (DisplayManager)ctx.getOuterContext().
getSystemService(Context.DISPLAY_SERVICE);
mDefaultDisplay = dm.getDisplay(Display.DEFAULT_DISPLAY);
}
display = mDefaultDisplay;
}
//没骗你吧
return new WindowManagerImpl(display);
}});
......
}@Override
public Object getSystemService(String name) {
ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
return fetcher == null ? null : fetcher.getService(this);
}
}

要注意的是，这里返回的WindowManagerImpl对象，最终并不是和我们的Window关联的，而且这个方法是有可能返回null的，所以在Window.setWindowManager()的时候，进行了处理

public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
boolean hardwareAccelerated) {
mAppToken = appToken;
mAppName = appName;
mHardwareAccelerated = hardwareAccelerated
|| SystemProperties.getBoolean(PROPERTY_HARDWARE_UI, false);
//重试一遍
if (wm == null) {
wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
}
//设置parentWindow，创建真正关联的WindowManagerImpl对象
mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
} public final class WindowManagerImpl implements WindowManager { //最终调用的这个构造
private WindowManagerImpl(Display display, Window parentWindow) {
mDisplay = display;
mParentWindow = parentWindow;
} public WindowManagerImpl createLocalWindowManager(Window parentWindow) {
return new WindowManagerImpl(mDisplay, parentWindow);
}
}


所以说，每一个Activity都有一个PhoneWindow成员变量，并且也都有一个WindowManagerImpl，而且，PhoneWindow和WindowManagerImpl在Activity.attach()的时候进行了关联。

插一张类图（转自工匠若水）

知道了这些，那下面的操作就可以直接看WindowManagerImpl了。

其实WindowManagerImpl这个类也没有什么看头，为啥这么说呢？因为他其实是代理模式中的代理。是谁的代理呢？是WindowManagerGlobal。

public final class WindowManagerImpl implements WindowManager {
private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();
private final Display mDisplay;
private final Window mParentWindow; @Override
public void addView(View view, ViewGroup.LayoutParams params) {
mGlobal.addView(view, params, mDisplay, mParentWindow);
} @Override
public void updateViewLayout(View view, ViewGroup.LayoutParams params) {
mGlobal.updateViewLayout(view, params);
} @Override
public void removeView(View view) {
mGlobal.removeView(view, false);
} @Override
public void removeViewImmediate(View view) {
mGlobal.removeView(view, true);
}}


从上面的代码中可以看出来，WindowManagerImpl里面对ViewManager接口内方法的实现，都是通过代理WindowManagerGlobal的方法实现的，所以重点转移到了WindowManagerGlobal这个类。

还记得前面我们的DecorView被添加到了WindowManager吗？

wm.addView(decor, l);

• 1

其实最终调用的是WindowManagerGlobal.addView();

public final class WindowManagerGlobal { private static IWindowManager sWindowManagerService;
private static IWindowSession sWindowSession; private final ArrayList<View> mViews = new ArrayList<View>();
private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
private final ArrayList<WindowManager.LayoutParams> mParams =
new ArrayList<WindowManager.LayoutParams>(); //WindowManagerGlobal是单例模式
private static WindowManagerGlobal sDefaultWindowManager; public static WindowManagerGlobal getInstance() {
synchronized (WindowManagerGlobal.class) {
if (sDefaultWindowManager == null) {
sDefaultWindowManager = new WindowManagerGlobal();
}
return sDefaultWindowManager;
}
} public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) { final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams)params;
......
synchronized (mLock) { ViewRootImpl root; root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams); mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
}
...... try {
//注意下这个方法，因为下面介绍ViewRootImpl的时候会用到
root.setView(view, wparams, panelParentView);
}catch (RuntimeException e) {
} }
}

我们看到，WindowManagerGlobal是单例模式，所以在一个App里面只会有一个WindowManagerGlobal实例。在WindowManagerGlobal里面维护了三个集合，分别存放添加进来的View（实际上就是DecorView），布局参数params，和刚刚实例化的ViewRootImpl对象，WindowManagerGlobal到底干嘛的呢？

其实，WindowManagerGlobal是和WindowManagerService(即WMS)通信的。

还记得在上一篇文章中我们介绍ActivityThread和AMS之间的IBinder通信的吗？是的，这里也是IBinder通信。


public static IWindowSession getWindowSession() {
synchronized (WindowManagerGlobal.class) {
if (sWindowSession == null) {
try {
InputMethodManager imm = InputMethodManager.getInstance();
IWindowManager windowManager = getWindowManagerService();
sWindowSession = windowManager.openSession( ...... } catch (RemoteException e) {
Log.e(TAG, "Failed to open window session", e);
}
}
return sWindowSession;
}
} public static IWindowManager getWindowManagerService() {
synchronized (WindowManagerGlobal.class) {
if (sWindowManagerService == null) {
//ServiceManager是用来管理系统服务的，比如AMS、WMS等，这里就获取到了WMS的客户端代理对象
sWindowManagerService = IWindowManager.Stub.asInterface(
ServiceManager.getService("window"));
}
return sWindowManagerService;
}
}

首先通过上面的方法获取到IBinder对象，然后转化成了WMS在本地的代理对象IWindowManager，然后通过openSession()初始化了sWindowSession对象。这个对象是干什么的呢？

“Session“是会话的意思，这个类就是为了实现与WMS的会话的，谁和WMS的对话呢？WindowManagerGlobal类内部并没有用这个类呀！

是ViewRootImpl与WMS的对话。

ViewRootImpl是什么？有什么作用？ViewRootImpl如何与WMS通信

你还记得么？在前面将WindowManagerGlobal.addView()的时候，实例化了一个ViewRootImpl，然后添加到了一个集合里面，咱们先看下ViewRootImpl的构造函数吧

public final class ViewRootImpl implements ViewParent,
View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks { public ViewRootImpl(Context context, Display display) { mContext = context;
//获取WindowSession
mWindowSession = WindowManagerGlobal.getWindowSession();
mDisplay = display; ...... mWindow = new W(this);
//默认不可见
mViewVisibility = View.GONE;
//这个数值就是屏幕宽度的dp总数
mDensity = context.getResources().getDisplayMetrics().densityDpi;
mChoreographer = Choreographer.getInstance();
mDisplayManager = (DisplayManager)context.getSystemService(Context.DISPLAY_SERVICE);
}}


在这个构造方法里面，主要是完成了各种参数的初始化，并且最关键的，获取到了前面介绍的WindowSession，那么你可能好奇了，这个ViewRootImpl到底有什么作用呢？

ViewRootImpl负责管理视图树和与WMS交互，与WMS交互是通过WindowSession。而且ViewRootImpl也负责UI界面的布局与渲染，负责把一些事件分发至Activity，以便Activity可以截获事件。大多数情况下，它管理Activity顶层视图DecorView，它相当于MVC模型中的Controller。

WindowSession是ViewRootImpl获取之后，主动和WMS通信的，但是我们在前面的文章知道，客户端和服务器需要互相持有对方的代理引用，才能实现双向通信，那么WMS是怎么得到ViewRootImpl的通信代理的呢？

是在ViewRootImpl.setView()的时候。

还记得不？在上面介绍WindowManagerGlobal.addView()的时候，我还重点说了下，在这个方法的try代码块中，调用了ViewRootImpl.setView()，下面咱们看下这个方法干嘛了：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) { if (mView == null) {
mView = view;
int res;
requestLayout(); try {
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(),
mAttachInfo.mContentInsets, mInputChannel);
}catch (RemoteException e) {
throw new RuntimeException("Adding window failed", e);
} finally { }
}
}
}

为了突出重点，我简化了很多代码，从上面可以看出来，是mWindowSession.addToDisplay()这个方法把mWindow传递给我WMS，WMS就持有了当前ViewRootlmpl的代理，就可以调用W对象让ViewRootlmpl做一些事情了。

这样，双方都有了对方的接口，WMS::Session注册到WindowManagerGlobal的成员WindowSession中，ViewRootImpl::W注册到WindowState中的成员mClient中。前者是为了App改变View结构时请求WMS为其更新布局。后者代表了App端的一个添加到WMS中的View，每一个像这样通过WindowManager接口中addView()添加的窗口都有一个对应的ViewRootImpl，也有一个相应的ViewRootImpl::W。它可以理解为是ViewRootImpl中暴露给WMS的接口，这样WMS可以通过这个接口和App端通信。

另外源码中很多地方采用了这种将接口隐藏为内部类的方式，这样可以实现六大设计原则之一——接口最小原则。

从什么时候开始绘制整个Activity的View树的？

注意前面代码中的requestLayout();因为这个方法执行之后，我们的ViewRootImpl才开始绘制整个View树！

@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true; scheduleTraversals();
}
}

void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
//暂停UI线程消息队列对同步消息的处理
mTraversalBarrier = mHandler.getLooper().postSyncBarrier();
//向Choreographer注册一个类型为CALLBACK_TRAVERSAL的回调，用于处理UI绘制
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
}
}

“Choreographer就是一个消息处理器,根据vsync 信号 来计算frame“

解释起来比较麻烦，我们暂时不展开讨论，你只要知道，当回调被触发之后，mTraversalRunnable对象的run()就会被调用

final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}

doTraversal()中最关键的，就是调用了performTraversals()，然后就开始mesure,layout,draw了，这里面的具体逻辑本篇文章不讲，因为重点是Activity的界面显示流程，这一块属于View的，找时间单独拿出来说

void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().removeSyncBarrier(mTraversalBarrier); if (mProfile) {
Debug.startMethodTracing("ViewAncestor");
} Trace.traceBegin(Trace.TRACE_TAG_VIEW, "performTraversals");
try {
performTraversals();
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
} if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}

来回倒腾了这么多，终于看见界面了，让我哭会 T^T

Window的类型有几种？分别在什么情况下会使用到哪一种？

Window的类型是根据WindowManager.LayoutParams的type属性相关的，根据类型可以分为三类：

• 取值在FIRST_APPLICATION_WINDOW与LAST_APPLICATION_WINDOW之间(1-99)，是常用的顶层应用程序窗口，须将token设置成Activity的token，比如前面开启Window的时候设置的类型即为TYPE_APPLICATION
• 在FIRST_SUB_WINDOW和LAST_SUB_WINDOW(1000-1999)之间，与顶层窗口相关联，需将token设置成它所附着宿主窗口的token，比如PopupWindow就是TYPE_APPLICATION_PANEL
• 取值在FIRST_SYSTEM_WINDOW和LAST_SYSTEM_WINDOW(2000-2999)之间，不能用于应用程序，使用时需要有特殊权限，它是特定的系统功能才能使用，比如Toast就是TYPE_TOAST=2005，所以不需要特殊权限

下面是所有的Type说明

//WindowType：开始应用程序窗口
public static final int FIRST_APPLICATION_WINDOW = 1;
//WindowType：所有程序窗口的base窗口，其他应用程序窗口都显示在它上面
public static final int TYPE_BASE_APPLICATION = 1;
//WindowType：普通应用程序窗口，token必须设置为Activity的token来指定窗口属于谁
public static final int TYPE_APPLICATION = 2;
//WindowType：应用程序启动时所显示的窗口，应用自己不要使用这种类型，它被系统用来显示一些信息，直到应用程序可以开启自己的窗口为止
public static final int TYPE_APPLICATION_STARTING = 3;
//WindowType：结束应用程序窗口
public static final int LAST_APPLICATION_WINDOW = 99; //WindowType：SubWindows子窗口，子窗口的Z序和坐标空间都依赖于他们的宿主窗口
public static final int FIRST_SUB_WINDOW = 1000;
//WindowType： 面板窗口，显示于宿主窗口的上层
public static final int TYPE_APPLICATION_PANEL = FIRST_SUB_WINDOW;
//WindowType：媒体窗口（例如视频），显示于宿主窗口下层
public static final int TYPE_APPLICATION_MEDIA = FIRST_SUB_WINDOW+1;
//WindowType：应用程序窗口的子面板，显示于所有面板窗口的上层
public static final int TYPE_APPLICATION_SUB_PANEL = FIRST_SUB_WINDOW+2;
//WindowType：对话框，类似于面板窗口，绘制类似于顶层窗口，而不是宿主的子窗口
public static final int TYPE_APPLICATION_ATTACHED_DIALOG = FIRST_SUB_WINDOW+3;
//WindowType：媒体信息，显示在媒体层和程序窗口之间，需要实现半透明效果
public static final int TYPE_APPLICATION_MEDIA_OVERLAY = FIRST_SUB_WINDOW+4;
//WindowType：子窗口结束
public static final int LAST_SUB_WINDOW = 1999; //WindowType：系统窗口，非应用程序创建
public static final int FIRST_SYSTEM_WINDOW = 2000;
//WindowType：状态栏，只能有一个状态栏，位于屏幕顶端，其他窗口都位于它下方
public static final int TYPE_STATUS_BAR = FIRST_SYSTEM_WINDOW;
//WindowType：搜索栏，只能有一个搜索栏，位于屏幕上方
public static final int TYPE_SEARCH_BAR = FIRST_SYSTEM_WINDOW+1;
//WindowType：电话窗口，它用于电话交互（特别是呼入），置于所有应用程序之上，状态栏之下
public static final int TYPE_PHONE = FIRST_SYSTEM_WINDOW+2;
//WindowType：系统提示，出现在应用程序窗口之上
public static final int TYPE_SYSTEM_ALERT = FIRST_SYSTEM_WINDOW+3;
//WindowType：锁屏窗口
public static final int TYPE_KEYGUARD = FIRST_SYSTEM_WINDOW+4;
//WindowType：信息窗口，用于显示Toast
public static final int TYPE_TOAST = FIRST_SYSTEM_WINDOW+5;
//WindowType：系统顶层窗口，显示在其他一切内容之上，此窗口不能获得输入焦点，否则影响锁屏
public static final int TYPE_SYSTEM_OVERLAY = FIRST_SYSTEM_WINDOW+6;
//WindowType：电话优先，当锁屏时显示，此窗口不能获得输入焦点，否则影响锁屏
public static final int TYPE_PRIORITY_PHONE = FIRST_SYSTEM_WINDOW+7;
//WindowType：系统对话框
public static final int TYPE_SYSTEM_DIALOG = FIRST_SYSTEM_WINDOW+8;
//WindowType：锁屏时显示的对话框
public static final int TYPE_KEYGUARD_DIALOG = FIRST_SYSTEM_WINDOW+9;
//WindowType：系统内部错误提示，显示于所有内容之上
public static final int TYPE_SYSTEM_ERROR = FIRST_SYSTEM_WINDOW+10;
//WindowType：内部输入法窗口，显示于普通UI之上，应用程序可重新布局以免被此窗口覆盖
public static final int TYPE_INPUT_METHOD = FIRST_SYSTEM_WINDOW+11;
//WindowType：内部输入法对话框，显示于当前输入法窗口之上
public static final int TYPE_INPUT_METHOD_DIALOG= FIRST_SYSTEM_WINDOW+12;
//WindowType：墙纸窗口
public static final int TYPE_WALLPAPER = FIRST_SYSTEM_WINDOW+13;
//WindowType：状态栏的滑动面板
public static final int TYPE_STATUS_BAR_PANEL = FIRST_SYSTEM_WINDOW+14;
//WindowType：安全系统覆盖窗口，这些窗户必须不带输入焦点，否则会干扰键盘
public static final int TYPE_SECURE_SYSTEM_OVERLAY = FIRST_SYSTEM_WINDOW+15;
//WindowType：拖放伪窗口，只有一个阻力层(最多)，它被放置在所有其他窗口上面
public static final int TYPE_DRAG = FIRST_SYSTEM_WINDOW+16;
//WindowType：状态栏下拉面板
public static final int TYPE_STATUS_BAR_SUB_PANEL = FIRST_SYSTEM_WINDOW+17;
//WindowType：鼠标指针
public static final int TYPE_POINTER = FIRST_SYSTEM_WINDOW+18;
//WindowType：导航栏(有别于状态栏时)
public static final int TYPE_NAVIGATION_BAR = FIRST_SYSTEM_WINDOW+19;
//WindowType：音量级别的覆盖对话框，显示当用户更改系统音量大小
public static final int TYPE_VOLUME_OVERLAY = FIRST_SYSTEM_WINDOW+20;
//WindowType：起机进度框，在一切之上
public static final int TYPE_BOOT_PROGRESS = FIRST_SYSTEM_WINDOW+21;
//WindowType：假窗，消费导航栏隐藏时触摸事件
public static final int TYPE_HIDDEN_NAV_CONSUMER = FIRST_SYSTEM_WINDOW+22;
//WindowType：梦想(屏保)窗口，略高于键盘
public static final int TYPE_DREAM = FIRST_SYSTEM_WINDOW+23;
//WindowType：导航栏面板(不同于状态栏的导航栏)
public static final int TYPE_NAVIGATION_BAR_PANEL = FIRST_SYSTEM_WINDOW+24;
//WindowType：universe背后真正的窗户
public static final int TYPE_UNIVERSE_BACKGROUND = FIRST_SYSTEM_WINDOW+25;
//WindowType：显示窗口覆盖，用于模拟辅助显示设备
public static final int TYPE_DISPLAY_OVERLAY = FIRST_SYSTEM_WINDOW+26;
//WindowType：放大窗口覆盖，用于突出显示的放大部分可访问性放大时启用
public static final int TYPE_MAGNIFICATION_OVERLAY = FIRST_SYSTEM_WINDOW+27;
//WindowType：......
public static final int TYPE_KEYGUARD_SCRIM = FIRST_SYSTEM_WINDOW+29;
public static final int TYPE_PRIVATE_PRESENTATION = FIRST_SYSTEM_WINDOW+30;
public static final int TYPE_VOICE_INTERACTION = FIRST_SYSTEM_WINDOW+31;
public static final int TYPE_ACCESSIBILITY_OVERLAY = FIRST_SYSTEM_WINDOW+32;
//WindowType：系统窗口结束
public static final int LAST_SYSTEM_WINDOW = 2999;


为什么使用PopWindow的时候，不设置背景就不能触发事件？

我们在使用PopupWindow的时候，会发现如果不给PopupWindow设置背景，那么就不能触发点击返回事件，有人认为这个是BUG，其实并不是的。

我们以下面的方法为例，其实所有的显示方法都有下面的流程：

public void showAtLocation(IBinder token, int gravity, int x, int y) {
if (isShowing() || mContentView == null) {
return;
} mIsShowing = true;
mIsDropdown = false; WindowManager.LayoutParams p = createPopupLayout(token);
p.windowAnimations = computeAnimationResource(); //在这里会根据不同的设置，配置不同的LayoutParams属性
preparePopup(p);
if (gravity == Gravity.NO_GRAVITY) {
gravity = Gravity.TOP | Gravity.START;
}
p.gravity = gravity;
p.x = x;
p.y = y;
if (mHeightMode < 0) p.height = mLastHeight = mHeightMode;
if (mWidthMode < 0) p.width = mLastWidth = mWidthMode;
invokePopup(p);
}

我们重点看下preparePopup()


private void preparePopup(WindowManager.LayoutParams p) {
//根据背景的设置情况进行不同的配置
if (mBackground != null) {
final ViewGroup.LayoutParams layoutParams = mContentView.getLayoutParams();
int height = ViewGroup.LayoutParams.MATCH_PARENT; //如果设置了背景，就用一个PopupViewContainer对象来包裹之前的mContentView，并设置背景后
PopupViewContainer popupViewContainer = new PopupViewContainer(mContext);
PopupViewContainer.LayoutParams listParams = new PopupViewContainer.LayoutParams(
ViewGroup.LayoutParams.MATCH_PARENT, height
);
popupViewContainer.setBackground(mBackground);
popupViewContainer.addView(mContentView, listParams); mPopupView = popupViewContainer;
} else {
mPopupView = mContentView;
}
}


为啥包了一层PopupViewContainer，就可以处理按钮点击事件了？因为PopupWindow没有相关事件回调，也没有重写按键和触摸方法，所以接收不到对应的信号

public class PopupWindow {}

而PopupViewContainer则可以，因为它重写了相关方法

private class PopupViewContainer extends FrameLayout { @Override
public boolean dispatchKeyEvent(KeyEvent event) {
if (event.getKeyCode() == KeyEvent.KEYCODE_BACK) {
if (getKeyDispatcherState() == null) {
return super.dispatchKeyEvent(event);
} if (event.getAction() == KeyEvent.ACTION_DOWN
&& event.getRepeatCount() == 0) {
KeyEvent.DispatcherState state = getKeyDispatcherState();
if (state != null) {
state.startTracking(event, this);
}
return true;
} else if (event.getAction() == KeyEvent.ACTION_UP) {
//back键消失
KeyEvent.DispatcherState state = getKeyDispatcherState();
if (state != null && state.isTracking(event) && !event.isCanceled()) {
dismiss();
return true;
}
}
return super.dispatchKeyEvent(event);
} else {
return super.dispatchKeyEvent(event);
}
} @Override
public boolean dispatchTouchEvent(MotionEvent ev) {
if (mTouchInterceptor != null && mTouchInterceptor.onTouch(this, ev)) {
return true;
}
return super.dispatchTouchEvent(ev);
} @Override
public boolean onTouchEvent(MotionEvent event) {
final int x = (int) event.getX();
final int y = (int) event.getY();
//触摸在外面就消失
if ((event.getAction() == MotionEvent.ACTION_DOWN)
&& ((x < 0) || (x >= getWidth()) || (y < 0) || (y >= getHeight()))) {
dismiss();
return true;
} else if (event.getAction() == MotionEvent.ACTION_OUTSIDE) {
dismiss();
return true;
} else {
return super.onTouchEvent(event);
}
}
}

在Activity中使用Dialog的时候，为什么有时候会报错“Unable to add window – token is not valid; is your activity running?”？

这种情况一般发生在什么时候？一般发生在Activity进入后台，Dialog没有主动Dismiss掉，然后从后台再次进入App的时候。

为什么会这样呢？

还记得前面说过吧，子窗口类型的Window，比如Dialog，想要显示的话，比如保证appToken与Activity保持一致，而当Activity销毁，再次回来的时候，Dialog试图重新创建，调用ViewRootImp的setView()的时候就会出问题，所以记得在Activity不可见的时候，主动Dismiss掉Dialog。

if (res < WindowManagerGlobal.ADD_OKAY) { switch (res) {
case WindowManagerGlobal.ADD_BAD_APP_TOKEN:
case WindowManagerGlobal.ADD_BAD_SUBWINDOW_TOKEN:
throw new WindowManager.BadTokenException(
"Unable to add window -- token " + attrs.token
+ " is not valid; is your activity running?");
case WindowManagerGlobal.ADD_NOT_APP_TOKEN:
throw new WindowManager.BadTokenException(
"Unable to add window -- token " + attrs.token
+ " is not for an application");
case WindowManagerGlobal.ADD_APP_EXITING:
throw new WindowManager.BadTokenException(
"Unable to add window -- app for token " + attrs.token
+ " is exiting");
case WindowManagerGlobal.ADD_DUPLICATE_ADD:
throw new WindowManager.BadTokenException(
"Unable to add window -- window " + mWindow
+ " has already been added");
case WindowManagerGlobal.ADD_STARTING_NOT_NEEDED:
// Silently ignore -- we would have just removed it
// right away, anyway.
return;
case WindowManagerGlobal.ADD_MULTIPLE_SINGLETON:
throw new WindowManager.BadTokenException(
"Unable to add window " + mWindow +
" -- another window of this type already exists");
case WindowManagerGlobal.ADD_PERMISSION_DENIED:
throw new WindowManager.BadTokenException(
"Unable to add window " + mWindow +
" -- permission denied for this window type");
case WindowManagerGlobal.ADD_INVALID_DISPLAY:
throw new WindowManager.InvalidDisplayException(
"Unable to add window " + mWindow +
" -- the specified display can not be found");
}
throw new RuntimeException(
"Unable to add window -- unknown error code " + res);
}
}

为什么Toast需要由系统统一控制，在子线程中为什么不能显示Toast？

首先Toast也属于窗口系统，但是并不是属于App的，是由系统同一控制的。 
关于这一块不想说太多，具体实现机制请参考后面的文章。

为了看下面的内容，你需要知道以下几件事情：

1. Toast的显示是由系统Toast服务控制的，与系统之间的通信方式是Binder
2. 整个Toast系统会维持最多50个Toast的队列，依次显示
3. 负责显示工作的是Toast的内部类TN，它负责最终的显示与隐藏操作
4. 负责给系统Toast服务发送内容的是INotificationManager的实现类，它负责在Toast.show()里面把TN对象传递给系统消息服务，service.enqueueToast(pkg, tn, mDuration);这样Toast服务就持有客户端的代理，可以通过TN来控制每个Toast的显示与隐藏。

再来张图（转自工匠若水）

ok，现在假如你知道上面这些啦，那么我们下面就看为什么在子线程使用Toast.show()会提示

"No Looper; Looper.prepare() wasn't called on this thread."

• 1

原因很简单，因为TN在操作Toast的时候，是通过Handler做的

@Override
public void show() {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.post(mShow);
} @Override
public void hide() {
if (localLOGV) Log.v(TAG, "HIDE: " + this);
mHandler.post(mHide);
}


所以说，TN初始化的线程必须为主线程，在子线程中使用Handler，由于没有消息队列，就会造成这个问题。

结语

上面写了这么多，你可能看了前面忘了后面，下面，凯子哥给你总结一下，这篇文章到底讲了什么东西：

• 每个Activity，都至少有一个Window，这个Window实际类型为PhoneWindow，当Activity中有子窗口，比如Dialog的时候，就会出现多个Window。Activity的Window是我们控制的，状态栏和导航栏的Window由系统控制。
• 在DecorView的里面，一定有一个id为content的FraneLayout的布局容器，咱们自己定义的xml布局都放在这里面。
• Activity的Window里面有一个DecorView，它使继承自FrameLayout的一个自定义控件，作为整个View层的容器，及View树的根节点。
• Window是虚拟的概念，DecorView才是看得见，摸得着的东西，Activity.setContentView()实际调用的是PhoneWindow.setContentView()，在这里面实现了DecorView的初始化和id为content的FraneLayout的布局容器的初始化，并且会根据主题等配置，选择不同的xml文件。而且在Activity.setContentView()之后，Window的一些特征位将被锁定。
• Activity.findViewById()实际上调用的是DecorView的findviewById()，这个方法在View中定义，但是是final的，实际起作用的是在ViewGroup中被重写的findViewTraversal()方法。
• Activity的mWindow成员变量是在attach()的时候被初始化的，attach()是Activity被通过反射手段实例化之后调用的第一个方法，在这之后生命周期方法才会依次调用
• 在onResume()刚执行之后，界面还是不可见的，只有执行完Activity.makeVisible()，DecorView才对用户可见
• ViewManager这个接口里面就三个接口，添加、移除和更新，实现这个接口的有WindowManager和ViewGroup，但是他们两个面向的对象是不一样的，WindowManager实现的是对Window的操作，而ViewGroup则是对View的增、删、更新操作。
• WindowManagerImpl是WindowManager的实现类，但是他就是一个代理类，代理的是WindowManagerGlobal，WindowManagerGlobal一个App里面就有一个，因为它是单例的，它里面管理了App中所有打开的DecorView，ContentView和PhoneWindow的布局参数WindowManager.LayoutParams，而且WindowManagerGlobal这个类是和WMS通信用的，是通过IWindowSession对象完成这个工作的，而IWindowSession一个App只有一个，但是每个ViewRootImpl都持有对IWindowSession的引用，所以ViewRootImpl可以和WMS喊话，但是WMS怎么和ViewRootImpl喊话呢？是通过ViewRootImpl::W这个内部类实现的，而且源码中很多地方采用了这种将接口隐藏为内部类的方式，这样可以实现六大设计原则之一——接口最小原则，这样ViewRootImpl和WMS就互相持有对方的代理，就可以互相交流了
• ViewRootImpl这个类每个Activity都有一个，它负责和WMS通信，同时相应WMS的指挥，还负责View界面的测量、布局和绘制工作，所以当你调用View.invalidate()和View.requestLayout()的时候，都会把事件传递到ViewRootImpl，然后ViewRootImpl计算出需要重绘的区域，告诉WMS，WMS再通知其他服务完成绘制和动画等效果，当然，这是后话，咱们以后再说。
• Window分为三种，子窗口，应用窗口和系统窗口，子窗口必须依附于一个上下文，就是Activity，因为它需要Activity的appToken，子窗口和Activity的WindowManager是一个的，都是根据appToken获取的，描述一个Window属于哪种类型，是根据LayoutParam.type决定的，不同类型有不同的取值范围，系统类的的Window需要特殊权限，当然Toast比较特殊，不需要权限
• PopupWindow使用的时候，如果想触发按键和触摸事件，需要添加一个背景，代码中会根据是否设置背景进行不同的逻辑判断
• Dialog在Activity不可见的时候，要主动dismiss掉，否则会因为appToken为空crash
• Toast属于系统窗口，由系统服务NotificationManagerService统一调度，NotificationManagerService中维持着一个集合ArrayList，最多存放50个Toast，但是NotificationManagerService只负责管理Toast，具体的显示工作由Toast::TN来实现

最后来一张Android的窗口管理框架（转自ariesjzj）

OK，关于Activity的界面显示就说到这里吧，本篇文章大部分的内容来自于阅读下面参考文章之后的总结和思考，想了解更详细的可以研究下。

下次再见，拜拜~

参考文章

• Android应用Activity、Dialog、PopWindow、Toast窗口添加机制及源码分析
• Android应用setContentView与LayoutInflater加载解析机制源码分析
• Android 4.4(KitKat)窗口管理子系统 - 体系框架
• Android 之 Window、WindowManager 与窗口管理
• 图解Android - Android GUI 系统 (1) - 概论