Activity的Window创建和添加过程-源码分析

之前介绍过Activity的启动过程，一直讲到了Actiivty的oCreate方法执行，Activity的启动过程完成。本文就顺着启动过程的完成，介绍下Activity的Window创建和添加的过程。为什么讲这个呢，因为Activity启动过程完成到onCreate方法的执行，Activity的页面还没有显示出来，而Activity的页面布局的显示，就是由Window、WIndowManager和WindowManager这一套机制来管理的，也就是通常说的WMS机制。
在Android系统中，一个Activity通常就表示一个页面，而这个页面实际是听过Window来管理和显示的。所以每个Activity都对应着一个Window。Window是一个抽象类，具体实现类是PhoneWindow，它对View进行管理。确切的来讲是，PhoneWindow包含一个DecorView类型的成员，它代表这个Window的顶层View，是一个FrameLayout。DecorView的布局结构包含两部分：标题栏（title）和内容栏（content）。根据设置的主题不同，这两部分也会有不同的呈现。但内容栏是一定存在的，并且它的id是固定的，完整id都是android.R.id.content。

需要说明一下：本文的源码分析是基于Android 8.0版本，也就是API Level26的源码。

Window的创建过程

熟悉Activity启动过程的同学应该都记得，在ActivityThread的performLaunchActivity方法，会调用Activity的attach方法。与Activity相关联的Window对象就是在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) {
    attachBaseContext(context);
    ...
    mWindow = new PhoneWindow(this, window, activityConfigCallback);
    mWindow.setWindowControllerCallback(this);
    mWindow.setCallback(this);
    mWindow.setOnWindowDismissedCallback(this);
    mWindow.getLayoutInflater().setPrivateFactory(this);
    if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
        mWindow.setSoftInputMode(info.softInputMode);
    }
    if (info.uiOptions != 0) {
        mWindow.setUiOptions(info.uiOptions);
    }
    ...
    mWindow.setWindowManager(
            (WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
            mToken, mComponent.flattenToString(),
            (info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
     ...

    mWindow.setColorMode(info.colorMode);
}

可以看到，在attach方法中创建了一个PhoneWindow对象，并为它设置回调接口Callback和WindowManager。由于Activity类实现了Window.Callback接口，因此当Window接收到相关的事件触发时就会调用Activity的相应方法。Callback接口中的方法很多，有几个是我们比较常见的，比如dispatchTouchEvent、onAttachedToWindow、onDetachedFromWindow等。

Window的添加过程

上面已经介绍了Activity关联的Window对象是在什么时候创建的，接下来，我们看看Activity的Window的添加过程。
在日常开发中，我们都会在Activity的onCreate方法中，通过setContentView来给Activity设置视图布局，来指定页面显示什么内容。
我们需要先看看ActivityThread的performLaunchActivity方法

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
        ...
        activity.attach(appContext, this, getInstrumentation(), r.token,
                        r.ident, app, r.intent, r.activityInfo, title, r.parent,
                        r.embeddedID, r.lastNonConfigurationInstances, config,
                        r.referrer, r.voiceInteractor, window, r.configCallback);
        ...
        if (r.isPersistable()) {
                    mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
                } else {
                    mInstrumentation.callActivityOnCreate(activity, r.state);
                }
}

在Activity的attach方法返回后，程序会调用mInstrumentation.callActivityOnCreate方法，而这个方法最终会触发Activity的onCreate回调。而在onCreate中，会调用setContentView方法，开始Activity的Window添加过程。

public void setContentView(@LayoutRes int layoutResID) {
    getWindow().setContentView(layoutResID);
    initWindowDecorActionBar();
}

Activity的setContentView方法内部调用的mWindow的setContentView方法，这个mWindow对象就是在attach方法中创建的PhoneWindow对象。所以，接下来要看到PhoneWindow的setContentView方法

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);
    }
    mContentParent.requestApplyInsets();
    final Callback cb = getCallback();
    if (cb != null && !isDestroyed()) {
        cb.onContentChanged();
    }
    mContentParentExplicitlySet = true;
}

PhoneWindow的setContentView中，首先判断mContentParent是否存在，否则调用installDecor方法。这个mContentParent指的就是DecorView的内容栏。它的赋值就只有一个地方，就是在installDecor方法中。

private void installDecor() {
    mForceDecorInstall = false;
    if (mDecor == null) {
        mDecor = generateDecor(-1);
        mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
        mDecor.setIsRootNamespace(true);
        if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
            mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
        }
    } else {
        mDecor.setWindow(this);
    }
    if (mContentParent == null) {
        mContentParent = generateLayout(mDecor);
    ...
}

如果mDecor为null，就先调用generateDecor方法创建DecorView

protected DecorView generateDecor(int featureId) {
    ...
    return new DecorView(context, featureId, this, getAttributes());
}

DecorView对象创建之后，再判断mContentParent对象是否存在，否则调用generateLayout方法

protected ViewGroup generateLayout(DecorView decor) {
    ...
    ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
    ...
    return contentParent;
}

generateLayout方法的代码很多，我们先只关注相关的重点，generateLayout最后会返回一个ViewGroup对象contentParent，而contentParent的id是ID_ANDROID_CONTENT，它的值就是com.android.internal.R.id.content。这就是DecorView的内容栏id为android.R.id.content的由来，也是Actvity的SetContentView方法名的由来。
现在回头看到PhoneWindow的setContentView方法，调用installDecor方法，创建好DecorView和mContentParent之后，会调用 mLayoutInflater.inflate(layoutResID, mContentParent)，将Activity的布局视图添加到mContentParent中。然后回调Activity的onContentChanged方法通知Activity，视图已经发生改变。
以上就是，Activity的视图布局已经添加到DecorView的过程。这个过程是在Activity的onCreate方法中完成的。但这个时候，Activity的视图布局还没有显示出来。这是因为，DecorView还没有被WindowManager正式添加到窗口中。这里说的窗口，并不是指WIndow和它的子类PhoneWindw，而是一个抽象的概念。窗口更多表示的是一种抽象的功能集合。虽然在Activity的attach方法中，WIndow对象就已经被创建了，但这个时候由于DecorView并没有被WindowManager识别，所以此时的WIndow无法提供具体功能，因为它还无法接受外界的输入信息。我们知道，在Activity执行onResume方法之后，视图才能完全显示，并和用户正常交互，那onResume方法是在什么地方回调了呢，熟悉Activity启动过程的同学，应该会有印象，在ActivityThread的handleLaunchActivity方法中，

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
    ...
    Activity a = performLaunchActivity(r, customIntent);
    if (a != null) {
    r.createdConfig = new Configuration(mConfiguration);
    reportSizeConfigurations(r);
    Bundle oldState = r.state;
    handleResumeActivity(r.token, false, r.isForward,
            !r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
    ...
}

执行完performLaunchActivity方法返回一个Activity的实例，接下来判断如果创建的Activity实例不为null，就会执行handleResumeActivity方法

final void handleResumeActivity(IBinder token,
        boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
    ...
    r = performResumeActivity(token, clearHide, reason);
    if (r != null) {
        final Activity a = r.activity;
        ...
        if (r.activity.mVisibleFromClient) {
            r.activity.makeVisible();
        }
    ...
}

在handleResumeActivity方法中，会调用performResumeActivity方法，这个方法中又经过层层调用，最终会回调Activity的onResume方法。这就是Activity的onResume方法的回调时机。这里不是本文的重点，就没有列出相关的源码。
handleResumeActivity中，在performResumeActivity方法执行之后，会调用Activity的makeVisible方法

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

在makeVisible方法中，会调用WindowManager的addView方法，将DecorView正式添加到窗口中。同时DecorView设置为可见。
这里先介绍下WindowManager，它是一个接口，继承自ViewManager。从ViewManager接口继承了三个方法addView、updateViewLayout和removeView。这三个方法都与窗口管理直接相关。WindowManager的实现类的WindowManagerImpl。所以Activity的makeVisible方法中，调用的实际上是WindowManagerImpl的addView方法

@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
    applyDefaultToken(params);
    mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}

在WindowManagerImpl的addView方法内部，调用的是WindowManagerGlobal的addView方法。WindowManagerImpl通过桥接模式，将功能实现委托给了WindowManagerGlobal。WindowManagerGlobal是一个单例，说明一个进程中只有一个WindowManagerGlobal实例。而每一个Window都会有一个相关联的WindowManagerImpl实例。WindowManagerGlobal的addView方法如下：

public void addView(View view, ViewGroup.LayoutParams params,
        Display display, Window parentWindow) {
    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 {
        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;
    ...
        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 (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);
        try {
            root.setView(view, wparams, panelParentView);
        } catch (RuntimeException e) {
            // BadTokenException or InvalidDisplayException, clean up.
            if (index >= 0) {
                removeViewLocked(index, true);
            }
            throw e;
        }
    }
}

WindowManagerGlobal的addView方法主要完成三个步骤：

1. 检查参数是否合法，如果是子Window还需要调整一些布局参数
2. 创建ViewRootImpl，并将传进来的View添加到mViews列表里
3. 通过ViewRootImpl来更新界面并完成WIndow的添加过程。

上来的代码中，涉及到WindowManagerGlobal类几个重要的列表

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>();
private final ArraySet<View> mDyingViews = new ArraySet<View>();

简单说明一下，mViews存放的是所有窗口所对应的View，比如Activity的窗口所对应的DecorView。mRoots存放的是所有窗口所对应的ViewRootImpl对象。mParams存放的是所有窗口所对应的布局参数。而在这三个列表中，索引值相同的一组View、ViewRootImpl和LayoutParam对象，可以看做是一个窗口的概念。mDyingViews则存储了正在被删除的View，或者说是那些已经调用了removeView方法但删除操作还没有完成的Window对象。
View和LayoutParams应该都不会陌生，关于ViewRootImpl，熟悉View绘制机制的同学，也会对它有印象。通俗的说法是，一个页面的绘制流程，就是从ViewRootImpl开始。而实际上ViewRootImpl承担的职责包括以下几点：

• 作为View层级(View hierarchy)的顶层(top-level)管理View层级
• 触发View的测量、布局和绘制
• 输入事件的中转站
• 负责与WMS进程间通信
  介绍完WindowManagerGlobal中这几个重要的列表之后，我们接着看addView方法。将View、ViewRootImpl和LayoutParams对象分别添加到列表之后，会调用ViewRootImpl的setView方法

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    ...
    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);
    ...
}

setView方法的代码很多，本文中暂时只关注两点。
调用requestLayout方法会触发View层级的绘制遍历。这个对于了解View的绘制过程的同学肯定不陌生。简单介绍下，requestLayout方法内部会调用scheduleTraversals方法。scheduleTraversals方法实际上就是View绘制过程的入口。
然后会调用mWindowSession对象的addToDisplay方法，mWindowSession的类型是IWindowSession，它是一个Binder对象，用于进程间通信，IWindowSession是Client端的代理。它的Server端实现是Session。此前的代码都是运行在Actiivty所在的app进程，而Session的addToDisplay方法则是运行在WMS所在的SystemServer进程中。

image.png

从上图中可以看出，app进程中的ViewRootImpl对象要想与WMS进行通信需要进过Session，确切的说，通过调用Session的addToDisplay方法

@Override
public int addToDisplay(IWindow window, int seq, WindowManager.LayoutParams attrs,
        int viewVisibility, int displayId, Rect outContentInsets, Rect outStableInsets,
        Rect outOutsets, InputChannel outInputChannel) {
    return mService.addWindow(this, window, seq, attrs, viewVisibility, displayId,
            outContentInsets, outStableInsets, outOutsets, outInputChannel);
}

addToDisplay方法内部，直接调用了mService的addWindow方法，并将Session对象本身作为第一个参数传进去。这个mService就是WMS的实例。每一个app进程都会对应一个Session对象，它用来表示app进程与WMS的通信渠道。WMS会用ArrayList来存放这些Session对象。接下来的工作就交给WMS来处理。WMS会为这个要添加的窗口分配Surface，并确定窗口的显示次序，而真正负责显示界面视图的是画布Surface，而不是窗口本身。WMS会将它所管理的Surface交由SurfaceFlinger处理，SurfaceFlinger会将这些Surface混合并绘制到屏幕上。
WindowManagerService的addWindow方法代码非常多，有兴趣的同学可以自行查看源码。这里只是概括性的介绍addWindow方法中主要做了四件事：

• 对要添加的窗口进行检查，确保窗口和一些参数满足条件，否则就直接返回相应的提示信息，不再往下执行。
• WindowToken的相关处理，比如有的窗口类型需要提供WindowToken，没有提供的话也会直接返回相应的提示信息，不再往下执行。有的窗口类型需要由WMS隐式创建WindowToken。
• WindowState的创建和相关处理，将WIndowToken和WindowState相关联。
• 创建和配置DisplayContent，完成窗口添加到系统前的准备工作。

关于WindowToken
要了解WindowToken，首先要了解ActivityRecord的内部类Token，它继承自IApplicationToken.Stub。很明显，它是基于Binder机制。Binder除了用于跨进程通信之外，另一个用途就是在多个进程中标识同一个对象，这里的Token主要是用于后者。一个Token对象（ActivityRecord的成员变量appToken）标识了一个ActivityRecord对象。而WindowToken中，IBinder类型token对象标识的也是ActivityRecord中的这个Token对象appToken。有兴趣的朋友可以由此去了解。

关于Surface、Window和View概念的理解
以下是由安卓framework开发者Dianne Hackborn在stackoverflow给出的关于Window和View的定义，由此可以更好的理解WIndow和View的关系
A Surface is an object holding pixels that are being composited to the screen. Every window you see on the screen (a dialog, your full-screen activity, the status bar) has its own surface that it draws in to, and Surface Flinger renders these to the final display in their correct Z-order. A surface typically has more than one buffer (usually two) to do double-buffered rendering: the application can be drawing its next UI state while the surface flinger is compositing the screen using the last buffer, without needing to wait for the application to finish drawing.
A window is basically like you think of a window on the desktop. It has a single Surface in which the contents of the window is rendered. An application interacts with the Window Manager to create windows; the Window Manager creates a Surface for each window and gives it to the application for drawing. The application can draw whatever it wants in the Surface; to the Window Manager it is just an opaque rectangle.
A View is an interactive UI element inside of a window. A window has a single view hierarchy attached to it, which provides all of the behavior of the window. Whenever the window needs to be redrawn (such as because a view has invalidated itself), this is done into the window's Surface. The Surface is locked, which returns a Canvas that can be used to draw into it. A draw traversal is done down the hierarchy, handing the Canvas down for each view to draw its part of the UI. Once done, the Surface is unlocked and posted so that the just drawn buffer is swapped to the foreground to then be composited to the screen by Surface Flinger.

到此，本文对Activity的Window创建和添加过程分析就讲到这里。