> 前几天凯子哥写的Framework层的解析文章[《Activity启动过程全解析》](http://blog.csdn.net/zhaokaiqiang1992/article/details/49428287)，反响还不错，这说明“写让大家都能看懂的Framework解析文章”的思想是基本正确的。
> 我个人觉得，深入分析的文章必不可少，但是对于更多的Android开发者——即只想做应用层开发，不想了解底层实现细节——来说，“整体上把握，重要环节深入“是更好的学习方式。因为这样既可以有完整的知识体系，又不会在浩瀚的源码世界里迷失兴趣和方向。
> 所以呢，今天凯子哥又带来一篇文章，接着上一篇的结尾，重点介绍Activity开启之后，Android系统对界面的一些操作及相关知识。
- [本期关键字](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#本期关键字)
- [学习目标](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#学习目标)
- [写作方式](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#写作方式)
- [进入正题](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#进入正题)
- [onCreate中的setContentView到底做了什么为什么不能在setContentView之后设置某些Window属性标志](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#oncreate中的setcontentview到底做了什么为什么不能在setcontentview之后设置某些window属性标志)
- [Activity中的findViewById本质上是在做什么](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#activity中的findviewbyid本质上是在做什么)
- [Window和PhoneWindow是什么关系WindowManager是做什么的](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#window和phonewindow是什么关系windowmanager是做什么的)
- [Activity中Window类型的成员变量mWindow是什么时候初始化的](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#activity中window类型的成员变量mwindow是什么时候初始化的)
- [PhoneWindowsetContentView到底发生了什么](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#phonewindowsetcontentview到底发生了什么)
- [如何验证上一个问题](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#如何验证上一个问题)
- [我们通过setContentView设置的界面为什么在onResume之后才对用户可见呢](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#我们通过setcontentview设置的界面为什么在onresume之后才对用户可见呢)
- [ViewManagerWindowManagerWindowManagerImplWindowManagerGlobal到底都是些什么玩意](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#viewmanagerwindowmanagerwindowmanagerimplwindowmanagerglobal到底都是些什么玩意)
- [ViewRootImpl是什么有什么作用ViewRootImpl如何与WMS通信](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#viewrootimpl是什么有什么作用viewrootimpl如何与wms通信)
- [从什么时候开始绘制整个Activity的View树的](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#从什么时候开始绘制整个activity的view树的)
- [Window的类型有几种分别在什么情况下会使用到哪一种](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#window的类型有几种分别在什么情况下会使用到哪一种)
- [为什么使用PopWindow的时候不设置背景就不能触发事件](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#为什么使用popwindow的时候不设置背景就不能触发事件)
- [在Activity中使用Dialog的时候为什么有时候会报错Unable to add window token is not valid is your activity running](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#在activity中使用dialog的时候为什么有时候会报错unable-to-add-window-token-is-not-valid-is-your-activity-running)
- [为什么Toast需要由系统统一控制在子线程中为什么不能显示Toast](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#为什么toast需要由系统统一控制在子线程中为什么不能显示toast)
- [结语](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#结语)
- [参考文章](http://blog.csdn.net/zhaokaiqiang1992/article/details/49681321#参考文章)
## 本期关键字
- 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。
下面贴上这个图，你就可以看明白了(转自 [工匠若水](http://blog.csdn.net/yanbober))
~~~
ViewGroup view = (ViewGroup) getWindow().getDecorView();
~~~
我们通过setContentView()设置的界面，为什么在onResume()之后才对用户可见呢？
有开发经验的朋友应该知道，我们的界面元素在onResume()之后才对用户是可见的，这是为啥呢？
那我们就追踪一下，onResume()是什么时候调用的，然后看看做了什么操作就Ok了。
这一下，我们又要从ActivityThread开始说起了，不熟悉的快去看前一篇文章《Activity启动过程全解析》]([http://blog.csdn.net/zhaokaiqiang1992/article/details/49428287](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 {}
~~~
怎么知道的呢？那我们还要从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()的时候进行了关联。
插一张类图（转自[工匠若水](http://blog.csdn.net/yanbober)）
知道了这些，那下面的操作就可以直接看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);
~~~
其实最终调用的是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
1. 整个Toast系统会维持最多50个Toast的队列，依次显示
1. 负责现实工作的是Toast的内部类TN，它负责最终的显示与隐藏操作
1. 负责给系统Toast服务发送内容的是INotificationManager的实现类，它负责在Toast.show()里面把TN对象传递给系统消息服务，service.enqueueToast(pkg, tn, mDuration);这样Toast服务就持有客户端的代理，可以通过TN来控制每个Toast的显示与隐藏。
再来张图（转自[工匠若水](http://blog.csdn.net/yanbober)）
ok，现在假如你知道上面这些啦，那么我们下面就看为什么在子线程使用Toast.show()会提示
~~~
"No Looper; Looper.prepare() wasn't called on this thread."
~~~
原因很简单，因为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](http://blog.csdn.net/jinzhuojun)）
OK，关于Activity的界面显示就说到这里吧，本篇文章大部分的内容来自于阅读下面参考文章之后的总结和思考，想了解更详细的可以研究下。
下次再见，拜拜~
## 参考文章
- [Android应用Activity、Dialog、PopWindow、Toast窗口添加机制及源码分析](http://blog.csdn.net/yanbober/article/details/46361191)
- [Android应用setContentView与LayoutInflater加载解析机制源码分析](http://blog.csdn.net/yanbober/article/details/45970721)
- [Android 4.4(KitKat)窗口管理子系统 - 体系框架](http://blog.csdn.net/jinzhuojun/article/details/37737439)
- [Android 之 Window、WindowManager 与窗口管理](http://blog.csdn.net/xieqibao/article/details/6567814)
- [图解Android - Android GUI 系统 (1) - 概论](http://www.cnblogs.com/samchen2009/p/3364327.html)
尊重原创，转载请注明：From 凯子哥（[](http://blog.csdn.net/zhaokaiqiang1992)[http://blog.csdn.net/zhaokaiqiang1992](http://blog.csdn.net/zhaokaiqiang1992)） 侵权必究！
关注我的微博，可以获得更多精彩内容
[](http://weibo.com/u/1783932377?s=6uyXnP)
- 前言
- Android触摸屏事件派发机制详解与源码分析一(View篇)
- Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)
- Android触摸屏事件派发机制详解与源码分析三(Activity篇)
- Android应用setContentView与LayoutInflater加载解析机制源码分析
- Android应用Context详解及源码解析
- Android异步消息处理机制详解及源码分析
- Android应用Activity、Dialog、PopWindow、Toast窗口添加机制及源码分析
- Android ListView工作原理完全解析，带你从源码的角度彻底理解
- Activity启动过程全解析
- Android应用AsyncTask处理机制详解及源码分析
- 说说 PendingIntent 的内部机制
- Android Activity.startActivity流程简介
- Activity界面显示全解析
- 框架层理解Activity生命周期(APP启动过程)
- APK安装过程及原理详解
- Android构建过程简述
- Android应用层View绘制流程与源码分析