Android窗口和视图
Android 窗口类型
Android 窗口与视图的关系
Android 窗口视图与 Activity/Service 的关系
Android 窗口视图的创建过程
Android 窗口视图销毁流程
前置文章
前言
在 Android 设备中，我们经常会看到各种各样的窗口或者说视图。例如，我们打开一个应用，会打开主 Activity，我们可以在多个 Activity 中来回切换；我们可以从菜单键打开一个菜单的小窗口；我们经常使用 Dialog 或者 PopupWindow；又或者我们直接通过 WindowManager 的 addView() 添加一个视图。我们也会经常看到，很多不同的视图重叠在一起，一前一后，一亮一暗等等。所有的这些窗口（视图）都是如何去显示，与生成显示这些窗口（视图）的 Activity、Service 又存在怎样的关系？本文将会论述各种类型的 Android 窗口，以及它们和创建者（Activity、Service）的关系。
窗口类型介绍
什么是窗口类型
在 Android 系统显示架构中，每一个要显示的 View 所依托的窗口有一个类型（type）区分，不同的 type 的窗口的 View 显示的层次不同，位置不同，显示/销毁的过程不同等等。那么，呈现给用户的第一感受，就是各种各样的视图，对用户的视觉冲击就会非常强烈。
在代码中，每个窗口由 WindowManager.LayoutParams 的变量 type确定。如下：
public interface WindowManager extends ViewManager {
public static class LayoutParams extends ViewGroup.LayoutParams implements Parcelable {
public int type;
}
}（代码片段1）变量定义在文件 frameworks/base/core/java/android/view/WindowManager.java 中。
Android 窗口分三大类型，它们分别是：应用窗口、子窗口和系统窗口，每个大类型下又分各种不同的小类型窗口。
应用窗口（Application Windows）
应用窗口，别名基本窗口，type 的取值范围 1 ~ 99。默认情况下，所有的应用窗口和 Activity 共用相同的 AppToken，如果 Activity 销毁，所有的应用窗口同时也会销毁。Token 是什么？简单阐述，Token 是所有持有该 Token 的持有者的身份标识。如果读者对 Android 系统中 Token 不了解的，可以查阅相关材料。
目前系统已经定义的应用窗口有三种类型：
| Name | Value | Purpose |
|---|---|---|
| FIRST_APPLICATION_WINDOW | 1 | 定义 type 开始值 |
| TYPE_BASE_APPLICATION | 1 | 定义“基”窗口，Activity 的窗口为这种类型 |
| TYPE_APPLICATION | 2 | 显示在 Activity 上的窗口，如默认类型的 Dialog、PopupWindow |
| TYPE_APPLICATION_STARTING | 3 | 启动应用时的过度窗口，一般用于在目的窗口显示开始到显示这段时间内的一个过度窗口，一般会携带有动画。只有系统所使用，在 PhoneWindowManager.addFastStartingWindow() 方法中添加此窗口视图 |
| LAST_APPLICATION_WINDOW | 99 | 定义 type 结束值 |
子窗口（Sub-windows）
子窗口，依附在某个窗口上面的的窗口，type 取值范围 1000 ~ 1999。子窗口的 Token 必须是和它依附的窗口的 Token 一致。如果依附窗口被销毁，子窗口也会同时销毁。
| Name | Value | Purpose |
|---|---|---|
| FIRST_SUB_WINDOW | 1000 | 定义 type 开始值 |
| TYPE_APPLICATION_PANEL | 1000 | 定义子窗口的“基”窗口 |
| TYPE_APPLICATION_MEDIA | 1001 | 显示多媒体窗口，displayed behind their attached window |
| TYPE_APPLICATION_SUB_PANEL | 1002 | A sub-panel on top of an application window. These windows are displayed on top their attached window |
| TYPE_APPLICATION_ATTACHED_DIALOG | 1003 | Like TYPE_APPLICATION_PANEL, but layout of the window happens as that of a top-level window, not as a child of its container |
| TYPE_APPLICATION_MEDIA_OVERLAY | 1004 | Window for showing overlays on top of media windows.These windows are displayed between TYPE_APPLICATION_MEDIA and the application window. They should be translucent to be useful |
| TYPE_APPLICATION_ABOVE_SUB_PANEL | 1005 | a above sub-panel on top of an application window and it’s sub-panel windows |
| LAST_SUB_WINDOW | 1999 | 定义 type 结束值 |
系统窗口（System Windows）
系统窗口，type 取值范围 2000 ~ 2999，是一种优先级比较高的窗口，一般会显示在所有应用的上面，而且不会自动销毁。它们的 Token 为 null，不依赖任何父窗口，在Actiivty、Service 中都可以显示系统窗口。第三方应用默认情况下只允许使用 TYPE_TOAST 类型的系统窗口，设备用户打开权限可以使用更多的系统窗口，但是依然有一部分系统窗口是不允许第三方应用去使用的。
| Name | Value | Purpose |
|---|---|---|
| FIRST_SYSTEM_WINDOW | 2000 | 定义 type 开始值 |
| TYPE_STATUS_BAR | 2000 | 状态栏窗口视图 |
| TYPE_SEARCH_BAR | 2001 | 搜索条 |
| TYPE_PHONE | 2002 | These are non-application windows providing user interaction with the phone (in particular incoming calls). These windows are normally placed above all applications, but behind the status bar. |
| TYPE_SYSTEM_ALERT | 2003 | System window, such as low power alert. These windows are always on top of application windows |
| TYPE_KEYGUARD | 2004 | Keyguard window |
| TYPE_TOAST | 2005 | Transient notifications |
| TYPE_SYSTEM_OVERLAY | 2006 | System overlay windows, which need to be displayed on top of everything else. These windows must not take input focus, or they will interfere with the keyguard. |
| TYPE_PRIORITY_PHONE | 2007 | Priority phone UI, which needs to be displayed even if the keyguard is active. These windows must not take input focus, or they will interfere with the keyguard. |
| TYPE_SYSTEM_DIALOG | 2008 | Panel that slides out from the status bar |
| TYPE_KEYGUARD_DIALOG | 2009 | Dialogs that the keyguard shows |
| TYPE_SYSTEM_ERROR | 2010 | Internal system error windows, appear on top of everything they can. |
| TYPE_INPUT_METHOD | 2011 | Internal input methods windows, which appear above the normal UI. Application windows may be resized or panned to keep the input focus visible while this window is displayed. |
| TYPE_INPUT_METHOD_DIALOG | 2012 | Internal input methods dialog windows |
| TYPE_WALLPAPER | 2013 | Wallpaper window, placed behind any window that wants to sit on top of the wallpaper. |
| TYPE_STATUS_BAR_PANEL | 2014 | Panel that slides out from over the status bar |
| TYPE_SECURE_SYSTEM_OVERLAY | 2015 | Secure system overlay windows, which need to be displayed on top of everything else. |
| TYPE_DRAG | 2016 | the drag-and-drop pseudowindow. There is only one drag layer (at most), and it is placed on top of all other windows. |
| TYPE_STATUS_BAR_SUB_PANEL | 2017 | Panel that slides out from under the status bar |
| TYPE_POINTER | 2018 | (mouse) pointer |
| TYPE_NAVIGATION_BAR | 2019 | Navigation bar (when distinct from status bar) |
| TYPE_VOLUME_OVERLAY | 2020 | The volume level overlay/dialog shown when the user changes the system volume. |
| TYPE_BOOT_PROGRESS | 2021 | The boot progress dialog, goes on top of everything in the world. |
| TYPE_INPUT_CONSUMER | 2022 | Window type to consume input events when the systemUI bars are hidden. |
| TYPE_DREAM | 2023 | Dreams (screen saver) window, just above keyguard. |
| TYPE_NAVIGATION_BAR_PANEL | 2024 | Navigation bar panel (when navigation bar is distinct from status bar) |
| TYPE_DISPLAY_OVERLAY | 2026 | Display overlay window. Used to simulate secondary display devices. |
| TYPE_MAGNIFICATION_OVERLAY | 2027 | Magnification overlay window. Used to highlight the magnified portion of a display when accessibility magnification is enabled |
| TYPE_KEYGUARD_SCRIM | 2029 | keyguard scrim window. Shows if keyguard needs to be restarted. |
| TYPE_PRIVATE_PRESENTATION | 2030 | Window for Presentation on top of private |
| TYPE_VOICE_INTERACTION | 2031 | Windows in the voice interaction layer. |
| TYPE_ACCESSIBILITY_OVERLAY | 2032 | Windows that are overlaid only by a connected AccessibilityService |
| TYPE_VOICE_INTERACTION_STARTING | 2033 | Starting window for voice interaction layer. |
| TYPE_DOCK_DIVIDER | 2034 | Window for displaying a handle used for resizing docked stacks. This window is owned by the system process. |
| TYPE_QS_DIALOG | 2035 | Like TYPE_APPLICATION_ATTACHED_DIALOG, but used by Quick Settings Tiles. |
| TYPE_SCREENSHOT | 2036 | Shares similar characteristics with {@link #TYPE_DREAM}. The layer is reserved for screenshot region selection. |
| TYPE_TOP_MOST | 2037 | Top most |
| LAST_SYSTEM_WINDOW | 2999 | 定义 type 结束值 |
Android 定义的系统窗口类型有点多，满满的一表格。对于第三方应用而言，能够使用那些系统窗口类型呢？我们看看权限检测过程。
switch (type) {
case TYPE_TOAST:
// XXX right now the app process has complete control over
// this... should introduce a token to let the system
// monitor/control what they are doing.
outAppOp[0] = AppOpsManager.OP_TOAST_WINDOW;
break;
case TYPE_DREAM:
case TYPE_INPUT_METHOD:
case TYPE_WALLPAPER:
case TYPE_PRIVATE_PRESENTATION:
case TYPE_VOICE_INTERACTION:
case TYPE_ACCESSIBILITY_OVERLAY:
case TYPE_QS_DIALOG:
/// M: Support IPO window.
case TYPE_TOP_MOST:
// The window manager will check these.
break;
case TYPE_PHONE:
case TYPE_PRIORITY_PHONE:
case TYPE_SYSTEM_ALERT:
case TYPE_SYSTEM_ERROR:
case TYPE_SYSTEM_OVERLAY:
permission = android.Manifest.permission.SYSTEM_ALERT_WINDOW;
break;
default:
permission = android.Manifest.permission.INTERNAL_SYSTEM_WINDOW;
}（代码片段2）代码定义在文件 frameworks/base/services/core/java/com/android/server/policy/PhoneWindowManager.java 中。
如上面的代码，如果 type 是 TYPE_TOAST 的，不需要单独其它任何权限，如果是 TYPE_DREAM TYPE_INPUT_METHOD … TYPE_TOP_MOST 这些类型的窗口，第三方应用不能申请，也需要 app token；TYPE_PHONE … TYPE_SYSTEM_OVERLAY 需要声明权限 android.permission.SYSTEM_ALERT_WINDOW，且设别用户需要在 Settings –> AppInfo 中打开该权限（如下图）。
在实际 App 开发过程中，如果应用检测没有该权限，可以通过如下代码引导用户直接跳到 AppInfo。
Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + packageName));
startActivityForResult(intent, requstCode);（代码片段3）
回到代码片段2，其它类型的系统窗口则需要 android.permission.INTERNAL_SYSTEM_WINDOW 权限，这个权限只有系统签名的应用才能使用这些类型的系统窗口，第三方应用无法使用。
Activity显示View的过程
当系统启动 Activity 时，会先调用 Activity 的 attach() 方法
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, ....., Window window) {
.....
mWindow = new PhoneWindow(this, window);
mWindow.setWindowControllerCallback(this);
mWindow.setCallback(this);
.....
mToken = token;
mIdent = ident;
mApplication = application;
mIntent = intent;
.....
// 设置 WindowMananger 和 AppToken 到 Window 对象
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
.....
}（代码片段4）这个方法定义在文件 frameworks/base/core/java/android/app/Activity.java 中。
如上面的代码，生成一个 PhoneWindow 对象，注意这里的 mWindow.setWindowManager() 方法，该方法会创建一个包含 parentWindow指向 PhoneWindow 的对象的 WindowManagerImpl 实例。
执行完 attach() 方法后，会执行 ActivityThread 的 handleResumeActivity() 方法，如下：
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
ActivityClientRecord r = mActivities.get(token);
.....
r = performResumeActivity(token, clearHide, reason);
.....
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 (a.mVisibleFromClient && !a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l);
}
.....
}（代码片段5）这个方法定义在文件 frameworks/base/core/java/android/app/ActivityThread.java 中。
上面的方法中，先调用 performResumeActivity() 会回调 Activity 的 onResume() 方法，然后设置 Activity 的窗口类型为 TYPE_BASE_APPLICATION，然后把 decor View add 到屏幕显示。我们先来看看 WindowManager.addView() 的过程。
WindowManager addView过程
我们通过 getSystemService() 获取到得 WindowManager 对象，实质是 WindowManagerImpl 的实例，读者可以参考文章《Android System Server大纲之VibratorService 》。在 Activity 中调用 getSystemService(Context.WINDOW_SERVICE) 中获取到 WindowManagerImpl 对象是 Activity 创建时的 attach() 方法中生成的对象实例，持有 parentWindow（Activity 的 PhoneWindow） 对象，在 Service 中通过 getSystemService(Context.WINDOW_SERVICE) 则获取到的是不持有 parentWindow 对象的 WindowManagerImpl 实例。
我们看看 addView() 的过程
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}（代码片段6）这个方法定义在文件 frameworks/base/core/java/android/view/WindowManagerImpl.java 中。
直接调用了 mGlobal 的 addView() 方法
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
.....
final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;
if (parentWindow != null) {
parentWindow.adjustLayoutParamsForSubWindow(wparams);
} else {
.....
}
ViewRootImpl root;
View panelParentView = null;
.....
int index = findViewLocked(view, false);
......
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
// 所有的根View保存到mViews中
mViews.add(view);
// View对应的ViewRootImpl保存到mRoots中
mRoots.add(root);
// View对应的WindowManager.LayoutParams保存到mParams
mParams.add(wparams);
/// M: Add log for tracking mViews.
Log.d("WindowClient", "Add to mViews: " + view + ", this = " + this);
}
// do this last because it fires off messages to start doing things
try {
// 设置 View 的显示到屏幕，这里三个参数中，没有 Window 对象，因此，Window对象在图形显示中没有直接的关系。
root.setView(view, wparams, panelParentView);
} catch (RuntimeException e) {
}
}（代码片段7）这个方法定义在文件 frameworks/base/core/java/android/view/WindowManagerGlobal.java 中。
在上面的方法中，由于 WindowManagerGlobal 是静态单例模式，因此，mViews、mRoots 和 mParams 会保存了应用所有的 View 和 View 相关的 ViewRootImpl 和 WindowManager.LayoutParams。如果是 add Activity 的 View，或者在 Activity 中获取的 WindowManagerImpl 对象，parentWindow 为 Activity 的 PhoneWindow 对象实例，因此会调用 Window.adjustLayoutParamsForSubWindow() 方法
void adjustLayoutParamsForSubWindow(WindowManager.LayoutParams wp) {
CharSequence curTitle = wp.getTitle();
if (wp.type >= WindowManager.LayoutParams.FIRST_SUB_WINDOW &&
wp.type <= WindowManager.LayoutParams.LAST_SUB_WINDOW) {
if (wp.token == null) {
View decor = peekDecorView();
if (decor != null) {
// ViewRootImpl 的 IWindow binder
wp.token = decor.getWindowToken();
}
}
.....
} else if (wp.type >= WindowManager.LayoutParams.FIRST_SYSTEM_WINDOW &&
wp.type <= WindowManager.LayoutParams.LAST_SYSTEM_WINDOW) {
if (curTitle == null || curTitle.length() == 0) {
final StringBuilder title = new StringBuilder(32);
title.append("Sys").append(wp.type);
if (mAppName != null) {
title.append(":").append(mAppName);
}
wp.setTitle(title);
}
} else {
// 设置 App token
if (wp.token == null) {
wp.token = mContainer == null ? mAppToken : mContainer.mAppToken;
}
if ((curTitle == null || curTitle.length() == 0)
&& mAppName != null) {
wp.setTitle(mAppName);
}
}
.....
}（代码片段8）这个方法定义在文件 frameworks/base/core/java/android/view/Window.java 中。
这个方法中，如果窗口的类型是 System Windows，则不设置 WindowManager.LayoutParams.token，即 token = null， 如果是非 Application Windows，非 Sub-Windows，则设置 WindowManager.LayoutParams.token 为 AppToken，mAppToken 在代码片段4中 attach() 方法中调用 setWindowManager() 的时候初始化。如果窗口的类型是 Sub-Windows，则是设置 WindowManager.LayoutParams.token 为 decor.getWindowToken()，decor.getWindowToken() 获取到 token 实例到底是谁呢？
public IBinder getWindowToken() {
// 返回 AttachInfo 的对象 mAttachInfo 持有的 mWindowToken 对象
return mAttachInfo != null ? mAttachInfo.mWindowToken : null;
}（代码片段9）这个方法定义在文件 frameworks/base/core/java/android/view/View.java 中。
继续看 mAttachInfo 的初始化过程
// 设置时间处理机制
AttachInfo(IWindowSession session, IWindow window, Display display,
ViewRootImpl viewRootImpl, Handler handler, Callbacks effectPlayer) {
mSession = session;
mWindow = window;
// 初始化 mWindowToken
mWindowToken = window.asBinder();
mDisplay = display;
mViewRootImpl = viewRootImpl;
mHandler = handler;
mRootCallbacks = effectPlayer;
}（代码片段10）这个方法定义在文件 frameworks/base/core/java/android/view/View.java 中。
mWindowToken 通过 window.asBinder() 初始化，window 是传过来的参数，继续看 AttachInfo 实例化的地方
public ViewRootImpl(Context context, Display display) {
mContext = context;
mWindowSession = WindowManagerGlobal.getWindowSession();
// 初始化 mWindow
mWindow = new W(this);
.....
// 初始化 View 的 AttachInfo，传入 mWindow 对象
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this);
.....
}（代码片段11）这个方法定义在文件 frameworks/base/core/java/android/view/ViewRootImpl.java 中。
AttachInfo 的初始化是在 ViewRootImpl 初始化的时候完成，ViewRootImpl 的实例化的地方在代码片段7中。mWindow 是 W 的实例，W 的定义如下：
static class W extends IWindow.Stub {}（代码片段12）这个方法定义在文件 frameworks/base/core/java/android/view/ViewRootImpl.java 中。
回到代码片段8，当窗口类型是 Sub-Windows 时，WindowManager.LayoutParams.token 实际指向 ViewRootImpl 持有的对象 mWindow 的 Binder 句柄 IBinder。
因此，当窗口类型是 Application Windows 时，token = AppToken，当窗口类型是 Sub-Windows 时，token = mWindowToken，当窗口类型是 System Windows 时，token = null。因为 token 的值不同，确定了不同类型的窗口不同的显示规则和销毁过程。单从这点出发，在 Service 中不能创建类型为非 System Windows 的窗口，所以 Service 中不能随意添加视图。
接着代码片段7，继续往下看 ViewRootImpl.setView() 方法
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
mView = view;
.....
attrs = mWindowAttributes;
setTag();
.....
requestLayout();
.....
try {
mOrigWindowType = mWindowAttributes.type;
mAttachInfo.mRecomputeGlobalAttributes = true;
collectViewAttributes();
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(),
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mInputChannel);
} catch (RemoteException e) {}
.....
// 事件处理
if (mInputChannel != null) {
if (mInputQueueCallback != null) {
mInputQueue = new InputQueue();
mInputQueueCallback.onInputQueueCreated(mInputQueue);
}
mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,
Looper.myLooper());
}
.....
}
}
}（代码片段13）这个方法定义在文件 frameworks/base/core/java/android/view/ViewRootImpl.java 中。
首先调用 requestLayout() 对 View 进行绘制，这个过程就会调用 View 的三大著名方法， measure()、layout() 和 draw()， 如下：
private void performTraversals() {
.....
// 计算 View 大小
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
int width = host.getMeasuredWidth();
int height = host.getMeasuredHeight();
.....
// 定位 View 位置
performLayout(lp, mWidth, mHeight);
.....
// 在画布上绘制 View
performDraw();
.....
}（代码片段14）这个方法定义在文件 frameworks/base/core/java/android/view/ViewRootImpl.java 中。
回到代码片段13，View 绘制完成后，调用 IWindowSession.addToDisplay() 方法，最终会调用到 WindowManagerService 的 addWindow() 方法
public int addWindow(Session session, IWindow client, int seq,
WindowManager.LayoutParams attrs, int viewVisibility, int displayId,
Rect outContentInsets, Rect outStableInsets, Rect outOutsets,
InputChannel outInputChannel) {
WindowToken token = mTokenMap.get(attrs.token);
AppWindowToken atoken = null;
// 实例化 WindowState， WindowState 可以对不同类型的窗口的显示位置进行控制
WindowState win = new WindowState(this, session, client, token,
attachedWindow, appOp[0], seq, attrs, viewVisibility, displayContent);
mPolicy.adjustWindowParamsLw(win.mAttrs);
win.setShowToOwnerOnlyLocked(mPolicy.checkShowToOwnerOnly(attrs));
res = mPolicy.prepareAddWindowLw(win, attrs);
// 计算窗口的层次关系
addWindowToListInOrderLocked(win, true);
.....
}（代码片段15）这个方法定义在文件 frameworks/base/services/core/java/com/android/server/wm/WindowManagerService.java 中。
在 WindowState 中持有两个变量 mSubLayer 和 mBaseLayer，这两个变量在 addWindowToListInOrderLocked() 方法中计算出具体的值，者两个值对应 Android 系统中 View 渲染框架 SurfaceFlinger 中的 Layer。在 View 的位置确认中，有水平面的 x/y 轴以外，还有立体的 z轴，z 轴对应 SurfaceFlinger 中的 Layer，也就是 mSubLayer 和 mBaseLayer，从而确定了不同窗口类型显示的层次不同。
Add View时序图
窗口视图的销毁
当我们推出 Activity 的时候，针对 Applicaton Windows、Sub-Windows 和 System Windows 如何销毁？我们来看一下这个处理过程。Activity 销毁时，AMS 先调用了 ActivityThread 的 handleDestroyActivity() 方法
private void handleDestroyActivity(IBinder token, boolean finishing,
int configChanges, boolean getNonConfigInstance) {
ActivityClientRecord r = performDestroyActivity(token, finishing,
configChanges, getNonConfigInstance);
WindowManager wm = r.activity.getWindowManager();
// Docor View
View v = r.activity.mDecor;
if (v != null) {
.....、
// ViewRootImpl 的 mWindow 的 Binder 句柄
IBinder wtoken = v.getWindowToken();
if (r.activity.mWindowAdded) {
if (r.mPreserveWindow) {
.....
} else {
// 移除 Decor View
wm.removeViewImmediate(v);
}
}
if (wtoken != null && r.mPendingRemoveWindow == null) {
// 移除依附在 ViewRootImpl 的 mWindow 的 Binder 句柄 mWindowToken 的 View
WindowManagerGlobal.getInstance().closeAll(wtoken,
r.activity.getClass().getName(), "Activity");
} else if (r.mPendingRemoveWindow != null) {
WindowManagerGlobal.getInstance().closeAllExceptView(token, v,
r.activity.getClass().getName(), "Activity");
}
r.activity.mDecor = null;
}
if (r.mPendingRemoveWindow == null) {
// 移除依附在 AppToken 的 View
WindowManagerGlobal.getInstance().closeAll(token,
r.activity.getClass().getName(), "Activity");
}
}（代码片段16）这个方法定义在文件 frameworks/base/core/java/android/app/ActivityThread.java 中。
如上面的代码，v.getWindowToken() 获取到 ViewRootImpl 的持有的变量 mWindow 的 Binder 句柄 mWindowToken，窗口类型为 Sub-Windows 的使用该 token。然后先调用 wm.removeViewImmediate(v) 移除 Decor View，等于 Activity 的 View 被移除了，然后移除 Sub-Windows 类型的 View，接着移除使用 AppToken 类型为 Application Windows 的 View，我们往下看 closeAll() 的过程
public void closeAll(IBinder token, String who, String what) {
// 直接调用了 closeAllExceptView()
closeAllExceptView(token, null /* view */, who, what);
}
public void closeAllExceptView(IBinder token, View view, String who, String what) {
synchronized (mLock) {
int count = mViews.size();
for (int i = 0; i < count; i++) {
// 在closeAll()中传递过来的 view 就是 null， 所以(view == null || mViews.get(i) != view) = true，
// 第一次传递过来的是 mWindowToken， 第二次传递过来的是 AppToken，
// 所以 token == null = false，所以这里只看 mParams.get(i).token == token，
// 对于 Application Windows 和 Sub-Windows，mParams.get(i).token == token = true，
// 对于 System Windows， mParams.get(i).token == token = false，
// 所以，Activity 推出时，System Windows 不会销毁，非 System Windows 被销毁
if ((view == null || mViews.get(i) != view)
&& (token == null || mParams.get(i).token == token)) {
ViewRootImpl root = mRoots.get(i);
if (who != null) {
WindowLeaked leak = new WindowLeaked(
what + " " + who + " has leaked window "
+ root.getView() + " that was originally added here");
leak.setStackTrace(root.getLocation().getStackTrace());
Log.e(TAG, "", leak);
}
removeViewLocked(i, false);
}
}
}
}（代码片段16）这个方法定义在文件 frameworks/base/core/java/android/view/WindowManagerGlobal.java 中。
上面的方法中，首先获取到应用所有的 View（根View） 的数量，然后一个逐一遍历，通过一个条件判断，如果成立，调用 removeViewLocked() 移除 View。具体逻辑判断看代码中的注释。
View移除时序图
升级Dialog窗口类型
我们看 Dialog 初始化是的窗口类型
// 实例化 WindowManager.LayoutParams
private final WindowManager.LayoutParams mWindowAttributes =
new WindowManager.LayoutParams();（代码片段17）这个变量定义在文件 frameworks/base/core/java/android/view/Window.java 中。
public LayoutParams() {
super(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT);
// 默认窗口类型 type 为 TYPE_APPLICATION
type = TYPE_APPLICATION;
format = PixelFormat.OPAQUE;
}（代码片段18）这个方法定义在文件 frameworks/base/core/java/android/view/WindowManager.java 中。
我们可以通过如下方法，把 Dialog 的窗口类型升级，如下：
Dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);（代码片段19）这个方法定义在文件 frameworks/base/core/java/android/app/Dialog.java 中。
升级 Dialog 的窗口类型为 System Windows，当 Activity 销毁时，Dialog 就不会被销毁。
升级PopupWindow窗口类型
先看看默认情况下 PopupWindow 的窗口类型
// 默认使用 TYPE_APPLICATION_PANEL 的 Sub-Windows，
// 默认使用调用显示是传递进来的 View 的 mWindowToken
private int mWindowLayoutType = WindowManager.LayoutParams.TYPE_APPLICATION_PANEL;（代码片段20）这个变量定义在文件 frameworks/base/core/java/android/widget/PopupWindow.java 中。
private WindowManager.LayoutParams createPopupLayoutParams(IBinder token) {
final WindowManager.LayoutParams p = new WindowManager.LayoutParams();
.....
p.flags = computeFlags(p.flags);
// 设置窗口类型
p.type = mWindowLayoutType;
p.token = token;
.....
return p;
}（代码片段21）这个方法定义在文件 frameworks/base/core/java/android/widget/PopupWindow.java 中。
可以通过调用 PopupWindow 的 setWindowLayoutType() 方法改变窗口类型
// API 23 才添加的方法
public void setWindowLayoutType(int layoutType) {
mWindowLayoutType = layoutType;
}（代码片段22）这个方法定义在文件 frameworks/base/core/java/android/widget/PopupWindow.java 中。
升级 Activity 窗口类型
是否可以升级 Activity 的窗口类型？不能，就算你调用了 getWindow().setType() 方法，改变了窗口类型，也不会生效。因为在 handleResumeActivity() 方法中显示 Decor View 时，强制改变了窗口类型
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
ActivityClientRecord r = mActivities.get(token);
.....
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
// 强制转换类型为 TYPE_BASE_APPLICATION
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
.....
if (a.mVisibleFromClient && !a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l);
}（代码片段23）这个方法定义在文件 frameworks/base/core/java/android/app/ActivityThread.java 中。
总结
在本文中，我们认识了 Android 定义的 Application Windows、Sub-windows 和 System Windows 三大类型的窗口类型，不同的窗口类型在界面的显示框架 SurfaceFlinger 中，对应不同的 Layer，从而有一个 Z 轴的定义。Activity 的 DecorView 所对应的窗口类型为 WindowManager.LayoutParams.TYPE_BASE_APPLICATION，不能改变。Dialog 默认的窗口类型则是 WindowManager.LayoutParams.TYPE_APPLICATION，可以通过 Dialog.getWindow().setType() 改变；PopupWindow 默认定义的窗口类型为 WindowManager.LayoutParams.TYPE_APPLICATION_PANEL，可以通过 PopupWindow.setWindowLayoutType() 改变窗口类型，但是这是 Android API 23 才添加的方法。
不同的窗口类型的销毁过程不同，和一个 View 共用相同的 mWindowToken 的窗口，当这个 View 被销毁时，对应的窗口也会被销毁；当 Activity 销毁时，和 Activity 共用 AppToken 和 mWindowToken 的窗口也会同时被销毁。在 Service 中，只能显示系统类型的窗口，而且是某些不用指定 Token 的系统窗口。在显示框架中，没有 Window 的概念，只有 View 的概念，所以 Window 只是 View 的呈现的一个抽象，确定 View 呈现样式的一个通道。
扫一扫
197
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
