不知道有多少伙伴在实际的项目中使用过WindowManager，如果有了解过WindowManager或者WMS的伙伴应该知道，这在Android Framework中其实是很庞大的，因为所有页面的展示都是基于Window的，而且现在很多音视频软件，例如音视频通话、播放器等，在退出后台之后会在前台有一个悬浮窗口，我们可以随意拖动，像这种技术实现手段就是通过WindowManager完成的，所以了解WMS的原理能够帮助我们实现高性能的悬浮窗组件。
1 Window的认知
首先我们从常见的几个概念入手，初步了解WMS。
1.1 基础概念了解
- Window
相信伙伴们对于Window都有所了解，Window是一个抽象类，源码中声明现存唯一的实现类就是PhoneWindow。
The only existing implementation of this abstract class is android.view.PhoneWindow, which you should instantiate when needing a Window.
其实每个页面都对应一个Window，例如每启动一个Activity，都会创建一个Window，当前页面所有的View都会在这个容器中展示。
- WindowManager
WindowManager是用于对Window的管理，例如前面我们提到的每次启动一个Activity都会创建一个Window，除了创建之外，还包括更新以及删除。
public interface ViewManager
{
/**
* Assign the passed LayoutParams to the passed View and add the view to the window.
* <p>Throws {@link android.view.WindowManager.BadTokenException} for certain programming
* errors, such as adding a second view to a window without removing the first view.
* <p>Throws {@link android.view.WindowManager.InvalidDisplayException} if the window is on a
* secondary {@link Display} and the specified display can't be found
* (see {@link android.app.Presentation}).
* @param view The view to be added to this window.
* @param params The LayoutParams to assign to view.
*/
public void addView(View view, ViewGroup.LayoutParams params);
public void updateViewLayout(View view, ViewGroup.LayoutParams params);
public void removeView(View view);
}
- WMS
WMS，全称是WindowManagerService，也是与AMS、PKMS平级的系统服务，所以我们平时使用的WindowManager只是服务端的一个代理，这才是真正去做View的添加、删除和更新逻辑的服务。
那么常见的Window有哪些呢？首先Activity就是一个窗口，页面所有的View都在Window之上；除此之外，Dialog、Toast、PopupWindow等，也是一个Window。
1.2 Window的分类
- Application Window
这一类属于应用程序窗口，例如Activity就是典型，就不在此赘述了。
/**
* Start of window types that represent normal application windows.
*/
public static final int FIRST_APPLICATION_WINDOW = 1;
/**
* End of types of application windows.
*/
public static final int LAST_APPLICATION_WINDOW = 99;
这里系统对于应用程序窗口做了上下界的控制，在type处于1-99之间的都是属于应用窗口。
- Sub Window
我们可以理解为子窗口，它不能独立存在，而是需要依附于父窗口才能展示。例如Dialog，它需要依附于Activity的窗口作为父窗口才可以展示，共用一个Token。
/**
* Start of types of sub-windows. The {@link #token} of these windows
* must be set to the window they are attached to. These types of
* windows are kept next to their attached window in Z-order, and their
* coordinate space is relative to their attached window.
*/
public static final int FIRST_SUB_WINDOW = 1000;
/**
* End of types of sub-windows.
*/
public static final int LAST_SUB_WINDOW = 1999;
这里系统对于子窗口做了上下界的控制，在type处于1000-1999之间的都是属于子窗口。
- System Window
系统窗口比较特殊，它不需要依附于父窗口就可以独立存在，而且子窗口可以升级为系统窗口，只需要将Window的type修改为TYPE_SYSTEM_ALERT ，就可以将Dialog升级为系统窗口。
window?.setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT)
除此之外，还有系统的音量条、亮度条、Toast，以及发生crash之后弹出的系统弹窗。
/**
* Start of system-specific window types. These are not normally
* created by applications.
*/
public static final int FIRST_SYSTEM_WINDOW = 2000;
/**
* End of types of system windows.
*/
public static final int LAST_SYSTEM_WINDOW = 2999;
这里系统对于系统窗口做了上下界的控制，在type处于2000-2999之间的都是属于系统窗口。
1.3 窗口的等级排序
那么这里想一个问题，既然窗口分了3种类型，那么其排列顺序是什么样的呢，是否可以在两个子窗口中间弹出一个系统弹窗呢？
答案是不可以！其实这里大家需要记住一点，Window的type值越大，那么其层级就越深，也就意味着会在屏幕的最上层展示。
所以系统窗口会在应用窗口以及子窗口的最上面，见下图展示：
所以如果我们想要在应用上层做View的展示，可以选择使用子窗口或者系统窗口 ，当然使用Dialog可能无法满足产品需求，所以才会考虑使用WindowManager。
2 WindowManager的使用
首先画一下与Window相关的类图：
这里是采用了桥接设计模式，抽象与实现分离，每个实现类（PhoneWindow和WindowManagerImpl）自由发展，Window作为抽象类，持有了WindowManager的引用，子类可以在此基础上做相应的扩展。
2.1 Window的创建
当我们启动一个Activity的时候，就会创建一个Window，所以我们从Activity的启动开始看起，通过前面我们对于Activity启动章节的介绍，会在performLaunchActivity方法中，做真正Activity的启动。
在这个方法中，通过Instrument创建一个新的Activity，然后调用Activity的attach方法：
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, String referrer, IVoiceInteractor voiceInteractor,
Window window, ActivityConfigCallback activityConfigCallback, IBinder assistToken,
IBinder shareableActivityToken) {
attachBaseContext(context);
mFragments.attachHost(null /*parent*/);
//创建PhoneWindow对象
mWindow = new PhoneWindow(this, window, activityConfigCallback);
mWindow.setWindowControllerCallback(mWindowControllerCallback);
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
mWindow.getLayoutInflater().setPrivateFactory(this);
// 创建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();
mCurrentConfig = config;
mWindow.setColorMode(info.colorMode);
mWindow.setPreferMinimalPostProcessing(
(info.flags & ActivityInfo.FLAG_PREFER_MINIMAL_POST_PROCESSING) != 0);
setAutofillOptions(application.getAutofillOptions());
setContentCaptureOptions(application.getContentCaptureOptions());
}
我们看到，在Activity的attach方法中，创建了PhoneWindow对象，然后获取到WindowManager对象并调用setWindowManager方法。
public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
boolean hardwareAccelerated) {
mAppToken = appToken;
mAppName = appName;
mHardwareAccelerated = hardwareAccelerated;
if (wm == null) {
wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
}
mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
}
在setWindowManager中，将mWindowManager赋值，其实就是创建了WindowManagerImpl对象，在调用getWindowManager方法时，拿到的就是WindowManagerImpl实例，后续所有View的处理都是通过WindowManagerImpl来完成。
那么当Window创建完成之后，内部View是如何添加的呢？现在只是创建一个空壳容器，那么在Activity创建完成之后，调用onCreate方法，就是开始往空壳中填充元素，具体的一个抽象层级可以看下图：
这里我们拿应用窗口举例，其实子窗口与系统窗口与其架构一致，当启动一个Activity的时候，前面我们分析到在调用attach方法时，会创建PhoneWindow以及WindowManager实现类。然后往下会有一个DecorView，这个是什么呢？
2.1.1 DecorView的创建
DecorView是FrameLayout的一个子类，它是页面树形结构中的根节点，那么它是什么时候创建的呢？
public void setContentView(int resId) {
ensureSubDecor();
ViewGroup contentParent = mSubDecor.findViewById(android.R.id.content);
contentParent.removeAllViews();
LayoutInflater.from(mContext).inflate(resId, contentParent);
mAppCompatWindowCallback.bypassOnContentChanged(mWindow.getCallback());
}
当调用setContentView时，首先调用ensureSubDecor判断DecorView是否创建；
所以DecorView就是在setContentView时完成了创建，并且与Window完成了绑定关系，当然DecorView的布局可能会因为不同的配置而渲染不同的xml文件，但是一定会存在一个承载页面的容器，我们看在DecorView创建完成之后，会通过查找id为content的容器，移除里面全部的子View，并把最新的布局添加到content中。
所以我们页面的布局，其实就是DecorView的一个子View。
2.1.2 View的添加时机
当Activity调用onCreate方法时，会将布局解析并实例化View，那么具体显示在页面上时就是在onResume生命周期完成后，此时页面可以与用户交互了，所以我们看下handleResumeActivity中具体做了什么事。
@Override
public void handleResumeActivity(ActivityClientRecord r, boolean finalStateRequest,
boolean isForward, String reason) {
// .....
final Activity a = r.activity;
// .....
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (r.mPreserveWindow) {
a.mWindowAdded = true;
r.mPreserveWindow = false;
// Normally the ViewRoot sets up callbacks with the Activity
// in addView->ViewRootImpl#setView. If we are instead reusing
// the decor view we have to notify the view root that the
// callbacks may have changed.
ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
// ※ 这里添加了DecorView
wm.addView(decor, l);
} else {
// The activity will get a callback for this {@link LayoutParams} change
// earlier. However, at that time the decor will not be set (this is set
// in this method), so no action will be taken. This call ensures the
// callback occurs with the decor set.
a.onWindowAttributesChanged(l);
}
}
// If the window has already been added, but during resume
// we started another activity, then don't yet make the
// window visible.
} else if (!willBeVisible) {
if (localLOGV) Slog.v(TAG, "Launch " + r + " mStartedActivity set");
r.hideForNow = true;
}
// ......
}
我们看到在handleResumeActivity中，调用了WindowManagerImpl的addView方法，所以我们需要总结一下：
- 当onCreate方法中调用setContentView方法时，首先会创建DecorView（如果没有创建的话），然后解析xml布局将View添加到DecorView当中，此时并没有显示；
- 在onResume方法中，如上源码，此时会将准备好的DecorView添加到Window当中，此时页面才会可见可交互。
2.2 ViewRootImpl大管家
通过前面的分析，我们知道当onResume的时候，调用WindowManagerImpl的addView方法，我们看了下源码发现是空实现，其实在调用getWindowManager().addView方法时，实际上是调用的WindowManagerGlobal的addView方法。
@UnsupportedAppUsage
private final ArrayList<View> mViews = new ArrayList<View>();
@UnsupportedAppUsage
private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow, int userId) {
if (view == null) {
throw new IllegalArgumentException("view must not be null");
}
if (display == null) {
throw new IllegalArgumentException("display must not be null");
}
if (!(params instanceof WindowManager.LayoutParams)) {
throw new IllegalArgumentException("Params must be WindowManager.LayoutParams");
}
final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;
if (parentWindow != null) {
parentWindow.adjustLayoutParamsForSubWindow(wparams);
} else {
// If there's no parent, then hardware acceleration for this view is
// set from the application's hardware acceleration setting.
final Context context = view.getContext();
if (context != null
&& (context.getApplicationInfo().flags
& ApplicationInfo.FLAG_HARDWARE_ACCELERATED) != 0) {
wparams.flags |= WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED;
}
}
ViewRootImpl root;
View panelParentView = null;
synchronized (mLock) {
// Start watching for system property changes.
if (mSystemPropertyUpdater == null) {
mSystemPropertyUpdater = new Runnable() {
@Override public void run() {
synchronized (mLock) {
for (int i = mRoots.size() - 1; i >= 0; --i) {
mRoots.get(i).loadSystemProperties();
}
}
}
};
SystemProperties.addChangeCallback(mSystemPropertyUpdater);
}
int index = findViewLocked(view, false);
if (index >= 0) {
if (mDyingViews.contains(view)) {
// Don't wait for MSG_DIE to make it's way through root's queue.
mRoots.get(index).doDie();
} else {
throw new IllegalStateException("View " + view
+ " has already been added to the window manager.");
}
// The previous removeView() had not completed executing. Now it has.
}
// If this is a panel window, then find the window it is being
// attached to for future reference.
if (wparams.type >= WindowManager.LayoutParams.FIRST_SUB_WINDOW &&
wparams.type <= WindowManager.LayoutParams.LAST_SUB_WINDOW) {
final int count = mViews.size();
for (int i = 0; i < count; i++) {
if (mRoots.get(i).mWindow.asBinder() == wparams.token) {
panelParentView = mViews.get(i);
}
}
}
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// do this last because it fires off messages to start doing things
try {
// 与view树建立关联
root.setView(view, wparams, panelParentView, userId);
} catch (RuntimeException e) {
// BadTokenException or InvalidDisplayException, clean up.
if (index >= 0) {
removeViewLocked(index, true);
}
throw e;
}
}
}
在addView方法中，创建了一个ViewRootImpl对象，这个对象负责全部View的管理，相当于View的根节点，每创建一个Window，都会创建一个ViewRootIMpl，因为WindowManagerGlobal是一个单例，所以会有一个mRoots集合存储所有Window的树形结构。
通过下面这张图可以直观地看到两者的关系：
创建ViewRootImpl之后，会调用setView方法与View树建立关联，在setView方法中，会通过mWindowSession与WMS建立通信。
try {
mOrigWindowType = mWindowAttributes.type;
mAttachInfo.mRecomputeGlobalAttributes = true;
collectViewAttributes();
adjustLayoutParamsForCompatibility(mWindowAttributes);
controlInsetsForCompatibility(mWindowAttributes);
res = mWindowSession.addToDisplayAsUser(mWindow, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(), userId,
mInsetsController.getRequestedVisibilities(), inputChannel, mTempInsets,
mTempControls);
if (mTranslator != null) {
mTranslator.translateInsetsStateInScreenToAppWindow(mTempInsets);
mTranslator.translateSourceControlsInScreenToAppWindow(mTempControls);
}
} catch (RemoteException e) {
mAdded = false;
mView = null;
mAttachInfo.mRootView = null;
mFallbackEventHandler.setView(null);
unscheduleTraversals();
setAccessibilityFocus(null, null);
throw new RuntimeException("Adding window failed", e);
} finally {
if (restore) {
attrs.restore();
}
}
IWindowSession可以认为是WMS服务端的代理对象，双方通过Binder完成进程间通信，告诉WMS要添加一个窗口，这里我们后续会详细地介绍。
那么到这里一个Window窗口就显示在了用户面前。
2.2.1 绘制流程的触发时机
前面我们讲到了ViewRootImpl主要用来管理View树，既然能够管理View树，那么View的刷新也是交由ViewRootImpl来控制。
具体可见2.3节的介绍。
2.2.2 事件分发流程
既然作为全部View的大管家，那么事件的分发其实也是由ViewRootImpl来完成，具体流程如下：
首先ViewRootImpl将事件给到DecorView，但是DecorView并没有直接将事件给到ViewGroup，而是先给了Activity，看起来红色区域的是有点儿重复，但是能略过1-2-3步骤，直接从步骤4开始吗？
其实是不行的！为什么呢？相信伙伴们在开发中，肯定涉及到对Window设置flag，也就是所谓的“标志”，例如我们设置了一个FLAG_NOT_FOCUSABLE标志位，此时Window不会拿到任何的焦点。
window.addFlags(WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE)
如果只是从步骤4进行分发，那么窗体一定是可以获取到焦点，因为这是默认的行为，所以这样设置Flag就无效了，因此DecorView先将事件给到Activity，然后Activity将事件给到PhoneWindow，由PhoneWindow自身设置的flag决定事件如何分发。
2.3 Window的刷新
前面我们介绍了Window的创建以及View的添加，接下来我们分析ViewManager的第二个方法刷新方法。其实在调用刷新方法时，最终肯定是调用了WindowManagerGlobal的updateViewLayout方法。
public void updateViewLayout(View view, ViewGroup.LayoutParams params) {
if (view == null) {
throw new IllegalArgumentException("view must not be null");
}
if (!(params instanceof WindowManager.LayoutParams)) {
throw new IllegalArgumentException("Params must be WindowManager.LayoutParams");
}
final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams)params;
view.setLayoutParams(wparams);
synchronized (mLock) {
int index = findViewLocked(view, true);
ViewRootImpl root = mRoots.get(index);
mParams.remove(index);
mParams.add(index, wparams);
root.setLayoutParams(wparams, false);
}
}
通过前面我们对于addView源码的分析，我们需要先熟知两个变量：mRoots和mViews，首先mRoots是ViewRootImpl的集合，mViews是添加进来的View的集合，如果我们拿启动Activity为例，添加进来的View是DecorView，所以在更新Window的时候，首先会调用findViewLocked从mViews中拿到对应的位置index。
private int findViewLocked(View view, boolean required) {
final int index = mViews.indexOf(view);
if (required && index < 0) {
throw new IllegalArgumentException("View=" + view + " not attached to window manager");
}
return index;
}
找到View所在的index之后，因为添加View和Roots是同步的，所以也可以拿到当前Window对应的ViewRootImpl，从而调用setLayoutParams方法进行刷新。
public void setLayoutParams(WindowManager.LayoutParams attrs, boolean newView) {
synchronized (this) {
// ......
if (newView) {
mSoftInputMode = attrs.softInputMode;
requestLayout();
}
// Don't lose the mode we last auto-computed.
if ((attrs.softInputMode & SOFT_INPUT_MASK_ADJUST)
== WindowManager.LayoutParams.SOFT_INPUT_ADJUST_UNSPECIFIED) {
mWindowAttributes.softInputMode = (mWindowAttributes.softInputMode
& ~SOFT_INPUT_MASK_ADJUST) | (oldSoftInputMode & SOFT_INPUT_MASK_ADJUST);
}
if (mWindowAttributes.softInputMode != oldSoftInputMode) {
requestFitSystemWindows();
}
mWindowAttributesChanged = true;
scheduleTraversals();
}
}
我们关注下第二个参数，如果是newView，那么就会调用requestLayout进行刷新，我们看到调用updateViewLayout方法时，传入的为false，那么就会直接调用scheduleTraversals方法。
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
这个时候会发送UI刷新的信号，通过postSyncBarrier发送同步屏障，最终进入到ViewRootImpl的performTraversals方法中，主要从以下几步入手：
- 在发送同步栅栏信号之后，其实就会等待VSYNC信号回来，然后执行TraversalRunnable中的run方法。
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
- 其实doTraversal方法中，就是执行performTraversals方法，
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
if (mProfile) {
Debug.startMethodTracing("ViewAncestor");
}
performTraversals();
if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}
这个方法中具体干了什么，记住下面的图即可。
是不是很熟悉，其实就是通过ViewRootImpl发起重新绘制的流程，通过ViewRootImpl传递给ViewGroup，然后通过ViewGroup传递到子View，分别进行测量、布局、绘制到页面上。
2.3.1 UI刷新机制
前面我们讲到，当调用updateViewLayout时，就会触发UI刷新绘制流程，例如我们想要修改TextView的值，假如我们连续调用两次setTextView会触发几次重绘呢？
这里我们先了解下Android的刷新机制，Android手机目前设置的帧率为60FPS，也就是每秒60帧的刷新速率，精确到毫秒，就是间隔16ms会绘制一帧，所以即便我们多次调用setTextView，最终也只是会在16ms内触发一次重绘。
那么当UI准备刷新时，到刷新完成中间的流程是什么样的呢？我们以setTextView为例。
当在上层主动调用刷新接口时，一般是通过调用invalidate或者postinvalidate，调用setTextView方法时，底层其实也是调用了invalidate方法申请发起重绘。
那么View自身肯定不能说刷新就能立刻刷新，需要一层一层向上打报告，直到找到ViewRootImpl，此时就像调用ViewManager的updateViewLayout方法一样，会执行ViewRootImpl # scheduleTraversals方法进行重绘，往MessageQueue中插入同步栅栏，同时向VSYNC服务发起请求。
当VSYNC服务同意重绘之后，会将VSYNC信号返回，ViewRootImpl接收到消息后，删除同步栅栏，调用performTravesals方法进行UI重绘。
所以整个的流程如下：
这里需要注意一点，即便是有16ms的刷机机制，但是系统一定是在每隔16ms的间隔内完成刷新吗？其实不是的，发起刷新请求一定是客户端主动申请VSYNC，等到VSYNC返回之后才会刷新，否则就不会刷新，例如整个页面的UI都没有变化。
2.3.2 SurfaceFlinger渲染进程
前面我们分析在接收到VSYNC信号返回之后，会执行performTraversal方法进行重绘，最终终点就在onDraw方法中，会在画布上画出图像数据。
那么既然提到了图像渲染，那么简单提一下Android系统的渲染核心进程SurfaceFlinger，包括我们前面提到的画布渲染，应用的所有渲染逻辑都会进入到SF中进行，把处理后的图像数据交给CPU或者GPU进行绘制。
其实通过对Window的基本概念的理解，以及从Window的创建到View的添加，我们大概对于WindowManager的作用有了大致的了解，其实这里没有涉及到WMS源码的分析，在后续的文章中会深入WMS，看在系统底层如何完成对View的控制逻辑。
