1. 前景回顾

以冷启动的场景看启动 TargetActivity 需要2个条件：

1. TargetActivity 所在的进程需要启动
1. 需要SourceActivity 的 completePause 流程

启动进程和completePause 流程是异步执行的，这2个流程都会执行到 ActivityTaskSupervisor::realStartActivityLocked 方法试图启动 TargetActivity ，但是因为需要同时满足上面的2个条件，所以肯定是后执行到这个方法的流程来触发 TargetActivity 的创建和启动。

不过 TargetActivity 的启动了并不能代表屏幕上就显示了UI数据，中间还有很多流程。

1.2 应用端显示窗口一级框图

一个应用想要将它的UI内容显示到屏幕窗口上，涉及到3个模块：应用端，SystemService端和SurfaceFlinger端。

1. 应用端的Activity启动后，会通过Session与SystemService端通信处理显示UI的逻辑
1. 真正显示是SurfaceFlinger端是控制的，所以SystemService端还需要与SurfaceFlinger端通信

SurfaceFlinger控制屏幕显示，非常重要但不是现在分析的重点，当前阶段以黑盒的形式了解SurfaceFlinger端的概念即可，当前小节要知道SystemService会在relayoutoutWindow流程的时候创建一个Surface返回给客户端绘制。

在Activity启动流程的几篇记录里已经把Activity启动的主流程介绍了，也知道WMS最后做的事是触发了2个事务：LaunchActivityItem 和 ResumeActivityItem ，剩下的逻辑就又交给了应用端处理。这两个事务后续的调用链如下：

arduino 复制代码

LaunchActivityItem::execute
   ActivityThread::handleLaunchActivity
         ActivityThread::performLaunchActivity
            Instrumentation::newActivity      --- 创建Activity
            Activity::attach                  --- 创建Window
               Window::init
               Window::setWindowManager
            Instrumentation::callActivityOnCreate  
               Activity::performCreate
                  Activity::onCreate       --- onCreate

ResumeActivityItem::execute
   ActivityThread::handleResumeActivity
        ActivityThread::performResumeActivity   
            Activity::performResume     
               Instrumentation::callActivityOnResume
                  Activity::onResume          --- onResume
        WindowManagerImpl::addView            --- 创建ViewRootImpl
            WindowManagerGlobal::addView   
               ViewRootImpl::setView          --- 与WMS通信触发窗口的显示逻辑

其中 LaunchActivityItem 事务会触发 Activity 的创建，并且执行到 Activity 的 onCreate 生命周期。

ResumeActivityItem 事务则做了另外2件事：

1. 执行到 Activity 的 onResume 生命周期
1. 与WMS通信触发窗口的显示逻辑

可以看到Activity的创建和生命周期的执行与是否屏幕上有对应的窗口信息没有绝对的联系，因为屏幕上窗口UI的显示是在 ViewRootImpl::setView 方法中触发的。

1.3 应用端显示窗口二级框图

在App开发中一个View想要显示需要经过3个步骤，也就是View三部曲：Measure，Layout，Draw 对应的一个Window想要在屏幕上显示也需要经过3个步骤:

1. addWindow : SystemService端为应用窗口创建对应的WindowState并且挂载到窗口树中
1. relayoutWindow ：这一步会创建一个Surface返回给应用端进行绘制，并且触发WMS的各个窗口的位置摆放（relayout）
1. finishDrawingWindow：这一步是应用端的View绘制完成后，Surface已经有UI信息了，需要通过SurfaceFlinger进行合成

因为是窗口是以 SystemService 端的角度来分析的，所以对比上面的框图，这3个步骤均是在WMS中完成的。而应用端会触发这WMS这3个步骤的执行，从框图中可以看到应用端这边多了一个"View绘制三部曲"的步骤。

这是因为经过第二步relayoutWindow后，应用端就有了一个可以用来绘制的Surface，所以就需要进行View的绘制了，屏幕上窗口显示的UI信息本质性就是View绘制的， View绘制后才可以进行第三步：finishDrawingWindow。

窗口显示的三部曲的触发点都是在 ResumeActivityItem 事务执行到 ViewRootImpl::setView 方法触发的，调用链如下：

arduino 复制代码

ViewRootImpl::setView
   ViewRootImpl::requestLayout
      ViewRootImpl::scheduleTraversals             
            ViewRootImpl.TraversalRunnable::run          --- Vsync相关--scheduleTraversals
               ViewRootImpl::doTraversal
                  ViewRootImpl::performTraversals 
                     ViewRootImpl::relayoutWindow        --- 第二步：relayoutWindow
                        Session::relayout                --- 跨进程调用
                        ViewRootImpl::updateBlastSurfaceIfNeeded
                           Surface::transferFrom         -- 应用端Surface赋值
                     ViewRootImpl::performMeasure        --- View绘制三部曲
                     ViewRootImpl::performLayout
                     ViewRootImpl::performDraw        
                     ViewRootImpl::createSyncIfNeeded    --- 第三步：绘制完成 finishDrawingWindow
   Session.addToDisplayAsUser                     --- 第一步：addWindow

doTraversal 方法是异步执行，所以 Session.addToDisplayAsUser 触发的 addWindow 流程是比 relayoutWindow 先执行的。

上一篇介绍addWindow流程知道在 SystemService 端已经为应用窗口创建对应的WindowState并且挂载到窗口树中了，现在开始分析第二步：relayoutWindow。

relayoutWindow 流程主要做了2件事：

1. 创建装载View绘制数据的Surface
1. 触发窗口摆放，计算窗口位置

本篇分析 relayoutWindow 的第一件事：创建装载View绘制数据的Surface

本篇的核心内容和窗口层级-4-Surface树中的 "Buff类型Surface的创建与挂载" 小结内容是一样的，但是本篇会先把前面的调用流程介绍完全。

2. 正文

在【addWindow流程】中分析了一个WindowState是如何创建并被挂载到层级树中的，但是WindowState本身也是一个"容器"，其对应的Surface也是一个"容器"类型的Surface，没有UI数据。

在【WindowContainer窗口层级-4-Surface树】中也知道了SurfaceFlinger层也映射了一个Surface树，还知道了 "容器"类型和"Buff"类型Surface的区别。

下面完整介绍 relayoutWindow 流程是如何创建"Buff"类型Surface的。

2.1 应用端逻辑处理

开始撸代码，先看一下 ViewRootImpl::setView 方法

java 复制代码

# ViewRootImpl

   public final Surface mSurface = new Surface();
   private final SurfaceControl mSurfaceControl = new SurfaceControl();
   final IWindowSession mWindowSession;
    
   public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView,
            int userId) {
      synchronized (this) {
            // 当前第一次执行肯定为null
            if (mView == null) {
               mView = view;
               ......
               int res; // 定义稍后跨进程add返回的结果
               // 重点* 第二步：会触发relayoutWindow
               requestLayout();  
               InputChannel inputChannel = null; // input事件相关
               if ((mWindowAttributes.inputFeatures
                    & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {
                  inputChannel = new InputChannel();
               }
               ......
               try {
                    ......
                    // 重点* 第一步：addWindow流程
                  res = mWindowSession.addToDisplayAsUser(mWindow, mWindowAttributes,
                           getHostVisibility(), mDisplay.getDisplayId(), userId,
                           mInsetsController.getRequestedVisibilities(), inputChannel, mTempInsets,
                           mTempControls);
                  ......
               }
               // 后续流程与addWindow主流程无关，但是也非常重要
               ......
               // 计算window的尺寸
               ......
               if (res < WindowManagerGlobal.ADD_OKAY) {
                  ......// 对WMS调用后的结果判断是什么错误
               }
               ......
               view.assignParent(this); //这就是为什么decorView调用getParent返回的是ViewRootImpl的原因
               ......
            }
         }
   }

1. 首先看到 ViewRootImpl 下面有2个和Surface相关的变量 mSurface，mSurfaceControl。但是点击去会发现都没什么东西，这是因为真正的Suface创建是在 SystemSerive 端触发
1. 调用 addToDisplayAsUser 方法触发了addWindow 流程
1. 本篇重点，触发 relayoutWindow

requestLayout 这个方法写App的同学可能比较熟悉，布局刷新的使用调用 View::requestLayout 虽然不是当前 ViewRootImpl 下的这个方法，但是最终也会触发 ViewRootImpl::requestLayout 的执行。

所以看看ViewRootImpl::requestLayout的代码

typescript 复制代码

# ViewRootImpl

   boolean mLayoutRequested;

   @Override
   public void requestLayout() {
         if (!mHandlingLayoutInLayoutRequest) {
            ......
            // 只有主线程才能更新UI
            checkThread();
            // 正确请求layout
            mLayoutRequested = true;
            scheduleTraversals();
         }
   }

   void checkThread() {
        if (mThread != Thread.currentThread()) {
            throw new CalledFromWrongThreadException(
                    "Only the original thread that created a view hierarchy can touch its views.");
        }
    }

这个方法主要是做了2件事

1. 线程检查，可以看到checkThread() 方法的报错很多写App的同学就很熟悉：不能在子线程更新UI。
1. 执行 scheduleTraversals()

scss 复制代码

# ViewRootImpl

   final TraversalRunnable mTraversalRunnable = new TraversalRunnable();

   //  是否在执行scheduleTraversals
   public boolean mTraversalScheduled;

   void scheduleTraversals() {
         // 如果遍历操作尚未被调度 
         if (!mTraversalScheduled) {
            // 将调度标志设置为true，表示遍历操作已被调度
            mTraversalScheduled = true;
            // 设置一个同步屏障 
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            // 重点 * 执行mTraversalRunnable
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            // 通知渲染器有一个新的帧即将开始处理
            notifyRendererOfFramePending();
            // 根据需要戳一下绘制锁
            pokeDrawLockIfNeeded();
         }
   }

这个方法虽然代码不多，但是还是有不少知识点的，比如：同步屏障，Vsync，感兴趣的自行了解，当前不做拓展。

当前只要知道当下一个软件Vsync到来的时候，会执行 TraversalRunnable 这个 Runnable 就好，所以重点看看这个 TraversalRunnable 做了什么。

前面看 ViewRootImpl::setView 方法的时候看到在代码顺序上是先执行 requestLayout 再执行 addToDisplayAsUser，就是因为 requestLayout 方法内部需要等待 Vsync 的到来，并且还是异步执行Runable，所以 addToDisplayAsUser 触发的 addWindow 流程是先于 relayoutWindow 流程执行的。

scss 复制代码

# ViewRootImpl

   final class TraversalRunnable implements Runnable {
         @Override
         public void run() {
            doTraversal();
         }
   }

   void doTraversal() {
         if (mTraversalScheduled) {
            // 正在执行或已经执行完毕 
            mTraversalScheduled = false;
            // 移除同步屏障
            mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
            .....
            performTraversals();
            ......
         }
      }

这里移除了同步屏障，那么 mHandler 就可以正常处理后面的消息了，主要流程还是在 performTraversals() 中，这个方法非常重要。我手上android 13的源码中这个方法有1890行。所以我省略了很多代码，保留了个人认为和当前学习相关的一些逻辑，本篇重点看注释的第2步relayoutWindow。

ini 复制代码

# ViewRootImpl

   private void performTraversals() {
      ......
      
      // mWinFrame保存的是当前窗口的尺寸
      Rect frame = mWinFrame;
      ----1.1 硬绘相关----
      // 硬件加速是否初始化
      boolean hwInitialized = false;
      ......
      ----2. relayoutWindow流程----
      // 内部会将经过WMS计算后的窗口尺寸给mWinFrame
      relayoutResult = relayoutWindow(params, viewVisibility, insetsPending);
      ......
      // 1.2 初始化硬件加速，将Surface与硬件加速绑定
      hwInitialized = mAttachInfo.mThreadedRenderer.initialize(mSurface);
      ......
      ----3. View绘制三部曲----
      performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
      ......
      performLayout(lp, mWidth, mHeight);
      ......
      ----4. finishDrawing流程----
      createSyncIfNeeded();
      ......   
      if (!performDraw() && mSyncBufferCallback != null) {
         mSyncBufferCallback.onBufferReady(null);
      }
      ......
      // 触发执行回调
      mSurfaceSyncer.markSyncReady(mSyncId);
      ......
   }

1. 后续需要介绍软绘硬绘的流程，所以可以看到硬绘的初始化逻辑也在这个方法
1. relayoutWindow 相关，也是当前分析重点
1. 经过第第二步relayoutWindow后就View就可以绘制了，也是需要分析的重点流程，后面会陆续写博客
1. 绘制完成后就要通知SurfaceFlinger进行合作了，finishDrawing流程也很重要。

上面的分析有个印象就好，当前不关注其他，只看 relayoutWindow 流程，关心的太多没有重点分析对象就很容易跑偏。

2.2 ViewRootImpl::relayoutWindow

ViewRootImpl::relayoutWindow方法如下：

java 复制代码

# ViewRootImpl

   public final Surface mSurface = new Surface();
   private final SurfaceControl mSurfaceControl = new SurfaceControl();

   private int relayoutWindow(WindowManager.LayoutParams params, int viewVisibility,
            boolean insetsPending) throws RemoteException {
               ......
               // 重点* 1. 调用WMS的 relayoutWindow流程
               int relayoutResult = mWindowSession.relayout(mWindow, ...,mTmpFrames, ..., mSurfaceControl,...);
               ......
               if (mSurfaceControl.isValid()) {
                  if (!useBLAST()) {
                     mSurface.copyFrom(mSurfaceControl);
                  } else {
                     // 重点* 2. 给当前的成员变量mSurface赋值
                     updateBlastSurfaceIfNeeded(); // 目前版本都走这
                  }
                  if (mAttachInfo.mThreadedRenderer != null) {
                     // 重点* 3. 置硬件加速渲染器的 SurfaceControl 和 BlastBufferQueue
                     mAttachInfo.mThreadedRenderer.setSurfaceControl(mSurfaceControl);
                     mAttachInfo.mThreadedRenderer.setBlastBufferQueue(mBlastBufferQueue);
                  }
               } else ......
               // 将WMS计算的窗口大小设置到当前
               setFrame(mTmpFrames.frame);
               return relayoutResult;
            }

这个方法主要就是跨进程通信触发 WMS的relayoutWindow流程，注意这里将 mTmpFrames 和 mSurfaceControl 作为参数传递了过去。执行这个方法前 mSurfaceControl 只是一个没有实际内容的对象，但是经过 WMS::relayoutWindow 流程处理后，mSurfaceControl 就会真正持有一个 native层的Surface句柄，有个这个native的Surface句柄，View就可以把图像数据保存到Surface中了。

而mTmpFrames 表示临时窗口大小，和 mSurfaceControl 一样传递给WMS处理，然后由WMS计算出一个值再返回到应用端。

上面这个方法我标记了3个重点，除了第一个重点是主流程外，后面2个重点都是在应用端真正拿到Surface后的处理，比如第三点会把Surface设置给硬绘渲染器。重点二是给ViewRootImpl下的mSurface赋值，执行完后这个 mSurface也就持有一个 native层的Surface句柄。

在看主流程之前先看一下ViewRootImpl::updateBlastSurfaceIfNeeded 方法：

scss 复制代码

# ViewRootImpl

    private BLASTBufferQueue mBlastBufferQueue;
    
    void updateBlastSurfaceIfNeeded() {
        // 经过system_service处理后的mSurfaceControl有值
        if (!mSurfaceControl.isValid()) {
            return;
        }
        ......
        // 创建对象
        mBlastBufferQueue = new BLASTBufferQueue(mTag, mSurfaceControl,
                mSurfaceSize.x, mSurfaceSize.y, mWindowAttributes.format);
        mBlastBufferQueue.setTransactionHangCallback(sTransactionHangCallback);
        Surface blastSurface = mBlastBufferQueue.createSurface();
        // Only call transferFrom if the surface has changed to prevent inc the generation ID and
        // causing EGL resources to be recreated.
        // 给当前mSurface赋值
        mSurface.transferFrom(blastSurface);
    }

现在知道 WMS::relayoutWindow 流程执行后拿应用端拿到到Surface的一些处理，需要回头正式看一下 relayoutWindow到底做了什么。

2.3 WindowManagerService::relayoutWindow

应该端通过Session 与 SystemService 端通信

typescript 复制代码

# Session
    @Override
    public int relayout(IWindow window, ...ClientWindowFrames outFrames,...SurfaceControl outSurfaceControl,...) {
      ......
      int res = mService.relayoutWindow(this, window, attrs,
                requestedWidth, requestedHeight, viewFlags, flags,
                outFrames, mergedConfiguration, outSurfaceControl, outInsetsState,
                outActiveControls, outSyncSeqIdBundle);
      ......
      return res;
    }

主要就是调用到通过Session调用到WMS的relayoutWindow流程，上面看到在ViewRootImpl的mSurface和mSurfaceControl对象都是直接创建的，然后将mSurfaceControl专递到了WMS，这里注意在 Session::relayout 方法的参数中应用端传过来的 mSurfaceControl 变成了：outSurfaceControl，说明这是个出参，会在 WMS::relayoutWindow 对其进行真正的赋值。

outFrames 参数也同理。

WindowManagerService::relayoutWindow 代码如下：

java 复制代码

# WindowManagerService

   public int relayoutWindow(Session session, IWindow client, LayoutParams attrs,
            int requestedWidth, int requestedHeight, int viewVisibility, int flags,
            ClientWindowFrames outFrames, MergedConfiguration mergedConfiguration,
            SurfaceControl outSurfaceControl, InsetsState outInsetsState,
            InsetsSourceControl[] outActiveControls, Bundle outSyncIdBundle) {
         ......
         synchronized (mGlobalLock) {
            // 重点* 从mWindowMap中获取WindowState
            final WindowState win = windowForClientLocked(session, client, false);
            if (win == null) {
                return 0;
            }
            ......
            if (attrs != null) {
                // 调整窗口属性和类型
                displayPolicy.adjustWindowParamsLw(win, attrs);
                attrs.flags = sanitizeFlagSlippery(attrs.flags, win.getName(), uid, pid);
                inAnimator.mAlpha = attrs.alpha;
                ......
            }
            .......
            // 设置窗口可见 viewVisibility = VISIBLE
            win.setViewVisibility(viewVisibility);
            // 打印Proto日志
            ProtoLog.i(WM_DEBUG_SCREEN_ON,
                    "Relayout %s: oldVis=%d newVis=%d. %s", win, oldVisibility,
                            viewVisibility, new RuntimeException().fillInStackTrace());
            ......
            if (shouldRelayout) {
                try {
                    // 重点* 1. 创建SurfaceControl
                    result = createSurfaceControl(outSurfaceControl, result, win, winAnimator);
                } catch (Exception e) {
                    ......
                    return 0;
                }
            }

            // 重点* 2. 摆放Window的Surface （极其重要的方法）
            mWindowPlacerLocked.performSurfacePlacement(true /* force */);
            ......
            if (focusMayChange) {
                // 更新焦点
                if (updateFocusedWindowLocked(UPDATE_FOCUS_NORMAL, true /*updateInputWindows*/)) {
                    imMayMove = false;
                }
            }
            ......
            // 重点* 填充WMS计算好后的数据，返回应用端
            win.fillClientWindowFramesAndConfiguration(outFrames, mergedConfiguration,
                    false /* useLatestConfig */, shouldRelayout);
            ......
         }

         Binder.restoreCallingIdentity(origId);
         return result;
      }

方法开始就执行了 windowForClientLocked 方法是从mWindowMap去获取WindowState，mWindowMap在【addWindow流程】讲过了。然后 setViewVisibility 设置可见性了，这里的参数是传过来的，根据打印的ProtoLog:

ini 复制代码

09-25 14:10:36.963 10280 16547 I WindowManager: Relayout Window{2fa12a u0 com.example.myapplication/com.example.myapplication.MainActivity2}: oldVis=4 newVis=0. java.lang.RuntimeException

值为0，也就是VISIBLE了。

这个方法在WMS中也是个核心方法了，注释都在代码中了，当前分析的 relayoutWindow 流程，所以主要跟踪下面2个执行逻辑：

1. createSurfaceControl ：创建"Buff"类型的Surface
1. performSurfacePlacement ：窗口的摆放（View一般有变化也要执行 layout，WMS在管理窗口这边肯定也要执行layout）最后将WMS模块计算的结果通过WindowState::fillClientWindowFramesAndConfiguration进行填充，带回应用进程。

由于篇幅原因，本篇先介绍 createSurfaceControl 这个分支是如何创建 Surface的。

2.3.1 了解"容器"和"Buff"类型的Surface

看调用栈一般除了debug外，还可以在关键点加上堆栈，比如在SurfaceControl的构造方法加堆栈，只要有触发创建SurfaceControl的地方必然会打印，然后发现有以下2个输出(模拟的场景是在MainActivity点击按钮启动MainActivity2)

addWindow触发的堆栈

yaml 复制代码

09-25 19:42:46.028 13422 14723 E biubiubiu: SurfaceControl mName: 4e72d78 com.example.myapplication/com.example.myapplication.MainActivity2  mCallsiteWindowContainer.setInitialSurfaceControlProperties
09-25 19:42:46.028 13422 14723 E biubiubiu: java.lang.Exception
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at android.view.SurfaceControl.<init>(SurfaceControl.java:1580)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at android.view.SurfaceControl.<init>(Unknown Source:0)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at android.view.SurfaceControl$Builder.build(SurfaceControl.java:1240)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowContainer.setInitialSurfaceControlProperties(WindowContainer.java:630)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowContainer.createSurfaceControl(WindowContainer.java:626)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowContainer.onParentChanged(WindowContainer.java:607)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowContainer.onParentChanged(WindowContainer.java:594)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowState.onParentChanged(WindowState.java:1341)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowContainer.setParent(WindowContainer.java:584)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowContainer.addChild(WindowContainer.java:730)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowToken.addWindow(WindowToken.java:302)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.ActivityRecord.addWindow(ActivityRecord.java:4248)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowManagerService.addWindow(WindowManagerService.java:1814)
09-25 19:42:46.028 13422 14723 E biubiubiu: 	at com.android.server.wm.Session.addToDisplayAsUser(Session.java:215)

relayoutWindow触发的堆栈

yaml 复制代码

09-25 19:42:46.036 13422 14723 E biubiubiu: SurfaceControl mName: com.example.myapplication/com.example.myapplication.MainActivity2  mCallsiteWindowSurfaceController
09-25 19:42:46.036 13422 14723 E biubiubiu: java.lang.Exception
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at android.view.SurfaceControl.<init>(SurfaceControl.java:1580)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at android.view.SurfaceControl.<init>(Unknown Source:0)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at android.view.SurfaceControl$Builder.build(SurfaceControl.java:1240)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowSurfaceController.<init>(WindowSurfaceController.java:109)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowStateAnimator.createSurfaceLocked(WindowStateAnimator.java:335)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowManagerService.createSurfaceControl(WindowManagerService.java:2686)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at com.android.server.wm.WindowManagerService.relayoutWindow(WindowManagerService.java:2449)
09-25 19:42:46.036 13422 14723 E biubiubiu: 	at com.android.server.wm.Session.relayout(Session.java:267)

发现2个地方创建了SurfaceControl，而且看名字都是为MainActivity2创建的，区别就是调用栈不同，和一个是带 "4e72d78 "这种对象名的，这让我很好奇，然后我立马想到这种类型之前在窗口层级树中见过。于是dump了层级树的信息

果然就是以WindowState的名字取的，看调用栈在addWindow的时候将这个WindowState添加到层级树的时候就创建了。后面的"mCallsiteWindowContainer.setInitialSurfaceControlProperties"2个调用栈输出的也不同，代表的是调用的地方。

这就很奇怪了，在addWindow的时候就创建好了SurfaceControl为什么执行relayoutWindow的时候又创建一个？那到底是用的哪个呢？

我用winscope看了trace后发现原来是下面这个结构：

原来下面创建的才是真正可见的，而带 "4e72d78 "的则是作为parent，dump一下SurfaceFlinger看一下

发现带"4e72d78 " 的是ContainerLayer类型，而下面的是BufferStateLayer类型，也是作为起孩子的存在，我们知道BufferStateLayer类型的才是真正绘制显示数据的Surface。

容器类型的图层不能显示只能作为容器,只有BufferStateLayer才可以作为显示图层

原来在addWindow流程中，将WindowState挂在到层级树中就创建了一个容器类型的SurfaceControl，而后在执行WindowManagerService::relayoutWindow又创建了一个BufferStateLayer类型的SurfaceControl用来做真正的显示数据。

这块的内容和后面的内容其实在窗口层级-4-Surface树也介绍过了，关于"容器"类型比如WindowState的Surface是如何创建就不再重复了，但是"Buff"类型Surface的创建还是需要再说一遍，比较是本篇分析的重点。看过并且熟悉这一流程的可以忽略 2.4 小节

2.4 Buff类型Surface的创建与挂载

2.4.1 流程概览

relayoutWindow的调用链如下：

arduino 复制代码

WindowManagerService::relayoutWindow
   WindowManagerService::createSurfaceControl
      WindowStateAnimator::createSurfaceLocked -- 创建"Buff" 类型Surface
         WindowStateAnimator::resetDrawState   -- 设置窗口状态为DRAW_PENDING
         WindowSurfaceController::init
            SurfaceControl.Builder::build
               SurfaceControl::init
   WindowSurfaceController::getSurfaceControl  -- 给应用端Surface赋值

开始撸代码，WindowManagerService::relayoutWindow 下调用 createSurfaceControl 方法有4个参数

csharp 复制代码

# WindowManagerService 

   public int relayoutWindow(Session session, IWindow client, LayoutParams attrs,
         int requestedWidth, int requestedHeight, int viewVisibility, int flags,
         ClientWindowFrames outFrames, MergedConfiguration mergedConfiguration,
         SurfaceControl outSurfaceControl, InsetsState outInsetsState,
         InsetsSourceControl[] outActiveControls, Bundle outSyncIdBundle) {
         ......
            result = createSurfaceControl(outSurfaceControl, result, win, winAnimator);
         ......
      }

createSurfaceControl 方法有4个参数：

outSurfaceControl: WMS创建好一个Surface后，还需要返回给应用端用于View的绘制，就是通过这个参数，由参数命名也可以知道这是一个"出参"。
result：方法执行结果
win: 当前窗口对应的WindowState,稍后创建Surface会挂载到这个WindowState节点之下
winAnimator：WindowStateAnimator对象，管理窗口状态和动画，稍后通过其内部方法创建Surface

csharp 复制代码

# WindowManagerService
   private int createSurfaceControl(SurfaceControl outSurfaceControl, int result,
      WindowState win, WindowStateAnimator winAnimator) {
      // 1. 创建WindowSurfaceController对象
      WindowSurfaceController surfaceController;
      try {
         // 2. 创建"Buff"类型Surface
         Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "createSurfaceControl");
         surfaceController = winAnimator.createSurfaceLocked();
      } finally {
         Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
      }
      if (surfaceController != null) {
         // 3. 出参给应用端
         surfaceController.getSurfaceControl(outSurfaceControl);
         // 打印日志，outSurfaceControl复制到了framework的值
         ProtoLog.i(WM_SHOW_TRANSACTIONS, "OUT SURFACE %s: copied", outSurfaceControl);

      }......
      return result;
   }

这个方法主要有三步，都是围绕着 WindowSurfaceController 来的：

1. 先创建出一个WindowSurfaceController 对象 surfaceController
1. 通过WindowStateAnimator::createSurfaceLocked 对 surfaceController 赋值，根据方法名猜测是创建了一个Surface
1. 通过 WindowSurfaceController::getSurfaceControl,给应用端 Surface 赋值

这么看来重点是在第二步 WindowStateAnimator::createSurfaceLocked 是如何创建Surface的。

csharp 复制代码

# WindowStateAnimator

   WindowSurfaceController mSurfaceController;
   // WindowState的状态
   int mDrawState;

   WindowSurfaceController createSurfaceLocked() {
      final WindowState w = mWin;
         if (mSurfaceController != null) {
            return mSurfaceController;
      }

      w.setHasSurface(false);
      // 打印窗口状态
      ProtoLog.i(WM_DEBUG_ANIM, "createSurface %s: mDrawState=DRAW_PENDING", this);
      // 重点* 1. 重置窗口状态
      resetDrawState();
      ......
         // 重点* 2. 创建WindowSurfaceController
         mSurfaceController = new WindowSurfaceController(attrs.getTitle().toString(), format,
                    flags, this, attrs.type);
      ......
      return mSurfaceController;
   }

这里有2个重点：

1. 设置窗口状态为 DRAW_PENDING
1. 创建Surface

2.4.2 设置窗口状态--DRAW_PENDING

ini 复制代码

# WindowStateAnimator
   void resetDrawState() {
      // 设置windowState状态为DRAW_PENDING
      mDrawState = DRAW_PENDING;

      if (mWin.mActivityRecord == null) {
         return;
      }

      if (!mWin.mActivityRecord.isAnimating(TRANSITION)) {
         mWin.mActivityRecord.clearAllDrawn();
      }
   }

WindowState有很多状态，以后会单独说，这里需要注意

WindowState状态是保存在WindowStateAnimator中
WindowStateAnimator::createSurfaceLocked方法会将WindowState状态设置为DRAW_PENDING，表示等待绘制。

2.4.3 创建与挂载"Buff"类型Surface

继续回到主流程，看看 WindowSurfaceController 的构造方法

ini 复制代码

# WindowSurfaceController

   SurfaceControl mSurfaceControl;

    WindowSurfaceController(String name, int format, int flags, WindowStateAnimator animator,
            int windowType) {
      mAnimator = animator;
      // 1. 也会作为Surface的name
      title = name;

      mService = animator.mService;
      // 2. 拿到WindowState
      final WindowState win = animator.mWin;
      mWindowType = windowType;
      mWindowSession = win.mSession;

      Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "new SurfaceControl");
      // 3. 重点* 构建Surface（也是通过makeSurface 方法）
      final SurfaceControl.Builder b = win.makeSurface()
               .setParent(win.getSurfaceControl()) // 设置为父节点
               .setName(name)
               .setFormat(format)
               .setFlags(flags)
               .setMetadata(METADATA_WINDOW_TYPE, windowType)
               .setMetadata(METADATA_OWNER_UID, mWindowSession.mUid)
               .setMetadata(METADATA_OWNER_PID, mWindowSession.mPid)
               .setCallsite("WindowSurfaceController");

      final boolean useBLAST = mService.mUseBLAST && ((win.getAttrs().privateFlags
               & WindowManager.LayoutParams.PRIVATE_FLAG_USE_BLAST) != 0);
      // 高版本都为BLAST
      if (useBLAST) {
         // 4. 重点* 设置为"Buff"图层
         b.setBLASTLayer();
      }
      // 触发build
      mSurfaceControl = b.build();
      Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
    }

这个方法有4个点

第一个参数传递的字符串最终也会作为Surface的name
获取到WindowState对象，后面会设置为创建Surface的父节点
构建出一个Surface对象，注意name和父节点的设置。另外可以知道也是通过makeSurface()方法构建的，这个方法会构建出一个"容器"类型的Surface。
将Surface设置为"Buff"类型，这个非常重要，因为上一步默认还是"容器"类型，所以需要设置成"Buff"类型，再后面就是build出一个Surface了

makeSurface() 方法是如何构建Surface的需要移步窗口层级-4-Surface树看第二小节：2 容器类型的创建，就不重复介绍了。

那么到这里Surface的创建就完成了，这里可能有的人如果对Surface知识不太清楚的话会比较迷糊，WindowSurfaceController，SurfaceController，Surface到底是什么关系，这个不在当前流程的重点，暂且理解为同级吧，有WindowSurfaceController就可以拿到内部的SurfaceController，而SurfaceController又可以获取到Surface。

2.4.4 返回Surface到应用端

最后再来看一下 WMS这边创建好后的Surface是如何设置给应用端的。

应用端View的绘制信息都是保存到Surface上的，因为必定要有一个"Buff"类型的Surface，也就是上面流程中创建的这个Surface。

应用端的ViewRootImpl触发WMS的relayoutWindow会传递一个出参：outSurfaceControl过来，现在WMS会通过以下方法将刚刚创建好是Surface传递到应用端。

这样一来应用端就有了可以保持绘制数据的Surface，然后就可以执行 View::draw。

csharp 复制代码

# WindowSurfaceController
    void getSurfaceControl(SurfaceControl outSurfaceControl) {
      // 将framework层的SurfaceControl copy给应用层传递过来的outSurfaceControl
      outSurfaceControl.copyFrom(mSurfaceControl, "WindowSurfaceController.getSurfaceControl");
    }

2.4.5 创建Surface小结

对于Surface的知识是一个复杂的模块，是需要单独详细讲解的，目前可以知道的是原以为给WindowState创建图层就是一个，但是实际上发现创建了2个。

1. WindowState本身对应的是"容器"类型的Surface，在"addWindow流程"就创建了，而relayoutWindow创建的是一个"BufferStateLayer"类型的Surface，这个也是被copy到应用层的Surface，说明应用层的数据是被绘制在这个Surface上的。
1. "BufferStateLayer"类型Surface的创建其实创建一个WindowSurfaceController对象，然后内部会创建SurfaceController。从WindowSurfaceController这个类名也能看出来是针对Window显示的。
1. 不仅仅Framework层的层级树有容器概念 ，SurfaceFlinger里也有容器概念
1. 我们在执行adb shell dumpsys activity containers 看到层级结构树，最底层的WindowState其实也是个容器，不是真正显示的地方。这个点从 "containers"也能理解，毕竟是容器树。

2.4.5.1 WindowState "容器"概念拓展

WindowState是容器这个是肯定的，也是WindowContainer子类，然后他的孩子也是WindowState定义如下：

scala 复制代码

# WindowState
public class WindowState extends WindowContainer<WindowState> implements
        WindowManagerPolicy.WindowState, InsetsControlTarget, InputTarget {

        }

那么什么场景下WindowState下还有孩子呢？答案是子窗口，子窗口的定义在Window类型里，具体的不在当前讨论，之前我一直有个误区，我一直以为我们弹出的Dialog是子窗口，但是实际上并不是，我目前找到了一个比较常见的子窗口是PopupWindow。以在google电话应用打开一个菜单为例

对应的dump 为

看的到子窗口PopupWindow的WindowState是被挂载到Activity的WindowState下对应的winscope trace为：

这里能看到PopupWindow也有一个容器图层和显示图层，容器图层挂载在Activity窗口容器图层下，和Activity窗口显示图层同级

3. 小结

本篇介绍了应用端发起relayoutWindow的逻辑，然后介绍了一些"容器"和"Buff"类型Surface的概念，知道了 relayoutWindow 流程主要是做2件事，本篇介绍了第一件事：创建Surface。下一篇开始分析窗口（Surface）的摆放流程。

【Android 13源码分析】窗口显示第二步:relayoutWindow -1

1. 前景回顾

1.2 应用端显示窗口一级框图

1.3 应用端显示窗口二级框图

2. 正文

2.1 应用端逻辑处理

2.2 ViewRootImpl::relayoutWindow

2.3 WindowManagerService::relayoutWindow

2.3.1 了解"容器"和"Buff"类型的Surface

2.4 Buff类型Surface的创建与挂载

2.4.1 流程概览

2.4.2 设置窗口状态--DRAW_PENDING

2.4.3 创建与挂载"Buff"类型Surface

2.4.4 返回Surface到应用端

2.4.5 创建Surface小结

2.4.5.1 WindowState "容器"概念拓展

3. 小结