“一文读懂”系列：无处不在的WMS

小余的自习室

已于 2022-12-03 15:07:07 修改

阅读量557

点赞数

分类专栏： framework 文章标签： android 架构

于 2022-12-03 14:03:21 首次发布

本文链接：https://blog.csdn.net/yuhaibing111/article/details/128161009

版权

framework 专栏收录该内容

6 篇文章 1 订阅

订阅专栏

前言：

[前一篇文章]介绍了关于Android中Window体系的介绍，主要介绍的是View层的Window体系概念，但是想要深入了解Window在系统中的机制，WMS是绕不过去的坎。有句话说的好：AMS和WMS占据了Framework层的半壁江山，所以了解这两个概念对我们在日常开发中的性能优化或有想转Framework开发的都大有帮助。

笔者花了几天时间对WMS相关知识进行了整理。

首先我们来说下WMS在系统中的几大职责

WMS中窗口容器树的概念

为了更好的讲解个个核心成员类，我们需要先来理清Window中的容器和树的概念。

容器：这个大家都熟悉，在WMS中通过继承WindowContainer类来实现容器机制：

而树就是说每个容器在作为父容器的时候，同时也可能是其他容器的子容器。

具体我们来看WindowContainer整体结构：

class WindowContainer<E extends WindowContainer> implements Comparable<WindowContainer> {
    ...
    private WindowContainer mParent = null;//1
    protected final WindowList<E> mChildren = new WindowList<E>();//2
    
}

注释1处mParent是当前WindowContainer容器的父容器

注释2处的mChildren是一个继承WindowContainer的集合对象，说明当前WindowContainer可能会有好几个子容器。

画个图来说明下这里面的关系：

有了容器的概念后下面按职责来介绍WMS

窗口管理：

窗口管理核心类介绍：

窗口管理使用到的DisplayContent，WindowToken和WindowState

DisplayContent：

用来管理一个逻辑屏上的所有窗口，有几个屏幕就会有几个DisplayContent。使用displayId来区分。

处于不同DisplayContent的两个窗口在布局、显示顺序以及动画处理上不会产生任何耦合。 因此，就这几个方面来说，DisplayContent就像一个孤岛，所有这些操作都可以在其内部独立执行。

DisplayContent类声明：

class DisplayContent extends WindowContainer<DisplayContent.DisplayChildWindowContainer>{
    // Mapping from a token IBinder to a WindowToken object on this display.
    private final HashMap<IBinder, WindowToken> mTokenMap = new HashMap();
}

1.DisplayContent的子容器是其内部类DisplayChildWindowContainer

2.DisplayContent内部使用：IBinder为key，WindowToken为value的键值对保存在HashMap中。

3.DisplayContent是在Window添加到WMS的时候初始化的：

WMS：

public int addWindow(Session session, ..){
    final DisplayContent displayContent = mRoot.getDisplayContentOrCreate(displayId);
    ..
}

mRoot是RootWindowContainer类型的对象，看名字就知道其是窗口容器的根。说明在Window体系中，RootWindowContainer节点是容器最顶端的父容器。

class RootWindowContainer extends WindowContainer<DisplayContent> {
    DisplayContent getDisplayContentOrCreate(int displayId) {
        DisplayContent dc = getDisplayContent(displayId);
        if (dc == null) {
            final Display display = mService.mDisplayManager.getDisplay(displayId);
            if (display != null) {              
                dc = createDisplayContent(display);         
            }
        }
        return dc;
    }

   DisplayContent getDisplayContent(int displayId) {
      for (int i = mChildren.size() - 1; i >= 0; --i) {
          final DisplayContent current = mChildren.get(i);
           if (current.getDisplayId() == displayId) {
              return current;
           }
      }
      return null;
  }
}

其继承了WindowContainer，这里的DisplayContent是一个泛型声明，表示其子容器的类型是DisplayContent， 在getDisplayContent方法中也可知，其mChildren列表是DisplayContent的集合。这也变相的说明DisplayContent也是一个容器

WindowToken：

类声明：

class WindowToken extends WindowContainer<WindowState>

表明WindowToken也是子容器，其子容器是WindowState，所以WindowState也是一个容器。

WindowToken在窗口体系中有两个作用：

1.应用组件标识：将属于同一个应用组件的窗口组织在一起，这里的应用组件可以是：Activity、InputMethod、Wallpaper以及Dream。 WMS在对窗口的管理过程中：用WindowToken来指代一个应用组件。例如在进行窗口的Z-Order排序时，属于同一个WindowToken的窗口会被安排在一起。
2.令牌作用：WindowToken由应用组件或其管理者负责向WMS声明并持有，应用组件在需要更新窗口时，需要向WMS提供令牌表明自己的身份，并且窗口的类型必须与所持有的WindowToken的类型一致。

但是系统窗口是个例外，并不需要提供token，WMS会隐式声明一个WindowToken。

那是不是说谁都可以添加系统窗口了呢？非也，在addWindow开始处就会调用下面代码：

mPolicy.checkAddPermission()

它要求客户端必须拥有SYSTEM_ALERT_WINDOW或INTERNAL_SYSTEM_WINDOW权限才能创建系统类型的窗口。

Window和WindowToken关系如下：

WindowState：

类声明：

class WindowState extends WindowContainer<WindowState>

表明WindowState也是一个WindowContainer容器，但是其子容器也是WindowState，一般窗口有子窗口SUB_WINDOW的情况下，WindowState才有子容器节点。

WindowState在WMS中表示一个Window窗口状态属性，其内部保存了一个Window所有的属性信息。

其与View以及WindowToken关系如下：

如何查看当前设备Window窗口状态命令？

adb shell dumpsys window windows

Window #9 Window{884cb45 u0 com.android.messaging/com.android.messaging.ui.conversationlist.ConversationListActivity}:
    mDisplayId=0 stackId=3 mSession=Session{f1b7b8e 4307:u0a10065} mClient=android.os.BinderProxy@a512fbc
    mOwnerUid=10065 mShowToOwnerOnly=true package=com.android.messaging appop=NONE
    mAttrs={(0,36)(828xwrap) gr=BOTTOM CENTER sim={adjust=pan forwardNavigation} ty=APPLICATION fmt=TRANSLUCENT wanim=0x7f130015
      fl=DIM_BEHIND ALT_FOCUSABLE_IM HARDWARE_ACCELERATED
      vsysui=LIGHT_STATUS_BAR LIGHT_NAVIGATION_BAR}
    Requested w=828 h=290 mLayoutSeq=220
    mBaseLayer=21000 mSubLayer=0    mToken=AppWindowToken{3f9efb8 token=Token{2b272cc ActivityRecord{55a41e u0 com.android.messaging/.ui.conversationlist.ConversationListActivity t8}}}
    mAppToken=AppWindowToken{3f9efb8 token=Token{2b272cc ActivityRecord{55a41e u0 com.android.messaging/.ui.conversationlist.ConversationListActivity t8}}}
...

下面笔者以窗口的添加操作为例讲解WMS的窗口管理

窗口的添加操作

public int addWindow(Session session, IWindow client, int seq,
        WindowManager.LayoutParams attrs, int viewVisibility, int displayId,
        Rect outContentInsets, Rect outStableInsets, Rect outOutsets,
        InputChannel outInputChannel) {
    ...
    int res = mPolicy.checkAddPermission(attrs, appOp);//1
    ...
    synchronized(mWindowMap) {
        

        final DisplayContent displayContent = mRoot.getDisplayContentOrCreate(displayId);//2
        
        if (type >= FIRST_SUB_WINDOW && type <= LAST_SUB_WINDOW) {
            parentWindow = windowForClientLocked(null, attrs.token, false);//3
            
        }
        ...            
        WindowToken token = displayContent.getWindowToken(
                hasParent ? parentWindow.mAttrs.token : attrs.token);//4
       
        if (token == null) {                              
            final IBinder binder = attrs.token != null ? attrs.token : client.asBinder();
            token = new WindowToken(this, binder, type, false, displayContent,
                    session.mCanAddInternalSystemWindow);//5
        } 
        ...
        final WindowState win = new WindowState(this, session, client, token, parentWindow,
                appOp[0], seq, attrs, viewVisibility, session.mUid,
                session.mCanAddInternalSystemWindow);//6
        ...
        mPolicy.adjustWindowParamsLw(win.mAttrs);//7
        ...
        if  (openInputChannels) {
            win.openInputChannel(outInputChannel);//8
        }
        ...
        mWindowMap.put(client.asBinder(), win);//9
        ...
        win.mToken.addWindow(win);//10
        ...
        displayContent.assignWindowLayers(false /* setLayoutNeeded */);//11
        
        //12
        if (focusChanged) {
            mInputMonitor.setInputFocusLw(mCurrentFocus, false /*updateInputWindows*/);
        }
        mInputMonitor.updateInputWindowsLw(false /*force*/);
       
    }
    ...
    return res;

}

注释1：检查当前Window的token等权限合法性

注释2：这在介绍DisplayContent已经说过，使用RootWindowContainer的子容器中获取一个DisplayContent，如果子容器集合中不存在，则去获取一个，并添加到child集合中

注释3：如果是Dialog等子窗口，则获取父窗口，没有就报找不到父窗口的异常。

注释4：使用attr.token去displayContent的键值对mTokenMap中获取对应的WindowToken，WindowToken中保存了一组Window。

注释5：如果4中WindowToken为null，则创建一个WindowToken，传入app层传入的attr.token以及displayContent对象，内部会将这个创建的WindowToken保存到displayContent中

注释6：创建一个WindowState，并传入所有关于Window相关的属性，这样WindowState在WMS中就是以一个Window性质存在了、WindowState构造过程中会将其添加到WindowToken中去。

注释7：根据mPolicy调整window的attr属性，mPolicy的实现类是PhoneManagerPolicy。

注释8：执行WindowState的openInputChannel，这里主要是打通和Input系统的通道，用于接收IMS的输入事件请求。

注释9：将客户端app层的Window对象和WindowState关联上，这样WMS就可以通过Window找到WMS中的WindowState对象、

注释10： win.mToken是前面创建的WindowToken对象，所以此处就是将WindowState加入到WindowToken的子容器集合中。

注释11：分配窗口的层级，这里的setLayoutNeeded参数为false，说明不需要进行Layout操作。

这里小结下addWindow方法： 主要就是创建了一个和Window一一对应的WindowState对象，并将WindowState插入到父容器WindowToken的子容器集合中，而WindowToken又保存在DisplayContent的键值对集合中。三种关系可以简单总结如下：

窗口动画

我们知道在Android内部有两种动画：Window切换移动动画以及app层的View的动画， 动画操作的是View而Window切换操作的是Surface，对不同层级的SurfaceControl进行操纵，会产生不同的动画效果， 注意区分。

我们这里涉及到的是Window切换移动动画：

但是不管是View的动画还是Window切换操作，对底层屏幕刷新来说都是针对不同帧动画来说，所以会涉及到VSync同步信号相关知识。

核心类：

WindowStateAnimator

类声明：

Keep track of animations and surface operations for a single WindowState.

用来管理一个Window的动画操作的，在WindowState构造方法中创建，说明每个Window窗口都对应一个WindowStateAnimator

WindowState(WindowManagerService service...){
    mWinAnimator = new WindowStateAnimator(this);
}

WindowAnimator：

   /**
   
    * Singleton class that carries out the animations and Surface operations in a separate task
    * on behalf of WindowManagerService.
      */
       public class WindowAnimator

看方法说明，这个类还是用于WMS中的窗口动画以及Surface操作的单例工具类，WMS将动画的工作都委托他来处理。其在WMS构造的时候创建了实例。

WindowAnimator(final WindowManagerService service) {
    mService = service;
    ..
    mWindowPlacerLocked = service.mWindowPlacerLocked;//1 这个类用于Surface的摆放
    AnimationThread.getHandler().runWithScissors(
            () -> mChoreographer = Choreographer.getSfInstance(), 0 /* timeout */);//2

```
mAnimationFrameCallback = frameTimeNs -> {//3
    synchronized (mService.mWindowMap) {
        mAnimationFrameCallbackScheduled = false;
    }
    animate(frameTimeNs);
};
```

}

注释1处创建了一个WindowSurfacePlacer对象，这个对象是用于Surface的摆放的操作，说明WindowAnimator还支持Surface的各种操作 注释2处使用AnimationThread线程进行Window的动画操作，AnimationThread内部使用的是HandlerThread机制，说明其内部也创建了一个异步消息处理机制。 注释3处mAnimationFrameCallback类型是Choreographer.FrameCallback。FrameCallback在这篇文章中有讲过，其就是给Choreographer设置一个回调，在Choreographer接收到 VSync信号时，在doFrame中触发这个回调，一般是用来监听帧率等操作。

而这里是在接收到doFrame的时候回调的是一个animate(frameTimeNs)动画处理的方法。animate函数执行流程很长，包括更新壁纸、转屏动画等逻辑均包含在其中。

那么mAnimationFrameCallback回调是什么时候注册到Choreographer中去的呢？

WindowAnimator的scheduleAnimation方法：

void scheduleAnimation() {
    if (!mAnimationFrameCallbackScheduled) {
        mAnimationFrameCallbackScheduled = true;
        mChoreographer.postFrameCallback(mAnimationFrameCallback);
    }
}

在外部需要进行动画的时候，就会优先scheduleAnimation，将mAnimationFrameCallback注册到Choreographer中去。

我们重点来看animate方法：这个方法内部有这么段代码

dc.updateWindowsForAnimator(this);

表示为了动画去更新Windows：可以进入看看：

void updateWindowsForAnimator(WindowAnimator animator) {
    mTmpWindowAnimator = animator;
    forAllWindows(mUpdateWindowsForAnimator, true /* traverseTopToBottom */);
}
boolean forAllWindows(ToBooleanFunction<WindowState> callback, boolean traverseTopToBottom) {

```
...
final int count = mChildren.size();
for (int i = 0; i < count; i++) {
    final DisplayChildWindowContainer child = mChildren.get(i);
    if (child == mImeWindowsContainers && mService.mInputMethodTarget != null) {
        // In this case the Ime windows will be processed above their target so we skip
        // here.
        continue;
    }
    if (child.forAllWindows(callback, traverseTopToBottom)) {
        return true;
    }
}
...
return false;
```

}

forAllWindows方法会遍历整个容器树都去调用mUpdateWindowsForAnimator回调。这个回调内部就会去执行winAnimator.stepAnimationLocked去更新Window的更新操作。 stepAnimationLocked，代表单步动画。这里面的操作大家自行查看也不难、

这里对动画做个小结: 通过在需要动画的时候，post一个FrameCallBack给Choreographer，在VSync信号到来的时候，会优先执行动画操作。动画回调内部会去遍历整个容器树模型，依次更改每个Window对应的Surface的状态。然后在绘制完成后，提交给SurfaceFlinger、

过程图示：

输入事件处理：

关于Input事件在这篇文章中已经有讲过。输入子系统从驱动文件中读取事件后，再封装提交给IMS，IMS再发送给WMS进行处理。

输入系统整体架构：

今天我们从WMS的角度来分析下输入事件：

核心类：

InputChannel

类声明：

/**

 * An input channel specifies the file descriptors used to send input events to
 * a window in another process.  It is Parcelable so that it can be sent
 * to the process that is to receive events.  Only one thread should be reading
 * from an InputChannel at a time.
 * @hide
   */
    public final class InputChannel implements Parcelable {

注释中说明了：InputChannel是一个使用文件描述符fd来发送input事件给其他进程的一个输入通道，且只有一个线程可以同时读取InputChannel中的数据，说明InputChannel是线程安全的。 其内部使用的是socket通讯。

前面在分析Window添加过程的时候说过在WMS的addWindow中会调用

win.openInputChannel(outInputChannel)

void openInputChannel(InputChannel outInputChannel) {
    ...
    String name = getName();
    InputChannel[] inputChannels = InputChannel.openInputChannelPair(name);//1
    mInputChannel = inputChannels[0];
    mClientChannel = inputChannels[1];
    mInputWindowHandle.inputChannel = inputChannels[0];
    if (outInputChannel != null) {
        mClientChannel.transferTo(outInputChannel);//2
        mClientChannel.dispose();
        mClientChannel = null;
    }
    ...
    mService.mInputManager.registerInputChannel(mInputChannel, mInputWindowHandle);//3
}
InputChannel.java:
public static InputChannel[] openInputChannelPair(String name) {
    ...
    return nativeOpenInputChannelPair(name);
}
android_view_InputChannel.cpp:
static jobjectArray android_view_InputChannel_nativeOpenInputChannelPair(JNIEnv* env...) {
    ...
    sp<InputChannel> serverChannel;
    sp<InputChannel> clientChannel;
    status_t result = InputChannel::openInputChannelPair(name, serverChannel, clientChannel);


```
jobjectArray channelPair = env->NewObjectArray(2, gInputChannelClassInfo.clazz, NULL);
jobject serverChannelObj = android_view_InputChannel_createInputChannel(env,
        std::make_unique<NativeInputChannel>(serverChannel));
jobject clientChannelObj = android_view_InputChannel_createInputChannel(env,
        std::make_unique<NativeInputChannel>(clientChannel));
...
env->SetObjectArrayElement(channelPair, 0, serverChannelObj);
env->SetObjectArrayElement(channelPair, 1, clientChannelObj);
return channelPair;
```

}

status_t InputChannel::openInputChannelPair(const String8& name,
        sp<InputChannel>& outServerChannel, sp<InputChannel>& outClientChannel) {
    int sockets[2];
    if (socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sockets)) {
        ...
        return result;
    }
    ...
    outServerChannel = new InputChannel(serverChannelName, sockets[0]);
    outClientChannel = new InputChannel(clientChannelName, sockets[1]);
    return OK;
}

通过以上代码可以看出InputChannel使用的是sockets通讯，且WindowState的openInputChannel中注释1处：

InputChannel[] inputChannels = InputChannel.openInputChannelPair(name)，

返回的inputChannels是一个服务端和客户端的输入通道数组其中：

下标0：表示服务端的InputChannel
下标1：表示客户端的InputChannel

在注释3处registerInputChannel传入的是server端InputChannel给IMS。而注释2处将client端的InputChannel与app端传入的outInputChannel关联起来了。

这样服务端在InputChannel就可以写入input事件，然后在app端的InputChannel就可以接受到数据了。输入事件通讯模型如下：

Surface管理：

WMS负责创建Surface以及对Surface的摆放工作，之后将Surface提交给SurfaceFlinger进行合并。 在App层也创建了一个Surface对象，但是那个是空对象，用于WMS的填充。

Surface的创建：

Surface的创建在WMS中使用WindowStateAnimator代理创建，而WindowStateAnimator中又创建了一个WindowSurfaceController对Surface进行管理。

核心类：WindowSurfaceController

public WindowSurfaceController(SurfaceSession s, String name, int w, int h...){
	mSurfaceControl = new SurfaceControl(s, name, w, h, format, flags, windowType, ownerUid);
}
public SurfaceControl(SurfaceSession session, String name, ...){
	mNativeObject = nativeCreate(session, name, w, h, format, flags,...);
}

在其构造方法中创建了一个SurfaceControl,SurfaceControl最终进入native层，在native层创建了一个Surface，并返回native surface地址.实际在native层也是创建一个SurfaceControl

static jlong nativeCreate(JNIEnv* env, jclass clazz, jobject sessionObj,
        jstring nameStr, jint w, jint h, jint format, jint flags, jlong parentObject,
        jint windowType, jint ownerUid) {

    ```
    sp<SurfaceComposerClient> client(android_view_SurfaceSession_getClient(env, sessionObj));
    SurfaceControl *parent = reinterpret_cast<SurfaceControl*>(parentObject);
    sp<SurfaceControl> surface = client->createSurface(
            String8(name.c_str()), w, h, format, flags, parent, windowType, ownerUid);
    ...
    return reinterpret_cast<jlong>(surface.get());
    ```
}

那app层是什么时候发起WMS的Surface创建任务的？ 看ViewRootImpl的relayoutWindow方法：

private int relayoutWindow(WindowManager.LayoutParams params..){
    int relayoutResult = mWindowSession.relayout(mWindow, mSeq, params...mSurface);
}

调用mWindowSession的relayout方法，并传入最后mSurface对象，这是空Surface，在WMS中会被填充返回 最终调用到WMS中的relayoutWindow。

public int relayoutWindow(Session session, IWindow client, int seq..){
    ...
    result = createSurfaceControl(outSurface, result, win, winAnimator);           
}
private int createSurfaceControl(Surface outSurface, int result, WindowState win,
        WindowStateAnimator winAnimator) {
    
    ```
    WindowSurfaceController surfaceController;
    try {
        surfaceController = winAnimator.createSurfaceLocked(win.mAttrs.type, win.mOwnerUid);
    } finally {
        Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
    }
    if (surfaceController != null) {
        surfaceController.getSurface(outSurface);//1
        if (SHOW_TRANSACTIONS) Slog.i(TAG_WM, "  OUT SURFACE " + outSurface + ": copied");
    } 
    return result;
    ```
    
}

最终会调用WindowStateAnimator的createSurfaceLocked这个前面已经分析过了。返回的surfaceController对象在注释1处调用getSurface(outSurface)，将native层的Surface填充到App传递过来的outSurface 进入getSurface看看：

WindowSurfaceController.java
void getSurface(Surface outSurface) {
    outSurface.copyFrom(mSurfaceControl);
}
Surface.java
public void copyFrom(SurfaceControl other) {
    if (other == null) {
        throw new IllegalArgumentException("other must not be null");
    }
    
    ```
    long surfaceControlPtr = other.mNativeObject;
    if (surfaceControlPtr == 0) {
        throw new NullPointerException(
                "null SurfaceControl native object. Are you using a released SurfaceControl?");
    }
    long newNativeObject = nativeGetFromSurfaceControl(surfaceControlPtr);
    
    synchronized (mLock) {
        if (mNativeObject != 0) {
            nativeRelease(mNativeObject);
        }
        setNativeObjectLocked(newNativeObject);
    }
    ```

}
private void setNativeObjectLocked(long ptr) {
    if (mNativeObject != ptr) {
        mNativeObject = ptr;
    }
}

getSurface方法将WMS中创建的WindowSurfaceController中SurfaceControl对象的mNativeObject对象传递给新的Surface，并使用这个对象去native层获取一个新的NativeObject 赋值给当前Surface的mNativeObject，这样App层的Surface就获取到了WMS在native中创建的SurfaceControl对象，可以在app层操作native层的Surface了。

那么为什么谷歌要绕这么大圈来创建Surface呢?直接在App层去创建不就可以了么？

个人见解谷歌是希望统一管理Surface而不是单独让某个应用持有，且Surface的摆放操作等都是得由WMS进行处理，所以就直接让WMS去创建，然后返回给App层去绘制Surface操作。

Surface的摆放：

Surface在创建之后还需要进行屏幕位置的确认，那这个在哪里操作呢？

核心类：WindowSurfacePlacer

WMS在构造的时候就创建了WindowSurfacePlacer对象。这个对象主要用来给Surface进行位置的定位、

定位到WindowSurfacePlacer的performSurfacePlacement方法，这个方法可以说是WMS最核心的方法，其负责了所有窗口的摆放工作：如何显示？显示在屏幕什么位置？区域大小等。这些将在确认后，下发给SurfaceFlinger进行处理。

WMS中任何窗口状态发生改变都会触发该方法，整个方法进行容器树的遍历，确认窗口可见性等。

final void performSurfacePlacement(boolean force) {
    
    ```
    int loopCount = 6;
    do {
        mTraversalScheduled = false;
        performSurfacePlacementLoop();
        loopCount--;
    } while (mTraversalScheduled && loopCount > 0);
    ```
    
}

private void performSurfacePlacementLoop() {
    ...
    mInLayout = true;
    mService.mRoot.performSurfacePlacement(recoveringMemory);
    mInLayout = false;
    if (mService.mRoot.isLayoutNeeded()) {
        if (++mLayoutRepeatCount < 6) {
            requestTraversal();
        } else {
            Slog.e(TAG, "Performed 6 layouts in a row. Skipping");
            mLayoutRepeatCount = 0;
        }
    } else {
        mLayoutRepeatCount = 0;
    }   
}

performSurfacePlacement最终会调用到mService.mRoot.performSurfacePlacement， mService.mRoot.performSurfacePlacement中最终会执行到对窗口容器树做以下遍历操作,中间代码跳转太多，就略过了。 主要做了下面三件事：

1.DisplayContent的mPerformLayout操作：计算所有DisplayFrame以及WindowFrame的大小和位置

private final Consumer<WindowState> mPerformLayout = w -> {
    ...
    mService.mPolicy.layoutWindowLw(w, null);
    ...
}
mPolicy = PhoneManagerPolicy
PhoneManagerPolicy.java
public void layoutWindowLw(WindowState win, WindowState attached) {
    //这里面都是对不同给的Window的位置进行确认
    computeFrameLw(....);//这个方法会计算所有DisplayFrame以及WindowFrame的大小和位置
}

2.DisplayContent的mApplySurfaceChangesTransaction操作：


private final Consumer<WindowState> mApplySurfaceChangesTransaction = w -> {
    ..前面一大推处理
    winAnimator.setSurfaceBoundariesLocked(mTmpRecoveringMemory /* recoveringMemory */);
  }
  winAnimator = WindowStateAnimator
  WindowStateAnimator.java

  void setSurfaceBoundariesLocked(final boolean recoveringMemory) {
    calculateSurfaceBounds(w, attrs);//1
    mSurfaceResized = mSurfaceController.setSizeInTransaction(
                      mTmpSize.width(), mTmpSize.height(), recoveringMemory);//2
    ...
    mSurfaceController.setPositionInTransaction((float) Math.floor(posX),
                      (float) Math.floor(posY), recoveringMemory);//3

}

注释1处计算Surface的size大小，然后在注释2处使用mSurfaceController设置到native层的SurfaceController对象中， 注释3处在计算好位置后，也使用mSurfaceController设置到native层的SurfaceController对象中。 这样就将Surface在屏幕中给的位置以及大小都确认下来了、

3.WindowStateAnimator的commitFinishDrawingLocked();提交事务

boolean commitFinishDrawingLocked() {

    ```
    mDrawState = READY_TO_SHOW;
    boolean result = false;
    final AppWindowToken atoken = mWin.mAppToken;
    if (atoken == null || atoken.allDrawn || mWin.mAttrs.type == TYPE_APPLICATION_STARTING) {
        result = mWin.performShowLocked();
    }
    return result;
    ```

}

boolean performShowLocked() {
    final int drawState = mWinAnimator.mDrawState;
    if ((drawState == HAS_DRAWN || drawState == READY_TO_SHOW)
            && mAttrs.type != TYPE_APPLICATION_STARTING && mAppToken != null) {
        mAppToken.onFirstWindowDrawn(this, mWinAnimator);
    }

    ```
    if (mWinAnimator.mDrawState != READY_TO_SHOW || !isReadyForDisplay()) {
        return false;
    }
    
    logPerformShow("Showing ");
    
    mService.enableScreenIfNeededLocked();
    mWinAnimator.applyEnterAnimationLocked();
    
    mWinAnimator.mDrawState = HAS_DRAWN;
    mService.scheduleAnimationLocked();//1
    
    if (mHidden) {
        mHidden = false;
        final DisplayContent displayContent = getDisplayContent();  
        //2
        for (int i = mChildren.size() - 1; i >= 0; --i) {
            final WindowState c = mChildren.get(i);
            if (c.mWinAnimator.mSurfaceController != null) {
                c.performShowLocked();
            }
        }
    }
    ```
    
    }

performShowLocked方法中有大量的对窗口状态的判断：窗口的显示过程共有五个状态：

NO_SURFACE：

在创建WindowState后的默认状态，表示当前窗口还创没有执行relayout()方法创建Surface；
DRAW_PENDING：

执行relayout()方法后，创建完成Surface后的状态，表示等待绘制；
COMMIT_DRAW_PENDING：

窗口Surface上完成绘制后的状态，执行WindowStateAnimator#finishDrawingLocked()方法设置，表示已经完成绘制，等待下次刷帧进行提交；
READY_TO_SHOW：

表示窗口已经绘制完成并且完成提交，此时如果该窗口的兄弟窗口全部完成绘制且满足显示要求，则直接进行HAS_DRAWN的转变完成显示，否则等待其他兄弟窗口完成绘制后，再进行HAS_DRAWN转变；-
HAS_DRAWN：表示该窗口正式显示；

在注释2处又对窗口容器树进行了遍历：都指向performShowLocked方法在注释1处调用了WMS的scheduleAnimationLocked方法，如果你还有印象，在前面分析窗口动画的时候说过，scheduleAnimationLocked方法会将动画帧回调FrameCallback设置到Choreographer中去。 然后在VSYNC信号到来的时候，指向CallBack动画回调、最后执行animate

private void animate(long frameTimeNs) {
    //..
    for (int i = 0; i < numDisplays; i++) {
        final int displayId = mDisplayContentsAnimators.keyAt(i);
        final DisplayContent dc = mService.mRoot.getDisplayContentOrCreate(displayId);
        ...
        dc.prepareWindowSurfaces();
}
void prepareWindowSurfaces() {
    forAllWindows(mPrepareWindowSurfaces, false / traverseTopToBottom */);
}

private final Consumer<WindowState> mPrepareWindowSurfaces =
        w -> w.mWinAnimator.prepareSurfaceLocked(true);

void prepareSurfaceLocked(final boolean recoveringMemory) {
    boolean prepared = mSurfaceController.prepareToShowInTransaction(mShownAlpha,..);//1
    
    ```
    mSurfaceController.setLayer(mAnimLayer);//2
    
    showSurfaceRobustlyLocked()//3
    ```

}
private boolean showSurfaceRobustlyLocked() {
    final Task task = mWin.getTask();
    if (task != null && StackId.windowsAreScaleable(task.mStack.mStackId)) {
        mSurfaceController.forceScaleableInTransaction(true);
    }

```
boolean shown = mSurfaceController.showRobustlyInTransaction();
    if (!shown)
        return false;
    
    if (mWin.mTurnOnScreen) {
        if (DEBUG_VISIBILITY) Slog.v(TAG, "Show surface turning screen on: " + mWin);
        mWin.mTurnOnScreen = false;
        mAnimator.mBulkUpdateParams |= SET_TURN_ON_SCREEN;
    }
    return true;
    ```

}

最终在showSurfaceRobustlyLocked中调mSurfaceController.showRobustlyInTransaction()方法进行Surface的提交给SurfaceFlinger进行合成并显示在屏幕上。

可以看到Surface的size，postion以及状态管理，提交执行等操作还是一个比较繁琐的过程。

时序图如下：

总结

本篇文章笔者通过对WMS的责任进行划分，并分别对几个责任进行了较为详细的讲解。

希望这篇文章对你有帮助。如果你想了解更多关于Framework的知识请关注我、

笔者公众号：“小余的自习室”

参考文章：

Android系统中动画浅析

深入理解Android 卷III

"一文读懂"系列：Android屏幕刷新机制

Android R WindowManagerService模块(1) WMS整体架构及启动过程

小余的自习室

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
“一文读懂”系列：无处不在的WMS

前一篇文章介绍了关于Android中Window体系的介绍，主要介绍的是View层的Window体系概念，但是想要深入了解Window在系统中的机制，WMS是绕不过去的坎。有句话说的好：AMS和WMS占据了Framework层的半壁江山，所以了解这两个概念对我们在日常开发中的性能优化或有想转Framework开发的都大有帮助。笔者花了几天时间对WMS相关知识进行了整理。首先我们来说下WMS在系统中的几大职责为了更好的讲解个个核心成员类，我们需要先来理清Window中的容器和树的概念。容器：这个大家都熟悉，在
复制链接

扫一扫